TECHNICAL SPECIFICATION METERING DATA MANAGEMENT - MDM

(1)

TECHNICAL SPECIFICATION

METERING DATA MANAGEMENT - MDM

PREPARED APPROVED TECHNICAL

SPECIFICATION

ET-DD-002/2010

REVIEW

(2)

INDEX

1. OBJECTIVE ... 3

2. DESCRIPTION ... 3

3. SPECIFICATION OF THE MDM ENVIRONMENT ... 3

3.1 General ... 3

3.2 Central Subsystem ... 3

3.3 Remote Subsystem ... 21

3.4 Communication System ... 21

3.5 Fraud Identification Decision Aid Module (or functions)... 22

4. SCOPE OF THE SUPPLY ... 30

4.1 General ... 30

4.2 Central Subsystem ... 31

4.3 Integration services ... 32

4.4 Support Services on Demand ... 34

5. MODEL FOR THE IMPLEMENTATION OF THE SERVICES ... 34

5.2 Homologation of system ... 34

5.3 Technical Support ... 34

5.4 Training ... 35

(3)

1. OBJECTIVE

1.1 To establish the criteria and the minimum technical requirements for the supply of Metering Management System (MDM), as well as the additional services necessary for its deployment and technical support.

2. DESCRIPTION

2.1 MDM is a metering services management platform that shall allow the PURCHASER to perform remote metering operations, upload of files, analysis and data processing, exchange of information with their information systems and implementation of processes to fight commercial losses. The MDM must be a, ready and fully operational product, not including any development service, exception made for the integration with other information systems of the PURCHASER, for the adaptations to the their IT environments or for the new features later required by the PURCHASER.

3. SPECIFICATION OF THE MDM ENVIRONMENT

3.1 General

3.1.1 Consisting by at least three modules: Remote Subsystem, Communication Systems and Central Subsystem. The Remote Subsystem is the set of billing electronic meters that form the universe of electronic billing meters of the PURCHASER, added to the remote communications (gateways, modems, radios, concentrators) equipment required to connect this equipment to the Central Subsystem. The Communication Systems are the available means of communication in the concession areas of the PURCHASER. The Central Subsystem is a set of software and hardware necessary to provide the PURCHASER with an automation metering management platform, using remote metering.

3.1.2 The item 4 of this specification defines the mandatory requirements of the MDM. The BIDDERS shall submit a statement, according to the model disclosed at the time of the bidding, indicating that the proposed solution meets all this mandatory requirements.

3.2 Central Subsystem

3.2.1 Hardware and Software Environment for Central Subsystem

3.2.1.1 The operating system shall be the Windows 2008 Server or superior;

3.2.1.2 All the hardware environment of the central subsystem shall be compatible with the Intel architecture or similar;

3.2.1.3 The system shall operate using ORACLE database or MICROSOFT SQL SERVER, as per ET-DD-008/2010;

3.2.1.4 The SUPPLIER shall furnish all the manuals for the operation, administration and maintenance of all the applications involved in the solution during their initial supply and at every new update of the systems that will imply in modification thereof. It shall be included in this documentation at least the following technical documents of the system: Requirements Specification detailing all the elements of the system, the Software Design and a DER - Diagram of Entities and Relationships;

3.2.1.5 In order to guarantee the continuity of the services the sources of the MDM programs shall be monthly delivered to the PURCHASER during the implantation phase. During the production phase and the validity of the guaranty, the updates of the sources shall be delivered immediately after their effectuation;

3.2.1.6 During the delivery of the sources of the programs the SUPPLIER and the PURCHASER shall check the material that will be sealed in an envelope properly

(4)

identified and signed by the parties. The PURCHASER undertakes to only use them in case of unavailability of services by the provider of the MDM;

3.2.1.7 The complete system documentation shall be delivered in Portuguese. 3.2.2 Requirements of the MDM system architecture

3.2.2.1 The system shall have at least the following layers bounded by independent programs: application server, communication server and database server; all with its corresponding redundancy.

3.2.2.2 The application must be delivered fully integrated with the Commercial Management Systems, Border Metering Systems, Distribution Management System, Supervisory Control and Data Acquisition and Metering Management System already existing in Eletrobras Amazonas Energia;

3.2.2.3 The messages and screens of the system shall be exhibited in Portuguese;

3.2.2.4 The system shall have the resources of auditing trail and recording of transactions that were made: who made, when and where they were made;

3.2.2.5 The system shall be scalable and will allow the use of multiple instances provided they be integrated into a single database.

3.2.2.6 The system shall have capacity of increase of the hardware components as required for the improvement of performance (horizontal scalability);

3.2.2.7 The system shall have ability to migrate to a hardware platform for better performance (vertical scalability);

3.2.2.8 The system shall have scalability of the components considering the following aspects:

Processing Capacity; Data storage;

Increase in the number of simultaneous clients without loss of performance; 3.2.2.9 It shall allow "hot standby" for:

Application servers; Communication servers; Database servers

3.2.2.10 The system interfaces shall be WEB1 (accessible from a Web Browser, like Internet Explorer, Mozilla, Chrome);

3.2.2.11 It shall have capacity for remote operation, through access from a local network or through the Internet in safe environments, enabling configurations, programming and control of the applications.

3.2.2.12 Index of availability equal to or bigger than 99.4% (ninety-nine point four percent), representing a total time of unavailability of the system of up to 52 (fifty-two) hours/year. The BIDDER shall present the methodology for measuring of the availability, which will be submitted to the approval of the PURCHASER.

3.2.3 General Features of the MDM

3.2.3.1 The MDM provides a joint infrastructure for data receipt on metered consumption from the implemented AMI calculating potentially the consume of electricity and it

(5)

provides the data necessary to the system for calculation and billing of electricity. Preserves and manages data, and also provides access to subject data to all interested parties.

3.2.3.2 It shall have features that will allow performing the activities related to the management of the metering and actions related to the protection of the revenue; 3.2.3.3 The use of middleware will be enable the connection the MDM with other business

systems, that is or may be implemented by the contractor after the implementation of the MDM.

3.2.3.4 WAN facilities will be using by MDM for connection with all entities on environment of the PURCHASER, as well as with all interested parties.

3.2.3.5 The system shall be able to create and maintain updated data on metering points, meters, accounts, network resources, etc., necessary for the MDM operation and to make it available for the PURCHASER.

3.2.3.6 The PURCHASER is responsible that all changes done in any metering point are automatically updated in the MDM database.

3.2.3.7 The MDM shall support:

