MIOS

Universal Meter Reading & Common Doc. No.
001
Format
Version 2.3
th
Date 16 july 09
Table Of Contents Page
1 INTRODUCTION ................................................................................................................. 5
1.1 PURPOSE ........................................................................................................................... 5

1.2 SCOPE ............................................................................................................................... 5
1.3 DEFINITIONS & ABBREVIATIONS ......................................................................................... 6
1.4 REFERENCES ..................................................................................................................... 6
1.5 PRE-REQUISITES (OPTIONAL) ............................................................................................. 6
1.6 OVERVIEW (OPTIONAL) ...................................................................................................... 6
2 KEY POINT (OPTIONAL) ................................................................................................... 6
3 COMMON FRAME-WORK (CFW) ...................................................................................... 7
3.1 RESPONSIBILITY OF CFW ................................................................................................... 7

3.2 RESPONSIBILITY OF MANUFACTURER’S API........................................................................ 8
4 INVOKING METER MANUFACTURER MODULES .......................................................... 9
5 METER INTEROPERABILITY INTERPROCESS PROTOCOL (MII PROTOCOL) .......... 9
5.1 HEADER ........................................................................................................................... 10

5.2 COMMAND SET ................................................................................................................. 10
5.2.1 The Data portion of each command ............................................................................ 13
6 METER READING ............................................................................................................. 16
6.1 RESPONSIBILITY OF CFW FOR METER READING................................................................ 17

6.2 RESPONSIBILITY OF MANUFACTURER’S READING MODULE (API 1) .................................... 17
6.3 READING CONFIGURATION FILE ........................................................................................ 18
6.3.1 Dictionary for reading configuration file ....................................................................... 19
6.3.2 Connection type ........................................................................................................... 26
6.4 RESULT FILES................................................................................................................... 26
6.4.1 Dictionary for result file ................................................................................................ 26
6.4.2 Result Code ................................................................................................................. 28
6.4.3 Support to read remote device having one or multiple meter data............................. 28
7 PREPARING MRI AND DOWNLOADING DATA FROM MRI........................................ 28
7.1 RESPONSIBILITY OF CFW FOR PREPARING MRI AND DOWNLOADING DATA FROM MRI ..... 29
7.2 RESPONSIBILITY OF PREPARING MRI AND DOWNLOADING DATA FROM MRI (API2) .......... 29
7.3 PREPARING MRI AND DOWNLOADING DATA FROM MRI CONFIGURATION FILE ................... 30
7.3.1 Dictionary of preparing MRI and downloading data from MRI configuration file ........ 31
Public
Universal Meter Reading & Common Doc. No. 001
Format
Version 2.3
th
Table Of Contents Date 16 July 09
Page 2 of 107
7.4 MRI RESULT FILE............................................................................................................. 37

7.4.1 Dictionary for MRIRESULT result file .......................................................................... 37
7.4.2 Result Code-DOWNLOAD MODE .............................................................................. 39
7.4.3 Result Code-PREPARE MODE .................................................................................. 39
8 CONVERTING TO COMMON FORMAT .......................................................................... 39
8.1 RESPONSIBILITY OF CFW FOR CONVERTING TO CDF ....................................................... 40

8.2 RESPONSIBILITY OF COMMON FORMAT CONVERTER MODULE (API3) ................................ 40
8.3 CFC CONFIGURATION FILE ............................................................................................... 40
8.3.1 Dictionary for CFC configuration file ........................................................................... 41
8.4 RESULT FILE..................................................................................................................... 43
8.4.1 Dictionary for CFCResult file ....................................................................................... 43
8.4.2 Result Code ................................................................................................................. 45
9 COMMON DATA FORMAT (CDF) ................................................................................... 46
9.1 DATA FORMATS – POSSIBLE ALTERNATE ......................................................................... 46

9.2 PROPOSED COMMON FILE FORMAT ................................................................................... 46
9.2.1 Dictionary of common file format ................................................................................. 46
9.2.2 CDF .............................................................................................................................. 69
9.2.3 Utility Type ................................................................................................................... 70
9.2.4 General Information ..................................................................................................... 70
9.2.5 Instantaneous parameter............................................................................................. 71
9.2.6 Billing registers data .................................................................................................... 71
9.2.7 Profile data ................................................................................................................... 73
9.2.8 Events Data ................................................................................................................. 75
9.2.9 Daily energy snapshot ................................................................................................. 77
9.2.10 Duration data within thresholds ................................................................................. 78
9.2.11 Current meter settings ............................................................................................... 78
9.2.12 Transaction Data ....................................................................................................... 78
9.2.13 Flag Data ................................................................................................................... 79
9.3 PARAMETER CODES ......................................................................................................... 80
9.3.1 Parameter type ............................................................................................................ 80
9.3.2 Voltage ......................................................................................................................... 81
9.3.3 Current ......................................................................................................................... 81
9.3.4 Power ........................................................................................................................... 82
9.3.5 Power factor ................................................................................................................. 83
9.3.6 Voltage Angles ............................................................................................................. 84
9.3.7 Power factor Angles..................................................................................................... 84
9.3.8 Energy / Demand ......................................................................................................... 85
9.3.9 Phase Sequence ......................................................................................................... 87
9.3.10 Frequency .................................................................................................................. 87
9.3.11 Current angles ........................................................................................................... 87
9.3.12 Duration ..................................................................................................................... 88
10 INTEGRITY CHECK OF CDF ......................................................................................... 88
Public File Name: MIOS Universal Meter Reading common format V2.3.doc
Format
Version 2.3
th
Page 3 of 107
10.1 AUTHENTICATOR GENERATOR ........................................................................................ 88

10.2 AUTHENTICATOR VERIFIER ............................................................................................. 89
11 FUTURE EXPANDABILITY ............................................................................................ 90
12 LOG MAINTENANCE ..................................................................................................... 91
13 APPROVAL OF NEW TAGS .......................................................................................... 92
14 GLOSSARY OF TERMS ................................................................................................. 93
14.1 NOT APPLICABLE QUALIFIER IN A PARAMETER CODE ...................................................... 93

14.2 RETENTION OF DATA IN CASE OF MORE THAN ONE DATA SOURCE ................................... 93
14.3 DEFINED DURATION ........................................................................................................ 93
14.4 QUADRANT DEFINITION ................................................................................................... 93
14.5 PHASE SEQUENCE .......................................................................................................... 93
14.6 PARAMETER CODE LIST .................................................................................................. 93
15 ANNEXURE ..................................................................................................................... 96
15.1 API COMPATIBILITY WITH READING CONFIGURATION FILE ............................................... 96

15.2 ADDING MANUFACTURER SPECIFIC TAGS ........................................................................ 97
15.3 FOLDERS PATH FOR TEMPORARY FILES AND SOFTWARE HARDWARE SPECIFICATION ...... 97
16 DOCUMENT HISTORY ................................................................................................... 98
16.1 VERSION 01.00 .............................................................................................................. 98

16.2 VERSION 01.10 .............................................................................................................. 98
16.3 VERSION 01.20 .............................................................................................................. 98
16.4 VERSION 01.30 .............................................................................................................. 98
16.5 VERSION 01.40 .............................................................................................................. 98
16.6 VERSION 01.50 .............................................................................................................. 98
16.7 VERSION 01.60 (OCT 01, 2004) ..................................................................................... 99
16.8 VERSION 01.70 (NOV 04 2004) .................................................................................... 100
16.9 VERSION 01.80 (DEC 28 2004) .................................................................................... 100
16.10 VERSION 01.90(18TH JAN 05) ..................................................................................... 102
16.11 VERSION 01.10(18TH JAN 05) .................................................................................... 102
16.12 VERSION 01.11 .......................................................................................................... 102
16.13 VERSION 01.12 .......................................................................................................... 102
16.14 VERSION 1.13 ............................................................................................................ 103
16.15 VERSION 1.14 ............................................................................................................ 103
16.16 VERSION 1.15 ............................................................................................................ 104
16.17 VERSION 1.16 ............................................................................................................ 104
16.18 VERSION 1.17 ............................................................................................................ 104
16.19 VERSION 1.18 ............................................................................................................ 104
16.20 VERSION 1.19 ............................................................................................................ 104
Format
Version 2.3
th
Page 4 of 107
16.21 VERSION 1.20 ............................................................................................................ 104

16.22 VERSION 1.21 ............................................................................................................ 105
16.23 VERSION 1.22 ............................................................................................................ 105
16.24 VERSION 2.0 – 30TH MEETING 24TH NOV 2008 ............................................................. 105
• VERSION 2.0 – 30TH MEETING 24TH NOV 2008 .................................................................... 105
• VERSION 2.1 – 31ST MEETING 21ST JAN 2009 .................................................................... 105
• VERSION 2.2 – 33RD MEETING 8TH MAY 2009 ...................................................................... 106
• VERSION 2.3 – 34TH MEETING 16TH JULY 2009 .................................................................. 106
Format
Version 2.3
th
Page 5 of 107
1 Introduction
1.1 Purpose
The intention of this document is to provide possible way forward by the metering companies so that
utilities can use common IT infrastructure to gather information from meters of all manufacturers. This
initiative should help the utilities to protect their investments in reading and billing infrastructure for
meters of all types. In order to achieve this goal this document provides specification of software
which can be used for acquiring meter data of different manufacturer & to provide data in common
format for further processing of meter data.
The specification fulfils following objectives.

• To provide Common framework (CFW) for software & to specify interfaces so that
modules can be attached with it. It is envisaged that the common software will have minimum
functionality attached which is described below.
o To provide module (API) for reading meter.
o To provide module (API) for exporting data in common format so that 3rd party
software which is using the data for further processing will have uniform way of
handling the data irrespective of the manufacturer from which the meter is bought.
o To provide module (API) for checking integrity of the data.
• The common framework will ensure that
o Future expandability is easy to accommodate technically & administratively
o Backward compatibility for existing meter base
o Scalability of the software
o Accommodating different utility
o Simplicity of ‘maintenance’
o Security of the data
1.2 Scope
The computer system operates on different hardware & operating system. For the purpose of
simplicity PC hardware & Microsoft Windows operating system is used as operating platform. The
common framework software will operate on this platform & meter manufacturer will provide APIs for
this platform. It has been believed that meter manufacturer specific software will continue to operate.
The software written from this specification will simplify utilities every day work but there will still be
few technical operations left out for which manufacturer software will be used.
It has been assumed that the target application is to collect meter data from a fixed network on need
basis. The specification evolved here does not address on line data collection application or does not
address SCADA application. Since different meter continue to operate in it’s own way different makes
of meter will not be connected on the same connection point. Similarly meters can not operate with
different baudrate on the same network.
The common frame work software is not expected to operate on MRI. MRIs will continue to operate as
it is operating today whereby different manufacturer’s software co-exists on a common MRI.
This document does not specify that all meters will supply the same information. This document only
suggests that the same parameter is represented in the uniform way.
It is expected that each manufacturer will supply APIs as per the latest released version of the MIOS-
UMRCF specification. Each API will only comply to the respective manufacturer’s meters. The user of
the APIs (e.g. utility / System Integrator) will have to make their own arrangement for developing
software complying to Common framework specification (CFW).
Format
Version 2.3
th
Page 6 of 107
1.3 Definitions & Abbreviations

Name Description
PC Personal Computers whose design is derived from original IBM’ personal computer
architecture
CFW Common framework
CDF Common data format
API Application program interface
API1 Manufacturer’s reading module
API2 Manufacturer’s MRI downloading module
API3 Manufacturer’s CDF convert module
API4 Manufacturer’s authenticator verification module
Seed Number used as an input along with the data to generate authenticator
XML eXtended Markup Language
Bill Date/ Bill date is the date which then cumulative register for energy, MD etc. are frozen.
billing Billing will happen as per the meter configuration. Possible reasons can be Reset by
push button, occurrence of reset date.
1.4 References
No. Name Description
1 XML Legal site on XML standard www.w3c.org
2 RIPEMD - Algorithm for authentication. www.esat.kuleuven.ac.be
160
1.5 Pre-Requisites (Optional)
1.6 Overview (Optional)
2 Key Point (Optional)

One of the simplest way to resolve this issue is to enforce all the meter manufacturer’s to follow
the common reading protocol & to provide same set of data from all the meters. But this looks
impractical due to following reasons
• This will not provide solution for the present install base.
• This will stop innovation.
The solution should provide way such that it is possible for each meter manufacturer to be
independent from each other yet provide means of co-existence. The specification evolved here
does not envisage change in the meter software.
Format
Version 2.3
th
Page 7 of 107
3 Common Frame-Work (CFW)
Common Frame-Work (CFW)
Meter
Make #1 #1 MRD #1 MRI #1 CFC
#2 MRD #2 MRI #2 CFC Common

Meter Data
Make #2 Format
#3 MRI (CDF)
#3 MRD #3 CFC
Meter Manufacturer’s Manufacturer’s Common format

Make #3 Reading (MRD) MRI Converter (CFC)
modules (API1) Downloading & module (API3)
Prepare
(MRI) module
(API2)
The common framework will provide interface for APIs to be plugged in. The above diagram
shows three important functionality reading the meters & common format converter being plugged
in the CFW. This will ultimately result in Common Data Format (CDF).
3.1 Responsibility of CFW

1) CFW is to be designed for Microsoft Windows platform.
2) CFW is master program & each manufacturer specific API is a slave (passive) module.
3) All action will be initiated by user interface of CFW and CFW will in turn invoke API’s to
perform meter specific task.
4) To create & maintain manufacturer specific folders for containing file in manufacturer specific
format & one for containing common data format file folder
5) The CFW shall provide facility
a) To maintain consumer database (to co-relate factory serial number & consumer
number)
b) To schedule meter reading
c) To decide & supply information to be read from meter to reading API
d) To check up the result code & decide future course of action.
e) To convey error by suitable means such as unable to invoke the API, unable to
establish connection & so on.
f) To invoke convert API for conversion of data in CDF format.
Format
Version 2.3
th
Page 8 of 107
g) Manufacturer folder: There shall be three folders in manufacturer folder.

(1) CFW \ Manufacturer \ ABC \ ConversionPending
(2) CFW \ Manufacturer \ ABC \ ConversionDone
(3) CFW \ Manufacturer \ ABC \ ConversionError
(4) CFW \ Manufacturer \ ABC \ API
Manufacturer API with related files supplied will be kept here. Any file related to OS or
environment will be supplied by manufacturer & will be installed as per the
instructions given in the API release note.
h) To maintain common Data Format (CDF) folder in which common data format files
will be kept. The location of common data format file folder will be
i) CFW \ CDF \ …
6) CFW does not know how APIs work.
7) CFW will not change the information for any of the tags even if CFW believes that the
information supplied by the meter is obsolete & out of date.
8) Multiple instances of the same APIs will not be invoked by CFW.
9) House keeping is CFW’s responsibility & method of doing house keeping should be defined &
published by the CFW.
10) The agency desiring to use APIs will have to enter with a legal contract with manufacturer.
Each time API is deployed the manufacturer’s written permission is required.
11) CFW and API should be operated from the same machine. However different APIs can be
operated from different machine as long as it is accompanied by CFW.
12) Configuration files generated as a input to API should have all XML tags and attribute names
in upper case
3.2 Responsibility of manufacturer’s API

The manufacturer’s API will follow the rules as described below:
1. All APIs will be executable exes or batch files (i.e. EXE or .BAT).
2. All APIs are controlled by CFW. No API will handle screen or keyboard request directly.
3. All messages will either be passed on via configuration file or via the command structure
described.
4. APIs will transfer the messages via MII protocol. Longer message to API will be passed
on via configuration file.
5. APIs should pass on meaningful message in case particular command is not handled by
it.
6. Error reported can be meter specific or API specific. API should give clarity about it.
7. Success of the work is to be declared only if last step of the operation is done such as file
generated for a given command is stored at the indicated (or predefined) location.
8. APIs may drop some of the tags due to unavailability of information from the meter.
9. API will give acknowledgement of any command within 3 seconds.
Format
Version 2.3
th
Page 9 of 107
10. API shall take path/filenames and other parameter specified in configuration files provided
to the API and should not hardcode anything. Tag values written in this document are
suggested paths and are for example only.
11. Result file and common data format file generated should have all XML tags and
attributes in upper case.
12. API should create log file which can be used for debugging/troubleshooting purpose.
4 Invoking meter manufacturer modules

Meter manufacturer modules shall only be invoked with CFW .The CFW should pass IP address
and port number as two command line parameters. IP address is first parameter and port number
is second parameter.
Example of passing parameter
<APIName> 172.16.1.123 3333
User
selects the
operation
to be
performed
with meter
IP address and
Port number
Common Manufacturer’s
framework modules (API)
program
5 Meter Interoperability Interprocess Protocol (MII Protocol)
This is Interprocess protocol to have an effective means of communication between the two
systems. The two systems will communicate with each other through sockets by establishing a
TCP/IP connection and passing messages on this channel.
The system suggested ion this section is mainly designed to take care of the situation where
immediate attention is to be drawn during normal or abnormal condition. Smaller message will be
transferred via TCP/ IP link while bigger message will still be transferred via configuration file.
• This protocol passes meter wise information. Therefore, for each meter reading it will
pass one message to the manufacturer API whereas the API in turn passes a message
for each meter reading with instance number.
• CFW will control the traffic to the API & on TCP/IP message stream.
Format
Version 2.3
th
Page 10 of 107
• Not necessarily best optimized but it is disciplined

• All messages will be terminated by End of Line (&0D0A) characters.
The message structure is explained in the sections below:
5.1 Header
The message header would be comprised of the following fields:
Field Size Fixed Value

Header Length 2 “16”
Data Length 4
Command 2
Command qualifier 2
Additional command 2
Qualifier (Instance
number)
Instance Id 4
Header Length: This contains the length of the header record. This is fixed to 16 for this protocol
Data Length: The length of the data packet to read after the message header
Command: The action requested or response code

Command Qualifier: It is used to qualify the command
Additional Command Qualifier: It is used to sub-qualify the command
Instance ID: It is the instance number, generated by CFW and used to link the instance of meter
reading with the messages. This number will also be passed in the configuration file prepared by
CFW. It shall be the responsibility of CFW to link the messages between API and itself with the
instance number. It will be the responsibility of CFW to maintain unique instance Id. Maximum
length Instance Id will be of 4 characters. Instance Id can be alphanumeric characters.
Note: All the field values shall be passed in ASCII format, for example 12 will be sent as ‘12’ and
so on.
5.2 Command Set
Command Purpose Command qualifier Additional Qualifier Type of Data Flow

(CQ) (AQ) command
wrt CFW
01 Start 00:Meter reading 00: With audit trail Request CFW to API
01:MRI read 01: Silent operation,
02:MRI prepare only final result
03:Convert to required
common format 02: Indicate only
major milestones
(do not supply
incremental
progress)
02 Acknowled 00: Receipt of 00 :Accepted Response API to CFW
ge start Reading command 01: Failed due to
operation 01:Receipt of MRI duplicate instance
download ID
command 02: Failed due to
02:Receipt of MRI Invalid configuration
Format
Version 2.3
th
Page 11 of 107
prepare command file.

