SOFTWARE’S TECHNICAL REGULATION

1. OBJECTIVE AND AREA OF APPLICATION

1.1. This Regulation establishes the technical requirements of software for distributed electrical
energy metering systems (referred to as SDMEE) for use in consumer units.
1.2. In order to apply this Regulation, the target SDMEE is composed of all elements involved
in the capture, processing and publication of the result (display device) to the end user
(consumer).
1.3. The elements of the SDMEE directly involved or that, in any way, interfere in the
processes of capture, processing and publication of the result to the end user, are said to be
“legally relevant” and must fully meet the set of requirements contained in this Regulation.
1.4. The Pictures 1 and 2, below, exemplify the two different possible architectural
configurations of the SDMEE with their respective elements considered to be legally relevant
outlined by the dotted line. The elements not contained in the dotted space are not considered
legally relevant because they do not directly involve or interfere in any way in the processes of
capture, processing and publication of the result to the end user.

Picture 1

Picture 2

1.5. All evidence related to the compliance with the requirements established in this Regulation
shall be provided by the manufacturer.
2. TERMINOLOGY
2.1. Legally relevant
Software/hardware/data that interfere with the requirements regulated by legal metrology,
for example, the measurement’s accuracy, or in the correct functioning of the system.
The national regulatory metrology authority is responsible to specify which
software/hardware/data is considered legally relevant.
2.2. Communication interface
Any type of interface that enables the transfer of information between the components of
the measurement systems (optical, radio, electronics, etc.).
2.3. Authentication
Proof of claimed/alleged identity of a user, process or device.
2.4. Integrity
Guarantee that the data/software/parameters have not been changed during use, repair,
maintenance, transfer or storage without authorization.
2.5. Confidentiality
Guarantee that data/parameters have not been disclosed to unauthorized people, legal
entities or processes during use, repair, maintenance, transfer or storage.
2.6. Availability
Guarantee that the data/software/parameters/system are available to the authorized
processes or legal entities when requested.
2.7. Attack
Any unauthorized action that may compromise the security of the
data/parameters/software/system.
2.8. Download
Automatic software transfer process to the distributed metering system using any
appropriate local or remote means.
2.9. Software identifier
Uniquely assigned readable string to software.
2.10. User interface
Allows for the exchange of information between the human user and the distributed
metering system, or its hardware and software components.
2.11. Validation
Confirmation through analysis and generation of objective evidence that the specific usage
requirements were fully satisfied.
2.12. Hash
Mathematical function that maps values of a block of data into a fixed and reduced
number (hash code), with the following properties:
(i) Changing any bit of a data block implies a different hash code;
(ii) It is not feasible, from a hash code, to return to the original data block;
(iii) It is not feasible to find two blocks that generates the same hash code.
 2.13. Digital signature
Code uniquely assigned to a text/data/software file in order to prove its integrity and
authenticity when transmitting or storing. Usually a digital signature is generated in two
steps:
(i) The hash code of the file is initially calculated;
(ii) A private key is used to encode this code.

3. P-TYPE REQUIREMENTS: EMBEDDED SOFTWARE FOR MEASUREMENT