Upload on metered consumption and any other relevant data. Validation, editing and estimation of received meter data Data storage, management and maintenance

Expandability in terms of full integration with other Information System Revision of changed data

Security in access management of all functions and data

Calculation of consumed energy for each point of delivery based on different price structures, including hourly and other specified tariff rate periods.

Data based on the sequence defined in advance or on request

3.2.3.8 All functionalities related to validation, editing and estimation should be centralized 3.2.3.9 Data transfer from the MDM to the Billing System, as well as to other information

systems of the PURCHASER, shall be implemented through the (push) procedure (according to sequence) or the (pull) procedure (on request)

3.2.3.10 Hourly load profiles (LP) specified by other information systems should be used for VEE analysis needs, in case when there are sufficient data.

3.2.3.11 The MDM shall initially be filled with all necessary data (identifiers of points of services of all customers), in order to enable the performance of VEE analysis of connected AMI system.

3.2.3.12 During initial system filling with the necessary data, the PURCHASER shall submit all its historical data, necessary to fill the MDM database.

3.2.3.13 In initial implementation phase, MDM shall receive, process and manage data on metered electricity consumption for all customers having meters installed and that passing to be read by the AMI system.

3.2.3.14 The MDM must enable the following functionality in the future: Distribution Asset Planning & Analysis

Customer Care

(6)

Load Research & Forecasting DG control

3.2.3.15 Data billing and memorizing function collects data automatically in an efficient and reliable manner from the meter; and memorizes (archive) them in a corresponding database or performs instant reading of the meter upon user request.

3.2.3.16 The following data billing and functionality:

Consumption of power Direct e reverse by hourly or less intervals of time; Net metering data hourly and at interval periods;

Voltage;

Outage Counts; Demand metering; Remote demand resets; Fiscal Page;

It shall permit the customer data entry and update;

Entry, update and monitoring of data on installation and replacement of meters; DIC2, FIC3, DMIC4, DRP5 and DRC6 voltage transgressions

Real time clock synchronization when applicable; Set up and change of approved mean power limit; Change of voltage thresholds related to energy quality;

Setup, change, review and synchronization of reading programmers/sequence; Setup, change, review and synchronization of programmers/sequence execution priorities;

Setup, change, review and automatic update of communication route when applicable;

Setup and management of grouping of meter reading;

Activation of function’s key on the meter (e.g. conditional reconnection);

Any programmable or not programmable command can be sent individually or to any group of meters;

3.2.3.17 The exportation of all meter data from the system to ASCII, TXT, CSV7, Excel and XML files;

3.2.3.18 The importation and exportation of a public file8 ;

2

Duration of interruption per consumer unit or individual per connection point, expressed in hundredths of hours and hours 3

Frequency of interruption per consumer unit or individual connection point, expressed in number of interruptions 4

Maximum of continuous interruption per consumer unit or point connection expressed in hundredths of hours and hours 5

Relative duration of transgression voltage precarious individual unit consumer 6

Relative duration of transgressing voltage critical individual unit consuming 7

The CSV format (comma separated value) saves only the text and the values as they are shown in an active spreadsheet. All lines and all characters of each cell are save. The data columns are separated by commas and each data line ends at a change of line. If one cell has a comma the cell content is put between brackets.

8

(7)

3.2.3.19 The allocation of consumer units for analysis groups and relocate them, when necessary;

3.2.3.20 Summaries of the events with information about power, current and voltage, alarms, etc.;

3.2.3.21 It shall have features that will allow performing the activities related to the disconnection and reconnection of low voltage consumer units;

3.2.3.22 It shall generate graphical reports and statistics related to active energy, reactive energy, demands and quality parameters;

3.2.3.23 It shall generate statistics of periodic events (frequency and duration) per metering points, per occurrences;

3.2.3.24 It shall generate histories of all the parameters per metering point;

3.2.3.25 It shall have functionalities that will allow the setting for a scheduled energy meter readings, in addition to allow on-demand access, at any time, to these same points of metering;

3.2.3.26 It shall have functionalities to define priority on system Commands;

3.2.3.27 The communication with the meter shall be done using the its serial number and the customers ID or customers account number;

3.2.3.28 For any command sent the system shall have a feature for tracking their situation, such as: command sent, command received by the meter, command performed, etc. 3.2.3.29 It shall be able to monitor read meter data during data processing. Shall report the

status of the reading process, percentage of advance, etc.; 3.2.3.30 It shall permit to define a Calendar with holidays;

3.2.3.31 It shall permit to define and schedule automatically reading according to the reading route;

3.2.3.32 To allow the creation of configurable groups in at least four (4) levels (trees), allowing the association of the consumer unit (UC) in any of these levels. The consumer units can be simultaneously allocated in more than one group, provided that any eventual update of a registration in one UC will imply in the automatic updating of the various locations where it is allocated. Any programmable or not programmable command can be sent individually or to any group of any level. The MDM shall automatically provide the available data from each consumer unit starting from its selection. All consumer units allocated in a particular group must be viewed within the same section even if it will be needed the exhibition of multiple screens. It is allowed the paging of the screens for the display of consumer units in the selected group. If there is such paging, the system shall allow the exportation of all consumer units in the group or of only part of them, according to the required selection in Excel files. The MDM must allow the allocation of consumer units for analysis groups and relocate them, when necessary;

3.2.3.33 Shall allow the acquisition of remote metering of distribution substation feeders, aiming, among other functions, to provide data for the management system of the power distribution network of the PURCHASER;

3.2.3.34 Generation of Reports / Charts

this kind of file are ASCII. The standardization for the name of the file in the public format is as follows: NNNNN&XX.XXX where: NNNNN are the 5 less significant digits of the serial number of the meter; XX.XXX are the less significant digits of the result of the calculation: SS+MMx60+HHx3600+(DD)x24x3600+(MM)x31x24x3600 transformed to the base 20, where A=0 until T=19. Second, minute, hour, day and month of the generated file refer to the hour and to the date of their reading.

(8)

It shall allow the generation of graphs of the metering point, with at least the following characteristics:

Zoom functionality (increasing and decreasing), making possible amplifications for detailing specific areas of the graph and subsequent return to the initial conditions sizing;

Dynamic features with automatic adjustment of scales. Under normal conditions, the minimum value of the scale must be around 10% below the lowest found data value (except zero).

3.2.3.34.1 Must allow at least the availability of consumption charts (daily, weekly, monthly) of active and reactive energy of the metering point, with at least the following features and characteristics:

