MIOS Universal Meter Reading Common Format V3.0 PDF

Universal Meter Reading & Common Format
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10
1 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 RESPONSIBILITY OF CFW................................................................................................. 7 3.2 RESPONSIBILITY OF MANUFACTURERS 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 .......................................................................................................... 17 6.1 RESPONSIBILITY OF CFW FOR METER READING .............................................................. 17 6.2 RESPONSIBILITY OF MANUFACTURERS READING MODULE (API 1)................................... 18 6.3 READING CONFIGURATION FILE ...................................................................................... 19 6.3.1 Dictionary for reading configuration file ..................................................................... 20 6.3.2 Connection type ........................................................................................................ 27 6.4 RESULT FILES ................................................................................................................ 27 6.4.1 Dictionary for result file.............................................................................................. 27 6.4.2 Result Code............................................................................................................... 29 6.4.3 Support to read remote device having one or multiple meter data............................ 29 6.5 GPRS METER READING .................................................................................................. 30 7 PREPARING MRI AND DOWNLOADING DATA FROM MRI....................................... 31 7.1 RESPONSIBILITY OF CFW FOR PREPARING MRI AND DOWNLOADING DATA FROM MRI..... 32 7.2 RESPONSIBILITY OF PREPARING MRI AND DOWNLOADING DATA FROM MRI (API2).......... 32 7.3 PREPARING MRI AND DOWNLOADING DATA FROM MRI CONFIGURATION FILE .................. 33
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 2 of 113
7.3.1 Dictionary of preparing MRI and downloading data from MRI configuration file........ 34 7.4 MRI RESULT FILE .......................................................................................................... 40 7.4.1 Dictionary for MRIRESULT result file ........................................................................ 40 7.4.2 Result Code-DOWNLOAD MODE ............................................................................ 42 7.4.3 Result Code-PREPARE MODE ................................................................................ 42 8 CONVERTING TO COMMON FORMAT ........................................................................ 42 8.1 RESPONSIBILITY OF CFW FOR CONVERTING TO CDF ...................................................... 43 8.2 RESPONSIBILITY OF COMMON FORMAT CONVERTER MODULE (API3)................................ 43 8.3 CFC CONFIGURATION FILE ............................................................................................. 43 8.3.1 Dictionary for CFC configuration file.......................................................................... 44 8.4 RESULT FILE .................................................................................................................. 46 8.4.1 Dictionary for CFCResult file ..................................................................................... 46 8.4.2 Result Code............................................................................................................... 48 9 COMMON DATA FORMAT (CDF) ................................................................................. 49 9.1 DATA FORMATS POSSIBLE ALTERNATE ....................................................................... 49 9.2 PROPOSED COMMON FILE FORMAT ................................................................................. 49 9.2.1 Dictionary of common file format............................................................................... 49 9.2.2 CDF ........................................................................................................................... 73 9.2.3 Utility Type................................................................................................................. 73 9.2.4 General Information................................................................................................... 73 9.2.5 Instantaneous parameter .......................................................................................... 74 9.2.6 Billing registers data .................................................................................................. 75 9.2.7 Profile data ................................................................................................................ 77 9.2.8 Events Data............................................................................................................... 79 9.2.9 Daily energy snapshot............................................................................................... 81 9.2.10 Duration data within thresholds ............................................................................... 81 9.2.11 Current meter settings............................................................................................. 81 9.2.12 Transaction Data ..................................................................................................... 82 9.2.13 Flag Data................................................................................................................. 83 9.3 PARAMETER CODES ....................................................................................................... 84 9.3.1 Parameter type.......................................................................................................... 84 9.3.2 Voltage ...................................................................................................................... 85 9.3.3 Current ...................................................................................................................... 86 9.3.4 Power ........................................................................................................................ 86 9.3.5 Power factor .............................................................................................................. 87 9.3.6 Voltage Angles .......................................................................................................... 88 9.3.7 Power factor Angles .................................................................................................. 88 9.3.8 Energy / Demand ...................................................................................................... 89 9.3.9 Phase Sequence ....................................................................................................... 91 9.3.10 Frequency ............................................................................................................... 91 9.3.11 Current angles......................................................................................................... 92 9.3.12 Duration................................................................................................................... 92
Public
File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 3 of 113
10 INTEGRITY CHECK OF CDF ....................................................................................... 93 10.1 AUTHENTICATOR GENERATOR ...................................................................................... 93 10.2 AUTHENTICATOR VERIFIER ........................................................................................... 94 11 FUTURE EXPANDABILITY.......................................................................................... 94 12 LOG MAINTENANCE ................................................................................................... 95 13 APPROVAL OF NEW TAGS ........................................................................................ 97 14 GLOSSARY OF TERMS............................................................................................... 97 14.1 14.2 14.3 14.4 14.5 14.6 NOT APPLICABLE QUALIFIER IN A PARAMETER CODE ..................................................... 97 RETENTION OF DATA IN CASE OF MORE THAN ONE DATA SOURCE .................................. 97 DEFINED DURATION ...................................................................................................... 97 QUADRANT DEFINITION................................................................................................. 97 PHASE SEQUENCE ....................................................................................................... 98 PARAMETER CODE LIST ................................................................................................ 98
15 ANNEXURE ................................................................................................................ 100 15.1 15.2 15.3 15.4 API COMPATIBILITY WITH READING CONFIGURATION FILE ............................................ 100 ADDING MANUFACTURER SPECIFIC TAGS .................................................................... 101 FOLDERS PATH FOR TEMPORARY FILES AND SOFTWARE HARDWARE SPECIFICATION .... 101 MII PROTOCOL MESSAGE CLASSIFICATION ................................................................. 102
16 DOCUMENT HISTORY............................................................................................... 103 16.1 VERSION 01.00 .......................................................................................................... 103 16.2 VERSION 01.10 .......................................................................................................... 103 16.3 VERSION 01.20 .......................................................................................................... 103 16.4 VERSION 01.30 .......................................................................................................... 104 16.5 VERSION 01.40 .......................................................................................................... 104 16.6 VERSION 01.50 .......................................................................................................... 104 16.7 VERSION 01.60 (OCT 01, 2004) ................................................................................. 105 16.8 VERSION 01.70 (NOV 04 2004) .................................................................................. 105 16.9 VERSION 01.80 (DEC 28 2004) .................................................................................. 106 16.10 VERSION 01.90(18TH JAN 05) ................................................................................... 107 16.11 VERSION 01.10(18TH JAN 05).................................................................................. 107 16.12 VERSION 01.11 ........................................................................................................ 108 16.13 VERSION 01.12 ........................................................................................................ 108 16.14 VERSION 1.13 .......................................................................................................... 108 16.15 VERSION 1.14 .......................................................................................................... 109 16.16 VERSION 1.15 .......................................................................................................... 109
Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 4 of 113
16.17 VERSION 1.16 .......................................................................................................... 109 16.18 VERSION 1.17 .......................................................................................................... 109 16.19 VERSION 1.18 .......................................................................................................... 109 16.20 VERSION 1.19 .......................................................................................................... 110 16.21 VERSION 1.20 .......................................................................................................... 110 16.22 VERSION 1.21 .......................................................................................................... 110 16.23 VERSION 1.22 .......................................................................................................... 110 16.24 VERSION 2.0 30TH MEETING 24TH NOV 2008 ........................................................... 111 VERSION 2.0 30TH MEETING 24TH NOV 2008................................................................... 111 VERSION 2.1 31ST MEETING 21ST JAN 2009 .................................................................. 111 VERSION 2.2 33RD MEETING 8TH MAY 2009 .................................................................... 111 VERSION 2.3 34TH MEETING 16TH JULY 2009 ................................................................ 112 VERSION 2.4 37TH MEETING 17TH DEC 2009 ................................................................. 112 VERSION 2.5 38TH MEETING 08TH JUNE 2010 ............................................................... 113 VERSION 2.6 39TH MEETING 07 AUG 2010 .................................................................... 113 VERSION 3.0 ................................................................................................................... 113
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 5 of 113
1
1.1
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 its 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 and API are not expected to reside on MRI. MRIs will continue to operate as it is operating today whereby different manufacturers software co-exists on a common MRI. For transferring data from MRI to CFW or vice versa API 2 is required at CFW end. 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 manufacturers 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
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 6 of 113
1.3
Name PC CFW CDF API API1 API2 API3 API4 Seed XML Bill Date/ billing
Definitions & Abbreviations

