Instituto Nacional de Metrologia, Qualidade e Tecnologia

ORIENTATIONS FOR EDITING SOFTWARE DESCRIPTIVE MEMORY FOR ELECTRIC POWER METERS

Guidance Document

DOQ-DIMEL-009

Review 00 – November/2018

MOD-Gabin-039 - Rev. 00 – Published Apr/16 – Pg.1/20– Responsibility: Gabin – Reference(s): NIG-

Gabin-040
SUMÁRIO
1. OBJECTIVE
This document intends to provide basic information for the writing of the software’s descriptive
memorial for electric energy meters. In the software’s descriptive memorial, the applicant explains how
he fulfilled the requirements of the Inmetro Ordinance 586/2012.

2. APPLICATION FIELD
It applies to applicants and laboratories involved in the software evaluation process of the legal
metrology board.

3. RESPONSIBILITY
The responsibility for the approval, revision and cancellation of this Standard befalls to Sinst.

4. REFERENCE DOCUMENTATION
Inmetro Ordinance nº371 Approves the technical and metrological requirements as minimum
from Sep 28th, 2007 conditions to be met by Centralized Measurement Systems for use in
measuring electric power in consumer units.
Inmetro Ordinance nº586 Approves the metrological technical regulation of software for electronic
from Nov 1st, 2012 power meters and software for distributed power measurement
systems.
Inmetro Ordinance nº587 Approves the technical metrological regulation for active and/or reactive
from Nov 5th, 2012 electronic meters, single-phase and multi-phase, including the
reconditioned ones.
Inmetro Ordinance nº232 International Metrology Vocabulary: Fundamental and General Concepts
from May 8th, 2012 and Associated Terms (VIM) – 1st Luso-Brazilian Edition (2012).
Inmetro Ordinance nº163 International Vocabulary of Legal Metrology Terms
from Sep 6th, 2005
OIML D 31 General requirements for software-controlled measuring instruments –
OIML, 2008
OIML D 11 General requirements for electronic measuring instruments – OIML,
2004
WELMEC Software Guide Measuring Instruments Directive 2004/22/EC – WELMEC, March 2012
7.2 Issue 5
Inmetro’s meeting Software security and interoperability
minutes Jun 23rd, Jul 2nd,
Jul 3rd, Sep 22nd; 2015
SP 800-22 A Statistical Test Suite for Random and Pseudorandom Number
Generator for Cryptographic Applications
SP 800-57 Recommendation for Key Management, Part 1: General

5. COMPLEMENTARY DOCUMENTS
NIT-Sinst-003 Organization of documentations for the software evaluation process
NIT-Sinst-019 Software analysis for the evaluation of instrument/power measurement
system model
Plan-Sinst-019 Software Evaluation Record Worksheet for Evaluation of
Instrument/Power Metering Systems Models
6. DEFINITIONS
6.1. Acronyms
Inmetro’s UP/UO acronyms can be accessed at:

http://intranet.inmetro.gov.br/tema/qualidade/docs/pdf/siglas-inmetro.pdf

AM Avaliação de Modelo (Model Evaluation)

RTM Regulamento Técnico Metrológico (Technical Metrological Regulation)

VIM Vocabulário Internacional de Metrologia (International Metrology Vocabulary)

VIML Vocabulário Internacional de Metrologia Legal (International Legal Metrology Vocabulary)

EFS Ensaio Funcional de Software (Software Functional Testing)

AMD Análise do Memorial Descritivo (Descriptive Memorial Analysis)

ACF Análise do Código Fonte (Source Code Analysis)

SDMEE Sistema Distribuído de Medição de Energia Elétrica (Distributed Power Measurement System)

TLI Terminal de Leitura Individual (Individual Reading Terminal)

DVIS Dispositivo Verificador de Integridade de Software (Software Integrity Verification Device)

RTOS Real Time Operating System

ROM Read Only Memory

6.2. Terms
6.2.1. Binary File
Computer file that is not in text format, coming from the compilation of a source code, which contains
legally relevant software.

6.2.2. Digital Signature

Result from an algorithmic process, which ensures authenticity, integrity, non-repudiation and
authorship of a digital file or measurement.

6.2.3. Gross Force Attack

Method of obtaining unauthorized information by trial and error.

