Right Data, Right Place, Right Time - Part B
Photo by Jannes Glas on Unsplash
By Mike Beevor, Digi.CIty Expert in Residence - IOT
In part A of “Right Data, Right Place, Right Time” I spoke about examining the human aspects of the solution and the wider picture. This second chapter in this series of articles is both blessedly shorter and begins to discuss the first of the technology considerations in any smart city project to ensure that you are approaching the practical part of your Smart City solution in the correct manner.
The most important thing is to remember the outcome that you are searching for, and what data you absolutely need to understand the problem. Don’t be lured into trialling or purchasing a sensor that claims to gather all possible metrics and with a little manipulation, will give you something that can be interpreted to solve your specific challenge.
I think that Udny Yule said it best:
"In our lust for measurement, we frequently measure that which we can rather than that which we wish to measure... and forget that there is a difference."
Giving that concept an IoT spin, it may be translated as “Right Sensor, Right Place, Right Time” and can be filled out further.
Right Sensor – Make sure that the sensor you are deploying measures something that is pertinent and easily attributable to what you are trying to measure. Any data that you have to manipulate in order to get your metric introduces the opportunity for error and for misinterpretation of the results.
Right Place – I often see this in video surveillance when it comes to placing cameras, especially when the organisation is attempting to process the video with an analytics tool. Taking the oft misunderstood facial recognition technology as an example, placing a video camera in a 40ft ceiling space and trying to read faces on an entrance 40m away, simply isn’t going to be effective!
Right Time – This is the area where I see IoT opportunities fail most of the time. Either the organisation doesn’t capture data at the right time of day/night, or they don’t leave the sensor in place for long enough to get a truly representative sample for the problem they are trying to solve.
The upshot of all of this is that if you have a fault in any of the above methods, you are going to have a fault in your observed results and your conclusions. This is not necessarily the difference between success and failure, but you should understand and be aware of it!
The success of an IoT solutions pilot is a relatively fine line to walk, however. You don’t want to have your pilot deployment in place for six months (without VERY good reason), but you can’t afford to make the pilot too short, or you risk missing vital information.
The final consideration around sensors, should be related directly to the scale of the problem that you are attempting to solve. Over my career in IoT, I have condensed IoT sensor data into three key classes around scale; Micro, Medio and Macro. Scale is also relative, based on the area that you are covering – an appliance in an individual home is akin to a building in a smart city.
Micro-scale is where you are taking the output from a single sensor, observing a single metric and applying understanding based on an incredibly narrow window, or as an isolated sensor. A smart Fridge/Freezer that alerts you if the door has been left open is a great example. I
n a smart city, this may be an individual smart building, as long as it is being treated as a component part of the city as a whole.
Medio-scale is where you are beginning to bring multiple metrics into play, either through a single multi-sensor, or through collaboration between single-capture sensors. The area in which those sensors are operating, may also be slightly larger – a smart power meter in a home that manages multiple devices based upon their energy use and efficiency.
In a smart city, this may be a city block with more than one smart building within it, where the individual data sets from each building are examined and considered as a whole.
Macro-scale elevates us into an entire smart home, where multiple sensors interact to control many aspects of the building. Smart lights may be tied to access control, or proximity detection of the homeowner arriving back from work, and that proximity sensor may trigger the smart thermostat to adjust the temperature in the house to a predetermined or desired setting.
In our city, we are beginning to examine multiple datasets, from multiple sensors, city blocks and buildings to create a city-wide view. The additional aspect to consider in this scenario is time. Changes in patterns, and the effects of small changes in cities often take a number of years to manifest, and the effects of those changes are difficult to pinpoint exactly. Often, it is an imperceptible change each day or week, until a time when everyone suddenly stops and thinks… “Didn’t this used to be different?!”
If you apply these concepts to your smart city deployments and can also understand the category into which your solutions fall, you will gain a stronger understanding of the projects you’re undertaking and the effects that they may have on your city.
Comments? Questions? Want to talk with MIke about IoT/Smart City consulting, opportunities or roles, reach out to him on LinkedIn.