Smart Grid Event Detection: Adding Intelligence to AMI Meter Alerts

Today’s AMI meters advertise event detection capabilities, but this is a limited view of event detection. In this post, we explore what expanded AMI detection abilities look like.

AMI meters (smart meters) come with increasingly robust ability to provide alerts (also called alarms). These alerts are based on a variety of conditions such as tamper entry, temperature, battery, and more.

This event detection is a fantastic contribution by AMI technologies; but like many edge computing scenarios, there are limits. Those limits can devalue this important data asset as Utilities experience issues such as alert noise, defunct events, and the lack of business context.

As a prominent IoT use case, AMI technologies promised to bring about digital transformation of the utility sector. Trynzic’s view is that audacious transformation should be seen in the people and business processes of the organization. The change shouldn’t be subtle. What is needed in this scenario are the robust alert enrichment capabilities of solutions, like Trynzic for Utilities, that leverage the power of the serverless cloud.

If your organization finds themselves ignoring large numbers of meter-originated alerts, read on to see what intelligent event detection looks like.

Context Matters

The biggest limitation of meter-borne “events” is the lack of business context available to the Utility, but not available to the meter.

Complex determinations are difficult to make in isolation using limited data sources. Raw meter telemetry and meter alerts benefit when cross-referenced with a variety of data facets found across Utilities’ line of business (LOB) data sources. When LOB is brought into event determination, then we see logic that includes (but isn’t limited to):

• “Suppress event if the meter was installed more than 7 days prior”
• “Suppress event if a higher-severity condition has been detected” (e.g., a transformer issue or a declared outage)
• “Only declare this event if another set of detectable conditions are present”
• “Change the event type or severity if near to this meter’s billing date”
• “Suppress the event if it comes from an asset that is known to report said event under certain conditions (e.g. time of day, etc.)”
• “Only declare this event if it is within a list of specific assets”
• “Only declare this event if it is within a specific organizational or geographical area”

About That Noise

Question: when is an alert an “event”?

The answer varies, but an alert is not an event when it is discarded as noise by Utility personnel.

Often applying context solves the noise problem, but other detection engine features are helpful in certain situations.

Some of these features include rule parameters for recurrence thresholds, min/max chronological measures, asset properties such as meter form and voltage ratings, and configuration information such as meter program, to name a few.

Events Want to be Relevant

When working with device-originated events, nothing is more unproductive than investing human resources to an identified event within the grid that is found to be already resolved. It degrades trust in the AMI data and related software applications.

Too many utilities are operating on “fire and forget” detection software. As utilities move closer and closer to near real-time operations using AMI telemetry, fire-and-forget will no longer suffice. Trynzic’s Trynzic for Utilities has robust event detection capabilities, but importantly, Trynzic for Utiliites applies all inbound telemetry and data to all outstanding open events. This validates events’ continued relevance or automatically closes events that are no longer detectable.

Be Open to Change

When referring to ‘change’, we literally mean that it should be easy to tune (or change) your detection “rules”.

Event detection is the result of intelligently designed “rules” processed by a “rules engine”. Making changes to the distinct parameters within your rules should be easy to iterate, low-risk, and non-destructive.

Rapid iterations of the “try and assess” cycle is common to data analysis, but this is not well suited for distributed devices such as meters. It is unlikely that Utilities want to rapidly iterate changes to their meter settings.

It can be advantageous to have a sandbox environment to test ideas. This also should be inexpensive and easy to maintain.

Is the End Game the “Event”?

Short Answer: No.

The event is just an important first step towards the end game, which is empowered people participating in business processes enriched with the near real-time AMI data stream.

Trynzic for Utilities appends robust event detection capabilities (we call this SENSE) with two other important capabilities for people and processes:

TRIAGE: Situational awareness of events within a single pane of glass, enriched with current & historical meter and line of business data.

ACT: Business processes facilitated with Trynzic for Utilities’ case management, workflow engine, workflow designer, collaboration & cross-system orchestration features.

Conclusion – Completing Your Digital Transformation Begins with a Whole-of-Utility Approach to Event Detection Use Cases

An automatically detected “event” should always be relevant to the Utility’s business processes. Utility professionals know the limits brought on by long iteration cycles, alert noise, irrelevant events, and disconnected diagnostic and workflows tools.

If you are ready to complete the journey to digital transformation, seek partners who are taking advantage of serverless cloud technologies and addressing the full meter-to-outcome use cases with their SaaS product(s).

Want to see what robust business event detection looks like? Tell us more about your needs or request a demo of our IoT business platform, Trynzic for Utilities.