6.2.4. Integrity Authentication

The process of providing assurance that the data, or software, has not been modified since an
authentication code was created for that data.

6.2.5. Source Authentication

The process of providing assurance about the source of information. Sometimes called identity
authentication or source authentication.
6.2.6. Buffer Overflow
Anomalous situation where a program writes data in a buffer and exceeds defined limits, accessing
adjacent memory and causing an unexpected behavior.

6.2.7. Legally Relevant Chain

Every hardware and software involved in the measurement process consisting of the acquisition,
processing and publication of measurement data.

6.2.8. Software Load

Automatic software transfer process to the measuring instrument using any appropriate local or remote
means without the need to break main sealing.

6.2.9. Test Case

A specification containing the state of the system, a set of inputs, a process and expected outputs in
order to validate the system for a given requirement.

6.2.10. Checksum
Code used to verify the integrity of transmitted data.

6.2.11. Activity Diagram

Flowchart that demonstrates the logic of operations of a particular process. Each step of the process, or
activity, is denoted by a rectangular box and every decision denoted by a diamond.

6.2.12. Time Diagram

Graphical representation of the entities that make up a system and its interactions on a time scale

6.2.13. Software Documentation

Set of digital files to be delivered to Dimel/Disme/Sinst, to be analyzed in a process of analysis of
software requirements. Synonym for delivery package. See NIT-Sinst-003 item 6.2.15.

6.2.14. State
Establishes the current set of system conditions. In a given state the system behaves, waits for a trigger
or performs some action.

6.2.15. U-Type Computer Instrument

An instrument with a general-purpose computer, usually based on a PC, that does not conform to the
definition of a P-type computer.

6.2.16. P-Type Computer Instrument

An instrument with an embedded P-type computer is characterized by:

a) The software is built exclusively for measurement purposes. Additionally, functions for software and
data protection, data transmission and software loading are considered to be built for measurement
purposes.
b) The user interface is dedicated for the measurement purpose.
c) An operating system (OS) or subsystem can be included if only legally relevant software has external
communication; if it does not allow you to load or change programs, parameters or data or run
programs; if it does not allow changing the environment of the legally relevant application; and
includes access control and does not allow for a subsequent change in access control configuration.
d) The software environment is invariable and there are no internal or external means to program or
change the software in its embedded status except when the software load requirements are met.

6.2.17. User Input Interface

Interaction interface with the instrument through physical mean, such as a keyboard or touchscreen.

6.2.18. Protective Software Interface

Interface between legally relevant software and legally non-relevant software.

6.2.19. Interrupt
Hardware interrupt is a signal form a device sent to the processor in order to interrupt the usual flow of
instructions for an execution exception to be handled.

6.2.20. Legally Relevant

All software modules (programs, subroutines, objects, etc.) that perform legally relevant functions or
contain legally relevant data domains form the legally relevant part of a software from a measuring
instrument. More specifically, this includes all software modules that:

a) Have an impact on the calculation of a legal measurement unit;

b) Contribute to functions such as: display, protect and store legally relevant data;
c) Identify legally relevant software or;
d) Execute legally relevant software load.

6.2.21. Data Memory

Memory area with read and write permission (RAM) used to save data.

6.2.22. Program Memory

Memory area where the current program is written.

6.2.23. Descriptive Memorial

Document that describes in detail the technological implementations aimed at meeting the hardware
and software security requirements.

6.2.24. Configuration Mode

Mode that allows you to change legally relevant parameters.

6.2.25. Non-legally Relevant

All software/hardware/data present on the instrument that are not legally relevant.

6.2.26. Legally Relevant Parameter

Parameter of a measuring instrument or one of its sub-assemblies subject to legal control.

6.2.27. Metrologically Relevant Parameter

Legally relevant parameter which is used in the calculation to obtain the measurement value. For
example, in a white rate meter, date and time are legally relevant parameters, but they are not
metrologically relevant. Kh is a metrologically relevant parameter.

6.2.28. Cryptographic Primitive

Low-level cryptographic algorithms well established in the literature that are used to construct
cryptographic protocols for computer security systems.
6.2.29. Open Network
A network of arbitrary participants (devices with arbitrary functions). The number, identity and location
of a participant can be dynamic and unfamiliar to other participants.