03:Receipt of 03: Invalid or
Convert to common unknown command
format command 04: command not
supported
05: Falied due to
invalid instance Id
03 Abort & 00: Abort Meter 00: Abort Request CFW to API
close reading 01: Abort & close
Operation 01: Abort MRI
download
02: Abort MRI
prepare
03: Abort Convert
to common format
04 Report 00:Meter reading 00: In progress Response API to CFW
progress 01:MRI download 01: Connection
02:MRI prepare established.
03:Convert to 02: Meter reading
common format started
03: Meter reading
finished
04: CDF conversion
successful
05: Idle state
51: Cannot establish
connection – No dial
tone
connection – Local
Modem not
responding
connection – Line
busy
connection – Port
not available
connection – No
hand shaking
56: Line
disconnected
57: CDF Conversion
failed – File
structure corrupted
58: CDF Conversion
failed – file write
error
59: CDF Conversion
failed – File not
found
60 :User Abort
61: Process stopped
Format
Version 2.3
th
Page 12 of 107
- Meter Serial No.

Mismatch"
62 : Meter reading
failed
63: Conversion
Failed.
64: File(s) are not
available for Data
conversion.
65:Meter reading
failed - Check Sum
Error.
66 :Meter reading
failed - Data
Collection error..."
67: Invalid
Header..."
68: Source Folder
Path not Found.
69: Unit Code is not
set. Continuing with
remaining Meters.
70: Tariff cant be
zero.
71: Can't continue
with Parsing.
72: Unsupported
meter Version.
73:Not enough free
space
74 :Meter is inactive,
cannot Collect Data
75: Can notailed
establish connection
-No carrier
76: Can not
establish connection
– No answer
77: MRI data
transfer successful
78: MRI data
transfer failed
79: MRI not
responding
80-Failed to
configure remote
device due to invalid
configuration file.
81-Failed to initialise
remote device.
05 Request for 00:Meter reading Request CFW to API

progress 01:MRI download
status 02:MRI prepare
03:Convert to
Format
Version 2.3
th
Page 13 of 107
common format
06 Request for 00:Default value 00:Default value Request CFW to API
API
identificatio
n
07 Response 00:Default value 00:Default value Response API to CFW
to API
identificatio
n
command
5.2.1 The Data portion of each command
Command Comm Data Field Name Field Description

No and Field
qualifi No
ers
001 All 1 Configuration file name The name (with path) of the
configuration file to be used by the
meter reading program
004 All 1 Message The progress message to be shown
on user interface, or final status,
depending on the qualifier
Example 1. Start Meter Reading
Header
Field Size Example
Header Length 2 16
Data Length 4 0087
Command 2 01
Command Qualifier 2 00
Additional Qualifier 2 00
Instance Number 4 0001
Mode of meter reading will be decided by Additional Qualifier as below
Additional Qualifier Mode

00 Audit Trail Mode
01 Silent Mode
02 Mile stone mode
Header data would be: 1600870100000001 (in ASCII)

Data
No Field
1 Configuration file name
The data packet would be

C:\Program Files\CFW\SML\ConfigurationFiles\READCFG \ InstanceID_Readcfgfile .XML
The entire packet is the addition of the header data and command data, like
Format
Version 2.3
th
Page 14 of 107
1600870100000001C:\Program Files\CFW\SML\ConfigurationFiles\READCFG \
InstanceID_Readcfgfile .XML
The above packet will be enclosed within TCP/IP framework.
Example 2. Acknowledge Meter Reading

Header
Field Size Example
Header Length 2 16
Data Length 4 0000
Command 2 02
Header data would be: 1600000200000001
There is no data in this command; therefore the data length is 00. The above packet will be
enclosed within TCP/IP framework.
Header data would be: 1600380200000001Invalid configuration file: modem make
There is data in this command; therefore the data length is 38. The above packet will be enclosed
within TCP/IP framework.
Example 3. Abort Meter Reading

Header
Field Size Example
Header Length 2 16
Data Length 4 0000
Command 2 03
There is no data in this command, therefore the data length is 00. The above packet will be
enclosed within TCP/IP framework. In case of multiple thread of an API abort command will only
kill a particular instance Id of the TCP / IP link. In case instance Id is 0000 then all the instances
will be closed & API will be terminated.
Example 4. Report progress

Header
Field Size Example
Header Length 2 16
Data Length 4 0041
Command 2 04
Format
Version 2.3
th
Page 15 of 107

Data
No Field
1 Message
Data would be: Meter No XYZ0001, Phase 1- Step 1 complete
The entire data packet will be

1600410400000001Meter No XYZ0001, Phase 1- Step 1 complete
To indicate BR at which the connection is established the message format can be as follows:
1600040400010001,4800
For Audit Trail Mode: - API will respond more frequently to CFW while meter reading is going
on.
Example:-
0001|1600080200000001|ACCEPTED
1600250400010001|TRND0001,MakingConnection
1600400400000001|TRND0001,ReadingInstParams, Message:1
1600360400000001|TRND0001,ReadingEnergy, Message:1
1600360400000001|TRND0001,ReadingEnergy, Message:2
For Silent Mode: - API will respond only at start and end step to CFW while meter reading action
is performed. Example:-
1600080200000003|ACCEPTED
1600160400030003|TRND0001,Success
For Mile stone Mode: - API will respond only on major steps to CFW while meter reading action
is going on. Example:-
1600080200000002|ACCEPTED
1600250400000002|TRND0001,MakingConnection
1600260400000002|TRND0001,ReadingInstParams
1600220400000002|TRND0001,ReadingEnergy
Example 5. Request for Progress
Header
Field Size Example
Header Length 2 16
Data Length 4 0041
Command 2 05
Header would be: 1600018500000001
Format
Version 2.3
th
Page 16 of 107
Data
No Field
1 Message
Data would be: Meter No XYZ0001, Phase 1- Step 1 complete
The entire packet will be like 1600410500000001 Meter No XYZ0001, Phase 2- Step 2 complete
Example 6. Request for API identification
Header
Field Size Example
Header Length 2 16
Data Length 4 0000
Command 2 06
Header would be: 1600000600000001
The entire packet will be like 1600000600000001

Example 7. Response to API identification command
Header
Field Size Example
Header Length 2 16
Data Length 4 0010
Command 2 07
Header would be: 1600100700000001

Data
No Field
1 API name with extension
The entire packet will be like 1600100700000001LNTMRD.EXE

6 Meter Reading
This function enables CFW to meter of any make. User will select the data to be read from meter.
CFW will generate configuration file which will specify connection details and data to be read from
meter. CFW will invoke Manufacturer reading module (API 1) to read the meter and store the data
in manufacturer specific format in manufacturer folder.
Multiple meter reading option is applicable only when more than one meter is connected on the
same network (or on the same telephone line). When multiple meters reading option is chosen
Format
Version 2.3
th
Page 17 of 107
each meter is read sequentially. Next meter reading is started once first meter reading is
completed.
User
selects the Meter
Connection details
operation Make #1
(Connection type,
to be
Baudrate, Device
performed
ID,
with meter
port)
What to read from
meter? Meter
ReadMeter Make #2
Audit trail/
Result log
Meter
Common Manufacturer’s Make #3
framework Reading (MR)
program modules (API)
6.1 Responsibility of CFW for meter reading

1) Create reading configuration file. This will contains the information about connection, data
to be read and paths/names of intermediate files.
2) Decide & Invoke respective meter manufacturer’s reading API
3) Looking at the TCP /IP message for showing progress of reading process.
4) Deciding course of action after looking at result file.
5) CFW should terminate the API after getting the required work done. This will
automatically break the TCP / IP link.
6) Reading configuration file should contain meters of only one make.
7) Though it is responsibility of API to bring the modem back to standard setting of
(1200/N/8/1) however in case of abnormal termination of API or in exception condition
modem does not come back to standard setting. In this case the CFW should check &
ensure that the modem setting is (1200/N/8/1) before assigning modem for next meter
reading instance.
6.2 Responsibility of manufacturer’s reading module (API 1)

Responsibility of manufacturer reading modules is
1) Reading the meter and making files in manufacturer specific format in manufacturer
folder. The meter reading shall be done as defined in reading configuration file.
2) Deleting all temporary or incomplete files
3) Creating result file which will be used by CFW for determining result of the operation
4) API should start the operation only after verifying that it has been invoked by CFW.
Format
Version 2.3
th
Page 18 of 107
5) API should establish the TCP / IP link with CFW.

6) API should open the COM port & close the COM port after completing the required work.
7) Configuring the modem will be responsibility of API.
8) API will attempt to use specified Baudrate.
9) API will attempt to read as per the reading configuration file. However if meter does not
support specific read request, it will read as per nearby supported configuration.
10) Modem configuration file will be supplied by meter manufacturer and will follow
manufacturer’s name followed by file name. The details for modem configuration file
structure should be provided by meter manufacturer to CFW writer.
11) It is primary responsibility of API to set the modem to standard setting of 1200 baud, No
parity, 8 data bits and 1 stop bit (1200/N/8/1) while leaving the modem. All API’s can
assume that modem will be at above setting before using the modem for meter reading.
This is required so that API’s from different manufacturer can use same modem.
12) Entire set of manufacturer’s API will be kept in separate folder.
13) Manufacturer should provide list of mandatory tags and the possible values of the tags
applicable for the API in the format mentioned in Annexure.
14) There can be multiple manufacturer specific format file generated by reading API.
Manufacturer should provide the list of output file generated from reading API.
15) API shall take path/filenames and other parameter specified in configuration files provided
to the API and should not hardcode anything. Tag values written in this document are
suggested paths and are for example only.
16) For verification purpose of the data given by API, a suitable tool will have to be supplied
by the respective manufacturer.
6.3 Reading Configuration file

The structure of the reading configuration will look like
<READAPI>
<INSTANCEID>0009</INSTANCEID>
<CONNECTIONDETAIL>
<BAUDRATE>1200</BAUDRATE>
<CONNECTIONTYPE>PSTN</CONNECTIONTYPE>
<MODEMMAKE>MultiTech ZX</MODEMMAKE>
<MODEMCONFIGFILE>C:\CFW\modem.cfg</MODEMCONFIGFILE>
<DIALRETRY>3</DIALRETRY>
<PORT>COM1</PORT>
<TELEPHONENUMBER>989156</TELEPHONENUMBER>
<MULTIPLEMETERS>No</MULTIPLEMETERS>
<SERIAL>NDP18271</SERIAL>
<DEVICEID>0</DEVICEID>
</CONNECTIONDETAIL>
<WHATTOREAD>
<INSTPARAM>Yes</INSTPARAM>
Format
Version 2.3
th
Page 19 of 107
<ENERGYDATA>0</ENERGYDATA>
<EVENTS>no</EVENTS>
<LOADPROFILE>
<DAYS>0</DAYS>
<TYPE>partial</TYPE>
</LOADPROFILE>
</WHATTOREAD>
<PATHANDNAME>
<DATAFILEPATH>C:\CFW\MANUFACTURER\SEMS\METERDATA</DATAFILEPATH>
<RESULTFILE>C:\CFW\MANUFACTURER\SEMS\READRESULT\ReadResult_0009_0501200512158.XML</RESULTF
ILE>
</PATHANDNAME>
<COMMAND>
<TIMESYNCH>No</TIMESYNCH>
<MDRESET>No</MDRESET>
<TAMPERRESET>No</TAMPERRESET>
</COMMAND>
</READAPI>
6.3.1 Dictionary for reading configuration file
Element Details
READAPI Description: This is root element of configuration file

Contains: InstanceID, ConnectionDetails, WhatToRead,
PathandName and command
Is Contained by: None
Attribute : None
Occurrence: Single
DataType : N/A
INSTANCEID Description: This contains the value of instance number which is

a running number for the request given by CFW to API. It should
be four digit number with ‘0’ appended in beginning if number is
less then 4 digit.
Contains: None
Is Contained by: READAPI
Attribute : None
Occurrence: Single
DataType: Numeric
CONNECTIONDETAILS Description: Connection information is contained in this tag

Contains: BAUDRATE, TYPE, PORT, SERIAL,
MULLTIPLEMETER, DEVICEID, MODEMMAKE
DIALRETRY,METERCOMMUNICATIONPORT,
Format
Version 2.3
th
Page 20 of 107
MODEMCONFIGFILE, TELEPHONENUMBER
Attribute : None
Occurrence: Single
DataType: N/A
MODEMMAKE Description: Modem make & model number information is

contained in this tag
Contains: None
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Single
DataType: Alphanumeric
MODEMCONFIGFILE Description: Modem initialisation command information is

contained in this tag
Contains: None
Attribute : None
Occurrence: Single
BAUDRATE Description: Holds value of baudrate. Value can

1200,2400,4800,9600 and so on. Meter may not support all
baudrate. And the value provided shall be applicable to that
meter make otherwise READAPI will take its default baudrate.
Contains: None
Attribute : None
Occurrence: Single
DataType: Numeric
CONNECTIONTYPE Description: Holds value of connection type at computer end. It

can take following values – Direct, PSTN, TCP/IP,GPRS, GSM,
VSAT, RF, PLCC
Contains: TELEPHONENUMBER (or IP address for TCP/IP
connection type)
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
Format
Version 2.3
th
Page 21 of 107
TELEPHONENUMBER Description: Holds value of telephone number

Contains: None
Is Contained by: CONNECTIONDETAIL
Attribute : None
Occurrence: Single
DIALRETRY Description: Holds value of maximum dial retries count in case

of unsuccessful attempts.
Contains: None
Is Contained by: CONNECTIONDETAIL
Attribute : None
Occurrence: Single
DataType: Numeric
PORT Description: Holds value of Comport – Com1, Com2, Comn, or

TCP port address for TCP/IP connection type such as 80h, 81h
etc at computer end.
Contains: None
Attribute : None
Occurrence: Single
METERCOMMUNICATIONPORT Description: Holds value of com port at meter end optical,

RS232, RF, RS 485, IrDA, USB
Contains: None
Is Contained by: ConnectionDetails
Attribute : None
Occurrence: Single
MULTIPLEMETERS Description: Holds ‘Yes’ if multiple meters are connected and

‘No’ if single meter is connected. In case of multiple meters is
‘Yes’ the meters shall be of same make.
Contains: None
Attribute : None
Occurrence: Single
Format
Version 2.3
th
Page 22 of 107
SERIAL Description: Holds the value of meter serial number

Contains: None
Attribute : None
Occurrence: Multiple
DEVICE ID Description: Holds device id of the meter connected. The valid

device id will be numeric such as 0,1,2 & so on.
Contains: None
Attribute : None
WHATTOREAD Description: Specifies about what is to be read by manufacturer

reading API
Contains: INSTPARAM, BILLINGDATA, LOADPROFILE,
EVENTS
Attribute : None
Occurrence: Single
DataType: N/A
INSTPARAM Description: Holds ‘YES’ if instantaneous parameters are to be

read and ‘NO’ if instantaneous parameters are not to be read.
Contains: None
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
ENERGYDATA Description: Holds 0 for current, -1 for history 1(the most

recent), -2 for history set previous to the most recent & so on.
Holds 1 for complete reading. Holds ‘NO’ if Energydata should
not be read. The selection is not applicable for information
appearing under D6, D7.
Contains: None
Attribute : None
Occurrence: multiple
Format
Version 2.3
th
Page 23 of 107
SETTINGS Description: Holds ‘Yes’ if meter settings is to be read

Contains: None
Attribute : None
Occurrence: Single
LOADPROFILE Description: Specifies profile data to be read

Contains: Days , type
Attribute : None
Occurrence: Single
DataType: None
DAYS Description: Holds number of days of profile data to be read. ‘0’

days will indicate no data to read.
Contains: None
Is Contained by: PROFILEDATA
Attribute : None
Occurrence: Single
DataType: Numeric
TYPE Description: Holds ‘Full’ if complete profile data available in

meter is to be read or ’Partial’ if profile data since last reading is
to be read Or ‘NO’ in case no data is to be read.
Contains: None
Attribute : None
Occurrence: Single
EVENTS Description: Holds ‘YES’ if events data is to be read and ‘NO if

events data is not to be read.
Contains: None
Attribute : None
Occurrence: Single
Format
Version 2.3
th
Page 24 of 107
TRANSACTION Description: Holds ‘YES’ if transaction data is to be read and

‘NO if transaction data is not to be read.
Contains: None
Attribute : None
Occurrence: Single
CURRENTSETTING Description: Holds ‘YES’ if current settings data is to be read

and ‘NO if current settings is not to be read. This data can only be
provided if meter program supports it.
Contains: None
Attribute : None
Occurrence: Single
PATHANDNAME Description: Specify the path and name for the files used by
CFW and API1.
Contains: DATAFILEPATH, RESULTFILE
Attribute : None
Occurrence: Single
DataType: N/A
DATAFILEPATH Description: Holds value of the path where manufacturer

specific format data file will be created by manufacturer reading
API. There is possibility of single file having multiple meters data
or as many number of files as the number of meter read.
Contains: None
Is Contained by: PATHANDNAME
Attribute : None
Occurrence: Single
RESULTFILE Description: Holds the name of file which contains consequence

of the operation.
Contains: None
Attribute : None
Format
Version 2.3
th
Page 25 of 107
Occurrence: Single
COMMAND Description: Holds the name of instructions to be sent to the

meter at the time of reading
Contains: TIMESYNCH, MDRESET, TAMPERRESET
Attribute : None
Occurrence: Single
DataType: N/A
TIMESYNCH For Future use( not applicable for now)

Description: Holds “YES” if time synchronisation of meter is to
be done else it will contains “NO” .
Contains: None
Is Contained by: COMMAND
Attribute : None
Occurrence: Single
DataType: N/A
MDRESET For Future use( not applicable for now)

Description: Holds “YES” if MD reset in meter is to be done else
it will contains “NO” .
Contains: None
Attribute : None
Occurrence: Single
DataType: N/A
TAMPERRESET For Future use( not applicable for now)

Description: Holds “YES” if tamper reset in meter is to be done
else it will contains “NO” .
Contains: None
Attribute : None
Occurrence: Single
DataType: N/A
Format
Version 2.3
th
Page 26 of 107
6.3.2 Connection type
ConnectionType tag values Description
Direct Local connection through RS232, One to

one or one to many
PSTN Connection through telephone line via

telephone line modem
GSM Connection through GSM modems
GPRS Connection through GPRS modems
RF Connection through Low Power Radio
RS485 Local connection through RS485, One to

one or one to many
TCP/IP Connection through TCP/IP connection
6.4 Result files