Description Personal Computers whose design is derived from original IBM personal computer architecture Common framework Common data format Application program interface Manufacturers reading module Manufacturers MRI downloading module Manufacturers CDF convert module Manufacturers 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.
1.4
No. 1 2
References
Name XML RIPEMD 160 Description Legal site on XML standard www.w3c.org Algorithm for authentication. www.esat.kuleuven.ac.be
1.5 1.6
Pre-Requisites (Optional) Overview (Optional)
2 Key Point (Optional)

One of the simplest way to resolve this issue is to enforce all the meter manufacturers 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
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 7 of 113
3 Common Frame-Work (CFW)

Common Frame-Work (CFW) Meter Make #1
#1 MRD
#1 MRI
#1 CFC
#2 MRD
#2 MRI
#2 CFC
Meter Make #2
#3 MRD #3 MRI #3 CFC
Common Data Format (CDF)
Meter Make #3
Manufacturers Reading (MRD) modules (API1)
Manufacturers MRI Downloading & Prepare (MRI) module (API2)
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 APIs 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) c) d) To schedule meter reading To decide & supply information to be read from meter to reading API 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 V3.0
Doc. No. 001
Table Of Contents
g)
Version Date Page
3.0 th 26 Aug 10 8 of 113
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 CFWs 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 manufacturers 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 manufacturers API

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.
The manufacturers API will follow the rules as described below:
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 9 of 113
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 IP address and Port number
Common framework program
Manufacturers 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. 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. File Name: MIOS Universal Meter Reading common format V3.0
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 10 of 113
CFW will control the traffic to the API & on TCP/IP message stream. 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
Field Header Length Data Length Command Command qualifier Additional command Qualifier (Instance number) Instance Id Size 2 4 2 2 2 Fixed Value 16
The message header would be comprised of the following fields:
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
Command Set
Purpose Command qualifier (CQ) 00:Meter reading 01:MRI read 02:MRI prepare 03:Convert to common format Additional Qualifier (AQ) 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 Type of command wrt CFW Request Data Flow
01
Start
CFW to API
02
Acknowled ge start operation
00: Receipt of Reading command 01:Receipt of MRI download
Response
API to CFW
Public
Doc. No. 001
Table Of Contents
command 02:Receipt of MRI prepare command 03:Receipt of Convert to common format command 02: Failed due to Invalid configuration file. 03: Invalid or unknown command 04: command not supported 05: Falied due to invalid instance Id 00: Abort 01: Abort & close
Version Date Page
3.0 th 26 Aug 10 11 of 113
03
Abort & close Operation
04
Report progress
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
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
Response
API to CFW
Public
Doc. No. 001
Table Of Contents
found 60 :User Abort 61: Process stopped - 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.
Version Date Page
3.0 th 26 Aug 10 12 of 113
Public
Doc. No. 001
Table Of Contents
05 Request for progress status 00:Meter reading 01:MRI download 02:MRI prepare 03:Convert to common format 00:Default value
Version Date Page
3.0 th 26 Aug 10 13 of 113
Request
CFW to API
06
07
Request for API identificatio n Response to API identificatio n command
00:Default value
Request
CFW to API
00:Default value
00:Default value
Response
API to CFW
5.2.1
The Data portion of each command Comm and qualifi ers All Data Field No 1 Field Name Field Description
Command No
001
Configuration file name
004
All
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 14 of 113
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 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 Public
Size
Example
Doc. No. 001
Table Of Contents
Header Length Data Length Command Command Qualifier Additional Qualifier Instance Number 2 4 2 2 2 4 16 0041 04 00 00 0001
Version Date Page
3.0 th 26 Aug 10 15 of 113
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 Public Size 2 4 2 Example 16 0041 05
Doc. No. 001
Table Of Contents
Command Qualifier Additional Qualifier Instance Number 2 2 4 00 00 0001
Version Date Page
3.0 th 26 Aug 10 16 of 113
Header would be: 1600018500000001 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.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 17 of 113
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 each meter is read sequentially. Next meter reading is started once first meter reading is completed.
User selects the operation to be performed
Connection details (Connection type, Baudrate, Device ID, What to read from meter? ReadMeter Audit trail/ Result log Common framework program Manufacturers Reading (MR) modules (API)
Meter Make #1
Meter Make #2
Meter Make #3
6.1
Responsibility of CFW for meter reading

1) Create reading configuration file. The naming convention of read configuration is INSTANCEID_READCFGFILE. This will contains the information about connection, data to be read and paths/names of intermediate files. 2) Decide & Invoke respective meter manufacturers 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.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 18 of 113
8) CFW should support multi threading for API1. The CFW should be capable of handling multiple meters, read over TCP/IP showing Instance ID wise message, of respective manufacturer API for progress status. 9) CFW should be able to launch multiple instances for different manufacturers API1, API2 & API3 (one instance per manufacturer). 10) The CFW should assign unique Instance ID to API1. 11) The support of GPRS communication by CFW is through static Public IP and Port and the same should be configured at GPRS modem. 12) The interval for establishing connection between modem & CFW should be supported.
6.2
Responsibility of manufacturers reading module (API 1)

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. The Result file naming convention is INSTANCEID_READRESULTFILE. 4) API should start the operation only after verifying that it has been invoked by CFW. 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 manufacturers 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 APIs can assume that modem will be at above setting before using the modem for meter reading. This is required so that APIs from different manufacturer can use same modem. 12) Entire set of manufacturers 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.
Responsibility of manufacturer reading modules is
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 19 of 113
17) The API1 should support multi threading, with unique Instance ID. The API1 Should gives the TCP/IP Progress message Instance ID wise. 18) The API1 should maintain the log information for each and every instance ID wise.
6.3
Reading Configuration file
The naming convention of reading configuration file is INSTANCEID_READRESULTFILE for e.g. 0002_READRESULTFILE The structure of the reading configuration will look like
<READAPI> <INSTANCEID>0009</INSTANCEID> <CONNECTIONDETAIL> <CONNECTIONTIMEOUT>2000</ CONNECTIONTIMEOUT > <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> <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>
Public
Doc. No. 001
Table Of Contents
<TAMPERRESET>No</TAMPERRESET> </COMMAND> </READAPI>
Version Date Page
3.0 th 26 Aug 10 20 of 113
6.3.1 Element READAPI
Dictionary for reading configuration file Details Description: This is root element of configuration file Contains: InstanceID, ConnectionDetails, PathandName and command Is Contained by: None Attribute : None Occurrence: Single DataType : N/A WhatToRead,
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, MODEMCONFIGFILE, TELEPHONENUMBER Is Contained by: READAPI Attribute : None Occurrence: Single DataType: N/A
CONNECTIONTIMEOUT
Description: Holds value of connection time out of command send from API to modem. The Connection timeout in millisecond. Contains: None Is Contained by: CONNECTIONDETAILS Attribute : None
Public
Doc. No. 001
Table Of Contents
Occurrence: Single
DataType: Numeric MODEMMAKE
Version Date Page
3.0 th 26 Aug 10 21 of 113
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, DynamicIPGPRS, 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
TELEPHONENUMBER
Description: Holds value of telephone number Contains: None
Public
Doc. No. 001
Table Of Contents
Is Contained by: CONNECTIONDETAIL Attribute : None Occurrence: Single DataType: Alphanumeric DIALRETRY
Version Date Page
3.0 th 26 Aug 10 22 of 113
Description: Holds value of maximum dial retries count in case of unsuccessful attempts. Contains: None Is Contained by: CONNECTIONDETAIL Attribute : None Occurrence: Single DataType: Numeric
PORT
Description: Holds value of Comport Com1, Com2, Comn, or TCP port address for TCP/IP connection type such as 80h, 81h etc at computer end. Contains: None 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
SERIAL
Description: Holds the value of meter serial number
Public
Doc. No. 001
Table Of Contents
Contains: None
Version Date Page
3.0 th 26 Aug 10 23 of 113
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
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 24 of 113
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 V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 25 of 113
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
Public
Doc. No. 001
Table Of Contents
Attribute : None Occurrence: Single DataType: Alphanumeric COMMAND
Version Date Page
3.0 th 26 Aug 10 26 of 113
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
Doc. No. 001
Table Of Contents
6.3.2 Connection type Description
Version Date Page
3.0 th 26 Aug 10 27 of 113
ConnectionType tag values Direct
Local connection through RS232, One to one or one to many Connection through telephone line via telephone line modem Connection through GSM modems Connection through GPRS modems Connection through Low Power Radio Local connection through RS485, One to one or one to many Connection through TCP/IP connection
PSTN
GSM GPRS RF RS485
TCP/IP
6.4
Result files
The purpose of this file is to give result of reading operation which can be used by CFW for deciding next course of action. This file is the common file for all manufacturers. All manufacturers will follow strict format of this file. The naming convention of Result file is INSTANCEID_READCFGFILE For e.g. 0002_READCFGFILE 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 Element
Dictionary for result file Description
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 28 of 113
READINGRESULT
Description: This is root node for reading 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 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 29 of 113
OUTPUTFILENAME
Description: Holds value of manufacturer specific file made by reading A Contains: None Is Contained by: INSTANCE Attribute : None Occurrence: Multiple DataType: Alphanumeric
RESULT
Description: Holds the value of result of the reading operation. Contains: None Is Contained by: INSTANCE Attribute : None Occurrence: Single DataType: Alphanumeric
DEVIATION
Description: Holds the sub-tags of WhatToRead tag for which deviation is taken. Contains: Empty sub-tags of WHATTOREAD Is Contained by: Instance Attribute : None Occurrence: Single DataType: None
6.4.2
Result Code Description Success Failure Success with Deviation
Result Code 0 1 2
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 its 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. Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents 6.5 GPRS meter reading
Version Date Page
3.0 th 26 Aug 10 30 of 113
The following steps are required for meter reading on GPRS network (Applicable for modem having dynamic IP) 1) Modem side setting a. Modem should have provision of configuring -- APN number, IP address, port number where connection is to be made etc. b. The modem configuration tool shall be provided by the modem manufacturer. c. System Integrator should assign unique port number for each meter manufacturer & configure the modem using modem configuration tool to identify the meter make based on port on which connection is received & invoke relevant API for e.g. 81 for L&T, 82 for Secure, 83 for HSPL and so on.
d. Each modem should have unique modem Id. (Factory set) 2) Operation a. Each modem will establish the connection with CFW on public IP address and port number configured within it. b. At the time of establishing connection modem will pass on following information in comma separated format. 1. MODEM_ID 2. METER_ID Example -- MODEM_ID=MDM00001,METER_ID=MTR00001/r Note: /r means the carriage return c. If multiple meters (of same manufacturer) are connected to same modem then meter id should be separated by : File Name: MIOS Universal Meter Reading common format V3.0
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 31 of 113
Example -MODEM_ID=MDM00001,METER_ID=MTR00001:MTR00002:MTR00003/r d. CFW will allocate & maintain a unique connection ID for each modem when connected. e. CFW will decide its course of action based on information passed on by modem, regarding port number & meter id & whether meter data is to be acquired or not as per schedule. f.
g.
If meter is to be read then CFW will pass on instance id to API through read CFG file. When invoked API will connect to CFW via IP address (TELEPHONENUMBER tag) and port number (PORT tag) specified in the Read CFG file.
1. <PORT>123456</PORT> 2. < TELEPHONENUMBER >120.75.29.30</ TELEPHONENUMBER >
h. API will return the instance ID to CFW for the meter reading request to connect to the correct socket. i. The CFW will check the validity of existing connection (which may not be valid on account of modem connection drop or modem timeout) & will send following reply to API 1. CONNECTOK/r - If instance ID which is returned by API is matching with the unique connection ID as maintained by CFW 2. CONNECTIONFAIL/r - If instance ID which is returned by API is not matching with the unique connection ID maintained by CFW j. k. API will collect data & update the result file as detailed in section number 6.2 Connection of modem (socket) will be closed by API & unique connection ID will be removed by CFW.
7 Preparing MRI and downloading data from MRI