6.2.30. Closed Network

A network of a fixed number of participants with a known identity, functionality and location.

6.2.31. Change/Audit Log

A set of data containing the record of any events and/or changes in the instrument that are legally
relevant and likely to influence its metrological characteristics.

6.2.32. Registry of Changes in Relevant Metrological Parameters

Audit log that stores events related to changes in relevant metrological parameters in the instrument.

6.2.33. Registry of Legally Relevant Software Loads

Audit log that stores events related to legally relevant software load operations in the instrument.

6.2.34. Applicant
It is every legal, public or private entity, national or foreign, headquartered in Brazil, that develops
activities of production, assembly, creation, construction, transformation, import, export, distribution or
sale of instruments.

6.2.35. Specific Software Requirements

Legally relevant software and hardware that employ specific technological features must meet the
specific RTM requirements in question.

6.2.36. General Software Requirements

The software and hardware considered legally relevant must meet all the general requirements of the
RTM in question.

6.2.37. Main Sealing

Sealing of the measuring instrument that demonstrates that it will be able to operate upon verification
by the Organ of the RBMLQ-I or by an authorized entity.

6.2.38. Operating System

A collection of software and firmware elements that control the execution of computer programs and
provide services such as computer resource allocation, task control, input/output control and file
management on a computer.

6.2.39. White Tariff

It is a mode of horo-seasonal tariff offered for consumer units at low voltage.

6.2.40. Horo-seasonal Tariff

Structure characterized by the application of differentiated rates of electric power consumption and
power demand according to the hours of use of the day and the periods of the year, as specified below:

a) Blue Tariff: modality structured for the application of differentiated tariffs of electric energy
consumption according to the hours of use in a day and the periods of the year, as well as
differentiated rates of power demand according to the hours of use in a day; and
b) Green Tariff: modality structured for the application of differentiated rates of energy consumption
according to the hours of use in a day and the periods of the year, as well as a single rate for power
demand.

6.2.41. Audit Trail

Chronological record of the system activities that allow the reconstruction and examination of the
sequence of events and/or changes in a given event.

6.2.42. Integrity Check

Process that verifies that the data/software/parameters were not changed during use, repair,
maintenance, transfer or storage without Inmetro’s authorization.

7. SOFWARE’S DESCRIPTIVE MEMORIAL

This guidance document presents the general guidelines on how to meet the RTM software
requirements attached to the Administrative Rule nº 586, dated November 1 st, 2012. However, it is still a
generalist approach, not paying attention to the peculiarities of each instrument. The applicant, in
submitting the software documentation, should be thorough and attentive to clearly establish a link
between the requirements of the metrological technical regulation attached to the ordinance and the
architecture of his instrument.

Note – The documentation to be delivered is detailed in NIT-Sinst-003. This guidance document only
covers one of the documentation items, the software’s descriptive memo.

7.1. Pre-Textual and Textual Elements

Documentation related to software and hardware security requirements, henceforth a software’s
descriptive memorial, should have a cover sheet, document review control table, table of contents, list
of figures and list of tables. Must clearly identify the model in software evaluation. The document should
have numbered pages and sessions. The document must be written in Portuguese. It is recommended
that the document be sent in unprotected pdf format.

If the measuring instrument has more than one embedded firmware, henceforth a module, the
software’s descriptive memorial must describe in detail the service for the requirements of each module
that makes up the measurement system. If the documentation is very extensive and the measurement
system has many modules, the software memorial can be divided into multiple documents, one for each
module.

Note – The appropriate safeguards for the information contained in the documentation are described in
the NIT-Sinst-003 document.

7.2. Software and Hardware General Security Requirements

The general requirements comprise the cybersecurity requirements applicable to all architectures of
electric energy meters regulated by Administrative Rule nº 586 of November 1 st, 2012.
7.2.1. Basic Features of the Measuring System/Instrument
Item 7.2.1 clarifies requirement 3.1.1.2 of Administrative Rule nº586 of November 1 st, 2012.

It should be described in detail: the features that support the execution of the software (memory,
processor/microcontroller); the static (software architecture) and dynamic aspects (execution flows) of
the software; specific block features that contribute for the measuring system’s functioning as a whole
(specific features of the display and the meter, for example); physical protection mechanisms (sealed
box or not, for example).

