This part of IEC 61968 contains the clauses listed in the table below.
Document overview for IEC 61968 – 9
|
Clause |
Title |
Purpose |
|
1. |
Scope |
The scope and purpose of the document are described. |
|
2. |
Normative References |
Documents that contain provisions which, through reference in this text, constitute provisions of this International Standard. |
|
3. |
Reference and Information Models |
Description of general approach to metering system, reference model, use cases, interface reference model, meter reading and control functions and components, message type terms and static information model. |
|
4. |
Meter Reading and Control Message Types |
Message types related to the exchange of information for documents related to meter reading and control. |
|
Annex A |
Message Type Verbs |
Description of the Verbs that are used for the message types |
|
Annex B |
CIM Extensions |
CIM extensions needed for meter reading and control |
|
Annex C |
Recommended Use of ReadingTypeId |
Recommended formulation of the ReadingTypeId |
|
Annex D |
Recommended Procedure for Maintaining Relationships Between Objects |
To describe the use of the master resource identifier (mRID). |
System Interfaces For Distribution Management –
Part 9: Interface Standard for Meter Reading and Control
The IEC 61968 standard, taken as a whole, defines interfaces for the major elements of an interface architecture for Distribution Management Systems (DMS). Part 1: Interface Architecture and General Requirements, identifies and establishes requirements for standard interfaces based on an Interface Reference Model (IRM). Parts 3-10 of this standard define interfaces relevant to each of the major business functions described by the Interface Reference Model.
As used in IEC 61968, a DMS consists of various distributed application components for the utility to manage electrical distribution networks. These capabilities include monitoring and control of equipment for power delivery, management processes to ensure system reliability, voltage management, demand-side management, outage management, work management, automated mapping, meter reading, meter control and facilities management. This set of standards is limited to the definition of interfaces and is implementation independent. It provides for interoperability among different computer systems, platforms, and programming languages. Methods and technologies used to implement functionality conforming to these interfaces are considered outside of the scope of these standards; only the interface itself is specified in these standards.
This document is Part 9 of the IEC 61968 standard and specifies the information content of a set of message types that can be used to support many of the business functions related to Meter Reading and Control. Typical uses of the message types include meter reading, meter control, meter events, customer data synchronization and customer switching. Although intended primarily for electrical distribution networks, IEC 61968-9 can be used for other metering applications, including non-electrical metered quantities necessary to support gas and water networks.
The purpose of this document is to define a standard for the integration of Metering Systems (MS), which includes traditional manual systems, and (one or two-way) Automated Meter Reading (AMR) Systems, with other systems and business functions within the scope of IEC 61968. The scope of this standard is the exchange of information between a Metering System and other systems within the utility enterprise. The specific details of communication protocols those systems employ are outside the scope of this standard. Instead, this standard will recognize and model the general capabilities that can be potentially provided by advanced and/or legacy meter infrastructures, including two-way communication capabilities such as load control, dynamic pricing, outage detection, distributed energy resource (DER) control signals and on-request read. In this way, this standard will not be impacted by the specification, development and/or deployment of next generation meter infrastructures either through the use of standards or proprietary means.
The capabilities and information provided by a meter reading system are important for a variety of purposes, including (but not limited to) interval data, time-based demand data, time-based energy data (usage and production), outage management, service interruption, service restoration, quality of service monitoring, distribution network analysis, distribution planning, demand reduction, customer billing and work management. This standard also extends the CIM (Common Information Model) to support the exchange of meter data.
The following normative documents contain provisions, which through reference in this text, constitute provisions of this International Standard. For dated references, only the editions cited apply. For undated references, the latest edition of the referenced document (including any amendments) applies. Members of IEC and ISO maintain registers of currently valid International Standards.
IEC 60050-300, International Electrotechnical Vocabulary (IEV) - Electrical and electronic measurements and measuring instruments - Part 311: General terms relating to measurements - Part 312: General terms relating to electrical measurements - Part 313: Types of electrical measuring instruments - Part 314: Specific terms according to the type of instrument
IEC 61970-301 Energy Management System Application Program Interfaces – Part 301 Common Information Model Core. November 2003.
IEC 61968-1 System Interfaces for Distribution Management – Interface Architecture and General Requirements
IEC 61968-2 Glossary
IEC 62051:1999, Electricity metering - Glossary of terms
All UML-based sequence diagrams contained herein are to be considered as informative examples of how a message exchange could occur.
Note: One of the strengths of the CIM is its flexibility. As technology advances, and new needs develop, new messages can be created. These new messages might involve additional systems (not pictured.) These new messages may leverage different options than the ones depicted in the example.
All UML-based communication diagrams and message flow diagrams contained herein are to be considered informative.
All UML-based class diagrams contained herein are to be considered informative. The reader is referred to part 1 to locate the document that contains the normative definitions of the classes used in the CIM.
Message format diagrams contained in the body of this document are to be considered normative. Message format diagrams contained in the annexes of this document are to be considered informative. Message format diagrams can be construed to represent an XML schema.
These messages were derived from usecases which satisfy an underlying business need. The usecase provides a given context for the use of the CIM. Message format diagrams describe the elements which are passed. The elements depicted in dashed-line boxes are to be considered optional in a given context. The elements depicted in solid boxes are to be considered mandatory in a given context. If a diagram should depict an entire class as mandatory or optional, the reader should interpret this to mean that the use of the class is either mandatory or optional, but not that every element within the class is now mandatory or optional. The reader must refer to the normative definition of the class to determine this.
For the purposes of this standard, the terms and definitions given in IEC 60050-300, IEC 61968-2, IEC 62051, IEC 62055-31 and the following terms apply.
Where there is a difference between the definitions in this standard and those contained in other referenced IEC standards, then those defined in part 2 shall take precedence over the others listed, and those defined in part 9 shall take precedence over those defined in part 2.
3.1.2
customer program
a classification scheme for the sale of energy to consumers according to a particular tariff. The program may specify the purpose, conditions on the time of use, the service voltage(s), the volumes consumed, and/or other terms as a condition of the sale.
Note: Utilities may promote particular programs to their industrial, commercial, agricultural, and residential customers in an effort to encourage a particular behaviour, or to make them aware of their options
3.1.3
end device
Equipment located at the end of the communication system, usually on the customer premises, which may perform functions such as metrology, connect/disconnect, load control, demand response, or other functions, and may have power relay and/or communications capability.
3.1.4
load control device
type of End Device which can receive signals causing it to shed load for the purposes of maintaining network reliability and/or commercial agreements.
3.1.5
meter
type of End Device which performs metrology and supports the tariffing of the distribution and/or transmission network.
Note: A meter could be defined as a 61850 device with logical nodes.
3.1.6
meter changeout
the process of replacing an existing meter with a new meter.
Note: The installer will customarily follow a work order which specifies a given location, and usually requires that he or she capture readings from the old and new meters, and record the time and day in which the work was performed.
3.1.7
payment meter
electricity meter with additional functionality that can be operated and controlled to allow the flow of energy according to agreed payment modes.
3.1.8
prepayment mode
payment mode in which automatic interruption occurs when available credit is exhausted.
|
AM |
Asset Management |
|
AMR |
Automated Meter Reading |
|
AMI |
Advanced Metering Infrastructure |
|
CIM |
Common Information Model |
|
CIS
COSEM
DLMS UA |
Customer Information System
Companion Specification for Energy Metering
Device Language Message Specification User Association |
|
DMS |
Distribution Management System |
|
IDR
IEC |
Interval Data Recorder
International Electrotechnical Commission |
|
LC |
Load Control |
|
LMS |
Load Management System |
|
MAM |
Meter Asset Management |
|
MDM |
Meter Data Management |
|
MM |
Meter Maintenance |
|
MR
MS |
Meter Reading
Metering System |
|
NO |
Network Operations |
|
OMS |
Outage Management System |
|
POS |
Point Of Sale |
|
RF |
Radio Frequency |
|
VEE |
Validating, Editing, and Estimating |
|
WM |
Work Management |
4 Reference and Information Models
The spinning disk in an electromechanical meter generally serves as a pulse initiator to the meter recorder module. In a similar fashion, solid-state meters may also employ a metrology unit that generates pulses which represent a fraction of a kWh, and if more sophisticated, the solid-state meter may have a meter recorder which is able to accumulate many different kinds of information and store it for presentation to the meter communications module using a message and table-driven protocol such as ANSI C12.19 or IEC 62056.
The most common metered data element is kWh, but many electricity meters can also capture kW, kVAr, kVArh, kVAr, and other similar billing quantities. Some meters can also capture pure engineering quantities such as voltage, current, power factor, etc.
Some AMR systems attempt to add value to low-end meters by adding functionality that the meter may lack. For low-end meters (e.g., energy only) it is common for an AMR meter module to add the capability to perform demand metering, Interval Data Recording (IDR), maintain an energisation count, or even provide estimates of certain engineering quantities such as voltage.
Commercial and Industrial meters often employ current transformers and voltage transformers to meter the actual service. Primary voltages and currents are scaled down using potential transformers (PTs) and current transformers (CTs) so that the meter does not have to be constructed to withstand the high voltages and currents actually delivered to the load. Secondary voltage or current values are those that are often measured directly by the meter. Secondary values are small percentage of the primary values that may actually delivered to or connected to the load. If secondary voltages and currents are measured by the meter, these can be converted back to primary values using the PT and CT ratios, which are just the ratio of primary to secondary values.
The metering system will convey meter data and other value-added data through the metering system network to the destination. Depending on the system, the journey may involve multiple steps through public or private networks, licensed or unlicensed RF spectrums, standardized or proprietary systems, in a one-way or two-way fashion.
Some general operations or services can be defined for a metering system. These general operations will translate to specific actions in the context of a given metering solution.
General operations can be scheduled or called on-demand. Each operation returns an answer with a status. A message encapsulates a General operation.
Examples of Meter General Operations (reading) are:
· Reading Phone Calls
· Reading Load Curve
· Reading Encryption Keys
· Reading Equipment Configuration
· Reading Contract Parameters
· Reading Functional Maintenance Data
· Reading Technical Maintenance Data
· Metrological Reading
· Reading Status Parameters
· Reading Quality
· Reading Date-time
· Meter Reading
· Reading Historical Data
· Reading programming Data
Examples of Meter General Operations (writing) are:
· Writing Client Parameters
· Writing Season Parameters
· Writing Date-Time Changing Seasons
· Writing Encryption Keys
· Writing First Time In-service
· Writing Calling Parameters
· Writing Public Holiday Schedule
· Writing Self-read Parameters
· Writing Status parameters
· Writing Programming parameters (pricing)
· Writing Defect Parameters
· Writing Minimal Defect Threshold Period
· Writing Nominal Voltage Level
Readers of Part 9 interested in standards concerning Meter Reading should refer to IEC 62056, DLMS UA (Device Language Message Specification User Association) and the COSEM model: COmpanion Specification for Energy Metering. COSEM specifies 3 steps:
a) The meter model and data identification.
b) The mapping of the model into protocol data units.
c) The transportation of the bits.
The following diagrams serve as Reference Models and provide examples of the logical components and data flows related to this International Standard.
The “meter” is treated as an “end device”. The end device may contain a metrology capability, it may contain a communications capability, it may be a Load Control unit, and it may contain a mixture of many different types of functionality. Figure 1 attempts to describe the concept of essentially a shopping-list of functionality which may be available in the (logical or physical) end device.
Insert Figure Here
Figure 1 – Example of an end device with functions
The end device itself, while presenting a myriad of functionality, is not the subject of this standard. There are many interactions which ultimately affect the end device but occur as a result of a communication between systems at a much higher level in the control architecture. The interaction between systems is within the scope of this standard, and Figure 2 attempts to describe the exact systems involved, and provide an overview to the stakeholder landscape.
From the perspective of this standard, an end device:
· has a unique identity
· is managed as a physical asset
· may issue events
· may receive control requests
· may collect and report measured values
· may participate in utility business processes
Insert Figure Here
Figure 2 – Part 9 reference model
Insert Figure Here
Figure 3 - Part 9 Reference Model with Customer Information and Billing System
The reference architecture reflects five main logical components (potentially realized as systems or subsystems) related to metering:
a) Metering System, potentially including Data Collection and Control and reconfiguration functionality
b) Meter Data Management
c) Meter Maintenance
d) Load Management, potentially including Load Control and Load Analysis functionality
e) Meter Asset Management
The Metering System and Meter Maintenance System components may be bound to a specific Meter and associated communication technology or they may support multiple meters (and more generically end devices) types and associated communication technology. The Meter Data Management System component may support and consolidate meter data from more than one Metering System. The Metering System may also support consolidation of various measurement and data collection implementations, providing a consistent interface to the Meter Data Management System component.
The tasks of the Data Collection sub-component within the Metering System may include:
· Readings and status collection. Readings and status may be obtained through either manual or automated means, on a scheduled or on-request basis
· Transmission of meter readings and status to a Meter Data Management system
· Transmission of power reliability and quality event data to Outage Management, Network Operations, and Capacity Planning Systems
· Transmission of communication network health information to those responsible for maintaining the communications network.
It is important to note that Metering Systems are significantly diverse with respect to technologies used, protocols used, capabilities and frequency of data collection. The details of the internals of meters, communication transports and protocols are outside the scope of this International Standard.
A handheld device used by a human meter reader could be regarded as a metering system. In a typical meter reading by human, a reader inputs meter data into a handheld device in a field. The handheld device is not connected to a communication network in a field. At the end of day work, the handheld device is connected to a communication network at reader’s home (not in an office), and meter data is uploaded to a meter data management system. In this case, this communication network should be part of a metering system. Data collection is described in 61968-1 as “MR-RMR.”
The tasks of the Control and Reconfiguration subcomponent within the Metering System are:
a) Primary interface in executing meter control commands
b) Communicating payment system information
c) Act as a communication gateway for load control devices
d) Service Connect / Disconnect
e) Configuration of tariff units of measure and calendar
f) Configuration of power quality measurement
g) Configuration of meter event recording
h) Relay of Load Control signals
i) Configuration of meter identity and security credentials
j) Fraud detection
This subcomponent is identified separately within the Metering System in order to recognize the existence of Metering Systems that do not have the ability to send messages to meters. 61968-1 describes this subcomponent as “MR-MOP-Meter Configuration.”
The Metering System Infrastructure may often be used as a communication gateway to load control units (61968-1 describes this as “MR-LDC”). Load Control units are End Devices with Load Control (LC) capability. These are wired to control individual, target devices. End Devices with LC functionality can take on different forms. Quite often a dedicated LC unit can be located at (or near) the device to be controlled. Another approach is to use meters that have relays which are configured to serve as LC devices. Still another approach is to interface with a customer Energy Management System (which would be another type of end device).
A Load Management System is used to manage and control load by the utility in order to promote system reliability. A Load Management System may perform load forecasting, contingency analysis, and other simulations prior to issuing a load control command. This function largely falls under the domain of IEC 61968-5 (Operational Planning and optimization).
An Outage Management System (OMS) is used by distribution operators to detect and track outages, and to assist in the process of verification and/or restoration. An OMS typically combines (or has ties to) functionality such as Network Operations (61968-3) fault management (NO-FLT); Operational Planning and optimisation (61968-5) network operation simulation (NO-SIM); Maintenance and Construction (61968-6) maintenance and inspection (MC-MAI), and work scheduling and dispatching (MC-SCHD).
The Metering System can be an important source of information for identifying the existence and extent of outages, and can be used to verify the restoration of outages. The MS might have the ability to publish outage and restoration data to the OMS as it finds it. This type of information typically joins customer call-ins in the OMS to allow it to better predict the location of the outage. However, due to the time-sensitive nature of outage detection, there is also the potential need for a request/reply interface with the MS, where the OMS can ask for specific equipment on the distribution network to be tested by the MS, and an energisation status returned for analysis. The request/reply interface can be used by the OMS to supply critical data needed to make an outage prediction, or by a dispatcher who would like to verify that power has been restored to all of the metered endpoints downstream of a particular switch prior to sending the lineman to the next location.
Utilities will employ some form of asset management software in an effort to maintain detailed records regarding their physical assets. Asset Management is treated categorically in 61968-4. However, metering has such unusual requirements, that it is not uncommon for a utility to use specialized Meter Asset Management software. The software inventories the asset – providing a record of its physical attributes as well as its location. For sake of discussion, the part 9 document will talk about a MAM system which is closely coupled to the MS and MDM, though some implementations will successfully generalize the asset management application sufficiently so that it can live within a more generic AM system.
From a historical perspective, it was common for a utility to have more than one Automated Meter Reading System. Alternatively, a utility might outsource meter reading services to one or more third-party service providers who operate an AMR system and/or read the meters manually. The Meter Data Management (MDM) system is used to provide a common repository, and point of management and access of meter data that is collected from disparate Metering Systems. In addition to data aggregation, quite often the MDM will also make an effort to scrutinize the data collected from the various Metering Systems, and provide a Validating, Editing, and Estimating (VEE) capability. (IEC 61968-1 includes these functions under “MR-RMR-Meter data aggregation,” and “MR-MOP-Meter Data Management.”)
1.1.8 Customer Information System (CIS)
A CIS will typically encompass functionality related to customer care and billing. This is a subject which is external to the 61968 standard (refer to Customer account management (EXT-ACT)). The billing function is driven by readings, typically Demand or Time-of-Use, obtained from the meter. The CIS is also often involved with processes related to billing inquires, meter disconnect and meter reconnect, rate program changes.
Network Operations (61968-3) may occasionally need to issue load control and pricing signals to meters. This can be done for both economic and emergency reasons.
Meter Maintenance is responsible for functionality related to the configuration and installation of meters. This type of functionality generally falls under Meter Asset Management, or Asset Management in general. Performing meter maintenance may require exchanges with Work Management.
The planning function is described in Operational planning and optimisation (61968-5) network operation simulation (OP-SIM).
A Work Management system is responsible for work that is performed by field resources. This subject is covered in Maintenance and Construction (61968-6) maintenance and inspection (MC-MAI).
With respect to metering, WM includes the installation, maintenance and replacement of meters. This may also involve the process of special reads.
A Point of Sale (POS) system is used for the management of payment meters, where a customer either purchases a token or makes a payment for service. Point of Sale falls under the scope of IEC 61968-10.
The meter records the data used for tariffing public networks, and data used for network balancing mechanisms.
Readings captured by the MS are collected by a system such as the MDM before being presented for billing purposes. Billing entities may correct the data, or, in some regions, the energy supplier may perform Validating, Editing, and Estimating (VEE) according to rules established by the appropriate supervising regulatory agency. In any case, those corrections are made available to the user who requests them.
Where this International Standard refers to a Meter, it should be realized that a “Meter” is an end device that has metrology capability, it may or may not have communications capability, it may or may not have connect/disconnect capability, or a host of other capabilities. Given that a meter will have metrology capability, it will in all likelihood meter kWh, but possibly also demand, reactive energy and demand, Time Of Use quantities, Interval Data, Engineering quantities, and more.
Load control devices are used to control loads at a ServiceDeliveryPoint. The metering system may often have a communication network which can be used for transmitting load control signals to various CommunicationsAsset(s) in order to control the load presented by the EndDeviceAsset(s). Alternatively, the communication network could be used to communicate demand response (price) signals to the CommunicationsAsset(s) in order to affect the load presented by the EndDeviceAsset(s).
It is not the intention of this standard to define the applications and systems that vendors should produce. It is expected that a concrete (physical) application will provide the functionality of one or more abstract (logical) components as listed in this standard. These abstract components are grouped by the business functions of the Interface Reference Model.
In this standard, the term abstract component is used to refer to that portion of a software system that supports one or more of the interfaces defined in Parts 3 to 10. It does not necessarily mean that compliant software is delivered neither as separate modules nor as a single system.
Part 1 of this standard describes infrastructure services common to all abstract components while Parts 3-10 define the details of the information exchanged for specific types of abstract component.
IEC 61968 defines that:
a) An inter-application infrastructure is compliant if it supplies services defined in Part 1 to support at least two applications with interfaces compliant to sections of Parts 3 to 10.
b) An application interface is compliant if it supports the interface standards defined in Parts 3 to 10 for the relevant abstract components defined in the Interface Reference Model.
c) An application is only required to support interface standards of the applicable components listed under Abstract Components. An application is not required to support interfaces required by other Abstract Components of the same Business Sub-Function or within the same Business Function. While this standard primarily defines information exchanged among components in different business functions, it will occasionally also define information exchanged among components within a single Business Function when a strong market need for this capability has been realised.
It should be noted that the message types defined in this document: IEC 61968 Part 9: Interface Standard for Meter reading and Control, may be sent or received by any type of component within a Distribution Management System (DMS) system.
The Table 1 shows these functions and typical abstract components that are expected to be producers of information for these message types. Typical consumers of the information include, but are not restricted to, the other components as listed in IEC 61968 Part 1.
|
Business Functions |
Business
Sub-Functions |
Abstract Components |
|
Meter Reading and Control (MR) |
Metering System (MS) |
Data collection |
|
End point controls |
|
End point reconfiguration |
|
Disconnect/reconnect |
|
Demand reset |
|
On request read |
|
Point of sale |
|
Outage detection and restoration verification |
|
Power reliability and quality events |
|
Metering system events |
|
Meter Maintenance and Asset Management |
End point install, configure, remove, repair, disconnect, reconnect |
|
End point asset history |
|
End point reconfiguration |
|
Special read |
|
Meter service request |
|
Tariffs |
|
Meter Data Management (MDM) |
Meter data repository |
|
Usage history |
|
Validation, estimation and editing |
|
Customer billing data |
|
Load Management (LM) |
Load analysis |
|
Load control |
|
Demand response |
|
Performance measurements |
|
Risk management |
Table 1 – Business Functions and Abstract Components
The information model relevant to meter reading and control consists of classes that provide a template for the attributes for each message.
The classes are defined in detail in IEC61968 Part 11 or in IEC 61970 Part 301 “Energy Management System Application Program Interfaces – Common Information Model Core.”
Table 2 lists classes used within message types. Usually all the attributes of these classes are contained within a message type. The descriptions provided describe usage within this part.
Classes described as type "Document" are top-level container entities. Message type names are based on these entities.
Classes described as type "Asset" are defined in the 61968/Asset package of the CIM.
Classes described as type "Part" are lower level entities that are associated with a containing document.
Table 2 – Classes for meter reading and control
|
Noun |
Type |
Description |
|
ComEquipAsset |
Asset |
Communication equipment, other than media, such as gateways, routers, controllers, etc. |
|
ComFunction |
Document |
Communication function of communication equipment or a device such as a meter. |
|
ComMediaAsset |
Asset |
Communication media such as fibre optic cable, power-line, telephone, etc. |
|
CommunicationsAsset |
Asset |
The CommunicationsAsset class is used to represent a communications device that is attached to a piece of conducting equipment. A CommunicationsAsset may be associated with a specific EndDeviceAsset or other piece of conducting equipment (e.g., Power Transformer, Capacitor Bank Controller, Fault Monitor, Switch, etc).
The CommunicationsAsset is typically considered to be a meter communications module, or a load control unit. |
|
ConnectionRequest |
Document |
A ConnectionRequest is a subtype of EndDeviceControl that can be used to disconnect or reconnect service via a Meter using an MS.
The ConnectionRequest must identify the Meter and the type of action requested, e.g. connect or disconnect. |
|
CreditInformation |
Document |
Credit information is used for determining customer credit worthiness for point of sale meters. |
|
CustomerMeterDataSet |
Document |
The CustomerMeterDataSet includes one or more CustomerAccounts for one or more ServiceLocations for one or more ServiceDeliveryPoints. TheCustomerMeterDataSet may include one or more EndDeviceGroups. |
|
EndDeviceAsset |
Part 9 |
The EndDeviceAsset is equipment that performs the role of an end device. It may contain functionality such as metrology, communications, load control, connect/disconnect, or other capabilities. It is known as “the meter”, “a smart meter”, an “advanced meter”, ”air conditioner”, “refrigerator”, “pool pump”, etc. that a CommModule and/or MeterAsset may monitor and/or control. The asset may be owned by a consumer, a service provider, utility or other party. |
|
EndDeviceControl |
Part 9 |
Used to issue commands to EndDeviceAssets such as meters. May be addressed by EndDeviceAsset or by EndDeviceGroup. EndDeviceControls may have control types and parameters. |
|
EndDeviceEvent |
Part 9 |
Used to report events detected by end devices such as meters. Each EndDeviceEvent has an event type and a timestamp. |
|
EndDeviceGroup |
Part 9 |
An EndDeviceGroup is used for grouping end devices for a variety of purposes including, but not limited to, load control and other types of demand response. An EndDeviceGroup may belong to another EndDeviceGroup, and an end device may belong to zero or more EndDeviceGroups. In some cases the group ID is maintained within the end device, but in other cases it can be managed by a metering system. |
|
LoadControl |
Document |
A LoadControl is a subtype of EndDeviceControl, where a Meter may be instructed to activate a load control relay for a specified time interval. |
|
MeterAsset |
Part 9 |
The MeterAsset class is used to describe meters. A MeterAsset is a type of EndDevice typically used to measure and potentially monitor a customer load. The EndDeviceAsset class definition should be used as the basis for MeterAsset class. |
|
MeterReading |
Document |
A set of values obtained from the meter. Each MeterReading may have multiple ReadingTypes, and each ReadingType may contain multiple values. |
|
MeterReadingHistory |
Document |
A MeterReadingHistory is simply a sequence of MeterReadings for a particular Meter within a given timeframe. |
|
MeterServiceRequest |
Document |
A meter service request is a type of work that can be used for a variety of meter service related activities. These activities would include meter installation, meter change out, customer disconnect/reconnect, , etc. |
|
OutageDetectionEvent |
Document |
The OutageDetectionEvent contains the information of a trouble report which is the consequence of an MS outage detection or detection of a power quality issue (e.g. momentary outage) reported from a meter.
The OutageDetectionEvent may contain data identifying the meter’s associated Feeder, PowerTransformer, ServiceDeliveryPoint and ServiceLocation. |
|
PowerQualityEvent |
Document |
This is a subtype of EndDeviceEvent used to report power quality issues. |
|
PriceSignal |
Document |
This is a subtype of EndDeviceControl used to send price signals to a Meter. |
|
Reading |
Part 9 |
Subclass of MeasurementValue, where the value may be an integer, floating point or binary value. Each Reading has an associated ReadingType. Readings may have one or more MeasurementQuality indicators. |
|
ReadingType |
Part 9 |
Subclass of MeterReading, identifies the type of a Reading (e.g., Demand Register, Interval Register, Meter Configuration, Meter Health, Power Quality Thresholds, etc). The values associated with each ReadingType are defined in the specific type’s definition. |
|
ServiceDeliveryPoint |
Part 9 |
There can be multiple service points at a single service location, each one identified as a meter service point.
A service point exists within a service location and is used at the place where a meter may be installed. Properties include:
1) serviceType (gas, electric, water)
2) servicePhase
3) voltageLevel
4) vtdtReference (optional, where meters are indirectly connected for a medium voltage service) |
Table 3 lists those classes that are associated with Meter Reading and Control classes but only the name of an instance is given within messages defined in this standard. The detailed attributes of these classes are used in message types defined in other parts of IEC61968.
---temporary stop---more wikifying to do---