SYSTEMS
P-type measurement systems are those that make use of embedded software, according to the
following considerations:
a) All application software was developed for measurement, including functions subject to
legal metrological control, as well as the remaining ones;
b) The software is designed and treated as a whole, unless there is a separation of software
according to the requirements described in item 5 (S-type Requirements: Software
separation);
c) The user interface is dedicated to the measurement application;
d) There is no operating system for sharing computing resources with other users;
e) The software and its environment are invariable: there are no means available to change
the legally relevant software; the software load is only allowed when the requirements
described in item 6 (D-type Requirements: Legally relevant software download) are met;
f) Interfaces for the transmission of measurement data through communication networks are
allowed, provided they meet the requirements in item 3.5 (Communication interface
influence in the SDMEE).
3.1. The P-type requirements are divided in:
a) Documentation;
b) Software Identification;
c) User interface influence on the SDMEE;
d) Communication interface influence on the SDMEE;
e) Protection against accidental/unintentional changes;
f) Protection against intentional changes;
g) Parameter protection.
3.2. Documentation
In addition to the specific documentation required for the evaluation of the other
requirements described throughout this document, the regulation should basically include:
a) Architectural description and commented source code of all legally relevant software;
b) Description of the measurement algorithms’ accuracy (calculation and rounding of
results);
c) Description of the user interface, menus and dialogues (if any);
d) Unequivocal identification of the software;
e) Description of the hardware system, which includes: topology, block diagram,
processor type and type of network;
f) Operating Manual.
3.3. Software Identification
The legally relevant software must be clearly identified. Software identification must be
indissolubly linked to the software. It must be displayed on command or automatically
during the operation of the SDMEE.
3.3.1. Technical requirements
a) Each change in the software defined as legally relevant shall be evaluated and
approved by Inmetro and have a new identifier.
b) The software identifier must have a structure that clearly identifies the versions
that need evaluation and approval and those that do not need it.
3.3.2. Required Documentation
The documentation should describe the software identifiers, how they were created,
how the identifiers are indissolubly linked to the software, how the identifiers can
be accessed for visualization, and how they are structured in order to differentiate
between versions that require or do not require change approval.
3.4. User interface influence on the SDMEE
None of the commands generated through the interface of the power distributor shall
influence the legally relevant software, nor the measurement data, in a manner not
foreseen in the description presented in the model approval process.
3.4.1. Technical requirements
a) The commands can be triggered by a single key press or by a sequence of
manually performed operations.
b) There must be an unequivocal and unambiguous assignment of each command
and its function or the data chance procedure.
c) The activation of keys that are not explicitly declared and documented as
commands cannot have any effect on the functions of the system or
measurements.
3.4.2. Required documentation
a) A complete list of all the existing commands together with a declaration of
completeness.
b) A description of each command’s meaning and its effects on the system’s
functions and data.
c) Description of the procedures performed to validate the completeness of the
commands.
d) A description of the tests carried out to prove the declared functionality of the
controls.
3.5. Communication interface influence on the SDMEE
Commands introduced through SDMEE communication interfaces shall not influence
legally relevant software or measurement data, in a manner not provided for in the
description presented in the model approval process.
3.5.1. Technical requirements
a) There must be an unequivocal and unambiguous assignment of each command
to a function or a change of data.
 b) Signals or codes that are not declared and documented as commands cannot
have any effect on the functions and data of the system.
c) Commands can be a sequence of signals (electrical, optical, electromagnetic),
input channels or data transmission protocol codes.
d) This requirement applies only to interfaces that are not sealed.
3.5.2. Required documentation
a) A complete list of all the commands together with a declaration of
completeness.
b) A description of the meaning of each command and its effect on the functions
and data of the SDMEE.
c) The procedures used to validate the completeness of the documented
commands.
d) A description of the tests carried out to prove the declared functionality of the
controls.
3.6. Protection against accidental/unintentional changes
Legally relevant software and measurement data must be protected against accidental or
unintended modifications.
3.6.1. The possible reasons for accidental and unintended modifications are:
a) Unpredictable physical influences
 The data storage of the measurements must be protected against corruption or
suppression in the presence of a fault or, alternatively, the fault (error) must
be detectable.
b) Effects caused by user functions
 Confirmation must be required before deleting or changing the data.
c) Residual software defects
 Adequate measures should be taken to protect data from unintentional
changes that may occur through an incorrect design or programming errors,
for example, plausibility checks.
3.6.2. Required documentation
The documentation should show the measures that have been taken to protect the
software/data against unintended changes.
3.7. Protection against intentional changes
Legally relevant software must be protected from tampering, loading and memory
swapping.
3.7.1. Technical requirements
a) System without interface: ensure that the system enclosure is secure (tamper-
evident), or that physical memory cannot be removed without authorization.
b) Systems with interface: the interface should contain only functions that can be
examined.
c) The data is considered sufficiently protected if it is processed only by legally
relevant software. If there is a need to change software that is not legally
relevant, after evaluation and approval by Inmetro, the requirements of S-type,
defined in item 5, must be met.
 3.7.2. Required documentation