The documents that describe the instrument are specified in item 8 of NIT-Sinst-003. If it is the
applicant’s interest, the documents described in items 8.2 and 8.3 of NIT-Sinst-003 may be linked to the
software’s memorial. In addition to the documents of item 8 in NIT-Sinst-003, the software’s descriptive
memo should contain the following information.

7.2.1.1. Legally Relevant Chain Identification

Identify and describe the legally relevant chain, that is, all software, hardware and data elements
involved in the generation of information relevant to the measurement, capture of data, processing and
dissemination of the result. Present the legally relevant chain using block diagrams. Comments:

(i) Automation routines that control the measurement dynamics are part of the legally relevant chain.
(ii) Software components that prepare legally relevant data for storage or transmission, or that
perform data verification after reading or receiving, are legally relevant software.
(iii) Automation routines that control the measurement dynamics are part of the legally relevant chain.

7.2.1.2. Sealing Plan

Describe the sealing plan and its relevance to the safety of the equipment. The sealing plans shall be
documented using the technical drawing as described in item 7.6 of NIT-Sinst-003.

7.2.1.3. Processor/Microcontroller Detailing

 Describe the main characteristics of the processor/microcontroller used.
 Refer to the descriptive manual (datasheet).
 Detail the development/programming environment of the processor/microcontroller. For example,
describe the programming language used, available resources, etc.

7.2.1.4. Memory
Describe: Type, Quantity, Map, etc. Figure 1 shows an example of a memory map.

Figure 1 – Processor’s Memory Map

 Describe the address space of the firmware, displaying the filled-in random values at the end of the
retaining area, if any.
 Describe how these random values were generated.
 Show the secondary storage memories of the module.

The applicant should provide a figure on the memory organization. All block memories, even the
auxiliary ones (temporarily used in the software loading process, for example), are subject to integrity
checking. NIT-Sinst-020 Annex A discusses two integrity check procedures.

The applicant should pay special attention to completing the various reports and must justify those
which have not been fully or partially fulfilled. To avoid an attack using unoccupied memory space, it
must be filled with random numbers known by Inmetro. Thus, the memory of the microcontroller will
have an organization similar to that of figure 2. This filling with random data makes it difficult for an
attack to chance the measurement routines, because to make that in a way that it is not perceived in a
future audit would require additional memory. Because the unused memory space has non-negligible
data (they are part of the memory content to be audited), they cannot be simply overwritten, thus
making it difficult for software change attacks.

Figure 2 – Microcontroller’s Memory Organization

An attacker may, however, use some sort of compression on the existing data in the unused memory
area and perform decompression in real time at the time the integrity check is invoked. Thus, the
attacker will obtain the additional memory space, necessary for his attack to occur successfully. Thus, in
order to minimize the risk of a compression attack, the unused memory area must be filled with random
high-scatter data. One suggestion for random number source generated with great dispersion are those
provided by random.org. If a pseudorandom number generator is chosen to fill the unoccupied memory,
the generator must meet the requirements of standard SP 800-22.

7.2.2. Unequivocal Identification of Software

Item 7.2.2 clarifies requirement 3.1.2.3 of Administrative Rule nº586 of November 1 st, 2012.
Description of the software identifier – Should present how the software identifier is constructed, how it
is structured and how it can be viewed. It should also describe how the identifier is indissolubly
associated with the software. The software identifier is considered a legally relevant parameter and
must be protected as such.

In the case of a U-type computer, the documentation specifies an identifier for the operating system and
for each system component that has been modified or added, such as drivers. This identifier could be,
for example, the version of the Linux distribution or the Windows 7 Service Pack number.

The documentation should indicate in the source code the location of the routines responsible for the
creation and access to the software identifier (eg, file, class, method, routine, etc.).

7.2.3. Integrity Check

Item 7.2.3 clarifies requirement 3.1.3.4 of Administrative Rule nº586 of November 1 st, 2012.

If the instrument uses the communication protocol described in NIT-Sinst-020 and makes use of the
challenge and response integrity check tool described in Annex A of NIT-Sinst-020, it will not be
necessary for the applicant to implement an integrity check. In this case it should be informed:

 The technical specification of the serial data communication interface used;

 A list of all general and specific commands that can be activated via the metrological verification
