Smart Energy Cloud? Sounds like fun.
Having just returned from our annual D&D tournament, this year in Las Vegas, I have role-playing on the mind, so when I read the title of Elizabeth White’s blog IBM and Cable & Wireless to Develop UK Smart Energy Cloud, I immediately thought of the AD&D Druid spell Call Lightning which gathers clouds and then emits lightning every ten minutes until it runs out. Which is kind of in line with what her blog is talking about – two companies with a history in smart energy grids getting together to make it a reality.
Most striking to me is the following quote from the article:
The challenge is for smart meters to reach the entire UK population and this will require a combination of enabling solutions, such as GPRS, radio and Power Line Carrier to make sure it's cost effective. However, it is the network connecting it all and intelligent data management, that is central to the smart agenda's success.
Yes indeed, that’s one of the challenges. For regular readers you will note that I’ve talked about how complex this gets and how fast. We had everything – power line carrier, telephone, RIM, local wireless, and cell phone towers being used to get data back to our DC when I was running just such a project. It was a lot of work both in IT and in the field with engineering, and we had some great guys on the engineering side to keep things coming, and my staff was busy pretty much non-stop keeping up with the IT end of the problem.
But the private cloud and entire country bits add some interesting twists to the problem domain. Like the volume of data that is transferred and the bandwidth required to handle that much data. An individual meter read is not a huge chunk of data, and read once a day does not, even with header information, amount to a substantial amount of data. For most uses a single daily read fits inside an IP packet, which is not much bother on a decent sized WAN. The problem comes up when there are hundreds of thousands (or in the UK’s case no doubt millions) of meters and many of them need 15 minute or even five minute interval reads, or there are meters that can gauge power being put back onto the grid from local sources that needs to be compared to usage figures. It rapidly becomes not only complex data-wise, which no doubt they’re hoping having it all in one major cloud would resolve, but also network bandwidth wise.
This would be one heck of a project to work on. There is a little of everything in meter reading, and I really enjoyed the technology part of that job. You have infosec – is the data protected? You have database – Is the data in a common format (much of our internal application development was on this topic), you have communications issues – is the communications method being used for a given meter adequate for the requirements of not just that meter but the entire collection of meters that use the medium, and can you set reading schedules to maximize bandwidth usage over the course of a day? There is analytics, can you drag patterns out of the data that will help your generation units better provide for the needs of the customer base, which sounds like a lot of the focus of this project. There is systems admin because the article lists three communications mechanisms, which means at least three systems to read meters. We had many, all required to meet our goal of 100% coverage because truly rural places or “end of the line” customers often could not be well serviced by power line carrier solutions, which were our first choice. They’re going to add “build a cloud” and “manage a massive network” to an already massively complex undertaking. If you’re a geek in the UK, see if they’re looking for help, you’ll have a blast and learn a lot.
Having been through most of this, I’m focused on learning about the cloud bit. Moving that much data around in a timely manner is difficult, and we certainly had a fair number of translation programs to get the data into a unified format that could be utilized for billing, analysis, and troubleshooting. But using private cloud might relieve much of the overhead of applications by allowing more translations to occur in real time, and utilizing IBM might give a leg up on standardizing the smart meter communications themselves (even “standardized” isn’t “interoperable”, just like every other IT field), so then the networking aspect becomes the bottleneck. Can you switch enough servers over to task X to accomplish the job, do you have acceleration in place to get the data transmitted down to the smallest number of bytes possible, is the security as secure as possible or “good enough”, and once you start talking security, is there an upgrade path for that security? Seriously, most of the functionality of a meter never needs to be updated. It’s reading usage. But the tools used when securing those connections is guaranteed to become outdated over time, so what’s the upgrade path, and is security in the network (ala our BIG-IP WAN Optimization Module (WOM) which wouldn’t work for this solution because it needs symmetric deployment, but is an example of offloading security to a place that can be easily updated, or is security hard bundled into the smart-meter, touching every piece of it. My guess is the latter, just so that the reads can be stored encrypted locally and the meter can be tamper-proofed. Both worthy reasons, but that means instead of upgrading one tiny bit when security becomes dated, you’ll have to upgrade an array of systems on the meter.
It would be cool too to see how the private cloud is locked down, because one big pool of any kind of data becomes a target of curious or malicious hackers just because it is a lot of information collected at one point. Point-to-point security within the cloud is probably going to be a requirement, even if the perimeter is well locked down, so that’s a huge overhead that would be interesting to see how they’re implementing and what the cost in terms of on-server encryption versus offload devices is.
Apparently you can take the geek out of IT, but you can’t take IT out of the geek. I’d love to see the design and analysis of this monster – from the cloud to the meter – and see how far we’ve come since I was running a project like this. I’ll bet there are a lot of similarities and a lot of differences.
You might want to follow along too – there are a lot of uses for private cloud, but if this goes forward, IBM and Cable & Wireless are going to have experience in highly redundant, highly efficient private cloud implementations. Any word on how or what they’re doing might be an indicator of what you can expect moving forward in the growing world of private cloud, which is driven by the desire for more IT efficiency, these people will be proving or disproving that reasoning over the next several years.
Like the AD&D Druid spell though, this is going to take time, longer than we’d like. Sometimes we in IT forget the massive investment of time and resources that this level of project requires, so be patient if you want to watch them, the clouds have to be summoned and the energy built up.