The documentation must provide assurances that the legally relevant software may
not suffer unauthorized changes, also, the protective measures taken to prevent
these changes must be highlighted in the source code.
3.8. Parameter protection
The parameters that set the legally relevant characteristics of the distributed metering
system must be protected against unauthorized modifications.
3.8.1. Technical requirement
Model-specific parameters are identical for all copies of the same product and are
generally part of the program code. In addition, they must meet the requirements
described in sub-item 3.7.
3.8.2. Required documentation
Description of all relevant legal parameters, including:
a) Nominal values and variation margins;
b) Where they are stored;
c) How they can be visualized;
d) How they are protected;
e) When (whether before or after evaluation and approval by Inmetro).

4. T-TYPE REQUIREMENTS: DATA TRANSMISSION THROUGH COMMUNICATION

NETWORKS
The set of T-type requirements applies only when the system uses an internal communication
network to transmit and receive legally relevant measurement data. The set of requirements
for data transmission via network are:
a) Completeness of transmitted data;
b) Protection against accidental/unintentional changes;
c) Data integrity;
d) Authenticity of transmitted data;
e) Confidentiality of keys;
f) Manipulation of corrupted data;
g) Transmission delay;
h) Availability of transmission services.
4.1. Completeness of transmitted data
The transmitted data must include all the information necessary for the presentation or
processing of the measurement on the receiving device.
4.1.1. Technical requirements
The metrological content of the transmitted data is composed of:
a) One or more measurement values at the correct resolution;
b) The unit of measurement;
c) Temporal information;
d) Identification of measurement point.
 4.1.2. Required documentation
Description of all data unit fields transmitted.
4.2. Protection against accidental/unintentional changes
The transmitted data must be protected against accidental or unintentional changes.
Accidental changes of data are caused by physical phenomena, and unintentional changes
are caused by the system user.
4.2.1. Technical requirement
Means must be provided for the detection of transmission errors.
4.2.2. Required documentation
a) Description of the checksum algorithm (if used), including the length of the
generator polynomial.
b) Description of the alternative method (if applicable, e.g.: hash).
4.3. Integrity of transmitted data
The legally relevant data transmitted must have its integrity checked and can only be used
if it is confirmed.
4.3.1. Required documentation
Description of the integrity check method.
4.4. Authenticity of transmitted data.
It must be possible to verify the authenticity and assignment of the measurement values to
a given measurement point at the reception of the data.
4.4.1. Technical requirements
a) It is necessary to identify the unambiguous origin of the transmitted
measurement data.
b) In order to cope with the possible transmission delays, it is necessary that the
measurement instant is recorded next to the measurement value.
c) To ensure authenticity it is not necessary to encrypt the data.
4.4.2. Required documentation
Description of the IT mechanisms that guarantee correct assignment of the value of
measurement to a specific meter.
4.5. Confidentiality of keys
The cryptographic keys (and related data), if used, should be treated as legally relevant
data and should be kept secret and protected from being corrupted.
4.5.1. Technical requirement
Protection should cover intentional chance attempts from attacks.
4.5.2. Required documentation.
Description of main manipulation and management mechanisms of keys to keep
them secret.
4.6. Manipulation of corrupted data
Data identified as corrupted must not be used.
4.6.1. Required documentation
a) Description of the mechanism for detecting transmission errors or intentional
changes.
b) Description of the mechanisms used to manipulate the corrupted data
 4.7. Transmission delay
A measurement cannot be influenced by the communication.
4.7.1. Technical requirements
The manufacturer must ensure that, even under the worst conditions of the means of
communication (high traffic, for example), it will not invalidate the measurements.
4.7.2. Required documentation
Description of how the measurement is protected against the performance of the
communication devices and the processing resulting therefrom.
4.8. Availability of transmission services
Even if the communication network services become unavailable, there should be no loss
of measurement data and the display device installed on the consumer should signal such a
situation.
4.8.1. Technical requirement
The user of the distributed metering system should not be capable of corrupting
measurement data as a function of transmission suppression. The distributed
measurement system must be able to handle transmission problems.
4.8.2. Required documentation
Description of the protection procedures against transmission interruptions or other
errors.

5. S-TYPE REQUIREMENTS: SOFTWARE SEPARATION

Software-controlled SDMEE can have complex functionalities and contain modules that are
legally relevant and modules that are not. Software separation is a methodology that allows
the manufacturer to easily modify software that is not legally relevant. The separation
requirements for software are:
a) Carrying out the separation of software;
b) Shared presentation;
c) Protective software interface.
5.1. Carrying out the separation of software
There must be a part of the software that contains all legally relevant modules and
parameters, clearly separate from the other software components.
5.1.1. Technical requirements
a) All legally relevant software (subroutines, procedures, functions, classes) and,
in the case of high-level separation, all programs and libraries which contribute
to:
 The calculation of measurement of values or that have an impact on it;
 Auxiliary functions such as data display, data security, data storage, software