The period, under the initial conditions of implementation, shall automatically present the available reading period;

Possibility of choice of date and hour for the start time and end time of the analysis;

Line type chart or bar type chart, with different colors for each type of quantities; Ability to export the data from the charts

3.2.3.34.2 Report of analysis of statuses and alarms

This type of report shows alarms and statuses of meters/concentrators, event logs, after finding corresponding alarms, statuses and events.

Result of such reports should be the daily showing all alarms, statuses and events and on which meters, representing the basis for further action on these meters. 3.2.3.34.3 Reports on energy quality

This report shall execute analysis of voltage circumstances on meters themselves since there are corresponding records in the energy quality log recording voltage drop/overvoltage below/above defined voltage thresholds and supply interruptions. In this way, the function shall indicate poor voltage circumstances with one or a group of customers.

3.2.3.34.4 Reports on Communication

Report statistics of Successfulness communication between system elements represents a special whole within the reporting functions.

3.2.3.34.5 MDM shall automatically generate reports, whereas, it is not only limited: Confirmation of successful load data transfer by AMI System

Confirmation of all data changes in the database occurring due to the addition, migration or change in any of the metering points.

Reports related to meter data. Unsuccessful meter data upload. Unsuccessful meter data receipt.

Difference between the meter identifier and the identifier of POSN Lack of storage capacity in the database or on disk

(9)

Computer network problems

3.2.3.34.6 All reports must be capable to be downloading to Excel, ASCII or TXT file.

3.2.3.34.7 Print/Print Preview option is mandatory with every report automatically generated in the form of PDF file.

3.2.3.35 Data and information exchange functions with MDM and other Information System of PURCHASER

3.2.3.35.1 This portion identifies elements that need to be transferred to and from MDM. Data transfer request should be executed consistently to and from MDM, information subsystems of the PURCHASER and other interested parties.

3.2.3.36 Data submitted to MDM:

3.2.3.36.1 Data on metered consumption for LV customers at an hourly level; 3.2.3.36.2 Data on metered consumption for MV Customers at an hourly level;

3.2.3.37 Capacity to Perform Validation, Estimation, and Editing (VEE) on all meter reads, to ensure “clean” data with no missing gaps. Standard tests included:

Missing Values Zero Values Static Values Negative Values Spike Check Sum Check

3.2.3.38 Users also shall have the ability to create their own, custom VEE rules.

3.2.3.39 Shall provide a set of standard validation includes referential integrity, data version control, missing interval, negative value, zero value, static value, spike and sum checks, which can all be configured individually.

3.2.3.40 Historical load validation – Load validation for both interval data and consumption data:

3.2.3.41 It shall be capable to compare against historical consumption, and adjustments are made for weather and cycle length using the Consumption Data.

3.2.3.42 It shall provide a tool, preferable graphic that allows the business analyst to build and maintain custom logic sets for validation purposes. It shall allow the analyst to build unlimited logic.

3.2.3.43 Estimation shall be provided for both interval data and consumption data.

3.2.3.44 For interval data, estimation shall be performed using a sophisticated algorithm, which allows for weather-sensitive regression, day-type, and similar-day estimations.

3.2.3.45 For consumption data, the estimate is derived from historical usage factors, and default values are used for the new meters.

3.2.3.46 The editing function shall have a tool for analysts can view meter data in graphs or reports. Questionable data are highlighted with a suggested estimate, and the analyst can choose to accept the estimate, accept raw data, or input an alternative estimate.

(10)

3.2.3.47 Enable user-friendly querying and reporting using standard reporting tools.

3.2.3.48 XML Web Services that allows loading and extracting data elements from the database.

3.2.3.49 It shall have a powerful scheduling, archiving, and maintenance administration tools, robust task monitoring and error messaging.

3.2.3.50 It shall supports a role-based security model.

3.2.3.51 It shall provide a powerful analytic tool to generate a list of suspicious accounts or meters that require further field investigation by the revenue protection team.

3.2.3.52 Must allow standard validation tests; examining the results of various combinations of validation tests provides the first level in identifying potential energy theft.

3.2.3.53 The software must compare and analyze customer, meter and account data to identify individual consumption patterns and detect suspect consumption behavior. A set of logic tests must be loaded during the implementation.

3.2.3.54 Allows an easy way to query and chart the data to extract business intelligence. Business Users must have the ability to aggregate meters into meaningful billings, and then build logic tests with the meter data to look for outliers and meter anomalies.

3.2.3.55 Automatically schedule and run a series of standard theft detection and logic tests to identify theft. These include:

Inactive Status Pending Disconnect Tamper Flag on

Reverse Rotation flag on Meter changes

Repeat customer Drop in Monthly Usage

Zero Usage (systematic intervals) Reverse Spike in Usage

Spike in Usage Load Factor > 100%

High quantity On/Off condition Abnormal Voltage Variation Abnormal voltage condition Abnormal current condition

3.2.3.56 Allow combinations of logic tests to refine results. Allow the combination of meter read checks with CIS - Commercial System data to create further tests. Examples of these are:

Zero Monthly Consumption on Active Customers Consumption on Inactive Customers or Disconnects Seasonal Customer Use

(11)

Decrease in monthly usage High load factors

3.2.3.57 Allow business users to create their own logic tests and iterative workflows to identify theft.

3.2.3.58 The MDM shall identify in a unique way all points in which electricity delivery to customers is executed. Unique POSN shall be awarded by Commercial System and it shall represent a unique identifier serving for identification of the point on which calculation of consumed electricity is performed.

3.2.3.59 The PURCHASER is responsible for creating and maintaining the POSN database. 3.2.3.60 Data entry into MDM

3.2.3.60.1 Data entered into the MDM include: Meter Data

Data from Customer Information System / Commercial System Information related to tariffs and price structures

Data from Billing System / Commercial System

Data on network resources on which points of service (POS) have been implemented

3.2.3.61 Transfer of received meter data from AMI System

3.2.3.61.1 The MDM shall receive and process data on metered consumption and other data from the subordinated AMI system. Received meter data to be transferred to the MDM from each advanced metering system include the following:

Data on metered consumption for LV customers, at each hour. Data on metered consumption for MV Customers, at each hour. Interval Data

3.2.3.61.2 It is necessary for all data transferred via this data transfer method to be related to the same calendar day. Finally, it is expected that all of these transferred parameters, at least contain identification information in the heading defining data upload priority for MDM System for several subordinated devices, when simultaneous data transfer is requested.

