METRO POWERMetro Power Academy lessonPlan a project ↗

Electric Metering & AMILesson 4 of 6FOUNDATION LESSON

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.

READING TIME
14 minutes
OBJECTIVES
3 learning objectives
SELF-CHECK
3 check questions
INTENDED FOR
Utility leaders, metering, ICT, operations, procurement and informed consumers

Educational lesson. Confirm project-specific requirements before application.

Round ANSI-socket smart electricity meter
Product imageNA67 Series ANSI round smart meter

01LEARNING OBJECTIVES

After this lesson, you should be able to:

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

02EXPLANATION

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.

  1. 01

    Control requirement

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

    Authority
  2. 02

    Map requirement

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

    Traceability
  3. 03

    Attach evidence

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

    Model fit
  4. 04

    Close gaps

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

    Decision status
READING NOTEA generic company profile or family brochure is contextual evidence, not proof of every exact configuration.
TECHNICAL VISUAL · SYSTEM-SPECIFIC MODEL

Requirement-to-evidence trace

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

04OPTIONAL ENGINEERING DEPTHEngineering reasoning for this learning pathThe same design relationship, checks and evidence apply across every lesson in this path.
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 PATH
  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 aging and closure register

05WORKED EXAMPLE

Remote disconnect is listed in a brochure

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

STEP BY STEP
  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.

06COMMON FAILURE OR MISCONCEPTION

“If a product family supports a feature, every model in that family complies.”

CORRECTION

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.

08SOURCE NOTES

Sources for further study.

International references support further study. They do not replace Philippine laws, regulations, utility requirements or project specifications.

  1. 01Advanced Metering in Smart Distribution GridsNational Institute of Standards and Technology

    Metering accuracy, upgradeability and smart-grid measurement context.

    Open source ↗
  2. 02Advanced Metering Infrastructure Security ConsiderationsUS Department of Energy

    Planning, procurement, rollout and assessment of AMI security.

    Open source ↗
Read the complete technical paper

NEXT IN THIS COURSELesson 5 of 613 minutes

Operating AMI and deciding when to scale