Building Your Smart Meter
Journey with IoT
IoT Technologist, Sean van der Walt, takes us on a journey of building, managing, and deploying smart meters.
In this webinar, we cover the following topics:
- Smart Meters at status-quo and advancing with new technology
- Building Blocks for Smart Metering
- Managing and Deploying Smart Meters
- Realizing Smart Meter data
Friendly Technologies is at the forefront of managing IoT devices globally, having been one of the very first to work with battery-powered NB-IoT smart water meters more than four years ago and to have recently been chosen by a Fortune 500 company to deploy the largest IoT device deployment (more than 1 Billion NB-IoT devices) in recent times.
Transcript:
Ariela: Welcome to the session for Build your Smart Meter Journey with IoT, featuring Shawn van der Walt. I am Ariela Ross, Head of Marketing at Friendly Technologies. I appreciate you taking the time out of your day to join us for this webinar. And if you have any questions, go ahead and put them into the box. Let’s go ahead and hand it over to you Sean.
Sean: Good evening and good morning, everyone. Thank you for attending our webinar. This webinar is intended as a high-level technical presentation. And I will also be doing a short demonstration. So today, the topic is Build your Smart Meter Journey with the Internet of Things. So what we’re going to cover in the session now is we’re going to be looking at using cellular Low Power WAN, and in particular narrowband IoT in this case. There are a few reasons for that and we could probably go into detail around why that is.
So we’re going to be looking at some Smart Meter concepts, looking at how that’s integrated, and how that is utilized on narrowband IoT, together with some of the communications protocols, and some of the modules. So just looking at sort of the Smart Meter ecosystem. We’re going to be looking at the communications network. So the cellular network, the embedded SIMs, and the SIM management. We’re also going to be looking a little bit around the meter device management, what is required in terms of managing these, if not 1000s, 10s, or hundreds of millions of devices in the field. And last but not least, we’re going to be covering the meter data management, and what is required to be able to egest and utilize such meter data.
So first of all, you’re obviously familiar with legacy meters. Now, the topic today is sort of covering the water meter use case, but I’ll briefly talk about some of the gas metering and electricity metering. So from a meter point of view, there’s the legacy meter approach, there are big deployed base o legacy meters. And so the approach there is obviously having an add-on module. So the top diagram is just showing you an existing legacy meter with some add-on modules. So this could be an optical module reading the actual sort of, in this case, water consumption reading. Or it could be a pulse log input, measuring a read switch and pulses as the water meters run-up. So this is sort of an older approach but it does allow you to extend the life of an existing asset. And there are some complications around that. Of course, you’ve got to have some mechanical mountings of that module on your existing legacy meter, and you also have to have a look at what the lifetime of your legacy meters is. Whether that’s still applicable to do sort of a midlife upgrade on old meters.
So the other approach is using the new smart meters or integrated digital meters. Now, these meters I’ve just taken off one of our local utilities here in Australia called Unity Water. And so this is just for illustration purposes. But there are a number of off-the-shelf integrated digital meters, in this case, what a meter.
And what does that mean? An integrated meter here includes integrated sensors. So typically, the newer water meters are using ultrasonics and in some cases, there are additional sensor inputs as well. So asides from sort of pressure, temperature, things like that, there may be some additional electronics in there to look at, sort of water leakage and other use cases similar to that.
So we’ve seen a move in water meters. We started a project so with the local water utility about five years ago, and that was probably one of the very first NB-IoT Integrated Digital Water Metering. It started as a trial on NB-IoT and it has obviously progressed into production. We’re seeing a move in the gas metering space as well. So that’s an interesting area and lends itself similarly to water meters. So in the case of water meters, these meters are dug and embedded into a manhole or underground, and there’s no power, so they have to utilize onboard battery storage. And usually looking at a 10, 11,12 year, battery life out of such a meter, it’s very expensive to go and do field visits and replace batteries or recharge batteries. So a similar situation exists with gas metering. So the gas metering also lends itself to using the same sort of approach. Now electricity metering is sort of a little bit more of a difficult use case mainly because there’s a huge legacy installed base of AMR, AMI type, electricity metering using even the older GPRS and even 3G communications modules. The electricity metering doesn’t have such a big issue around powers, it’s obviously deriving the power of the utility. But yeah, there are a number of interesting examples for electricity metering moving into some of the new IoT-based protocols and applications. So we can go through some of that.
So when we’re looking at the insides of such a meter, this is done for illustration purposes. So typically, the vendor, the metering vendor designing, developing such a meter will follow sort of two main approaches. One approach is used in this case, we’re talking about narrowband IoT. So they would use a cellular module, and that cellular module, of course, in some cases, have support for a dual-mode. So NB-IoT, CAT M1, but in the case of NB-IoT with such module, they’ll have an embedded micro built into the module. And the modules you’re seeing already include a lightweight M2M protocol stack in the actual module itself. And the programmers, the developer of such a meter, in that case, will have to make use of 80 commands to configure the lightweight M2M protocol to set it up, configure it, set up security credentials, and so forth, especially for the bootstrapping.
And the identity of the module and so forth. So, the ST command is faces used. So there are pros and cons to doing it using AT commands directly with the module. The other approach is when you have a circuit board designed for such an integrated meter or [inaudible 08:10] module, you may use the cellular module as a communications interface and have your own embedded micro. It may be a very low-power embedded micro, that essentially controls the communications module. So whether the communications module is powered or not powered. And in ultra low power, long life battery applications, such as a water meter/gas meter, you want optimal use of energy, so you’d want to have that communications module off for the time it does not need to be communicating. So the embedded micro on the baseboard in this case, maybe do very low power monitoring of pulses and readings. And it would maybe be building up a little bit of a sort of RAM storage of the readings over a period of time in very, very low power conditions. And then, perhaps once a day or once a certain period of time, the embedded micro will wake up the communications module and actually upload the metering data. So the second approach was there, is to develop and integrate your own lightweight M2M clients within the embedded micro on the baseboard. So these are two sorts of main approaches now.
I’ve jumped straight into lightweight M2M as a protocol. This is sort of the de facto IoT lightweights protocol and implementation for IoT EDGE devices, especially for these IoT devices constrained in low power, very low footprint, a very little bit of RAM, a very little bit of flash, so you really catering for those high volume, low resource embedded devices. Now, lightweight M2M is ideally suited to these applications. It is a standard that has been around since version 1.0 in February 2017. So it’s more than four and a half years already. It’s already evolved to version 1.1 and version 1.2. So there are a lot of thoughts and a fairly large ecosystem of vendors and interested parties been involved in the standard. So yeah, it’s been evolved and grown over the last many years. So essentially, we’re catering for multiple protocol stacks for lightweight M2M, so at the heart of it, at the very lowest implementation, including security would be something like UDP-DTLS for security, and, of course, CoAP, lightweight M2M. So those layers would be sort of the very lowest level implementation in an EDGE device. And so right up to version 1.2 of the standard, there is an inclusion of a bunch of other protocol stacks such as TLS-TCP, even bindings for LoRaWAN, and even we talk about cellular IoT, but in this particular case, on the extreme, right, cellular it refers to non IP on the cellular network, and we can cover that in a minute. So lightweight M2m in its current version allows for a lot of flexibility, right up to including OSCORE application-level security. So this is very mature, and it is a protocol that is well established today. Almost every single cellular module that you can get today for NB-IoT CAT- M1 most likely will have a [inaudible 12:18] in it. So the heart of this protocol is around security and allowing you to bootstrap the device and register the device securely on the network and with the management system, and the ability for you to add additional sensor data, objects, and resources. So there’s a bunch of sort of standard ones, and that ability to expand that, and I’m going to going to cover that on the next slide, but it is very versatile in its use in these types of applications.
The lightweight interim protocol standard, as I said, allows for the ability to add custom objects. And what does that mean? So that means the OMA object lightweight M2M registry, object, and resource registry defines a whole range of mandatory, optional, third-party, and custom objects. And also the definition of private resources as well. So using this standard you could leverage what has already been defined. And even including, there are many, many third parties that have already defined a whole bunch of standard objects. And those are reusable. So they’re available on this registry and you could just download the XML configuration for it and use that in your embedded device add-on. Most device management platforms today allow for the importation of such an object. So one of the additional objects in there is IPSO. It’s a smart object, and it’s defined by the IPSO working group, and that allows for a whole series of sensor-based objects. So defining it could be pressure, temperature, humidity, whatever the particular parameters are, I think including there are even metering objects defined as well. So we’ll cover that.
Now, this is an example of one of the water meter objects. It’s one of the standard objects defined. So on the left is sort of the object definition. And all these objects get defined as an object ID. So in this case is 3424, object ID. And in that object ID, we have a bunch of resources that are allocated for this particular object. So you can see cumulated water volume, there might be pulse ratios, minimum-maximum flow rates, and a whole bunch of others. Now, they’re not, you can see only one of them is mandatory in the case of this object, and these resource cases, but there’s a whole bunch of optional ones. So there’s a definition of an ID number, the actual sort of parameter name, so like pulse ratio, and whether they’re read-only, write-only, or executable, and like you’ll see this number five, it’s accumulated pulse value reset. So you can actually go and reset that value, so it’s an executable parameter. So the incidences where you can instantiate multiple of those or not. So it’s a single, mandatory, optional, what type of resource it is – float, integer, string, and so forth. It’s units and the description, so a bit of a textual description of how to use that particular parameter. So this is all well laid out, well standardized, and also you have the ability to create your own custom objects.
The next sort of step in this evolution is making use of a SIMS for NB-IoT Cat-M1. You’re obviously familiar with all the old plastic SIMS, and you’ve heard of embedded SiIMS. So the pros and cons, and in these types of water meet applications with long field life of 10-12 years, you ideally want to be using the embedded SIM for a whole bunch of obvious reasons. So obviously, it’s soldered down, it has much higher reliability in terms of the components. Its MTBF is much higher than using plastic SIMS, extend extended temperatures, and so forth. So the ability to manufacture an embedded SIM in the product at the manufacturer and they could be shipping that in volume anywhere around the world. So that embedded SIM then has sort of features and capabilities around being able to be provisioned remotely. So over there, Ameda may arrive in a destination country, it is provisioned, it is switched on, and the embedded SIM communication will be established initially, and be set for the target territory for a target carrier, so the mobile operator in your particular territory. So there’s a lot of advantages to that, in that you don’t have to go into the field and replace plastic SIMS and have to activate plastic SIMS and replace plastics and so forth, So there’s a huge number of advantages to using that. Of course, there are a lot of additional advantages like doing firmware over the air updates. And yes, you can do that with plastic SIMS. But with embedded SIMS, you have much better efficient control of that FOTA firmware over the air delivery to your target device by means of this SIM management system, as well as you know, this additional value-added use cases as well, such as location-based services and other networks near the device management type application. So linking that SIM device parameters and credentials together with your device management system.
From a cellular network point of view, I’m not going into great detail about the actual cellular network here. I think your target territory is potentially supported for NB-IoT or not, or CAD-M1. Generally, NB-IoT does seem to be pretty pervasive globally, presently. So obviously, you’d want cellular coverage if you’re deploying the smart meters in your target territory. Of course, there’s a different discussion if there’s no cellular coverage, there are other options but we’re catering for in the cases of cellular coverage, and in particular narrowband IoT support. And that’s couple because when you’re using certain of the narrowband IoT modules, they’re very low priced and optimized for narrowband IoT and being able to use that in a high volume product, an application like a meter. But there are other options available as well. So alternatively, another module, a variant of that, or dual-mode module might be to use CAT-M1 one but obviously, you may have some battery lifetime limitations using that. So you may design your meter with a higher battery capacity. That does push up the cost a little bit but there are trade-offs for that. So that’s one of the options. And I sort of use narrowband IoT CAT-M1 interchangeably. They’re both LTE 4G, sort of add-on standards, and the GSMA and the 3GPP standard have also included those NB-IoT CAT-M1 standards into the new 5GNR standard. So it’s future-proofed and you have the ability to grow with the new 5g networks as they grow as well. One of the things you want to do is obviously look at the abated SIM that you’d be using in your meter search, not just the soldered down SIM from the meter vendor manufacturer, but also looking at the ability for that embedded SIM to bere-factored or re-targeted to your region, and your particular communications partner. Or you may use one of the embedded SIMS that have roaming mobile network coverage. So there’s a couple of operators offering those sort of roaming agreements as well.
Now, you may also want to be looking at the sort of combination and integration of embedded SIM management, and the actual physical device management, which covers a whole lot more outside of the embedded SIM including all the device parameters and overhead parameters, and all those sorts of use cases, including firmware updates, and so forth. So there’s a lot of benefits in having an integrated SIM management device management platform.
Now, when we start looking at a Meter Device Management application, one of them is an application that looks like this. So generally, there’s an IoT device management engine. This is the middle part that handles the interface to the southbound side. So basically, through the access networks, and managing multiple protocols. So this one IoT device management platform particularly supports a whole bunch of different protocols. And you’ll see the word mentioned MQTT and some of the older protocols like TR-069, but they’re horses for courses, certain protocols are used for certain applications in the metering environment, lightweight M2M is sort of an ideal fit for the metering applications. If your utility, water metering, gas metering, electricity metering, and you have other more complex applications, you may have an RTU or a gateway and sort of a substation, lightweight M2M is still a good protocol to use in those cases. But potentially, you could be using USP; USP there is an evolution to support IoT protocols. And USP allows for a lot more complex integration with higher-end gateways. So managing container applications, EDGE devices, microservices, and Fog Computing and EDGE Gateway devices. So there are quite a few advantages in using such a protocol as well. But in your device management platform, you want the ability to manage in high scale, high volume, high availability, geo-redundancy, working across multiple networks, using an ability to support multiple protocols. Of course, with device management typically, there’s some management application. So there’s a management portal, a technician portal, a provisioning system, and applications like monitoring and analytics. So these are sort of add-on applications and typically an application enablement platform. And we’ll cover that in a little bit of a quick part of the demo. So once you’ve connected your devices to the device manager platform and you’ve established the bootstrapping and the registration, and you’ve established the data orchestration. So in other words, you have a device management system that knows what devices and what parameters in that device it is interested in, to collect in, sort of, let’s say real-time or in the case of water metering or gas metering, it may be the particular parameter values that picks up over a period of time but uploaded perhaps once a day, so. So in those cases, you also may want to stream that data into upstream applications, such as a cloud data lake you know, perhaps integrating into upstream AI, ML type cloud services, maybe some analytics applications. It doesn’t necessarily have to be cloud, it could be various other applications.
So there are various integration options going from sort of device management into the upstream applications. And connectivity management to medicine management could be a software as a service, such as a chart here, or it could be part and parcel of the device management application. Now as far as device management, you’re managing the device, configuring the device, updating firmware, and so forth, doing essentially setting up the data orchestration. But now, what do you do with this data?
So in a device management system, that data orchestration allows you some rule sets and workflow to configure that data orchestration, like the devices and what parameters but now where to send it? So there’s a couple of options. So there is an API approach and typically, a sort of Cloud Connector approach. And the two can be used in parallel or individually. And so the REST API speaks for itself. So any external application could make use of a REST API and collect data from the platform, including things like API patterns, subscriptions, so being able to register for autonomous data ingestion from a device management platform like this one. So the other approach is cloud connectors. And so for example, AMQPS is a cloud connector you would use when integrating to Microsoft as your IoT. And so there’s a bunch of nice integration options there as your IoT Hub and as your IoT central, I’ll give you a quick sort of highlight demo on that. And you may want to use something like Kafka with Amazon, and we’ve got like Pub-Sub with Google Cloud. So there are a few different cloud connector options to each pair you to the different cloud environments. We talk here about SCEF-T8. SCEF is a radio network access integration interface and typically, Ericsson, Oracle communications have these SCEF platforms for operators, usually in the newer 5g networks. So that allows the T8-API allows us to onboard non-IP cellular IoT devices. So an EDGE device with no IP stack. So obviously there’s a good reason for that. And in the case of that device, were able to via the SCEF T8, API, onboard such devices and collect data and even control the outputs on such devices as well.
Thank you, everyone.
— end transcript —
If you’d like to view the demo portion of the recorded webinar – or to get your own custom demo – please reach out to our team and we’ll be happy to help.