interface as defined in NIT-Sinst-020;
 The detailed description of the extended commands that can be activated through the metrological
verification interface, presenting the corresponding actions that can be triggered in the instrument;
 A description of the error codes used by the applicant to inform the occurrence of error situations
not provided for in the NIT-Sinst-020 Standard, following a request for information from the DVIS;
 List of codes used to identify legally relevant parameters in the audit trail as defined in NIT-Sinst-
020;
 Description of the MAC algorithm used during the software integrity check process (Random
Memory Interval Method), as defined in the NIT-Sinst-020 Annex A.

Otherwise, the documentation shall describe the method of verifying the integrity of the legally relevant
software on the instrument and the procedure for performing it. As stated in item 8.5.1 of NIT-Sinst-003,
the integrity check tool should be included in the documentation package as well as its installation
manual, operation and description of the communication protocol used. The description of
implemented integrity checking algorithms and mechanisms should be provided.

The documentation should indicate in the source code the location of the routines responsible for the
integrity checking (eg, file, class, method, routine, etc.).

7.2.4. Measurement Algorithms Accuracy Description

Item 7.2.4 clarifies the requirement 3.1.4.2 of the Administrative Rule nº586 of November 1 st, 2012.

It should describe the algorithm through flowchart, highlighting inputs and outputs.

Explain the current sensor type, measurement shape (two or four quadrants) and record form
(unidirectional recorder, bi-directional recorder or ratchet recorder). Clearly relate the form of
measurement and registration in the implementation, pointing out the functionalities and
computational resources used, for example, if there is a measurement unit for energy in the
microcontroller and how it works. Note the numerical errors associated with the implementation of the
measurement algorithm used.
The documentation should indicate in the source code the location of the measurement algorithm (eg,
file, class, method, routine, etc.).

7.2.5. Data Input Interface Influence

Item 7.2.5 clarifies the requirement 3.1.5.2 of the Administrative Rule nº586 of November 1 st, 2012.

The documentation should contain a list of all the commands, explaining the functionality of each of
them and an explicit statement that all the commands are contemplated in the presented list.

Note: For the declaration of completeness, it suffices a clear sentence in the documentation that all the
commands implemented in the software are described in the documentation.

The behavior of the instrument when receiving each command should be described, preferably using
state diagram and activity diagram associating the corresponding routines in the source code.

Display test case report for each of the commands. This report shall contain the procedures used to test
each command as well as the description of the tests performed.

The documentation should describe the access controls when it is possible to change metrologically
relevant parameters with the use of communication interfaces. Preferably, the cryptographic algorithms
for access control must obey the SP 800-57, part 1 standard.

The documentation should indicate in the source code the location of the routines responsible for
treating the data interfaces.

7.2.6. Protection Against Accidental/Unintentional Changes

Item 7.2.6 clarifies requirement 3.1.6.2 of Administrative Rule nº586 of November 1 st, 2012. Legally
relevant software, parameters and measurement data must be protected against accidental or
unintended modifications. The documentation should describe how this goal is achieved. For Example:
data replication with voting scheme or data CRC.

The documentation should show how the instrument verifies the integrity of its program memory
against accidental changes, measurement data against accidental changes and legally relevant
parameters against accidental changes.

When accidental changes occur, the documentation should state the error codes generated and the
handling of those errors.

The documentation should indicate the source code routines responsible for dealing with protections
against accidental changes.

7.2.7. Protection Against Unauthorized Intentional Changes

Item 7.2.7 clarifies requirement 3.1.7.1 of Administrative Rule nº586 of November 1 st, 2012. The
software and hardware of the instrument shall be designed and constructed in such a way that the
possibility of its improper or fraudulent use, whether intentional, unintentional or accidental, are
minimal.

Protection measures against improper or fraudulent use of the instrument, including mechanical,
electronic and/or cryptographic protection devices shall be described. The cryptographic algorithms
used must be in accordance with SP 800-57 Part 1.

Legally relevant software and parameters must be protected against inadmissible or unauthorized
modifications. The documentation should describe the protection against physical modifications to the
instrument, such as those caused by improper exchange of memory units. If the instrument accepts
software load, only loads of software signed by Inmetro must be authorized.