The purpose of this file is to give result of reading operation which can be used by CFW for
deciding next course of action. This file is the common file for all manufacturers. All manufacturers
will follow strict format of this file. This is an XML file with following structure
<READINGRESULT>
<INSTANCE>
<DATETIME>04-01-2005 14:21:54</DATETIME>
<OUTPUTFILENAME> C:\CFW\Manufacturer\ABC\01012004.MRD</ OUTPUTFILENAME >
<RESULT>2</RESULT>
<DEVIATION>
<ENERYDATA/>
</DEVIATION>
</INSTANCE>
</READINGRESULT>
6.4.1 Dictionary for result file
Element Description
READINGRESULT Description: This is root node for reading result file

Contains: INSTANCE
Format
Version 2.3
th
Page 27 of 107
Attribute : None
Occurrence: Single
DataType: N/A
INSTANCE Description: This node will appear for every instance result. If result of the
instance id is to be appended in same file then a new instace tag shall be
created.
Contains: Serial, DATETIME, RESULT, OUTPUTFILENAME,
INSTANCEID
Is Contained by: ReadingResult
Attribute : None
Occurrence: One or more
DataType: N/A
INSTANCEID Description: This contains the value of instance number which is a running
number for the request given by CFW to API. It should be four digit number
with ‘0’ appended in beginning if number is less then 4 digit.
Contains: None
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Numeric
SERIAL Description: Holds value of meter serial number.

Contains: None
Attribute : None
Occurrence: Single
DATETIME Description: Holds value of date time of meter reading.

Contains: None
Attribute : None
Occurrence: Single
DataType: DateTime in dd-mm-yyyy hh:mm:ss format
OUTPUTFILENAME Description: Holds value of manufacturer specific file made by reading A

Contains: None
Attribute : None
Format
Version 2.3
th
Page 28 of 107
RESULT Description: Holds the value of result of the reading operation.

Contains: None
Attribute : None
Occurrence: Single
DEVIATION Description: Holds the sub-tags of ‘WhatToRead’ tag for which deviation is
taken.
Contains: Empty sub-tags of WHATTOREAD
Is Contained by: Instance
Attribute : None
Occurrence: Single
DataType: None
6.4.2 Result Code
Result Code Description
0 Success
1 Failure
2 Success with Deviation
6.4.3 Support to read remote device having one or multiple meter data
Remote device periodically reads data from meter and stores the same into it’s local memory.
CFW will have to collect the data from this device.
API1 will support reading meter or remote device. The read data will be stored in manufacture
specific folder. Remote device support is restricted to device supplied by the meter manufacturer.
Tag to be passed in Reading Configuration file is explained below
<REMOTEDEVICE> Two possible values either METER or RMD. If the value is “RMD” then
API will get to know that the reading will happen from remote device therefore read
accordingly, If this tag is not present the default value would be assumed as mater.
7 Preparing MRI and downloading data from MRI

This function enables CFW to prepare the MRI or download data from MRI.
Assumption: Prepare MRI and download data from MRI operation cannot execute on single
request or single configuration file.
Format
Version 2.3
th
Page 29 of 107
7.1 Responsibility of CFW for Preparing MRI and downloading data from MRI
User Communication
selects the and other details MRI
operation (MRI type, Make #1
to be Baudrate,
performed Comport)
with meter What to read from
meter/MRI ..? Clear MRI
MRI
Clear MRI ? MRI Operation Make #2
Prepare
Invoke MRI API Result log
with above details
Manufacturer’s MRI
Common Make #3
framework MRI Prepare &
Downloading
program
modules (API)
1) Ask from user what action does he want to perform either Preparing MRI or Download form
MRI
2) According to point 1, create configuration in XML format. This file contains information like
a. What operation to perform (Prepare/Download)
b. What to read from meter (Instantaneous, energy, events, tampers)
c. MRI makes and communication details baudrate (between PC & MRI) & comport.
d. Whether or not to clear the MRI files.
3) CFW should provide facility to select meter manufacturer whose APIs are to be invoked
during preparing or downloading operation.
4) Invoking meter manufacturer specific MRI API for preparing or downloading operation.
5) Deciding course of action based on the result file.
6) The naming convention of MRI read configuration file is INSTANCEID_MRICFGFILE.XML for
e.g. 0003_ MRICFGFILE.XML
7) The naming convention of MRI result configuration file is
INSTANCEID_MRIRESULTFILE.XML
8) Configuration file should contain meters of only one make.
7.2 Responsibility of preparing MRI and downloading data from MRI (API2)
1) Prepare MRI
a. Delete all temporary or incomplete files from MRI.
b. Upload schedule files in MRI.
c. Create result file.
Format
Version 2.3
th
Page 30 of 107
2) Download MRI
a. Read from MRI and transfer data files in manufacturer specific folder on PC.
b. Delete all temporary or incomplete files from MRI.
c. Create result file.
d. The data file name should be prefixed with ‘MRI’ letter.
Note: API shall take path/filenames and other parameter specified in configuration files provided to the
API and should not hardcode anything. Tag values written in this document are suggested paths and
are for example only
7.3 Preparing MRI and downloading data from MRI configuration file
Prepare MRI feature is optional & may not be supported by all meter manufacturer.
This file contains the information about Whattoread (Instantaneous, energy, events, tampers), make
of MRI, Data format, Path related information, port or whether to clear the MRI or not. The structure of
the file is
Prepare e.g.
<MRIAPI>
<INSTANCEID>0001<INSTANCEID>
<WHICHMRI> MRI MAKE1 </WHICHMRI>
<DATAFORMAT>NORMAL </DATAFORMAT> OR COMPRESSED
<PROTOCOLTYPE>STANDARD</PROTOCOLTYPE>
<IPADDRESS>120.75.29.30</IPADDRESS>
<PORT> COM1 </PORT> -- PORT NUMBER IF IP ADDRESS IS GIVEN ( 10020)
<PREPARE>
<WHATTOREAD type=”full/custom>
<INSTPARAM>Yes</INSTPARAM>
<ENERGYDATA>1</ENERGYDATA>
<EVENTS>no</EVENTS>
<LOADPROFILE>
<DAYS>0</DAYS>
<TYPE>partial</TYPE>
</LOADPROFILE>
</WHATTOREAD>
<DELETEFROMMRI>YES </DELETEFROMMRI>
<PATHANDNAME>
<MRISCHEDULEFILEPATH>C:\DATA\ </ MRISCHEDULEFILEPATH >
<RESULTFILE>C:\CFW\MANUFACTURER\0001_MRIRESULTFILE.XML</RESULTFILE> (ALWAYS IN APPEND
MODE)
</PATHANDNAME>
</PREPARE>
</MRIAPI>
Format
Version 2.3
th
Page 31 of 107
Download e.g.
<MRIAPI>
<WHICHMRI> MRI MAKE1 </WHICHMRI>
<DATAFORMAT>NORMAL </DATAFORMAT> OR COMPRESSED
<PROTOCOLTYPE>STANDARD</PROTOCOLTYPE>
<IPADDRESS>120.75.29.30</IPADDRESS>
<PORT> COM1 </PORT> -- PORT NUMBER IF IP ADDRESS IS GIVEN ( 10020)
<DOWNLOAD>
<DELETEFROMMRI>YES </DELETEFROMMRI>
<PATHANDNAME>
<PCDATAFILEPATH>C:\CFW\MANUFACTURER\ABC</PCDATAFILEPATH>
<RESULTFILE>C:\CFW\MANUFACTURER\ 0002_MRIRESULTFILE.XML</RESULTFILE> (ALWAYS IN APPEND
MODE)
</PATHANDNAME>
</DOWNLOAD>
</MRIAPI>
7.3.1 Dictionary of preparing MRI and downloading data from MRI configuration file
Element Description
MRIAPI Description: This is root node for preparing MRI and downloading data
from MRI configuration file.
Contains:
WHICHMRI,DATAFORMAT,PROTOCOLTYPE,IPADDRESS,PORT,
BAUDRATE, PREPARE,DOWNLOAD
Attribute : None
Occurrence: Single
DataType: N/A
INSTANCEID Description: This contains the value of instance number which is a

running number for the request given by CFW to API. It should be four
digit numbers with ‘0’ appended in beginning if number is less then 4
digit.
Contains: None
Is Contained by: MRIAPI
Format
Version 2.3
th
Page 32 of 107
Attribute : None
Occurrence: Single
DataType: Numeric
WHICHMRI Description: Holds value of make of Handheld unit (MRI)

Contains: None
Attribute : Analogic, Sands, Radix, PDA
Occurrence: Single
DATAFORMAT Description: Holds value of data type which can either be compressed
or can be normal. This is an optional tag.
Contains: None
Attribute: Compressed, Normal
Occurrence: Single
SERIAL Description: Holds value of serial number of meter to be transferred or

meter to be prepared. This is an optional tag
Contains: None
Attribute : ABC00001 & so on
PORT Description: Holds value of port number of PC via which data is to be

transferred. This is an optional tag
Contains: None
Attribute : COM1, COM2, COM3, COM4, 8080
Occurrence: Single
PROTOCOL TYPE Description: Holds value of protocol followed by MRI. This is an

optional tag
Contains: None
Attribute : None
Format
Version 2.3
th
Page 33 of 107
Occurrence: Single
IP ADDRESS Description: Holds value of IP address of meter to be transferred. This

is an optional tag
Contains: None
Attribute : None
Occurrence: Single
DataType: Numeric
BAUDRATE Description: Holds value of baudrate. Value can 1200,2400,4800,9600

and so on. The baudrate between PC and MRI.
Contains: None
Attribute : None
Occurrence: Single
DataType: Numeric
DOWNLOAD Description: This is root node for download data from MRI. This is an
optional tag
Contains: PATHNAME, DELETEFROMMRI
Attribute : None
Occurrence: Single
DataType: Numeric
DELETEFROMMRI Description: Holds ‘Yes’ if data files are to be deleted in downloading

/Prepare of MRI operation
Contains: None
Is Contained by: DOWNLOAD
Attribute : None
Occurrence: Single
DataType: Can take value “Yes” or “No”
PATHNAME Description: This contains the path related information. This is an

optional tag
Contains: MRIDataFilePath, PCDataFilePath, ResultFile
Is Contained by: DOWNLOAD
Attribute : None
Occurrence: Single
Format
Version 2.3
th
Page 34 of 107
DataType: Numeric
MRIDATAFILEPATH Description: Specify the path (&name) of the files to be transferred

from MRI.
Contains: None
Is Contained by: PATHNAME
Attribute : None
Occurrence: Single
PCDATAFILEPATH Description: Specify the path where the files are to be transferred to
PC
Contains: None
Attribute : None
Occurrence: Single
OUTPUTFILENAME Description: Specify the path where the files are to be transferred to
PC
Contains: Filename
Attribute : None
Occurrence: Single
FILENAME Description: Specify the path where the files are to be transferred to
PC
Contains: None
Is Contained by: OUTPUTFILENAME
Attribute : None
PREPARE Description: This is root node for preparing MRI. This is an optional tag
Contains: PATHNAME, WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Numeric
Format
Version 2.3
th
Page 35 of 107
WHATTOREAD Description: Specifies about what data to be read from Meter. It has
two attributes 1. Full 2. Custom
FULL- All data to be read from Meter
Customer- Partial data to be read Meter
Contains: INSTPARAM, BILLINGDATA, LOADPROFILE, EVENTS
Is Contained by: PREPARE
Attribute : FULL, Custom
Occurrence: Single
DataType: N/A
INSTPARAM Description: Holds ‘YES’ if instantaneous parameters are to be read

and ‘NO’ if instantaneous parameters are not to be read.
Contains: None
Attribute : None
Occurrence: Single
ENERGYDATA Description: Holds 0 for current, -1 for history1 (the most recent), -2 for
history set previous to the most recent & so on. Holds 1 for complete
reading. Holds ‘NO’ if Energy data should not be read. The selection is
not applicable for information appearing under D6, D7.
Contains: None
Attribute : None
Occurrence: multiple
SETTINGS Description: Holds ‘Yes’ if a meter setting is to be read. This is an

optional tag.
Contains: None
Attribute : None
Occurrence: Single
LOADPROFILE Description: Specifies profile data to be read

Contains: Days , type
Attribute : None
Format
Version 2.3
th
Page 36 of 107
Occurrence: Single
DataType: None
DAYS Description: Holds number of days of profile data to be read. ‘0’ days
will indicate no data to read. This is an optional tag.
Contains: None
Attribute : None
Occurrence: Single
DataType: Numeric
TYPE Description: Holds ‘Full’ if complete profile data available in meter is to

be read or ’Partial’ if profile data since last reading is to be read Or
‘NO’ in case no data is to be read. This is an optional tag.
Contains: None
Attribute : None
Occurrence: Single
EVENTS Description: Holds ‘YES’ if events data is to be read and ‘NO if events
data is not to be read. This is an optional tag.
Contains: None
Attribute : None
Occurrence: Single
MRISCHEDULEFILEPATH Description: Specify the path (&name) of the schedule files to be

transferred into MRI. This is an optional tag.
Contains: None
Attribute : None
Occurrence: Single
RESULTFILE Description: Holds the name of file which contains consequence of the
operation.
Contains: None
Attribute : None
Format
Version 2.3
th
Page 37 of 107
Occurrence: Single
7.4 MRI Result File

The purpose of this file is to give result of prepare or download operation which can be used by CFW
for deciding next course of action. This file is the common file for all manufacturers. All manufacturers
will follow strict format of this file. The naming convention of result file is
INSTANCEID_MRIRESULTFILE.XML
This is an XML file for MRI Result with following structure.
<MRIRESULT>
<INSTANCE>
<INSTACEID>0001</INSTANCEID>
<DATETIME> DD-MM-YYYY, HH:MM </DATETIME>
<MODE>PREPARE/DOWNLOAD</MODE>
<OUTPUTFILE>
<FILENAME> C:\CFW\MANUFACTURER\ABC\MRI01012004.MRD</FILENAME>
</OUTPUTFILE>
<RESULT>0</RESULT>
</INSTANCE>
</ MRIRESULT >
7.4.1 Dictionary for MRIRESULT result file
Element Description
MRIRESULT Description: This is root node for prepare MRI or download data from
MRI result file
Contains: INSTANCE
Attribute : None
Occurrence: Single
DataType: N/A
INSTANCE Description: This node will appear for every instance result. If result of
the instance id is to be appended in same file then a new instance tag
shall be created.
Contains: DATETIME, RESULT, OUTPUTFILENAME,
INSTANCEID,MODE
Format
Version 2.3
th
Page 38 of 107
Is Contained by: MRIRESULT

Attribute : None
DataType: N/A
INSTANCEID Description: This contains the value of instance number which is a

running number for the request given by CFW to API. It should be four
digit number with ‘0’ appended in beginning if number is less then 4 digit.
Contains: NONE
Attribute : None
Occurrence: Single
DataType: Numeric
MODE Description: Hold values of Operation perform on MRI. The MODE have
two value
PREPARE
DOWNLOAD
Contains: None
Attribute : None
Occurrence: Single
DATETIME Description: Holds value of date time of MRI downloading/Prepare in dd-

mm-yyyy hh:mm:ss format
Contains: None
Attribute : None
Occurrence: Single
DataType: Date time in dd-mm-yyyy hh:mm:ss format
OUTPUTFILENAME Description: Holds value of manufacturer specific file made by reading

A. This node is created only for DOWLOAD Mode.
Contains: None
Attribute : None
Occurrence: Single
RESULT Description: Holds the value of result of prepare or downloads
Format
Version 2.3
th
Page 39 of 107
operation.
Contains: None
Attribute : None
Occurrence: Single
DataType: Numeric
7.4.2 Result Code-DOWNLOAD MODE
0 Success
1 Failure
2 Partial Success – On
multiple meter data
transfer all files are not
transferred.
7.4.3 Result Code-PREPARE MODE
0 Success
1 Failure
8 Converting to Common Format

This function enables CFW to convert meter data of different make to a common agreed format which
can be further used by billing and analysis software.
Format
Version 2.3
th
Page 40 of 107
User selects #1 CFC

the data to be
converted in
Common data Source file path #2 CFC
format Destination file path,
Seed
#3 CFC
Common
Data
ConvertToCDF
Format
(CDF)
Result file
Common
Common
format
framework
Converter
program (CFC) module
(API)
8.1 Responsibility of CFW for converting to CDF

1) Provide destination file path to API.
2) Decide further course of action based on result file
8.2 Responsibility of common format converter module (API3)

1) One instance of meter reading will generate one CDF file.
2) Converting the data from manufacturer specific format to common data format & shifting the
manufacturer specific file from ‘conversion pending folder’ to ‘conversion done folder’ after
successful conversion. In case of conversion fails API should move manufacturer specific format
data in conversion error folder.
3) One CDF file will be created for one meter reading operation.
4) Destination File Name will always be “Serial Date Time.XML” (such as Filename ABC00001
yyyymmdd hhmmss.XML). Date & time of creation of CDF file. Converted file should have
extension as .XML
5) Creating result file.
6) API shall take path/filenames and other parameter specified in configuration files provided to the
API and should not hardcode anything. Tag values written in this document are suggested paths
and are for example only
8.3 CFC Configuration file

This file contains the information which will be used by CDF converting module to convert the
manufacturer specific format file to CDF file. The structure of CFC configuration file is
<CFCAPI>
<SOURCEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONPENDING</SOURCEPATH>
<DONEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONDONE</DONEPATH>
Format
Version 2.3
th
Page 41 of 107
<ERRORPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONERROR</ERRORPATH>
<SCOPE CONVERTFILE=”ALL”[OR “SPECIFIC”]> </SCOPE>
<FILENAME>SOURCEFILENAME1</FILENAME>
<FILENAME>SOURCEFILENAME2</FILENAME>
</SCOPE> [IN CASE OF SPECIFIC]
<DESTPATH>C:\CFC\CDF</DESTPATH>
<SEED>A345B267</SEED>
<RESULTFILE> C:\CFC\MANUFACTURER\ABC\RESULT\CFCRESULT01.XML</RESULTFILE>.
</CFCAPI>
8.3.1 Dictionary for CFC configuration file
Element Descption
CFCAPI Description: This is root node for CFC configuration file

Contains: SOURCEPATH, SCOPE DESTPATH, SEED, RESULTFILE
Attribute : None
Occurrence: Single
DataType: N/A
Contains: NONE
Attribute : None
Occurrence: Single
DataType: Numeric
SOURCEPATH Description: Holds the value of the path from which CDF converter module
will take the manufacturer specific format files.
Contains: None
Is Contained by: CFCAPI
Attribute : None
Occurrence: Single
DONEPATH Description: Holds the value of the path to which CDF converter module
will move the manufacturer specific format files after successful conversion.
Contains: None
Format
Version 2.3
th
Page 42 of 107
Attribute : None
Occurrence: Single
ERRORPATH Description: Holds the value of the path to which CDF converter module
will move the manufacturer specific format files in case of failure.
Contains: None
Attribute : None
Occurrence: Single
SCOPE Description: Hold the information about the files which needs to be
converted into common format.
Contains: FILENAME
Attribute :
ConvertFile – If value of Convertfile attribute is “ALL” then all files in the
source path will be converted else if the value of convertfile attribute is
”SPECIFIC” then the fiels listed in FileName tags will be converted.
Occurrence: Single
DataType: N/A
FILENAME Description: Hold the name of files which needs to be converted into
common format.
Contains:
Attribute : None
DESTPATH Description: Holds the value of the path where CDF converter module will
create the CDF files.
Contains: None
Attribute : None
Occurrence: Single
SEED Description: Holds license key from which authenticator will be generated.
If seed tag is not in configuration file then no authenticator will be generated
in CDF file
Format
Version 2.3
th
Page 43 of 107
Contains: None
Attribute : None
Occurrence: Single
RESULTFILE Description: Holds name of the result file along with complete path.
Contains: None
Attribute : None
Occurrence: Single
8.4 Result file