This function enables CFW to prepare the MRI or download data from MRI.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 32 of 113
Assumption: Prepare MRI and download data from MRI operation cannot execute on single request or single configuration file.
7.1
Responsibility of CFW for Preparing MRI and downloading data from MRI
User selects the operation to be performed Communication and other details (MRI type, Baudrate, What to read from meter/MRI ..? Clear MRI ? Invoke MRI API with above details Common framework program
MRI Make #1
Clear MRI MRI Operation Prepare Result log Manufacturers MRI Prepare & Downloading modules (API) MRI Make #3 MRI Make #2
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.
Public
Doc. No. 001
Table Of Contents
b. Upload schedule files in MRI. c. Create result file.
Version Date Page
3.0 th 26 Aug 10 33 of 113
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
Public
Doc. No. 001
Table Of Contents
</PATHANDNAME> </PREPARE> </MRIAPI>
Version Date Page
3.0 th 26 Aug 10 34 of 113
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) </PATHANDNAME> </DOWNLOAD> </MRIAPI> 0002_MRIRESULTFILE.XML</RESULTFILE> (ALWAYS IN APPEND
7.3.1
Dictionary of preparing MRI and downloading data from MRI configuration file Description 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
Element MRIAPI
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 File Name: MIOS Universal Meter Reading common format V3.0
Public
Doc. No. 001
Table Of Contents
digit. Contains: None Is Contained by: MRIAPI Attribute : None Occurrence: Single DataType: Numeric WHICHMRI
Version Date Page
3.0 th 26 Aug 10 35 of 113
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 File Name: MIOS Universal Meter Reading common format V3.0
Public
Doc. No. 001
Table Of Contents
Contains: None Is Contained by: MRIAPI Attribute : None Occurrence: Single DataType: Alphanumeric IP ADDRESS
Version Date Page
3.0 th 26 Aug 10 36 of 113
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 37 of 113
Contains: MRIDataFilePath, PCDataFilePath, ResultFile Is Contained by: DOWNLOAD Attribute : None Occurrence: Single 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Is Contained by: MRIAPI Attribute : None Occurrence: Single DataType: Numeric WHATTOREAD
Version Date Page
3.0 th 26 Aug 10 38 of 113
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 39 of 113
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. 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 40 of 113
RESULTFILE
Description: Holds the name of file which contains consequence of the operation. Contains: None Is Contained by: PATHANDNAME Attribute : None 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 Description 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
Element MRIRESULT
Public
Doc. No. 001
Table Of Contents
DataType: N/A INSTANCE
Version Date Page
3.0 th 26 Aug 10 41 of 113
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 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.
Public
Doc. No. 001
Table Of Contents
Contains: None Is Contained by: INSTANCE Attribute : None Occurrence: Single DataType: Alphanumeric RESULT
Version Date Page
3.0 th 26 Aug 10 42 of 113
Description: Holds the value of result of prepare or downloads operation. Contains: None Is Contained by: INSTANCE Attribute : None Occurrence: Single DataType: Numeric
7.4.2
Result Code-DOWNLOAD MODE Description Success Failure Partial Success On multiple meter data transfer all files are not transferred. Result Code-PREPARE MODE
Result Code 0 1 2
7.4.3
Result Code 0 1
Description Success 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
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 43 of 113
User selects the data to be converted in Common data format
#1 CFC Source file path Destination file path, Seed #2 CFC #3 CFC ConvertToCDF Result file Common framework program Common format Converter (CFC) module (API) Common Data Format (CDF)
8.1
Responsibility of CFW for converting to CDF

1) Provide destination file path to API. 2) Decide further course of action based on result file
8.2
Responsibility of common format converter module (API3)
1) One instance of meter reading will generate one CDF file. 2) Converting the data from manufacturer specific format to common data format & shifting the manufacturer specific file from conversion pending folder to conversion done folder after successful conversion. In case of conversion fails API should move manufacturer specific format data in conversion error folder. 3) One CDF file will be created for one meter reading operation. 4) Destination File Name will always be Serial Date Time.XML (such as Filename ABC00001 yyyymmdd hhmmss.XML). Date & time of creation of CDF file. Converted file should have extension as .XML 5) Creating result file. 6) API shall take path/filenames and other parameter specified in configuration files provided to the API and should not hardcode anything. Tag values written in this document are suggested paths and are for example only
8.3
CFC Configuration file
This file contains the information which will be used by CDF converting module to convert the manufacturer specific format file to CDF file. The structure of CFC configuration file is
<CFCAPI> <INSTANCEID>0001</INSTANCEID> <SOURCEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONPENDING</SOURCEPATH>
Public
Doc. No. 001
Table Of Contents
<DONEPATH>C:\CFC\MANUFACTURER\ABC\CONVERSIONDONE</DONEPATH> <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>
Version Date Page
3.0 th 26 Aug 10 44 of 113
<RESULTFILE> C:\CFC\MANUFACTURER\ABC\RESULT\CFCRESULT01.XML</RESULTFILE>. </CFCAPI>
8.3.1
Dictionary for CFC configuration file Descption 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
Element CFCAPI
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
Public
Doc. No. 001
Table Of Contents
Is Contained by: CFCAPI Attribute : None Occurrence: Single DataType: Alphanumeric ERRORPATH
Version Date Page
3.0 th 26 Aug 10 45 of 113
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 46 of 113
SEED
Description: Holds license key from which authenticator will be generated. If seed tag is not in configuration file then no authenticator will be generated in CDF file 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 Description Description: This is root node for CFCResult file Contains: INSTANCE
Element CFCRESULT
Public
Doc. No. 001
Table Of Contents
Is Contained by: None Attribute : None Occurrence: Single DataType: N/A INSTANCE
Version Date Page
3.0 th 26 Aug 10 47 of 113
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 Public
Description: Holds the value of the date time format which is applicable for File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 48 of 113
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 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 Error Success Failure
Result Code 0 1
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 49 of 113
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 days 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 Description 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
Element CDF
Public
Doc. No. 001
Table Of Contents
Contains: None Is Contained by: CDF Attribute : None Occurrence: Single DataType: Alphanumeric
Version Date Page
3.0 th 26 Aug 10 50 of 113
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 51 of 113
D4
Description: This contains profile data for an integration period. This data can have profile for different electricity parameter. Contains: DAYPROFILE 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 52 of 113
Contains: APPCALC , LOADSURVEYSETTING, MDSETTING Is Contained by: UTILITYTYPE Attribute : 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: Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 53 of 113
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 G1 Description: Holds the value of meter serial number. This is the metering device ID which uniquely identifies the metering device. Origin of data: Manufacturer API Contains: None Is Contained by: D1 Attribute : None Occurrence: Single 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 54 of 113
Occurrence: Single DataType: Date time. The format of date time is dd-mmyyyy hh:mm:ss G7 Description: Holds the value of ratio of Programmed PT Primary to Programmed PT secondary in meter. 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 Public
DataType: Numeric Description: Holds the value of Programmed PT File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 55 of 113
Secondary 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 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 DataType: Alphanumeric. Can only take values defined Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 56 of 113
G16
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 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
Public
Doc. No. 001
Table Of Contents
DataType: Alphanumeric G22
Version Date Page
3.0 th 26 Aug 10 57 of 113
Description: Holds the value of manufacturer code and name. Origin of data: Manufacturer API Contains: None Is Contained by: D1 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
Public
Doc. No. 001
Table Of Contents
Attribute : None Occurrence: Single G27
Version Date Page
3.0 th 26 Aug 10 58 of 113
DataType: Alphanumeric Description: Holds the value of Data Validation status. This checks the integrity of data Origin of data: Manufacturer API Contains: None 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
Public
Doc. No. 001
Table Of Contents
Is Contained by: D1 Attribute : None Occurrence: Single G34
Version Date Page
3.0 th 26 Aug 10 59 of 113
DataType: Alpha Numeric Description: Holds the value of Meter range. (Standard, long range) Origin of data: Manufacturer API 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) Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 60 of 113
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 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 61 of 113
(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 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 62 of 113
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 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 63 of 113
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 (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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 64 of 113
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 B14 Description: Contains data of sliding window Max Demand registers. These registers contain value for 24 hours max demand. This tag will repeat for all energies supported. Contains: None 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 65 of 113
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 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: Counts.
This
contains
Energy
Crossover
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 66 of 113
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.

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 IPs 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 67 of 113
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 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. COMPARTMENTID this attribute is optional and indicate the compartment id of event code. Occurrence: One or more Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 68 of 113
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. 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 69 of 113
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 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 70 of 113
(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 Description: Holds the value of mechanism by which MD reset can be done in the meter. The possible values are 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 Public DataType: PARAMETER CODE Description: Holds the value for the max demand File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 71 of 113
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 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. Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
DATA
Version Date Page
3.0 th 26 Aug 10 72 of 113
Description: Contains the value for the date. This tag 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 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
Public
Doc. No. 001
Table Of Contents
previous day / month Occurrence: One or more
Version Date Page
3.0 th 26 Aug 10 73 of 113
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> . </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>
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 74 of 113
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. 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>
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 75 of 113
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="3" STARTTIME="10:00" ENDTIME="17:00"/> <B1 TODZONE="4" STARTTIME="17:00" ENDTIME="22:00"/> <B1 TODZONE="5" 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" 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>
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 76 of 113
<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"/> </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> Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
<D3-01 DATETIME="27-08-2008 11:34" MECHANISM=""> <B20 EVENTCODE ="2" COUNT="2"/> <B20 EVENTCODE ="11" COUNT="2"/> </D3-01> </D3>
Version Date Page
3.0 th 26 Aug 10 77 of 113
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 Low PF Current Reversal Under Voltage Over Voltage Under Current Over Current Current Bypass RTC Advance RTC Retard Magnetic Tamper Neutral Disturbance
106 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>
Public
Doc. No. 001
Table Of Contents
<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> . </DAYPROFILE> <DAYPROFILE DATE=02/07/2003 > .. . </DAYPROFILE> </D4>
Version Date Page
3.0 th 26 Aug 10 78 of 113
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>
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 79 of 113
9.2.8 Events Data <D5> tag is used events data information. Events data contains events code and sometimes snapshot of the electrical parameters when the event occurred. Codes can be defined for each event such as Code Events 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 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 File Name: MIOS Universal Meter Reading common format V3.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Public
Doc. No. 001
Table Of Contents
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
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
Version Date Page
3.0 th 26 Aug 10 80 of 113
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 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" COMPARTMENTID=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="2" TIME="15-07-2003 11:23:20" STATUS="1 COMPARTMENTID=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>
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 81 of 113
<EVENT CODE="11" TIME="16-07-2003 19:23 :20" STATUS="0" COMPARTMENTID=1/> <EVENT CODE="11" TIME="17-07-2003 23:12" STATUS="0" COMPARTMENTID=1/> <EVENT CODE="5" TIME="18-07-2003 11:23" STATUS="0" COMPARTMENTID=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> <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" COMPARTMENTID=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" COMPARTMENTID=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"/> <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>
Public
Doc. No. 001
Table Of Contents
</LOADSURVEYSETTING > <MDRESETSETTING> 2</MDRESETSETTING> <MDSETTING INTERVALPERIOD=30> <PARAM> P7-4-5-1-0</PARAM> <PARAM> P7-4-6-1-0</PARAM> </MDSETTING > </D8>
Version Date Page
3.0 th 26 Aug 10 82 of 113
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 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 & 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
1 2 3 4 5 6 7 8. 9
10
11 12 13 14 15 16 17 18 19 20 21 22 23
Public
Doc. No. 001
Table Of Contents
24 25 26 27 28 29 30
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
Version Date Page
3.0 th 26 Aug 10 83 of 113
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 Codes can be defined for each event such as Code 1 2 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 84 of 113
<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) Degree (D) P6 Power factor 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) 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. 1. L&T P1000 2. SML P1200 3. Elster P1400 4. Datapro P1600 5. DukeArnics P1800 6. HSPL P2000 7. Genus P2200 8. Omniagate P2400 9. Easun Reyrolle P2600 10. Capital Power P2800 11. Bentec P3000 12. Delhi control devices P3200 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
13. ICSA P3400 14. Holley Meters P3600 15. Indo Asian P3800
Version Date Page
3.0 th 26 Aug 10 85 of 113
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.
Public
Doc. No. 001
Table Of Contents
9.3.3 Current
Version Date Page
3.0 th 26 Aug 10 86 of 113
Qualifier1 Qualifier1 denotes the type of value. Table below defines the code. Code 1 2 3 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. Power
9.3.4
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
Public
Doc. No. 001
Table Of Contents
Qualifier2 Qualifier2 denotes phase. Table below defines the code Code Description 1 R- phase 2 Y-phase 3 B-phase 4 System(All phases)
Version Date Page
3.0 th 26 Aug 10 87 of 113
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. Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 88 of 113
Code 0 1 2 Qualifier4 Qualifier4 is not used and will be zero .
Description Not applicable Import Export
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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
4 System
Version Date Page
3.0 th 26 Aug 10 89 of 113
Qualifier2 Qualifier4 is not applicable and hence 0 shall be used. 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 90 of 113
7 8 9 10 11 12 13 14 15 16 17 18
Q1+Q2 Q3+Q4 Q1-Q4 Q4-Q1 Q2-Q3 Q3-Q2 Q1+Q2+Q3+Q4 Q1+Q4-Q2-Q3 Q2+Q3-Q1-Q4 Q1+Q2-Q3-Q4 Q3+Q4-Q1-Q2 Forwarded
19 20
Forwarded (import) Forwarded (export)
2. Apparent while active export 3. Reactive energy, lag + lead while active export Reactive Import Reactive Export 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 91 of 113
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
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.
Public
Doc. No. 001
Table Of Contents
Example Frequency parameters code will be generated as P9-<Qualifier1>-0-0-0 Code for instantaneous frequency will be P9-1-0-0-0.
Version Date Page
3.0 th 26 Aug 10 92 of 113
9.3.11 Current angles Current angles can be derived from following qualifiers. 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.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 93 of 113
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. 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)
Authenticator = fn (Data + Seed)
Common Data Format (Generated by CFC module)
Authenticator = fn (Data + Seed)
Public
Doc. No. 001
Table Of Contents 10.2 Authenticator verifier
Version Date Page
3.0 th 26 Aug 10 94 of 113
Manufact urers Data CDF
API4
Authenticator match or Authenticator mismatch
External Seed
CFW will pass the seed in configuration file of API3.
11 Future expandability
Interoperability standard provide following advantages All new innovation in metering will be handled by manufacturer APIs 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
14. Holley Meters G3600 15. Indo Asian G3800
Version Date Page
3.0 th 26 Aug 10 95 of 113
The naming convention of the different meter manufacturers are given below: API function Secure L&T Datapro Elster DukeArnics HSPL Genus Omniagate Easun Reyrolle Capital Power Bentec Delhi Control Devices ICSA (ECE) Indo Asian ERLMRD ERLMRI ERLCFC SMLMRD LNTMRD DEPLMRD ELSMRD DUKEMRD HSPLMRD GNSMRD SMLMRI LNTMRI DEPLMRI ELSMRI DUKEMRI HSPLMRI GNSMRI SMLCFC LNTCFC DEPLCFC ELSCFC DUKECFC HSPLCFC GNSCFC MRD MRI CFC
CPSMRD
CPSMRI
CPSCFC
BEEMRD DCDMRD
BEEMRI DCDMRI
BEECFC DCDCFC
ICSAMRD
ICSAMRI
ICSACFC
IAMMRD
IAMMRI
IAMCFC
As this format is open and defined so it is not dependent on any single party.
12 Log Maintenance
All APIs should create log file which can be used for debugging/troubleshooting the communication between CFW/API and API/meter. Though APIs creates log file but CFW should not use log for any practical purpose other then debugging the API.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 96 of 113
1. API should create log file in \LOG subfolder relative the folder where API exists. For example if API resides in CFW\manufacturer\ABC folder then log file shall be created in CFW\manufacturer\ABC\LOG folder. 2. The log file name should be YYYYMMDD.log, where YYYY stands for year , MM stands for month, DD stands for day. 3. Log file should contain information about a. Communication between CFW and API. b. Communication between reading API and modem. 4. The log file contains following field. All fields are delimited by | a. Date Time in dd/mm/yyyy hh:mm:ss format b. Direction with respect to API. In case of communication between API and CFW API will only write sent and received. In case of communication with modem API will write sent to modem and received from modem. c. Comport In case of communication with modem comport shall be added to log file. It can be blank if it is communication between CFW and API.
d. Instance ID e. Command f. Data/Description
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 97 of 113
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. 12. Secure Meter Ltd Mr. Surendra Jhalora Surendra.jhalora@securemeters.com Elster Mr. Rupesh Phatak rupesh.phatak@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 Mr. Prashanta Dutta Choudhary prashantadc@icsa-india.com Delhi Control Devices Mr. Bhawani Shankar bhawani.abes@gmail.com Bentec Electri & electronic Mr. Ravindra Chaturvedi bentecncr@gmail.com Holley Meters -
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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 98 of 113
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 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 Public Parameter Code P1-2-1-1-0 P1-2-2-1-0 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
Doc. No. 001
Table Of Contents
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 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
Version Date Page
3.0 th 26 Aug 10 99 of 113
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 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
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 100 of 113
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 Modemmake Supported (Y/N) Description /Possible values Type and value of modem make supported Name of modem configuration file Support baud rates Connection type supported
Modemconfigfile Baudrate ConnectionType TelephoneNumber Port MeterComuncationPort MultipleMeters Serial Device ID InstParam EnergyData Settings ProfileData Days Type Events TimeSynch MDReset TamperReset
Values which this parameter can take
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 101 of 113
Output file details
List of output file which are generated 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 Reason for change <Tag Name> <Name of the file in which tag is added> <Brief description of why this additional tag is required > 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 1 2 3 4 5 6 7 8 9 10 11 Manufacturers Name Capital Power System Elster L&T Genus Secure Meters Easun Reyrolle ICSA HPL Socomec Delhi control devices Bentec Indo Asian 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 Windows XP with SP2 OS Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes RAM 1Gb or higher CPU P IV 2.4 GHz or higher HDD 2 GB or higher Supporting Platform .Net 2.0 JVM 1.6.0 .Net 2.0 .Net 2.0 No additional .Net 2.0 .Net 2.0 .Net 2.0
Application path\temp Application path\temp
.Net 2.0 .Net 2.0
Public
Doc. No. 001
Table Of Contents 15.4 MII Protocol message classification

MII Code MII Message Failed due to duplicate instance ID Failed due to Invalid configuration file. Invalid or unknown command command not supported Failed due to invalid instance Id In progress Idle state User Abort Request for progress status Request for API identification Not enough free space Meter reading started Meter reading finished Cannot establish connection No dial tone Cannot establish connection Local Modem not responding Cannot establish connection Port not available Cannot establish connection No hand shaking Line disconnected Can not establish connection -No carrier Connection established. Cannot establish connection Line busy Failed to configure remote device due to invalid configuration file. Failed to initialize remote device. Can not establish connection No answer Process stopped - Meter Serial No. Mismatch" Meter reading failed Meter reading failed - Check Sum Error. Meter reading failed - Data Collection error..." Main Category
Version Date Page
3.0 th 26 Aug 10 102 of 113
Sub Category
1 2 3 4 5 0 5 60 77 73 2 3 51 52 54 55 56 75 1 53 80 81 76 61 62 65 66
API API API API API API API API API API API ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI ReadAPI
Generic Generic Generic Generic Generic Generic All All All All IO Meter Meter LOCALMODEM LOCALMODEM LOCALMODEM LOCALMODEM LOCAL/REMOTE MODEM LOCAL/REMOTE MODEM REMOTEMODEM REMOTEMODEM REMOTEMODEM REMOTEMODEM REMOTEMODEM FILE METER FILE FILE
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 103 of 113
MII Code
MII Message Invalid Header..." Unit Code is not set. Continuing with remaining Meters. Tariff cant be zero. Meter is inactive, cannot Collect Data CDF conversion successful CDF Conversion failed File structure corrupted CDF Conversion failed file write error CDF Conversion failed File not found File(s) are not available for Data conversion. Conversion Failed. Source Folder Path not Found. Can't continue with Parsing. Unsupported meter Version. MRI data transfer failed MRI not responding
Main Category
Sub Category
67 69 70 74 4 57 58 59 64 63 68 71 72 78 79
ReadAPI ReadAPI ReadAPI ReadAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI ConvertAPI MRIAPI MRIAPI
NotApplicable NotApplicable NotApplicable METER Generic FILE FILE FILE FILE GENERIC FILE FILE METER MRI MRI
16 Document History
16.1 Version 01.00
Date 23rd Feb 2k4 Written by Author Reviewed by SML, L&T, Elster Approve d by SML, L&T, Elster
Initial template for use.
16.2 Version 01.10

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