The documentation should indicate the source code’s routines responsible for dealing with the
protection against intentional changes.

7.2.8. Parameter Protection

Item 7.2.8 clarifies the requirement 3.1.8.3 of Administrative Rule nº586 of November 1 st, 2012.

The documentation should describe each of the legally relevant parameters.

It should be presented in the documentation a table informing, for each parameter, the function in the
source code that allows its change, nominal value, variation range and storage location, like Table 1.

Table 1 – Legally Relevant Parameters

Parameter Function Nominal Value Variation Range Storage Location

Source: Sinst

Describe the protection methods used so that they are protected against unauthorized modification.

Describe the procedures for changing parameters. For seasonal fare meters and white tariffs, if an
authentication scheme is used, the authentication requirements must comply with the provisions of
item 8.8 of NIT-Sinst-019, which deals with the need for validity in the model approval regulations for
the meters if the authentication scheme adopted is not strong enough.

Description of the Registration Procedure for Alteration of Relevant Metrological Parameters. Describe
the format of all parameter change records by indicating the meaning of each field of the records. If
more appropriate, point to it at the time the test case is described. Records should not contain sensitive
information, such as the cryptographic key used by the devices. The record, depending on the event
generated, should indicate who made the access, when that event occurred and what the event caused
in the system’s behavior. Describe the mechanism for retrieving records. Identify the storage capacity of
each record and timing.

Describe the parameter change registration procedure of the stored data’s format.

Describe how the parameters are referenced in the audit log and how they can be viewed.

Provide assurances that the components that store legally relevant audit records, data and parameters
are physically and logically tamper-evident.

The records in the Registry of Changes of Relevant Metrological Parameters shall contain at least the
parameter identification, the value before and after the change and the timestamp.

7.2.9. Fault Detection

Item 7.2.9 clarifies the requirement 3.1.9.2 of Administrative Rule nº586 of November 1 st, 2012.

Document the list of faults that are detectable, their detection algorithms and reactions triggered. The
instrument shall not perform measurement while in the fault state.
Indicate in the source code the location of the routines responsible for detecting and handling the faults.
Explain in the documentation how these routines are triggered (interrupts, watchdogs, etc.).
7.2.10. Software Validation
Item 7.2.10 clarifies the requirement 3.1.10.1 of Administrative Rule nº586 of November 1 st, 2012.

Describe the test cases used to validate the measuring instrument’s software. Assemble a table,
according to table 2, for each test case.

Table2 – Test Case Record Example

Item Description
Title Test case’s title.
Author Name of the one responsible for executing the test.
Summary Contains a description of the test case, describing the test’s
purpose or objective as well as its scope.
Pre-Conditions For each execution condition, it describes the mandatory state of
the system before the start of the test.
Inputs For each execution condition, it lists a set of the specific stimuli to
be applied during the test. In general, they are called test entries
and include the objects or interaction fields and the specific data
values entered during the execution of this test case.
Procedure For the test’s execution, these are the actions that the user must
perform so that the system can comply with what will be tested.
Expected It is the resulting state or observable conditions expected as a result
Results of the test run. Note that this may include both positive and
negative responses (such as error conditions and failures).
Results Found It is the actual result of the test run. Note that this includes both
positive and negative outcomes.
Evidence of the Set of information that evidences the result described in the
Results Found previous item, such as: screen printscreen of the system containing
the result, photographic record or video recording, system log file,
block of data trafficked in response, etc.
Post-Conditions For each execution condition, it describes the state to which the
system should return to allow subsequent tests to run. Report only
in exceptional cases.
Source: Sinst

7.3. Specific Software and Hardware Security Requirements

The specific requirements deal with technical aspects concerning complementary functionalities.

7.3.1. Specific Requirements Description

The items below are considered as specific requirements by the RTM attached to the Administrative
Rule nº586 of November 1st, 2012:

 Separation of legally relevant parties. These requirements must be met when the instrument has
legally irrelevant software and legally relevant software. This approach allows the applicant to
maintain legally non-relevant software in the instrument and can be changed without going through
a model modification;
 Transmission of data through the communication network. When the instrument uses
communication network within the legally relevant chain;
 Loading legally relevant software. When it is possible to change the legally relevant software