The purpose of this file is to give result of reading operation which can be used by CFW for deciding
next course of action. This file is the common file for all manufacturers. All manufacturers will follow
strict format of this file. This is an XML file with following structure
<CFCRESULT>
<INSTANCE>
<CONVERTTIME>18-01-2005 12:35:00<CONVERTTIME>
<DATETIMEFORMAT>
<GENERAL>DD-MM-YYYY, HH:MM<GENERAL>
<D3> DD-MM, HH:MM </D3>
</DATETIMEFORMAT>
<CONVERT SERIAL=’ABC00001’ READTIME=’ 01-01-2005 12:00’ RESULT=”0”
OUTFILENAME=”ABC00001010120051200.XML”/>
<CONVERT SERIAL=’ABC00002’ READTIME=’ 01-01-2005 14:00’ RESULT=”1” OUTFILENAME=” ” />
</INSTANCE>
</CFCRESULT>
8.4.1 Dictionary for CFCResult file
Element Description
CFCRESULT Description: This is root node for CFCResult file

Contains: INSTANCE
Attribute : None
Occurrence: Single
Format
Version 2.3
th
Page 44 of 107
DataType: N/A
INSTANCE Description: This node will appear for every instance result. If result of the
instance id is to be appended in same file then a new instace tag shall be
created.
Contains: INSTANCEID ,CONVERTTIME, DATETIMEFORMAT, RESULT,
OUTPUTFILENAME
Is Contained by: CFCRESULT
Attribute : None
DataType: N/A
Contains: NONE
Attribute : None
Occurrence: Single
DataType: Numeric
CONVERTTIME Description: This contains the date and time when the manufacturer specific
file was converted into common XML format.
Contains: None
Attribute : None
DataType: N/A
DATETIMEFORMAT Description: Holds the tags containing value of date time format used during
conversion.
Contains: GENERAL , Tag specific date format such as D3
Attribute : None
Occurrence: Single
DataType: None
GENERAL Description: Holds the value of the date time format which is applicable for
entire XML document. Exception to this is defined in the next occurring tags.
In case year is not available from meter then ‘yyyy’ will be written. For
example 01-01-yyyy 00:00:00 is to be written.
Contains: none
Format
Version 2.3
th
Page 45 of 107
Is Contained by: DATETIMEFORMAT

Attribute : None
Occurrence: Single
DataType: String -- dd-mm-yyyy hh:mm:ss (This is an example not a rule)
Tag name such as Description: Holds the value of the date time format which is applicable for
Dn all the sub tags appearing under a particular tag. For rest of the tags date
format described under general is applicable.
Contains: none
Is Contained by: DATETIMEFORMAT
Attribute : None
Occurrence: Single
DataType: string -- dd-mm (This is an example not a rule)
CONVERT Description: This tag contains the information about whether the conversion
of particular meter reading was successful or failed. This will repeat for all
metering reading which is being converted.
Contains: None
Attribute :
SERIAL – Holds the value of serial number. Data type -String
DATETIME – Holds the value of date time of meter reading. Data Type –
Date in dd-mm-yyyy hh:mm
RESULT – Holds result for success or failure of the conversion on the meter
reading.
OUTFILENAME – Holds the name of output file generated after successful
conversion. In case conversion fails the value will be blank. The value will not
contain path as path is same as DESTPATH
DataType: N/A
8.4.2 Result Code
Result Code Error
0 Success
1 Failure
Format
Version 2.3
th
Page 46 of 107
9 Common Data Format (CDF)

9.1 Data Formats – Possible alternate
XML, CSV, Fixed format are different technologies available for creating such format. XML can be
used for generating the common format as XML is scalable and portable. Now a day’s most of popular
databases such as Oracle, MS SQL etc. provides support to direct query or generate XML format.
CSV and fixed format had problem in scalability as new parameter added may require change in
sequence of the parameter it contains which will further affect the software which use such format.
9.2 Proposed common file format

This file format only discuss about the tags related to electricity utility. This file format contains the
data in XML format. The data is divided into level and sublevels using the tags. Data file may or may
not contain tags depending on the data available from meter. Tags can be divided based on following
category.
9.2.1 Dictionary of common file format
Element Description
CDF Description: CDF tag is the root element and all data is
placed below this tag. Multiple utility data can come
underneath this tag.
Contains: UTILITYTYPE, AUTHENTICATOR
Attribute : None
Occurrence: Single
DataType: N/A
UTILITYTYPE Description: <UtilityType> is next level tag all other

tags which occurs below this tag will have their definition
based on code attribute of this tag. As the file can have
data from several utility therefore a code should be
there to distinguish the data in the file.
Contains: D1,D2,D3,D4,D5,D6,D7, AUTHENTICATOR
Is Contained by: CDF
Attribute : Code – This contains utility code i.e. Code
for electricity, gas, PSTN etc.
DataType: N/A
AUTHENTICATOR Description: This contains authenticator which is

function of data and seed. This is to ensure the integrity
of data. This tag is mandatory. In case authenticator is
not generated the blank tag is to be created
Contains: None
Is Contained by: CDF
Format
Version 2.3
th
Page 47 of 107
Attribute : None
Occurrence: Single
Data type – There are different type of data available for the utility. The definition and interpretation of
data type should be done with respect to Utility type code Standard codes for data type can be
defined up to D1000. Code above D1000 can be used for manufacturer specific data type. These
codes should be interpreted based on meter manufacturer.
D1 Description: This contains the general information