Date 1st Mar 2k4 Written by Author Reviewed by SML, L&T, Elster Approve d by SML, L&T, Elster
Restructured after the meeting held on 1st and 2nd March
Public
Doc. No. 001
Table Of Contents 16.4 Version 01.30

Date 02nd Apr 2k4 Written by Author Reviewed by SML, L&T, Elster
Version Date Page
3.0 th 26 Aug 10 104 of 113
Approve d by
SML, L&T, Elster
Modified during the meeting held on 2nd April.
16.5 Version 01.40

Date 15 Apr 2k4
th
Written by
Author
Reviewed by
SML, L&T, Elster
Approve d by
SML, L&T, Elster
Modified during the meeting held on 15th 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. 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 API1s 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 its 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) j) XML tags are case insensitive. 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 Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents 16.7 Version 01.60 (Oct 01, 2004)

a) Instance id is of 4 characters only. Anomaly in section 5 removed.
Version Date Page
3.0 th 26 Aug 10 105 of 113
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) j) Instead of reshuffling all the General information tags G18 is kept missing. 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. 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.
Public
Doc. No. 001
Table Of Contents
e) Serial number occurrence value changed from single to multiple f)
Version Date Page
3.0 th 26 Aug 10 106 of 113
<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) j) Settings tag is added. Load survey parameter data type value attribute is modified. Provision to indicate No power is added.
k) C1 tag under tamper is modified as cumulative. l) D4 tag date format was indicated by / slash. This has been corrected & indicated by dash.
m) CRC word is replaced by authenticator. n) Same readings configuration file cannot have multiple make of meters
16.9 Version 01.80 (Dec 28 2004)

a) <D4> tag value for parameter as No power is removed. Value will always be numeric. Complete power fail or part power fail during IP will be indicated by <IFlag>. b) <D3> tag Mechanism attribute added. <B2> tag definition modified. Different interpretation is added for <D3-00> & <D3-01>. c) Provision is made to identify date representation for a specific tag (tag which is not following general rule) in the result file. d) Example modified (for <D3>) to indicate discontinuous time zone for the same TOD register. e) TOD registers numbering to start with 1. Clarification added. f) Energy data selective option is removed from dictionary of reading configuration.
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) j) Under energy parameter qualifier2 parameter code added (19,20). This is done to facilitate forwarded reactive register representation. 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 CFWs responsibility. q) Providing IP address & port number is made mandatory for invoking all APIs. Public File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
r)
Version Date Page
3.0 th 26 Aug 10 107 of 113
Positive value of power indicates import (or lag) and negative values will indicate export.
s) Profile data will have demand parameter instead of energy. t) Tag G30, G31 and G32 added for document version, API version and cumulative MD reset count
u) Tamper code for High neutral current added. v) Qualifier 1 for frequency added to denote instantaneous, maximum, minimum and average frequency. w) Qualifier 3 for power factor added to denote import/export power. Positive value will denote lag and negative value will denote lead power factor. x) Tag B13 for history wise cumulative tamper count added. y) Single phase meter added in possible values G15 z) B1 tag will be only contained by D3-00 aa) G5,G6,G7,G8,G9,G10,G28,G29 tags are removed. Other tags are not shifted as these tags are kept missing. bb) Authenticator tag is made mandatory. cc) B2 tag is made mandatory. dd) ErrorPath added to convert API configuration file. ee) OutFileName attribute added in convert API result file. ff) yyyy will be printed if year is not available from meter gg) Format for API compatibility with reading configuration file added in Annexure. hh) Structure of overall common data format file added to add clarity. ii) Added additional error code.
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) Public Path should be taken from configuration file mentioned in section 6.2 and section 8.2. File Name: MIOS Universal Meter Reading common format V3.0
Doc. No. 001
Table Of Contents
g) <DATETIMEFORMAT> tag removed from readings result file. h) Attribute of CONVERT tag made capital in data dictionary. i) j)
Version Date Page
3.0 th 26 Aug 10 108 of 113
<INSTANCEID> tag It should be four digit number with 0 appended in beginning if number is less then 4 digit. 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) APIs 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. 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.
Public
Doc. No. 001
Table Of Contents
i) j) Clarity added for P7 as it can be used in energy/demand Forwarded energy is for active
Version Date Page
3.0 th 26 Aug 10 109 of 113
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) j) Section 9.2.13 - Flag data tags added Section 15.2 Manufacturer specific tag addition template added.
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.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 110 of 113
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.
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.
Public
Doc. No. 001
Table Of Contents
Version Date Page
3.0 th 26 Aug 10 111 of 113
Duration of No power & No load example added & related tags & parameter codes also has been defined.
16.24 Version 2.0 30th Meeting 24th Nov 2008

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

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

o o o o o o o o o Support for Inbound Dialling-Reading Direction updated. MRI Prepare Module added. Cumulative Tamper Count Added in D3 Tag. B16 Tag (provision to transfer tariff file name) is added. IFLAG Code 106 to 117 Added. Event Data Tag 55 to 64 Added. Transaction Tag 12 to 19 Added. Log File naming convention (From YYYYMMDDhhmmss.log to YYYYMMDD.log) updated in Log Maintenance Section. Folder Path for Temporary file and Software & Hardware specification Annexure added.
Version 2.2 33rd Meeting 8th May 2009

o o Section 6.1 modified Which manufacturer API to be invoked is reemphasized as mentioned here-- Decide & Invoke respective meter manufacturers reading API 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. Tag D5 - Cumulative time from hours only changed to ddd:hh:mm:ss.
Public
Doc. No. 001
Table Of Contents
o
Version Date Page
3.0 th 26 Aug 10 112 of 113
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 o Section 6.4.3 Removed Support of inbound dialling. 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. Sections 9.2.1 updated- Cumulative tamper Count removed. Section 9.2.6 Updated- The B16 tag (Tariff Name) added in Billing register data example. Section 15.3 - Folders path for temporary files and software hardware specification table updated Section 9.2.2 Version encoding information for XML file is added 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. 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. Section 6.3.1 - Relationship of What to Read & CDF Tags is removed Section 6.2. Item 17 Removed having reference about inbound modem Tag G34 is added as Standard or Long range Tag G14 modified as meter rating in place of meter range. Section 7 Prepare MRI is made optional Event code 65 to 71 added Transaction code 20 to 30 added. MD reset mechanism auto clarified further. D11 (Sag & Swell) & D12 (Phase wise Power on time) tags are added B17(Billing period power on duration), B18 (Energy cross over count), B19 (Cumulative energy during magnetic tamper) , B20 (Reset specific information) added
o o o o o
o o o o o o o o o o o
Version 2.4 37th Meeting 17th Dec 2009

o o o o o Section 6.1 Updated Support of multithreading and multiple instance related points added in CFW responsibility. Section 6.2 Added- Responsibility of GPRS modem Section 6.3 Updated Support of multithreading and multiple instance related points added in API 1 responsibility Section 6.4.1 Connection Timeout tag added Section 6.5 Result file naming convention related section added
Public
Doc. No. 001
Table Of Contents Version 2.5 38th Meeting 08th June 2010

o o o o Section 9.2.6 (Billing register data) example-1 updated.
Version Date Page
3.0 th 26 Aug 10 113 of 113
Section 15.4 added in Annexure section for classification of MII protocol message CONNECTION ID Tag added at Dictionary for reading configuration table (6.3.1) Section 6.5 added for GPRS meter reading
Version 2.6 39th Meeting 07 Aug 2010

o o o o o o o Section 1.2 scope -- CFW is not expected to operate from MRI is changed to CFW and API are not expected to reside on MRI. Need of API2 is re-emphasised. GPRS section modified Section 6.5 Indo Asian related information added Version 2.6 will be published as version 3.0 Manufacturer specific tag number for parameters are changed from M1, M2 to P1000, P1100, P1200 & so on. Connection type tag GPRS changed to DynamicIPGPRS How to differentiate between power fail condition & zero load in load survey.
Version 3.0
o Architecture diagram and process flow diagram added in GPRS section 6.5
Public

MIOS Universal Meter Reading Common Format V3.0 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MIOS Universal Meter Reading Common Format V3.0 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 2 of 113

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 3 of 113

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 4 of 113

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 5 of 113

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 6 of 113

Definitions & Abbreviations

Pre-Requisites (Optional) Overview (Optional)

2 Key Point (Optional)

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 7 of 113

3 Common Frame-Work (CFW)

Common Data Format (CDF)

Manufacturers Reading (MRD) modules (API1)

Manufacturers MRI Downloading & Prepare (MRI) module (API2)

Common format Converter (CFC) module (API3)

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 8 of 113

Responsibility of manufacturers API

The manufacturers API will follow the rules as described below:

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 9 of 113

4 Invoking meter manufacturer modules

Common framework program

Manufacturers modules (API)

5 Meter Interoperability Interprocess Protocol (MII Protocol)

Universal Meter Reading & Common Format

Doc. No. 001

Version Date Page

3.0 th 26 Aug 10 10 of 113

The message header would be comprised of the following fields:

Acknowled ge start operation

00: Receipt of Reading command 01:Receipt of MRI download

File Name: MIOS Universal Meter Reading common format V3.0

Universal Meter Reading & Common Format