METRO POWERMetro Power Academy lessonAll Academy pathways ↗

Electric Metering & AMI · Lesson 4 of 5

Qualifying meters, communications and software against the TOR

AMI product selection is controlled by the approved requirement and architecture, not by a list of attractive features. A meter family may support remote disconnect, load profile or RF mesh, while the exact offered form, current class, firmware, communication module or certification scope remains different. Qualification must follow the exact model and revision being offered.

14minutes3learning objectives3check questions
LEARNING OBJECTIVES

After this lesson, you should be able to:

  1. Distinguish product-family claims from exact configuration evidence
  2. Classify requirements as compliant, deviating or unverified
  3. Explain why interoperability must be demonstrated at the required interfaces
EXPLANATION

What is physically and operationally happening?

AMI product selection is controlled by the approved requirement and architecture, not by a list of attractive features. A meter family may support remote disconnect, load profile or RF mesh, while the exact offered form, current class, firmware, communication module or certification scope remains different. Qualification must follow the exact model and revision being offered.

The responsible review classifies each requirement. Compliant means current evidence matches the requirement. Deviating means the offer is known to differ and requires an authorized disposition. Unverified means the available evidence is insufficient. Unverified is not the same as compliant, and a verbal assurance is not a substitute for model-specific confirmation.

01

Control requirement

Identify the latest approved TOR, addenda, drawings and architecture decisions.

Authority
02

Map requirement

Translate each clause into a measurable product, interface or operating obligation.

Traceability
03

Attach evidence

Link exact datasheet, certificate, test, firmware or demonstration evidence.

Model fit
04

Dispose gaps

Resolve deviation, clarification and principal-confirmation items before commitment.

Decision status
TECHNICAL VISUAL · SYSTEM-SPECIFIC MODEL

Requirement-to-evidence trace

Every offered capability should terminate in current, exact and reviewable evidence.

READING NOTEA generic company profile or family brochure is contextual evidence, not proof of every exact configuration.
OPTIONAL ENGINEERING DEPTHTOR & product qualificationEvaluate exact configurations, deviations, certificates, firmware and integration evidence.
DESIGN RELATIONSHIPEnd-to-end success = field exchange × transport × platform processing × downstream acceptance
  • Define the eligible population and time window
  • Measure the result at the utility-use boundary
  • Preserve identity, timestamp, status and acknowledgement
ENGINEERING CHECKS FOR THIS LESSON
  1. 01Trace a reading and a return command across every interface
  2. 02Segment results by topology, terrain and service type
  3. 03Freeze KPI denominators, exclusions and acceptance gates
FAILURE ANALYSIS
Observed signalPossible causeDiscriminating test

HES read exists but billing data is missing

Mapping, validation or export failure

Trace one interval and its acknowledgements

Aggregate KPI is strong but exceptions cluster

Topology or service-condition bias

Segment performance and compare cohorts

PROJECT EVIDENCE TO COLLECT
  • Time-aligned HES and MDMS extracts
  • Device-to-service identity map
  • Exception ageing and closure register
WORKED EXAMPLE

Remote disconnect is listed in a brochure

The TOR requires remote disconnect with command acknowledgement and role-based authorization.

  1. Mark the functional requirement as unverified
  2. Request exact model and firmware support statement
  3. Demonstrate authorization, command, device response and exception status
  4. Record evidence and any limits in the compliance matrix
INTERPRETATION

The feature should not be declared compliant until the exact end-to-end behavior is supported by evidence.

COMMON FAILURE OR MISCONCEPTION
“If a product family supports a feature, every model in that family complies.”

Capability can vary by form, hardware option, communication module, firmware, license and system integration. Exact configuration evidence controls.

RETRIEVAL PRACTICE · 3 QUESTIONS

Check what you can explain without looking back.

Choose an answer and report your confidence. The confidence signal is stored only until you submit this page.

OBJECTIVE · Classify evidence

A family brochure lists RF mesh, but the offered model is not identified. What is the status?

How confident are you?
OBJECTIVE · Evaluate interoperability

What best proves an interface requirement?

How confident are you?
OBJECTIVE · Control revisions

A TOR was amended after the first compliance review. What must happen?

How confident are you?
Answer every question and confidence prompt.