shipped in the instrument without breaking the main sealing;
 Architectures based on digital signature. When the system uses digital signature to ensure
authenticity and irrefutability.

7.3.2. Software Separation

Item 7.3.2 clarifies the requirement 3.2.2.9 of Administrative Rule nº586 of November 1 st, 2012.

Software-controlled measuring instruments can have complex functionalities and contain modules that
are legally relevant and modules that are not. Software separation is a methodology that allows the
applicant to easily modify software that is not legally relevant.

The documentation should describe the design of the software and/or hardware separation in detail.
The use of block diagram corroborates in the understanding of software separation. Description and
identification of software modules (programs, subroutines, libraries) and hardware (electronic boards,
components, transducers) that perform legally relevant functions or contain legally relevant data.

All the program units (subroutines, procedures, functions, classes) and, in the case of high-level
separation, all the programs and libraries that contribute to 1) the calculation of value’s measurements
or that have an impact on it and for 2) auxiliary functions such as data display, data security, data
storage, software identification, software loading, transmission or storage of data, checking or storage of
received data.

Legally relevant software belongs to all variables, temporary files and parameters that have an impact
on legally relevant measurement values or functions, or data. If legally relevant software runs on an
operating system, that operating system is also legally relevant. Other program units and data or
parameters not mentioned above make up the legally non-relevant software. Modifications to the
legally non-relevant part are permitted provided that the software separation requirements are
observed.

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.

Description of the separation interface, or protective software interface, between legally relevant and
non-legally relevant parties (including descriptions of functions, data domains, communication protocols
and data bus). Any interactions and data flows should not inadvertently influence legally relevant
software.

The documentation shall present the communication protocol in detail and a complete list containing
the description and functionality of the software and/or hardware separation interface commands. As a
complement to the specified list of commands, a declaration of completeness of the commands used
through the instrument interfaces should be presented.

Note – the declaration of completeness corresponds to a statement by the applicant stating that only
the commands described in the documentation have influence on the measuring instrument or system
being analyzed.

If the legally relevant software and the legally non-relevant software use the same computational
resources, the documentation shall describe how the necessary availability for the correct execution of
legally relevant software is guaranteed: interrupt hierarchy, time schedule of software tasks, time limit
for legally non-relevant tasks.

For each command listed, indicate the respective part of the software’s source code that handles the
command.
7.3.3. Transmission of Data Over a Communication Network
Item 7.3.3 clarifies requirement 3.2.3.1 of Administrative Rule nº586 of November 1 st, 2012.

The documentation should describe the mechanisms that guarantee the authenticity of the information
trafficked between the modules. Constructive solutions, such as sealing and logic, like the use of
encryption tools such as HMAC, can be used to ensure authenticity.

The documentation should describe the mechanisms that guarantee the integrity of the information
trafficked between the modules. For example, with the use of error detection tools (CRC, checksums,
cryptographic hash functions, etc.) that in turn change the state of the instrument to handle the
detected error. Other approaches, such as the use of error correction algorithms, are also possible.

Document the network topology, the technology used for the connections, the network interfaces and
their respective controllers, the operation of rubs, bridges, switches, communication protocol, etc.

The documentation should describe the communication protocol in detail. If a known protocol is used,
such as TCP/IP, the documentation should describe how the instrument makes use of the protocol to
transmit the data.

The mechanisms used to discard or reconstruct corrupted data must be described in the documentation,
as well as the measurement is protected against delays arising from communication and protection
against interruption of transmission.

The respective security measures must be detailed to prevent intrusion into the internal network.
Constructive solutions such as sealing, and logical use such as strong authentication tools can be used to
protect the communication network.

The documentation should describe the mechanisms for the confidentiality of cryptographic keys if they
are used for data transmission.

7.3.4. Remote Software Load

Item 7.3.4 clarifies requirement 3.2.3.3 of Administrative Rule nº586 of November 1 st, 2012.

The documentation should describe the loading procedure of legally relevant software.