3.2.3.61.3 Data transfer priorities

Priority should be based on time and date of meter data creation.

The MDM shall be capable to enable receipt and storage of all data on metered consumption every day for the previous daily reading period. In order to have successful data transmission, it is necessary for all process clocks on all computers within subject subsystems to be synchronized in terms of time.

3.2.3.62 Manual entry

3.2.3.62.1 The MDM shall provide the possibility of manual entry of meter data and other data. 3.2.3.62.2 Manually entered meter data shall be in the same format as the ones automatically

entered into the MDM by AMI system, whereby, the same validation of message content is performed, as in the case of automatically transferred messages.

(12)

3.2.3.62.3 Data validation prior to (VEE) analysis

The MDM should perform, without restrictions, the data validations uploaded into MDM system.

During every data transfer, verify if the combination ‘POSN/Meter ID’ is valid and is concurrent with data in the Commercial or Billing System.

3.2.3.63 Data exchange between the billing or CIS system and MDM system

3.2.3.63.1 The system shall be capable to receive and process the following transfers: New unique POSN

Data on the network resource where the meter is connected Request for meter data reading

Request related to data for electricity calculation.

3.2.3.63.2 The MDM shall receive and process incremental changes of data contained in Data Base of Customer Information or Billing System. These contain changes in various time-dependent attributes, related to points of sale of electricity.

3.2.3.63.3 Time Flow of Data Exchange

Meter data uploaded daily into the MDM are mainly data from the previous daily reading period.

When for any reason meter data from the previous day shall be uploaded from AMI system, for the purpose of efficient data transfer, missing data are usually transferred with high priority.

In cases, when instead of missing accounting data, estimated values are sent to Billing System, it is possible to perform missing data transfer under lower priority. Estimated values must be accepted by an operator.

3.2.3.64 Data submission by MDM

3.2.3.64.1 The MDM shall submit data on other information subsystems in different ways, as explained in the following text.

3.2.3.65 Data submitted to Billing System

3.2.3.65.1 The data on electricity accounting shall be transferred to the billing system under the schedule defined in advance.

3.2.3.65.2 In the definition of the requirements in terms of automated data transfer between systems, it is necessary to anticipate the submission of grouped accounting data in addition to standardized daily sequence.

3.2.3.65.3 All data on energy accounting to be submitted to the Billing System will be archived by the System.

3.2.3.65.4 In the course of MDM implementation phase, it must provide accounting data to the Billing System for each metering point containing an advanced meter and according to the criteria defined by the utility.

3.2.3.65.5 In case when there is no consumption at some metering point, the MDM will submit a zero value for metered consumption to Billing System. It should also be noted that

(13)

zero value represents a valid consumption reading which has undergone the validation process and that it does not represent missing data.

3.2.3.66 The MDM shall have an internal user interface enabling supervision, change and management of processes and data within the system.

3.2.3.67 If data transfer is completed unsuccessfully, MDM system will send and internal message, if necessary, it may notify AMI system operator about the failure.

3.2.3.68 Data Grouping

3.2.3.68.1 Key information of MDM is grouping of gathered meter data for the following purposes: billing, reporting and analysis. Compared to accounting data, MDM will group confirmed meter data according to tariff periods, established on a daily basis, at the level of electric utility.

3.2.3.69 Data Versions

3.2.3.69.1 MDM must provide access to meter data by using the corresponding data version. Every time meter data are altered, MDM system should update only data related to that metering point and certain date of the year.

3.2.3.70 Data Monitoring

3.2.3.70.1 MDM shall make such information available in the form supporting the revision process, starting from the meter data receipt to the final generation of accounting data. It is necessary to record meter data versions used for creation of accounting data sent to Billing System, for keeping the records on change for revision needs. 3.2.3.70.2 MDM must enable the usage of real meter data during revision, when they are

available in the system, instead of data replaced or estimated, used for generation of accounting reports. All newly arriving data will be processed through VEE analysis.

3.2.3.71 Validation, Editing and Estimation (VEE)

3.2.3.71.1 All meter data received by MDM will be subject to VEE analysis. Automatic process of VEE analysis shall be realized within MDM. The VEE analysis process performs analysis of current meter data for finding possible anomalies, and in the case that anomalies are discovered, an error report is generated, as well as the request for data correction within the MDM with the estimated value.

3.2.3.71.2 In the course of VEE analysis within MDM, it is necessary to possess the entire documents related to algorithm implementation used for the validation and estimation of meter data, whereas, applied algorithms have to be explained on real examples, with clearly defined data flows and definitions. The MDM shall use subject algorithms for future revisions and improvement of the analysis procedure. 3.2.3.71.3 The MDM must continuously validate meter data in search for possible anomalies.

Various rules should be enabled within the MDM for meter data validation coming from certain metering points or groups of metering points. Applied validation algorithms should not disturb the existing business processes in the environment of the PURCHASER

3.2.3.71.4 The MDM must have automated estimations techniques to complete missing or invalid data.

(14)

3.2.3.71.5 The MDM should enable meter data change by the operator. Review and change of meter data shall be restricted to certain metering points, for which an identity has been identified as the primary authority for such data.

3.2.3.72 Functional requirements in terms of data storage

3.2.3.72.1 The MDM shall be capable to receive notifications on the addition of the new metering point, new meter (either classic or advanced), meter dismantling, as well as change of information related to the metering point by any PURCHASER’s system. PURCHASER will be responsible for providing data on metering points, meters, network topology, customer data, as well as other reference data, for the purpose of their full synchronization.

3.2.3.73 Archive data and data Restoration

3.2.3.73.1 An archiving procedure shall be implemented enabling efficient data storage for the time of at least 5 years, and subsequent transfer to storage media providing permanent storage.

3.2.3.74 Historical data

3.2.3.74.1 The MDM should be able to store data for on-line availability. In addition to this, MDM system has to be able to store data for off-line availability, in order to provide historical reserve. The MDM should be able to provide all these data for the purpose of submission to all interested parties.

3.2.3.74.2 On-line availability of meter data and ancillary accounting data must provide for at least 24 months.

3.2.3.74.3 Off-line availability will be primarily use for the purpose of revision, but also for historical analysis of consumption trends.

3.2.3.75 Security

3.2.3.75.1 Security within the MDM should provide control of data access and functionalities within MDM.

3.2.3.75.2 The MDM shall provide control for the access to data and functions depending on user authorizations, as well as data sensitivity.

3.2.3.75.3 The MDM shall provide such data access and target functionality ensuring that only authorized users could use the system, within the scope of their authorizations according to the security level.