identification, software loading, transmission or storage of data, checking or
storing the received data.
b) All variables, temporary files and parameters that have an impact on the
measurement values or legally relevant functions, or even data, are part of the
legally relevant software.
 c) The components of the protective software interface (see 5.3) are part of the
legally relevant software.
d) Legally non-relevant software includes the remaining program units and data or
parameters not included in the previous categories. Modifications to this part are
permitted provided that software separation requirements are observed.
5.1.2. Required documentation
Description of all components described above that pertain to legally relevant
software. The correct implementation of software separation should be
demonstrated in the documentation.
5.2. Shared presentation
Additional information generated by software that is not legally relevant can only be
displayed (or printed) if it cannot be confused with the information that originates from
the legally relevant part.
5.2.1. Required documentation
a) Description of the software that performs the presentation.
b) Description of how the presentation of legally relevant information is made and
the existence of a shared presentation must be explicitly documented.
5.3. Protective software interface
The exchange of data between legally relevant and non-relevant software must be
performed through a protective interface that covers all interactions and data flows.
5.3.1. Technical requirements
a) Any interactions and data flows must not inadmissibly influence legally relevant
software, including the dynamic behavior of the measurement process.
b) There must be an unequivocal assignment of each command sent through the
software interface to a function or a change of data of the legally relevant
software.
c) Codes and data that are not declared and documented as commands should have
no effect on legally relevant software.
d) The interface must be fully documented, and any other undocumented
interactions/flow of data should not be performed by either the programmer of
the legally relevant software nor the programmers of the non-relevant software.
5.3.2. Required documentation
a) Description of the software interface.
b) A complete list of all the commands together with a declaration of
completeness.
c) A description of the controls and their effects on SDMEE functions and data.

6. D-TYPE REQUIREMENTS: LOADING OF LEGALLY RELEVANT SOFTWARE

D-type requirements must be used to enable the download of legally relevant software. The
legally non-relevant software load is not subject to these requirements. The legally relevant
software load requirements set consists of:
a) Load mechanism (download);
b) Remotely loaded software authentication;
 c) Integrity of loaded software;
d) Loaded software traceability;
e) Permission to load.
6.1. Load mechanism (download)
The loading and subsequent software installation must be automatic and must ensure that
the software protection environment is not compromised at the end of the process.
6.1.1. Technical requirements
a) The loading procedure must be automatic to ensure that the existing level of
protection is not compromised.
b) The target device must have legally relevant software permanently resident and
unvarying, with all functions necessary to verify the requirements defined in
sub-items ‘6.2’ to ‘6.5’.
c) The device must be capable of detecting a failure during the loading and
installation processes, generating a signal of this occurrence. If the loading or
installation fails, or if it is interrupted, the initial system state should not be
affected. If this is not possible, the system should display a permanent error
message and its metrological operation must be prevented until the error is
corrected.
d) In the case of a successful installation, all forms of protection must be restored
to their original state, unless the software loaded has the appropriate
authorization to change them.
e) During loading and installation of new software, the measurement functions of
the system must be prevented if they cannot be fully guaranteed.
f) Even if the requirements defined in sub-items ‘6.2’ to 6.5’ cannot be met, it is
still possible to load the legally non-relevant part of the software, provided that
the following requirements are met:
 There is a clear separation between legally relevant and legally non-relevant
software, in accordance with the requirements of item 5 (S-type requirements:
Software separation);
 Any part of the legally relevant software is permanent and unvarying, that is, it
cannot be loaded or altered without a seal being broken.
6.1.2. Required documentation
The documentation should describe: the automatic loading process, the verification
and installation process, how the protection level is guaranteed at the end and what
happens when a failure occurs.
6.2. Remotely loaded software authentication
Means shall be employed to ensure the authenticity of the loaded software and to indicate
that this software has been previously evaluated and approved.
6.2.1. Technical requirements
a) Before using the loaded software, the SDMEE shall automatically check if:
 the software is authentic (not fraudulent);
 the software is approved for this type of distributed metering system.
 b) The means by which the software identifies its prior authorization shall be