The documentation shall describe the means by which it is ensured that the legally relevant software
has been evaluated and approved by Inmetro. The process for authenticity of the remotely loaded
software passes through the use of a public key provided by Inmetro as specified in item 10 of NIT-Sinst-
003, and by a digital signature of the software-approved software binary. The memorial should describe
which component of the measuring instrument verifies the digital signature of new software (signed
with Inmetro’s private key) from an auxiliary memory and, attested to authenticity, replaces the old
software with the new one and loads the latter during the boot process.

Describe load protection measures and unauthorized modifications of legally relevant software and
behavior in the event of a software load failure and how the instrument signals the error.

Describe hardware support. (Example: there is an additional buffer for temporary storage of
downloaded software).

Description of the software load registration procedure and data format. Describe the format of all
software load records pointing to the meaning of each field of the records. If more appropriate, point to
it at the time the test case is described. Records should not contain sensitive information, such as the
cryptographic key used by the devices. The record, depending on the generated event, should indicate
who made the access, when that event occurred and what the event caused in the behavior of the
system. Describe the mechanism for retrieving records. Identify the storage capacity of each record and
timing.

Description of the procedure for making available and publishing legally relevant software load records
and description of the physical and logical tampering of components that store legally relevant software
load records.

For seasonal fare meters and white tariffs, if an authentication scheme is used, the authentication
requirements must comply with the provisions of item 9.3 of NIT-Sinst-019, which deals with the need
for validity in the model approval regulations for the meters if the authentication scheme adopted is not
strong enough.

Indicate in the source code the location of the routines responsible for loading the software.

7.3.5. Digital Signature Based Architectures

Item 7.3.5 clarifies requirement 3.2.5 of Administrative Rule nº586 of November 1 st, 2012.

Meters whose input quantities are digitally signed only require the delivery of the source code that
includes all states and system activities from the initialization to where the digital signature occurs. All
communication interface source codes that cause a change in the instrument’s state before the digital
signature must also be delivered.

The documentation must be explicit about the commands that cause change in the state of the
instrument before the digital signature. For example, a command that changes the input quantities, that
allow to change the order of the measurement or to act in the process of digital signature of these
quantities. These commands cannot allow undue behavior of the measurement system. For example, a
combination of the use of these commands should not allow the introduction of a systematic error into
one of the input quantities.

The applicant shall provide a tool so that it is possible to reconstruct the measurement from the input
quantities. The tool should also allow to evaluate the accuracy of the measurement algorithm. The
accuracy of the measurement algorithm must be stated in the documentation.

If the instrument loads software, it is necessary to present the source code associated with the routines
that allow loading and all legally relevant software must be signed by Inmetro.

All digitally signed input quantities shall be treated as part of the legally and metrologically complete
measurement result. There must be a way to verify the digital signature of the measurement.

The management of these keys should be detailed to ensure their safety. The security specification of
the components that store cryptographic keys must be provided.

7.4. Dynamic Behavior

Item 7.4 clarifies requirement 3.3 of Administrative Rule nº586 of November 1 st, 2012.

Describe in detail the main task of each module’s software using an activity diagram. The main task is
that performed when the system is initialized by the main function. A task is characterized by a single
flow of sequential control within the running software (process). Figure 2 shows a simplified activity
diagram for the main task.
Describe the modules/libraries/functions that are used by the main task, describe the initial state and
the stopping conditions (if any) and present a time diagram.

Figure 2 – Module’s Main Task

The documentation should present test cases for the dynamic behavior of the instrument confirming the
correct operation of the time diagram and the respective changes when the error situations are
provoked.

7.5. Processing Capacity

Item 7.5 clarifies requirement 3.4 of Administrative Rule nº586 of November 1 st, 2012.

Documentation should provide calculations that demonstrate the ability to share hardware resources
that have shared use, such as hubs, communication networks, switches, and so on.

The documentation should present test cases of instrument performance, such as stress level, load test,
containment test and performance profile test.

8. Review History and Approval Flow

Review Date Reviewed Items
00 Nov/2018 -Initial publication;

Approval Flow
Name Role
Carlos Eduardo Cardoso Galhardo Sinst’s Quality Coordinator
Prepared
by:
Fabiano O Leitão Technologist Researcher in Metrology and Quality
Verified Juliana Wilm Sinst’s Intern
by:
 Amsterdam de J.S.M. de Mendonça Dimel’s Quality Coordinator
Approved
Bruno Erthal Sinst’s Supervisor
by: