For those of you who have read the SSP blog posts since the early days of our organization, you know that the vast majority of our early projects have been focused around GIS and specifically Esri technology. More often than not, those early projects involved the same user groups within a Utility, such as GIS Technicians, Engineers, Field Crews and others.
Over recent years, the SSP “footprint” have expanded with the release of our Lifecycle Solutions (both Work and Assets) – which enable fully integrated Work and Asset Management capabilities across utilities. To-date, both of these solutions have also focused around the traditional areas of utility business that we’ve been involved in including capital work, operations and maintenance activities.
The term “Smart Grid” and related technologies such as Advanced Metering Infrastructure (AMI), Meter Data Management (MDM) are now relatively mature – and we’ve constructed integrations to these systems in the past and continue to do so. What’s changed more recently are the expectations of utilities in leveraging the investments made in these technologies. No longer is it simply enough to be able to provide better consumption information to customers, more rate options, and more operational data (such as up-to-date outage or voltage information).
Utilities (among other growing needs) are expecting to utilize data from these systems to support implementation of Advanced Distribution Management systems (ADMS), to in turn provide more automation and reliability in the management of their distribution networks. Not only that, information regarding “Distributed Energy Resources” (DERs) – Solar Panels, Battery Storage, Plug-in Hybrid/Electric Vehicle chargers, “Micro-Grids” and other facilities ‘beyond the meter’ is becoming more important to utilities as the penetration of these systems impacts the behavior of a network, and utilities also seek new working relationships with their customers as a result.
I’ll cover the wide range of assets, systems, processes and people that are impacted by these growing expectations in upcoming articles – but for today, I wanted to focus this article on the ‘hub’ of a lot of this activity, the AMI meter itself, and how SSP technologies can support the management, performance monitoring and testing of AMI meters and their supporting technologies.
Are my AMI meters “Assets?”
For a lot of utilities, the information about a meter for the bulk of their population was limited to it’s ID, which sat in a CIS associated with an account, and when it was time for the meter to be read (a customer’s “Bill Cycle”). That information was downloaded to a handheld, the meter reader took it out and read your meter, uploaded the data and that was that. In the AMI world – that process hasn’t changed substantially – the CIS tells the MDM it needs a read (a ‘billing determinant’) which it generates from the data it’s receiving from the meter constantly.
What has changed is the expectation around the process with which meters are treated when they fail. In the past, specifically for residential meters, because we only used a single read from a dial to generate a bill which was only read once a month, we didn’t even know a meter was out until it was attempted to be read. We had some time to deal with it, and expectations around its performance were low. Now, with Time of Use (TOU) and other rate structures based on ‘demand’ (the peak usage from a customer) being utilized for more customers, we rely on the meter to get information about our system (pinging a meter to see if it has power, listening to events from the meter), and we *do* care more about them.
For a lot of utilities, the “System of Record” for a meter is the CIS, but for information beyond the Meter ID and where it is (address/premise) – the data could be in an access database, a spreadsheet, a piece of paper, or in the ether. Even when the meter is tracked in CIS, it’s often not truly represented as an “Asset” in the sense that it has history – it’s more often stored as a record associated with a Customer account or premise – or even simply a few attributes, so when a meter ‘moves’, the history is lost.
Traditional asset management systems are often focused on larger assets and/or those critical in operation which require regular inspection and/or can be depreciated for tax purposes. The procurement of AMI meters – which typically involves sample testing unique to meters – is also a process which is not managed in traditional systems.
SSP Lifecycle is an SSP Innovations’ Work and Asset Management system which we have implemented at a number of utilities and integrates with Esri. It’s based on a flexible, web-based architecture, and designed to be extremely configurable by utilities themselves, to enable support for constantly changing processes and work/asset needs. Customer are currently using Lifecycle to manage transformers for example, and we’re in the process of enabling “Meter support” to provide procurement of meter shipments, generate sample tests, and track the life a meter.
SSP Lifecycle fills the gap between having meter asset detail loaded into a ‘heavy’ asset management system (expensive to configure and maintain) – and having that data spread across your CIS, spreadsheets and custom access databases. Whether you have an existing Work Management system that manages meter-related service orders, or a paper-based process that uses CIS to generate exchange orders – Lifecycle can be integrated in various ways to existing processes or support the management of work orders itself – whatever is most cost-effective and efficient for your organization.
How are my AMI meters performing?
For most of the equipment on electric distribution system, the pattern of their life is fairly simple. They are installed, they operate, they may get inspected (and/or replaced, repaired, or fail). However, in the case of AMI meters, their behaviors can have somewhat more ‘variance.’ A meter may be recording consumption accurately, but failing to deliver those reads based on communication issues (either with the meter itself or the network). The meter can also let us know of certain behavior it’s experiencing through alarms – not simply “on” or “off” – but alarms related to voltage levels on certain phase, or memory issues for example, and even issues to do with transformer and/or the circuit it is part of.
SSP AMI Ops is a solution that takes the raw AMI delivered data – the same information used to feed the Meter Data Management system – and uses this data to provide a spatial and metric/report view of which meters are failing to deliver reads (both interval and register reads) to their expected level, typically defined by a Service Level Agreement (SLA) created with an AMI vendor.
SSP AMI Ops also determines ‘patterns’ in certain behavior indicative of non-meter activities such as similar voltage alarms occurring on meters connected to the same transformer, which could be indicative of a failing transformer, incorrect tap settings on the transformer, or other issues. These can be represented spatially and/or pushed out in the form of reports, or even sent to a mobile workforce system.
SSP AMI Ops provides a simple view of your data.
Am I ready for all this AMI data?
The volume of data generated by AMI data can be extremely large, and in many cases results in the Meter Data Management System having largest databases that a Utility has implemented. While MDM vendors can provide detailed specifications for their own systems, it’s challenging to simulate the exact ‘day in the life’ environment that a system will experience under full load, especially when you take into account all the various dependencies involved, such as underlying network and hardware (SAN/Hard Drives) platforms and conflicting needs.
Part of this is because the source data simply doesn’t exist – unlike GIS programs where we can migrate from old formats or files to validate a migration before go-live – in the AMI world we are moving from a world where meters were manually read once a month (perhaps 3-4 pieces of data per month), to an AMI world where a smart meter can deliver reads every 15 minutes for multiple ‘channels’ (delivered KWH, received KWH, voltage, etc.) , tamper detection, remote disconnect/reconnect status, outage and restorage notifications, load profiling and system load snapshots, voltage and power quality info, fault indications, etc., resulting in thousands of pieces of data which can overwhelm systems quickly.
When an AMI program begins, often the utility only has a handful or at most a few dozen meters at their disposal – often in a ‘meter lab’ or ‘meter shop’ to begin testing – unless they are undertaking a form of pilot or ‘initial deployment’ to gather more data. Even then, the volume of data is a fraction of that which will be generated when all meters are deployed. So how do we simulate all this data, and the types of behavior that an AMI and downstream system waiting for data will be exposed to?
SSP’s AMI Sim was developed to address this exact requirement. AMI Sim (think SIMulator) generates data like an AMI production system – it can be configured to deliver different interval read frequencies (i.e. meters recoding intervals every 15 minutes, hourly etc.) on different read schedules (i.e. read files sent every 15 minutes, 4 hourly, daily) and combinations of each, for a list of Meter IDs that can be generated by the utility or auto-generated, from a single meter up to millions of meters. Various ‘load profiles’ or ‘consumption patterns’ can be created to simulate customer types and behaviors, all with associated matching register reads. This means that all downstream systems can be tested (MDM, CIS, others) not only for scalability, but also function testing. Need meter data to test new billing rate configurations? No problem!
Not only it is designed to generate vast amounts of good data – AMI Sim is designed to validate what downstream systems do when reads are not delivered as expected? Gaps in data? Spikes? Outages across midnight? AMI Sim can simulate these events and many others to support your testing. AMI Sim provides not only the capability to validate all of your AMI related technologies capabilities around performance and scalability – it’s an engine to simulate the behavior of your overall ‘smart grid,’ and your customers connected to it.
If you’ve undergone, undergoing, or planning an AMI implementation – you’ll know that I’ve only touched the ‘tip of the iceberg’ when it comes to these programs and the growing technology needs facing utilities – and (this is the fun part) – the benefits that utilities can gain by leveraging new Esri technology (think utility network!) across various groups both within their enterprise, but also external customers. Stay tuned!