A Smart City is a blending of current and emerging technologies being employed to allow a city to better manage its assets and deliver value to its residents. It is an emerging concept and still very much in exploration. The 2 core technology areas being investigated as the primary value creators are ICT (Information and Communications Technology) and the IoT (Internet of Things).
What isn’t fully understood is the relationships between any or all of the list below:
- what is worth measuring?
- how to measure it (what sensor, what platform)?
- how often?
- in what detail?
- to learn what from?
- how quickly to transport the reading?
- how much will it cost to transport the data?
- via what technologies?
- stored how?
- accessed how?
- analysed how?
Quite a big list.
Did you know there is a Smart Cities Plan for Australia? I only recently found out. And if you read through it there are more questions than answers. Which I think is the right balance given where we are positioned in trying to understand what is possible versus what is useful.
There are some obvious areas already being tackled by ICT systems. These include:
- transport logistics (road, rail, freight, air, sea)
- public transport
- utility services (gas, water, electricity, waste)
- weather prediction
- environmental monitoring
And there are a range of trials underway to try and understand what using a broader sensor mix and more widely deployed sensors might do to improve amenity, even if they aren’t all very high quality sensors. Again the questions come back to:
- what sensors?
- how many and where?
- how accurate?
- how much do they and their platform cost?
- measured how often?
- at what latency?
- what to do with the data?
The first is the IoT Hardware device that is deployed to the field. These come in a wide range of shapes, sizes, power profiles and capabilities. So we are seeing everything from full computing platform devices (Windows, Linux, Other) deployed as well as tiny resource constrained platforms such as Sensor Node devices. Examples of the later are Wimoto Motes and our own FLEXIO Telemetry devices which are OS-less Sensor Nodes.
The trade offs are between:
- power consumption
- power supply
- always online versus post on a schedule or by exception
- cost (device, data, installation, maintenance)
- open standard versus proprietary
- upgrade capable (over the air OTA firmware or software capability)
As of a month ago, the KPMG IoT Innovation Network reported there are 450 different IoT platforms available. And most don’t talk to each other. Many lock you in. Many only work with their specific hardware. So picking a hardware platform is only part of the challenge. And new products appear every week.
The second area of challenge is the communications. Everyone is trying to get away from Cellular IoT Communications because the Telecommunications Companies pricing model has traditionally been higher than they want to pay, and because the power required means you need a much higher power budget. So there has been a push to find other options which has opened the way for players like LoRa and sigfox.
However the CAT-M1 and NB-IoT Telecommunications Standards mean that the pendulum could easily go back the other way. CAT-M1 reduces the data rate (no streaming video needed for most IoT devices) and changes the modulation scheme so you get a better range at a much lower power consumption. And unlike sigfox, you aren’t severely constrained on how much data you can move or how often. CAT-M1 has just gone live in Australia on the Telstra network and we are about to do our first trials.
NB-IoT doesn’t yet have an official availability date but we aren’t too concerned about that. NB-IoT is really aimed at the smart meter market and similar devices which have low amounts of data and upload it infrequently. So a water meter running off battery for 10+ years is an example of what it is targeting. We will find CAT-M1 a lot more useful. And the modules that support CAT-M1 currently also support NB-IoT so we are designing now and can make the decision later.
IoT Back End
The third area of challenge is the back end. Pick the wrong data service and storage provider and you could find you don’t own your own data and you have to pay every time you want a report on it. And you can’t get at it to port it to another system. And if the volume of data grows the cost can grow even faster as many offer a low entry point but the pricing get expensive quickly once you exceed the first threshold.
Because of this there is an strongly emerging preference for open systems or for systems that do allow you to push and pull data as it suits you.
So our strategy to date has been to provide our own intermediate web service and then republish the data in the required format to suit the end user / client. The result is the best of both worlds. We can deploy resource constrained field devices which are low power and low cost, then communicate with high security and high cost platforms using the intermediate service to do the heavy lifting. And we don’t try and imprison the data and trap the client.
This isn’t the only approach and so we also create devices and incorporate protocols that allow them to directly connect to other systems. This includes porting our core IP to other URLs which are then owned by our clients. So far we haven’t found that one single approach suits every scenario.
You can’t be smart if you don’t know anything. And this is certainly true for Smart Cities. To be a Smart City requires Sensors and Telemetry. But the jury is still out on how much and what kind.
Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In Australia. Ray Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2017 Successful Endeavours Pty Ltd.