like serial number, commissioning information, type
information etc.
Contains: G1 to Gnn ( Up to the tags defined in
general information category
Is Contained by: UTILITYTYPE
Attribute : None
Occurrence: Single
DataType: N/A
D2 Description: This contains the information about

the electrical parameter persisting at the time of
meter reading. Effective time is to be derived from
‘Reading date time (meter)’ tag available in general
information category.
Contains: INSTPARAM
Attribute : None
Occurrence: Single
DataType: N/A
D3 Description: This contains the data for frozen

registers like main energy, TOD energy, demand,
TOD demand, CMD, TOD CMD, cumulative power
on off hours, power factor etc.
Contains: D3-00 to D3-nn (D3-nn denotes the tag
for history n)
Attribute : None
Occurrence: Single
DataType: N/A
D4 Description: This contains profile data for an

integration period. This data can have profile for
different electricity parameter.
Contains: DAYPROFILE
Format
Version 2.3
th
Page 48 of 107

Attribute : INTERVALPERIOD. Intervalperiod is
integration period of Load survey in minutes.
Occurrence: Single
DataType: N/A
D5 Description: This data contains the information of

various electrical abnormal events occurred at
meter.
Contains: EVENT
Attribute : None
Occurrence: Single
DataType: N/A
D6 Description: This data contains snapshot of

energy at a particular time.
Contains: SNAPSHOT
Attribute : None
Occurrence: Single
DataType: N/A
Description: This data contains information about
D7
“supply quality”. Supply quality is indicated by
duration in percentage or minutes for the
parameters persisting between specified
thresholds, such as
30% duration between (Vn – 10%) to Vn
20% duration between (Vn – 20%) to (Vn -10%)
Contains: DAILYDATA
Attribute : None
Occurrence: Single
DataType: N/A
D8 Description: Contains the information about

current meter settings.
Contains: APPCALC , LOADSURVEYSETTING,
MDSETTING
Attribute :
Format
Version 2.3
th
Page 49 of 107
Occurrence: Single
DataType:
D9 Description: Contains the information about when
meter was written externally to change settings with
occurrence date & time. This is also termed as
transaction with meter
Contains: TRANSACTION
Attribute :
Occurrence: Single
DataType:
D10 Description: Contains the information about the

flags which indicates the meter health.
Contains: FLAG
Attribute :
Occurrence: Single
DataType:
D11 Description: This contains value of Sag & Swell

count. This is hold by tag D11.
Contains: FLAG
Attribute :
Occurrence: Single
DataType:
D12
Description: This contains Power ON duration for
phases based on reset type ie. Daily / monthly.
This is hold by tag D12.
Contains: FLAG
Attribute :
Occurrence: Single
DataType:
General Information – This information comes under <D1> is used for general information. This
contains the information specific to the meter. Standard codes for general information can be defined
up to G1000. Code above G1000 can be used for manufacturer specific data type. These codes
should be interpreted based on meter manufacturer. Origin of data is not required.
Tags defined for general information parameters are
Format
Version 2.3
th
Page 50 of 107
G1
Description: Holds the value of meter serial number.
This is the metering device ID which uniquely identifies
the metering device.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G2
Description: Holds the value of date time stamp as per
meter at the time of reading.
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Date time. The format of date time is dd-mm-
yyyy hh:mm:ss
G3
Description: Holds the value of date time stamp as per
PC/MRI at the time of reading.
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
yyyy hh:mm:ss
G4
Description: Holds the value of date time stamp at the
time of MRI dumping to PC. The format of date time is
dd-mm-yyyy hh:mm:ss
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
yyyy hh:mm:ss
G7
Description: Holds the value of ratio of Programmed
PT Primary to Programmed PT secondary in meter.
Format
Version 2.3
th
Page 51 of 107
Origin of data: CFW/Manufacturer API

Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G8
Description: Holds the value of ratio of Programmed
CT Primary to Programmed CT secondary in meter.
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G9
Description: Holds the value of Programmed PT
Primary in meter. Value is always in Volts
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G10
Description: Holds the value of Programmed CT
Primary in meter. Value is always in Amps
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G11 Description: Holds the value of Programmed PT
Secondary in meter. Value is always in Volts
Contains: None
Is Contained by: D1
Attribute : None
Format
Version 2.3
th
Page 52 of 107
Occurrence: Single
DataType: Numeric
G12
Description: Holds the value of Programmed CT
Secondary in meter. Value is always in Amp
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G13 Description: Holds the value of Meter class. This is
class of accuracy of meter
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G14 Description: Holds the value of Meter rating. (5-6, 5-20)
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G15 Description: Holds the value of Meter type. Meter type
means HT(3ph-3W), HT(3ph-4W),LT(3ph-3W), LT(3ph-
4W), WC(3ph-4W),WC(1ph-2W)
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Alphanumeric. Can only take values defined
above.
G16 Description: Holds the value of Meter Scaling. Meter
scaling can have value Primary/Secondary.
Contains: None
Is Contained by: D1
Format
Version 2.3
th
Page 53 of 107
Attribute : None
Occurrence: Single
DataType: Can have value Primary or Secondary
G17 Description: Holds the value of Meter Program Name
including version number
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G19 Description: Holds the value of cumulative successful
meter reading count
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G20 Description: Holds the value of MD integration period
(Possible values - 1 mt, 2mts, 5 mts,15mts, 30mts,
60mts)
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G21 Description: Holds the value of additional information.
Origin of data: CFW
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G22
Description: Holds the value of manufacturer code and
name.
Contains: None
Is Contained by: D1
Format
Version 2.3
th
Page 54 of 107
Attribute : Code – Holds manufacturer code

Name – Holds manufacturer name
Occurrence: Single
DataType: (Code) – Alphanumeric
(Name) - Aplhanumeric
G23
Description: Holds the value of meter location.
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G24 Description: Holds the value of Meter collection status.

Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G25 Description: Holds the value of present configuration
Name
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G26 Description: Holds the value of previous configuration
Name
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G27 Description: Holds the value of Data Validation status.
This checks the integrity of data
Contains: None
Format
Version 2.3
th
Page 55 of 107
Is Contained by: D1
Attribute : None
Occurrence: Single
G30 Description: Holds the version number of
interoperability document to which the common format
complies
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: String. (For example 1.80)
G31 Description: Holds the version number of API from
which the common format is generated
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: String ( For example 1.1.0.1)
G32 Description: Holds the value of cumulative maximum
demand reset count.
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Numeric
G33 Description: Holds the value of MIOS membership ID
issued by MIOS forum and as received in reading result
file generated by Read API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Alpha Numeric
G34 Description: Holds the value of Meter range.
(Standard, long range)
Format
Version 2.3
th
Page 56 of 107
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Alpha
Instantaneous parameter – Instantaneous parameter data is hold under D2 tag. All data is provided
by manufacturer API
Description: Holds the code, value and unit of
INSTPARAM
instantaneous parameter
Contains: None
Is Contained by: D2
Attribute : CODE – Parameter code
VALUE – Value of the parameter
UNIT – Unit of the parameter
DataType: (CODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
Billing register data - Tag<D3> is used for Billing register information. There are many type Billing
registers supported in energy meters. The values of these registers are frozen at every billing.
Standard codes for cumulative data registers can be defined up to B1000. Code above B1000 can be
used for manufacturer specific data type. These codes should be interpreted based on meter
manufacturer.
D3-nn Description: <D3-nn> tag will appear for each bill date
where nn will be history number and 0 corresponds to
current (present) values, 01 corresponds to most recent
bill values and so on. <D3-00> indicates date & time of
reading the meter.
Contains: None
Is Contained by: D3
Attribute : DATETIME – Holds the value of frozen value
date time stamp (except for D3-00 which is described
above) (date will remain blank if meter does not store
MD reset date & time).
MECHANISM –Mechanism used to do MD reset. This
can take four values “Push Button”,
“Auto” (Bill date), “Command” (includes Tariff change),
“” (blank is to indicate MD reset is not performed)
Occurrence : One or more
DataType : DateTime .The format is dd-mm-yyyy
hh:mm. Mechanism - Alpha
B1 Description: Contains the information about time of

day(TOD) zone. This tag will appear only in D3-00 as
meter only sends TODZone currently applicable.
Contains: None
Format
Version 2.3
th
Page 57 of 107
Is Contained by: D3-nn

Attribute: TODZONE – time of day zone number. Zone
shall be represented by number. This time zone is
linked with all TOD registers
STARTTIME – Start time of time zone
ENDTIME – End time of time zone.
DataType: (STARTTIME) – DateTime .The format is
hh:mm
(ENDTIME)- DateTime . The format is
hh:mm
B2 Description: Contains the information about last MD

reset date. This tag will appear only if next history
exists. <B2> tag may not always contain same
DATETIME and MECHANISM as next D3-nn.
Contains: None
Attribute: DATETIME – Date time of MD reset
MECHANISM –Mechanism used to do MD
reset. This can take three values “Push Button”,
“Auto” , “Command”.
DataType: DATETIME .The format is dd-mm-yyyy
hh:mm
B3 Description: Contains data of Main Energy registers.

These registers contain cumulative value for 24 hours
energies. (irrespective of time of day). This tag will
repeat for all energies supported
Contains: None
Attribute : PARAMCODE – Energy parameter code
Value – Cumulative value of energy register.
Unit – Unit of the energy value i.e. k, M
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
B4 Description: Contains data of TOD energy registers.

These registers contain cumulative value for time zone
based energy registers. This tag will repeat for all
energies and all TOD registers supported
Contains: None
Format
Version 2.3
th
Page 58 of 107
Attribute: TOD – Time of register number. This is linked

with TODZone attribute of B1 tag.
TODZONE – 1,2 & so on or 0,1,2 & so on
PARAMCODE – Energy parameter code
VALUE – Cumulative value of energy
register.
UNIT – Unit of the energy value i.e. k, M
(VALUE) – Numeric
B5 Description: Contains data of fixed window Max

Demand registers. These registers contain value for 24
hours max demand. This tag will repeat for all energies
supported.
Contains: None
VALUE –Value of max demand register.
UNIT – Unit of the max demand value i.e. k,
M
OCCDATE – Max demand occurrence date
time stamp
(VALUE) – Numeric
(OCCDATE) - DateTime . The format is dd-
mm-yyyy hh:mm
B6 Description: Contains data of fixed window TOD Max

Demand registers. These registers contain value for
time zone based demand registers. This tag will repeat
for all energies and all TOD registers supported
Contains: None
Attribute : TOD – TOD register number. This is linked
VALUE –Value of TOD max demand
register.
UNIT – Unit of the TOD max demand value
i.e. k, M
time stamp
Format
Version 2.3
th
Page 59 of 107

(VALUE) – Numeric
mm-yyyy hh:mm
B7 Description: Contains data of cumulative max demand

(CMD) registers. These registers contain cumulative
value for 24 hours max demand. This tag will repeat for
all energies supported
Contains: None
VALUE – Cumulative value of CMD register.

(VALUE) – Numeric
B8 Description: Contains data of TOD CMD registers.

These registers contain value for time zone based CMD
registers. This tag will repeat for all energies and all
TOD registers supported
Contains: None
Attribute: TOD – TOD register number. This is linked
with TODZONE attribute of B1 tag.
VALUE – Cumulative value of TOD CMD
register.
(VALUE) – Numeric
B9 Description: Contains data of average power factor.

This is for 24 hours.
Contains: None
Attribute: PARAMCODE – Power factor parameter
Code
VALUE – Value of power factor.
Format
Version 2.3
th
Page 60 of 107
(VALUE) – Numeric
B10 Description: Contains data of TOD average power

factor. This contains value for time zone based power
factor. The tag will repeat for all TOD registers
supported.
Contains: None
Attribute: TOD – TOD register number. This is linked
with TODZONE attribute of B1 tag.
PARAMCODE – Power factor parameter
Code
VALUE – Value of power factor.
DataType: (TOD) – Numeric
(PARAMCODE) – Alphanumeric
(VALUE) - Numeric
B11 Description: Contains data of Power On duration time

since meter manufactured.
Contains: None
Attribute: VALUE – Value of Power On duration. The
value will be in minutes
DataType: VALUE - Numeric
B12 Description: Contains data of Power Off duration time

since meter manufactured.
Contains: None
Attribute: VALUE – Value of Power Off duration. The
value will in minutes
DataType: VALUE -Numeric
B13 Description: Contains data of cumulative tamper count.

Contains: None
Attribute: VALUE – Value of cumulative tamper count.
DataType: VALUE -Numeric
Format
Version 2.3
th
Page 61 of 107
B14 Description: Contains data of sliding window Max

Demand registers. These registers contain value for 24
hours max demand. This tag will repeat for all energies
supported.
Contains: None
VALUE – Cumulative value of max demand
register.
UNIT – Unit of the max demand value i.e. k,
M
time stamp
(VALUE) – Numeric
mm-yyyy hh:mm
B15 Description: Contains data of sliding window TOD Max

Demand registers. These registers contain value for
time zone based demand registers. This tag will repeat
for all energies and all TOD registers supported
Contains: None
Attribute : TOD – TOD register number. This is linked
VALUE – Cumulative value of TOD max
demand register.
UNIT – Unit of the TOD max demand value
i.e. k, M
time stamp
(VALUE) – Numeric
mm-yyyy hh:mm
Description: Contains name of Tariff file

B16
Contains: None
Attribute :None
Format
Version 2.3
th
Page 62 of 107

Data Type:– Alphanumeric
B17
Description: This contains Billing period Power on
duration Values.
Contains: Billing Data
Is Contained by: D3-nn.
Attribute: VALUE
Occurrence: Single
Data Type: Minutes
B18
Description: This contains Energy Crossover
Counts.
Is Contained by: D3-00.
Attribute: 2-Attributes.
PARAMCODE -Hold the code of the Energy.
COUNT-Holds the count of the particular Energy
crossover.
Occurrence: One or More
Data Type: N/A
B19 Description: Contains data of Main Energy registers

during Magnetic Tamper. These registers contain
cumulative value for 24 hours energies. (Irrespective of
time of day). This tag will repeat for all energies
supported.
Contains: None
Value – Cumulative value of energy register
during Magnetic Tamper.
Unit – Unit of the energy value i.e. k, M
Data Type: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
B20 Description: This contains event count between two

reset. This tag will repeat for all event supported.
Is Contained by: D3-01 to D3-nn.
Format
Version 2.3
th
Page 63 of 107
Attribute: 2-Attributes.
EVENTCODE-Holds the code of the event.
COUNT-Holds the count of the Tamper event occurred.
Data Type: N/A
Load Profile data – Load Profile data is value of the parameter for defined integration period for
specified days. Tag D4 is used to hold profile data.
Description: Contains every day data. This tag will
DAYPROFILE
repeat for all date for which load profile is available.
Contains: IP
Is Contained by: D4
Attribute: DATE – Date of the profile .
DataType: DATE - The format is dd-mm-yyyy
IP Description: Contains the value of all parameters and

flags for the IP. This tag will repeat for all IP’s
Contains: IFLAG, PARAMETER
Is Contained by: DAYPROFILE
Attribute: Interval – Interval number
DataType: (INTERVAL ) – Numeric
IFLAG Description: Contains code and value of the flag

applicable for the integration period irrespective of
parameter. This tag will repeat for all flags
Contains: None
Is Contained by: IP
Attribute: CODE – Code of the flag
VALUE – Value of the flag
(VALUE) – Numeric
PARAMETER Description: Contains code and value of the

parameter. This tag will repeat for all parameters.
Contains: PFlag
Is Contained by: IP
Attribute: PARAMCODE – Parameter code
VALUE – Parameter value
UNIT – Unit of parameter value
Format
Version 2.3
th
Page 64 of 107

(VALUE) – Numeric
PFLAG Description: Contains code and value of the flag

applicable only for that interval & applicable only for that
parameter . This tag will repeat for all flags
Contains: None
Is Contained by: Parameter
Attribute: CODE – Code the flag
VALUE – Value of the flag
(VALUE) – Numeric
Events data - <D5> tag is used events data information. Events data contains events code and
sometimes snapshot of the electrical parameters when the event occurred.
EVENT Description: Contains code, time and status of the
events. This tag will repeat for all events.
Contains: SNAPSHOT
Is Contained by: D5
Attribute: CODE – Code the events
TIME –Time of the event. If time does not
come then blank should be used as value.
DURATION – This attribute is optional and
indicate the duration of event. This attribute can come
only when status attribute had value ‘1’.
STATUS – ‘0’ if event had occurred and ‘1’ if
event had restored.
(TIME) – DateTime . The format is dd-mm-
yyyy hh:mm
(DURATION) – The format is
DDD:hh:mm:ss
(STATUS)- Can only take values defined
above
SNAPSHOT Description: Contains parameter code and value of

parameter at the time of event. This tag will repeat for all
parameters whose snapshot is supported.
Contains: None
Is Contained by: EVENT
VALUE – Value of parameter
UNIT – Unit of parameter value.
Format
Version 2.3
th
Page 65 of 107

(VALUE) –Numeric
(UNIT)- Alphanumeric
CUMULATIVE Description: Contains data of cumulative count &

cumulative duration for event
Contains: None
Is Contained by: D5
Attribute: CODE – Event code. ‘0’ will be used for code
if it is cumulative count for all events
VALUE – Value of event count.
CUMULATIVETIME – Value in ddd:hh:mm:ss
(VALUE) –Numeric
(CUMULATIVETIME)- ddd:hh:mm:ss
Daily energy register snapshot - This contains value of Daily energy snapshot. This is hold by tag
D6. Typical usage is for logging mid night energy snapshot
SNAPSHOT Description: Contains the value for the date. This tag
will repeat for all dates.
Contains: REGISTER
Is Contained by: D6
Attribute: DATETIME – Date time stamp of the
snapshot
DataType: DATETIME . The format is dd-mm-yyyy
hh:mm:ss
REGISTER Description: Contains the value for the energy register.

This tag will repeat for all energies supported.
Contains: None
Is Contained by: SNAPSHOT
Attribute: PARAMCODE – Energy parameter code
VALUE – Value of energy parameter
UNIT – Unit of energy parameter value.
(VALUE) –Numeric
(UNIT)- Alphanumeric
Daily duration indicator for the parameter between the specified threshold - This data contains
Format
Version 2.3
th
Page 66 of 107
information about “supply quality”. Supply quality is duration in percentage or minutes for the
parameters persisting between specified thresholds, such as
30% duration between (Vn – 10%) to Vn
20% duration between (Vn – 20%) to (Vn -10%)
This is hold by tag D7.
DAILYDATA Description: Contains the value for the date. This tag
Contains: REGISTER
Is Contained by: D7
Attribute: DATE – Date of the data i
DataType: DATE . The format is dd-mm-yyyy
REGISTER Description: Contains the value for the date. This tag
Contains: None
Is Contained by: DAILYDATA
STARTLIMIT – Start limit of threshold
ENDLIMIT – End limit of threshold
VALUE – Value of the data
UNIT – Unit of value
Note: 0 limit indicates nominal value of the parameter.
Positive value of limit indicates above nominal and
negative value indicates below nominal.
(STARTLIMIT) –Numeric
(ENDLIMIT)- Numeric
(VALUE) - Numeric
(UNIT) - Alphanumeric
Current Meter settings : This data contains information about the current setting in the meter.
These settings changes less frequently. This is hold by D8.
APPCALC Description: Holds the value on which apparent
calculation is based. The possible values are
0 for Lag and
1 for Lag+Lead
Contains: None
Is Contained by: D8
Attribute: None
Occurrence: One
DataType: 0 or 1
MDRESETSETTING Description: Holds the value of mechanism by which

MD reset can be done in the meter. The possible values
are
Format
Version 2.3
th
Page 67 of 107
0 for Auto reset and

1 for Manual reset
2. for both
Contains: None
Is Contained by: D8
Attribute: None
Occurrence: One
DataType: 0, 1 or 2
LOADSURVEYSETTING Description: Holds the value for the load survey setting
in meter. That is parameter which are configured in load
survey and integration period used in load survey
Contains: PARAM
Is Contained by: D8
Attribute: INTERVALPERIOD- Integration period used
for load survey
Occurrence: One
DataType:
PARAM Description: Holds the value of parameter code which
are configured in the load survey. This tag repeats for all
parameter in load survey.
Contains: None
Is Contained by: LOADSURVEYSETTING
Attribute: None
DataType: PARAMETER CODE
MDSETTING Description: Holds the value for the max demand
setting in meter. That is parameter which are configured
for max demand and integration period used for max
demand calculation
Contains: PARAM
Is Contained by: D8
Attribute: INTERVALPERIOD - Integration period used
for max demand calculation.
Occurrence: One
DataType: INTERVALPERIOD - Integer
PARAM Description: Holds the value of parameter code which
are configured for max demand. This tag repeats for all
parameter in max demand.
Contains: None
Is Contained by: MDSETTING
Attribute: None
Format
Version 2.3
th
Page 68 of 107

DataType: PARAMETER CODE
Transaction - <D9> tag is used for transaction information. The transactions are desired changes
done to meter intentionally by utility through some authentication mechanism. Meter also log the
change and date and time of change
TRANSACTION Description: Contains code, time and status of the
events. This tag will repeat for all transaction.
Contains: None
Is Contained by: D9
Attribute: CODE – Code of the transaction
TIME –Time of the transaction
(TIME) – DateTime . The format is dd-mm-
yyyy hh:mm
Flags - <D10> tag is used for meter health information. This information can be used to find out faulty
meters.
FLAG Description: Contains code and value of flag. This tag
will repeat for all flags.
Contains: None
Is Contained by: D10
Attribute: CODE – Code of the transaction
VALUE – 0 for false and 1 for true
(VALUE) – 0,1
Sag & Swell information- This contains value of Sag & Swell count. This is hold by tag D11.
DATA Description: Contains the value for the date. This tag
Contains: SAGSWELL
snapshot
hh:mm:ss
SAGSWELL Description: Contains the value for Sag & Swell count.
This tag will repeat for all Phases supported.
Contains: None
Is Contained by: DATA
Attribute: CODE – parameter code
Format
Version 2.3
th
Page 69 of 107
COUNT -- Value of Sag/Swell count.

DataType: (COUNT) - Numeric
Phase Power-ON time- This contains Power ON duration for phases based on reset type ie.
Daily / monthly. This is kept by tag D12.
RESET TYPE Description: It contains the type of automatic reset
which can be daily or monthly.
Attribute: 1 Represents daily & 2 Represents monthly.
DataTYpe: Numeric
ROOSTERDATA Description: Contains the value for the date. This tag
Contains: ROOSTERING
snapshot
hh:mm:ss
ROOSTERING Description: Contains the value for Phase power on

duration. This tag will repeat for number of phases.
Contains: None
Is Contained by: DATA
Attribute: CODE – Phase number code(1,2,3
representing R,Y,B phase respectively)
DURATION -- Value of Power-ON time for
previous day / month
DataType: (DURATION) –DD:HH:MM
9.2.2 CDF
CDF is root tag for the common data format file. All tags will come below this tag. Structure of the file
will look like
VERSION <?XML = “VERSION = “1.0” ENCODING=“UTF-8” STANDALONE = “YES”?>

<CDF>
<UTILITYTYPE CODE =”1”>
<D1>
…..
</D1>
Format
Version 2.3
th
Page 70 of 107
…….
……
</DN>
</UTILITYTYPE>
<AUTHENTICATOR>A123DCA889FEDBC</AUTHENTICATOR>
</CDF>
9.2.3 Utility Type

Utility type is second level tag having attribute code. Each utility is be assigned unique code. Such as
Code Utility
1 Electricity
2 Telephone
3 Cell phones
4 Gas
Now if the attribute code is for electricity then definition and meaning of all the tags below this tag
should be taken from the Electricity utility coding standards.
9.2.4 General Information

Tag <D1> is used for general information. This contains the information specific to the meter. The
General information tag D1 will look like
<D1>
<G1>S0000001</G1>
<G2>01/01/2004 10:00:00</G2>
<G3>01/01/2004 10:01:00</G3>
<G4>01/01/2004 12:01:00</G4>
<G5>100</G5>
<G6>240</G6>
<G7>100</G7>
<G8>240</G8>
</D1>
Manufacturer Type code

A code should be defined for each meter manufacturer.<ManufacturerType> tag is used for it. The
code attribute can take manufacturer code. Manufacturer can also provide manufacture specific data
in manufacturer specific codes category. Codes can be defined as
Code Meter Manufacturer
1 SML.
2 Elster
3 L&T
4 ….
Membership ID
Purpose of membership ID: To ensure that APIs are not freely exchanged in the market. Every API
will self identify to whom the API was issued.
Tracking
From where one can read membership ID? The membership ID will be embedded within API.
o The membership ID will have to be read from configuration file for API1 & from CDF
file for API3.
Where is the output available? The
• For API1 – The membership ID will appear in Result file.
Format
Version 2.3
th
Page 71 of 107
• For API3 – The membership ID will appear in xml tag labelled as

<membershipID>MM001</memebrshipID>
An ID will be issued during registration process (Web Site /Manual) to the party who is seeking for
membership of MIOS The seeking party may be meter manufacturer, Utility or any third party.
The Membership ID format would be as following:
Length = 5 Alphanumeric characters
In which first two digits are reserved for character ‘A’ to Z’’ and rest 3 are reserved for numbers
ranging from 000 to 999.
Initial Membership ID Member Type

MM MM001 for Secure, Meter Manufacturer
MM002 for L&T etc.
UT UT001 for utility X X=MSEB
TP TP001 for Third Party XX=IBM
name ‘XX’
9.2.5 Instantaneous parameter

Tag <D2> can be used for instantaneous parameters. Parameter code can be made tags. It will have
two tags value and unit. The instantaneous parameter information tag D2 will look like
<D2>
<INSTPARAM CODE=”P1-1-1-1-0” VALUE=”240.34” UNIT=”V” />
<INSTPARAM CODE=”P2-1-1-1-0” VALUE=”40.34” UNIT=”A” />
</D2>
9.2.6 Billing registers data

Tag<D3> is used for Billing register information. There are many type Billing registers supported in
energy meters. <D3-nn> tag will appear for each bill date where nn will be history number and 0
corresponds to current (present) values, 01 corresponds to most recent bill values and so on.
Example 1
Data under <D3> will look like
<D3>
<D3-00 DATETIME="03-08-2003 10:00" MECHANISM=””>
<B1 TODZONE="1" STARTTIME="00:00" ENDTIME="7:00"/>
<B2 DATETIME=”01-07-2003 00:00” MECHANISM=”AUTO”/>
<B3 PARAMCODE="P7-1-5-1-0" VALUE="2000" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B5 PARAMCODE="P7-4-5-1-0" VALUE="500" OCCDATE="06-07-2003 14:45" UNIT="K"/>
<B5 PARAMCODE="P7-6-5-1-0" VALUE="700" OCCDATE="20-07-2003 13:15" UNIT="K"/>
<B6 TOD=”1” PARAMCODE="P7-6-5-1-0" VALUE="700" OCCDATE="20-07-2003 13:15"
UNIT="K"/>
<B6 TOD=”2” PARAMCODE="P7-6-5-1-0" VALUE="650" OCCDATE="19-07-2003 12:15"
Format
Version 2.3
th
Page 72 of 107
UNIT="K"/>
<B8 TOD=“1” PARAMCODE="P7-4-5-1-0" VALUE="900" UNIT="K"/>
<B9 PARAMCODE= “P4-4-4-1-0” VALUE="0.9" />
<B10 TOD="1" PARAMCODE= “P4-4-4-1-0” VALUE="0.8" />
<B10 TOD="2" PARAMCODE= “P4-4-4-1-0” VALUE="0.8" />
<B11 VALUE=”123542”/>
<B12 VALUE=”4334”/>
<B16 VALUE=”TARIFFNAME”/>
</D3-00>
<D3-01 DATETIME="01-07-2003 00:00" MECHANISM=”AUTO”>
<B2 DATETIME=”21-06-2003 10:00” MECHANISM=”COMMAND”/>
<B5 PARAMCODE="P7-1-5-1-0" VALUE="400" OCCURRENCEDATE="06-06-2003 14:45" UNIT="K"/>
<B5 PARAMCODE="P7-3-5-1-0" VALUE="600" OCCURENCEDATE="20-06-2003 13:15" UNIT="K"/>
<B6 TOD=”1” PARAMCODE="P7-3-5-1-0" VALUE="700" OCCURENCEDATE="20-07-2003 13:15"
UNIT="K"/>
UNIT="K"/>
<B9 PARAMCODE="P4-4-4-0-0" VALUE="0.9" />
<B10 TOD="1" VALUE="0.8" />
<B11 VALUE=”123542”/>
<B12 VALUE=”4334”/>
</D3-01>
<D3-02 DATETIME="01-06-2003 00:00" MECHANISM=”AUTO”>
<B5 PARAMCODE="P7-1-5-1-0" VALUE="400" OCCURRENCEDATE="06-06-2003 14:45" UNIT="K"/>
<B5 PARAMCODE="P7-3-5-1-0" VALUE="600" OCCURENCEDATE="20-06-2003 13:15" UNIT="K"/>
UNIT="K"/>
UNIT="K"/>
<B9 PARAMCODE="P4-4-4-0-0" VALUE="0.9" />
<B10 TOD="1" VALUE="0.8" />
<B11 VALUE=”123542”/>
<B12 VALUE=”4334”/>
</D3-02>
</D3>
Example 2
<D3>
<D3-00 DATETIME="27-08-2008 11:34" MECHANISM="">
<B17 VALUE = "41000"/>
Format
Version 2.3
th
Page 73 of 107
</D3-00>
<B17 VALUE = "40000"/>
</D3-01>
</D3>
Example 3
<D3>
<B18 PARAMCODE ="P7-6-5-2-0" COUNT="2"/>
<B18 PARAMCODE ="P7-6-5-3-0" COUNT="2"/>
</D3-00>
</D3>
Example 4
<D3>
<B19 PARAMCODE="P7-6-5-2-0" VALUE="3456.67" UNIT="k"/>
</D3-00>
</D3-01>
</D3>
Example 5
<D3>
<B20 EVENTCODE ="2" COUNT="2"/>
<B20 EVENTCODE ="11" COUNT="2"/>
</D3-01>
</D3>
9.2.7 Profile data

Profile data is value of the parameter for defined integration period for some days. Either demand or
energy parameter can be given in load survey as the other can be derived ( i.e Demand = Energy *
60/Integration period in mins)
• IFlag – IFlag is interval specific status indicator which indicates occurrence of specific
electrical conditions such as power fail, unbalance, PTMiss. IFlag can only have Boolean
value (0 or 1.). The following table list the flag and their code
Condition Code
Power fail 101
Current Unbalance 102
Loss of voltage (for any 103
phase)
Voltage unbalance 104
Invalid Interval 105
Current Failure 106
Format
Version 2.3
th
Page 74 of 107
Low PF 107
Current Reversal 108
Under Voltage 109
Over Voltage 110
Under Current 111
Over Current 112
Current Bypass 113
RTC Advance 114
RTC Retard 115
Magnetic Tamper 116
Neutral Disturbance 117
• PFlag – Pflag is parameter specific status indicator which indicates validity/invalidity of the
value of a parameter such as variable overflow. Pflag can only have Boolean value (0 or
1).The following table list the flag and their code
Condition Code
Variable Overflow 1
Any profile data <D4> will look like
<D4 INTERVALPERIOD=”15”>
<DAYPROFILE DATE=”01-07-2003” >
<IP INTERVAL =0 >
<PARAMETER PARAMCODE=”P7-1-5-1-0” VALUE=”0” UNIT=”K”>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”0” UNIT=”K”/>
<IP INTERVAL =1 >

</IP>
<IP INTERVAL =5 >
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”113” UNIT=”V”/>
</IP>
….
…
</DAYPROFILE>
…..
….
</DAYPROFILE>
<DAYPROFILE DATE=”01/07/2003” >
<IP INTERVAL =1 >
<IFLAG CODE=’101’ VALUE=’1’/>
<PFLAG CODE=’0’ VALUE=’1’/>
</PARAMETER>
</IP>
<IP INTERVAL =2 >
<PFLAG CODE=’1’ VALUE=’1’/>
</PARAMETER>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”113” UNIT=”V”/>
</IP>
….
Format
Version 2.3
th
Page 75 of 107
…
</DAYPROFILE>
<DAYPROFILE DATE=”02/07/2003” >
…..
….
</DAYPROFILE>
</D4>
Max-Min load profile:

“<IP Interval=0>” shall be treated - for whole day consumption (24 hours energy value)
EXAMPLE:
<IP INTERVAL =0 > WHOLE DAY CONSUMPTION

<PARAMETER PARAMCODE="P7-1-18-0-0" VALUE="150" UNIT="K" />
<PARAMETER PARAMCODE="P7-3-18-0-0" VALUE="150" UNIT="K" />
</IP>
<IP INTERVAL =7 >
<PARAMETER PARAMCODE=” P7-4-18-0-4” VALUE=”MAXIMUM VALUE” UNIT=”K”>
</IP>
<IP INTERVAL =15 >
<PARAMETER PARAMCODE=” P7-4-18-0-5” VALUE=”MINIMUM VALUE” UNIT=”K”>
</IP>
<IP INTERVAL =3 >
<PARAMETER PARAMCODE=” P1-2-1-2-0” VALUE=”MAXIMUM VALUE” UNIT=”K”>
</IP>
<IP INTERVAL =21 >
<PARAMETER PARAMCODE=” P1-2-1-3-0” VALUE=”MINIMUM VALUE” UNIT=”K”>
</IP>
….
…
</DAYPROFILE>
</D4>
9.2.8 Events Data

<D5> tag is used events data information. Events data contains events code and sometimes snapshot
of the electrical parameters when the event occurred.
• Codes can be defined for each event such as
Code Events
1 R phase potential missing

2 Y phase potential missing
3 B phase potential missing
4 R phase CT reversed
5 Y phase CT reversed
6 B phase CT reversed
7 Load imbalance
8 Load unbalance – R phase
9 Load unbalance – Y phase
10 Load unbalance – B phase
11 Overload(Current)
12 Low power factor
13 Power failed
14 Unbalance voltage
15 Unbalance voltage – R phase
16 Unbalance voltage – Y phase
17 Unbalance voltage – B phase
Format
Version 2.3
th
Page 76 of 107
18 Invalid voltage inputs

19 CT short
20 CT short – R phase
21 CT short – Y phase
22 CT short – B phase
23 CT open
24 CT open – R phase
25 CT open – Y phase
26 CT open – B phase
27 Magnet
28 Neutral disturbance
29 High neutral current
30 R-Ph current missing
31 Y-Ph current missing
32 B-Ph current missing
33 High voltage
34 High voltage – R phase
35 High voltage – Y phase
36 High voltage – B phase
37 Over load (current) – R phase
38 Over load (current) – Y phase
39 Over load (current) – B phase
40 Low voltage – R phase
41 Low voltage – Y phase
42 Low voltage – B phase
43 Low current – R phase
44 Low current – Y phase
45 Low current – B phase
46 Power reversed – R phase
47 Power reversed – Y phase
48 Power reversed – B phase
49 Power failed in the presence of magnet
50 High second harmonics
51 High total harmonics distortion current
52 Low PF – R Phase
53 Low PF – Y Phase
54 Low PF – B Phase
55 Potential Missing
56 Current Reversal
57 Current Missing
58 Low Voltage
59 Low Current
60 Meter Cover Open
61 RTC Change
62 Energy Corruption
63 Gain Angle Corruption
64 Power Reversal
65 Abnormal Restart Detected
Format
Version 2.3
th
Page 77 of 107
66 Invalid Phase Association

67 Over Load (Apparent Power)
68 Under Load (Apparent Power)
69 Short Term Over Load (Apparent Power)
70 Supply Status-FULL
71 Supply Status-Partial
Standard codes for events can be defined up to 1000. Code above 1000 can be used for
manufacturer specific data type. These codes should be interpreted based on meter manufacturer.
The D5 tag will look like

<D5>
<EVENT CODE="2" TIME="12-07-2003 10:23:20" STATUS="0">
<SNAPSHOT PARAMCODE="P1-1-1-1-0" VALUE="240" UNIT="V"/>
<SNAPSHOT PARAMCODE="P1-1-3-1-0" VALUE="300" UNIT='V'/>
<SNAPSHOT PARAMCODE="P2-1-1-1-0" VALUE="10.2" UNIT="A"/>
<SNAPSHOT PARAMCODE="P2-1-2-1-0" VALUE="10" UNIT="A"/>
<SNAPSHOT PARAMCODE="P2-1-3-1-0" VALUE="5" UNIT='A'/>
</EVENT>
<EVENT CODE="2" TIME="15-07-2003 11:23:20" STATUS="1">
</EVENT>
<EVENT CODE="11" TIME="16-07-2003 19:23 :20" STATUS="0""/>
<EVENT CODE="11" TIME="17-07-2003 23:12" STATUS="0""/>
<EVENT CODE="5" TIME="18-07-2003 11:23" STATUS="0"">
</EVENT>
<CUMULATIVE CODE=1 VALUE=453 CUMULATIVETIME =033:22:58 :35/>
<CUMULATIVE CODE=2 VALUE=54 CUMULATIVETIME=033:22:58 :35/>
</D5>
In case TIME attribute value is not supported by meters at the time of restoration ( STATUS=’1’) then
event tag will look like
<EVENT CODE="2" TIME="" DURATION=003:01:00:00 STATUS="1">
In case TIME attribute value and DURATION both are supported by meter at the time of restoration (
STATUS=’1’) then event tag will look like
<EVENT CODE="2" TIME="15-07-2003 11:23:20" DURATION=003:01:00:00 STATUS="1">
9.2.9 Daily energy snapshot

This contains value of Daily energy snapshot.
•
Any <D6> tag will look like

<D6>
<SNAPSHOT DATE="29-07-2003 00:00">
<REGISTER PARAMCODE="P7-1-5-1-0" VALUE="500" UNIT="K"/>
Format
Version 2.3
th
Page 78 of 107
<REGISTER PARAMCODE="P7-2-1-1-0" VALUE="200" UNIT="K"/>

</SNAPSHOT>
</D6>
9.2.10 Duration data within thresholds

<D7>
<DAILYDATA DATE="29-07-2003 ">
<REGISTER PARAMCODE="P1-1-1-1-0" VALUE="3" UNIT="HOURS" STARTLIMIT="0" ENDLIMIT=”-10”/>
<REGISTER PARAMCODE="P1-1-1-1-0" VALUE="7" UNIT="HOURS" STARTLIMIT="0" ENDLIMIT=”10”/>
<REGISTER PARAMCODE="P1-1-2-1-0" VALUE="5" UNIT="HOURS" STARTLIMIT="10" ENDLIMIT=”20”
/>
</ DAILYDATA >
</D7>
The above example shows that R- phase voltage had remained 3 hours between nominal to -10%
band, remained 7 hours between nominal to +10% band and had remained 5 hours between +10%
and +20% of voltage band
9.2.11 Current meter settings

These data contains the information about the current meter setting. The typical example for the data
will look like
<D8>
<APPCALC>0</APPCALC>
<LOADSURVEYSETTING INTERVALPERIOD=15>
<PARAM> P7-4-5-1-0</PARAM>
</LOADSURVEYSETTING >
<MDRESETSETTING> 2</MDRESETSETTING>
<MDSETTING INTERVALPERIOD=30>
</MDSETTING >
</D8>
9.2.12 Transaction Data

<D9> tag is used transaction data information. Transaction contains the code of the transaction and
when the transaction was performed. Transaction for intentional configuration changes in the meter.
Code Transaction
1 Externally written - single / multiple changes

2 Load survey configured
3 Time changed
4 Max demand reset human initiated (such as
PB, PC / MRI command) – Auto reset will
not get reflected here
5 Event log reset
6 TOD definition changed
7 Apparent energy calculation definition
changed
8. Max Demand settings changed (parameter
changed or integration period changed)
9 Max demand reset setting changed (type
Push button, command, auto reset &
Format
Version 2.3
th
Page 79 of 107
combination thereof or auto reset date time

changed)
10 Time before time change. For this date time
attribute will contain the value of time before
time changed
11 Time after time change. For this date time

attribute will contain the value of time after
time changed
12 CT Reprogrammed
13 PT Reprogrammed
14 Display Programmed
15 Season Profile Programmed
16 Festival Days Programmed
17 Meter Programmed
18 Reset Info changed
19 KVAh configuration / Direction (Uni / Bi-
directional ) Programmed
20 Tariff download- tariff definition
21 Tariff download- energy definition
22 Tariff download- bill dates
23 Meter Security- Unlock
24 Meter Security- Lock
25 Meter Security- Password changed
26 Configuration related transactions- Limit for
Underload/Overload/Short term overload
27 Configuration transactions- Persistence
time
28 Configuration transactions- Load survey
configuration
29 Configuration transactions- Display
parameter change
30 Tamper Reset
Standard codes for transaction can be defined up to 1000. Code above 1000 can be used for
manufacturer specific data type. These codes should be interpreted based on meter manufacturer.
<D9>
<TRANSACTION CODE=5 DATETIME=21/04/2006 12:10/>
</D9>
9.2.13 Flag Data

<D10> tag is used flag information. Flag contains the information about meter health. It contains the
code of the parameter and value attribute indicating the state of that parameter
Format
Version 2.3
th
Page 80 of 107
Code Transaction
1 Real Time Clock(RTC) failure (bad battery, bad

RTC)
2 Memory failure
<D10>
<FLAG CODE=1 VALUE=0 />
<FLAG CODE=2 VALUE=1 />
</D10>
<D11> (CODE 1,2,3 IS REPRESENTING R,Y,B PHASE RESPECTIVELY)

<DATA DATETIME="06-08-2008 00:00:00">
<SAG CODE=”1” COUNT=”21”/>
<SWELL CODE=”1” COUNT=”25”/>
</DATA>
</D11>

<D12 RESETTYPE = "1" >
<ROOSTERDATA DATETIME = "01-08-2008 00:00:00">
<ROOSTERING CODE = "1" DURATION = "00:21:50"/>
</ ROOSTERDATA >
</D12>
9.3 Parameter codes

Parameter code is derived as ParamterTypeCode-Qualifier1-Qualifier2-Qualifier3-Qualifier4. If
some qualifier is not applicable then 0 shall be used. Coding scheme for generating parameter code is
described below. List of all the parameter with parameter code is available in glossary.
9.3.1 Parameter type

Parameter type is type of parameter. Codes assigned to each parameter & their respective admissible
units are mentioned. Please note that 11 kV is to be mentioned as 11000 V.
Code Parameter Possible units
P1 Voltage Volt (V)
P2 Current Ampere (A)
P3 Power Kilo (k), Mega (M)
P4 Power factor Unit less
P5 Voltage Angles Degree (D)
P6 Power factor Degree (D)
Angles (angle
between voltage &
current)
P7 Energy/Demand Kilo (k), Mega (M),
Giga (G)
P8 Phase Sequence Unit less
P9 Frequency Hertz (Hz)
P10 Current angle Degree (D)
P11 Duration Minutes(Min)
Format
Version 2.3
th
Page 81 of 107
Standard codes for parameters can be defined up to P1000. Code starting with Mn (M1, M2, M3 & so
on) can be used for manufacturer specific data type. These codes should be interpreted based on
meter manufacturer code.
9.3.2 Voltage
Voltage codes can be derived from following qualifier.
Qualifier1
Qualifier1 denotes the type of value. Table below defines the code.
Code Description
1 Phase to phase
2 Phase to neutral
Qualifier2
Qualifier2 denotes phase. Table below defines the code
Code Description
1 R- phase
2 Y-phase
3 B-phase
4 R-Y phase
5 B-Y phase
6 R-B phase
7 System(All phases)
Qualifier3
Qualifier3 denotes whether it is instantaneous, maximum, minimum or average voltage. These values
are over a period. Table below defines the code
Code Description
1 Instantaneous
2 Maximum for defined duration
3 Minimum for defined duration
4 Average for defined duration
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
Example
Voltage parameters code will be generated as P1-<Qualifier1>-<Qualifier2>-<Qualifier3>-0
• Code for phase to phase R-Y phase Instantaneous voltage will be P1-1-4-1-0.
• Code for phase to neutral B-phase Average voltage will be P1-2-3-4-0.
• Code for phase to phase Maximum system voltage will be P1-1-7-2-0.
9.3.3 Current
Qualifier1
Format
Version 2.3
th
Page 82 of 107
Code Description
1 Line Current
2 Active Current
3 Reactive Current
Qualifier2
Code Description
1 R- phase
2 Y-phase
3 B-phase
4 Neutral
Qualifier3
Qualifier3 denotes whether it is maximum, minimum or average current. These values are over a
period. Table below defines the code
Code Description
1 Instantaneous
Qualifier4
Qualifier 4 is not applicable.
Example
Current parameters code will be generated as P2-<Qualifier1>-<Qualifier2>-<Qualifier3>-0
• Code for R-phase instantaneous line current will be P2-1-1-1-0
• Code for instantaneous system line current will be P1-1-5-1-0.
9.3.4 Power
Positive values of power will indicate import (or lag) and negative value will indicate export (or lead).
Qualifier1
Code Description
1 Active – Fundamental
2 Active – Total
3 Reactive
4 Apparent
Qualifier2
Code Description
1 R- phase
Format
Version 2.3
th
Page 83 of 107
2 Y-phase
3 B-phase
Qualifier3
Qualifier3 denotes whether it is maximum, minimum or average power. Table below defines the code
Code Description
1 Instantaneous
Qualifier4
Qualifier 4 is not used.
Example
Power parameters code will be generated as P3-<Qualifier1>-<Qualifier2>-<Qualifier3>-<Qualifier4>
• Code for active total R-phase average power will be P3-2-1-4-0.
• Code for reactive B-phase instantaneous power will be P3-3-3-1-0.
9.3.5 Power factor

Positive value denote lag power factor and negative values will denote lead power factor. Power
factor codes can be derived from following qualifier.
Qualifier1
Code Description
1 R- phase
2 Y-phase
3 B-phase
Qualifier2
Qualifier2 denotes whether it is maximum, minimum or average voltage. Table below defines the code
Code Description
1 Instantaneous
Qualifier3
Qualifier3 denotes the direction. Table below defines the code.
Code Description
0 Not applicable
1 Import
2 Export
Format
Version 2.3
th
Page 84 of 107
Qualifier4
Qualifier4 is not used and will be zero
.
Example
Power factor parameters code will be generated as P4-<Qualifier1>-<Qualifier2>-<Qualifier3>-0
• Code for instantaneous R-phase power factor for will be P4-1-1-0-0.
• Code for Average import power factor will be P4-4-4-1-0
9.3.6 Voltage Angles

Voltage angles can be derived from following qualifiers. The voltage is measured in clockwise
direction.
Qualifier1
Code Description
3P,4W 3P, 3W
1 R phase angle RY
2 Y phase angle 0
3 B phase angle BY
Qualifier2
Qualifier3
Qualifier4
Example
Voltage angle parameters code will be generated as P5-<Qualifier1>-0-0-0
• Code for R-Y voltage angle for will be P5-1-0-0-0.
9.3.7 Power factor Angles

Power factor angles can be derived from following qualifiers.
Qualifier1
Code Description
1 R phase
2 Y phase
3. B phase
4 System
Qualifier2
Format
Version 2.3
th
Page 85 of 107
Qualifier3
Qualifier4
Example
Power factor angle parameters code will be generated as P7-<Qualifier1>-0-0-0
Code for R phase power factor angle for will be P7-1-0-0-0.
9.3.8 Energy / Demand

P7 parameter code will indicate Energy or demand based on the context in which it is being used.
Qualifier1
Code Description
1 Active energy
2 Reactive energy
3 Apparent energy
4 Active demand
5 Reactive demand
6 Apparent demand
Qualifier2
Qualifier4 denotes direction. Table below defines the code. For quadrant definition see appendix ?.
Code Description (As per Possible use
quadrant)
0 Not applicable Will applicable for
Qualifier 4 >1.
1 Q1 Reactive energy, import while
active import
2 Q2 Reactive energy, import while
active export
3 Q3 Reactive energy, export while
active export
4 Q4 Reactive energy, export while
active import
5 (Q1+Q4) 1. Active Import
2. Apparent while active
import
3. Reactive energy, lag +
lead while active import
6 (Q2+Q3) 1. Active Export
2. Apparent while active
export
3. Reactive energy, lag +
lead while active export
7 Q1+Q2 Reactive Import
8 Q3+Q4 Reactive Export
Format
Version 2.3
th
Page 86 of 107
9 Q1-Q4 Reactive energy, lag – lead while

active import
10 Q4-Q1 Reactive energy, lead – lag while
active import
11 Q2-Q3 Reactive energy, lag – lead while
active export
12 Q3-Q2 Reactive energy, lead – Lag while
active export
13 Q1+Q2+Q3+Q4 Active ,reactive, appraent for all
quadrant ( Import + export)
14 Q1+Q4-Q2-Q3 Active (Import – Export)
15 Q2+Q3-Q1-Q4 Active (Export – Import
16 Q1+Q2-Q3-Q4 Reactive energy, import – export
17 Q3+Q4-Q1-Q2 Reactive energy, export – import
18 Forwarded Sum of absolute values of all
Quandrants. This is to be used for
active.
19 Forwarded (import) Sum of absolute values of Q1 &
Q2. This is to be used for reactive.
20 Forwarded (export) Sum of absolute values of Q3 &
Q4. This is to be used for reactive.
Qualifier3
Qualifier3 further qualifies the energy type. Table below defines the code.
Code Description
0 Not applicable
1 Fundamental
2 Total
3 Defrauded
Qualifier4
Qualifier4 is used for threshold based energy registers.
Code Description
0 Not threshold based
1 Threshold based
2 Voltage Threshold based – High
(ABT application)
3 Voltage Threshold based – Low
(ABT application)
Example
Energy parameters code will be generated as P7-<Qualifier1>-<Qualifier2>-<Qualifier3>-<Qualifier4>
• Code for active import total energy will be P7-1-5-2-0.
• Code for Reactive import while active import energy will be P7-2-1-0.
• Code for apparent import + export fundamental energy will be P7-3-12-1-0
Format
Version 2.3
th
Page 87 of 107
9.3.9 Phase Sequence

It can take value as FORWARD or REVERSE. It is generally used in instantanoues parameters. P8
tag is defined as follows
Qualifier 1
Code Description
1 Voltage
2 Current
Qualifier2
Qualifier3
Qualifier4
Example
Phase sequence parameters code will be generated as P8-<Qualifier1>-0-0-0
Code for voltage phase sequence will be P8-1-0-0-0.
9.3.10 Frequency
Frequency code can be derived from following qualifiers
Qualifier1
Qualifier1 denotes instantaneous, maximum , minimum or average frequency. Table below defines
the code
Code Description
1 Instantaneous
Qualifier2
Qualifier3
Qualifier4
Example
Frequency parameters code will be generated as P9-<Qualifier1>-0-0-0
• Code for instantaneous frequency will be P9-1-0-0-0.
9.3.11 Current angles

Current angles can be derived from following qualifiers.
Format
Version 2.3
th
Page 88 of 107
Qualifier1
Code Description
1 R with respect to R phase voltage
2 Y with respect to R phase voltage
3 B with respect to R phase voltage
Qualifier2
Qualifier3
Qualifier4
Example
Current angle parameters code will be generated as P10-<Qualifier1>-0-0-0
• Code for R-Y current angle will be P10-1-0-0-0.
9.3.12 Duration
It can take value as ‘No Power’ or ‘No Load’. It is generally used in instantaneous interval (D4)
parameters. P11 tag is defined as follows
Qualifier1
Code Description
1 No Power ad
2 No Load
Qualifier2
Qualifier3
Qualifier4
10 Integrity check of CDF

10.1 Authenticator generator
It is the responsibility of meter manufacturer to ensure that the file generated & maintained in their
format is intact.
API3 will add authenticator at the end of CDF using an internal seed (Si to be embedded in API3) &
external seed (Se) passed by CFW to API3 through convert configuration file.
Format
Version 2.3
th
Page 89 of 107
The 'authenticator' is a number which is sent with a message so that a check can be made by the
receiver of the message that it has not been altered since it left the sender. For authenticators in
general the sender and receiver share the knowledge of a seed S which is otherwise secret. If M is
the message, the authenticator is a function of S and M. It is calculated by the sender and again by
the receiver. If the receiver's calculated value equals the authenticator value received with the
message, the message is assumed to be correct. Authenticator verification module is API4.
1. Data + Se (API3 + Si ) Authenticator value
2. Data + Authenticator value CDF file
3. CDF + Se (API4 + Si ) Authenticator value
Authenticator found in step 1 & step 3 should match.
<Authenticator>Authenticator Value</Authenticator>
All meter manufacturers must use authentication algorithm RIPEMD-160.
Common Common
Data Format Data Format
(Generated by Authenticator = (Generated by
CFC module) fn (Data + Seed) CFC module)
Authenticator =
fn (Data + Seed)
10.2 Authenticator verifier
Manufact
urer’s API4 Authenticator
Data match or
CDF Authenticator
mismatch
External Seed
CFW will pass the seed in configuration file of API3.
Format
Version 2.3
th
Page 90 of 107
11 Future expandability
Interoperability standard provide following advantages
• All new innovation in metering will be handled by manufacturer API’s and will be transparent
to CFW. However to use new features CFW may have to implement new interfaces.
• Any change in new meter reading protocol or disparity in the old and new version meters will
be handled by manufacturer API.
• As CDF is an XML file so it is easy to add any data/parameter.
• Any addition or removal of tag will not affect any software (for analysis or billing software)
which uses this file format as it will ignore the tags which are not required and also take
appropriate action if some tag which is required by the software is not present.
• All meter manufacturers are free to add any new data/parameter they support in XML file
without requiring any permission or looking for compatibility. So this does not stop
innovations from any vendors in metering field. For this 200 tags have been provided to each
manufacturer. The numbering of these tags are as follows:
1. L&T G1000
2. SML G1200
3. Elster G1400
4. Datapro G1600
5. DukeArnics G1800
6. HSPL G2000
7. Genus G2200
8. Omniagate G2400
9. Easun Reyrolle G2600
10. Capital Power G2800
11. Bentec G3000
12. Delhi control devices G3200
13. ICSA G3400
14. Holley Meters G3600
• The naming convention of the diffetent meter manufacturer’s are given below:
API MRD MRI CFC

function
Secure SMLMRD SMLMRI SMLCFC
L&T LNTMRD LNTMRI LNTCFC
Datapro DEPLMRD DEPLMRI DEPLCFC
Elster ELSMRD ELSMRI ELSCFC
DukeArnics DUKEMRD DUKEMRI DUKECFC
Format
Version 2.3
th
Page 91 of 107
HSPL HSPLMRD HSPLMRI HSPLCFC
Genus GNSMRD GNSMRI GNSCFC
Omniagate
Easun ERLMRD ERLMRI ERLCFC

Reyrolle
Capital CPSMRD CPSMRI CPSCFC

Power
Bentec
Delhi DCDMRD DCDMRI DCDCFC

Control
Devices
ICSA
(ECE)
• As this format is open and defined so it is not dependent on any single party.
12 Log Maintenance
All API’s should create log file which can be used for debugging/troubleshooting the communication
between CFW/API and API/meter. Though API’s creates log file but CFW should not use log for any
practical purpose other then debugging the API.
1. API should create log file in \LOG subfolder relative the folder where API exists. For example
if API resides in C:\CFW\SEMS folder then log file shall be created in C:\CFW\SEMS\LOG
folder.
2. The log file name should be YYYYMMDD.log, where YYYY stands for year , MM stands for
month, DD stands for day.
3. Log file should contain information about
a. Communication between CFW and API.
b. Communication between reading API and modem.
4. The log file contains following field. All fields are delimited by ‘|’
a. Date Time in dd/mm/yyyy hh:mm:ss format
b. Direction with respect to API. In case of communication between API and CFW API
will only write sent and received. In case of communication with modem API will write
sent to modem and received from modem.
c. Comport – In case of communication with modem comport shall be added to log file.
It can be blank if it is communication between CFW and API.
d. Instance ID
e. Command
f. Data/Description
Format
Version 2.3
th
Page 92 of 107
5. It is responsibility of CFW to delete the old log files and do housekeeping.

6. A responsibility of CFW writer that the message (communication between CFW & API) is
uniquely identifiable.
7. A typical example of log file contents will be like. Please note this is for example only and
command, description and log can be different as supported by API.
04-10-05 17:26:48| Received||0001|1600000600000001|
04-10-05 17:26:48| Sent||0001|1600100700000001|SMLMRD.EXE
04-10-05 17:26:53| Received|||0001|1600360100020001|C:\CFW\Conf Files\ReadAPI0001.xml
04-10-05 17:26:53| Sent||0001|1600230400000001|Connecting To The Meter
04-10-05 17:26:53| Sent to Modem|COM1|0001|ATD9352520183|Dial from modem
04-10-05 17:27:50| Received from Modem|COM1|0001|CONNECT 9600|Accepted by modem
04-10-05 17:27:56| Sent||0001|1600220400010001|Connection Established
04-10-05 17:27:41| Sent||0001|1600430400000001|Meter No: SML12345, Reading Line Parameters
04-10-05 17:27:44| Sent||0001|1600400400000001|Meter No: SML12345, Line Parameters Read
04-10-05 17:27:48| Sent||0001|1600410400000001|Meter No: SML12345, Reading Energy Values
04-10-05 17:40:24| Sent||0001|1600380400000001|Meter No: SML12345, Energy Values Read
04-10-05 17:40:27| Sent||0001|1600390400000001|Meter No: SML12345, Reading Load Survey
04-10-05 17:42:39| Sent||0001|1600360400000001|Meter No: SML12345, Load Survey Read
04-10-05 17:26:53| Sent to Modem|COM1|0001|+++|Bring to command mode
04-10-05 17:41:53| Sent to Modem|COM1|0001|ATH|Hangup
04-10-05 17:42:05| Received from Modem|COM1|0001|OK |Accepted by modem
04-10-05 17:42:42| Sent||0001|1600000400030001| Reading Successful
13 Approval of new tags

New tags will be defined when the working group meeting will be held. It is envisaged that the meeting
will be held at least once in a quarter. The latest document shall be available at
www.meteringindia.com. All other issues can be addressed by sending mail to following personnel.
1. Secure Meter Ltd – Mr. Surendra Jhalora Surendra.jhalora@securemeters.com
2. Elster – Mr. Ajit Magar ajit.magar@in.elster.com
3. L&T – Mr. Sanjay Ahuja ahujas@lntebg.com;
4. Genus – Mr. Rajesh Srivastava Rajesh.srivastava@genus.in
5. Easun Reyrolle – Mr. N. Suresh suresh.n@easunreyrolle.com
6. Omniagate – Mr. Muthu muthu@omniagate.com
7. HSPL – Mr. Rajesh Banthia banthia@hplindia.com
8. Capital Power – Mr. Vimal Shyam vimalshyam64@gmail.com
9. ICSA industries – Ivyjit Ivyjitsingh@icsa-india.com
10. Delhi Control Devices – Mr. Pushpendra Kumar Puspendra_kumar@rediffmail.com
11. Bentec Electri & electronic – Mr. Harjit Singh Harjit1973@gmail.com
Format
Version 2.3
th
Page 93 of 107
14 Glossary of terms
14.1 Not applicable qualifier in a parameter code
The parameter code will be defined as ‘P1-Q1-Q2-Q3-Q4’.
Zero shall be used as qualifier if the qualifier is not applicable for that parameter. Absence of any
qualifier is not legal parameter code e.g. <P1-a-b-c> is not a legal tag, it shall be P1-a-b-c-0 as a legal
tag.
14.2 Retention of data in case of more than one data source

If data is coming from manufacturer API as well as from CFW then data coming from manufacturer
API will be retained and data coming from CFW will be discarded.
14.3 Defined duration

Maximum, Minimum & average depends upon the context of the data. If it refers to the load survey
data then load survey integration period will be taken as defined period.
14.4 Quadrant definition

The quadrant definition corresponds to that in IEC 61268
Active
Quadrant 4 Quadrant 1
Active Import Active Import
Reactive Export Reactive Import
PF Leading, < 0 PF Lagging, > 0
Capacitive Inductive
Reactive
Quadrant 3 Quadrant 2
Active Export Active Export
Reactive Export Reactive Import
PF Lagging, > 0 PF Leading, < 0
Inductive Capacitive
14.5 Phase sequence

Phase sequence can have two values forward and reverse.
If Voltage supply connection is connected in the order of R, Y, B or Y, B, R or B, R, Y then it is called
forward sequence. The connection in any other order is called reverse sequence.
14.6 Parameter code list

This is the list of most common parameter. Parameter codes for other parameter can be generated in
similar way.
Parameter description Parameter Code

R-Phase phase to neutral instantaneous voltage P1-2-1-1-0
Y-Phase phase to neutral instantaneous voltage P1-2-2-1-0
Format
Version 2.3
th
Page 94 of 107
B-Phase phase to neutral instantaneous voltage P1-2-3-1-0

System phase to neutral instantaneous voltage P1-2-4-1-0
R-Phase instantaneous Line Current P2-1-1-1-0
R-Phase instantaneous Active Current P2-2-1-1-0
R-Phase instantaneous Reactive Current P2-3-1-1-0
Y-Phase instantaneous Line Current P2-1-2-1-0
Y-Phase instantaneous Active Current P2-2-2-1-0
Y-Phase instantaneous Reactive Current P2-3-2-1-0
B-Phase instantaneous Line Current P2-1-3-1-0
B-Phase instantaneous Active Current P2-2-3-1-0
B-Phase instantaneous Reactive Current P2-3-3-1-0
Instantaneous neutral current P2-0-4-1-0
System active total instantaneous power P3-2-4-1-0
System reactive instantaneous power P3-3-4-1-0
System apparent instantaneous power P3-4-4-1-0
R-ph active total instantaneous power P3-2-1-1-0
Y-ph active total instantaneous power P3-2-2-1-0
B-ph active total instantaneous power P3-2-3-1-0
R-ph reactive instantaneous power P3-3-1-1-0
Y-ph reactive instantaneous power P3-3-2-1-0
B-ph reactive instantaneous power P3-3-3-1-0
R-ph apparent instantaneous power P3-4-1-1-0
Y-ph apparent instantaneous power P3-4-2-1-0
B-ph apparent power P3-4-3-1-0
R-Phase instantaneous Power Factor P4-1-1-0-0
Y-Phase instantaneous Power Factor P4-2-1-0-0
B-Phase instantaneous Power Factor P4-3-1-0-0
Average instantaneous Power Factor P4-4-1-0-0
Voltage angle Y-ph wrt R-ph P5-1-0-0-0
Voltage angle B-ph wrt R-ph P5-2-0-0-0
Power Factor angle R-ph P6-1-0-0-0
Power Factor angle Y-ph P6-2-0-0-0
Power Factor angle B-ph P6-3-0-0-0
Active import fundamental P7-1-5-1-0
Active import total P7-1-5-2-0
Active export fundamental P7-1-6-1-0
Active export total P7-1-6-2-0
Active forwarded fundamental P7-1-18-1-0
Active forwarded total P7-1-18-2-0
Active Sum(Imp+Exp)fundamental P7-1-13-1-0
Active sum (Imp+Exp)total P7-1-13-2-0
Active net (Imp-Exp)fundamental P7-1-14-1-0
Active net (Imp-Exp)total P7-1-14-2-0
Reactive import P7-2-7-0-0
Reactive export P7-2-8-0-0
Reactive all 4 quadrant P7-2-13-0-0
Reactive Q1 P7-2-1-0-0
Reactive Q1 + Q4 P7-2-5-0-0
Reactive Q2 + Q3 P7-2-6-0-0
Format
Version 2.3
th
Page 95 of 107
Reactive Q1-Q4 P7-2-9-0-0

Reactive Q2-Q3 P7-2-11-0-0
Apparent Sum (all Quadrants) P7-3-13-0-0
Apparent while active import (Q1+Q4) P7-3-5-0-0
Apparent while active export (Q2+Q3) P7-3-6-0-0
Apparent Net P7-3-14-0-0
Apparent Q1 P7-3-1-0-0
Phase sequence P8-0-0-0-0
Instantaneous frequency P9-1-0-0-0
No Power Duration P11-1-0-0-0
No Load Duration P11-2-0-0-0
Format
Version 2.3
th
Page 96 of 107
15 Annexure
15.1 API compatibility with Reading configuration file
Each manufacturer shall provide reading configuration file information in this format along with API
Manufacture Name:
Element Supported (Y/N) Description /Possible values
Modemmake Type and value of modem make

supported
Modemconfigfile Name of modem configuration file
Baudrate Support baud rates
ConnectionType Connection type supported
TelephoneNumber
Port
MeterComuncationPort Values which this parameter can take
MultipleMeters
Serial
Device ID
InstParam
EnergyData
Settings
ProfileData
Days
Type
Events
TimeSynch
MDReset
TamperReset
Output file details List of output file which are generated
Format
Version 2.3
th
Page 97 of 107
after reading through Read API.
15.2 Adding manufacturer specific tags

Each manufacturer should provide addition tags in all XML files (i.e. configuration files / result file or
CDF file) in following format. This structure is to be created for each additional manufacturer specific
tag requirement. Please note: All tag and code should be created in manufacturer specific range only.
This will ensure that manufacturer specific code does not conflict with standard tags/codes
File name <Name of the file in which tag is added>
Reason for change <Brief description of why this additional tag is required >
<Tag Name> Description: <Description of tag>

Contains: <any tag which are contained by this tag>
Is Contained by: <Tag which contains this tag>
Attribute : <attribute which it contains>
Occurrence: <No of possible occurrences in the XML file>
DataType: <data type of value or attribute value>
<Code Name> Parent: <Category in which the code lies>

Description: <Brief description of code>
15.3 Folders path for temporary files and software hardware specification
Sr. Folder Path for Windows Supporting
HDD
No Manufacturer’s temporary files for XP with RAM CPU Platform
Name API1, API2, API3 SP2 OS
1 Capital Power Application Yes 1Gb P IV 2 GB .Net 2.0
System path\garb or 2.4 or
2 Elster Yes higher GHz higher JVM 1.6.0
3 L&T Application Yes or .Net 2.0
path\temp higher
4 Genus C:\CFW\Genus\temp Yes .Net 2.0
5 Secure Meters Application Yes No
path\temp additional
6 Easun Reyrolle Application Yes .Net 2.0
path\temp
7 ICSA Application Yes .Net 2.0
path\temp
8 HPL Socomec Application path\tmp Yes .Net 2.0
9 Delhi control Yes
devices
10 Bentec Application Yes .Net 2.0
path\temp
11 Holley Meters Yes
12 Omne-agate
Format
Version 2.3
th
Page 98 of 107
16 Document History
16.1 Version 01.00
Date 23rd Feb 2k4 Written Author Reviewed SML, L&T, Approved SML, L&T,
by by Elster by Elster
Initial template for use.
16.2 Version 01.10

Date 01st Mar 2k4 Written Author Reviewed SML, L&T, Approved SML, L&T,
st nd
Modified during the meeting held on 1 and 2 March.
16.3 Version 01.20

Date 1st Mar 2k4 Written Author Reviewed SML, L&T, Approved SML, L&T,
st nd
Restructured after the meeting held on 1 and 2 March
16.4 Version 01.30

Date 02nd Apr 2k4 Written Author Reviewed SML, L&T, Approved SML, L&T,
nd
Modified during the meeting held on 2 April.
16.5 Version 01.40

Date 15th Apr 2k4 Written Author Reviewed SML, L&T, Approved SML, L&T,
th
Modified during the meeting held on 15 April.
1. Scope includes the application.
2. Billing datacomplete & billing dataselective tag added.
3. Meter Interprocess communication protocol added. Section labelled as Meter
Interoperability Interprocess Protocol (MII Protocol)
4. Establishing connection responsibility is shifted to API
5. Audit trail via file is removed instead it will be passed on via TCP/IP command
protocol.
6. Specific Tags allocation for each manufacturer is added.
7. Naming convention for manufacturer specific APIs is added.
8. Threshold based energy register tag added.
16.6 Version 01.50

a) Option of appending CDF file on single file is removed.
Format
Version 2.3
th
Page 99 of 107
b) New error message / normal status enriched.

c) Document property is made Public from confidential.
d) Establishing TCP / IP link & terminating the API clause is added. (Section 7.2)
e) Responsibility of opening & closing the COM port is added as API1’s responsibility. (section
7.2)
f) Connection established will be shown with a BR. Example on this is added under example-4
of Meter Interoperability Interprocess protocol.
g) Abort command clarification is kept to close specific instance of the request or to abort the
API & all it’s link.
h) Mismatch of length of instance Id & use in the example is removed. Instance Id in all case is
of 4 characters now.
i) XML tags are case insensitive.
j) Modem configuration responsibility is added on the part of API.(section 7.2)
k) Tags for Modem make & modemconfig file name is added.
l) Power fail tag appearing every time against each IP is removed.
m) Port for CFW is defined in section 7.1
16.7 Version 01.60 (Oct 01, 2004)

a) Instance id is of 4 characters only. Anomaly in section 5 removed.
b) Status and Error messages section removed as this is covered in data part of progress
messages (Section 6 of Ver 1.5)
c) Additional command qualifier for acknowledge command added to indicate failure of the start
operation.
d) Additional command qualifier 60 (Invalid configuration file) is removed for Report progress as
it is added in acknowledgement command as ‘failed’ .
e) Multiple instances removed from configuration file as only single instance is possible in one
configuration file. For another instance new configuration file shall be made.
f) Example of D3 tag modified to cover all Bxx tags.
g) The purpose of D7 tag is explained. Threshold attribute is dropped and StartLimit and
EndLimit attributes are added in D7 tag example.
h) Gn tag removed for general information section.
i) Instead of reshuffling all the General information tags G18 is kept missing.
j) B14 is removed as it is same as D7.
k) Typographic error correction of Events data Section 9.2.1. Event tag is contained by D5 tag
instead of D3
l) Additional qualifier for User Abort added.
m) Instance tag in reading configuration file removed as one configuration file will contain data for
one instance only.
n) ALL tags are modified for occurrence and datatype fields to bring more clarity.
o) D3-00 instead of D3-0. D3-nn where nn is always of two digits.
Format
Version 2.3
th
Page 100 of 107
p) D3 tag description ‘billing’ word is replaced by ‘frozen’.

q) Dial retry added in reading API configuration.
r) Result file will contain the name of the output file along with complete path
s) Naming convention for file downloaded through MRI API has been defined. Name of file is
prefixed by ‘MRI’.
t) Tag causing error is mentioned in the data portion of invalid configuration file message.
u) Provision to close the API is added.
v) IP Address and port number are made configurable by passing them as command line
argument of API.
16.8 Version 01.70 (Nov 04 2004)

a) D4 tag attribute changed to INTERVALPERIOD from NONE.
b) On command acknowledgement two more codes are added “Invalid or unknown command”,
“command not supported”, “Failed due to invalid instance Id”
c) Under report progress idle state is added.
d) MeterComuncationPort tag added.
e) Serial number occurrence value changed from single to multiple
f) <DateTimeFormat> tag added in result file. Dates in all result file will be indicated by
DateTime format tag.
g) The attribute of result file is changed from ‘single’ to ‘multiple’
h) EnergyDataComplete tag is changed to EnergyData. The values are modified as -2,-1,0,1.
The tag occurrence value is modified from single to multiple.
i) Settings tag is added.
j) Load survey parameter data type value attribute is modified. Provision to indicate ‘No power’
is added.
k) C1 tag under tamper is modified as cumulative.
l) D4 tag date format was indicated by / ‘slash’. This has been corrected & indicated by – ‘dash’.
m) CRC word is replaced by authenticator.
n) Same readings configuration file cannot have multiple make of meters
16.9 Version 01.80 (Dec 28 2004)