protected to prevent counterfeiting.
6.2.2. Required documentation
The documentation should describe how:
a) The authenticity of the software identification is guaranteed;
b) The authenticity of the prior approval is guaranteed;
c) It is guaranteed that the loaded software has been approved for the type of
SDMEE in question.
6.3. Integrity of loaded software
Means shall be employed to ensure that the software has its integrity checked and can only
be used if it is found.
6.3.1. Required documentation
The documentation should describe how the integrity of the software is guaranteed.
6.4. Loaded software traceability
Appropriate technical means must ensure that all loaded software is properly identified
and recorded in the distributed measurement system for post-control purposes.
6.4.1. Technical requirements
The procedures and records responsible for traceability are part of the legally
relevant software and should be protected as such.
6.4.2. Required documentation
The documentation should:
a) Describe how traceability is implemented and protected;
b) Demonstrate how software loads are tracked.
6.5. Permission to load
It must be guaranteed by technical means that the software can only be loaded with the
explicit permission of the SDMEE proprietary power distributor.
6.5.1. Technical requirements
a) After a distributed metering system has been put into service, the electric power
distributor is responsible for controlling the loading permit. This requirement
ensures that the manufacturer cannot change the legally relevant software of the
SDMEE without the explicit consent of the distributor.
b) The mean by which the proprietary power distributor expresses its permission is
part of the legally relevant software and should be protected as such. Their
permission is required by default unless stated otherwise.
c) The availability of the device for loading must be indicated to the power
distributor.
6.5.2. Required documentation
The documentation shall describe the technical means by which the loading process
considers the permission of the electric power distributor.

7. FAILURE SELF-DIAGNOSIS
The software must be able to diagnose a state of malfunctioning.
7.1. Required documentation
 a) Description of the fault diagnosis mechanism and when it is invoked;
b) Description of the tests carried out by the manufacturer.

7.2. Backups
There should be a mechanism that provides for periodic copies of legally relevant data,
such as measurement results and the current status of the processes, in order to enable a
subsequent retrieval of the distributed measurement system after a malfunction. This data
must be saved to nonvolatile media.
7.2.1. Technical requirements
The backup frequency must be compatible with the fault diagnosis mechanism.
7.2.2. Required documentation
A description of the data with a copy, a description of the update frequency and the
calculation used to justify this frequency.

8. ADVANTAGING THE DISPLAY DEVICE

8.1. The electronic or electromechanical display device shall be capable of recording, from
zero, for a minimum time of 1150h, the energy corresponding to the maximum current at the
highest rated voltage and unitary power factor.
8.2. The maximum update time allowed for each KWh consumed is 1min.
8.3. The display device shall be capable of displaying the information required in sub-item
4.1.1.
8.4. Required documentation
Documentation regarding the form of parameterization of information presented by the
user interface (display device). For example: number of digits, resolution, presentation
time, etc.

9. DYNAMIC BEHAVIOR
Software that is not legally relevant cannot negatively influence the dynamic behavior of a
measurement process. This means that if there is a sharing of processing resources, legally
relevant software must always have the necessary availability for its proper functioning (e.g.:
priority over non-relevant software).
9.1. Technical requirements
a) This requirement applies in addition to the requirements set out in 5.1, 5.2 and 5.3 for
separation of software.
b) This additional requirement ensures that, for real-time meter applications, the dynamic
behavior of legally relevant software is not influenced by legally non-relevant
software, that is, the legally relevant software features cannot be changed in a way not
supported by the non-relevant part.
9.2. Required documentation
a) Description of the interruption hierarchy;
b) Time chart of the software tasks. Execution time limit for legally non-relevant tasks.
10. REQUIREMENTS FOR SOFTWARE VALIDATION
The techniques used for software validation, along with the results of the tests implemented,
should be enumerated. The results of this validation phase are expected to eradicate
predictable errors, such as: extrapolation of input/output limits and division by zero.

11. PROCESSING LOAD CAPACITY

All components of the distributed electric power metering system (SDMEE) of shared use
(concentrators, communication networks) must be dimensioned according to the moments of
high load. All calculations proving the sharing capability must be provided.