Uploaded by Vivek Tambakad

MIOSUniversalMeter

advertisement
Universal Meter Reading & Common
Format
Table Of Contents
1
Doc. No. 001
Version
Date
Page
2.3
th
16 july 09
INTRODUCTION ................................................................................................................. 5
1.1
1.2
1.3
1.4
1.5
1.6
PURPOSE ........................................................................................................................... 5
SCOPE ............................................................................................................................... 5
DEFINITIONS & ABBREVIATIONS ......................................................................................... 6
REFERENCES ..................................................................................................................... 6
PRE-REQUISITES (OPTIONAL) ............................................................................................. 6
OVERVIEW (OPTIONAL) ...................................................................................................... 6
2
KEY POINT (OPTIONAL) ................................................................................................... 6
3
COMMON FRAME-WORK (CFW) ...................................................................................... 7
3.1
3.2
RESPONSIBILITY OF CFW ................................................................................................... 7
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
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Universal Meter Reading & Common
Format
Table Of Contents
10.1
10.2
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
3 of 107
AUTHENTICATOR GENERATOR ........................................................................................ 88
AUTHENTICATOR VERIFIER ............................................................................................. 89
11
FUTURE EXPANDABILITY ............................................................................................ 90
12
LOG MAINTENANCE ..................................................................................................... 91
13
APPROVAL OF NEW TAGS .......................................................................................... 92
14
GLOSSARY OF TERMS ................................................................................................. 93
14.1
14.2
14.3
14.4
14.5
14.6
15
NOT APPLICABLE QUALIFIER IN A PARAMETER CODE ...................................................... 93
RETENTION OF DATA IN CASE OF MORE THAN ONE DATA SOURCE ................................... 93
DEFINED DURATION ........................................................................................................ 93
QUADRANT DEFINITION ................................................................................................... 93
PHASE SEQUENCE .......................................................................................................... 93
PARAMETER CODE LIST .................................................................................................. 93
ANNEXURE ..................................................................................................................... 96
15.1
15.2
15.3
16
API COMPATIBILITY WITH READING CONFIGURATION FILE ............................................... 96
ADDING MANUFACTURER SPECIFIC TAGS ........................................................................ 97
FOLDERS PATH FOR TEMPORARY FILES AND SOFTWARE HARDWARE SPECIFICATION ...... 97
DOCUMENT HISTORY ................................................................................................... 98
16.1
16.2
16.3
16.4
16.5
16.6
16.7
16.8
16.9
16.10
16.11
16.12
16.13
16.14
16.15
16.16
16.17
16.18
16.19
16.20
Public
VERSION 01.00 .............................................................................................................. 98
VERSION 01.10 .............................................................................................................. 98
VERSION 01.20 .............................................................................................................. 98
VERSION 01.30 .............................................................................................................. 98
VERSION 01.40 .............................................................................................................. 98
VERSION 01.50 .............................................................................................................. 98
VERSION 01.60 (OCT 01, 2004) ..................................................................................... 99
VERSION 01.70 (NOV 04 2004) .................................................................................... 100
VERSION 01.80 (DEC 28 2004) .................................................................................... 100
VERSION 01.90(18TH JAN 05) ..................................................................................... 102
VERSION 01.10(18TH JAN 05) .................................................................................... 102
VERSION 01.11 .......................................................................................................... 102
VERSION 01.12 .......................................................................................................... 102
VERSION 1.13 ............................................................................................................ 103
VERSION 1.14 ............................................................................................................ 103
VERSION 1.15 ............................................................................................................ 104
VERSION 1.16 ............................................................................................................ 104
VERSION 1.17 ............................................................................................................ 104
VERSION 1.18 ............................................................................................................ 104
VERSION 1.19 ............................................................................................................ 104
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
1
1.1
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
5 of 107
Introduction
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 MIOSUMRCF 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).
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
1.3
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
6 of 107
Definitions & Abbreviations
Name
PC
CFW
CDF
API
API1
API2
API3
API4
Seed
XML
Bill Date/
billing
1.4
No.
1
2
Description
Personal Computers whose design is derived from original IBM’ personal computer
architecture
Common framework
Common data format
Application program interface
Manufacturer’s reading module
Manufacturer’s MRI downloading module
Manufacturer’s CDF convert module
Manufacturer’s authenticator verification module
Number used as an input along with the data to generate authenticator
eXtended Markup Language
Bill date is the date which then cumulative register for energy, MD etc. are frozen.
Billing will happen as per the meter configuration. Possible reasons can be Reset by
push button, occurrence of reset date.
References
Name
XML
RIPEMD 160
Description
Legal site on XML standard www.w3c.org
Algorithm for authentication. www.esat.kuleuven.ac.be
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
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
#3 MRD
#3 MRI
#3 CFC
Meter
Make #2
Meter
Make #3
Manufacturer’s
Reading (MRD)
modules (API1)
Manufacturer’s
MRI
Downloading &
Prepare
(MRI) module
(API2)
Common
Data
Format
(CDF)
Common format
Converter (CFC)
module (API3)
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)
Public
To invoke convert API for conversion of data in CDF format.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
g)
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
8 of 107
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
framework
program
Manufacturer’s
modules (API)
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.
•
•
Public
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.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Header Length
Data Length
Command
Command qualifier
Additional command
Qualifier (Instance
number)
Instance Id
Size
2
4
2
2
2
Fixed Value
“16”
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
(CQ)
Additional Qualifier
(AQ)
01
Start
00:Meter reading
01:MRI read
02:MRI prepare
03:Convert to
common format
02
Acknowled
ge start
operation
00: Receipt of
Reading command
01:Receipt of MRI
download
command
02:Receipt of MRI
00: With audit trail
01: Silent operation,
only final result
required
02: Indicate only
major milestones
(do not supply
incremental
progress)
00 :Accepted
01: Failed due to
duplicate instance
ID
02: Failed due to
Invalid configuration
Public
Type of
command
wrt CFW
Request
Data Flow
CFW to API
Response
API to CFW
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
03
Abort &
close
Operation
04
Report
progress
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
11 of 107
prepare command
03:Receipt of
Convert to common
format command
file.
03: Invalid or
unknown command
04: command not
supported
05: Falied due to
invalid instance Id
00: Abort Meter
reading
01: Abort MRI
download
02: Abort MRI
prepare
03: Abort Convert
to common format
00:Meter reading
01:MRI download
02:MRI prepare
03:Convert to
common format
00: Abort
01: Abort & close
Request
CFW to API
00: In progress
01: Connection
established.
02: Meter reading
started
03: Meter reading
finished
04: CDF conversion
successful
05: Idle state
51: Cannot establish
connection – No dial
tone
52: Cannot establish
connection – Local
Modem not
responding
53: Cannot establish
connection – Line
busy
54: Cannot establish
connection – Port
not available
55: Cannot establish
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
Response
API to CFW
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Public
Request for
progress
status
00:Meter reading
01:MRI download
02:MRI prepare
03:Convert to
Request
CFW to API
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
06
Request for
API
identificatio
n
Response
to API
identificatio
n
command
07
5.2.1
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
13 of 107
common format
00:Default value
00:Default value
Request
CFW to API
00:Default value
00:Default value
Response
API to CFW
The Data portion of each command
Command
No
Data
Field
No
Field Name
Field Description
001
Comm
and
qualifi
ers
All
1
Configuration file name
004
All
1
Message
The name (with path) of the
configuration file to be used by the
meter reading program
The progress message to be shown
on user interface, or final status,
depending on the qualifier
Example 1. Start Meter Reading
Header
Field
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0087
01
00
00
0001
Mode of meter reading will be decided by Additional Qualifier as below
Additional Qualifier
00
01
02
Mode
Audit Trail Mode
Silent Mode
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0000
02
00
00
0001
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
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0000
03
00
00
0001
Header data would be: 1600000300000001
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
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Public
Size
2
4
2
2
2
Example
16
0041
04
00
00
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Instance Number
4
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
15 of 107
0001
Header data would be: 1600410400000001
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
The above packet will be enclosed within TCP/IP framework.
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
1600400400000001|TRND0001,ReadingInstParams, Message:2
1600400400000001|TRND0001,ReadingInstParams, Message:3
1600400400000001|TRND0001,ReadingInstParams, Message:5
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
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0041
05
00
00
0001
Header would be: 1600018500000001
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
16 of 107
Data
No
1
Field
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
The above packet will be enclosed within TCP/IP framework.
Example 6. Request for API identification
Header
Field
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0000
06
00
00
0001
Header would be: 1600000600000001
The entire packet will be like 1600000600000001
The above packet will be enclosed within TCP/IP framework.
Example 7. Response to API identification command
Header
Field
Header Length
Data Length
Command
Command Qualifier
Additional Qualifier
Instance Number
Size
2
4
2
2
2
4
Example
16
0010
07
00
00
0001
Header would be: 1600100700000001
Data
No
Field
1
API name with extension
The entire packet will be like 1600100700000001LNTMRD.EXE
The above packet will be enclosed within TCP/IP framework.
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
17 of 107
each meter is read sequentially. Next meter reading is started once first meter reading is
completed.
User
selects the
operation
to be
performed
with meter
Meter
Make #1
Connection details
(Connection type,
Baudrate, Device
ID,
port)
What to read from
meter?
ReadMeter
Meter
Make #2
Audit trail/
Result log
Common
framework
program
6.1
Manufacturer’s
Reading (MR)
modules (API)
Meter
Make #3
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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,
PathandName and command
WhatToRead,
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,
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
20 of 107
MODEMCONFIGFILE, TELEPHONENUMBER
Is Contained by: READAPI
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
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Single
DataType: Alphanumeric
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
Is Contained by: CONNECTIONDETAILS
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)
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
21 of 107
Description: Holds value of telephone number
TELEPHONENUMBER
Contains: None
Is Contained by: CONNECTIONDETAIL
Attribute : None
Occurrence: Single
DataType: Alphanumeric
Description: Holds value of maximum dial retries count in case
of unsuccessful attempts.
DIALRETRY
Contains: None
Is Contained by: CONNECTIONDETAIL
Attribute : None
Occurrence: Single
DataType: Numeric
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.
PORT
Contains: None
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
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
DataType: Can only take values defined above
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
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Version
Date
Page
Table Of Contents
SERIAL
Doc. No. 001
2.3
th
16 July 09
22 of 107
Description: Holds the value of meter serial number
Contains: None
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Multiple
DataType: Alphanumeric
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
Is Contained by: CONNECTIONDETAILS
Attribute : None
Occurrence: Multiple
DataType: Alphanumeric
WHATTOREAD
Description: Specifies about what is to be read by manufacturer
reading API
Contains:
EVENTS
INSTPARAM,
BILLINGDATA,
LOADPROFILE,
Is Contained by: READAPI
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
DataType: Can only take values defined above
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
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: multiple
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
23 of 107
DataType: Can only take values defined above
SETTINGS
Description: Holds ‘Yes’ if meter settings is to be read
Contains: None
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
LOADPROFILE
Description: Specifies profile data to be read
Contains: Days , type
Is Contained by: WHATTOREAD
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
Is Contained by: PROFILEDATA
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
EVENTS
Description: Holds ‘YES’ if events data is to be read and ‘NO if
events data is not to be read.
Contains: None
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
24 of 107
DataType: Can only take values defined above
TRANSACTION
Description: Holds ‘YES’ if transaction data is to be read and
‘NO if transaction data is not to be read.
Contains: None
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
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
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
PATHANDNAME
Description: Specify the path and name for the files used by
CFW and API1.
Contains: DATAFILEPATH, RESULTFILE
Is Contained by: READAPI
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
DataType: Alphanumeric
RESULTFILE
Description: Holds the name of file which contains consequence
of the operation.
Contains: None
Is Contained by: PATHANDNAME
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
25 of 107
Occurrence: Single
DataType: Alphanumeric
COMMAND
Description: Holds the name of instructions to be sent to the
meter at the time of reading
Contains: TIMESYNCH, MDRESET, TAMPERRESET
Is Contained by: READAPI
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
Is Contained by: COMMAND
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
Is Contained by: COMMAND
Attribute : None
Occurrence: Single
DataType: N/A
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
6.3.2
Doc. No. 001
Version
Date
Page
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
2.3
th
16 July 09
26 of 107
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>
<INSTANCEID>0009</INSTANCEID>
<SERIAL>NDP13654</SERIAL>
<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
Is Contained by: None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
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,
INSTANCEID
DATETIME,
RESULT,
OUTPUTFILENAME,
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
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Alphanumeric
DATETIME
Description: Holds value of date time of meter reading.
Contains: None
Is Contained by: INSTANCE
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
Is Contained by: INSTANCE
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
28 of 107
Occurrence: Multiple
DataType: Alphanumeric
Description: Holds the value of result of the reading operation.
RESULT
Contains: None
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Alphanumeric
Description: Holds the sub-tags of ‘WhatToRead’ tag for which deviation is
taken.
DEVIATION
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Version
Date
Page
Table Of Contents
7.1
Doc. No. 001
2.3
th
16 July 09
29 of 107
Responsibility of CFW for Preparing MRI and downloading data from MRI
User
selects the
operation
to be
performed
with meter
Communication
and other details
(MRI type,
Baudrate,
Comport)
What to read from
meter/MRI ..?
MRI
Make #1
Clear MRI
Clear MRI ?
Invoke MRI API
with above details
Common
framework
program
MRI Operation
Prepare
MRI
Make #2
Result log
Manufacturer’s
MRI Prepare &
Downloading
modules (API)
MRI
Make #3
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.
Public
Create result file.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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)
<BAUDRATE>9600</BAUDRATE>
<SERIAL>NDP18271</SERIAL>
<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>
MODE)
(ALWAYS
IN
APPEND
</PATHANDNAME>
</PREPARE>
</MRIAPI>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
31 of 107
Download e.g.
<MRIAPI>
<INSTANCEID>0002<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)
<BAUDRATE>9600</BAUDRATE>
<SERIAL>NDP18271</SERIAL>
<DOWNLOAD>
<DELETEFROMMRI>YES </DELETEFROMMRI>
<PATHANDNAME>
<PCDATAFILEPATH>C:\CFW\MANUFACTURER\ABC</PCDATAFILEPATH>
<RESULTFILE>C:\CFW\MANUFACTURER\
MODE)
0002_MRIRESULTFILE.XML</RESULTFILE>
(ALWAYS
IN
APPEND
</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
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 numbers with ‘0’ appended in beginning if number is less then 4
digit.
Contains: None
Is Contained by: MRIAPI
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
32 of 107
Attribute : None
Occurrence: Single
DataType: Numeric
WHICHMRI
Description: Holds value of make of Handheld unit (MRI)
Contains: None
Is Contained by: MRIAPI
Attribute : Analogic, Sands, Radix, PDA
Occurrence: Single
DataType: Alphanumeric
DATAFORMAT
Description: Holds value of data type which can either be compressed
or can be normal. This is an optional tag.
Contains: None
Is Contained by: MRIAPI
Attribute: Compressed, Normal
Occurrence: Single
DataType: Alphanumeric
SERIAL
Description: Holds value of serial number of meter to be transferred or
meter to be prepared. This is an optional tag
Contains: None
Is Contained by: MRIAPI
Attribute : ABC00001 & so on
Occurrence: Multiple
DataType: Alphanumeric
PORT
Description: Holds value of port number of PC via which data is to be
transferred. This is an optional tag
Contains: None
Is Contained by: MRIAPI
Attribute : COM1, COM2, COM3, COM4, 8080
Occurrence: Single
DataType: Alphanumeric
PROTOCOL TYPE
Description: Holds value of protocol followed by MRI. This is an
optional tag
Contains: None
Is Contained by: MRIAPI
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
33 of 107
Occurrence: Single
DataType: Alphanumeric
IP ADDRESS
Description: Holds value of IP address of meter to be transferred. This
is an optional tag
Contains: None
Is Contained by: MRIAPI
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
Is Contained by: MRIAPI
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
Is Contained by: MRIAPI
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
DataType: Alphanumeric
PCDATAFILEPATH
Description: Specify the path where the files are to be transferred to
PC
Contains: None
Is Contained by: PATHNAME
Attribute : None
Occurrence: Single
DataType: Alphanumeric
OUTPUTFILENAME
Description: Specify the path where the files are to be transferred to
PC
Contains: Filename
Is Contained by: PATHNAME
Attribute : None
Occurrence: Single
DataType: Alphanumeric
FILENAME
Description: Specify the path where the files are to be transferred to
PC
Contains: None
Is Contained by: OUTPUTFILENAME
Attribute : None
Occurrence: Multiple
DataType: Alphanumeric
PREPARE
Description: This is root node for preparing MRI. This is an optional tag
Contains: PATHNAME, WHATTOREAD
Is Contained by: MRIAPI
Attribute : None
Occurrence: Single
DataType: Numeric
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
WHATTOREAD
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
35 of 107
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
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
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
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: multiple
DataType: Can only take values defined above
SETTINGS
Description: Holds ‘Yes’ if a meter setting is to be read. This is an
optional tag.
Contains: None
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
LOADPROFILE
Description: Specifies profile data to be read
Contains: Days , type
Is Contained by: WHATTOREAD
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
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. This is an optional tag.
Contains: None
Is Contained by: PROFILEDATA
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
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
Is Contained by: WHATTOREAD
Attribute : None
Occurrence: Single
DataType: Can only take values defined above
MRISCHEDULEFILEPATH
Description: Specify the path (&name) of the schedule files to be
transferred into MRI. This is an optional tag.
Contains: None
Is Contained by: PATHANDNAME
Attribute : None
Occurrence: Single
DataType: Alphanumeric
RESULTFILE
Description: Holds the name of file which contains consequence of the
operation.
Contains: None
Is Contained by: PATHANDNAME
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
37 of 107
Occurrence: Single
DataType: Alphanumeric
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>
<FILENAME> C:\CFW\MANUFACTURER\ABC\MRI01012005.MRD</FILENAME>
<FILENAME> C:\CFW\MANUFACTURER\ABC\MRI01012006.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
Is Contained by: None
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
38 of 107
Is Contained by: MRIRESULT
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
MODE
Description: Hold values of Operation perform on MRI. The MODE have
two value
PREPARE
DOWNLOAD
Contains: None
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Alphanumeric
DATETIME
Description: Holds value of date time of MRI downloading/Prepare in ddmm-yyyy hh:mm:ss format
Contains: None
Is Contained by: INSTANCE
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
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Alphanumeric
RESULT
Public
Description: Holds the value of result of prepare or downloads
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
39 of 107
operation.
Contains: None
Is Contained by: INSTANCE
Attribute : None
Occurrence: Single
DataType: Numeric
7.4.2
Result Code-DOWNLOAD MODE
Result Code
Description
0
Success
1
Failure
2
Partial Success – On
multiple meter data
transfer all files are not
transferred.
7.4.3
Result Code-PREPARE MODE
Result Code
Description
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
User selects
the data to be
converted in
Common data
format
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
40 of 107
#1 CFC
Source file path
Destination file path,
Seed
#2 CFC
#3 CFC
ConvertToCDF
Common
Data
Format
(CDF)
Result file
Common
framework
program
8.1
Common
format
Converter
(CFC) module
(API)
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>
<INSTANCEID>0001</INSTANCEID>
<SOURCEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONPENDING</SOURCEPATH>
<DONEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONDONE</DONEPATH>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
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: 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
DataType: Alphanumeric
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
Is Contained by: CFCAPI
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
42 of 107
Attribute : None
Occurrence: Single
DataType: Alphanumeric
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
Is Contained by: CFCAPI
Attribute : None
Occurrence: Single
DataType: Alphanumeric
SCOPE
Description: Hold the information about the files which needs to be
converted into common format.
Contains: FILENAME
Is Contained by: CFCAPI
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:
Is Contained by: CFCAPI
Attribute : None
Occurrence: One or more
DataType: Alphanumeric
DESTPATH
Description: Holds the value of the path where CDF converter module will
create the CDF files.
Contains: None
Is Contained by: CFCAPI
Attribute : None
Occurrence: Single
DataType: Alphanumeric
SEED
Public
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
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
43 of 107
Contains: None
Is Contained by: CFCAPI
Attribute : None
Occurrence: Single
DataType: Alphanumeric
RESULTFILE
Description: Holds name of the result file along with complete path.
Contains: None
Is Contained by: CFCAPI
Attribute : None
Occurrence: Single
DataType: Alphanumeric
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>
<INSTANCEID>0001<INSTANCEID>
<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
Is Contained by: None
Attribute : None
Occurrence: Single
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
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: 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
Is Contained by: INSTANCE
Attribute : None
Occurrence: One or more
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
Is Contained by: INSTANCE
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Dn
Description: Holds the value of the date time format which is applicable for
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
Is Contained by: CFCAPI
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
Occurrence: One or more
DataType: N/A
8.4.2
Result Code
Result Code
Error
0
Success
1
Failure
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Is Contained by: None
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.
Occurrence: One or more
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
47 of 107
Attribute : None
Occurrence: Single
DataType: Alphanumeric
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
Is Contained by: UTILITYTYPE
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)
Is Contained by: UTILITYTYPE
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
48 of 107
Is Contained by: UTILITYTYPE
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
Is Contained by: UTILITYTYPE
Attribute : None
Occurrence: Single
DataType: N/A
D6
Description: This data contains snapshot of
energy at a particular time.
Contains: SNAPSHOT
Is Contained by: UTILITYTYPE
Attribute : None
Occurrence: Single
DataType: N/A
D7
Description: This data contains information about
“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
Is Contained by: UTILITYTYPE
Attribute : None
Occurrence: Single
DataType: N/A
D8
Description: Contains
current meter settings.
the
information
about
Contains: APPCALC , LOADSURVEYSETTING,
MDSETTING
Is Contained by: UTILITYTYPE
Attribute :
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Is Contained by: UTILITYTYPE
Attribute :
Occurrence: Single
DataType:
D10
Description: Contains the information about the
flags which indicates the meter health.
Contains: FLAG
Is Contained by: UTILITYTYPE
Attribute :
Occurrence: Single
DataType:
D11
Description: This contains value of Sag & Swell
count. This is hold by tag D11.
Contains: FLAG
Is Contained by: UTILITYTYPE
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
Is Contained by: UTILITYTYPE
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
G1
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
50 of 107
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
DataType: Alphanumeric
G2
Description: Holds the value of date time stamp as per
meter at the time of reading.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Date time. The format of date time is dd-mmyyyy hh:mm:ss
G3
Description: Holds the value of date time stamp as per
PC/MRI at the time of reading.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Date time. The format of date time is dd-mmyyyy 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
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Date time. The format of date time is dd-mmyyyy hh:mm:ss
G7
Public
Description: Holds the value of ratio of Programmed
PT Primary to Programmed PT secondary in meter.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Origin of data: CFW/Manufacturer API
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
Origin of data: CFW/Manufacturer API
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
Origin of data: CFW/Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G11
DataType: Numeric
Description: Holds the value of Programmed PT
Secondary in meter. Value is always in Volts
Origin of data: CFW/Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
52 of 107
Occurrence: Single
DataType: Numeric
G12
Description: Holds the value of Programmed CT
Secondary in meter. Value is always in Amp
Origin of data: CFW/Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G13
DataType: Numeric
Description: Holds the value of Meter class. This is
class of accuracy of meter
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G14
DataType: Alphanumeric
Description: Holds the value of Meter rating. (5-6, 5-20)
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G15
DataType: Alphanumeric
Description: Holds the value of Meter type. Meter type
means HT(3ph-3W), HT(3ph-4W),LT(3ph-3W), LT(3ph4W), WC(3ph-4W),WC(1ph-2W)
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G16
DataType: Alphanumeric. Can only take values defined
above.
Description: Holds the value of Meter Scaling. Meter
scaling can have value Primary/Secondary.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
53 of 107
Attribute : None
Occurrence: Single
G17
DataType: Can have value Primary or Secondary
Description: Holds the value of Meter Program Name
including version number
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G19
DataType: Alphanumeric
Description: Holds the value of cumulative successful
meter reading count
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G20
DataType: Numeric
Description: Holds the value of MD integration period
(Possible values - 1 mt, 2mts, 5 mts,15mts, 30mts,
60mts)
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G21
DataType: Numeric
Description: Holds the value of additional information.
Origin of data: CFW
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Alphanumeric
G22
Description: Holds the value of manufacturer code and
name.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Origin of data: CFW/Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
DataType: Alphanumeric
G24
Description: Holds the value of Meter collection status.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G25
DataType: Alphanumeric
Description: Holds the value of present configuration
Name
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G26
DataType: Alphanumeric
Description: Holds the value of previous configuration
Name
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G27
DataType: Alphanumeric
Description: Holds the value of Data Validation status.
This checks the integrity of data
Origin of data: Manufacturer API
Contains: None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
55 of 107
Is Contained by: D1
Attribute : None
Occurrence: Single
G30
DataType: Alphanumeric
Description: Holds the version number of
interoperability document to which the common format
complies
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G31
DataType: String. (For example 1.80)
Description: Holds the version number of API from
which the common format is generated
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G32
DataType: String ( For example 1.1.0.1)
Description: Holds the value of cumulative maximum
demand reset count.
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G33
DataType: Numeric
Description: Holds the value of MIOS membership ID
issued by MIOS forum and as received in reading result
file generated by Read API
Origin of data: Manufacturer API
Contains: None
Is Contained by: D1
Attribute : None
Occurrence: Single
G34
Public
DataType: Alpha Numeric
Description: Holds the value of Meter range.
(Standard, long range)
Origin of data: Manufacturer API
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Occurrence: One or more
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.
Description: <D3-nn> tag will appear for each bill date
D3-nn
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Occurrence: One or more
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
Is Contained by: D3-nn
Attribute: DATETIME – Date time of MD reset
MECHANISM –Mechanism used to do MD
reset. This can take three values “Push Button”,
“Auto” , “Command”.
Occurrence: One or more
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
Is Contained by: D3-nn
Attribute : PARAMCODE – Energy parameter code
Value – Cumulative value of energy register.
Unit – Unit of the energy value i.e. k, M
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
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
Is Contained by: D3-nn
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
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
Is Contained by: D3-nn
Attribute : PARAMCODE – Energy parameter code
VALUE –Value of max demand register.
UNIT – Unit of the max demand value i.e. k,
M
OCCDATE – Max demand occurrence date
time stamp
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
(OCCDATE) - DateTime . The format is ddmm-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
Is Contained by: D3-nn
Attribute : TOD – TOD register number. This is linked
with TODZone attribute of B1 tag.
PARAMCODE – Energy parameter code
VALUE –Value of TOD max demand
register.
UNIT – Unit of the TOD max demand value
i.e. k, M
OCCDATE – Max demand occurrence date
time stamp
Occurrence: One or more
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
59 of 107
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
(OCCDATE) - DateTime . The format is ddmm-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
Is Contained by: D3-nn
Attribute : PARAMCODE – Energy parameter code
VALUE – Cumulative value of CMD register.
UNIT – Unit of the energy value i.e. k, M
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
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
Is Contained by: D3-nn
Attribute: TOD – TOD register number. This is linked
with TODZONE attribute of B1 tag.
PARAMCODE – Energy parameter code
VALUE – Cumulative value of TOD CMD
register.
UNIT – Unit of the energy value i.e. k, M
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
B9
Description: Contains data of average power factor.
This is for 24 hours.
Contains: None
Is Contained by: D3-nn
Attribute: PARAMCODE – Power factor parameter
Code
VALUE – Value of power factor.
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Is Contained by: D3-nn
Attribute: TOD – TOD register number. This is linked
with TODZONE attribute of B1 tag.
PARAMCODE – Power factor parameter
Code
VALUE – Value of power factor.
Occurrence: One or more
DataType: (TOD) – Numeric
(PARAMCODE) – Alphanumeric
(VALUE) - Numeric
B11
Description: Contains data of Power On duration time
since meter manufactured.
Contains: None
Is Contained by: D3-nn
Attribute: VALUE – Value of Power On duration. The
value will be in minutes
Occurrence: One or more
DataType: VALUE - Numeric
B12
Description: Contains data of Power Off duration time
since meter manufactured.
Contains: None
Is Contained by: D3-nn
Attribute: VALUE – Value of Power Off duration. The
value will in minutes
Occurrence: One or more
DataType: VALUE -Numeric
B13
Description: Contains data of cumulative tamper count.
Contains: None
Is Contained by: D3-nn
Attribute: VALUE – Value of cumulative tamper count.
Occurrence: One or more
DataType: VALUE -Numeric
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
B14
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
61 of 107
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
Is Contained by: D3-nn
Attribute : PARAMCODE – Energy parameter code
VALUE – Cumulative value of max demand
register.
UNIT – Unit of the max demand value i.e. k,
M
OCCDATE – Max demand occurrence date
time stamp
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
(OCCDATE) - DateTime . The format is ddmm-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
Is Contained by: D3-nn
Attribute : TOD – TOD register number. This is linked
with TODZone attribute of B1 tag.
PARAMCODE – Energy parameter code
VALUE – Cumulative value of TOD max
demand register.
UNIT – Unit of the TOD max demand value
i.e. k, M
OCCDATE – Max demand occurrence date
time stamp
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
(OCCDATE) - DateTime . The format is ddmm-yyyy hh:mm
B16
Description: Contains name of Tariff file
Contains: None
Is Contained by: D3-nn
Attribute :None
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
62 of 107
Occurrence: One or more
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.
Contains: Billing Data
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
Is Contained by: D3-nn
Attribute : PARAMCODE – Energy parameter code
Value – Cumulative value of energy register
during Magnetic Tamper.
Unit – Unit of the energy value i.e. k, M
Occurrence: One or more
Data Type: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
B20
Description: This contains event count between two
reset. This tag will repeat for all event supported.
Contains: Billing Data
Is Contained by: D3-01 to D3-nn.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
63 of 107
Attribute: 2-Attributes.
EVENTCODE-Holds the code of the event.
COUNT-Holds the count of the Tamper event occurred.
Occurrence: Multiple
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 .
Occurrence: One or more
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
Occurrence: One or more
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
Occurrence: One or more
DataType: (CODE) – Alphanumeric
(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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
64 of 107
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) – Numeric
(UNIT) – Alphanumeric
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
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(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.
Description: Contains code, time and status of the
EVENT
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.
Occurrence: One or more
DataType: (CODE) – Alphanumeric
(TIME) – DateTime . The format is dd-mmyyyy 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
Attribute: PARAMCODE – Parameter code
VALUE – Value of parameter
UNIT – Unit of parameter value.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
65 of 107
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(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
Occurrence: One or more
DataType: (CODE) – Alphanumeric
(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
Description: Contains the value for the date. This tag
SNAPSHOT
will repeat for all dates.
Contains: REGISTER
Is Contained by: D6
Attribute: DATETIME – Date time stamp of the
snapshot
Occurrence: One or more
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.
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(VALUE) –Numeric
(UNIT)- Alphanumeric
Daily duration indicator for the parameter between the specified threshold - This data contains
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Description: Contains the value for the date. This tag
DAILYDATA
will repeat for all dates.
Contains: REGISTER
Is Contained by: D7
Attribute: DATE – Date of the data i
Occurrence: One or more
DataType: DATE . The format is dd-mm-yyyy
REGISTER
Description: Contains the value for the date. This tag
will repeat for all dates.
Contains: None
Is Contained by: DAILYDATA
Attribute: PARAMCODE – Parameter code
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.
Occurrence: One or more
DataType: (PARAMCODE) – Alphanumeric
(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.
Description: Holds the value on which apparent
APPCALC
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
Public
Description: Holds the value of mechanism by which
MD reset can be done in the meter. The possible values
are
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
LOADSURVEYSETTING
DataType: 0, 1 or 2
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
PARAM
DataType:
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
Occurrence: One or More
MDSETTING
DataType: PARAMETER CODE
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
PARAM
DataType: INTERVALPERIOD - Integer
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
68 of 107
Occurrence: One or More
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
Description: Contains code, time and status of the
TRANSACTION
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
Occurrence: One or more
DataType: (CODE) – Alphanumeric
(TIME) – DateTime . The format is dd-mmyyyy hh:mm
Flags - <D10> tag is used for meter health information. This information can be used to find out faulty
meters.
Description: Contains code and value of flag. This tag
FLAG
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
Occurrence: One or more
DataType: (CODE) – Alphanumeric
(VALUE) – 0,1
Sag & Swell information- This contains value of Sag & Swell count. This is hold by tag D11.
Description: Contains the value for the date. This tag
DATA
will repeat for all dates.
Contains: SAGSWELL
Is Contained by: D11
Attribute: DATETIME – Date time stamp of the
snapshot
Occurrence: One or more
DataType: DATETIME . The format is dd-mm-yyyy
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
69 of 107
COUNT -- Value of Sag/Swell count.
Occurrence: One or more
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.
Description: It contains the type of automatic reset
RESET TYPE
which can be daily or monthly.
Attribute: 1 Represents daily & 2 Represents monthly.
DataTYpe: Numeric
Description: Contains the value for the date. This tag
ROOSTERDATA
will repeat for all dates.
Contains: ROOSTERING
Is Contained by: D12
Attribute: DATETIME – Date time stamp of the
snapshot
Occurrence: One or more
DataType: DATETIME . The format is dd-mm-yyyy
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
Occurrence: One or more
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>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
MM
UT
TP
Membership ID
MM001 for Secure,
MM002 for L&T etc.
UT001 for utility X
TP001 for Third Party
name ‘XX’
Member Type
Meter Manufacturer
X=MSEB
XX=IBM
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=”P1-1-2-1-0” VALUE=”220.34” UNIT=”V” />
<INSTPARAM CODE=”P1-1-3-1-0” VALUE=”250.34” UNIT=”V” />
<INSTPARAM CODE=”P2-1-1-1-0” VALUE=”40.34” UNIT=”A” />
<INSTPARAM CODE=”P2-1-2-1-0” VALUE=”50.34” UNIT=”A” />
<INSTPARAM CODE=”P2-1-3-1-0” VALUE=”55.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"/>
<B1 TODZONE="2" STARTTIME="07:00" ENDTIME="10:00"/>
<B1 TODZONE="1" STARTTIME="10:00" ENDTIME="17:00"/>
<B1 TODZONE="2" STARTTIME="17:00" ENDTIME="22:00"/>
<B1 TODZONE="1" STARTTIME="22:00" ENDTIME="00:00"/>
<B2 DATETIME=”01-07-2003 00:00” MECHANISM=”AUTO”/>
<B3 PARAMCODE="P7-1-5-1-0" VALUE="2000" UNIT="K"/>
<B3 PARAMCODE="P7-2-1-1-0" VALUE="2000" UNIT="K"/>
<B3 PARAMCODE="P7-3-5-1-0" VALUE="2000" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-2-5-1-0" VALUE="1000" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-2-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"
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
72 of 107
UNIT="K"/>
<B7 PARAMCODE="P7-4-5-1-0" VALUE="1200" UNIT="K"/>
<B8 TOD=“1” PARAMCODE="P7-4-5-1-0" VALUE="900" UNIT="K"/>
<B8 TOD=“2” PARAMCODE="P7-4-5-1-0" VALUE="700" 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”/>
<B3 PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B3 PARAMCODE="P7-2-1-1-0" VALUE="1200" UNIT="K"/>
<B3 PARAMCODE="P7-3-5-1-0" VALUE="600" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-2-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-2-5-1-0" VALUE="900" UNIT="K"/>
<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"/>
<B6 TOD=”2” PARAMCODE="P7-3-5-1-0" VALUE="650" OCCURENCEDATE="19-07-2003 12:15"
UNIT="K"/>
<B7 PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B8 TOD=“1” PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B8 TOD=“2” PARAMCODE="P7-1-5-1-0" VALUE="700" UNIT="K"/>
<B9 PARAMCODE="P4-4-4-0-0" VALUE="0.9" />
<B10 TOD="1" VALUE="0.8" />
<B11 VALUE=”123542”/>
<B12 VALUE=”4334”/>
<B16 VALUE=”TARIFFNAME”/>
</D3-01>
<D3-02 DATETIME="01-06-2003 00:00" MECHANISM=”AUTO”>
<B3 PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B3 PARAMCODE="P7-2-1-1-0" VALUE="1200" UNIT="K"/>
<B3 PARAMCODE="P7-3-5-1-0" VALUE="600" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="1" PARAMCODE="P7-2-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B4 TOD="2" PARAMCODE="P7-2-5-1-0" VALUE="900" UNIT="K"/>
<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"/>
<B6 TOD=”2” PARAMCODE="P7-3-5-1-0" VALUE="650" OCCURENCEDATE="19-07-2003 12:15"
UNIT="K"/>
<B7 PARAMCODE="P7-1-5-1-0" VALUE="1000" UNIT="K"/>
<B8 TOD=“1” PARAMCODE="P7-1-5-1-0" VALUE="900" UNIT="K"/>
<B8 TOD=“2” PARAMCODE="P7-1-5-1-0" VALUE="700" UNIT="K"/>
<B9 PARAMCODE="P4-4-4-0-0" VALUE="0.9" />
<B10 TOD="1" VALUE="0.8" />
<B11 VALUE=”123542”/>
<B12 VALUE=”4334”/>
<B16 VALUE=”TARIFFNAME”/>
</D3-02>
</D3>
Example 2
<D3>
<D3-00 DATETIME="27-08-2008 11:34" MECHANISM="">
<B17 VALUE = "41000"/>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
73 of 107
</D3-00>
<D3-01 DATETIME="27-07-2008 11:34" MECHANISM="">
<B17 VALUE = "40000"/>
</D3-01>
</D3>
Example 3
<D3>
<D3-00 DATETIME="27-08-2008 11:34" MECHANISM="">
<B18 PARAMCODE ="P7-6-5-2-0" COUNT="2"/>
<B18 PARAMCODE ="P7-6-5-3-0" COUNT="2"/>
</D3-00>
</D3>
Example 4
<D3>
<D3-00 DATETIME="27-08-2008 11:34" MECHANISM="">
<B19 PARAMCODE="P7-6-5-2-0" VALUE="3456.67" UNIT="k"/>
<B19 PARAMCODE="P7-6-5-1-0" VALUE="3456.67" UNIT="k"/>
</D3-00>
<D3-01 DATETIME="01-08-2008 11:34" MECHANISM="">
<B19 PARAMCODE="P7-6-5-2-0" VALUE="3456.67" UNIT="k"/>
<B19 PARAMCODE="P7-6-5-1-0" VALUE="3456.67" UNIT="k"/>
</D3-01>
</D3>
Example 5
<D3>
<D3-01 DATETIME="27-08-2008 11:34" MECHANISM="">
<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
Public
106
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Low PF
Current Reversal
Under Voltage
Over Voltage
Under Current
Over Current
Current Bypass
RTC Advance
RTC Retard
Magnetic Tamper
Neutral Disturbance
•
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
74 of 107
107
108
109
110
111
112
113
114
115
116
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 >
<PARAMETER PARAMCODE=”P7-1-5-1-0” VALUE=”0” UNIT=”K”>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”0” UNIT=”K”/>
</IP>
<IP INTERVAL =5 >
<PARAMETER PARAMCODE=”P7-1-5-1-0” VALUE=”102” UNIT=”K”>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”113” UNIT=”V”/>
</IP>
….
…
</DAYPROFILE>
<DAYPROFILE DATE=”02-07-2003” >
…..
….
</DAYPROFILE>
<D4 INTERVALPERIOD=”15”>
<DAYPROFILE DATE=”01/07/2003” >
<IP INTERVAL =1 >
<IFLAG CODE=’101’ VALUE=’1’/>
<IFLAG CODE=’102’ VALUE=’0’/>
<IFLAG CODE=’103’ VALUE=’1’/>
<PARAMETER PARAMCODE=”P7-1-5-1-0” VALUE=”0” UNIT=”K”>
<PFLAG CODE=’0’ VALUE=’1’/>
</PARAMETER>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”0” UNIT=”K”/>
</IP>
<IP INTERVAL =2 >
<IFLAG CODE=’101’ VALUE=’1’/>
<IFLAG CODE=’102’ VALUE=’0’/>
<PARAMETER PARAMCODE=”P7-1-5-1-0” VALUE=”102” UNIT=”K”>
<PFLAG CODE=’1’ VALUE=’1’/>
</PARAMETER>
<PARAMETER PARAMCODE=”P1-1-1-1-0” VALUE=”113” UNIT=”V”/>
</IP>
….
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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:
<D4 INTERVALPERIOD=”15”>
<DAYPROFILE DATE=”01-07-2003” >
<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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Public
Events
R phase potential missing
Y phase potential missing
B phase potential missing
R phase CT reversed
Y phase CT reversed
B phase CT reversed
Load imbalance
Load unbalance – R phase
Load unbalance – Y phase
Load unbalance – B phase
Overload(Current)
Low power factor
Power failed
Unbalance voltage
Unbalance voltage – R phase
Unbalance voltage – Y phase
Unbalance voltage – B phase
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
76 of 107
Invalid voltage inputs
CT short
CT short – R phase
CT short – Y phase
CT short – B phase
CT open
CT open – R phase
CT open – Y phase
CT open – B phase
Magnet
Neutral disturbance
High neutral current
R-Ph current missing
Y-Ph current missing
B-Ph current missing
High voltage
High voltage – R phase
High voltage – Y phase
High voltage – B phase
Over load (current) – R phase
Over load (current) – Y phase
Over load (current) – B phase
Low voltage – R phase
Low voltage – Y phase
Low voltage – B phase
Low current – R phase
Low current – Y phase
Low current – B phase
Power reversed – R phase
Power reversed – Y phase
Power reversed – B phase
Power failed in the presence of magnet
High second harmonics
High total harmonics distortion current
Low PF – R Phase
Low PF – Y Phase
Low PF – B Phase
Potential Missing
Current Reversal
Current Missing
Low Voltage
Low Current
Meter Cover Open
RTC Change
Energy Corruption
Gain Angle Corruption
Power Reversal
Abnormal Restart Detected
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
66
67
68
69
70
71
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
77 of 107
Invalid Phase Association
Over Load (Apparent Power)
Under Load (Apparent Power)
Short Term Over Load (Apparent Power)
Supply Status-FULL
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-2-1-0" VALUE="0" 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">
<SNAPSHOT PARAMCODE="P1-1-1-1-0" VALUE="240" UNIT="V"/>
<SNAPSHOT PARAMCODE="P1-1-2-1-0" VALUE="0" 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="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"">
<SNAPSHOT PARAMCODE="P1-1-1-1-0" VALUE="240" UNIT="V"/>
<SNAPSHOT PARAMCODE="P1-1-2-1-0" VALUE="0" 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>
<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
STATUS=’1’) then event tag will look like
both are supported by meter at the time of restoration (
<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"/>
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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>
<PARAM> P7-4-6-1-0</PARAM>
<PARAM> P1-1-1-1-0</PARAM>
</LOADSURVEYSETTING >
<MDRESETSETTING> 2</MDRESETSETTING>
<MDSETTING INTERVALPERIOD=30>
<PARAM> P7-4-5-1-0</PARAM>
<PARAM> P7-4-6-1-0</PARAM>
</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.
• Codes can be defined for each event such as
Code
1
2
3
4
5
6
7
8.
9
Public
Transaction
Externally written - single / multiple changes
Load survey configured
Time changed
Max demand reset human initiated (such as
PB, PC / MRI command) – Auto reset will
not get reflected here
Event log reset
TOD definition changed
Apparent energy calculation definition
changed
Max Demand settings changed (parameter
changed or integration period changed)
Max demand reset setting changed (type
Push button, command, auto reset &
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
79 of 107
combination thereof or auto reset date time
changed)
Time before time change. For this date time
attribute will contain the value of time before
time changed
Time after time change. For this date time
attribute will contain the value of time after
time changed
CT Reprogrammed
PT Reprogrammed
Display Programmed
Season Profile Programmed
Festival Days Programmed
Meter Programmed
Reset Info changed
KVAh configuration / Direction (Uni / Bidirectional ) Programmed
Tariff download- tariff definition
Tariff download- energy definition
Tariff download- bill dates
Meter Security- Unlock
Meter Security- Lock
Meter Security- Password changed
Configuration related transactions- Limit for
Underload/Overload/Short term overload
Configuration transactions- Persistence
time
Configuration transactions- Load survey
configuration
Configuration transactions- Display
parameter change
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.
The D9 tag will look like
<D9>
<TRANSACTION CODE=5 DATETIME=21/04/2006 12:10/>
<TRANSACTION CODE=3 DATETIME=25/04/2006 14:10/>
<TRANSACTION CODE=5 DATETIME=28/04/2006 10: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
•
Public
Codes can be defined for each event such as
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Code
1
2
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
80 of 107
Transaction
Real Time Clock(RTC) failure (bad battery, bad
RTC)
Memory failure
The D10 tag will look like
<D10>
<FLAG CODE=1 VALUE=0 />
<FLAG CODE=2 VALUE=1 />
</D10>
The D11 tag will look like
<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”/>
<SAG CODE=”2” COUNT=”221”/>
<SWELL CODE=”2” COUNT=”321”/>
<SAG CODE=”3” COUNT=”321”/>
<SWELL CODE=”3” COUNT=”451”/>
</DATA>
</D11>
The D12 tag will look like
<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)
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
1
2
Description
Phase to phase
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
Qualifier1 denotes the type of value. Table below defines the code.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Code
1
2
3
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
82 of 107
Description
Line Current
Active Current
Reactive Current
Qualifier2
Qualifier2 denotes phase. Table below defines the code
Code
Description
1
R- phase
2
Y-phase
3
B-phase
4
Neutral
5
System(All phases)
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
2
Maximum for defined duration
3
Minimum for defined duration
4
Average for defined duration
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
Qualifier1 denotes the type of value. Table below defines the code.
Code
1
2
3
4
Description
Active – Fundamental
Active – Total
Reactive
Apparent
Qualifier2
Qualifier2 denotes phase. Table below defines the code
Code
Description
1
R- phase
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
2
3
4
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
83 of 107
Y-phase
B-phase
System(All phases)
Qualifier3
Qualifier3 denotes whether it is maximum, minimum or average power. 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
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
Qualifier1 denotes phase. Table below defines the code
Code
Description
1
R- phase
2
Y-phase
3
B-phase
4
System(All phases)
Qualifier2
Qualifier2 denotes whether it is maximum, minimum or average voltage. Table below defines the code
Code
Description
1
Instantaneous
2
Maximum for defined duration
3
Minimum for defined duration
4
Average for defined duration
Qualifier3
Qualifier3 denotes the direction. Table below defines the code.
Code
0
1
2
Public
Description
Not applicable
Import
Export
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Qualifier1 denotes phase. Table below defines the code
Code
Description
3P,4W
3P, 3W
1
R phase angle
RY
2
Y phase angle
0
3
B phase angle
BY
Qualifier2
Qualifier2 is not applicable and hence 0 shall be used.
Qualifier3
Qualifier3 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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
Qualifier1 denotes phase. Table below defines the code
Code
Description
1
R phase
2
Y phase
3.
B phase
4
System
Qualifier2
Qualifier4 is not applicable and hence 0 shall be used.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
85 of 107
Qualifier3
Qualifier4 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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
Qualifier1 denotes the type of value. Table below defines the code.
Code
1
2
3
4
5
6
Description
Active energy
Reactive energy
Apparent energy
Active demand
Reactive demand
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
9
Q1-Q4
10
Q4-Q1
11
Q2-Q3
12
Q3-Q2
13
Q1+Q2+Q3+Q4
14
15
16
17
18
Q1+Q4-Q2-Q3
Q2+Q3-Q1-Q4
Q1+Q2-Q3-Q4
Q3+Q4-Q1-Q2
Forwarded
19
Forwarded (import)
20
Forwarded (export)
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
86 of 107
Reactive energy, lag – lead while
active import
Reactive energy, lead – lag while
active import
Reactive energy, lag – lead while
active export
Reactive energy, lead – Lag while
active export
Active ,reactive, appraent for all
quadrant ( Import + export)
Active (Import – Export)
Active (Export – Import
Reactive energy, import – export
Reactive energy, export – import
Sum of absolute values of all
Quandrants. This is to be used for
active.
Sum of absolute values of Q1 &
Q2. This is to be used for reactive.
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
0
1
2
3
Description
Not applicable
Fundamental
Total
Defrauded
Qualifier4
Qualifier4 is used for threshold based energy registers.
Code
0
1
2
3
4
5
Description
Not threshold based
Threshold based
Voltage Threshold based – High
(ABT application)
Voltage Threshold based – Low
(ABT application)
Maximum for defined duration
Minimum for defined duration
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
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
1
2
Description
Voltage
Current
Qualifier2
Qualifier2 is not applicable and hence 0 shall be used.
Qualifier3
Qualifier3 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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
2
Maximum for defined duration
3
Minimum for defined duration
4
Average for defined duration
Qualifier2
Qualifier2 is not applicable and hence 0 shall be used.
Qualifier3
Qualifier3 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
88 of 107
Qualifier1
Qualifier1 denotes phase. Table below defines the code
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
Qualifier2 is not applicable and hence 0 shall be used.
Qualifier3
Qualifier3 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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
1
2
Description
No Power ad
No Load
Qualifier2
Qualifier2 is not applicable and hence 0 shall be used.
Qualifier3
Qualifier3 is not applicable and hence 0 shall be used.
Qualifier4
Qualifier4 is not applicable and hence 0 shall be used.
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Data Format
(Generated by
CFC module)
Common
Data Format
(Generated by
CFC module)
Authenticator =
fn (Data + Seed)
Authenticator =
fn (Data + Seed)
10.2 Authenticator verifier
Manufact
urer’s
Data
CDF
API4
Authenticator
match or
Authenticator
mismatch
External Seed
CFW will pass the seed in configuration file of API3.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Secure
SMLMRD
SMLMRI
SMLCFC
L&T
LNTMRD
LNTMRI
LNTCFC
Datapro
DEPLMRD
DEPLMRI
DEPLCFC
Elster
ELSMRD
ELSMRI
ELSCFC
DukeArnics
DUKEMRD
DUKEMRI
DUKECFC
function
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
HSPL
HSPLMRD
HSPLMRI
HSPLCFC
Genus
GNSMRD
GNSMRI
GNSCFC
Easun
Reyrolle
ERLMRD
ERLMRI
ERLCFC
Capital
Power
CPSMRD
CPSMRI
CPSCFC
DCDMRD
DCDMRI
DCDCFC
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
91 of 107
Omniagate
Bentec
Delhi
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.
Public
Data/Description
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Public
Secure Meter Ltd – Mr. Surendra Jhalora Surendra.jhalora@securemeters.com
Elster – Mr. Ajit Magar ajit.magar@in.elster.com
L&T – Mr. Sanjay Ahuja ahujas@lntebg.com;
Genus – Mr. Rajesh Srivastava Rajesh.srivastava@genus.in
Easun Reyrolle – Mr. N. Suresh suresh.n@easunreyrolle.com
Omniagate – Mr. Muthu muthu@omniagate.com
HSPL – Mr. Rajesh Banthia banthia@hplindia.com
Capital Power – Mr. Vimal Shyam vimalshyam64@gmail.com
ICSA industries – Ivyjit Ivyjitsingh@icsa-india.com
Delhi Control Devices – Mr. Pushpendra Kumar Puspendra_kumar@rediffmail.com
Bentec Electri & electronic – Mr. Harjit Singh Harjit1973@gmail.com
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
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
Active Import
Reactive Export
PF Leading, < 0
Capacitive
Quadrant 1
Active Import
Reactive Import
PF Lagging, > 0
Inductive
Reactive
Quadrant 3
Active Export
Reactive Export
PF Lagging, > 0
Inductive
Quadrant 2
Active Export
Reactive Import
PF Leading, < 0
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
R-Phase phase to neutral instantaneous voltage
Y-Phase phase to neutral instantaneous voltage
Public
Parameter Code
P1-2-1-1-0
P1-2-2-1-0
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
B-Phase phase to neutral instantaneous voltage
System phase to neutral instantaneous voltage
R-Phase instantaneous Line Current
R-Phase instantaneous Active Current
R-Phase instantaneous Reactive Current
Y-Phase instantaneous Line Current
Y-Phase instantaneous Active Current
Y-Phase instantaneous Reactive Current
B-Phase instantaneous Line Current
B-Phase instantaneous Active Current
B-Phase instantaneous Reactive Current
Instantaneous neutral current
System active total instantaneous power
System reactive instantaneous power
System apparent instantaneous power
R-ph active total instantaneous power
Y-ph active total instantaneous power
B-ph active total instantaneous power
R-ph reactive instantaneous power
Y-ph reactive instantaneous power
B-ph reactive instantaneous power
R-ph apparent instantaneous power
Y-ph apparent instantaneous power
B-ph apparent power
R-Phase instantaneous Power Factor
Y-Phase instantaneous Power Factor
B-Phase instantaneous Power Factor
Average instantaneous Power Factor
Voltage angle Y-ph wrt R-ph
Voltage angle B-ph wrt R-ph
Power Factor angle R-ph
Power Factor angle Y-ph
Power Factor angle B-ph
Active import fundamental
Active import total
Active export fundamental
Active export total
Active forwarded fundamental
Active forwarded total
Active Sum(Imp+Exp)fundamental
Active sum (Imp+Exp)total
Active net (Imp-Exp)fundamental
Active net (Imp-Exp)total
Reactive import
Reactive export
Reactive all 4 quadrant
Reactive Q1
Reactive Q2
Reactive Q3
Reactive Q4
Reactive Q1 + Q4
Reactive Q2 + Q3
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
94 of 107
P1-2-3-1-0
P1-2-4-1-0
P2-1-1-1-0
P2-2-1-1-0
P2-3-1-1-0
P2-1-2-1-0
P2-2-2-1-0
P2-3-2-1-0
P2-1-3-1-0
P2-2-3-1-0
P2-3-3-1-0
P2-0-4-1-0
P3-2-4-1-0
P3-3-4-1-0
P3-4-4-1-0
P3-2-1-1-0
P3-2-2-1-0
P3-2-3-1-0
P3-3-1-1-0
P3-3-2-1-0
P3-3-3-1-0
P3-4-1-1-0
P3-4-2-1-0
P3-4-3-1-0
P4-1-1-0-0
P4-2-1-0-0
P4-3-1-0-0
P4-4-1-0-0
P5-1-0-0-0
P5-2-0-0-0
P6-1-0-0-0
P6-2-0-0-0
P6-3-0-0-0
P7-1-5-1-0
P7-1-5-2-0
P7-1-6-1-0
P7-1-6-2-0
P7-1-18-1-0
P7-1-18-2-0
P7-1-13-1-0
P7-1-13-2-0
P7-1-14-1-0
P7-1-14-2-0
P7-2-7-0-0
P7-2-8-0-0
P7-2-13-0-0
P7-2-1-0-0
P7-2-2-0-0
P7-2-3-0-0
P7-2-4-0-0
P7-2-5-0-0
P7-2-6-0-0
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Reactive Q1-Q4
Reactive Q2-Q3
Apparent Sum (all Quadrants)
Apparent while active import (Q1+Q4)
Apparent while active export (Q2+Q3)
Apparent Net
Apparent Q1
Apparent Q2
Apparent Q3
Apparent Q4
Phase sequence
Instantaneous frequency
No Power Duration
No Load Duration
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
95 of 107
P7-2-9-0-0
P7-2-11-0-0
P7-3-13-0-0
P7-3-5-0-0
P7-3-6-0-0
P7-3-14-0-0
P7-3-1-0-0
P7-3-2-0-0
P7-3-3-0-0
P7-3-4-0-0
P8-0-0-0-0
P9-1-0-0-0
P11-1-0-0-0
P11-2-0-0-0
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
Public
List of output file which are generated
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Doc. No. 001
Version
Date
Page
Table Of Contents
2.3
th
16 July 09
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.
No
2
3
Manufacturer’s
Name
Capital Power
System
Elster
L&T
4
5
Genus
Secure Meters
6
Easun Reyrolle
7
ICSA
8
9
10
HPL Socomec
Delhi control
devices
Bentec
11
12
Holley Meters
Omne-agate
1
Public
Folder Path for
temporary files for
API1, API2, API3
Application
path\garb
Application
path\temp
C:\CFW\Genus\temp
Application
path\temp
Application
path\temp
Application
path\temp
Application path\tmp
Application
path\temp
Windows
XP with
SP2 OS
Yes
Yes
Yes
Yes
Yes
RAM
CPU
1Gb
or
higher
P IV
2.4
GHz
or
higher
HDD
2 GB
or
higher
Supporting
Platform
.Net 2.0
JVM 1.6.0
.Net 2.0
Yes
.Net 2.0
No
additional
.Net 2.0
Yes
.Net 2.0
Yes
Yes
.Net 2.0
Yes
.Net 2.0
Yes
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
98 of 107
16 Document History
16.1 Version 01.00
Date
23rd Feb 2k4
Written
by
Author
Reviewed
by
SML, L&T,
Elster
Approved
by
SML, L&T,
Elster
Written
by
Author
Reviewed
by
SML, L&T,
Elster
Approved
by
SML, L&T,
Elster
SML, L&T,
Elster
Approved
by
SML, L&T,
Elster
Reviewed
by
SML, L&T,
Elster
Approved
by
SML, L&T,
Elster
Reviewed
by
SML, L&T,
Elster
Approved
by
SML, L&T,
Elster
Initial template for use.
16.2 Version 01.10
Date
01st Mar 2k4
st
Modified during the meeting held on 1 and 2
nd
March.
16.3 Version 01.20
Date
1st Mar 2k4
Written
by
Author
st
Reviewed
by
nd
Restructured after the meeting held on 1 and 2
March
16.4 Version 01.30
Date
02nd Apr 2k4
Written
by
Author
Modified during the meeting held on 2
nd
April.
16.5 Version 01.40
Date
15th Apr 2k4
Written
by
Author
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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)
Public
Energy data selective option is removed from dictionary of reading configuration.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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)
Public
Added additional error code.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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 D3nn
16.13 Version 01.12
a) HPL API and contact person added.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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.
Public
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
•
•
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
•
Public
The diagram changed
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.
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
•
•
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
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
File Name: MIOS Universal Meter Reading common format V2.3.doc
Universal Meter Reading & Common
Format
Table Of Contents
o
Public
Doc. No. 001
Version
Date
Page
2.3
th
16 July 09
107 of 107
B17(Billing period power on duration), B18 (Energy cross over count), B19
(Cumulative energy during magnetic tamper) , B20 (Reset specific information) added
File Name: MIOS Universal Meter Reading common format V2.3.doc
Download