a) <D4> tag – value for parameter as ‘No power’ is removed. Value will always be numeric.
Complete power fail or part power fail during IP will be indicated by <IFlag>.
b) <D3> tag – Mechanism attribute added. <B2> tag definition modified. Different interpretation
is added for <D3-00> & <D3-01>.
c) Provision is made to identify date representation for a specific tag (tag which is not following
general rule) in the result file.
d) Example modified (for <D3>) to indicate discontinuous time zone for the same TOD register.
e) TOD registers numbering to start with 1. Clarification added.
f) Energy data selective option is removed from dictionary of reading configuration.
Format
Version 2.3
th
Page 101 of 107
g) Deviation tag is added in the result file for reading API.

h) All XML tags & values where datatype is alphabet should be in upper case. Except unit tag
where values can appear as mentioned in the document.
i) Under energy parameter qualifier2 parameter code added (19,20). This is done to facilitate
forwarded reactive register representation.
j) Under energy parameter qualifier4 parameter code added (2,3). Under energy parameter
qualifier2 parameter code added (0). This is done to facilitate ABT based register definition.
k) Inter-process communication command (06,07) for API identification are added.
l) Folder path for API & associated files are mentioned in the section under “Responsibility of
CFW”.
m) Reading configuration file example modified to remove mismatch for LS 6 days & Type
indicating ‘Full’.
n) After successful conversion shifting file from one folder to the other will be done by API3.
o) All messages will be terminated by End of Line (&0D0A) characters.
p) Responsibility of creation of folders is specified as CFW’s responsibility.
q) Providing IP address & port number is made mandatory for invoking all APIs.
r) Positive value of power indicates import (or lag) and negative values will indicate export.
s) Profile data will have demand parameter instead of energy.
t) Tag G30, G31 and G32 added for document version, API version and cumulative MD reset
count
u) Tamper code for High neutral current added.
v) Qualifier 1 for frequency added to denote instantaneous, maximum, minimum and average
frequency.
w) Qualifier 3 for power factor added to denote import/export power. Positive value will denote
lag and negative value will denote lead power factor.
x) Tag B13 for history wise cumulative tamper count added.
y) Single phase meter added in possible values G15
z) B1 tag will be only contained by D3-00
aa) G5,G6,G7,G8,G9,G10,G28,G29 tags are removed. Other tags are not shifted as these tags
are kept missing.
bb) Authenticator tag is made mandatory.
cc) B2 tag is made mandatory.
dd) ErrorPath added to convert API configuration file.
ee) OutFileName attribute added in convert API result file.
ff) ‘yyyy’ will be printed if year is not available from meter
gg) Format for API compatibility with reading configuration file added in Annexure.
hh) Structure of overall common data format file added to add clarity.
ii) Added additional error code.
Format
Version 2.3
th
Page 102 of 107
16.10 Version 01.90(18th Jan 05)

a) Discrepancy removed for LoadProfile tag in reading configuration file. Now data dictionary
and example both contain <LOADPROFILE> tag.
b) Discrepancy removed for OCCDATE attribute for B4 tag. Now example and data dictionary
both contain only OCCDATE.
16.11 Version 01.10(18th Jan 05)

a) In CFCRESULT xml files <DataTime> tag is change to <DATETIMEFORMAT> which
contains general tag for date time format of CDF file. One more tag <CONVERTTIME>is
added which holds the value of date and time of convert.
b) DESTFILE in data dictionary of CFC configuration file changed to DESTPATH.
c) OutputFileName in revision history 1.80 corrected to OutFileName
d) <INSTANCEID> tag added in data dictionary of CFC result file it was already there in
example.
e) ‘NO’ added as valid value of <ENERGYDATA> tag, <TYPE> tag in <LOADPROFILE> tag
and <EVENTS> tag.
f) Path should be taken from configuration file mentioned in section 6.2 and section 8.2.
g) <DATETIMEFORMAT> tag removed from readings result file.
h) Attribute of CONVERT tag made capital in data dictionary.
i) <INSTANCEID> tag It should be four digit number with ‘0’ appended in beginning if number is
less then 4 digit.
j) Example for <B2> tag corrected to take date time next history.
k) CUMULATIVE TIME changed to CUMULATIVETIME
l) Example of <CUMULATIVE> tag in <D5> tag corrected to take attribute as CODE.
m) PARAMCODE attribute added for B9 and B10 tag
n) API’s can be .EXE or .BAT
o) ERRORPATH value corrected in example.
16.12 Version 01.11

a) Data Type of day profile corrected
b) Power fail attribute removed from IP tag. Discrepancy between data dictionary and example
removed.
c) RESULT attribute of CONVERT tag in CFC API result file made capital.
d) COVERTTIME definition corrected in data dictionary.
e) CUMULATIVETIME attribute of CUMUALTIVE tag corrected.
D3-02 added in example to demonstrate that B2 tag may not always be same as next appearing D3-
nn
16.13 Version 01.12

a) HPL API and contact person added.
Format
Version 2.3
th
Page 103 of 107
b) Addition in reading API responsibility. API should leave modem at factory default setting and
1200 baudrate.
16.14 Version 1.13

a) In normal condition API should leave modem on standard settings of (1200/N/8/1) however in
case of exception condition CFW should bring the modem to standard settings of
(1200/N/8/1). This is added in responsibility of CFW and API in meter reading section.
b) Responsibility of making log file added in API responsibility. Log maintenance section added.
c) Manufacturer specific file generated by reading API should be compatible with the proprietary
software provided by meter manufacturer add in responsibility of read API.
d) The details for modem configuration file structure should be provided by meter manufacturer
to CFW writer added in responsibility of reading API.
e) Any new innovation in metering shall be handled by manufacturer API added in future
expandability section
f) Reference to www.meteringindia.com added.
g) G7.G8 added for ratio of primary to secondary PT/CT in meter
h) G9, G10 added for Primary PT, CT of meter.
i) Clarity added for P7 as it can be used in energy/demand
j) Forwarded energy is for active
k) Invalid interval code added in IFLAG tag of profile data
l) Current angle are made with respect to R phase voltage
m) System power factor angle added.
n) Current missing events for all phases added.
16.15 Version 1.14
a) Section 9.3.8 clarity provided for energy & demand code. Additional qualifier code added in
the demand under P7 tag.
b) Section 9.2.1 Demand calculation method clarification is given for fixed window (B5,B6) or
sliding window (B14,B15).
c) Phase sequence – Voltage & current qualifier added. Section 9.3.9
d) Tag G8 description is corrected. Instead of PT primary & secondary it is CT primary & CT
secondary.
e) Section 6.3 – Current meter setting and transaction data added in what to read tag.
f) Section 9.2.1 – D8, D9, D10 tags for Current meter setting, transaction data and flag data
added.
g) Section 9.2.11 – Current meter setting tags added
h) Section 9.2.12 – Transaction data tags added
i) Section 9.2.13 - Flag data tags added
j) Section 15.2 – Manufacturer specific tag addition template added.
Format
Version 2.3
th
Page 104 of 107
16.16 Version 1.15

a) EVENT tag definition changed at the request of LNT(mail dated21/12/06). Now a optional
DURATION attribute is added in case meters does not time of restoration. In this case TIME attribute
will be kept blank. DURATION attribute is kept option of maintain the backward compatibility.
16.17 Version 1.16

• Acronym AQ, CQ added (Sect 5.2)
16.18 Version 1.17

• MIOS logo is added in the document
16.19 Version 1.18

• Easun Reyrolle name & tag added
• SML name changed to Secure
• Section 9.2.11 Current Meter setting - example added for MDRESETSETTING.
• Section Parameter code list – Parameter code for Voltage (phase to neutral) example was
incorrect. The example is corrected now.
16.20 Version 1.19

• Support for Inbound dialling is added section 6.2 and 6.4.3
• Support for store and forward device is added section 6.4.4
• Changes related to Membership ID are made in following sections.
• 9.2.1- Tag G33 Added
9.2.4 –Membership ID description.
16.21 Version 1.20

• Tag approving authorities for Easun Rerolle, Genus & Omniagate added
• Duke Arnics , Datapro & NDPL name removed from tag approving authorities.
• MRI API XML data dictionary tag explained – PORT, PROTOCOL TYPE, SERIAL, IP
ADDRESS, MRIDATAFILEPATH, PCDATAFILEPATH
• Explanation of OUTPUTPATHANDNAME, DELETEFILEPATH removed
• <OUTPUT> file is made parent tag & <FILENAME> is made child tag.
• Command set MII protocol – additional qualifier code 77, 78, 79 added
• Result code 2 is added indicating partial success of MRI data transfer.
• Prepare MRI option is removed – it will be discussed later
• Changes done to support Max, Min data type in load profile (D4).
• Section 10, (Integrity of CDF file) is modified to mention digital signature scheme. Algorithm
and other necessary diagrams are added.
Format
Version 2.3
th
Page 105 of 107
16.22 Version 1.21

• RSA Data security Digital Signature process explained Sec 10.2
• Max / Min Load profile example added. Respective Tags added.
16.23 Version 1.22

• Corrected quotation mark in scope of CFC configuration file.
• Authentication & seed related information has been removed.
• API4 name has been changed from Authenticator generation module to Digital Signature
Verification.
• API5 “Authenticator checking module” related information has been removed.
• Signature element added in Dictionary of common file format.
• New code “80”&”81” added in report progress.
• Mode of meter reading examples added.
• Duration of No power & No load example added & related tags & parameter codes also has
been defined.
16.24 Version 2.0 – 30th Meeting 24th Nov 2008

• B5 & B6 tag value description ‘cumulative’ word is removed.
• License key clause is removed. This is done to popularise use of API.
o The diagram changed
• Public key / private key concept removed
o Authenticator generation will be merged within API3.
o Proprietary file will be used to generate authenticator along with seed.
o Same seed will be shared between utility & billing agency. This will not hamper
security in any case.
o Seed maintenance will be responsibility of utility.
o Authenticator check API4 (earlier called as API5) will have to be defined &
documented.
• Version 2.0 – 30th Meeting 24th Nov 2008

o Circuit switched for inbound dialling added
• Version 2.1 – 31st Meeting 21st Jan 2009

o Support for Inbound Dialling-Reading Direction updated.
o MRI Prepare Module added.
o Cumulative Tamper Count Added in D3 Tag.
o B16 Tag (provision to transfer tariff file name) is added.
o IFLAG Code 106 to 117 Added.
o Event Data Tag 55 to 64 Added.
Format
Version 2.3
th
Page 106 of 107
o Transaction Tag 12 to 19 Added.

o Log File naming convention (From YYYYMMDDhhmmss.log to YYYYMMDD.log)
updated in Log Maintenance Section.
o Folder Path for Temporary file and Software & Hardware specification Annexure
added.
• Version 2.2 – 33rd Meeting 8th May 2009

o Section 6.1 modified – Which manufacturer API to be invoked is reemphasized as
mentioned here-- Decide & Invoke respective meter manufacturer’s reading API
o Transaction code under D9 code 4, code 8, code 9 clarity added. Code 4 for logging
when MD reset happened, code 8 MD setting parameter changed & code 9 type
changed.
o Tag D5 - Cumulative time from hours only changed to ddd:hh:mm:ss.
o Tag B4 -- First register to start with 1 – statement removed. So now first register may
start with 1 or it may start with 0
• Version 2.3 – 34th Meeting 16th July 2009

o Section 6.4.3 Removed – Support of inbound dialling.
o Section 7.3 Updated-The Result file naming convention change, The Delete from MRI
tag added in Prepare operation. The Path name updated. The prepare and download
example updated.
o Sections 9.2.1 updated- Cumulative tamper Count removed.
o Section 9.2.6 Updated- The B16 tag (Tariff Name) added in Billing register data
example.
o Section 15.3 - Folders path for temporary files and software hardware specification
table updated
o Section 9.2.2 – Version encoding information for XML file is added
o Section 10, Section 8.3, Section 1.3 – Reference of digital signature is removed.
Authenticator, seed related information added. API4 is created to verify
authentication. Two different seed concept is added. Logic for authentication
algorithm logic is mandated to be used as specified in the web site – RIPEMD.
o Section 6.2 – Item 4- API should start the operation only after verifying that it has
been invoked by CFW. CFW word added in place of authorised program.
o Section 6.3.1 - Relationship of What to Read & CDF Tags – is removed
o Section 6.2. – Item 17 – Removed having reference about inbound modem
o Tag G34 is added as Standard or Long range
o Tag G14 modified as meter rating in place of meter range.
o Section 7 – Prepare MRI is made optional
o Event code 65 to 71 added
o Transaction code 20 to 30 added.
o MD reset mechanism auto clarified further.
o D11 (Sag & Swell) & D12 (Phase wise Power on time) tags are added
Format
Version 2.3
th
Page 107 of 107
o B17(Billing period power on duration), B18 (Energy cross over count), B19
(Cumulative energy during magnetic tamper) , B20 (Reset specific information) added

MIOS

Uploaded by

Copyright:

Available Formats

MIOS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MIOS

Uploaded by

Copyright:

Available Formats

Universal Meter Reading & Common Doc. No.

1.1 PURPOSE ........................................................................................................................... 5

2 KEY POINT (OPTIONAL) ................................................................................................... 6

3 COMMON FRAME-WORK (CFW) ...................................................................................... 7

3.1 RESPONSIBILITY OF CFW ................................................................................................... 7

4 INVOKING METER MANUFACTURER MODULES .......................................................... 9

5 METER INTEROPERABILITY INTERPROCESS PROTOCOL (MII PROTOCOL) .......... 9

5.1 HEADER ........................................................................................................................... 10

6 METER READING ............................................................................................................. 16

6.1 RESPONSIBILITY OF CFW FOR METER READING................................................................ 17

7 PREPARING MRI AND DOWNLOADING DATA FROM MRI........................................ 28

7.4 MRI RESULT FILE............................................................................................................. 37

8 CONVERTING TO COMMON FORMAT .......................................................................... 39

8.1 RESPONSIBILITY OF CFW FOR CONVERTING TO CDF ....................................................... 40

9 COMMON DATA FORMAT (CDF) ................................................................................... 46

9.1 DATA FORMATS – POSSIBLE ALTERNATE ......................................................................... 46

10 INTEGRITY CHECK OF CDF ......................................................................................... 88

10.1 AUTHENTICATOR GENERATOR ........................................................................................ 88

11 FUTURE EXPANDABILITY ............................................................................................ 90

12 LOG MAINTENANCE ..................................................................................................... 91

13 APPROVAL OF NEW TAGS .......................................................................................... 92

14 GLOSSARY OF TERMS ................................................................................................. 93

14.1 NOT APPLICABLE QUALIFIER IN A PARAMETER CODE ...................................................... 93

15.1 API COMPATIBILITY WITH READING CONFIGURATION FILE ............................................... 96

16 DOCUMENT HISTORY ................................................................................................... 98

16.1 VERSION 01.00 .............................................................................................................. 98

16.21 VERSION 1.20 ............................................................................................................ 104

The specification fulfils following objectives.

1.3 Definitions & Abbreviations

1.5 Pre-Requisites (Optional)

1.6 Overview (Optional)

2 Key Point (Optional)

3 Common Frame-Work (CFW)

Common Frame-Work (CFW)

#2 MRD #2 MRI #2 CFC Common

Meter Manufacturer’s Manufacturer’s Common format

3.1 Responsibility of CFW

g) Manufacturer folder: There shall be three folders in manufacturer folder.

3.2 Responsibility of manufacturer’s API

4 Invoking meter manufacturer modules

5 Meter Interoperability Interprocess Protocol (MII Protocol)

• Not necessarily best optimized but it is disciplined

Field Size Fixed Value

Command: The action requested or response code

5.2 Command Set

Command Purpose Command qualifier Additional Qualifier Type of Data Flow

prepare command file.

- Meter Serial No.

05 Request for 00:Meter reading Request CFW to API

5.2.1 The Data portion of each command

Command Comm Data Field Name Field Description

Mode of meter reading will be decided by Additional Qualifier as below

Additional Qualifier Mode

Header data would be: 1600870100000001 (in ASCII)

The data packet would be

The above packet will be enclosed within TCP/IP framework.

Example 2. Acknowledge Meter Reading

Header data would be: 1600000200000001