3.2.3.75.4 Records must be keeping about the users having system access, with specification of privileges for each user, as well as system access records (identification of successful and unsuccessful attempts).

3.2.3.75.5 When user privileges are changed, the MDM shall register the security level change, time of the change and who executed the change.

3.2.3.76 Roles and Group of System Users

3.2.3.76.1 The MDM shall implement a security procedure on all access levels through the usage of users, groups of users, as well as their roles.

(15)

3.2.3.76.2 Security procedure shall support the possibility of allocating users within specific or standard groups, whereby, roles are defined in the way enabling the application to individuals or groups of users.

3.2.3.76.3 Subject roles should define access levels to MDM. 3.2.4 Specific Features for Consumer Units of Group B 9

3.2.4.1 The following functions must be supported in addition to those indicated in the point 3.2.3.

Demand Side – current limit. TOU

3.2.4.2 It shall allow the visualization active energy, reactive energy, and fiscal page data registers of each point;

3.2.4.3 It shall allow the management of metering solutions for condominium with multipoint meters and a single point of connection with the MDM;

3.2.4.4 It shall enable the management of external metering solutions (solution in which the metering is installed in primary and/or secondary concentration boxes). In this condition it may be necessary the association of single-phase meters to meet the requirements of two phases and three phases supplies;

3.2.4.5 The communication with the meter shall be done using the serial number of the same;

3.2.4.6 It must handle active energy, reactive energy, voltages and frequency data;

3.2.4.7 It shall allow the management of remote disconnection and reconnection of the supply of energy of consumer units, in all the configurations previously described; 3.2.4.8 The MDM must have the ability to do emergency reconnections within up to 4 (four)

hours;

3.2.4.9 It must allow the management of the data of active and reactive power in at least three programmable periods, for different tariffs, provided that the meter or the metering solution will allow this feature;

3.2.4.10 It shall allow the Management by the Demand Side (in Portuguese: GLD) - current limit on a period of the day to be parameterized, provided that the installed meter will allow this feature (it shall have associated disconnection / reconnection devices); 3.2.4.11 It shall allow the creation of a virtual metering for energy balance that will display the

result of arithmetic operations of addition and subtraction of other metering, and also to compare this virtual metering with other metering. For virtual meterings it shall be also foreseen the input of other loads (power and power factor);

3.2.5 Specific Features of MDM for Consumer Units of Group A 10and group B (when relevant or in specific project)

9 _{These are Consumer Units supplied with voltages smaller than 2.3 kV (optionally for the Units supplied by underground}

distribution systems), or, yet, supplied with voltages higher than 2.3 kV and optionally billed in this group according to the terms defined in the Resolution nº 414/2010 of ANEEL. This group is characterized by the monomer structuring tariff (billed only by the active energy consumption).

10_{These are Consumer Units supplied with voltages equal to or greater than 2.3 kV (optionally for the Consumer Units defined in}

the Resolution nº 414/2010 of ANEEL), or, yet, optionally for those supplied with voltages smaller than 2.3 kV from underground distribution systems. This group is characterized by the binomial structuring tariff (billed by the active energy consumption and by the demand).

(16)

3.2.5.1 The following functions must be supported in addition to those indicated in the point 3.2.3

3.2.5.2 It shall allow at least the visualization of the data of the parameters of each point, with, at least the following information: last integralized period, meter’s operating system version, date and hour of the last billing and time of the penultimate billing, inductive PF (power factor) and capacitive PF, number of demand replacements, interval of integralization, beginning of the peak time, beginning of the off-peak hours, beginning of the reserved time, beginning of the inductive time, beginning of the capacitive time, national holidays, time segments, normal working days, Sundays, Saturdays and holidays, magnitudes of channels 1,2 and 3, constants of the channels 1,2 and 3, battery status, automatic demand replacement (enabled or disabled, and date), type of running fare, reserved time (set on or off), composition of the channels to calculate the PF (kWh in channel 1, inductive and capacitive kVArh in channel 2 or kWh in channel 1, inductive kVArh in channel 2 and capacitive kVArh in channel 3), the interval range of mass memory storage, integration interval, schedules for summer time and reference power factor used for the calculation of energy quantity corresponding to the reactive energy surplus; 3.2.5.3 It shall allow the visualization of the data from all available channels on the meter in

daily, weekly or monthly segmentation, for initial / final specified periods (day / month / year) in intervals of 5, 15 (default), 30 or 60 minutes, with exportation for, at least, the Excel format;

3.2.5.4 It shall allow the visualization of the data registers from channels 1/2/3 and 4/5/6, from every point, with at least the following information: Presentation Mode (pulses and magnitudes), grand total, total at the direct peak, total at the reverse peak , total off-direct peak, total off-reverse peak, total direct reserved, total reverse reserved, demand of the last interval, maximum peak demand, maximum off-peak demand, maximum reserved demand, accumulated demand at the peak, accumulated demand off the peak, accumulated reserved demand, Reactive Energy Billing Unit (in Portuguese UFER11 ), Maximum Demand Corresponding to Reactive Energy (in Portuguese DMCR12 ), accumulated DMCR, total exceeding reactive energy;

3.2.5.5 The files generated and recorded must be of the Public type. Additionally, according to the user's selection, the files can be generated in the FK7 format, as per NBR14 522. According to the capacity of the meter, it shall be possible to extract archives from the channels 1/2/3, 4/5/6, 7/8/9, 10/11/12, 13/14/15, 16/17/18 and 19/20/21. When it will be standardized the public XML format, with all the quantities defined in the same file, the provider shall provide a system upgrade at no charge for the PURCHASER;

3.2.5.6 It must have a screen for visualization of, at least, the last twenty energy failures in the metering, with date and time of the start of the fault, date and time of the end of the fault and detailed duration in days, hours, minutes and seconds;

3.2.5.7 It must have a screen with capacity to exhibit at least the last sixteen changes applied to the meter;

3.2.5.8 It shall automatically record the archives for recovery or replacement of the demand, segmented by billing period, immediately after the occurrence of replacement demand in the meter, regardless of the replacement have been carried out automatically or manually;

3.2.5.9 It shall make, at least, the following automatic readings:

11

(17)

Invoice or replacement of the demand; Verification;

Recovery;

Reading of all the mass storage; Reading of part of the mass storage; Summary of the invoice;

Summary of verification; Summary of a recovery; Fiscal page.

3.2.5.10 It shall allow at least the following changes via web browser: Date;

Range of demand; National holidays; Multiplication constants; Time segments;

Condition of reserved time; Method of demand calculation; Automatic replacement of demand; Summer time;

Method of calculation of the quantity of energy corresponding to the reactive energy surplus;

Visualization of the display codes;

Condition of the serial output of the user; Presentation format of the display quantities; Universal posts;

Micro-adjustment of clock; Reading.

Note: For any command sent the system shall have features for tracking their situation, such as: command sent, command received by the meter, command implemented status, etc.

3.2.5.11 It shall allow the scheduled execution of several commands to change the parameterization in blocks (e.g.: national holidays, summer time, reference power factor used for the calculation of the quantity of energy corresponding to the reactive surplus) in a single meter or a in a group of meters;

3.2.5.12 The "MDM" shall allow the following visualizations: Current Parameters;

Former parameters; Current registers;

(18)

Former registers; Energy failures; Changes records;

Status of the sensors and alarms description.

3.2.5.13 The system must allow for at least the availability of the following graphs:

3.2.5.13.1 Power factor graph: it hall have as a central reference on the horizontal axis the value of power factor equal to one or other adjusted value based on the available data. Values in the lower part of the chart shall correspond to inductive power factors and in the upper part to capacitive power factors. The reference values of power factor (0.92) defined in the Resolution 414 from ANEEL shall be presented in a line on the chart;

3.2.5.13.2 Graph of the load curve (daily, weekly, monthly) from the point of metering and from the available channels, with at least the following features and characteristics:

Option to view the data recorded in any of the channels (as available in the meters);

The period, in the initial execution conditions, shall automatically offer the available reading period;

Possibility of choice of the date and of the time of the start and of the end of the analysis;

Line chart or bar chart types, with different colors for each type of quantity; Ability to export data.

3.2.5.13.3 Phasor Analysis: it shall be composed by the data collected and stored in the same moment of the requirement. It shall be presented a graph with the phasor diagram of the metering point, showing the voltages, the currents and the angles for each of the three phases. The identification of the metering point must be presented with the date, hour and minute of the data billing. The screen of the phasor analysis must have at least the following characteristics:

It shall exhibit a framework where the alarms, if any, related to the metering point in analysis shall be shown, with description (type of alarm), date and time of the alarm detection;

It shall exhibit the current and voltage transformation ratio of the auxiliary transformers (RTC and RTP);

It shall exhibit a table with data from the fiscal page for each phase (A, B, C): voltage, angle of voltage, current, angle of current, power factor and power. It shall exhibit the data from the fiscal page for the primary and secondary sides of the metering, according to the transformation ratio associated with the consuming unit; It shall exhibit a table with the voltages between phases AB, BC and AC, at the primary and at the secondary sides of the metering, the phases sequence, the frequency and the values of the quantities of channels 1, 2 and 3;

It shall have an option to export the data of the phasor graph;

It shall have an option to generate a phasor analysis of the 'frame by frame' type in a pre-defined and user configurable period of time. The frames of the phasor analysis (graphs and tables) of each phasor reading shall be automatically and

(19)

one frame and the next shall be defined by the user. In this ‘frame by frame’ analysis shall also be available, in another graph, the quantities registered in the channels 1 , 2 and 3, also presented dynamically and progressively. There shall be buttons to control the projection of the ‘frame by frame’ screen such as start, stop, pause, forward and backward of the frames;

All the fields present on the screen of phasor analysis shall be automatically refreshed, according to the progress of the 'frames' in each phasor metering; The field 'Alarm', in the screen phasor analysis, shall also be automatically refreshed, according to the progress of the 'frames' in each phasor reading;

It shall be possible to perform this 'frame by frame' phasor analysis in a previously defined period;

It shall be possible to export, using Excel files format, the data used for assembling the frame by frame phasor analysis, arranged in the following columns: date; hour; meter; phase A voltage; phase B voltage; phase C voltage; phase A angle voltage; phase B angle voltage; phase C angle voltage; phase A current; phase B current; phase C current; phase A current angle, phase B current angle; phase C current angle; phase A power factor, phase B power factor, phase C power factor; phase A power; phase B power, phase C power, voltage between phases AB, voltage between phases BC voltage between phases AC, phases sequence, totalizer in channel 1; totalizer in channel 2; totalizer in channel 3; demand in channel 1, demand in channel 2, demand in channel 3. Each line of the file shall contain the data referred to each phasor reading, in the scheduled integration interval.

3.2.5.14 Meter Administration, Visualization and Change management.: Visualization of Meter parameters entry and update

Visualization Daylight saving time changes 15 minutes or less of interval data

Tariff programmed change

Change of display value period on meter display

Change of sequence and selection of registers for display on meter display Change of electric power integration period

Controllable output management

Change of registers within profile framework Change of profile periods

Change of voltage thresholds related to electricity quality Meter software change and Meter Firmware Update

Software shall be able to read any meters that provide a standard communication interface

Shall allow the exportation to Excel of the mass memory data for one meter (XLS format -worksheets), starting at a date set by the user;

Shall allow at least the visualization of the data of the parameters of each point, with, at least the following information:

Meter´s operative system version

(20)

Magnitudes of channels Battery status

Composition of the channels to calculate the PF The interval range of mass memory storage Integration interval

Shall allow the visualization of the data from all available channels on the meter in daily, weekly or monthly segmentation, for initial / final specified periods (day / month / year) in intervals of 5, 15 (default), 30 or 60 minutes, with exportation for, at least, the Excel format;

Shall allow the visualization of the data registers from channels, from every point, with at least the following information:

Presentation Mode (pulses and magnitudes) Grand total

Total at the direct peak Total at the reverse peak, Total off-direct peak Total off-reverse peak Total direct reserved Total reverse reserved Total direct intermediate Total reverse intermediate Demand of the last interval Maximum peak demand Maximum off-peak demand Maximum reserved demand Maximum intermediate demand Accumulated demand at the peak Accumulated demand off the peak Accumulated reserved demand Accumulated intermediate demand Reactive Energy Billing Unit

Reactive Power at Maximum Peak Demand

Reactive Power at Accumulated demand at the peak Total exceeding reactive energy

3.2.5.15 According to the capacity of the meter, it shall be possible to extract archives from all meters channels.

(21)

3.2.5.16 Virtual Meter 13; 3.2.5.17 Simulation14 ; 3.2.5.18 Fiscal Page 15;

3.2.5.19 The system must provide the following charts: Quantities x Time;

Typology of Load Curve.

3.2.5.20 The following reports shall be made available:

Parameters – It shall allow the visualization of the metering configuration parameters such as the transformation ratios of CT’s and VT’s, connection diagrams, constants, etc.;

Quantities - It shall allow the visualization of the electrical quantities programmed in the metering equipment;

Lack of energy - It shall allow the visualization of energy shortages, identifying the individual duration and the date and the time of the beginning of each one of them; Changes - It shall allow the visualization of changes made in the meter such as closing of bill invoices, change of parameters, change of the calendar clock, etc; Internal Registers - It shall allow the visualization of billing information such as energies and demands in the contemporaneous periods and in the periods previous to the billing;

Mass Memory - It shall display the load curve of the UC; Summarized Mass Memory;

Meters;

Schedule of Performed Billings.

3.3 Remote Subsystem

3.3.1 The Remote Subsystem is composed by remote units (gateways or modems) and energy metering equipment, according to ET-DD-006/2010 and to ET-DD-005/2010 respectively. The SUPPLIER shall provide the gateways or modems for the connection of the metering equipment to the central subsystem;

3.3.2 Some of the meters, provided with serial communication channel, optical port or IP, will be supplied by the PURCHASER so as to enable their interconnection with the remote units;

3.3.3 The meters supplied by the SUPPLIER will be applied in the sites as stated in ET-DD-017/2010.

3.4 Communication System

13

A virtual meter shall be understood as the feature that allows the generation of metering from data processing, adding and subtractions from the load curves of the several meters which data are in the database of the “MDM”.

14

This feature allows the change of any parameter of the meter. The system simulates how the mass memory of this meter would remain with the altered parameters. Through this operation complete or summarized reports may be obtained. The result may be saved in TXT, CVS or XLS files.

15_{A fiscal page shall be understood as the feature that allows the graphic analysis of the metering parameters such as angles,}

(22)

3.4.1 The communication system with which the MDM will be integrated, both to the gateways or modems and to the workstations of Regional Supervision Centers (CSR’s) is specified in ET-DD-010/2010.

3.4.2 Communication Protocols 3.4.2.1 The MDM must:

Support connection with energy meters that have serial, optical or Ethernet communication port of any manufacturer with public protocol, accessed by gateways or communication module;

To allow the communication under the public protocol ABNT NBR 14522, in such a way to integrate the existing meters in the PURCHASER’s system;

To be prepared for receiving new communication protocols, that shall be designed in layers fully independent of the application layer, reducing the costs and time required for their implementation and eliminating the necessity of validation at the application server.

To allow the communication of any gateway available in the market. If for this communication it will be necessary the development of a driver (collector layer) the SUPPLIER shall, at any time, by means of a confidentiality agreement, provide all the information necessary for the development and deployment of the driver. 3.5 Fraud Identification Decision Aid Module (or functions)

3.5.1 Applications of the MDM intended for the users of the losses cells (groups that work with revenue protection), business agents, field staff and engineering area, to support them with the analysis of data from the metering;

3.5.2 The main functionality of this module is the revenue protection activities. 3.5.3 This module shall:

Enable the analysis of the telemetry points by pre-defined rules, as detailed in this Technical Specification;

Enable the control of tasks/pending jobs to be performed for checks and actions related to cases of irregularities detected by the pre-defined rules;

Be capable to keep stored an unlimited number of analyses (the amount shall be only limited by the available disk space) and, at any time, to retrieve previous analysis. The searches shall result in lists of analyses, alarms and / or events allowing the user to go deep to the desired level of detail for each specific analysis. Provide, for each analysis performed by the system, the total consumption of the consumer unit, with the number of available days in the processed file. The system must additionally show, specifically for the consumers of Group A: the peak total, the off-peak total, the reserved total, the peak maximum demand, the off-peak maximum demand and the load factor.

3.5.4 Indicators of the performed analysis with:

Rules that were violated and rules that were not violated, with details; Disabled Rules or rules that could not be verified, with details;

Alarms / Events received during the period;

Chart of the load curve, able to be customized regarding zoom, period of time and level of detail.

(23)

3.5.5 Issue reports containing the details set out in any item, which should be recorded for later retrieval at the same level of detail.

3.5.6 A specific screen will present the cases with indication of any irregularity, and it shall be possible to apply filters for a better discrimination of the analysis. At least the following filters shall be available: rules of irregularity, branch of activity, meter serial number, time period, installation code and name of the consumer.

3.5.7 This module shall provide at least the following rules for signalization of cases with some irregularity in the metering, provided that the meter will allow the information. Notes: There may be more filters to be implemented, according to necessities observed by the PURCHASER in agreement with the SUPPLIER.

These filters shall be used for consumers with meters that provide the necessary data.

3.5.7.1 Change in consumption: Comparison of energy consumption in Channel 1, with an allowed limit. This rule shall be segmented in periods:

On weekends;

On working days (each day shall be classified separately); On Monday to Friday segments.

3.5.7.1.1 Information:

Average consumption in the period;

Average change in energy consumption of each period with regard to the average; Percent average change of the demand;

Allowable limit of variation for the average demand.

3.5.7.2 Variation of the Load Factor: Comparison of the Load Factor, with an allowed limit. This rule shall be segmented by periods:

On weekends;

Found result of the variation;

Limit of the allowed variation for each period.

3.5.7.3 Maximum demand: a comparison of the maximum demand, with an allowed limit. This rule should be segmented in periods:

On weekends;

Average peak demand per period;

Average change in the maximum absolute demand in relation to the average; Change in % of the maximum demand;

(24)

Limit of the allowable variation of the maximum demand.

3.5.7.4 Checking of the power failure intervals: It checks the power outages for long periods.

Maximum allowed interval; Found interval;

Date of an exceeded interval.

3.5.7.5 Verification of the change of consumption after power outages: Comparison of the consumptions before and after a power failure in accordance with the percentage drop allowed in the general parameterization for the 2 hours after and before the power failure.

Change in consumption

Allowed change in consumption.

3.5.7.6 Verification of unexpected changes: any change in the parameterization in the last 3 months, except bills, shall be signalized.

Date when an unexpected change was found.

3.5.7.7 Verification of the closing of the bill: it verifies whether there is a single closing of bills per month.

Date of the previous closing.

Date of closing of another invoice found in the same month.

3.5.7.8 Verification of changes in unexpected times: it checks the times of the changes in relation to a parameterized range of time (for example: 08:00 AM to 06:00 PM on a normal working day).

Date and time of occurrence of the change; Change made;

Configured interval of time.

3.5.7.9 Checking the configuration of summer time in the meter. It compares it with a model of registered parameters. It checks if there is an enabled daylight saving time parameter.

Starting date of the parameterized summer time; Ending date of the parameterized summer time;

Status of the enabling of summer time found on the meter; Starting date of the summer time verified in the meter;

(25)

Ending date of the summer time verified in the meter.

3.5.7.10 Checking the configuration of the interval of integralization in the meter. It compares it with the registered model parameter.

3.5.7.10.1 Information:

Expected range of integration.

Range of integration found in the meter.

3.5.7.11 Checking the configuration of reserved time in the meter. It compares it with the registered parameter model.

Habilitation of the verified reserved time segments; Habilitation of the expected reserved time segments.

3.5.7.12 Checking the battery status in the meter. It compares it with the registered parameter model.

Expected battery status. Verified battery status.

3.5.7.13 Checking the method of calculation of the demand in the meter. It compares it with the registered parameter model.

Method of expected calculation of the demand.

Method of the calculation of the demand parameterized in the meter.

3.5.7.14 Checking the method of calculation of the quantity of energy corresponding to the reactive surplus in the meter. It compares it with the registered parameter model. 3.5.7.14.1 Information:

Expected method of calculation of the quantity of energy corresponding to the reactive surplus;

Found method of calculation of the quantity of energy corresponding to the reactive surplus.

3.5.7.15 Checking the reference power factor in the meter. It compares it with the registered parameter model.

Value of the expected reference power factor;

Value of the reference power factor found in the meter.

3.5.7.16 Checking the range of the mass memory in the meter. It compares it with the registered parameter model.

(26)

Range of mass memory found in the meter..

3.5.7.17 Verification of the configuration of the peak hours, off peak hours and reserved time hours of the meter. It compares it with model parameters registered.

Indication if the setting of the meter matches with the parameterized setting; Indication if the setting of the peak hours, off peak hours and reserved hours on Saturdays match the parameterized setting for Sundays;

Indication if the setting peak hours, off peak and reserved hours on Sundays match with the parameterized setting for holidays.

Indication if the setting peak hours, off peak hours and reserved hours on Sundays match with the parameterized setting for Saturdays;

Peak Time (start-end) Configuration of the first peak time on the meter; Peak Time (start-end) Configuration of the second peak time on the meter; Peak Time (start-end) Configuration of the third peak time on the meter; Peak Time (start-end) Configuration of the fourth peak time on the meter.

3.5.7.18 Checking the configuration of reactive energy segments in the meter. It compares it with model parameters registered.

Indication if the setting of the meter matches with the parameterized setting; Indicative if the configuration of reactive energy segments on working days matches with the parameterized setting for normal working days;

Indicative if the configuration of reactive energy segments on Saturdays matches with the parameterized setting for Saturdays;

Indicative if the configuration of reactive energy segments on Sundays matches with the parameterized setting for Sundays;

Indicative if the configuration of reactive energy segments on holydays matches with the parameterized setting for holidays;

Indicative if the configuration of peak hours, off peak hours and reserved hours on Sundays match the parameterized setting for Sundays;

Setting of the first time of reserved hours on the meter; Setting of the second time of reserved hours on the meter.

3.5.7.19 Checking the consistency of the internal clock of the meter. It compares the weekday informed in the file with the actual weekday corresponding to the day of the extraction of the file.

Day of the week corresponding to the actual date of extraction of the file; Weekday informed in the file.

(27)

It checks whether there is a considerable drop in consumption at the beginning of the file, and an increase in the consumption at the end of the file. It considers 3 days after the start and 3 days at the end of the file (closing the bill).

Average consumption of the reading file;

Average consumption of the first 3 days of the reading file; Average consumption of the last 3 days of the reading file;

Variation of the average metering of the first 3 days with the average of the file; Variation of the average metering of the last 3 days with the average of the file; Allowed variation.

3.5.7.21 Verification of the consistency of the consumption with thee last quarter. It checks if the last consumption is coherent with the last quarter (it checks the average consumption of the last quarter with the current month).

Average consumption of the previous quarter; Consumption of the current month of the reading;

Variation between the average of the previous quarter and the current month; Allowed variation.

3.5.7.22 Verification of the metering constants of the consume channels. It checks if the constant of channel 1 corresponds to the constant of channel 2.

Value of the numerator of the constant of channel 1; Value of the denominator of the constant of channel 1; Value of the numerator of the constant of channel 2; Value of the denominator of the constant of channel 2.

3.5.7.23 Verification of available data. It checks if there are any data for the specific channel. 3.5.7.23.1 Information:

Verification of data available on channel 1; Verification of data available on channel 2; Verification of data available on channel 3.

3.5.7.24 Verification of national holidays in the current year. It checks whether the registration of non-working days of the meter is equivalent to the expected.

3.5.7.25 Checking the version of the firmware of the meter according to the prefix. It checks if there is and which is the prefix registered for the meter. It compares it with the expected data.

(28)

Description of the prefix found for the meter. Found version of the firmware.

3.5.7.26 Checking the configuration of the units of channels 1, 2 and 3. It checks if the quantities are configured as follows:

kWh, kVArh and Vh;

kWh, inductive kVArh and capacitive kVArh. 3.5.7.26.1 Information:

Quantity set in the meter for channel 1. Quantity set in the meter for channel 2. Quantity set in the meter for channel 3.

3.5.7.27 Systematic occurrence of power outages. It checks the frequency of power outages on a same day of the week. If the frequency is bigger than 2 occurrences it shall be notified.

Numbers of occurrences of power outages grouped by day of week.

3.5.7.28 Verification of data continuity in channels 1, 2 and 3. It checks whether there was a zero consumption or a lack of voltage (channel 3) and compares whether this interval corresponds to a record of power failure.

The date in which consumption was zeroed or a lack of voltage was verified out of the reported intervals of power failures;

It informs when the rule was not implemented. Note:

The verification of missing data related with voltage is only applicable when the meter displays voltage information on channel 3.

3.5.7.29 Checking of minimum voltage: it checks the voltage below established limits. 3.5.7.29.1 Information:

Minimum allowed value; Result found;

Data and time when it was found a voltage below the minimum value.

3.5.7.30 Verification of the variation between phase currents. It checks the imbalance between the currents when compared with the maximum variation allowed. This rule should be segmented in periods:

On weekends;

On working days (each working day shall be classified separately); On Monday to Friday segments.