European Cooperation in

Legal Metrology (WELMEC) e. V.

Bundesallee 100
38116 Braunschweig
Germany

WELMEC Guide 7.2

Software Guide

(EU Measuring Instruments Directive 2014/32/EU)

Version 2023

For information:
This Guide is made available for the Working Group Measuring Instruments (Euro-
pean Commission expert group E01349) for consideration for future referencing
on the Europa Website.

WELMEC e.V., Bundesallee 100, 38116 Braunschweig, Germany.

Phone: +49 531 592 1980 E-mail: [email protected]
WELMEC Guide 7.2: 2023 Software Guide

WELMEC e.V. is a cooperation between the legal metrology

authorities of the Member States of the European Union and
EFTA. This document is one of a number of Guides
published by WELMEC e.V. to provide guidance to
manufacturers of measuring instruments and to notified
bodies responsible for conformity assessment of their
products. The Guides are purely advisory and do not
themselves impose any restrictions or additional technical
requirements beyond those contained in relevant EU
Directives. Alternative approaches may be acceptable, but
the guidance provided in this document represents the
considered view of WELMEC e.V. as to the best practice to
be followed.

Published by:
WELMEC Secretariat

E-mail: [email protected]
Website: https://www.welmec.org/

WELMEC e.V., Bundesallee 100, 38116 Braunschweig, Germany.

Phone: +49 531 592 1980 E-mail: [email protected]
WELMEC Guide 7.2: 2023 Software Guide

Software Guide
(Measuring Instruments Directive 2014/32/EU)

Contents

Foreword ...................................................................................................................... 5
Introduction ................................................................................................................... 6
Terminology ........................................................................................................... 7
How to use this guide ...........................................................................................15
Overall structure of the guide ..................................................................................15
How to select the appropriate parts of the guide......................................................17
How to work with a requirement block .....................................................................18
How to work with the checklists ...............................................................................19
Definition of risk classes .......................................................................................20
General principle .....................................................................................................20
Description of levels of counteractions for the risk factors .......................................20
Derivation of risk classes .........................................................................................21
Interpretation of risk classes ....................................................................................21
Basic requirements for embedded software in a measuring instrument using a
built-for-purpose device (type P) ..................................................................................23
Technical description...............................................................................................23
Specific requirements for type P ..............................................................................24
Basic requirements for software of measuring instruments using a universal
device (type U) ............................................................................................................34
Technical description...............................................................................................34
Specific software requirements for type U ...............................................................35
Extension O: general-purpose operating systems ................................................44
Technical description...............................................................................................44
Applicability of requirements for components ..........................................................44
Specific requirements for configuration of general-purpose operating systems .......46
Extension L: storage of measurement data ..........................................................54
Technical description...............................................................................................54
Specific software requirements for storage ..............................................................55
Extension T: transmission of measurement data via communication networks ....66
Technical description...............................................................................................66
Specific software requirements for transmission of measurement data ...................67
Extension S: software separation .........................................................................75
Technical description...............................................................................................75

3
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements for software separation ...........................................76

Extension D: download of legally relevant software ..........................................79
Technical description...............................................................................................79
Specific Software Requirements .............................................................................80
Extension I: instrument-specific software requirements ....................................84
Structure .................................................................................................................84
Water Meters...........................................................................................................87
Gas Meters and Volume Conversion Devices .........................................................95
Active Electrical Energy Meters .............................................................................104
Thermal Energy Meters .........................................................................................111
Measuring Systems for the Continuous and Dynamic Measurement of Quantities of
Liquids Other than Water ..................................................................................................120
Weighing Instruments............................................................................................128
Taximeters ............................................................................................................134
Material Measures .................................................................................................138
Dimensional Measuring Instruments..................................................................139
Exhaust Gas Analysers .....................................................................................140
Pattern for test report (including checklists) ....................................................141
Information to be included in the certificate ...........................................................141
Pattern for the general part of the test report .........................................................143
Annex 1 of the test report: Checklists to support the selection of the appropriate
requirement Sets ..............................................................................................................147
Annex 2 of the test report: Specific checklists for the respective technical parts ....148
Cross reference for MID software requirements to MID articles and annexes 151
Given software requirement, reference to MID ......................................................152
Interpretation of MID Articles and Annexes by MID-Software Requirements .........155
Remarks on measurement terminology ..........................................................158
Legally relevant properties ..............................................................................160
References and literature ................................................................................161
Revision history...............................................................................................161

4
WELMEC Guide 7.2: 2023 Software Guide

Foreword
The guide in hand is based on the “Software Requirements and Validation Guide”, Ver-
sion 1.00, 29 October 2004, developed and delivered by the European Growth Network
“MID-Software” [1]. The Network was supported from January 2002 to December 2004
by the EU commission under the contract number G7RT-CT-2001-05064.
This guide is purely advisory and does not itself impose any restrictions or additional
technical requirements beyond those contained in the Measuring Instruments Directive
(MID) [2]. Alternative approaches may be acceptable, but the guidance provided in this
document represents the considered view of WELMEC as to a good practice to be fol-
lowed.
Although this guide is oriented on instruments included in the regulations of the MID, the
results are of a general nature and may be applied beyond.
Please note: This issue of the guide remains also valid for Directive 2004/22/EC [3].

5
WELMEC Guide 7.2: 2023 Software Guide

Introduction

This document provides technical guidance for the application of the Measuring
Instruments Directive (MID) [2], for software-equipped measuring instruments. It
addresses all those who are interested in the technical understanding of software-
related requirements of the MID, in particular of the essential requirements in annex 1
of the MID. The level of detailedness is oriented on the needs of manufacturers of
measuring instruments and of notified bodies (NB) which perform conformity
assessments of measuring instruments according to module B.
By following this guide, a compliance with the software-related requirements of the MID
can be assumed. It can be further assumed that all notified bodies accept this guide as
a compliant interpretation of the MID with respect to software. To show how the
requirements set up in this guide are related to the respective requirements in the MID,
a cross reference has been included in this guide as an annex (Chapter 13).
Latest information relating the work of WELMEC Working Group 7 is available on the
web site.

6
WELMEC Guide 7.2: 2023 Software Guide

Terminology

The terminology explained in this chapter describes the vocabulary as used in this guide.
References to a standard or to any other source are given, if the definition is completely
or in essential parts taken from it.
Acceptable solution: A design or a principle of a software module or hardware
component, or of a feature that is considered to comply with a particular requirement.
Note: An acceptable solution provides an example of how a particular requirement may
be met. It does not prejudice any other solution that also meets the requirement.
Audit trail: Continuous data containing a time stamped information record of events,
e.g., changes in the values of the parameters of a measuring instrument or software
updates, or other activities that are legally relevant and which are critical for the
metrological characteristics.
Note: Regarding examples for events logged in an audit trail, see Event.
Authentication: The process of checking of the declared or alleged identity of a user,
process, software or measuring instrument.
Note: This may be necessary when checking that downloaded software originates from
the owner of the TEC.
Authenticity: The result of authentication (passed or failed).
Basic configuration: The design of the measuring instrument with respect to the basic
architecture. There are two different basic configurations: measuring instrument using a
built-for-purpose device and measuring instruments using a universal device. The terms
are accordingly applicable to sub-assemblies.
Built-for-purpose device (type P): A device constructed for the specific purpose of a
metrological task.
Note 1: Built-for-purpose devices include devices that may not incorporate an operat-
ing system.
Note 2: If an operating system is present, it is not directly accessible.
Category 1 component: The components that are part of the measuring process, i.e.,
that handle measurement data to construct and indicate the final measured quantity
value together with the measurement result relevant data.
Category 2 component: The components that further process the measurement result
without modifying the final measured quantity value and related measurement result
relevant data.
Certification of keys: The process of binding a public key value to an individual,
organisation or other entity.
Checking facility: A facility that is incorporated in a measuring instrument or
component and which enables significant defects to be detected and acted upon.
Note: “acted upon” refers to any adequate response by the measuring instrument
(luminous signal, acoustic signal, prevention of the measurement process, etc.).
Closed network: A network of a fixed number of participants with a known identity,
functionality, and location (see also open network).

7
WELMEC Guide 7.2: 2023 Software Guide

Communication interface: A part of an instrument that enables information to be

passed between measuring instruments, components of measuring instruments or other
external systems.
Note 1: Communication interfaces can be wired, optical, radio, etc. and they are usu-
ally designed to use a specific protocol.
Note 2: This definition does not include communication between software modules
within the measuring instrument or the same component.
Component: An identifiable hardware part of a measuring instrument or sub-assembly
that performs a specific function or functions, and that can be separately evaluated
according to specific metrological and technical performance requirements.
Note: see WELMEC Guide 8.8.
Confidentiality: The property that information is not made available or disclosed to
unauthorized individuals, entities, or processes.
Cryptographic certificate: A dataset containing the public key belonging to a
measuring instrument, or a component or a person plus a unique identification of the
subject, e.g., serial number of the measuring instrument or name or Personal
Identification Number (PIN) of the person, plus a date of expiry.
Cryptographic means: A means such as encryption and decryption with the purpose
of hiding information from unauthorised persons, or hashes and electronic signatures to
ensure integrity and authenticity.
Data domain: A location in memory that each program needs for processing data.
Note: Data domains may belong to one software module only, or to several.
Device-specific parameter: A legally relevant parameter with a value that depends on
the individual instrument, component and/or software module(s) subject to legal control.
Note: Device-specific parameters comprise adjustment parameters (e.g. span adjust-
ment or other adjustments or corrections) and configuration parameters (e.g. maxi-
mum value, minimum value, units of measurement, etc.).
Electronic measuring instrument: A measuring instrument intended to measure an
electrical or non-electrical quantity using electronic means and/or equipped with
electronic parts.
Note: For the purpose of this guide, auxiliary equipment, provided that it is subject to
metrological control, is considered to be part of the measuring instrument.
Electronic signature: A software means which is added to software or data with the
purpose to verify the origin of software or data, i.e., to prove their authenticity, or to
check that the software or data are unchanged, i.e., to prove their integrity.
Note 1: For electronic signing, a public key system is used in general, i.e., a pair of
keys where only one needs to be kept private/secret; the other may be public.
Note 2: The private key is used when software or data are signed. The public key is
used when software or data are verified before use.
Note 3: The verifying instance may require a cryptographic certificate of the signing
instance to be sure of the authenticity of the public key.
Event: An action that might influence the metrological data and/or characteristics of the
measuring instrument.

8
WELMEC Guide 7.2: 2023 Software Guide

Note: examples of such events are changing a legally relevant parameter or a

modification or update of the legally relevant software.
Executable code: The digital information installed in the measuring instrument or
component (EPROM, hard disk, etc.).
Note: This code is interpreted by the central processing unit (CPU) of the measuring
instrument and converted into certain logical, arithmetical, decoding or data transporting
operations.
Hash function: A (mathematical) function which maps values from a large (possibly
very large) domain into a smaller range.
Note: A “good” hash function is such that the results of applying the function to a (large)
set of values in the domain will be evenly distributed (and apparently at random) over
the range.
Integrated storage: A non-removable storage that is part of the measuring instrument
or component, e.g. RAM, EEPROM, hard disk.
Integrity: The property that software, measurement data and parameters have not
changed.
Interface: A shared boundary between two functional units, defined by various
characteristics pertaining to the functions, physical interconnections, signal exchanges,
and other characteristics of the units, as appropriate.
Interruptible cumulative measurement: A process of cumulative measurement of the
quantity value of a measurand that can be easily and rapidly stopped during normal
operation.
Note 1: Examples include: a) discontinuous totalizing automatic weighing instrument,
b) fuel dispenser.
Note 2: See also non-interruptible measurement.
IT configuration: The design of the measuring instrument with respect to IT functions
and features. There are four IT configurations considered in this guide: storage of
measurement data, transmission of measurement data, software download and
software separation (see also basic configuration). The terms are accordingly applicable
to sub-assemblies.
Key: An appropriate number or sequence of characters used to encode and / or decode
information.
Legally relevant: The property of being required to fulfil the essential requirements
and/or having an impact on the compliance with the essential requirements of Annex I
and the instrument-specific requirements of the MID and/or the essential requirements
of Annex I and III of the NAWID.
Note 1: A measuring instrument put under legal control has to comply with the essential
requirements, see article 6 of the MID and article 4 of the NAWID, therefore, according
to the definition, that measuring instrument is legally relevant.
Note 2: Where instrument-specific annexes of the MID lay down essential requirements
for sub-assemblies, then said sub-assemblies, that are part of the legally relevant
measuring instrument, are legally relevant as well.
Note 3: See also chapter 15 for additional explanations.
Maximum permissible error (of a measuring instrument): The extreme value of a
measurement error, with respect to a known reference quantity value, permitted by
9
WELMEC Guide 7.2: 2023 Software Guide

specifications or regulations for a given measurement, measuring instrument, or meas-

uring system.
Measured quantity value: The quantity value representing a measurement result.
Measured quantity value metadata: The metadata related to the measured quantity
value.
Measurement: The process of experimentally obtaining one or more quantity values
that can reasonably be attributed to a quantity.
Note 1: Measurement does not apply to nominal properties.
Note 2: Measurement implies comparison of quantities or counting of entities.
Note 3: Measurement presupposes a description of the quantity commensurate with the
intended use of a measurement result, a measurement procedure, and a calibrated
measuring system operating according to the specified measurement procedure, includ-
ing the measurement conditions.
Note 4: Chapter 14 illustrates the terms and definitions related to the measurement pro-
cess and their usage in this document.
Measurement data: The data used during the measurement process.
Note: Measurement data includes the measured quantity value, measurement result
relevant data and measurement process data, see chapter 14.
Note: The measured quantity value and measurement result relevant data, are both part
of the measurement result and together with the measurement process data these form
the measurement data, see chapter 14.
Measurement metadata: The metadata related to the measurement process.
Note: Measurement metadata includes the measured quantity value metadata,
measurement result relevant metadata and measurement process metadata.
Measurement error: The measured quantity value minus a reference quantity value.
Note 1: The concept of ‘measurement error’ can be used both a) when there is a sin-
gle reference quantity value to refer to, which occurs if a calibration is made by means
of a measurement standard with a measured quantity value having a negligible meas-
urement uncertainty or if a conventional quantity value is given, in which case the
measurement error is known, and b) if a measurand is supposed to be represented by
a unique true quantity value or a set of true quantity values of negligible range, in
which case the measurement error is not known.
Note 2: Measurement implies comparison of quantities or counting of entities.
Measurement process data: The data used during the measurement process to
construct the measurement result.
Note: Examples of measurement process data include values of measurement
parameters, values of connection settings or values of session parameters.
Measurement process information: The set of values of qualitative or quantitative
variables representing the measurement process.
Note: Measurement process information includes measurement process data and
measurement process metadata.
Measurement process metadata: The metadata related to the measurement process.

10
WELMEC Guide 7.2: 2023 Software Guide

Note: Examples of measurement process metadata include format of the measurement

parameters, format of the connection settings or format of the session parameters.
Measurement result: The set of quantity values being attributed to a measurand
together with any other available measurement result relevant data.
Note: Examples of measurement result relevant data are the marks and inscriptions
necessary to inform the user of the significance of the measurement result, see article
10.2 of Annex I of the MID.
Note: Examples of measurement result relevant data include the information concerning
the origin of measurement data needed to identify the particular transaction, e.g.,
identification of the sensor, see article 11.1 of Annex I of the MID.
Note: Measurement result relevant data is also information to identify the particular
transaction, e.g., number of the measurement, date and time of the measurement, see
article 11.1 of Annex I of the MID.
Note: In the case where price calculation is part of the legally relevant software, unit
price and price to pay are part of the measurement result relevant data, see the
appropriate instrument-specific Annexes of the MID and Annex I of the NAWID.
Note: The measurement result (including the measured quantity value) is used for the
legally relevant purpose, e.g., conclusion of a transaction.
Measurement result relevant data: The data used during the process of constructing
the measurement result.
Note: Examples of measurement result relevant data include digital number or analogue
value originating from a sensor or measuring instrument ID, in cases where it is part of
the measurement result, see chapter 14.
Measurement result relevant information: The set of values of qualitative or
quantitative variables relevant to the measurement result.
Note: Measurement result relevant information includes measurement result relevant
data and measurement result relevant metadata.
Measurement result relevant metadata: The metadata related to the construction of
the measurement result.
Note: Examples of measurement result relevant metadata include format of the digital
number or analogue value originating from a sensor, format of the measured quantity
value or format of the measuring instrument ID, in cases where it is part of the
measurement result.
Measuring instrument: A device used for making measurements, alone or in
conjunction with one or more supplementary devices.
Metadata: The data about data or data elements, possibly including their data
descriptions, and data about data ownership, access paths, access rights and data
volatility.
Measuring instrument using a universal device (type U): A Measuring instrument
that comprises a general-purpose computer, usually a PC-based system, for performing
legally relevant functions. A type U system is assumed if the conditions of a measuring
instrument using a built-for-purpose device (type P) are not fulfilled.
Module: A software entity such as a program, subroutine, library, parameter or data set,
and other objects including their data domains that may be in relationship with other
entities.

11
WELMEC Guide 7.2: 2023 Software Guide

Note: The software of measuring instruments consists of one or more modules.

Non-interruptible cumulative measurement: A cumulative measuring process with
no definite end that cannot be stopped and continued again by a user/operator without
invalidating the result of the measurement.
Note 1: Examples include: a) continuous totalising automatic weighing instrument,
b) heat meter.
Note 2: See also interruptible cumulative measurement.
Open network: A network of arbitrary participants (devices with arbitrary functions). The
number, identity and location of a participant can be dynamic and unknown to the other
participants (see also closed network).
Operating System: The software to control program operation and to provide the ser-
vices for resource allocation, task scheduling, I/O control, and data management.
Note 1: Other programs (such as editors, office programs etc.) not intended for these
tasks do not count as part of the operating system.
Note 2: For category 1 components or complete measuring instruments the legally rel-
evant parts of the operating system, usually, at least consist of the boot loader, the ker-
nel, the interfaces (hardware and inter-process communication), the (background) ser-
vices, administration of user privileges, cryptographic libraries as well as the configura-
tion files of those parts.
Note 3: For category 2 components the legally relevant parts of the operating system,
usually, at least consist of the interfaces (hardware and inter-process communication),
administration of user privileges, cryptographic libraries as well as the configuration files
of those parts.
Protective interface: A legally relevant software module that handles all data flow to
the legally relevant software module(s) in order to prevent inadmissible influences.
Protection: The means to protect the measurement data, parameters, measuring
instrument, component or software module with the intention of making an intervention
impossible or evident.
Public Key Infrastructure (PKI): An organisation to guarantee the trustworthiness of a
public key system. This includes granting and distributing cryptographic certificates to
all members that take part in the information exchange.
Public Key System (PKS): A pair of two different keys, one called the secret key and
the other the public key. To verify integrity and authenticity of information, the hash code
of the information generated by a hash function is encrypted with the secret key of the
sender to create the signature, which is decrypted later by the receiver using the
sender’s public key.
Risk class: A class of measuring instrument types with almost identical risk
assessments.
Sealing: A means intended to protect the software, parameters, measurement data,
measuring instrument, component, or software module against any modification,
readjustment, removal of components or software modules, etc.
Note: This may be achieved by hardware, software or a combination of both.
Securing: A means to prevent unauthorized access to hardware, software, parameters
or measurement data.

12
WELMEC Guide 7.2: 2023 Software Guide

Note: This may be achieved by means of passwords.

Signature algorithm: A cryptographic algorithm that encrypts (encodes) a hash code
using an encoding key and that allows decoding of the encrypted hash code if the
corresponding decoding key is available.
Significant defect: An incident that has an undesirable impact on the compliance of the
measuring instrument or a fault.
Note: Examples of significant defects include a) deletion of the audit trail, b) inadmissible
parameter changes, c) unauthorised updates and d) accidental software changes due
to physical effects.
Software download: The process of automatically transferring software to a target
measuring instrument or component using any technical means from a local or distant
source (e.g., exchangeable storage media, portable computer, remote computer) via
arbitrary connections (e.g., direct links, networks).
Software examination: A technical operation that consists of determining one or more
characteristics of the software according to the specific procedure (e.g., analysis of
technical documentation or running the program under controlled conditions).
Software identification: A sequence of readable characters (e.g., version number,
checksum) that represents the software or software module under consideration.
Note: Software identification can be checked on an instrument whilst in use.
Software interface: A program code and dedicated data domain; receiving, filtering, or
transmitting data between software modules.
Note 1: A software interface is not necessarily legally relevant.
Note 2: A software interface is an interface between two or more software modules,
used to exchange data and transmit commands.
Software separation: The separation of the software in measuring instruments or
components, which can be divided into legally relevant software modules and not legally
relevant software modules.
Note: These modules communicate via a protective interface, see S3.
Source code: A computer program written in a form (programming language) that is
legible and editable.
Note: Source code is compiled or interpreted into executable code.
Storage device: A device used for storing measurement data that is necessary to
construct the measurement result and/or keeping the measurement result available after
completion of the measurement for later legally relevant purposes.
Sub-assembly: A hardware device, mentioned as such in the instrument-specific an-
nexes, that functions independently and makes up a measuring instrument together with
other sub-assemblies with which it is compatible, or with a measuring instrument with
which it is compatible [MID, Article 4 (2)].
TEC: The type examination certificate.
Time stamp: A unique value, e.g., in seconds, or a date and time string denoting the
date and/or time at which a certain incident (e.g., measurement or event) occurred.
Transmission of measurement data: The electronic transportation of measurement
data via communication lines or other means to a receiver.

13
WELMEC Guide 7.2: 2023 Software Guide

Trust Centre: An association that trustworthily generates, keeps, and issues information
about the authenticity of public keys of persons or other entities, e.g., measuring
instruments.
Type-specific parameter: A legally relevant parameter with a value that depends on
the type of instrument, component and/or software module subject to legal control.
Note: Type-specific parameters are part of the legally relevant software.
Universal device: A device that is not constructed for a specific purpose, but that can
be adapted to a legally relevant task by software.
User interface: An interface that enables information to be interchanged between the
user/operator and the measuring instrument or its (hardware) components or software
modules.
Note: Typical examples of user interfaces are switches, keyboard, mouse, display,
monitor, printer, touchscreen, software window on a screen including the software to
generate it.
Validation: The confirmation by examination and provision of objective evidence (i.e.,
information that can be proved true, based on facts obtained from observations,
measurement, test, etc.) that the particular requirements for the intended use are
fulfilled. In the present case the related requirements are those of the MID [2].
Verification: The provision of objective evidence that a given item fulfils specified
requirements.
Verification of a measuring instrument: The conformity assessment procedure (other
than type evaluation) which results in the affixing of a verification mark and/or issuing of
a verification certificate.

14
WELMEC Guide 7.2: 2023 Software Guide

How to use this guide

This chapter describes the organisation of this guide and explains how to use it.
Overall structure of the guide
The guide is organised as a structured set of requirement blocks. The overall structure
of the guide follows the classification of measuring instruments into basic configurations
and the classification of so-called IT configurations. The set of requirements is
complemented by instrument-specific requirements.
Consequently, there are three types of requirement sets:
1. requirements for two basic configurations of measuring instruments (called
type P and U) as well as requirements for operating systems (called exten-
sion O),
2. requirements for IT configurations (called extensions L, T, S and D) and
3. instrument-specific requirements (called extensions I1, I2, …).
The first type of requirements is applicable to all instruments. With regard to the operat-
ing system and the applicability of the respective extension (O), see subchapter 2.2.
The second type of requirements concerns the following IT configurations: storage of
measurement data (L), transmission of measurement data (T), software download (D)
and software separation (S). Each set of these requirements is only applicable if the
corresponding function exists.
The last type is a collection of further, instrument-specific requirements. The numbering
follows the numbering of instrument-specific annexes in the MID [2]. The set of require-
ments blocks that may be applied to a given measuring instrument is schematically
shown in Figure 2-1.

Figure 2-1: Type of requirement sets that should be applied to an instrument

15
WELMEC Guide 7.2: 2023 Software Guide

16
WELMEC Guide 7.2: 2023 Software Guide

Figure 2-2: Overview of requirement sets

In addition to the structure described, the requirements of this guide are differentiated
according to risk classes. Six risk classes, numbered from A to F with increasing risk
assumptions, are introduced. The lowest risk class A and the highest risk classes E and
F are not used for instruments under MID regulation, for the present. They are place-
holders for the eventual case, that they will become necessary in future. The remaining
risk classes B to D cover all of the instrument classes falling under the regulation of MID.
Moreover, the risk classes from A to F provide a sufficient window of opportunity for the
case of changing risk evaluations. The classes are defined in Chapter 3 of this guide.
Each measuring instrument shall be assigned to a risk class because the particular
software requirements to be applied are governed by the risk class the instrument
belongs to.

How to select the appropriate parts of the guide

This comprehensive software guide is applicable to a large variety of instruments. The
guide is modular in form. The appropriate requirement sets can be easily selected by
observing the following procedure.
See also Figure 2-2 for an overview of the different requirement sets.

Step 1: Selection of the basic configuration (P or U)

Only one of the two sets of requirements for basic configurations needs to be applied.
Decide which basic configuration the instrument conforms to: a measuring instrument
using a built-for-purpose device with embedded software (type P, see chapter 4) or an
instrument using a universal device (type U, see chapter 5). If type U is selected and the
instrument is equipped with a legally relevant operating system, i.e., the operating
system is used to fulfil the essential requirements of the MID or can be used to affect
compliance with requirements, the extension for operating systems (extension O) shall
be applied simultaneously. If extension O is not applicable because the prerequisites
laid down in the extension do not apply, the entire software of the instrument shall be
treated as type P. If only a sub-assembly or component of the instrument is the matter
of concern, then decide accordingly for the sub-assembly or component. Always apply
the complete set of requirements that belongs to the respective basic configuration and
extension O respectively.

Step 2: Selection of applicable IT configurations (extensions L, T, S and D)

17
WELMEC Guide 7.2: 2023 Software Guide

The IT configurations comprise: storage of measurement data (L), transmission of

measurement data (T), software separation (S) and download of legally relevant
software (D). The corresponding requirement sets, called modular extensions, are
independent of each other. The sets selected depend only on the IT configuration. If an
extension set is selected, then it shall be applied in full. Decide which, if any, of the
modular extensions are applicable and apply them accordingly.

Step 3: Selection of instrument-specific requirements (extension I)

If applicable, select a respective instrument-specific extension I, and apply the

instrument-specific requirements accordingly.

Step 4: Selection of the applicable risk class (extension I)

Select the risk class as defined in the respective instrument-specific extension I, chapter
11. There, the risk class is defined uniformly for a class of measuring instruments or
possibly further differentiated for categories, fields of application, etc. Once the
applicable risk class has been identified, only the respective requirements and validation
guidance need to be considered.

How to work with a requirement block

Each requirement block contains a well-defined requirement. It consists of a defining
text, explanatory specifying notes, the documentation to be provided, the validation guid-
ance and examples of acceptable solutions (if available). The content within a require-
ment block may be subdivided according to risk classes. This leads to the schematic
presentation of a requirement block shown in Figure 2-3.

Title of the requirement

Main statement of the requirement
Specifying notes (scope of application, additional explanations, exceptional cases,
etc.)
Documentation to be provided (eventually differentiated between risk classes)
Validation guidance for Validation guidance for ...
one risk class another risk class
Example of an acceptable Example of an acceptable …
solution for one risk class solution for another risk
class

Figure 2-3: Structure of a requirement block

The requirement block represents the technical content of the requirement including the
validation guidance. It addresses both the manufacturer and the notified body in two
directions: (1) to consider the requirement as a minimal condition, and (2) not to put
demands beyond this requirement.

Notes for the manufacturer:

• Observe the main statement and the additional specifying notes.

18
WELMEC Guide 7.2: 2023 Software Guide

• Provide documentation as required.

• Acceptable solutions are examples that comply with the requirement. There is
no obligation to follow them.
• The validation guidance has an informative character.

Notes for notified bodies:

• Observe the main statement and the additional specifying notes.
• Follow the validation guidance.
• Confirm the completeness of the documentation provided.

How to work with the checklists

Checklists are means of ensuring that all the requirements within a chapter have been
covered by the manufacturer or examiner. They are part of the test report. Be aware,
the checklists are only of a summarising nature, and they do not distinguish between
risk classes. Checklists do not replace the requirement definitions. Refer to the
requirement blocks for complete descriptions.
Procedure:
• Gather the checklists, which are necessary according to the selection
described in steps 1, 2 and 3 in sub-chapter 2.2.
• Go through the checklists and prove whether all requirements have been met.
• Fill in the checklists as required.

19
WELMEC Guide 7.2: 2023 Software Guide

Definition of risk classes

General principle
The specific requirements of this guide are differentiated according to (software) risk
classes. In this guide, risks are related to software of the measuring instrument and not
to any other component. For convenience reasons, the shorter term “risk class” is used.
Each measuring instrument shall be assigned to a risk class because the specific
software requirements to be applied are tailored to the risk class the instrument belongs
to.
Software risks in measuring instruments addressed by this guide are mainly caused by
three risk factors: inadequate protection of software, inadequate examination of
software, and non-conformity to type. A risk class is a combination of levels of these
three risk factors where the definition of levels of the risk factors is indirectly made by
definition of levels for the correspondingly necessary counteractions. Three levels of
counteractions, low, middle and high, are introduced for each of the risk factors. The
higher the risk is assumed, the higher the level of counteraction is taken.

Description of levels of counteractions for the risk factors

The following definitions are used for the corresponding levels.

Software protection levels

Low: No particular protection measures against intentional changes are
required.
Middle: The software is protected against intentional changes made by using
easily-available and simple common software tools (e.g. text editors).
High: The software is protected against intentional changes made by using
sophisticated software tools (debuggers and hard disc editors, software
development tools, etc).

Software examination levels

Low: Standard type examination including functional testing of the instrument is
performed. No extra software testing is required.
Middle: In addition to the low level, the software is examined on the basis of its
documentation. The documentation includes the description of the
software functions, parameter description, etc. Practical tests of the
software-supported functions (spot checks) may be carried out to check
the plausibility of documentation and the effectiveness of protection
measures.
High: In addition to the middle level, an in-depth test of the software is carried
out, usually based on the source code.

20
WELMEC Guide 7.2: 2023 Software Guide

Software conformity levels

Low: The legally relevant software of individual instruments is considered
conform to the legally relevant software of the type under examination if
the functionality of the software corresponds to the technical
documentation of the type. The binary code of the software itself does not
need to be identical to the software of the type.
Middle: In addition to the conformity level “low”, the binary code of legally relevant
software of individual instruments is identical to the software of the type
under examination (or re-examination). Software separation is allowed if
the restrictions in extension S of this guide (chapter 9) are fulfilled.
High: The binary code of the complete software implemented in the individual
instruments is identical to the software of the type under examination.
Software separation is not relevant.

Derivation of risk classes

Out of the 27 theoretically possible level combinations, only 3 or at the utmost 6 are of
practical interest (risk classes B, C, D and eventually A, E and F). They cover all of the
instrument classes falling under the regulation of MID. Moreover, they provide a
sufficient window of opportunity for the case of changing risk evaluations. The classes
are defined in Table 3-1. The table shall be interpreted in a way that a certain risk class
is defined by the corresponding combination of levels of necessary counteractions.

Software Software Software

Risk Class
Protection Examination Conformity
A low low low
B middle middle low
C middle middle middle
D high middle middle
E high high middle
F high high high

Table 3-1: Definition of risk classes

Interpretation of risk classes

Risk class A: It is the lowest risk class at all. No particular measures are required
against intentional changes of software. Examination of software is part
of the functional testing of the device. Conformity is required on the level
of documentation. It is not expected that any instrument is classified as
a risk class A instrument. However, by introducing this class, the
corresponding possibility is held open.
Risk class B: In comparison to risk class A, the protection of software is required on
the middle level. Correspondingly, the examination level is raised to the
middle level. The conformity remains unchanged in comparison to risk
class A.
21
WELMEC Guide 7.2: 2023 Software Guide

The software examination is carried out on the basis of the

documentation. As a consequence, the TEC allows different
implementations with respect to the same documentation when putting
the instruments on the market1.
Risk class C: In comparison to risk class B, the conformity level is raised to “middle”.
This means, the binary code of the legally relevant software of individual
instruments is identical to the software of the type under examination.
The levels of protection and examination remain unchanged in
comparison to risk class B.
Risk class D: The significant difference in comparison to risk class C is the upgrade
of the protection level to “high”. The examination level remains
unaffected at “middle”, therefore sufficiently informative documentation
shall be provided to show that the protection measures taken are
appropriate. The conformity level remains unchanged in comparison to
risk class C.
Risk class E: In comparison to risk class D, the examination level is raised to “high”.
The levels of protection and conformity remain unchanged.
Risk class F: The levels with respect to all aspects (protection, examination and
conformity) are set to “high”. The difference to risk class E is that there
is not any not legally relevant software anymore.

1 After having put the instrument on the market, the allowance for changing software depends on national
regulations.

22
WELMEC Guide 7.2: 2023 Software Guide

Basic requirements for embedded software in a

measuring instrument using a built-for-purpose device
(type P)

The set of specific requirements of this chapter are valid for built-for-purpose device as
well as for sub-assemblies and for components according to WELMEC Guide 8.8 (Mod-
ular Evaluation of Measuring instruments) that are of the built-for-purpose type. The
validity for sub-assemblies and components is included even if it is not repeatedly men-
tioned in the following text. The conditions, however, under which sub-assemblies and
components may be separately examined and the corresponding certificates may be
accepted, are not part of this guide.
If the measuring instrument uses a universal device (general-purpose PC), the set of
specific requirements in chapter 5 shall be referred to (type U instrument). The specific
requirements of type U instruments shall always be used if at least one of the
subsequent technical characteristics of a measuring instrument using a built-for-purpose
device is not matched.
Technical description
A type P instrument is a measuring instrument with an embedded IT system (e.g., a
microprocessor or microcontroller-based system). All components of the IT system used
are open for evaluation.
The embedded IT system is characterised in particular as follows:
 The software is exclusively constructed for the measuring purpose. Additional
functions for securing software and data, for transmitting data and for
downloading software are considered constructed for the measuring purpose.
 The user interface is dedicated to the measuring purpose, i.e., it is normally in
an operating mode subject to legal control. Switching to an operating mode not
subject to legal control is possible.
 An operating system (OS) or subsystems of it may be included if
 all communication is under control of legally relevant software,
 it does not allow loading or changing modules, parameters or data or
running programs,
 it does not allow to change the environment of the legally relevant
application, etc.
This includes that the access prevention shall be preset and not the result
of a respective subsequent configuration of these components.
 The software environment is invariable and there are no internal or external
means for programming or changing the software in its embedded status.
Software download is allowed if the specific requirements of extension D
(chapter 10) are observed.

23
WELMEC Guide 7.2: 2023 Software Guide

Specific requirements for type P

Risk Classes B to E
P1: Documentation
In addition to the specific documentation required in each of the following requirements, the documentation
shall basically include:
a. A description of the legally relevant software.
b. A description of the user interface, menus and dialogues.
c. The software identifier(s) of the legally relevant software.
d. An overview of the system hardware, e.g., topology block diagram, type of computer(s), type of
network.
e. The operating manual.

24
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P2: Software identification
The legally relevant software shall be clearly identified. The identifier(s) shall be permanently presented by
the instrument or presented on command or during operation.
Specifying Notes:
1. Legally relevant software identifiers may be independent or part of well-structured identifiers. In the second
case, the legally relevant software identifier(s) shall be clearly distinguishable.
2. If different software versions are valid implementations of the same type (e.g., for instruments in risk class
B), then the legally relevant software identifier(s) shall be the same for those versions.
3. The legally relevant software identifiers are type-specific parameters.
4. The legally relevant software identifiers shall be easily presented without requiring an additional tool.
5. The identifier(s) shall be displayed permanently on a protected plate, on command or on start-up.

Required Documentation:
1. The documentation shall list the software identifier(s) and describe how they are created, how they are
protected, how they are presented and how they are structured in order to differentiate between legally
relevant software identifiers and others as well as to assess the uniqueness.
2. The documentation shall list which legally relevant module is covered by which legally relevant software
identifier.

Validation Guidance:
Checks based on documentation:
 Check whether all legally relevant software identifiers are given in the documentation.
 Check whether legally relevant modules are clearly described so that it is reproducible which module is
covered by which software identifier.
 Examine the description of the generation and visualisation of all legally relevant software identifiers.
 Check whether all legally relevant software identifiers are unique (in particular in cases of re-
examinations).
Functional Checks:
 Check that the legally relevant software identifiers can be visualised as described in the documentation.
 Check that the legally relevant software identifier(s) presented are identical to the identifiers given in the
documentation.
 The legally relevant software identifier(s) are distinguishable from other identifiers.

Example of an Acceptable Solution:

a) a checksum over executable code.
b) any string, possibly added by a version number,
c) any string of numbers, letters, other characters,
Please note: If the manufacturer chooses a mixed identifier for legally relevant and not legally relevant
software, a simple solution that allows distinguishing the identifiers is using placeholders in the TEC, e.g.,
“abc1.xx” with “abc1” for the legally relevant software and “xx” as placeholder for not legally relevant
software.

Additions for Risk Class E

Required Documentation
Identical to risk classes B to D.

Validation Guidance
Identical to risk classes B to D.

25
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P3: Influence via user interfaces

Commands entered via the user interfaces shall not inadmissibly influence the legally relevant software,
device-specific parameters and measurement data.

Specifying Notes:
1. There shall be an unambiguous assignment of each command to an initiated function or data change.
2. Commands that are not documented shall have no effect on legally relevant software, device-specific
parameters and measurement data.
3. The modules that interpret commands are considered to be legally relevant software.

Required Documentation:
If the instrument has the ability to receive commands, the documentation shall include:
 Description of commands and their effect on legally relevant software, device-specific parameters and
measurement data.
 Description of how the legally relevant software, device-specific parameters and measurement data are
protected from being influenced by other inputs.

Validation Guidance:
Checks based on documentation:
 Check that documented commands are admissible, i.e., that they have an allowed influence on the legally
relevant software, device-specific parameters and measurement data).
 Check the protection measures against influences from other inputs.
Functional Checks:
 Carry out practical tests (spot checks) with documented commands.
 Try some combinations of keys to check that they are not having an effect on legally relevant software,
device-specific parameters, and measurement data. In case of an open source O.S. with a closed shell,
try some not documented standard commands to check that they are not accepted.

Example of an Acceptable Solution:

There is a legally relevant module that receives and interprets commands from the user interface. It forwards
only allowed commands to the other legally relevant modules. All unknown or not allowed sequences of
switch or key actuations are rejected and have no impact on the legally relevant software, device-specific
parameters and measurement data.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check the software design whether data flow concerning commands is unambiguously defined and
realised only in the legally relevant software.
 Search for inadmissible data flow from the user interface to the legally relevant data domains.
 Check with tools or manually that commands are decoded correctly.
 Check the source code for undocumented commands.

26
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P4: Influence via communication interfaces

Commands input via communication interfaces of the instrument shall not inadmissibly influence the legally
relevant software, device-specific parameters and measurement data.

Specifying Notes:
1. There shall be an unambiguous assignment of each command to an initiated function or data change.
2. Commands that are not documented shall have no effect on legally relevant software, device-specific
parameters and measurement data.
3. The modules that interpret commands are considered to be legally relevant software.
4. Interfaces that allow commands with inadmissible effects on the legally relevant software, device-specific
parameters and measurement data shall be sealed or protected in another appropriate way. This also
applies for interfaces that cannot be completely assessed.
5. This special requirement does not apply to software download according to Extension D.

Required Documentation:
If the instrument has an interface, the documentation shall include:
 Description of commands and their effect on the legally relevant software, device-specific parameters and
measurement data.
 Description of how the legally relevant software, device-specific parameters and measurement data are
protected from being influenced by other inputs.

Validation Guidance:
Checks based on documentation:
 Check that documented commands are admissible, i.e., that they have an allowed influence on the legally
relevant software, device-specific parameters and measurement data).
 Check the protection measures against influences from other inputs.
Functional checks:
 Carry out practical tests (spot checks) using peripheral equipment.

Example of an Acceptable Solution:

 There is a legally relevant module that receives and interprets data from the interface. It forwards only
allowed commands to the other legally relevant modules. All unknown or not allowed signal or code
sequences are rejected and have no impact on the legally relevant software, device-specific parameters
and measurement data.

Additions for Risk Classes E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check the software design whether data flow concerning commands is unambiguously defined in the
legally relevant software and can be verified.
 Search inadmissible data flow from the interface to the legally relevant data domains.
 Check with tools or manually that commands are decoded correctly.
 Check the source code for undocumented commands.

27
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P5: Securing and protecting legally relevant software and device-specific parameters
Legally relevant software and device-specific parameters shall be secured against unintentional and
protected against accidental changes.

Specifying Notes:
1. The software shall be capable to detect changes caused by physical effects (electromagnetic
interference, temperature, vibration, etc).
2. Means shall be implemented to secure from unintentional misuse of the user interfaces.
Required Documentation:
1. The documentation should show the measures that have been taken to secure the legally relevant
software and device-specific parameters from unintentional changes and how the legally relevant
software and device specific parameters are protected against accidental changes.

Validation Guidance:
Checks based on documentation:
 Check that measures against accidental or unintentional changes are described and appropriate.
Functional checks:
 Practical spot checks to show that software and device-specific parameters can either not be changed or
only changed after the security measure has been successfully passed, e.g., a password is submitted.

Example of an Acceptable Solution:

 The accidental modification of legally relevant software and device-specific parameters is checked by
periodically calculating checksum(s) and automatically comparing them with deposited nominal value(s).
If the comparison does not match, reactions are necessary that are adequate for the instrument (e.g., stop
of measurement, corresponding indication of measurement data, see Extension I for eventual
recommendations).
 Alternative methods are possible if the change status of software can be identified by them.
 For fault detection see Extension I.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C and D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes C and D):
Checks based on the source code:
 Check whether measures taken for detection of changes are correctly implemented.
 Check whether all legally relevant modules and all device-specific parameters are covered by the
checksum.

28
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P6: Software and measurement data protection

Legally relevant software and measurement data shall be protected against intentional changes.

Specifying Notes:
1. For protection against manipulation using the user interface, see P3.
2. For protection against manipulation using communication interfaces, see P4.
3. Measurement data are considered to be sufficiently protected if it is ensured that only legally relevant
software can process them. If no not legally relevant software exists, this is addressed by interface
protection in P requirements (P3, P4). In case of not legally relevant software, additional internal
protection against influences from the not legally relevant software is ensured through Extension S.
4. Storage devices that contain software and measurement data shall be protected against exchange.
5. A checksum or an alternative method with the same level
of protection shall be provided in order to support the
detection of software modifications.
6. The calculated checksum or an alternative indication of
software modification shall be made visible on command
for control purposes.
7. The checksum or the alternative indication is calculated
over the legally relevant software. The module that organ-
izes the generation of checksums or alternative indications
is legally relevant.
8. If a checksum is used, the algorithm shall have a key length
of at least 4 bytes; (See also Extensions L and T).
9. For key treatment, see also L5 and T5.

Required Documentation:
The documentation shall describe the protection methods.

• Description of measures that have been taken to protect the software, in particular the method of
checksum calculation and nominal checksums or alternative methods with the corresponding nominal
indication.
• Description of methods to prevent exchange of the memory that contains the software.
• Description of programming mode and its disabling, if applicable.

Validation Guidance:
Checks based on documentation:
 Examine whether the documented means of protection against exchange of the storage device that
contains the legally relevant software and measurement data are sufficient.
 Check that the checksum(s) or alternative indication(s) cover the legally relevant software.
Functional checks:
 Test practically the programming mode and check whether disabling works.
 Compare calculated checksums or alternative indications with the nominal values.

Example of an acceptable Solution: Example of an acceptable Solution: (in addition to a) and b))
a) To prevent from removing and replacing c) Executable code is protected by means of checksums. The
physical memory, the housing of the module calculates its own checksum and compares it with
instrument or the physical memory itself a desired value that is hidden in the executable code itself.
is protected. If the self-check fails, the module is blocked. A CRC-32
b) The instrument is sealed, and the inter- checksum with a secret initial vector (hidden in the
faces comply with the requirements P3 executable code) is used.
and P4.

Additions for Risk Classes E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

29
WELMEC Guide 7.2: 2023 Software Guide

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for the detection of intentional changes are correctly implemented.

30
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P7: Parameter protection

Device-specific parameters shall be protected against intentional modifications.
Specifying Notes:
1. Certain device-specific parameters may be set by the user, provided that they are protected by a facility
to automatically and non-erasable record any adjustment of the legally relevant device specific parame-
ter, e.g., an audit trail.
2. If necessary for the purpose of verification of a measuring instrument, display or printing of the current
relevant parameter settings shall be possible.
3. The records that provide evidence of an intervention shall be made available via display or printout upon
command.

Required Documentation:
1. The documentation shall describe how the device-specific parameters are protected, whether they may
be set and how they are set.
2. The documentation shall describe how the device specific parameters can be displayed or printed for the
purpose of verification of a measuring instrument.
3. The documentation shall describe how the records that provide evidence of an intervention can be dis-
played or printed.

Validation Guidance:
Checks based on documentation:
 Check that changing or adjusting device-specific parameters is impossible without evidence of an
intervention.
 Check that all relevant device-specific parameters (given in Extension I, if any) are protected.
 Check that all records that provide evidence of an intervention are displayed or printed.
Functional checks:
 Check that the device-specific parameters are adequately protected.
 Check that the device-specific parameters can be displayed or printed.
 Check that all records that provide evidence of an intervention can be displayed or printed.

Example of an Acceptable Solution:

a) Device-specific parameters that may not be set by the user are protected by sealing the instrument or
memory housing and disabling the write enable/disable input of the memory circuit by an associated
jumper or switch, which is sealed.
b) Device specific parameters are protected by an audit trail.
Changes of device specific parameters are registered in the audit
trail. It is an information record stored in a non-volatile memory.
Each entry is generated automatically by the legally relevant
software and contains:
• the identifier of the parameter (e.g., the name);
• the parameter value (the current or the value before);
• the time stamp of the change.
The audit trail cannot be deleted or be changed without destroying
a seal. The content of the audit trail is shown on the display or
printed upon command.

Additions for Risk Classes E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check source code whether measures taken for protecting device-specific parameters are correctly
implemented.

31
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

P8: Presented measurement data

The authenticity of the presented measurement data shall be guaranteed and the presentation shall be clear
and accompanied by all information necessary to inform the user of the significance of the result.

Specifying Notes:
1. It shall not be possible to fraudulently simulate (spoof) legally relevant software for presenting
measurement data.
2. For each presented legally relevant measurement data the meaning shall be clear. All presented legally
relevant measurement data shall be distinguishable from each other.
3. Presented legally relevant measurement data shall be clearly distinguishable from not legally relevant
data.
4. Presented measurement data shall be accompanied by all information, which is necessary to interpret
them (e.g., quantity, unit, sensor number, scale factor). Regarding necessary information to accompany
the data, see L1, T1. The sensor number (if required to correctly interpret the result) is a legally relevant
parameter that needs to be secured and protected, see P5/U5 and P7/U7.

Required Documentation:
 Naming of the modules which realise presentation of legally relevant measurement data.

Validation Guidance:
Checks based on documentation:
 Check that the presentation of measurement data can only be performed by legally relevant software.
Functional checks:
 Check that the meaning of all presented legally relevant measurement data is clear and that they are
distinguishable from each other.
 Check through visual control if the presentation of measurement data is easily distinguishable from other
information that may also be presented.
 Check through visual control that the presented measurement data are accompanied by all necessary
information.
 If required to correctly interpret the result, check that its source is identified and indicated by the legally
relevant software.

Example of an Acceptable Solution:

1. The presentation contains not legally relevant data that is clearly distinguishable from legally relevant
measurement data.
2. The sensor source encrypts the measurement data with a key known to the legally relevant software
running on the built-for-purpose device (e.g., a secret random number). Only the legally relevant software
can decrypt and use the measurement data, not legally relevant modules or components cannot as they
do not know the key. For key treatment see Extension T.
3. Before sending measurement data the source initiates a handshake sequence with the legally relevant
software on the built-for-purpose device based on secret keys. Only if the legally relevant software on the
built-for-purpose device communicates correctly, the source unit sends its measurement data. For key
treatment see Extension T.
4. The secret random number used in solutions 1 / 2 is chosen 4. The secret random number used in
and entered to the source and software on the built-for-purpose solutions 1 / 2 is chosen and entered
device without destroying a seal. in the source and in the software on
the built-for-purpose device only
when a seal is destroyed.
5. If the presented measurement data are not explicitly linked to a sensor, the originating sensor transmits
its data together with a unique identification of the sensor itself. All presented measurement data are
labelled with the identification of the individual sensor. The identification of each sensor is a legally
relevant parameter shown on the sensor housing.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.

32
WELMEC Guide 7.2: 2023 Software Guide

Validation Guidance (in addition to the guidance for risk classes C to D):
Checks based on the source code:
 Check that legally relevant software generates the presented measurement data.
 Check whether all measures taken are correct to guarantee the presentation of measurement data by
legally relevant software.

33
WELMEC Guide 7.2: 2023 Software Guide

Basic requirements for software of measuring

instruments using a universal device (type U)

The set of specific requirements of this chapter is valid for measuring instruments based
on a general-purpose computer as well as for sub-assemblies and for parts according
to WELMEC Guide 8.8 that uses universal device. The validity for sub-assemblies and
parts is included even if it is not repeatedly mentioned in the following text. The
conditions, however, under which sub-assemblies and parts may be separately
examined and the corresponding certificates may be accepted, are not part of this guide.

Technical description
A type U measuring system is typically characterised by the following configurations.

Hardware configuration
a) A modular general-purpose computer-based system. The computer system may be
stand-alone, part of a closed network, e.g. Ethernet, token-ring LAN, or part of an
open network, e.g. Internet.
b) Because the system is general purpose, the sensor is normally external to the
computer unit and linked to it by a communication connection.
c) The user interface offers further functions, which are not under legal control, besides
the operating mode for the measurement task.
d) Storage may be integrated, e.g., hard disk, or removable, e.g., USB, or remote.

Software configuration
e) Usually, an operating system is used.
f) In addition to the measuring instrument application, other software applications may
also reside on the system at the same time.
In addition to configurations described above, a type U system shall also be assumed if
the characteristics of a type P instrument (see sub-chapter 4.1) are not completely
fulfilled.

Consequences for risk classification

The software of type U instruments is much more openly accessible than the software
of type P instruments. The protection of software integrity shall be enhanced in
comparison to type P instruments. In particular, a checksum or an equivalent means
shall be required to support integrity checks of the software. The consequence is that
the conformity level “low” (only functional correspondence of the software to the
technical documentation of the type under examination) is not an adequate means for
ensuring software integrity. This means risk class C is the lowest possible risk class
instruments of the type U may be allocated to.

34
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements for type U

Risk Classes C to E
U1: Documentation
In addition to the specific documentation required in each requirement below, the documentation shall
basically include:
a. A description of the legally relevant software functions, meaning of the data, etc.
b. A description of the user interface, menus and dialogues.
c. The software identifier(s) of the legally relevant software .
d. An overview of the system hardware, e.g., topology block diagram, type of computer(s), type of
network
e. Regarding the documentation of the configuration of the operating system, see Extension O.
f. The operating manual.

35
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C and D

U2: Software identification

The legally relevant software shall be clearly identified. The identifier(s) shall be permanently presented by
the instrument, presented on command or during operation.

Specifying Notes:
1. Legally relevant software identifier(s) may be independent or part of well-structured identifiers.
2. In the case that a legally relevant software identifier is embedded in an overall identifier, it shall be clearly
distinguishable.
3. The legally relevant identifier(s) shall be unique for each legally relevant module an instrument is
equipped with.
4. The legally relevant identifiers shall be easily presented without requiring an additional tool.
5. For the identification of operating system parts, see O6. These specifying notes apply in conjunction
with O6 to the identification of the operating system.
6. The legally relevant software identifier(s) are type-specific parameters and shall be protected as such
(see U5 and U6). If the identifiers are not inextricably linked to the software itself, other protection means
are required.
7. The identifier(s) shall be displayed permanently, on command or on start-up.

Required Documentation:
 The documentation shall list the software identifiers and describe how they are created, how they are
protected, how they are presented and, if applicable, how they are structured in order to differentiate
between legally relevant identifiers and others.

Validation Guidance:
Checks based on documentation:
 Check whether all legally relevant software identifiers are given in the documentation.
 Check whether all legally relevant modules are clearly described so that it is reproducible which module
is covered by which software identifier.
 Examine the description of the generation and visualisation of all legally relevant software identifiers.
 Check whether all legally relevant software identifiers are unique (in particular in cases of re-
examinations).
Functional checks:
 The software identifiers can be visualised as described in the documentation.
 The presented identifiers are identical to the identifiers given in the documentation.
 The legally relevant identifiers are distinguishable from other identifiers.

Example of an Acceptable Solution:

a) a checksum over executable code
b) a string added by a version number,
c) any string of numbers, letters, other characters,
 If the manufacturer chooses a mixed identifier for legally relevant and not legally relevant software, a
simple solution that allows distinguishing the identifiers is using placeholders in the TEC, e.g., “abc1.xx”
with “abc1” for the legally relevant software and “xx” as placeholder for not legally relevant software.

Additions for Risk Class E

Required Documentation
Identical to risk classes C and D.

Validation Guidance
Identical to risk classes C and D.

36
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U3: Influence via user interfaces
Commands entered via the user interfaces shall not inadmissibly influence legally relevant software, device-
specific parameters and measurement data.

Specifying Notes:
1. There shall be an unambiguous assignment of each command to an initiated function or data change.
2. Commands that are not documented shall have no effect on legally relevant software, device-specific
parameters and measurement data.
3. The respective modules that interpret commands are considered to be legally relevant.

Required Documentation:
If the instrument has the ability to receive commands, the documentation shall include:
 Description of commands and their effect on legally relevant software, device-specific parameters and
measurement data.
 Description of how the legally relevant software, device-specific parameters and measurement data are
protected from being influenced by other inputs.

Validation Guidance:
Checks based on documentation:
 Check that documented commands are admissible, i.e., that they have an allowed influence on the
legally relevant software, device-specific parameters and measurement data).
 Check the protection measures against influences from other commands.
Functional checks:
 Carry out practical tests (spot checks) with documented commands.
 Try some combinations of keys using the keyboard to check that they are not having an effect on legally
relevant software, device-specific parameters, and measurement data.
 In case of an open source O.S. with a closed shell, try some not documented standard commands to
check that they are not accepted.

Example of acceptable Solution: Example of acceptable Solution:

• A legally relevant module filters out inadmissible • For using the measuring system, only an
commands. Only this module receives account with restricted permissions is set up.
commands, and there is no circumvention of it. Access to the administrator account is blocked
Any false input is blocked. according to U6.
• The user shell is closed, i.e., the user cannot
load programs, write programs or perform
commands to the operating system.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk class D):
Source code of the legally relevant software.
Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check the software design whether data flow concerning commands is unambiguously defined in the
legally relevant software and can be verified.
 Search inadmissible data flow from the user interface to legally relevant data domains.
 Check with tools or manually that commands are decoded correctly.
 Check the source code for undocumented commands.

37
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U4: Influence via communication interfaces

Commands input via communication interfaces of the device shall not inadmissibly influence the legally
relevant software, device-specific parameters and measurement data.

Specifying Notes:
1. There shall be an unambiguous assignment of each command to an initiated function or data change.
2. Commands that are not documented shall not have any effect on legally relevant software, device-
specific parameters and measurement data.
3. The module that interpret commands are considered to be legally relevant.
4. Interfaces that allow commands with inadmissible effects on the legally relevant software, device-
specific parameters and measurement data shall be sealed or protected in another appropriate way.
This also applies for interfaces that cannot be completely assessed.
5. This special requirement does not apply to software download according to Extension D.

Please note: If the operating system allows remote control or remote access, the requirements U3 apply to the
communication interface and the connected remote terminal, respectively.

Required Documentation:
If the instrument has an interface, the documentation shall include:
 Description of commands and their effect on legally relevant software, device-specific parameters and
measurement data.
 Description of how the legally relevant software, device-specific parameters and measurement data are
protected from being influenced by other inputs.

Validation Guidance:
Checks based on documentation:
 Check that documented commands are admissible, i.e., that they have an allowed influence on the
legally relevant software, device-specific parameters and measurement data).
 Check the protection measures against influences from other commands.
Functional checks:
 Carry out practical tests (spot checks) using peripheral equipment.

Examples of Acceptable Solutions:

 There is a legally relevant module that receives and interprets commands from the interface. It forwards
only allowed commands to the other legally relevant modules. All unknown or not allowed commands
are rejected and have no impact on the legally relevant software, device-specific parameters and
measurement data.
 The operating system policy for serial connections and the firewall settings for network connection
preventing an inadmissibly command execution to affect the legally relevant application.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes C to D):
Checks based on the source code:
 Check the software design whether data flow concerning commands is unambiguously defined in the
legally relevant software and can be verified.
 Search inadmissible data flow from the interface to the legally relevant data domains.
 Check with tools or manually that commands are decoded correctly.
 Check the source code for undocumented commands.

38
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U5: Securing and protecting legally relevant software and device-specific parameters
Legally relevant software and device-specific parameters shall be secured against unintentional and
protected against accidental changes.

Specifying Notes:
1. The software shall be capable to detect changes caused by physical effects (electromagnetic
interference, temperature, vibration, etc).
2. Means shall be implemented to secure from unintentional misuse of the user interfaces.
3. The accidental modification of legally relevant software and device-specific parameters shall be
periodically checked by calculating checksum(s) and automatically comparing them with deposited
nominal value(s). If the comparison does not match, reactions are necessary that are adequate for the
instrument (stop of measurement, indication of measurement data, see Extension I for eventual
recommendations)
Alternative methods are possible if the change status of software can be identified by them.
4. For additional protection measures to be implemented in the operating system, see O4.

Required Documentation:
• Description of measures that have been taken to secure the legally relevant software and device-
specific parameters from unintentional changes and how the legally relevant software and device
specific parameters are protected against accidental changes.
• Description of the checksum method and of reactions in case of non-matching.
• Description of how and where the nominal checksum(s), or the alternative indications of change status,
are deposited.

Validation Guidance:
Checks based on documentation:
 Check that measures against accidental or unintentional changes are described and appropriate.
 Check that the checksum(s) comprise the legally relevant software.
 Check that methods of checksum calculation, comparison and of reactions in the case of non-matching
are correct.

Example of an Acceptable Solution:

 To prevent misuse of the operating system, and to prevent overwriting or deletion of the legally relevant
software and all device-specific parameters full use is made of the protection and privacy rights provided
by the OS or programming language.
 All user rights for the deletion, moving or amendment of legally relevant software are removed, and
access is controlled via utility programs.
 The accidental modification of legally relevant software and all device-specific parameters is checked by
calculating a checksum over the executable code of the legally relevant software and all device-specific
parameters, comparing it with the nominal value and initiating appropriate actions if the legally relevant
executable code and/or device-specific parameters has/have been modified, see extension I for eventual
recommendation concerning the appropriate actions.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes C to D):
Checks based on the source code:
 Check whether measures taken for detection of changes are correctly implemented.
 Check whether all legally relevant modules and all device-specific parameters are covered by the
checksum.

39
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U6: Software and measurement data protection

Legally relevant software and measurement data shall be protected against intentional changes.

Specifying Notes:
1. Measurement data are considered to be sufficiently protected if it is ensured that only legally relevant
software can process them. This is addressed by interface protection in the U requirements U3 and U4.
In case of not legally relevant software, additional internal protection against influences from the not
legally relevant software is ensured through Extension S.
2. Storage devices that contain software and measurement data shall be protected against exchange.
3. A checksum or an alternative method with the same level of protection shall be provided in order to
support the detection of software modifications. The calculated checksum or an alternative indication of
software modification shall be made visible on command for control purposes.
4. The checksum or the alternative indication is calculated over the legally relevant software. The module
that organizes the generation of checksums or alternative indications is legally relevant.
5. For additional protection measures to be implemented in the operating system, see O4 and O7.
6. If a checksum is used, the algorithm shall have a key length of at least 4 bytes.
7. In general, a universal device is only usable if
additional hardware can be used to support pro-
tection.
8. Concerning algorithms and minimum key
lengths, the requirements or recommendations
of the national and international institutions re-
sponsible for data security shall be taken into
consideration.

Required Documentation:
• Description of measures that have been taken to protect the software, in particular the method of
checksum calculation and nominal checksums or alternative methods with the corresponding nominal
indication.
• Description of methods protecting the mass storages from exchange, if applicable.
• Description of how the checksum or an alternative indication are presented.

Validation Guidance:
Checks based on documentation
• Examine whether the documented means of protection against exchange of the storage device that
contains the legally relevant software and measurement data are sufficient.
• Check that the checksum(s) or alternative indication(s) comprise the legally relevant software.
• Check that measures taken to prevent from modifying or replacing legally relevant software by using
the operation system are adequate.
Functional checks:
• Arrange to calculate checksums or alternative indications and compare them with the nominal values.

Checks based on documentation:

1. Check whether the measures taken are
appropriate with respect to the required state of
the art for a high protection level.

Examples of an Acceptable Solution: Example of an Acceptable Solution:

1. Executable code is protected by means of  Executable code is protected by storing the
checksums. The module is calculating its own legally relevant software in a dedicated plug-in-
checksum and compares it with a desired value unit, which is sealed. The plug-in unit includes a
that is hidden in the executable code itself. If the read-only memory and a microcontroller.
self-check fails, the module is blocked. A CRC-32
checksum with a secret initial vector (hidden in
the executable code) is used. The access to the
administrator account is blocked by means of a
random password generated automatically,
known to nobody. Circumvention of the protection
means of the operating system by direct writing to

40
WELMEC Guide 7.2: 2023 Software Guide

mass storages or physical replacement is

prohibited by sealing.
2. The unauthorised manipulation of legally relevant
software is inhibited by the access control or pri-
vacy protection attributes of the operating system.
The administration level of these systems is pro-
tected by sealing or equivalent means.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance required for risk class D):
Checks based on the source code:
 Check communication with the additional securing hardware.
 Check that changes of legally relevant software are detected.

41
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U7: Parameter protection

Device-specific parameters shall be protected against intentional modification.

Specifying Notes:
1. Certain device-specific parameters may be set by the user, provided that they are protected by a facility
to automatically and non-erasable record any adjustment of the legally relevant device specific
parameter, e.g., an audit trail.
2. If necessary for the purpose of verification of a measuring instrument, display or printing of the current
relevant parameter settings shall be possible.
3. The records that provide evidence of an intervention shall be made available via display or printout
upon command.

Required Documentation:
1. The documentation shall describe how the device-specific parameters are protected, whether they may
be set and how they are set.
2. The documentation shall describe how the device specific parameters can be displayed or printed for
the purpose of verification of a measuring instrument.
3. The documentation shall describe how the records that provide evidence of an intervention can be
displayed or printed.

Validation Guidance:
Checks based on documentation:
 Check that changing or adjusting device specific parameters is impossible without evidence of an
intervention.
 Check that all relevant device-specific parameters (given in Extension I, if any) are protected.
 Check that all records that provide evidence of an intervention are displayed or printed.
Functional checks:
 Check that the device-specific parameters are adequately protected.
 Check that the device-specific parameters can be displayed or printed.
 Check that all records that provide evidence of an intervention can be displayed or printed.

Example of an Acceptable Solution:

 Device-specific parameters that may not be set by the user are protected by sealing the instrument or
memory housing and disabling the write enable/disable input of the memory circuit by an associated
jumper or switch, which is sealed.
 Device-specific parameters are protected by an audit trail. Changes of device-specific parameters are
registered in an audit trail. It is an information record stored in a non-volatile memory. Each entry is
generated automatically by the legally relevant software and contains:
 the identifier of the parameter (e.g., the name),
 the parameter value (the current or the value before) and
 the time stamp of the change.
The audit trail cannot be deleted or be changed without destroying a seal. The content of the audit trail
is shown on the display or printed upon command.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes C to D):
Checks based on the source code:
 Check whether measures taken for protecting device-specific parameters are correctly implemented.

42
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D

U8: Presented measurement data

The authenticity of the presented measurement data shall be guaranteed, and the presentation shall be
clear and accompanied by all information necessary to inform the user of the significance of the result.

Specifying Notes:
1. It shall not be possible to fraudulently simulate (spoof) legally relevant software for presenting
measurement data.
2. For each presented legally relevant measurement data the meaning shall be clear. All presented legally
relevant measurement data shall be distinguishable from each other.
3. Presented legally relevant measurement data shall be clearly distinguishable from not legally relevant
data.
4. Presented measurement data shall be accompanied by all information, which is necessary to interpret
them (e.g., quantity, unit, sensor number, scale factor). Regarding necessary information to accompany
the data, see L1, T1. The sensor number is a legally relevant parameter that needs to be secured and
protected, see P5/U5 and P7/U7.

Required Documentation:
 Naming of the modules which realise presentation of legally relevant measurement data.

Validation Guidance:
Checks based on documentation:
 Check that the presentation of measurement data can only be performed by legally relevant software.
Functional checks:
 Check that the meaning of all presented legally relevant measurement data is clear and that they are
distinguishable from each other.
 Check through visual control if the presentation of measurement data is easily distinguishable from other
information that may also be presented.
 Check through visual control that the presented measurement data are accompanied by all necessary
information.
 If required to correctly interpret the result, check that its source is identified and indicated by the legally
relevant software.

Examples of an Acceptable Solution:

1. The sensor unit encrypts the measurement data with a key known to the legally relevant software
running on the universal device (e.g., a secret random number). Only the legally relevant module can
decrypt and use the measurement data, not legally relevant modules on the universal device cannot as
they do not know the key. For key treatment see Extension T.
2. Before sending measurement data the sensor initiates a handshake sequence with the legally relevant
software on the universal device based on secret keys. Only if the legally relevant software on the
universal device communicates correctly, the sensor unit sends its measurement data. For key
treatment see Extension T.
3. The secret random number used in solution 1 / 2 is chosen 3. The secret random number used in
and entered to the sensor unit and software on the universal solution 1 / 2 is chosen and entered
device without destroying a seal. to the sensor unit and the software
on the universal device only when a
seal is destroyed.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes C to D):
Source code of the legally relevant software.
Validation Guidance (in addition to the guidance for risk classes C to D):
Checks based on the source code:
 Check that legally relevant software generates the presented measurement data.
 Check whether all measures taken are correct to guarantee the presentation of measurement data by
legally relevant software.

43
WELMEC Guide 7.2: 2023 Software Guide

Extension O: general-purpose operating systems

The specific requirements of this chapter only apply if an operating system on a compo-
nent of a measuring instrument is legally relevant, i.e., the operating system is used to
fulfil the essential requirements of the MID or can be used to affect compliance with
requirements. They are an addition to the specific requirements of software for measur-
ing instruments using a universal device (type U requirements). These requirements do
not have to be applied for measuring instruments type P.

Technical description
Software is described as a general-purpose operating system if system resources of a
measuring instrument (CPU, memory, interfaces) are administrated by that software and
are made available to the legally relevant application. In addition, the operating system
has a multi-user capacity and an administration mode (multi-user operating system).
Any general-purpose operating system evaluated according to this extension shall fulfil
the following prerequisites:
• shall be proven in use,
• shall be suitable for the general purpose,
• shall be state-of-the-art2 and
• must not have been developed by the manufacturer of the measuring instrument,
sub-assembly or producer of the component. However, a manufacturer or pro-
ducer can contribute to the OS with respect to drivers or modules that are specif-
ically programmed for a legally relevant task provided that the requirements of
O6 and O7 are met, i.e., drivers or modules that are specifically programmed for
a legally relevant task shall have their own identification and protection.
In this case, the software examination of the general-purpose operating system can be
reduced to an examination of the legally relevant configuration based on the require-
ments in Extension O.
Each of the implemented protective measures can be combined with measures on hard-
ware level or on the level of the legally relevant application.
Applicability of requirements for components
With respect to off-the-shelf operating systems, this extension distinguishes two cate-
gories of measuring instrument components, see definitions for components of catego-
ries 1 and 2 in Chapter 1.
This chapter only applies to components of a measuring instrument that can be evalu-
ated separately under the conditions specified in WELMEC Guide 8.8. In the case of a
complete instrument the requirements of a category 1 component shall be applied.
For components from category 2:
• O2 does not apply.
• O3, O4 and O5 apply in full.
• O1, O6 and O7 apply to the configuration/settings of the OS.
If this is the case, regular updates to the operating system are possible, as long as they
do not affect the configuration. Technical working groups may decide which components
from category 2 (if any) may be subject to this exception.

2 i.e. patches for all known bugs and vulnerabilities have been applied
44
WELMEC Guide 7.2: 2023 Software Guide

For some operating system types, an update might result in fundamental changes that
also affect the configuration (i.e., a major version upgrade in Windows or in a common
Debian-based Linux distribution). In this case, the aforementioned exception would not
apply.

45
WELMEC Guide 7.2: 2023 Software Guide

Specific requirements for configuration of general-purpose

operating systems
Risk Class C Risk Class D Risk Class E
O1 Hardware protection
The hardware part on which the legally relevant operating system runs, shall be protected against intentional
changes.
Specifying Notes:
1. For category 1 components and complete instruments, the legally relevant operating system shall be
protected against removal or exchange.
2. Hardware interfaces that might influence the operating system shall either be disconnected from power
supply, disabled by the OS, protected by a hardware seal or bound to a protective interface (see O5).
3. Interfaces with direct memory access shall be protected by a hardware seal.
4. The operating system shall use memory protection to prevent retrieval of sensitive cryptographic
material.
Required Documentation: Required Documentation (in addition to the documentation for risk
 A list of all components with an class C):
operating system.  If cryptographic material is used: Description of protective
 Description of the protective measures for volatile memory and storage devices.
measures for mass storages.
 Description of the protective
measures of hardware interfaces.
Validation Guidance:
Checks based on documentation:
 Check that all components with a legally relevant operating system are documented.
 Check that all hardware interfaces are protected or necessary for the legally relevant data exchange in
which case they shall be equipped with a protective interface, see U4.
 Check that all measures for the protection of memory, mass storages and hardware interfaces are
effective and adequate.
Checks based on the configuration files:
 Check that the configuration of the operating system for
memory protection correspond to the documented measures
Functional checks:
 Check that the additional protection measures for legally
relevant operating system and cryptographic material are
effective.
Example of an Acceptable Solution:
 The housing of the measuring instrument is physically protected by seals to prevent exchange of mass
storages or mass storages are fitted with sealed connections during use.
 A hardware seal is applied to ensure the mass storage device, on which the legally relevant OS resides,
cannot be exchanged or removed.
 Cryptographic material, such as passwords, is stored in a
separate hardware component which is protected against
access by the operating system.

46
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O2 Boot process
For category 1 components and complete instruments the configuration of the boot process shall provide
the same configured environment for the execution of legally relevant software.
Specifying Notes:
1. The boot process of the operating system shall be unambiguous and reproducible.
2. The legally relevant software application shall be included in the start-up procedure of the universal
device.
3. The boot configuration shall be protected against modifications.
4. At the end of the boot process, a chain of trust shall be established over the individual components of
the boot process.
5. The processing of the chain of trust may be interrupted if the integrity of the chain of trust is preserved.
6. Booting via open interfaces shall be prohibited.
7. The boot process shall be secured by adequate means,
depending on the level of protection.
Required Documentation:
 Information regarding the boot configuration of the operating system (e.g., mass storage, partitions,
kernel parameters).
 Description of protective measures for the boot process.
 Description of the structure of the chain of trust.
 Description of the booted operating system environment for the legally relevant software.
Validation Guidance:
Checks based on documentation:
 Check that the configuration of the boot process is protected against inadmissible modifications.
 Check that the operating system boots into the same secured environment for the legally relevant
software at each start up.
 Check that there are no undocumented interruptions of the boot process.
 Check the booting via open interfaces is prohibited.
Checks based on the documentation:
 Check if the used cryptographic measures are effective and
correspond to the requirements or recommendations of the
national and international institutions responsible for data
security.
Checks based on the configuration files:
 Check if the configuration of the boot loader is unambiguous.
 Check if it is possible to boot the operating system via open
interfaces.
Example of an Acceptable Solution:
 The boot configuration (BIOS) has been secured by a strong password.
The integrity of the boot loader and of the legally relevant parts of the operating system is checked by
means of a checksum
 A TPM (trusted platform module) verifies the electronic signature of the boot loader, the boot loader
then verifies the operating system, which in turn verifies and starts the legally relevant application.
 Secure boot: Only a signed kernel can be loaded by the boot
loader. Prior to booting of the operating system, the electronic
signature of the kernel is verified.

47
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O3 System resources
The configuration of the operating system shall ensure that there are enough resources for the operation of
the legally relevant application.
Specifying Notes:
1. The operating system should be configured as restrictively as possible.
2. The resources of the legally relevant software application are not reduced below the necessary minimum
by other software (legally relevant and not legally relevant).
Required Documentation:
 Information regarding the configuration of the installed operating system parts.
 Information regarding the running processes during use of the
measuring instrument.
Validation Guidance:
Checks based on documentation:
 Check that the installed operating system parts are appropriate and sufficiently configured to ensure the
operation of the measuring instrument.
Functional checks:
 Check that the export of running processes corresponds to the documentation.
 The manufacturer checks via the system utilization indication whether there are sufficient system
resources for the legally relevant application during use.
Examples of Acceptable Solution:
 By means of the package administration of the operating system, the manufacturer removes all
unnecessary programs.
 The manufacturer limits the runtime for not legally relevant tasks.
 Interrupt hierarchy is designed in a way that avoids adverse influences.

48
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O4 Protection during use
The operating system shall be configured in such a way that the legally relevant software cannot be
inadmissibly influenced by functions of the operating system or by other software.
Specifying Notes:
1. The administration tasks of the legally relevant software (application and operating system) shall be
secured.
2. The access control shall be configured in such way that the intended use cannot be inadmissibly
influenced.
3. The access permissions shall be routinely checked by the legally relevant operating system.
4. The operating system shall be configured to prevent removal of the legally relevant software.
5. The connection of auxiliary devices shall not have an inadmissible influence on the OS, or the
configuration settings.
Required Documentation:
 A list of mounted or mountable storage media with their attributes and policies for limiting their usage.
 Description of the administration of the user access control and protection of the administrator account.
 Description of the operation mode of the GUI.
 Description of the connection of auxiliary devices.
Validation Guidance:
Checks based on documentation:
• Check that the usage of the legally relevant application has been separated from administration of the
system, i.e., the legally relevant application cannot change any legally relevant
administration/configuration of the operating system.
• Check that the securing measures of the administrator account are sufficient and that there is no second
account with inadmissible administrator privileges.
• Check that no inadmissible software can be executed from mounted storage media.
• Check that no inadmissible operating system functions can be called through input devices (e.g.,
keyboard shortcuts) or by the user shell.
• Check that the application control only allows the execution of legally relevant software, unless software
separation has been implemented.
• Check that the connection of auxiliary devices does not inadmissibly affect the legally relevant operating
system or the configuration settings.
• Check that legally relevant settings of the operating system cannot be reset or modified.
Functional checks:
• Check that the administrator account is locked during use.
• Check that all inadmissible keyboard shortcuts have been deactivated.
• Check that exiting or changing the operation mode of the GUI is impossible.
• Check that application control and policies for storage media as well as auxiliary devices are effective.
• Check that the legally relevant settings are retained after a reboot.
Checks based on the configuration files:
Check that
 user and group privileges, administrator account,
 configuration of the application control,
 mounted storage media as well as partitions or media with ac-
cess attributes,
 policies for storage media and auxiliary devices
correspond to the information contained in the documentation and
are correctly configured.

49
WELMEC Guide 7.2: 2023 Software Guide

Example of an Acceptable Solution: Example of an Acceptable Solution:

• All legally relevant tasks are • The operating system possesses a secured administrator
bundled into one dynamically account for the administrative tasks, as well as a user account
linkable library on a PC. with limited privileges for usage during a measurement
• Cryptographic means ensure that operation.
only the legally relevant • The operating system boots at each start up into a kiosk mode
dynamically linkable library can with only the legally relevant application accessible. Keyboard
communicate with the sensor shortcuts have been limited to legally relevant usage.
connected to the PC. • Access to exchangeable media and auxiliary devices has been
• The window displaying the legally restricted by means of group policies
relevant data is generated and • There are no directories with write and execute permissions for
controlled by procedures in the files on the system.
legally relevant dynamically • The administrator account has been permanently deactivated.
linkable library.
• During measurement, these
procedures check cyclically that
the relevant window is still on top
of all the other open windows; if
not, the procedures place it on top
while process prioritization
ensures that other I/O devices do
not permanently block the CPU.

50
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O5 Protective interfaces
Operating system functions accessible via open interfaces shall not inadmissibly influence the legally
relevant software, legally relevant parameters or measurement data.
Specifying Notes:
1. Communication with the legally relevant operating system shall be made via protective interfaces.
2. In case of software separation on an operating system, Extension S and Extension T for open networks
apply for transmission of legally relevant measurement data via protective interfaces of the operating
system.
3. If the operating system configuration ensures that the communication partner connected to an open
interface can only be a certified component and the connection is protected, no further checking of the
interface is needed.
Required Documentation:
 Description of the operating system configuration for open hardware and software interfaces and how
they are protected.
 A list of open hardware and software interfaces not configured by the operating system.
 A list of all accepted commands and their influence for all open interfaces managed by the operating
system.
Validation Guidance:
Checks based on documentation:
 Check that open interfaces have no inadmissible influence on the legally relevant operating system, its
configuration, the legally relevant software application, legally relevant parameters or measurement
data.
Checks based on the configuration files:
It shall be checked that inadmissible influence is prevented for the
following open interfaces:
 network interfaces (open and closed ports, used protocols and
commands, policies)
 serial interfaces (command interpreter of the application,
policies for user account control
 software interfaces of the operating system (access control
used commands
In addition, it shall be checked
 whether the used cryptographic measures are effective and
correspond to the requirements or recommendations of the
national and international institutions responsible for data
security.
Functional checks:
 Check the effectiveness of the configuration of open serial
interfaces.
 Check the effectiveness of the configuration of open network
interfaces.
Example of an Acceptable Solution:
• All hardware interfaces with measurement data exchange are configured via the operating system
(network firewall, USB policies).
 Usage of IT-security protocols (VPN, PISEC) for open
networks.

51
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O6 Identification of the operating system and its configuration
The operating system and configuration of the operating system shall be identifiable. The identification of
the operating system and identification of the configuration of the operating system shall be presented on
command or during operation.
Specifying Notes:
1. If the legally relevant software and the account of the measuring task are protected by a specific
configuration of the operating system, the relevant configuration files shall have an own identifier.
2. Identification shall include modules (kernel modules, drivers, libraries) of the operating system that have
been modified or specifically programmed for a legally relevant task.
Required Documentation:
 General information regarding the operating system (manufacturer, distribution, product name, kernel
version).
 Information regarding the identification of those modules of the operating system configured for the
legally relevant task.
 Information regarding the identification of modified or added self-developed modules of the operating
system for the legally relevant task.
 A list of all used identifiers as well as a description of how they are created, of their indication and how
to distinguish them from not legally relevant identifiers.
Validation Guidance:
Checks based on documentation:
 Check that all identifiers of the legally relevant operating system configuration have been documented.
 Check that all identifiers of modified or added modules have been documented.
 Check that all identifiers of the operating system are unambiguous and that coverage of the legally
relevant modules of the operating system is complete and comprehensible.
 Check that creation, indication and protection of the identifiers as well as their distinguishability from
other not legally relevant identifiers is fully documented and free of contradictions.
Functional checks
• Check the indication of the identifiers of the operating system and compare them with the
documentation.
Example of an Acceptable Solution:
• The identifier consists of the name of the OS producer, the product name, and the version of the
operating system. Alternatively, the name and version of the distribution as well as the version of the
kernel are used.
• In addition, the modules of the operating system configured for the legally relevant task are identified by
means of a checksum.

52
WELMEC Guide 7.2: 2023 Software Guide

Risk Class C Risk Class D Risk Class E

O7 Protection of the operating system
The operating system shall be protected against intentional modifications.
Specifying Notes:
1. Modules of the operating system (kernel modules, drivers, libraries) that are specifically programmed
for a legally relevant task shall have their own protection.
2. The protective measures for the operating system shall cover all legally relevant modules completely.
An exception may be made to include the boot loader configuration in the protective measure instead
of the boot loader itself, if it is not part of the file system of the operating system.
3. If a checksum or an equivalent protective measure are used, they should be calculated by means of the
operating system. The calculated checksum or equivalent protective measure shall be indicated by the
operating system or by a legally relevant application.
4. The integrity of the legally relevant operating system shall be periodically checked. If the integrity check
fails, reactions are necessary that are adequate for the instrument.
5. Updates to the legally relevant modules of the operating system are not addressed by this requirement.
Such updates would fall under Extension D.
6. The checksum shall be obtained with cryptographically strong
methods.
Required Documentation:
 Documentation of the protective measures of the operating system.
 Description of methods for creation and indication of the protection measures
 Exhaustive list of legally relevant modules of the operating system
Validation Guidance:
Checks based on documentation:
 Check that all legally relevant modules of the operating system are adequately covered by the protective
measures.
 Check that creation and indication of the protective measures are fully documented and free of
contradictions.
Functional checks:
 If a checksum has been used: Check the indication of the checksum for the legally relevant modules of
the operating system (see definition for categories 1 and 2) and compare it with the reference values
given in the documentation.
 If alternative measures have been used: Check the prototype and compare it with the documentation.
 Check whether the used cryptographic measures are effective
and correspond to the requirements or recommendations of the
national and international institutions responsible for data
security.
Example of an Acceptable Solution:
 Linux: Checksum covering boot loader, kernel and the directory /etc.
 Windows: Checksum covering parts of the system directory, parts of the exported registry and parts of
the policy settings regarding user privileges, firewall, USB etc.
 The checksum is a CRC32.  The checksum is a SHA-value (secure hashing algorithm) of a
length recommended by ENISA.

53
WELMEC Guide 7.2: 2023 Software Guide

Extension L: storage of measurement data

The specific requirements of this chapter only apply if storage of measurement data is
designed. They are an addition to the specific requirements of embedded software for
measuring instruments using a built-for-purpose device (type P requirements) and of
software for measuring instruments using a universal device (type U requirements).
Storage includes the time from when a measurement is physically completed to the point
in time when all processes to be done by the legally relevant software are finished. It
may also be applied to long-term storage of the measurement result to make this
available after completion of the measurement for later legally relevant purposes.

Technical description
Three different technical configurations for storage are listed in Table 7-1. For a built-
for-purpose device, the variant of an integrated storage is typical: here the storage is
part of the metrologically necessary hardware and software. For instruments using a
universal device, another variant is typical: the use of resources already existing, e.g.,
hard disks. The third variant is the removable storage: here the storage can be removed
from the device, which could be either a built-for-purpose device or a universal device,
to be taken elsewhere. When data is retrieved from removable storage for legal
purposes, e.g., visualisation, ticket printing, etc, the retrieving device shall be subject to
legal control.

A) Integrated storage
Simple instrument, built-for-purpose, no externally usable tools or means available for
editing or changing data, integrated storage for measurement data or parameters, e.g.
RAM, flash memory, hard disk.

B) Storage for universal device

Universal device, graphical user interface, multitasking operating system, tasks subject
to legal control and not subject to legal control exist in parallel, storage can be removed
from the device or contents can be copied anywhere inside or outside the device.

C) Removable or remote (external) storage

Arbitrary basic instrument (built-for-purpose device or universal device), storage can be
taken from the instrument. These can be, for example, USB stick, flash cards, or remote
databases connected via network.

Table 7-1: Technical description of storage devices

The classification may be reduced for selected kinds of measuring instruments on con-
clusion of the responsible WELMEC Working Groups, see Extension I.

54
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements for storage

Risk Class B Risk Class C Risk Class D

L1 Completeness of stored measurement data

The measurement data stored shall be accompanied by all relevant information needed for legally relevant
purposes.

Specifying Notes:
1. The measurement data stored shall be capable of being traced back to the measurement that has
generated the data.
2. The measurement data stored shall be sufficient for checking invoices.
3. The kind of necessary information may depend on the type of instrument.
4. A presupposition to comply with this special requirement is an identification of each measurement data
set stored.

Required Documentation:
Description of all fields of the measurement data sets.

Validation Guidance:
Checks based on documentation:
 Check whether all information needed for legally relevant purposes are contained in the measurement
data set.

Example of an Acceptable Solution:

 A legally and metrologically complete measurement data set comprises the following fields:
º Measured quantity value(s) with correct resolution
º the unit of measure
º the unit price or the price to pay (if applicable)
º the date and time of the measurement (if applicable)
º identifier of the instrument
º the place of the measurement (if applicable)
 Measurement data is stored with the same resolution, values, units, etc. as indicated or printed on a
delivery note.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether the measurement data sets are correctly built.

55
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L2: Securing and protecting stored measurement data

Stored measurement data shall be secured against unintentional and protected against accidental changes.

Specifying Notes:
1. Stored measurement data shall be accompanied by additional redundant information to enable the
software retrieving, evaluating, and indicating or otherwise processing the data to verify that the stored
measurement data has not been changed by physical effects (electromagnetic interference,
temperature, vibration, etc).
2. Means shall be implemented to secure measurement data so it cannot be changed and can only be
deleted under the following conditions:
a. Measurement data that consist of the intermediate measured quantity value, see chapter 14, can’t
be deleted by the user but may be automatically deleted if the next module or component state a
proper completion of expected actions engaged.
b. For measuring instruments other than utility meters, the measurement result can be deleted after
the time that a request can be made to produce a durable proof has been passed. The regulations
concerning the minimum period for storing measurement results are left to national regulations and
therefore beyond the scope of this guide.
c. For utility meters, the total measured quantity shall never be deleted, i.e., these registers shall be
protected by a hardware seal against resetting. For further information see WELMEC Guide 11.1,
11.3 and 13.1.

Required Documentation:
 The method of how the securing against unintentional changes and deletion is realised and how the
retrieving software can verify the integrity of the measurement data.

Validation Guidance:
Checks based on documentation:
 Check that a method is implemented to detect accidental measurement data changes.
 Check that the method captures all measurement data.
 Check that overwriting or deleting measurement data cannot occur if not all conditions are met and in
case of manual deletions only after the security measure has been successfully passed, e.g., a password
is submitted.
Functional checks:
 Practical spot checks to show that measurement results can only be deleted after the conditions are met
and in case of manual deletion that the security measure has been successfully passed, e.g., a password
is submitted.

Example of an Acceptable Solution:

 To detect measurement data changes due to physical effects, a checksum with the CRC-16 algorithm is
calculated over the entire measurement data set and inserted into the measurement data set to be stored.
Note: The algorithm is not secret and, in contrast to requirement L3, neither is the initial vector of the CRC-
register nor the generator polynomial, i.e., the divisor in the algorithm. The initial vector and generator
polynomial are known to both of the modules that create and verify the checksums.
 Measurement result/invoice files are protected by attaching an automatic date stamp on creation and a
flag or label stating whether invoices were paid/unpaid. A utility program would only move/delete files if
invoices had been paid or were out-of-date.
 The measurement result is not deleted without prior authorisation, e.g., a dialogue statement or window
asking for confirmation of deletion and a password.
 Automatic overwriting of the measurement result is allowed if there is adequate protection of the rec-
ords to be retained. A parameter determining the number of days before the measurement result can
be deleted is set and secured when putting into use according to the user’s needs and data storage
size. The instrument stops if the memory is full and all the records are not old enough to be overwritten.
Manual deletion (with prior authorisation and providing a password) is performed in that case.

56
WELMEC Guide 7.2: 2023 Software Guide

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for protecting stored measurement data are correctly implemented.

57
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L3: Protecting stored measurement data

The measurement data stored shall be protected against intentional changes.

Specifying Notes:
1. Stored measurement data in integrated storages in general are protected by hardware means. No extra
software protection is necessary.
2. The protection shall apply against intentional changes carried out by easily available and manageable
software tools.
3. Stored measurement data shall be accompanied by additional redundant information to enable the soft-
ware retrieving, evaluating, and indicating or otherwise processing the data to verify integrity of the
measurement data.
4. The protection shall also apply against intentional
changes carried out by special sophisticated soft-
ware tools.
5. Concerning algorithms and minimum key
lengths, the requirements or recommendations of
the national and international institutions respon-
sible for data security have to be taken into con-
sideration.
6. Even if the algorithm and key meet the level high,
a technical solution with a standard personal
computer would not realise this protection level
provided that there are no appropriate protection
means for the modules that sign or verify a data
set (see basic guide U for universal devices,
comment on requirement U6-Risk Class D).

Required Documentation:
The method of how the protection against inadmissible intentional changes is realised and how the retrieving
software can verify integrity of the measurement data.

Validation Guidance: Validation Guidance (in addition to the guidance for

Checks based on documentation: risk classes B and C):
 If a checksum or electronic signature is used: Checks based on documentation:
 Check that the checksum or electronic  Check whether the measures taken are
signature is generated over the entire appropriate with respect to the required state of
measurement data set. the art for a high protection level.
 check that legally relevant software, which
reads the measurement data and calculates a
checksum or decrypts an electronic signature
compares calculated and nominal values.
 Check that secret data (e.g., key initial value if
used) are kept secret against spying out with
simple tools.

58
WELMEC Guide 7.2: 2023 Software Guide

Example of an Acceptable Solution: Example of an Acceptable Solution:

 The module of the storing device calculates a  The legally relevant storing module generates an
CRC-32 of the dataset and appends it to the electronic signature for the stored dataset. It is
dataset. It uses a secret initial value for this appended to the stored dataset. The private and
calculation. This initial value is employed as a public keys used for signing are generated in a
key and stored as a constant in the executable hardware security module which protects the
code. The reading module has also stored this private key against manipulation or reading and
initial value in its executable code. Before using exports the public key. The reading module
the dataset, the reading module calculates the verifies the electronic signature with the public
checksum and compares it with that stored in the key to check the authenticity and integrity of the
dataset. If both values match, the dataset is not dataset. To prove the origin of the dataset the
falsified. Otherwise, the module assumes reading module needs to know whether the public
falsification and discards the dataset and key really belongs to the storing module.
indicates that the measurement data is Therefore, the public key is presented on the
corrupted. display of the measuring instrument and can be
registered once, e.g., together with the serial
number of the instrument when it is verified in the
field. In case of an irregularity the module
assumes falsification and discards the dataset
and indicates that the measurement data is
corrupted.
Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check whether measures taken for ensuring integrity are correctly implemented.

59
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L4 Traceability of stored measurement data

Stored measurement data shall be capable of being traced back to the measurement and the measuring
instrument that generated them.

Specifying Notes:
1. Traceability requires the correct assignment (linking) of measurement data to the measurement that has
generated the data.
2. Traceability requires the correct assignment (linking) of measurement data to the measuring instrument
that has generated them.
3. Traceability to measurements presupposes an identification of measurements.
4. Traceability to a measuring instrument presupposes an identification of the measuring instrument.

Required Documentation:
 Description of the method used for ensuring the traceability.

Validation Guidance: Validation Guidance (in addition to the

Checks based on documentation: guidance for risk classes B and C):
 Check that there is a correct linking between each Checks based on documentation:
measurement data set and the corresponding measurement.  Check whether the measures taken are
 If a checksum or electronic signature is used, check that the appropriate with respect to the required
checksum or electronic signature is generated over the entire state of the art for a high protection
measurement data set. level.
 Check that secret data (e.g., key initial value if used) are kept
secret against spying out with simple tools.
Functional checks:
 Check whether corresponding stored data and data printed
on the ticket or invoice are identical.
 Check whether the ticket shows a hint that the measurement
data can be compared with the reference data on a means of
storage subject to legal control.

Example of an Acceptable Solution: Example of an acceptable solution:

Stored measurement data contain the following data fields: In addition to the acceptable solution to
 A unique (sequential) identification number and an identi- risk classes B and C, the origin of
fication of the measuring instrument that has generated the cryptographic certificates used for signing
measurement data. An electronic signature that is used for the measurement data is verified by
ensuring the integrity of data can simultaneously be used means of a PKI.
for ensuring the traceability.
 Time when the measurement has been performed (time
stamp) and an identification of the measuring instrument
that has generated the data.
Note: The ticket may state that the measurement data can be
compared with the reference data on a means of storage subject
to legal control. Assignment is demonstrated by comparing the
identification number or time stamp printed on the delivery note
with that in the stored measurement data set.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D ):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check whether the measurement data sets are correctly built and reliably traced back to measuring
instrument and measurement.

60
WELMEC Guide 7.2: 2023 Software Guide

61
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L5: Protecting confidential information

Confidential information shall be protected against changes, kept secret, and be protected against
disclosure.

Specifying Notes:
1. Only the legally relevant software shall have read access to confidential information.
2. The protection means shall ensure that no changes can be made by easily available and manageable
software tools.
3. Depending on the protection means the confidential information may consist of keys, generator
polynoms, initial vectors / start values, seeds, etc.
4. The protection means shall ensure that no
changes can be made out by special
sophisticated software tools.
5. A technical solution with a standard
personal computer would not be sufficient
to ensure high protection level if there were
no appropriate hardware protection means
for the key and other secret data (see basic
guide for universal devices U6).

Required Documentation:
 Description of the management of secret information and means for keeping keys and other information
secret.

Validation Guidance: Validation Guidance (in addition to the

Checks based on documentation: guidance for risk classes B and C):
 Check that the secret information cannot be disclosed. Checks based on documentation:
 Check whether the measures taken are
appropriate with respect to the required
state of the art for a high protection level.

Examples of Acceptable Solutions: Example of an Acceptable Solution:

 The secret key and associated information are stored in The secret key is stored in a hardware part that
binary and encrypted format in the executable code of can be physically sealed. The software does
the legally relevant software. The software does not not offer any features to view or edit these data.
offer any features to view or edit these data, and the
volatile memory is protected by the operating system
configuration to prevent retrieval of sensitive
cryptographic material, see O1.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check whether measures taken for management of secret information are correctly implemented.

62
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L6: Retrieval, verification, and indication of stored measurement data

In case measurement data is used for legally relevant purposes, there shall be a legally relevant component
or module for retrieving, verifying, handling, and indicating stored measurement data.

Specifying Notes:
1. The legally relevant software shall be able to retrieve, verify, handle, and indicate stored measurement
data. For requirements concerning the presentation of measurement data, see P8/U8.
2. Retrieved measurement data shall be verified.
3. In case of an irregularity the measurement data shall not be used for further legally relevant purposes.
They shall be registered as invalid. This register is considered measurement result relevant data.
4. The displayed or printed measurement data shall indicate any irregularity of the measurement data.

Required Documentation:
 Description of the functions of the retrieval software.
 Description how measurement data is verified.
 Description how corrupted measurement data is handled and indicated.

Validation Guidance:
Checks based on documentation:
 Check that the retrieval software has the required capabilities
Functional checks:
 Perform spot checks verifying that retrieval provides all necessary information.

Example of an Acceptable Solution: Example of an Acceptable Solution:

• The legally relevant module of the storing device • The legally relevant storing module generates an
calculates a CRC32 of the dataset and appends electronic signature for the stored dataset. It is
it to the dataset, see L3. It uses a secret initial appended to the stored dataset. The private and
value for this calculation. This initial value is em- public keys used for signing are generated in a
ployed as a key and stored as a constant in the hardware security module which protects the pri-
executable code. The reading module has also vate key against manipulation or reading and ex-
stored this initial value in its executable code. Be- ports the public key. The reading module verifies
fore using the dataset, the reading module calcu- the electronic signature with the public key to
lates the checksum and compares it with that check the authenticity and integrity of the da-
stored in the dataset. If both values match, the taset. To prove the origin of the dataset the read-
dataset is not falsified. Otherwise, the module as- ing module needs to know whether the public key
sumes falsification and discards the dataset, really belongs to the storing module. Therefore,
marks the dataset as corrupt and indicate that the public key is presented on the display of the
the measurement data is corrupted. measuring instrument and can be registered
once, e.g., together with the serial number of the
instrument when it is verified in the field.
• In case of an irregularity the module assumes fal-
sification and discards the dataset and marks the
dataset as corrupted and indicate that the meas-
urement data is corrupted.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for retrieval, verification of electronic signatures etc. are correctly
implemented.

63
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L7: Automatic storing

The measurement data shall be stored automatically when the measurement is concluded.

Specifying Notes:
1. The storing function shall not depend on the decision of the operator.
2. In cases where a decision is required from the operator whether or not to accept a measurement result,
the measurement data shall be stored automatically after making the decision.

Required Documentation:
 Description of automatic storing.
 Description of the graphical user interface in case of operator-dependent storing decisions.

Validation Guidance:
Checks based on documentation:
 Check that the storing process is automatic.
Functional checks:
 Examine by spot checks that the measurement data are stored automatically after measurement or
acceptance of measurement result is concluded. Check that there are no buttons or menu items to
interrupt or disable the automatic storing.

Example of an Acceptable Solution:

There is no menu item or button in the graphical user interface that supports manual initiation of storing
measurement results. The measurement result is wrapped in a measurement data set along with additional
measurement result relevant data such as time stamp and electronic signature and is stored immediately
after the measurement, or the acceptance of measurement result, respectively.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for automatic storing are correctly implemented.

64
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

L8: Storage capacity and continuity

The storage shall have a capacity which is sufficient for the intended purpose.

Specifying Notes:
1. When storage is full or removed or disconnected from the instrument, a warning shall be given to the
operator.
2. It shall be ensured that only outdated measurement data can be overwritten.
3. The regulations concerning the minimum period for storing measurement data and the required
inscriptions are left to national regulations and therefore beyond the scope of this guide.
4. The information on the capacity of the storage shall be made available.

Required Documentation:
 Capacity of storage, Description of the management of storing measurement data.
 Description of the behaviour of the device if storage is full or removed.

Validation Guidance:
Checks based on documentation:
 Check that the capacity of storage or a formula for calculating it, is given.
 Check that overwriting of measurement data cannot occur before the end of the data storage period that
is foreseen and documented by the manufacturer.
Functional checks:
 Check that a warning is given if the storage is full or removed, if applicable.

Example of an Acceptable Solution:

 Interruptible measurements: When the storage becomes unavailable before the measurement is
completed: The measuring instrument has a buffer that is large enough to store the current measurement
data. No new measurement is started, and the buffered data are kept for later transmission to a fresh
storage.
 Uninterruptible measurements: The cumulative register is read out and transmitted to the storage at a
later time, when the storage is available again.
 Measurement data is automatically overwritten by a tool that checks if the measurement data is out-of-
date (refer to national regulations for the relevant time period). The tool prompts the user for permission
to delete and measurement data is deleted in the order oldest first.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for storing are correctly implemented.

65
WELMEC Guide 7.2: 2023 Software Guide

Extension T: transmission of measurement data via

communication networks

The specific requirements of this chapter only apply if measurement data is transmitted
via communication networks to be used for legally relevant purposes. If that is the case,
measurement data shall be transmitted and received by a legally relevant component or
module.
They are an addition to the specific requirements of software for measuring instruments
using a built-for-purpose device (type P requirements) and of software for measuring
instruments using a universal device (type U requirements).
If software is downloaded to a device subject to legal control, then the requirements of
Extension D apply.

Technical description
In the following table two network configurations are identified.
Description of configurations
A) Closed network
Only a fixed number of participants with clear identity, functionality and location are connected. All devices
in the network are subject to legal control.
B) Open network
Arbitrary participants (devices with arbitrary functions) can be connected to the network. The identity and
functionality of a participating device and its location may be unknown to other participants.
Any network that contains legally controlled devices with infrared or wireless network communications
interfaces shall be considered to be an open network.

Table 8-1: Technical description of communication networks.

66
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements for transmission of measurement

data
Risk Class B Risk Class C Risk Class D
T1: Completeness of transmitted measurement data
The transmitted measurement data shall contain all relevant information necessary to present or further
process the measurement data in the receiving unit.

Specifying Notes:
1. The completeness depends individually on the type of measurement.

Required Documentation:
Document all fields of the measurement data set.

Validation Guidance:
Checks based on documentation:
 Check whether all information for further processing the measurement data at the receiving unit are
contained in the measurement data set.

Example of an Acceptable Solution:

The measurement data set comprises the following fields:
 Measured quantity value(s) with correct resolution
 the unit of measure
 the unit price or the price to pay (if applicable)
 the time and date of the measurement (if applicable)
 identifier of the instrument if applicable (data transmission)
 the place of the measurement (if applicable)

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D ):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measurement data sets are built correctly.

67
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T2: Securing and protecting transmitted measurement data

Transmitted measurement data shall be secured against unintentional and protected against accidental
changes.
Specifying Notes:
1. Means shall be implemented to secure transmitted measurement data against unintentional changes and
to detect change or loss of transmitted measurement data.

Required Documentation:
Description of the methods used to secure transmitted measurement data and detect transmission errors or
loss of transmitted measurement data.

Validation Guidance:
Checks based on documentation:
 Check that a method is implemented to secure transmitted measurement data and detect transmission
errors or loss of transmitted measurement data.

Example of an Acceptable Solution:

• Transmitted measurement data is accompanied by additional redundant information to enable the
software of the receiver to detect accidental data transmission errors.
• To detect measurement data changes, a checksum with the CRC-16 algorithm is calculated over all bytes
of a data set and inserted into the data set to be transmitted.
• In case of transmission errors, the receiving module discards the dataset and request that the data is
resend.
Note: The algorithm is not secret and, in contrast to requirement T3, neither is the initial vector of the CRC-register
nor the generator polynomial, i.e., the divisor in the algorithm. The initial vector and generator polynomial are known
to both of the modules that create and verify the checksums.
• Use of means provided by transmission protocols, e.g., TCP/IP, IFSF.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for protecting transmitted measurement data are correctly implemented.

68
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T3: Protecting transmitted measurement data

The transmitted measurement data shall be protected against intentional changes.

Specifying Notes:
1. This requirement only applies to open networks, not to closed networks.
2. The protection shall apply against intentional changes carried out by easily available and manageable
software tools.
3. The protection shall also apply against intentional
changes carried out by special sophisticated
software tools.
4. Concerning algorithms and minimum key lengths,
the requirements or recommendations of the
national and international institutions responsible
for data security have to be taken into
consideration.
5. To meet the high level of protection, appropriate
protection means for the module (e.g., hardware
support) that signs or verifies a data set are
necessary (see also chapter 5 for software on
universal devices, special requirement U6,
specifying note 6 for risk class D).

Required Documentation:
Description of the protection method.

Validation Guidance:
Checks based on documentation:
 Check that an appropriate method has been selected.

Example of an Acceptable Solution: Example of an Acceptable Solution:

 The module of the transmitting device calculates  The legally relevant transmitting module gener-
a CRC-32 of the dataset and appends it to the ates an electronic signature for the transmitted
dataset. It uses a secret initial value for this dataset. It is appended to the transmitted dataset.
calculation. This initial value is employed as a key The private and public keys used for signing are
and stored as a constant in the executable code. generated in a hardware security module which
The receiving module has also stored this initial protects the private key against manipulation or
value in its executable code. Before using the reading and exports the public key. The receiving
dataset, the receiving module calculates the module verifies the electronic signature with the
checksum and compares it with that stored in the public key to check the authenticity and integrity
dataset. If both values match, the dataset is not of the dataset. To prove the integrity and authen-
falsified. Otherwise, the module assumes ticity of the dataset the receiving module needs to
falsification and discards the dataset and request know whether the public key really belongs to the
that the data is resend. transmitting module. Therefore, the public key is
presented on the display of the measuring instru-
ment and can be registered once, e.g., together
with the serial number of the instrument when it is
verified in the field. In case of an irregularity the
receiving module discards the dataset and re-
quest that the data is resend.
Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for guaranteeing integrity of transmitted measurement data are correctly
implemented.

69
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T4: Traceability of transmitted measurement data

Transmitted measurement data to be used for legally relevant purposes shall be capable of being traced
back to the measurement and the legally relevant component or module or measuring instrument that
generated them.

Specifying Notes:
1. This requirement only applies to open networks, not to closed networks.
2. Traceability requires the correct assignment (linking) of measurement data to the measurement that has
generated the data.
3. Traceability requires the correct assignment (linking) of measurement data to the measuring instrument
that has generated them.
4. Traceability to measurements presupposes an identification of measurements.
5. Traceability to a measuring instrument presupposes an identification of the measuring instrument.
6. The protection shall apply against intentional changes carried out by easily available and manageable
software tools.
7. The protection shall also apply against
intentional changes carried out by
special sophisticated software tools.
8. Concerning algorithms and minimum
key lengths, the requirements or
recommendations of the national and
international institutions responsible
for data security have to be taken into
consideration.

Required Documentation:
• Description of the method used for ensuring traceability.

Validation Guidance:
Checks based on documentation:
Check that the method used for ensuring traceability is adequate.

Example of an Acceptable Solution:

 Each measurement data set has a unique (sequential) identification number, containing the date when
the measurement has been performed (time stamp).
 Each measurement data set contains information about the origin of the measurement data, i.e., serial
number or identity of the measuring instrument that generated the data.
 In open networks, traceability to the component or module or measuring instrument is guaranteed if the
measurement data set carries an unambiguous electronic signature. The electronic signature covers all
of these fields of the measurement data set.
 The receiver of the measurement data set checks all data for plausibility.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for guaranteeing the traceability of transmitted measurement data are
correctly implemented.

70
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T5: Protecting confidential information

Confidential information shall be protected against changes, kept secret, and be protected against
disclosure.

Specifying Notes:
1. Only the legally relevant software shall have read access to confidential information.
2. The protection means shall ensure that no changes can be made by easily available and manageable
software tools.
3. Depending on the protection means the confidential information may consist of keys, generator
polynoms, initial vectors / start values, seeds, etc.
4. The protection shall ensure that only the
legally relevant software has read access
and that no changes or modifications can
be made by special sophisticated software
tools.
5. A technical solution with a standard
personal computer would not be sufficient
to ensure high protection level if there were
no appropriate hardware protection means
for the key and other secret data (see basic
guide for universal devices U6).

Required Documentation:
Description of the management of secret information and means for keeping keys and other information
secret and preventing their modification.

Validation Guidance: Validation Guidance (in addition to the

Checks based on documentation: guidance for risk classes B and C):
 Check that the secret information cannot be disclosed or Checks based on documentation:
modified.  Check whether the measures taken are
appropriate with respect to the required
state of the art for a high protection level.

Example of an Acceptable Solution: Example of an Acceptable Solution:

 The secret key and associated information are stored in  The secret key is stored in a hardware part
binary and encrypted format in the executable code of that can be physically sealed. The software
the legally relevant software. The system software does does not offer any features to view or edit
not offer any features to view or edit these data, and the these data.
volatile memory is protected by the operating system
configuration to prevent retrieval of sensitive
cryptographic material. See O1.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of legally relevant software.

Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check whether measures taken for management of confidential information are correctly implemented.

71
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T6: Receiving, verification and handling of transmitted measurement data

In case measurement data is used for legally relevant purposes, there shall be a legally relevant component
or module for receiving, verifying, handling, and indicating transmitted measurement data.

Specifying Notes:
1. The legally relevant software shall be able to receive, verify, handle, and indicate transmitted
measurement data. For requirements concerning the presentation of measurement data, see P8/U8.
2. Received measurement data shall be verified.
3. In case of an irregularity, the measurement data shall not be used for further legally relevant purposes.
The receiving module either discards the dataset and requests that the data is resent or registers
reception of a corrupted dataset. This register is considered measurement result relevant data.
4. The displayed or printed measurement data shall indicate any irregularity of the measurement data.

Required Documentation:
• Description of the functions of the receiving software
• Description how measurement data is verified.
• Description how corrupted measurement data is handled and indicated.

Validation Guidance:
Checks based on documentation:
 Check that corrupted measurement data are not accepted and either replaced with the correct data or
registered accordingly.
Functional checks:
 Check that corrupted measurement data are not accepted and either replaced with the correct data or
registered accordingly.

Example of an Acceptable Solution: Example of an Acceptable Solution:

 The legally relevant module of the sending device calcu-  The legally relevant sending software gen-
lates a CRC32 of the dataset and appends it to the da- erates an electronic signature for the
taset, see T2 and T3. It uses a secret initial value for this transmitted dataset. It is appended to the
calculation. This initial value is employed as a key and transmitted dataset, see T2 and T3. The
stored as a constant in the executable code. The receiv- receiving module verifies the electronic
ing module has also stored this initial value in its execut- signature with the public key to check the
able code. Before using the dataset, the receiving mod- authenticity and integrity of the dataset. To
ule calculates the checksum and compares it with that prove the origin of the dataset the receiv-
stored in the dataset. If both values match, the dataset ing module needs to know whether the
is not falsified. Otherwise, the module assumes falsifica- public key really belongs to the sending
tion and discards the dataset and request that the data module. Therefore, the public key is pre-
is resent. sented on the display of the measuring in-
strument and can be registered once, e.g.,
together with the serial number of the in-
strument when it is verified in the field. In
case of an irregularity the receiving mod-
ule discards the dataset and request that
the data is resent.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for handling corrupted measurement data are correctly implemented.

72
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

T7: Transmission delay

The measurement shall not be inadmissibly influenced by a transmission delay.

Specifying Notes:
1. The timing of the data transmission shall be organised so that under worst case conditions the
measurement is not inadmissibly influenced.

Required Documentation:
Description of the concept, how measurement is protected against transmission delay.

Validation Guidance:
 Check the concept that the measurement is not influenced by transmission delay.

Example of an Acceptable Solution:

Implementation of transmission protocols for field buses.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B, C and D ):
Source code of legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B, C and D):
Checks based on the source code:
 Check whether measures taken for handling transmission delay are correctly implemented.

Risk Class B Risk Class C Risk Class D

T8: Availability of transmission services

If network services become unavailable, no measurement data shall get lost.
Specifying Notes:
1. It shall not be possible to corrupt measurement data by delaying or suppressing transmission.
2. The sending device shall be able to handle transmission disturbances accidentally happening.
3. The reaction of the measuring instrument if transmission services become unavailable depends on the
measuring principle (see Extension I).

Required Documentation:
Description of protection measures against transmission interruption or other failures.

Validation Guidance:
Checks based on documentation:
 Check the measures taken to protect measurement data from transmission disturbances and interruption.
Functional checks:
 Spot checks shall show that no measurement data is lost due to a transmission interruption.

Example of an Acceptable Solution:

1) Interruptible measurements: The measurement is completed even though the transmission is down.
However, the measuring instrument or the device that is sending the measurement data has a buffer
that is large enough to store the current measurement. After this no new measurement is started and
the buffered data are kept for later transmission. For other examples see part I.
2) Uninterruptible measurements: The cumulative register is read out and transmitted at a later time when
the connection is up again.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

73
WELMEC Guide 7.2: 2023 Software Guide

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for reacting on interrupted transmission services are correctly
implemented.

74
WELMEC Guide 7.2: 2023 Software Guide

Extension S: software separation

Software separation is an optional design method that allows to separate legally
relevant software from not legally relevant software. The communication between
these parts of software is carried out via controlled interfaces. If following the conditions
for software separation, the manufacturer need not to pass conformity assessment
procedures when changing not legally relevant software.
The specific requirements of this extension, if applicable, shall be considered in
addition to the basic requirements of types P or type U instruments, respectively,
described in Chapters 4 and 5 of this guide.
Technical description
Software-controlled measuring instruments or systems in general have complex
functionality and contain modules that are legally relevant and modules that are not. It
is advantageous – though it is not prescribed – to separate these types of modules.

75
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements for software separation

Risk Class B Risk Class C Risk Class D

S1: Realisation of software separation

There shall be a part of the software that contains all legally relevant software and parameters that is
clearly separated from other parts of software.

Specifying Notes:
1. The protective interface itself (see S3) is legally relevant.
2. With regard to the determination whether or not software, parameters or data is legally relevant, see
chapter 15.

Required Documentation:
Naming of all modules that belong to the legally relevant software.

Validation Guidance:
Checks based on documentation:
 Check that the naming is correct and the list of named modules is complete.

Example of an Acceptable Solution:

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check (e.g. by data flow analysis with tools or manually) that all modules that are involved in
processing the measurement data are registered as legally relevant software.

76
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

S2: Mixed indication

The legally relevant indication shall be generated by the legally relevant software and shall be clearly
distinguishable from the not legally relevant indication.

Specifying Notes:
1. The legally relevant indication shall be protected against influence from the not legally relevant soft-
ware, see S1.
2. The legally relevant software shall generate the legally relevant indication and shall only give the not
legally relevant software access to the measurement data after the measurement result has been
indicated.
3. The legally relevant indication shall be indicated in such a way that it is clear that this is the legally
relevant indication.
4. The legally relevant indication shall be visible as soon as the measurement starts and until the meas-
urement result is shown. Thus, the user can check if the indication contains the necessary measure-
ment data, e.g., unit price. See O8 for additional guidance in case of an operating system.

Required Documentation:
 Naming of the modules which realise presentation of legally relevant measurement data.
 Description how it is prevented that not legally relevant software has access to the measurement data
prior to indication of the measurement result.
 Description how the legally relevant indication is distinguishable from the not legally relevant
indication.

Validation Guidance:
Checks based on documentation:
 Check that the not legally relevant software has no access to the measurement data prior to indication.
Functional checks:
 Judge through visual checks that legally relevant indications are clearly distinguishable from the not
legally relevant indication.
Example of An Acceptable Solution:
 The legally relevant indication is presented in a dedicated part of the display that is under control of
the legally relevant software. The technical measures required of the application are:
a. No access to measurement data is given to not legally relevant modules until the measurement
data have been indicated.
b. The application is refreshed periodically. The associated module checks that the application is
visible as long as the measurement is not concluded. Processing of measurement data stops
whenever this application is closed or not completely visible.
 The legally relevant indication is presented in a window that is under control of the legally relevant
software. The window is always on top. See Extension O4.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check that legally relevant software generates the indication of measurement data.
 Check whether the realised implementation of mixed indication is correct.
 Check that this indication cannot be changed or suppressed by not legally relevant modules.

77
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

S3: Protective interface

The interaction and data exchange between the legally relevant and not legally relevant software shall
be exclusively carried out via a protective interface that is under full control of the legally relevant
software.

Specifying Notes:
1. This requirement applies to all kinds of interactions and data exchanges between the legally relevant
and not legally relevant software.
2. All communication shall exclusively be carried out via the defined protective interface.
3. There shall be only those interactions and data flows allowed that do not inadmissibly influence the
measuring process, in particular the legally relevant software, device-specific parameters and meas-
urement data.
4. Scheduling and runtime of the measuring process shall not be influenced by not legally relevant
software.
5. In case of software separation on a legally relevant operating system, see also O4.
6. The protective interface between legally relevant and not legally relevant software shall be as small
as possible, not containing any unnecessary functionality. It shall be under full control of the legally
relevant software.

Required Documentation: Description of the protective interface

 Description of the protective interface including description of allowed interactions and data flows.

Validation Guidance:
Checks based on documentation:
 Check that functions of the legally relevant software and actions of the measuring process, that may
be triggered via the protective interface are defined and described.
 Check that data that may be exchanged via the protective interface are defined and described.
 Undertake plausibility checks that the description of interactions and data exchanges is complete.

Example of an Acceptable Solution:

 The not legally relevant software is encapsulated in a library for calculation of not legally relevant data.
Thus, the legally relevant software has full control over all interactions with the not legally relevant
software. Each call from the legally relevant software to the library including the transmitted data are
documented. No data transmission has an inadmissible influence on the legally relevant software.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check the software design whether data flow is unambiguously defined in the legally relevant
software and can be verified.
 Check the data flow via the protective interface by using appropriate tools or manually. Check
whether the complete data flow between the modules has been documented. Search for inadmissible
data flow.
 Check that interactions triggered by the not legally relevant software are documented. Search for
inadmissible interactions.

78
WELMEC Guide 7.2: 2023 Software Guide

Extension D: download of legally relevant software

This extension shall be used if instruments are equipped with facilities for a software
download without breaking a seal. The specific requirements of this extension, if
applicable, are to be considered in addition to the basic requirements of types P or
type U instruments, respectively, described in Chapters 4 and 5 of this guide.
This guide does not impose any prescriptions whether a software download to
instruments in use without breaking a seal is allowed or not. However, if a download
without breaking a seal is allowed, then the specific requirements laid down below shall
be considered.
Technical description
The scope of configurations, which are in principle suitable for a software download is
large. It is described in the following table.

Hardware configuration
The instrument with facilities for a software download may be a measuring instrument
using a built-for-purpose device (type P) or an instrument with a universal device (type
U). Communications links for the software transmission may be direct, e.g. RS 232,
USB, over closed networks, e.g. Ethernet, token-ring LAN, or over open networks, e.g.
Internet.

Software configuration
The entire software to be downloaded may be legally relevant or there may be a
separation between legally relevant and not legally relevant software. In the latter case,
only the download of legally relevant software is subject to the requirements laid down
below. Download of not legally relevant software is allowed without any restrictions,
provided the software separation has been certified.

Table 10-1: Technical description of configurations for automatic software download.

The software download consists of two (logical) phases: (1) The transmission process
to the measuring instrument and (2) the installation of the software transmitted.

79
WELMEC Guide 7.2: 2023 Software Guide

Specific Software Requirements

Risk Class B Risk Class C Risk Class D

D1: Download mechanism

Both phases of the software download, the transmission and the subsequent installation of software, shall
run automatically and not affect the protection of legally relevant software.

Specifying Notes:
1. The instrument shall be equipped with legally relevant software that carries out the checking functions
required in D2 to D4.
2. The instrument shall be capable of detecting if the transmission of software or the subsequent
installation fails. A warning shall be given. If the transmission or the installation is unsuccessful or has
been interrupted, then the original status of the measuring instrument shall be unaffected.
Alternatively, the instrument shall display a permanent error message and its metrological functioning
shall be inhibited until the significant defect has been cleared.
3. On successful completion of the installation, all protective means shall be activated.
4. During transmission and subsequent installation of software, the measurement process shall be
inhibited, or correct measurement shall be appropriately guaranteed.
5. The number of retries of transmissions and installation attempts shall be reasonably limited.

Required Documentation:
The documentation shall describe how the conditions given in the specifying notes are implemented.

Validation Guidance:
Check that the conditions given in the specifying notes are fulfilled.
Functional checks:
 Perform at least one software download to check its correct process.

Example of an Acceptable Solution:

An auxiliary module resident in the legally relevant software that:
a. Handshakes with the sender and checks for consent
b. Automatically inhibits measurement during transmission and installation
c. Automatically transmits the legally relevant software to a secure holding area
d. Automatically carries out the checks required by D2 to D4
e. Automatically installs the software into the correct location
f. Takes care of housekeeping, e.g., deletes redundant files, etc.
g. Ensures that any protection removed to facilitate transmission and installation is automatically
replaced to the required level on completion.
h. Initiates the appropriate fault handling procedures if a significant defect occurs.

For member states where software download for instruments in use is not allowed, it shall be possible to
disable the software download mechanism by means of a sealable setting (switch, secured parameter).
In this case it must not be possible to download legally relevant software without breaking the seal.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for managing the download process are correctly implemented.

80
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

D2: Authentication of transmitted software

Means shall be employed to guarantee that the transmitted software is authentic.

Specifying Notes:
1. Before the transmitted software is installed, it shall be checked that:
a. The software is authentic, i.e., it originates from the manufacturer of the device.
b. The software belongs to the measuring instrument on which it shall be installed.
2. A negative check result shall be considered as failure of transmission and treated as laid down in D1.
3. Concerning algorithms and minimum key
lengths, the requirements or recommendations
of the national and international institutions re-
sponsible for data security have to be taken into
consideration.

Required Documentation:
The documentation shall describe how the checks mentioned in the specifying notes are carried out.

Validation Guidance:
Checks based on documentation:
 Check that the described checks are appropriate
Functional checks:
 Check that installation of not authentic or not to the instrument belonging software is inhibited.

Example of an Acceptable Solution:

1.a Authenticity: For integrity reasons (see D3) an electronic signature is generated over the software
to be downloaded. Authenticity is guaranteed if a key stored in the legally relevant software of the
instrument confirms that the electronic signature originates from the manufacturer of the device. Signature
matching is done automatically. The key can only be exchanged by breaking a seal.
1.b Correct type of measuring instrument: Checking the instrument type requires automatically
matching an identification of instrument type that is stored in the legally relevant software of the instrument
with a compatibility list attached to the software.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures are taken for checking the conditions laid down in the specifying notes.

81
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

D3: Protecting downloaded software

Downloaded software shall be protected against intentional changes.

Specifying Notes:
1. Before the transmitted software is installed, it shall be checked that the software has not been changed
during transmission.
2. A negative check result shall be considered as failure of transmission and treated as laid down in D1.
3. Concerning algorithms and minimum key
lengths, the requirements or recommendations
of the national and international institutions
responsible for data security have to be taken
into consideration.

Required Documentation:
The documentation shall describe how the checks are carried out.

Validation Guidance:
Checks based on documentation:
 Check that the described check is appropriate.
Functional checks:
 Check that installation of changed software is inhibited.

Example of an Acceptable Solution: Example of an Acceptable Solution:

 Integrity is demonstrated by calculating a  SHA with RSA is used as a signature
checksum over the legally relevant software and algorithm. The key for decrypting is stored in
comparing it against the checksum attached to the legally relevant software and cannot be
the software. exchanged or read out without breaking a seal.
 Acceptable algorithm: CRC, secret initial vector,
length 32 bit. The initial vector is stored in the
legally relevant module.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk classes B to D):
Checks based on the source code:
 Check whether measures taken for checking the integrity are correctly implemented.

82
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

D4: Traceability of legally relevant software download

It shall be guaranteed by appropriate technical means that downloads of legally relevant software are
adequately traceable within the instrument for subsequent controls.

Specifying Notes:
1. All relevant data making a download or a download attempt traceable shall be recorded and protected.
Relevant data includes date and time of download, identifier(s) of software, origin of transmission,
success note.
2. The data recorded shall be available for an adequate period of time (the period depends on regulations
outside MID).
3. The recorded data shall be presented on demand.
4. The traceability means and records are part of the legally relevant software and shall be protected as
such.

Required Documentation:
The documentation shall describe:
 how the traceability means are implemented and protected,
 the structure of records,
 how the recorded data may be presented

Validation Guidance: Validation Guidance (in addition to the

Checks based on documentation: guidance for risk classes B and C):
 Check that implemented traceability means fulfil the Checks based on documentation:
conditions laid down in the specifying notes.  Check whether the measures taken are
Functional checks: appropriate with respect to the required
 Check the functionality of the means while carrying out a state of the art for a high protection
software download. level.

Example of an Acceptable Solution:

 Audit trail. The measuring instrument is equipped with an audit trail that automatically records at least
the date and time of the download, identifier of the downloaded legally relevant software, the identifier
of the sending party, and an entry of the success. An entry is generated for each download attempt
regardless of the success.
 After having reached the limit of the audit trail, it is ensured by technical means that further downloads
are impossible. Audit trail may only be erased by breaking a seal and may be resealed only by the
inspection authorities.

Additions for Risk Class E

Required Documentation (in addition to the documentation required for risk classes B to D):
Source code of the legally relevant software.

Validation Guidance (in addition to the guidance for risk class D):
Checks based on the source code:
 Check whether measures taken for tracing the download process are correctly implemented.
 Check whether measures taken for protecting the recorded data are correctly implemented.

83
WELMEC Guide 7.2: 2023 Software Guide

Extension I: instrument-specific software requirements

This extension is intended to complement the general software requirements of the
previous chapters and cannot be considered isolated from parts P or U and the other
extensions (see Chapter 2). It reflects the existence of instrument-specific MID
annexes MI-x and contains specific aspects and requirements for measuring
instruments or systems (or sub-assemblies). These requirements do not, however, go
beyond the requirements of the MID. If reference is made to OIML recommendations
or ISO/IEC standards this is done only if these can be considered as normative
documents in the sense of the MID and if this supports a harmonised interpretation of
the MID requirements.
Besides instrument-specific software aspects and requirements Extension I contains
the instrument (or category) specific assignment of risk classes which ensures a
harmonised level of software examination, software protection and software
conformity.
For the present, Extension I is intended to be an initial draft to be completed by the
respective WELMEC Working Group that has the corresponding specific knowledge.
Therefore, Extension I has an "open structure", i.e., it provides a skeleton that is -
besides the initial assignment of risk classes - filled-in only partly (e.g., for utility meters
and automatic weighing instruments). It may be used for other MID (or non-MID)
instruments, too, according to the experiences gained and decisions taken by the
responsible WELMEC Working Groups.
Structure
There are different instrument-specific software aspects that might need consideration
for a certain type of measuring instrument. These aspects should be treated in a
systematic manner as follows: Each instrument-specific sub-chapter should be
subdivided into the following categories.

Specific regulations, standards and other normative documents

Here, instrument (or category) specific regulations, standards and other normative
documents (e.g., OIML recommendations) or WELMEC guidelines should be
mentioned that may help to develop instrument (or category) specific software
requirements as an interpretation of the requirements of the MID Annex I and its
specific annexes.
Normally, the specific software requirements apply in addition to the general ones in
the previous chapters. Otherwise, it should be clearly stated whether a specific
software requirement replaces one (or more) of the general software requirements, or
whether one (or more) general software requirements is (are) not applicable, and the
reason why.

84
WELMEC Guide 7.2: 2023 Software Guide

Technical description
Here
- examples of most common specific technical configurations,
- the application of parts P, U and extensions to these examples, and
- useful (instrument-specific) checklists for both the manufacturer and the
examiner
may be given. The description should mention
- the measuring principle (cumulative measurement or single independent
measurement; repeatable or non-repeatable measurement; static or
dynamic measurement), and
- the fault detection and reaction; two cases are possible:
a) the presence of a defect is obvious or can simply be checked or there are
hardware means for fault detection,
b) the presence of a defect is not obvious and cannot be easily checked and
there are no hardware means for fault detection.
In the latter case (b) fault detection and reaction requires appropriate
software means and hence appropriate software requirements.
- the hardware configuration; at least the following issues should be
addressed:
a) Is there a modular, general-purpose computer-based system or a dedicated
instrument with an embedded system subject to legal control?
b) Does the computer system stand-alone, or is it part of a closed network,
e.g., Ethernet, token-ring LAN, or part of an open network, e.g., Internet?
c) Is the sensor separated (separate housing and separate power supply) from
the type U system or is it partly or completely integrated into it?
d) Is the user interface always under legal control (both for type P and type U
instruments) or can it be switched to an operating mode which is not under
legal control?
e) Is long-term data storage foreseen? If yes, then is the storage local (e.g.,
hard disk) or remote (e.g., file server)?
f) Is the storage medium fixed (e.g., internal ROM) or removable (e.g., floppy
disc, CD-RW, smart-media card, memory stick)?
- the software configuration and environment; at least the following issues
should be addressed:
a) Which operating system is used or can be used?
b) Do other software applications reside on the system besides the legally
relevant software?
c) Is there software not subject to legal control that is intended to be freely
modified after approval?

Specific software requirements

Here, the specific software requirements should be listed and commented using a
similar form as in the previous chapters.

85
WELMEC Guide 7.2: 2023 Software Guide

Examples of legally relevant parameters, functions, and data

Here, examples of
- device-specific parameters (e.g., individual configuration and calibration
parameters of a specific measuring instrument),
- type-specific parameters (e.g., specific parameters that are fixed at type
examination), or
- legally relevant, specific functions
may be given.

Other aspects
Here, other aspects, e.g., specific documentation required for type (software)
examination, specific descriptions, and instructions to be supplied in type examination
certificates, or other aspects (e.g., requirements concerning the testability) may be
mentioned.

Assignment of risk class

Here, the appropriate risk class for instruments of the respective type should be
defined. This can be done
- either generally (for all categories within the respective type), or
- depending on the field of application, or category, or other aspects if these
exist.

86
WELMEC Guide 7.2: 2023 Software Guide

Water Meters
Specific regulations, standards and other normative documents
Member states may – in accordance with MID Article 2 – prescribe Water meters in
residential, commercial and light industrial use to be subject to the regulations in the
MID. The specific requirements of this chapter are based on Annex III (MI-001) of the
MID only.

Technical description

Hardware Configuration
The water meter is an instrument intended to measure continuously, memorize, and
display the volume of water passing through the measurement transducer at metering
conditions. A water meter includes at least a measurement transducer, a calculator
(including adjustment or correction devices, if present) and an indicating device. These
three devices can be in different housings.
Note: Volume means in sense of accumulated amounts of volume over a time period.

Software Configuration
This is specific to each manufacturer but would normally be expected to follow the
recommendations given in the main body of this guide.

Measuring Principle
Water meters continually cumulate the volume consumed. The cumulative volume is
displayed at the instrument. Various principles are employed.
The volume measurement typically cannot be repeated.

Fault Detection and Reaction

The requirement Annex III (MI-001), 7.1.2 deals with electromagnetic disturbances.
There is a need to interpret this requirement for software-controlled instruments
because detection of a disturbance and recovery is only possible by co-operation of
specific hardware components and specific modules. From the software point of view,
it makes no difference what the reason for a disturbance was (electromagnetic,
electrical, mechanical etc): the recovery procedures are all the same.
“After undergoing an electromagnetic disturbance, the water meter shall:
• recover to operate within MPE, and

• have all measurement functions safeguarded, and

• allow recovery of all measurement data present just before the disturb-
ance” (see ISO 4064-1:2014 A3, A5 and OIML R 49:2013-1 A3, A5)

87
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements

Risk Class B Risk Class C Risk Class D
I1-1: Fault Recovery
The software shall recover from a disturbance to normal processing.

Specifying Notes:
Date stamped flags should be raised to help logging of periods of faulty operation.
Required Documentation:
 A brief description of the fault recovery mechanisms and an explanation of how and when it is in-
voked.
 A brief description of the related tests carried out by the manufacturer.
 A brief description of SW recovery mechanism steps after an error (from the manufacturer of the
meter), if this is required for SW validation.
Validation Guidance:
Checks based on documentation:
 Check whether the realisation of fault recovery is appropriate.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
A hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to inhibit the
firing of the watchdog. If any function has not been processed or – in the worst case – the microprocessor
hangs in an arbitrary endless loop, the reset of the watchdog does not happen, and it fires after a certain
time span.

Risk Class B Risk Class C Risk Class D

I1-2: Not legally Relevant Software and Dynamic Behaviour
The not legally relevant software shall not adversely influence the dynamic behaviour of a measuring
process.

Specifying Notes:
This requirement ensures that for real time applications of meters the dynamic behaviour of the legally
relevant software is not inadmissibly influenced by not legally relevant software, i.e. the resources of the
legally relevant software are not inadmissibly reduced by the non-legal part.
Required Documentation:
 Description of the interrupt hierarchy.
 Timing diagram of the software tasks. Limits of proportionate runtime for not legally relevant tasks.
Validation Guidance:
Checks based on documentation:
 Documentation covering limits of the proportionate runtime for not legally relevant tasks is available
for the programmer of the not legally relevant software part.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The interrupt hierarchy is designed in a way that avoids adverse influences.

88
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

3
I1-3: Additional Functionality
Additional functionality, for example prepayment or interval metering 4, should not influence the legally
relevant measurement functions as specified by MID Annex III Water meters (MI-001).

Specifying Notes:
Additional functionality is allowed provided it does not influence the legally relevant measurement
functions as specified by MID, Annex III Water meters (MI-001).
Required Documentation:
See S1 to S3.
Validation Guidance:
See S1 to S3.
Example of an Acceptable Solution:
See S1 to S3.

Risk Class B Risk Class C Risk Class D

I1-4: Back-up Facilities
There may be a facility that provides for periodic back-up of measurement data, such as measurement
values and the current status of the process. This data shall be stored in a non-volatile storage.

Specifying Notes:
If the back-up facility is used for fault recovery, the minimum interval for the back-up shall be calculated
to ensure the critical change value is not exceeded.

Required Documentation:
• A brief description of which data is backed up and when this occurs.
• Calculation of the minimum interval for the back-up to ensure that the critical change value is not
exceeded.
Validation Guidance:
Checks based on documentation:
 Check whether measurement data is saved to non-volatile storage and can be recovered.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
Measurement data is backed up as required.

3 The manufacturer should always take into account the national requirements concerning additional functionality.
4
With respect to interval metering additional guidance is given in WELMEC Guide 13.3.
89
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I1-5: Software Download
During installation of the software, the measurement process should be inhibited for no longer than one
minute in total.
In case that the installation of the software takes more than one minute, extra measures needs to be
taken (e.g. installation takes place at low water consumption).

Specifying Notes:
 This requirement applies in addition to D1, D2, D3 and D4 if software download has been realized.
 The additional requirement ensures that for real time applications of the meter measurements are
not interrupted for too long.
Required Documentation:
See D1, D2, D3 and D4.
Validation Guidance:
See D1, D2, D3 and D4.
Example of an Acceptable Solution:
See D1, D2, D3 and D4.

Risk Class B Risk Class C Risk Class D

I1-6: MID-Annex I, 8.5 Inhibit Resetting of Cumulative Measurement Data
For utility measuring instruments the display of the total quantity supplied or the displays from which the
total quantity supplied can be derived, whole or partial reference to which is the basis for payment, shall
not be able to be reset during use.
Specifying Notes:
 Cumulative registers of a measuring instrument shall be reset prior to applicable conformity as-
sessment procedure. During a conformity assessment procedure according to annex D, F or H1
the water meters shall be fitted with all securing and protective means as specified by the TEC
after which resetting of the cumulative measurement data shall not be possible without evidence
of an intervention.
 Totalizers of the cumulative registers of a measuring instrument shall be reset before the relevant
conformity assessment procedure is completed. During the conformity assessment procedure
according to Annex D, F or H1, the water meters shall be equipped with all the safety provisions
set out in the TEC, that shall ensure evidence of an intervention into the meter registers after
resetting the cumulative measurement data.
Cumulative registers are not allowed to be reset during use in distribution network.
NB: specified in ISO 4064 under 6.8.2. - Electronic sealing devices
Required Documentation:
Documentation of protection means against resetting the volume registers.
Validation Guidance:
Checks based on documentation:
 Check that the reset operation of the cumulative legally relevant measurement data is secured
and that the protective means foreseen shall provide for evidence of an intervention.
Functional checks:
 Confirm correct functioning of the protective means foreseen, see also P3/U3 and P4/U4.
Example of an Acceptable Solution:
The register for the total measured quantity has to be protected by a hardware seal. Other registers, for
example day or night tariff register, may be protected by the same means as parameters (see P7/U7)
provided that a total (overall cumulative) register is available which is protected by a hardware seal. For
further information see WELMEC Guide 11.1/13 and ISO 4064 article 6.8.2. – electronic sealing

90
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I1-7: MID Annex I, article 10.5 Reading of Measurement Results
The measurement results that serve as the basis for the price to pay may be the results of different
registers, which are activated by remote control, a clock or other means. Each register represents the
total quantity, connected to one rate in the billing process. It should be possible to show the results on
different displays, periodically or on request via the user interface.
Specifying Notes:
 Cumulative registers or totalised registers of the water meter may be reset prior to applicable
conformity assessment procedure. During a conformity assessment procedure according to an-
nex D, F or H1 the utility meters shall be fitted with all protective means as specified by the TEC
by the manufacturer after which resetting of the cumulative measurement data shall not be pos-
sible without evidence of an intervention, see I1-6.
 When the maximum indicating range of the volume totalization is reached, the indicating range
will continue measuring starting from zero cubic meter, see also I1-9 (Number of Digits).
Required Documentation:
Documentation of how the measurement results are obtained that serves as the basis for the price to
pay.
Validation Guidance:
Checks based on documentation:
 Check the correct handling of the measurement results.
Functional checks:
 Confirm correct functioning of the handling of the measurement results.
Example of an Acceptable Solution:
If a meter is designed to count the quantities defined in MID (MI-001) in different registers a meter shall
be able to display the total quantities of each register on the display by means of the user interface (see
P3/U3, e.g.: buttons on instruments) as well as the currently active rate register. It is allowed to show the
results on different displays, periodically or on request via the user interface. However, when displaying
different measurement results it shall be clear which display belongs to which register, there shall be no
ambiguity in that respect.
If needed, additional inscriptions can be provided on the water meter, clarifying the different registers or
indication of test mode (see I1-9).

91
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I1-8: Protection against Intentional Changes for water meters type P (with mechanical register)
The calculated checksum or an alternative indication to support detection of software modification shall
be made visible on command for control purposes, see P6. As an exception for water meters of type P
with a mechanical counter, an imprint of the checksum or an alternative indication of software modifica-
tion on the name plate of an instrument shall be an acceptable solution if the following conditions A, B
and C are fulfilled:
A. The user interface does not have any control capability to activate the indication of the value of the
checksum or an alternative indication of software modification on the display or the display does not
allow technically showing these values (mechanical counter).
B. The instrument does not have any interface to communicate the software identifier.
C. After production of a meter a change of the software is not possible or only possible if also the hard-
ware or a hardware component that contains the software is changed.
Specifying Notes:
 The manufacturer of hardware or relevant hardware component is responsible that the checksum
or an alternative indication of software modification is correctly marked on the concerned hard-
ware.
 All other Specifying Notes of P6 apply.
Required Documentation:
According to P6.
Validation Guidance:
Checks based on documentation:
 According to P6.
Functional checks:
 According to P6.
Example of an Acceptable Solution:
Imprint of the checksum or an alternative indication of software modification on the name plate of the
instrument.

92
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I1-9: Number of Digits
The display of total quantity shall have sufficient numbers of digits. According to ISO 4064, part 1 the
number of digits displayed are based on permanent flow Q3:
Permanent flow Q3 Minimum range of indi-
[m3/h] cation [m3]
Q3 ≤ 6,3 9 999
6,3 < Q3 ≤ 63 99 999
63 < Q3 ≤ 630 999 999
630 < Q3 ≤ 6300 9 999 999
Also, according to ISO 4064 part 1 the resolution of the indicating device shall fulfil the following require-
ment:
 The subdivisions of the verification scale shall be small enough to ensure that the resolution error of
the indicating device does not exceed 0,25 % for accuracy class 1 meters, and 0,5 % for accuracy
class 2 meters, of the volume passed during 90 min at the minimum flow rate Q1.
 Additional verification elements may be used provided that the uncertainty of reading is not greater
than 0,25 % of the test volume for accuracy class 1 meters and 0,5 % of the test volume for accuracy
class 2 meters and that the correct functioning of the register is checked.
Suitability according to clause 7.6 and 10.5 of Annex I of Directive 2014/32/EU (MID):
A measuring instrument shall be designed so as to allow the control of the measuring tasks after the
instrument has been placed on the market and put into use. If necessary, special equipment or software
for this control shall be part of the instrument.
Also, for a measuring instrument with remotely read it shall in any case be fitted with a metrologically
controlled display accessible without tools to the consumer.
When the maximum indicating range of the volume totalization is reached, the indicating range will con-
tinue measuring starting from zero cubic meter.
Specifying Notes:
According to ISO 4064 part 1:
 The indicating device of a water meter shall provide an easily read, reliable, and unambiguous visual
indication of the indicated volume. A combination meter may have two indicating devices, the sum
of which provides the indicated volume.
 Every indicating device shall provide means for visual, non-ambiguous verification testing and cali-
bration.
 The visual verification display may have either a continuous or a discontinuous movement.
Required Documentation:
 A description of the display and display menu.
 A description of the visual verification display and an explanation on how to initiate visual verification
display.
Validation Guidance:
Functional checks:
 Check if the display of total quantity have a sufficient numbers of digits.
 Initiate the visual verification display and
 check if the resolution of the visual verification display fulfils the requirements
 check if special equipment or software for this control is part of the instrument (if relevant).
Example of an Acceptable Solution:
There are on the water meter sufficient number of digits on the display which fulfil both the requirements
of the total quantity with the required resolution.
Switching display modes on the indicating device for showing the values for the total quantity with the
correct resolution and the "test mode" with additional verification elements. These display modes shall be
possible to be displayed by means of:
 the user interface (See P3/U3, e.g.: buttons on instruments) or
 by cycling through the different display modes.
However, it should by clear what the primary display is when using different display modes, it shall be
clear how to read these values and there shall be no ambiguity in that respect to the other display modes
(See I1-7).
Note: It is not in line with the essential requirements of the Directive 2014/32/EU (MID) according to article
7.6, Annex I, that a verification organisation, inspection body or Notified Body has to ask the manufacturer
for the special equipment or the software.

93
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I1-10: Display Test
For verifying the correct function of all segments of the display, a display test shall be possible to be
executed.
Specifying Notes:
The display test is according to ISO 4064:
 The meter shall provide visual checking of the entire display which shall have the following se-
quence:
1) for seven segment type displaying all the elements (e.g. an “eights” test);
2) for seven segment type blanking all the elements (a “blanks” test);
3) for graphical displays an equivalent test to demonstrate that display faults cannot result in
any digit being misinterpreted.
 Each step of the sequence shall last at least 1 s.
Required Documentation:
A description of the display test and an explanation on how to initiate such a test.
Validation Guidance:
Initiate the display test and check if visual checking of the entire display is possible.
Example of an Acceptable Solution:
A display test is initiated after a special command by the user interface (See P3/U3, e.g.: buttons on
instruments) or is part of the cycling procedure that shows the different display modes.

Examples of legally relevant parameters, functions, and data

Access to means for modification of software, settings and/or parameters that influence
the determination of the results of measurements shall be secured5.

Parameter Protected Settable Comment

Calibration factor x
Linearisation factor x
Legally relevant configu- x
ration of registers
Settings for example: x
 Correction devices
 Curve fitting
Other relevant parame- x
ters that can or might in-
fluence the measure-
ment result
Software download of x
the legally relevant soft-
ware

Assignment of risk class

The following risk class is considered appropriate and should be applied if software
examinations based on this guide are carried out for (software-controlled) water meter:
– Risk class C for instruments of type P

5. With respect to securing a water meter additional guidance is given in WELMEC Guide 13.3.

94
WELMEC Guide 7.2: 2023 Software Guide

Gas Meters and Volume Conversion Devices

Specific regulations, standards, normative documents and other WEL-
MEC guides.
The specific requirements of this chapter are based on MID, Annex IV Gas meters and
Volume Conversion Devices (MI-002).
With respect to securing gas meters and volume conversion devices guidance can also
be found in WELMEC Guide 11.3.
Specific guidance in relation to the gas chromatograph connected as a live sensor to
an EVCD can be found in WELMEC Guide 11.1.
Additional guidance or updates on specific guidance for Gas Meters and Volume Con-
version Devices is found on the WELMEC website.
National legislation concerning additional functionality, OIML recommendations, (EN)
harmonized standards and (IEC) standards have not been taken into consideration.

Technical description

Hardware Configuration
Gas meter and conversion devices are usually separate hardware components.
Indicators or calculators of Gas meters and of volume conversion devices may have
one or more interfaces to connect external sensor units.
In case a gas chromatograph is connected as a live sensor to an EVCD, the GC influ-
ences the measuring result (base volume) of the EVCD and should therefore be a part
of the Conformity Assessment Procedure.

Software Configuration
This is specific to each type of meter but would normally be expected to follow the
recommendations given in the main body of this guide.

Measuring Principle
Gas meters continually cumulate the volume or mass flowed through the meter. A vol-
ume conversion device may be used to calculate the volume at base conditions.
The volume measurement is a non-repeatable measurement.

Fault Detection and Reaction

The requirement in MID, Annex IV Gas meters and Volume Conversion Devices (MI-
002), article 3.1 deals with the permissible effect of disturbances. From the software
point of view, it makes no difference what the reason for a disturbance was (electro-
magnetic, electrical, mechanical, etcetera): the recovery procedures are all the same.
• After undergoing a disturbance, the gas meter shall:
• recover to operate within MPE, and

• have all measurement functions safeguarded, and

• allow recovery of all measurement data present just before the disturb-
ance.

See article 3.1.2 of the MID, Annex IV Gas meters and Volume Conversion De-
vices (MI-002).

95
WELMEC Guide 7.2: 2023 Software Guide

• An electronic conversion device shall be capable of detecting when it is oper-

ating outside the operating range(s) stated by the manufacturer for parameters
that are relevant for measurement accuracy. In such a case, the conversion
device must stop integrating the converted quantity, and may totalise sepa-
rately the converted quantity for the time it is operating outside the operating
range(s).
See article 9.1 of the MID, Annex IV Gas meters and Volume Conversion De-
vices (MI-002).

Specific software requirements

Gas meters and volume converters

Risk Class B Risk Class C Risk Class D
I2-1: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002) article 3.1, Fault Re-
covery
The software shall recover from a disturbance to normal processing.
Specifying Notes:
Date stamped flags should be raised to help logging of periods of faulty operation.
Required Documentation:
A brief description of the fault recovery mechanisms and an explanation of how and when it is invoked.
Validation Guidance:
Checks based on documentation:
 Check whether the realisation of fault recovery is appropriate.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an Acceptable Solution:
The hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to inhibit
the firing of the watchdog.

Risk Class B Risk Class C Risk Class D

I2-2: Not Legally Relevant Software and Dynamic Behaviour
The not legally relevant software shall not adversely influence the dynamic behaviour of a measuring
process.
Specifying Notes:
This requirement ensures that for real time applications of meters the dynamic behaviour of the legally
relevant software is not inadmissibly influenced by not legally relevant software, i.e., the resources of
the legally relevant software are not inadmissibly reduced by the non-legal part.
Required Documentation:
 Description of the interrupt hierarchy.
 Timing diagram of the software tasks. Limits of proportionate runtime for not legally relevant tasks.
Validation Guidance:
Checks based on documentation:
 Documentation covering limits of the proportionate runtime for not legally relevant tasks is
available for the programmer of the not legally relevant software part.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The interrupt hierarchy is designed in a way that avoids adverse influences.

96
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I2-3: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002), article 3.1.2 Back-up
Facilities
There may be a facility that provides for periodic back-up of measurement data, such as measurement
values and the current status of the process. This data shall be stored in a non-volatile storage.
Specifying Notes:
If the back-up facility is used for fault recovery, the minimum interval for the back-up shall be
calculated to ensure the critical change value is not exceeded.
Required Documentation:
A brief description of what data is backed up and when this occurs.
Calculation of the minimum interval for the back-up to ensure that the critical change value is not ex-
ceeded.
Validation Guidance:
Checks based on documentation:
 Check whether measurement data is saved to non-volatile storage and can be recovered.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an Acceptable Solution:
Measurement data is backed up as required.

Risk Class B Risk Class C Risk Class D

6
I2-4: Additional Functionality
Additional functionality, for example prepayment or interval metering 7, should not influence the legally
relevant measurement functions as specified by MID, Annex IV Gas and Volume Conversion Devices
Meters (MI-002).
Specifying Notes:
 Additional functionality is allowed provided it does not influence the legally relevant
measurement functions as specified by MID, Annex IV Gas Meters and Volume Conversion
Devices (MI-002).
Required Documentation:
See S1 to S3.
Validation Guidance:
See S1 to S3.
Example of an Acceptable Solution:
See S1 to S3.

6 The manufacturer should always take into account the national requirements concerning additional functionality.
7
With respect to interval metering additional guidance is given in WELMEC Guide 11.2.
97
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I2-5: Software Download
During installation of the software, the measurement process should not be suspended longer than one
minute in total.
In case that the installation of the software takes more than one minute, extra measures needs to be
taken (e.g. installation takes place at low flow rate).
Specifying Notes:
 This requirement applies in addition to D1, D2, D3 and D4 if software download has been realised.
 The additional requirement ensures that for real time applications of the meter measurements
are not interrupted for too long.
Required Documentation:
See D1.
Validation Guidance:
See D1.
Example of an Acceptable Solution:
See D1.

Risk Class B Risk Class C Risk Class D

I2-6: MID-Annex I, article 8.5 (Inhibit Resetting of Cumulative Measurement Data)
For utility measuring instruments the display of the total quantity supplied or the displays from which
the total quantity supplied can be derived, whole or partial reference to which is the basis for payment,
shall not be able to be reset during use.
Specifying Notes:
During a conformity assessment procedure according to annex D, F or H1 the utility meters shall be
fitted with all securing and protective means as specified by the TEC by the manufacturer after which
resetting of the cumulative measurement data shall not be possible without evidence of an
intervention.
For gas meters the register for the total measured volume has to be protected by hardware
metrological seals.
For conversion devices the volume at base conditions has to be protected by hardware metrological
seals.
Required Documentation:
Documentation of protection means against resetting the volume registers.
Validation Guidance:
Checks based on documentation:
 Check that the reset operation of the cumulative legally relevant measurement data is secured
and that the protective means foreseen shall provide evidence of an intervention.
Functional checks:
 Confirm correct functioning of the protective means foreseen.
Example of an Acceptable Solution:
For gas meters the register for the total measured volume has to be protected by hardware metrological
seals. Other registers, for example day or night tariff register, may be protected by the same means as
parameters (see P7/U7) provided that a total (overall cumulative) register is available which is protected
by a hardware seal. See WELMEC Guide 11.1 and 11.3 for additional guidance.
For conversion devices the volume at base conditions has to be protected by hardware metrological
seals. The register showing the volume at measurement conditions can also be protected by the same
means as parameters (see P7/U7).
Note: The volume at measurement conditions may be synchronized with the indication of the connected
gas meter. Depending on national legislation additional actions have to be taken e.g. re-verifications of
a measuring instrument.

98
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I2-7: MID-Annex I, article 10.5 (Reading of Measurement Results)
A. The measurement results that serve as the basis for the price to pay may be the results of dif-
ferent registers, which are activated by remote control, a clock or other means. Each register
represents the total quantity, connected to one rate in the billing process. The meter should
show the results of each register periodically or on request via the user interface

Specifying Notes:
Cumulative registers of a measuring instrument may be reset prior to applicable conformity
assessment procedure. During a conformity assessment procedure according to annex D, F or H1
the utility meters shall be fitted with all Protective means as specified by the TEC by the manufacturer
after which resetting of the cumulative measurement data shall not be possible without evidence of
an intervention.
Required Documentation:
Documentation of how the measurement results are obtained that serves as the basis for the price to
pay.
Validation Guidance:
Checks based on documentation:
 Check the correct handling of the measurement results.
Functional checks:
 Confirm correct functioning of the handling of the measurement results.
Example of an Acceptable Solution:
If a meter is designed to count the quantities defined in MID, Annex IV Gas meters and Volume Con-
version Devices (MI-002) in different registers the meter shall be able to display the total quantities of
each register on the display by means of the user interface (see this guide, for instance buttons on the
instrument) as well as the currently active rate register.
An acceptable solution is also to show the results of the different register in different displays, periodi-
cally or on request via the user interface. However, when displaying different measurement results it
shall be clear which display belong to which register, there shall be no ambiguity in that respect.

99
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I2-8: Protection against Intentional Changes for Gas Meters of Type P with a Mechanical Counter
The calculated checksum or an alternative indication to support the detection of software modification
shall be made visible on command for control purposes, see P6, Risk Class C.
As an exception for gas meters and volume converters type P with a mechanical counter, an imprint of
the checksum or an alternative indication of software modification on the name plate of an instrument
shall be an acceptable solution if the following conditions A, B and C are fulfilled:
A. The user interface does not have any control capability to activate the indication of the value of
the checksum or an alternative indication of software modification on the display or the display
does not allow technically showing the identifier of the software (mechanical counter).
B. The instrument does not have any interface to communicate the software identifier.
C. After production of a meter a change of the software is not possible or only possible if also the
hardware or a hardware component that contains the software is changed.
Specifying Notes:
 The manufacturer is responsible that the checksum or an alternative indication of software
modification is correctly marked on the concerned hardware.
 All other Specifying Notes of P6 apply.
Required Documentation:
According to P6.
Validation Guidance:
Checks based on documentation:
 According to P6.
Functional checks:
 According to P6.
Example of an Acceptable Solution:
Imprint of the checksum or an alternative indication of software modification on the name plate of the
instrument.

Risk Class B Risk Class C Risk Class D

I2-9: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002), article 5.3 Number of
Digits (Gas meter and Electronic conversion device)
The display of the total quantity shall have a sufficient number of digits to ensure that when the meter
is operated for 8000 hours at Qmax, the indication does not return to its initial value.
Specifying Notes:

Required Documentation:
Documentation of the internal representation of the register.
Validation Guidance:
Checks based on documentation:
 Check that there is sufficient number of numerals that after the volume passed during 8.000 h of
flow at Qmax, the index has not pass to its initial value.
Example of an Acceptable Solution:
Typical values for domestic gas meters are: Qmax = 6 m3/h. The required range is then 48000 m3 requiring
5 digits to fit (currently mechanical and electronic gas meters display up to 99999 m 3 which is more than
adequate for this size of meter).

100
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I2-10: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002), article 5.2 Power
Source Lifetime
A dedicated power source shall have a lifetime of at least five years. After 90% of its lifetime an ap-
propriate warning shall be shown.
Specifying Notes:
Lifetime is used here in the sense of available energy capacity.
If the power source can be changed in the field, parameters and measurement data shall not be cor-
rupted during the changeover.
Additional warnings before the 90% threshold is reached, is allowed provided that these warnings are
not confusing.
Required Documentation:
Documentation of the power source capacity, maximum lifetime (independent of energy consump-
tion), measures to determine the consumed or available energy, description of the means for the
warning of low available energy and of the battery exchange process.
Validation Guidance:
Checks based on documentation:
Check whether the measures taken are appropriate for the surveillance of the energy available.
Example of an Acceptable Solution:
The operating hours or the wake-up signals of the device are counted, stored in a non-volatile
memory and compared with the nominal value of the battery lifetime. If 90% of the lifetime has
elapsed an appropriate warning is shown. The software detects the exchange of the power source
and resets the counter.

Another solution would be to monitor the health of the power supply continuously.

A warning is considered as appropriate in case of a visible warning like a message on the display or a
warning indication.
In addition, an electronic interface may provide the warning to the network / meter operator.
A hidden, “silent” warning (via the electronic interface) to the network / meter operator only is not a
sufficient solution.

Gas meters
Risk Class B Risk Class C Risk Class D
I2-11: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002), article 5.5 Test Ele-
ment of the Gas Meter
The gas meter shall have a test element, which shall enable tests to be carried out in a reasonable
time.
Specifying Notes:
The test element for accelerating time consuming test procedures is normally used for testing before
installation and normal operation.
During the test mode the same registers and software parts shall be used as during standard operat-
ing mode.
Required Documentation:
Documentation of the test element and instructions for activating the test mode.
Validation Guidance:
Checks based on documentation:
Check whether all time consuming test procedures of the gas meter can be completed by means of
the test element.
Example of an Acceptable Solution:
For test purposes the increment of the test element or pulse shall occur at least every 60 seconds at
Qmin, see WELMEC Guide 11.1, paragraph 2.4.4.

The time base of the internal clock can be accelerated. Processes that last e.g. a week, a month or
even a year and overrun of registers may be tested in the test mode within a time span of minutes or
hours.

101
WELMEC Guide 7.2: 2023 Software Guide

Electronic conversion device

Risk Class B Risk Class C Risk Class D
I2-12: MID, Annex IV Gas meters and Volume Conversion Devices (MI-002), article 9.1 (Elec-
tronic Conversion Device)
An electronic conversion device shall be capable of detecting when it is outside the specific field of
measurement stated by the manufacturer, for parameters that are relevant for measurement accu-
racy. In such a case, the conversion device shall stop integrating the converted quantity, and may to-
talise separately the converted quantity for the time it is operating outside the operating range(s).
Specifying Notes:
There shall be a display indication of the failure state.

Required Documentation:
Documentation of the different registers for converted quantity and failure quantity.
Validation Guidance:
Checks based on documentation:
• Check whether the measures taken are appropriate for the management of unusual operating
conditions.
Example of an Acceptable Solution:
The software monitors the relevant input values and compares them with predefined limits. If all val-
ues are inside the limits the converted quantity is integrated to the normal register (a dedicated varia-
ble). Else it totalizes the quantity in another variable.

Another solution would be to have only one cumulating register but to record the start and end date,
time and register values of the out-of-range period in an audit trail (see P7).
Both quantities can be indicated. The user can clearly identify and distinguish the regular and the fail-
ure indication by means of a status indication.

Risk Class B Risk Class C Risk Class D

I2-13: Recalculation of the Conversion Factor

In electronic gas volume conversion devices, the conversion factor shall be recalculated at intervals
not exceeding 1 min for a temperature conversion device and at intervals not exceeding 30 s for other
types of gas volume conversion devices.

However, when no volume signal has been received from the gas meter for:

- over 1 min for a temperature conversion device; or

- over 30 s for other types;

recalculation is not required until next volume signal is received.

Specifying Notes:

Required Documentation:
Documentation of the recalculating sequence.

Validation Guidance:
Checks based on documentation:
Check whether the measures taken are appropriate.

Example of an Acceptable Solution:

102
WELMEC Guide 7.2: 2023 Software Guide

Examples of legally relevant parameters, functions and data

Access to means for modification of legally relevant software, settings and/or parame-
ters that influence the determination of the results of measurements shall be secured8.
For Gas meters for example but not limited to:
Parameter Protected Settable Comment
Calibration factor X
Linearization factor X
Legally relevant configuration of registers X
Settings of for example X
• correction devices
• curve fitting
• pulse number
• minimum flow rate cut off
• setting of ultrasonic sensors
• transducers geometry in ultrasonic gas meters
Other relevant parameters that can or might influence the X
measurement result
Software download of the legally relevant software X

For Conversion devices for example but not limited to:

Parameter Protected Settable Comment
Calibration factor X
Linearization factor X
Legally relevant configuration of registers X
Setting of for example: X
• Legally relevant parameters of a correction de-
vice, such as parameters based on the error
curve of a gas meter
• Pulse value of a gas meter
• Gas composition and parameters for compressi-
bility calculation
Other relevant parameters that can or might influence the x
measurement result
Software download of the legally relevant software x

Assignment of risk class

The following risk class is considered appropriate and should be applied if software
examinations based on this guide are carried out for (software-controlled) gas meters
and volume conversion devices:

– Risk class C for instruments of type P and U.

8 The manufacturer should always take into account the national requirements concerning additional functionality.
With respect to interval metering additional guidance is given in WELMEC Guide 11.2.
103
WELMEC Guide 7.2: 2023 Software Guide

Active Electrical Energy Meters

Specific requirements, standards and other normative documents
The specific requirements of this chapter are based on MID, Annex V Active Electrical
Energy Meters (MI-003).
With respect to securing Active Electrical Energy Meters guidance can also be found
in WELMEC Guide 11.3.
Additional guidance or updates on specific guidance for Active Electrical Energy Me-
ters is found on the WELMEC website.
National legislation concerning additional functionality, OIML recommendations, (EN)
harmonized standards and (IEC) standards have not been taken into consideration.

Technical description

Hardware Configuration
Active electrical energy meters take voltages and currents measurements as inputs,
derive the active electrical power from them, and integrate this with respect to time to
give the energy consumed.
Active electrical energy meters may be used in combination with external instrument
transformers.

Software Configuration
This is specific to each type of meter but would normally be expected to follow the
recommendations given in the main body of this guide.

Measuring Principle
Active electrical energy meters continuously cumulate the energy consumed in a cir-
cuit. The cumulative consumed energy value is displayed by the instrument.
The measurement is a non-repeatable measurement.

Fault Detection and Reaction

The requirement in MID, Annex V Active Electrical Energy Meters (MI-003), article
4.3.1, deals with the permissible effect of disturbances. From the software point of
view, it makes no difference what the reason for a disturbance was (electromagnetic,
electrical, mechanical etc.) the recovery procedures are all the same.
• After undergoing a disturbance, the meter shall:
• recover to operate within MPE, and

• have all measurement functions safeguarded, and

• allow recovery of all measurement data present just before the disturbance and

• not indicate a change in the registered energy of more than the critical change value.

104
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements

Risk Class B Risk Class C Risk Class D
I3-1: MID, Annex V Active Electrical Energy Meters (MI-003), article 4.3.1 Fault Recovery
The software shall recover from a disturbance to normal processing.

Specifying Notes:
Date stamped flags should be raised to help logging of periods of faulty operation.
Required Documentation:
A brief description of the fault recovery mechanisms and an explanation of how and when it is invoked.
And a brief description of the related tests carried out by the manufacturer.
Validation Guidance:
Checks based on documentation:
 Check whether the realisation of fault recovery is appropriate.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an Acceptable Solution:
The hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to inhibit
the firing of the watchdog.
If any function has not been processed or - in the worst case - the microprocessor hangs in an arbitrary
endless loop, the reset of the watchdog does not happen in which case the watchdog fires after a certain
time span and resets the microprocessor.

Risk Class B Risk Class C Risk Class D

I3-2: Not legally Relevant Software and Dynamic Behaviour
The not legally relevant software shall not adversely influence the dynamic behaviour of a measuring
process.
Specifying Notes:
This requirement ensures that for real time applications of meters the dynamic behaviour of the legally
relevant software is not inadmissibly influenced by not legally relevant software, i.e., the resources of
the legally relevant software are not inadmissibly reduced by the non-legal part.
Required Documentation:
 Description of the interrupt hierarchy.
 Timing diagram of the software tasks. Limits of proportionate runtime for not legally relevant tasks.
Validation Guidance:
Checks based on documentation:
 Documentation covering limits of the proportionate runtime for not legally relevant tasks is available
for the programmer of the not legally relevant software part.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The interrupt hierarchy is designed in a way that avoids adverse influences.

105
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I3-3: Additional Functionality9
Additional functionality, for example prepayment or interval metering 10, should not influence the legally
relevant measurement functions as specified by MID, Annex V Annex Active Electrical Energy Meters
(MI-003), .
Specifying Notes:
 Additional functionality is allowed provided it does not influence the legally relevant
measurement functions as specified by MID, Annex V Active Electrical Energy Meters (MI-
003).
Required Documentation:
See S1 to S3.
Validation Guidance:
See S1 to S3.
Example of an Acceptable Solution:
See S1 to S3.

Risk Class B Risk Class C Risk Class D

I3-4: MID, Annex V Active Electrical Energy Meters (MI-003), article 4.3.1 Back-up Facilities
There may be a facility that provides for periodic back-up of measurement data, such as measurement
values and the current status of the process. This data shall be stored in a non-volatile storage.
Specifying Notes:
If the back-up facility is used for fault recovery, the minimum interval for the back-up shall be
calculated to ensure the critical change value is not exceeded.
Required Documentation:
A brief description of what data is backed up and when this occurs.
Calculation of the minimum interval for the back-up to ensure that the critical change value is not ex-
ceeded.
Validation Guidance:
Checks based on documentation:
 Check whether measurement data is saved to non-volatile storage and can be recovered.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an Acceptable Solution:
Measurement data is backed up as required.

9 The manufacturer should always take into account the national requirements concerning additional functionality.
10
With respect to interval metering additional guidance is given in WELMEC Guide 11.2.
106
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I3-5: Software Download
During installation of the software, the measurement process should be inhibited for no longer than one
minute in total.
In case that the installation of the software takes more than one minute, extra measures needs to be
taken (e.g. installation takes place at low energy consumption).
Specifying Notes:
 This requirement applies in addition to D1, D2, D3 and D4 if software download has been realised.
 The additional requirement ensures that for real time applications of the meter measurements
are not interrupted for too long.
Required Documentation:
See D1.
Validation Guidance:
See D1.
Example of an Acceptable Solution:
See D1.

Risk Class B Risk Class C Risk Class D

I3-6: MID-Annex I, 8.5 Inhibit Resetting of Cumulative Measurement Data
For utility measuring instruments the display of the total quantity supplied or the displays from which
the total quantity supplied can be derived, whole or partial reference to which is the basis for payment,
shall not be able to be reset during use.
Specifying Notes:
Cumulative registers of a measuring instrument shall be reset prior to applicable conformity
assessment procedure. During a conformity assessment procedure according to annex D, F or H1
the utility meters shall be fitted with all securing and protective means as specified by the TEC by the
manufacturer after which resetting of the cumulative measurement data shall not be possible without
evidence of an intervention.
Required Documentation:
Documentation of protection means against resetting the energy registers.
Validation Guidance:
Checks based on documentation:
 Check that the reset operation of the cumulative legally relevant measurement data is secured and
that the protective means foreseen shall provide for evidence of an intervention.
Functional checks:
 Confirm correct functioning of the protective means foreseen, see also P3/U3 and P4/U4.
Example of an Acceptable Solution:
The register for the total measured quantity has to be protected by a hardware seal. Other registers, for
example day or night tariff register, may be protected by the same means as parameters (see P7/U7)
provided that a total (overall cumulative) register is available which is protected by a hardware seal. See
WELMEC Guide 11.1 for additional guidance.

107
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I3-7: MID-Annex I, article 10.5 Reading of Measurement Results
The measurement results that serve as the basis for the price to pay may be the results of different
registers, which are activated by remote control, a clock or other means. Each register represents the
total quantity, connected to one rate in the billing process. It should be possible to show the results on
different displays, periodically or on request via the user interface.
Specifying Notes:
Cumulative registers of a measuring instrument may be reset prior to applicable conformity
assessment procedure. During a conformity assessment procedure according to annex D, F or H1
the utility meters shall be fitted with all securing and protective means as specified by the TEC by the
manufacturer after which resetting of the cumulative measurement data shall not be possible without
evidence of an intervention.
Required Documentation:
Documentation of how the measurement results are obtained that serves as the basis for the price to
pay.
Validation Guidance:
Checks based on documentation:
 Check the correct handling of the measurement results.
Functional checks:
 Confirm correct functioning of the handling of the measurement results.
Example of an Acceptable Solution:
If a meter is designed to count the quantities defined in MID, Annex V Active Electrical Energy Meters
(MI-003) in different registers (a) the meter shall be able to display the total quantities of each register
on the display by means of the user interface (see this guide, for instance buttons on the instrument) as
well as the currently active rate register. It is allowed to show the results on different displays, periodically
or on request via the user interface. However, when displaying different measurement results it shall be
clear which display belongs to which register, there shall be no ambiguity in that respect.

108
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I3-8: Protection against Intentional Changes for Active Electrical Energy Meters of Type P with
a Mechanical Counter

The calculated checksum or an alternative indication to support detection of software modification shall
be made visible on command for control purposes, see P6. As an exception for active electrical energy
meters of type P with a mechanical counter, an imprint of the checksum or an alternative indication of
software modification on the name plate of an instrument shall be an acceptable solution if the following
conditions A, B and C are fulfilled:
A. The user interface does not have any control capability to activate the indication of the value of
the checksum or an alternative indication of software modification on the display or the display
does not allow technically showing these values (mechanical counter).
B. The instrument does not have any interface to communicate the software identifier.
C. After production of a meter a change of the software is not possible or only possible if also the
hardware or a hardware component that contains the software is changed.
Specifying Notes:
 The manufacturer is responsible that the checksum or an alternative indication of software
modification is correctly marked on the concerned hardware.
 All other Specifying Notes of P6 apply.
Required Documentation:
According to P6.
Validation Guidance:
Checks based on documentation:
 According to P6.
Functional checks:
 According to P6.
Example of an Acceptable Solution:
Imprint of the checksum or an alternative indication of software modification on the name plate of the
instrument.

Risk Class B Risk Class C Risk Class D

I3-9: MID, Annex V Active Electrical Energy Meters (MI-003), article 5.2 Number of Digits
The display of the total quantity shall have a sufficient number of digits to ensure that when the meter
is operated for 4000 hours at full load (I=Imax, U=Un and PF=1) the indication does not return to its initial
value.
Specifying Notes:

Required Documentation:
Documentation of the internal representation of the electrical energy register and auxiliary quantities.
Validation Guidance:
Checks based on documentation:
Check whether the number of digits is sufficient (internal and on display)
Example of an Acceptable Solution:
Typical values for three phase electricity meters are: Emax (4000h) = 3*60 A * 230 V * 4.000h / 1.000 =
165600 kWh. This requires a presentation of at least 6 digits.

109
WELMEC Guide 7.2: 2023 Software Guide

Examples of legally relevant parameters, functions and data

Access to means for modification of software, settings and/or parameters that influence
the determination of the results of measurements shall be secured11.
Parameter Protected Settable Comment
Calibration factor x
Linearization factor x
Legally relevant configuration of registers x
Settings of for example x
• Legally relevant parameters of a correction de-
vices, such as parameters based on curve fitting
of an active electrical energy meter
• transformer ratio
Other relevant parameters that can or might influence the x
measurement result
Software download of the legally relevant software x

Assignment of risk class

The following risk class is considered appropriate and should be applied if software
examinations based on this guide are carried out for (software-controlled) active elec-
trical energy meter:

– Risk class C for instruments of type P and U.

11 The manufacturer should always take into account the national requirements concerning additional functionality.
With respect to interval metering additional guidance is given in WELMEC Guide 11.2.

110
WELMEC Guide 7.2: 2023 Software Guide

Thermal Energy Meters

Specific regulations, standards and other normative documents
Member states may – in accordance with MID Article 2 – prescribe Thermal energy
meters in residential, commercial and light industrial use to be subject to regulations in
the MID. The specific requirements of this chapter are based on Annex VI (MI-004) of
the MID only.

Technical description

Hardware Configuration
The thermal energy meters are instruments for measuring thermal energy transferred
by the heat-transfer medium. A thermal energy meter is either a complete instrument
or a combined instrument consisting of the sub-assemblies (modular approach) e.g.:
flow sensor, temperature sensor pair, and calculator, as defined in MID Article 4(b). A
thermal energy meter can be a combination both. Separate assemblies of thermal
energy meters, which has evaluation unit (contain software) shall be to the subject of
the validation process also.

Software Configuration
This is specific to each manufacturer but would normally be expected to follow the
recommendations given in the main body of this guide.

Measuring Principle
Thermal energy meters continually cumulate the energy consumed in a heating circuit.
The cumulated thermal energy is displayed at the instrument. Various principles are
employed. The energy measurement may not be repeated.

Fault Detection and Reaction

The requirement VI (MI-004), 4.1 and 4.2 deal with electromagnetic disturbances.
There is a need to interpret these requirements for software-controlled instruments
because detection of a disturbance and recovery is only possible by co-operation of
specific hardware parts and specific software. From the software point of view, it makes
no difference what the reason for a disturbance was (electromagnetic, electrical,
mechanical etc): the recovery procedures are all the same.
“After undergoing an electromagnetic disturbance, the thermal energy meter shall:
• recover to operate within MPE, and
• have all measurement functions safeguarded, and
• allow recovery of all measurement data present just before the disturbance”
(see EN 1434-4:2015 chapter 7)

111
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements

Risk Class B Risk Class C Risk Class D
I4-1: Fault Recovery
The software shall recover from a disturbance to normal processing.

Specifying Notes:
Date stamped flags should be raised to help logging of periods of faulty operation.
Required Documentation:
 A brief description of the fault recovery mechanisms and an explanation of how and when it is
invoked.
 A brief description of the related tests carried out by the manufacturer.
Validation Guidance:
Checks based on documentation:
 Check whether the realisation of fault recovery is appropriate.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to inhibit
the firing of the watchdog. If any function has not been processed or - in the worst case - the micropro-
cessor hangs in an arbitrary endless loop, the reset of the watchdog does not happen in which case the
watchdog fires after a certain time span and resets the microprocessor.

Risk Class B Risk Class C Risk Class D

I4-2: Not legally Relevant Software and Dynamic Behavior
There shall be a facility that provides for periodic back-up of measurement data, such as measurement
values and the current status of the process. This data shall be stored in a non-volatile storage.

Specifying Notes:
This requirement ensures that for real time applications of meters the dynamic behavior of the legally
relevant software is not inadmissibly influenced by not legally relevant software, i.e. the resources of
the legally relevant software are not inadmissibly reduced by the non-legal part.
Required Documentation:
 Description of the interrupt hierarchy.
 Timing diagram of the software tasks. Limits of proportionate runtime for not legally relevant tasks.
Validation Guidance:
Checks based on documentation:
 Documentation covering limits of the proportionate runtime for not legally relevant tasks is available
for the programmer of the not legally relevant software part.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The interrupt hierarchy is designed in a way that avoids adverse influences.

112
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

12
I4-3: Additional Functionality
Additional functionality, for example prepayment or interval metering 13, should not influence the legally
relevant measurement functions as specified by MID, Annex VI Annex Thermal energy meters (MI-
004).
Specifying Notes:
Additional functionality is allowed provided it does not influence the legally relevant measurement
functions as specified by MID, Annex VI Annex Thermal energy meters (MI-004).
Required Documentation:
See S1 to S3.
Validation Guidance:
See S1 to S3.
Example of an Acceptable Solution:
See S1 to S3.

Risk Class B Risk Class C Risk Class D

I4-4: Back-up Facilities
There may be a facility that provides for periodic back-up of measurement data, such as measurement
values and the current status of the process. This data shall be stored in a non-volatile storage.
Specifying Notes:
If the back-up facility is used for fault recovery, the minimum interval for the back-up shall be
calculated to ensure the critical change value is not exceeded.
Required Documentation:
 A brief description of what data is backed up and when this occurs.
 Calculation of the minimum interval for the back-up to ensure that the critical change value is not
exceeded.
Validation Guidance:
Checks based on documentation:
 Check whether measurement data is saved to non-volatile storage and can be recovered.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
Measurement data is backed up as required.

Risk Class B Risk Class C Risk Class D

I4-5: Software Download
During installation of the software, the measurement process should be inhibited for no longer than one
minute in total.
In case that the installation of the software takes more than one minute, extra measures needs to be
taken (e.g. installation takes place at low energy consumption).
Specifying Notes:
 This requirement applies in addition to D1, D2, D3 and D4 if software download has been realized.
 The additional requirement ensures that for real time applications of the meter measurements are
not interrupted for too long.
Required Documentation:
See D1, D2, D3 and D4.
Validation Guidance:
See D1, D2, D3 and D4.
Example of an Acceptable Solution:
See D1, D2, D3 and D4.

12 The manufacturer should always take into account the national requirements concerning additional functionality.
13
With respect to interval metering additional guidance is given in WELMEC Guide 13.3.
113
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I4-6: MID-Annex I, 8.5 Inhibit Resetting of Cumulative Measurement Data
For utility measuring instruments the display of the total quantity supplied or the displays from which
the total quantity supplied can be derived, whole or partial reference to which is the basis for payment,
shall not be able to be reset during use.
Specifying Notes:
 Cumulative registers of a measuring instrument shall be reset prior to applicable conformity
assessment procedure. During a conformity assessment procedure according to annex D, F or
H1 the thermal energy meters shall be fitted with all securing and protective means as specified
by the TEC by the manufacturer after which resetting of the cumulative measurement data shall
not be possible without evidence of an intervention.
 Totalizers of the cumulative registers of a measuring instrument shall be reset before the relevant
conformity assessment procedure is completed. During the conformity assessment procedure
according to Annex D, F or H1, the thermal energy meters shall be equipped with all the safety
provisions set out in the TEC, that shall ensure evidence of an intervention into the meter registers
after resetting the cumulative measurement data.
Cumulative registers are not allowed to be reset during use in distribution network.
NB: specified in EN 1434-1:2015 under 5.10 - Specific requirements on registration devices
Required Documentation:
Documentation of protection means against resetting the energy registers.
Validation Guidance:
Checks based on documentation:
 Check that the reset operation of the cumulative legally relevant measurement data is secured and
that the protective means foreseen shall provide for evidence of an intervention.
Functional checks:
 Confirm correct functioning of the protective means foreseen, see also P3/U3 and P4/U4.
Example of an Acceptable Solution:
The register for the total measured quantity has to be protected by a hardware seal. Other registers, for
example day or night tariff register, may be protected by the same means as parameters (see P7/U7)
provided that a total (overall cumulative) register is available which is protected by a hardware seal. See
WELMEC Guide 13.1 for additional guidance.

114
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I4-7: MID-Annex I, article 10.5 Reading of Measurement Results
The measurement results that serve as the basis for the price to pay may be the results of different
registers, which are activated by remote control, a clock or other means. Each register represents the
total quantity, connected to one rate in the billing process. It should be possible to show the results on
different displays, periodically or on request via the user interface.

Specifying Notes:
Cumulative registers of a measuring instrument may be reset prior to applicable conformity
assessment procedure. During a conformity assessment procedure according to annex D, F or H1
the utility meters shall be fitted with all securing and protective means as specified by the TEC by the
manufacturer after which resetting of the cumulative measurement data shall not be possible without
evidence of an intervention.
When the maximum indicating range of the totalization of the quantity of heat is reached, the indicating
range will continue measuring starting from zero cubic meter, see also I1-9 (Number of Digits).
Required Documentation:
Documentation of how the measurement results are obtained that serves as the basis for the price to
pay.
Validation Guidance:
Checks based on documentation:
 Check the correct handling of the measurement results.
Functional checks:
 Confirm correct functioning of the handling of the measurement results.
Example of an Acceptable Solution:
If a meter is designed to count the quantities defined in MID, Annex VI Thermal energy meters (MI-004)
in different registers a meter shall be able to display the total quantities of each register on the display
by means of the user interface (See P3/U3, e.g.: buttons on instruments) as well as the currently active
rate register. It is allowed to show the results on different displays, periodically or on request via the user
interface. However, when displaying different measurement results it shall be clear which display be-
longs to which register, there shall be no ambiguity in that respect.
If needed, additional inscriptions can be provided on the thermal energy meter, clarifying the different
registers or indication of test mode (see I1-9).

115
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I4-8: MID-Annex I, Protection against Intentional Changes for Thermal Energy Meters of Type P
with a Mechanical Counter
The calculated checksum or an alternative indication to support detection of software modification shall
be made visible on command for control purposes, see P6. As an exception for thermal energy meters
of type P with a mechanical counter, an imprint of the checksum or an alternative indication of software
modification on the name plate of an instrument shall be an acceptable solution if the following
conditions A, B and C are fulfilled:
A. The user interface does not have any control capability to activate the indication of the value of
the checksum or an alternative indication of software modification on the display or the display
does not allow technically showing these values (mechanical counter).
B. The instrument does not have any interface to communicate the software identifier.
C. After production of a meter a change of the software is not possible or only possible if also the
hardware or a hardware component that contains the software is changed.
Specifying Notes:
 The manufacturer is responsible that the checksum or an alternative indication of software
modification is correctly marked on the concerned hardware.
 All other Specifying Notes of P6 apply.
Required Documentation:
According to P6.
Validation Guidance:
Checks based on documentation:
 According to P6.
Functional checks:
 According to P6.
Example of an Acceptable Solution:
Imprint of the checksum or an alternative indication of software modification on the name plate of the
instrument.

116
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I4-9: Number of Digits
According to EN1434-1:2015 paragraph 6.3.7:
The display indicating the quantity of heat shall be able to register, without overflow, a quantity
of heat at least equal to the transfer of energy, which corresponds to a continuous operation for 3 000 h
at the upper limit of the thermal power of the heat meter. The quantity of heat, measured by a heat
meter, operating at the upper limit of the thermal power for 1 h shall correspond to at least one digit of
lowest significance of the display.

Suitability according to clause 7.6 and 10.5 of Annex I of Directive 2014/32/EU (MID):
A measuring instrument shall be designed so as to allow the control of the measuring tasks after the
instrument has been placed on the market and put into use. If necessary, special equipment or software
for this control shall be part of the instrument. Also, for a measuring instrument with remotely read it
shall in any case be fitted with a metrologically controlled display accessible without tools to the
consumer.

When the maximum indicating range of the totalization of the quantity of heat is reached, the indicating
range will continue measuring starting from zero cubic meter, see also I1-9 (Number of Digits).
Note: Heat meter can be read as thermal energy meter.
Specifying Notes:
 For the test signal output shall be according to EN1434-2 paragraph 5.3.
 The indicating device of a water meter shall provide an easily read, reliable, and unambiguous
visual indication of the indicated volume. A combination meter may have two indicating devices,
the sum of which provides the indicated volume.
 Every indicating device shall provide means for visual, non-ambiguous verification testing and
calibration.
 The visual verification display may have either a continuous or a discontinuous movement.
Required Documentation:
 Documentation of the internal representation of the calculator of energy, temperature sensor, and
flowmeters.
 A description of the display and display menu.
 A description of the visual verification display and an explanation on how to initiate visual
verification display.
Validation Guidance:
Checks based on documentation:
 Check whether the number of digits is sufficient (internal and on display).
Functional checks:
 Check if the display of total quantity have a sufficient numbers of digits.
 Initiate the visual verification display and
 check if the resolution of the visual verification display fulfils the requirements
 check if special equipment or software for this control is part of the instrument (if relevant).
Example of an Acceptable Solution:
There are on the thermal energy meter sufficient number of digits on the display which fulfil both the
requirements of the total quantity with the required resolution.
Switching display modes on the indicating device for showing the values for the total quantity with the
correct resolution and the "test mode" with additional verification elements. These display modes shall
be possible to be displayed by means of:
 the user interface (See P3/U3, e.g.: buttons on instruments) or
 by cycling through the different display modes.
However, it should by clear what the primary display is when using different display modes, it shall be
clear how to read these values and there shall be no ambiguity in that respect to the other display modes
(See I1-7).
Note: It is not in line with the essential requirements of the Directive 2014/32/EU (MID) according to
article 7.6, Annex I, that a verification organisation, inspection body or Notified Body has to ask the
manufacturer for the special equipment or the software.

117
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I4-10: Display Test
For verifying the correct function of all segments of the electronic display, a display test shall be possible
to be executed.
Specifying Notes:
The display test is:
 The meter shall provide visual checking of the entire display which shall have the following
sequence:
1) for seven segment type displaying all the elements (e.g. an “eights” test);
2) for seven segment type blanking all the elements (a “blanks” test);
3) for graphical displays an equivalent test to demonstrate that display faults cannot result in
any digit being misinterpreted.
 Each step of the sequence shall last at least 1 s.
Required Documentation:
A description of the electronic display test and an explanation on how to initiate such a test.
Validation Guidance:
Initiate the display test and check if visual checking of the entire display is possible.
Example of an Acceptable Solution:
A display test is initiated after a special command by the user interface (see P3/U3, e.g.: buttons on
instruments) or is part of the cycling procedure that shows the different display modes.

Examples of legally relevant parameters, functions, and data

Access to means for modification of software, settings and/or parameters that influence
the determination of the results of measurements shall be secured14.
Parameter Protected Settable Comment
Calibration factor x
Linearisation factor x
Legally relevant configu- x
ration of registers
Other relevant parame- x
ters that can or might in-
fluence the measure-
ment result – unit of
measuring energy
(MWh, GJ), installation
sensor of flow (supply,
return branch of the ther-
mal circuit)

Software download of x
the legally relevant soft-
ware

Assignment of risk class

The following risk class is considered appropriate and should be applied if software
examinations based on this guide are carried out for (software-controlled) thermal en-
ergy meter:

14 The manufacturer should always take into account the national requirements concerning additional functionality.
With respect to interval metering additional guidance is given in WELMEC Guide 13.3.

118
WELMEC Guide 7.2: 2023 Software Guide

- Risk class C for instruments of type P

119
WELMEC Guide 7.2: 2023 Software Guide

Measuring Systems for the Continuous and Dynamic

Measurement of Quantities of Liquids Other than Water
Measuring systems for the continuous and dynamic measurement of quantities of
liquids other than water are subject to the requirements of the MID. The specific
requirements of this chapter are based on Annex I and Annex VII (MI-005) only.

Specific regulations, standards and other normative documents

The specific requirements of this chapter are based on MID, Annex VII and OIML
R117-1 edition 2019.

Technical description

Hardware configuration
Measuring systems for continuous and dynamic measurement of quantities of liquids
other than water are either built-for-purpose device (type P in this document) or could
consist of several parts, including universal devices (type U in this document).

The smallest possible measuring system shall include:

 a meter,
 a transfer point, and
 a hydraulic path.

For correct operation, it is often necessary to add:

 a gas elimination device,
 a filter,
 a pump, and
 correction devices

The measuring system may be provided with other ancillary and additional devices.

Ancillary and additional devices can be:

 zero-setting device;
 repeating indicating device;
 printing device;
 memory device;
 price indicating device;
 totalizing indicating device;
 correction device;
 conversion device;
 pre-setting device;
 self-service arrangement; and
 self-service device.

If ancillary and additional devices is/are part(s) of Measuring Systems for continuous
and dynamic measurement of quantities of liquids other than water as separate de-
vice/s which can be disconnected without breaking the seal(s) and contains legally
relevant software, then extension T must be applied.

If several meters are intended for a single measuring operation, the meters are con-
sidered to form a single measuring system.

120
WELMEC Guide 7.2: 2023 Software Guide

If several meters intended for separate measuring operations have common elements
(calculator, filter, gas elimination device, conversion devices, etc.), each meter is con-
sidered to form a separate measuring system, sharing the common elements.

Software configuration
This is specific to each manufacturer but would normally be expected to follow the
recommendations given in the main body of this guide.

Measurement principles
The quantity of the liquid is measured by means of measuring sensor of a volume or
mass flow sensor which can operate on different principles. The measured quantity is
converted into a signal (e.g. pulses) in the transmitter and sent to the calculator and
indicating device. They together form a meter. Further auxiliary measuring devices for
measuring liquid characteristic can be connected to the meter. E.g. temperature sen-
sor, pressure sensor. The measured quantity can be converted to the base conditions,
e.g., using an ATC (Automatic Temperature Compensation) function for conversion to
15 °C. The measured quantity must be indicated in millilitres, cubic centimetres, litters,
cubic meters, grams, kilograms or tons.

Error detection and troubleshooting

The requirement of Annex VII (MI-005), Article 3.1 deals with electromagnetic interfer-
ence. This requirement must be interpreted in relation to software-controlled devices
since interference detection and error correction are not possible without the interop-
erability of specific hardware components and modules. In terms of software the type
of interference does not matter, e.g.: electromagnetic, electrical or mechanical inter-
ference, as recovery procedures are always the same.

121
WELMEC Guide 7.2: 2023 Software Guide

Specific software requirements

Risk Class B Risk Class C Risk Class D
I5-1: Fault Recovery
Non-interruptible measuring systems shall be designed and manufactured in such a way that no
significant defects occur when they are exposed to the disturbances. The detection by the checking
facilities of incorrectness in the generation, transmission, processing and/or indication of measure-
ment data shall result in appropriate action.

Interruptible electronic measuring systems shall be designed and manufactured such that, when
they are exposed to the disturbances either:
a) the indication of the measurement result shows a momentary variation that cannot be inter-
preted, memorized or transmitted as a measuring result. Furthermore, in the case of an
interruptible system, this can also mean the impossibility to perform any measurement; or
b) the change in the measurement result is greater than the critical change value, in which
case the measuring system shall permit the retrieval of the measuring result just before the
critical change value occurred and cut off the flow.
Specifying Notes:
For non-interruptible measuring systems the detection by the checking facilities of incorrectness in
the generation, transmission, processing and/or indication of measurement data shall result in the
following actions:
 automatic correction of the malfunction; or
 stopping only the faulty device when the measuring system without that device continues to
comply with the regulations.
If the checking facilities of an interruptible electronic measuring systems detect significant defects
or any incorrectness in the generation, transmission, processing, or indication of the measurement
data they shall act by either
 automatic correction of the malfunction; or
 stopping only the faulty device, when the measuring system without that device continues
to comply with the regulations; or
 the measuring system shall permit the retrieval of the measuring result just before the critical
change value occurred and cut off the flow.
Additional requirement is stated in OIML R117-1:2019 section A.1.5 regarding fault generation pa-
rameters.
Required Documentation:
A brief description of what is checked, what is required to trigger the fault detection process, what
action is taken on the detection of a fault.
A list of parameters and their valid and controlled ranges which may generate faults and which will
be detected by the software including the expected reaction and, if necessary for understanding the
detection algorithm, its description.
Validation Guidance:
Checks based on documentation:
 Check whether the realization of fault recovery is appropriate.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an acceptable solution:
The hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to
inhibit the firing of the watchdog.
If any function has not been processed or - in the worst case - the microprocessor hangs in
an arbitrary endless loop, the reset of the watchdog does not happen in which case the
watchdog fires after a certain time span and resets the microprocessor.

122
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I5-2: Not legally relevant Software and Dynamic Behaviour
The not legally relevant software shall not inadmissibly influence the dynamic behaviour of a meas-
uring process.
Specifying Notes:
This requirement ensures that for real time applications of meters the dynamic behaviour of the
legally relevant software is not inadmissibly influenced by not legally relevant software, i.e. the re-
sources of the legally relevant software are not inadmissibly reduced by the not legally relevant part.
Required Documentation:
 Description of the interrupt hierarchy.
 Timing diagram of the software tasks. Limits of proportionate runtime for not legally relevant
tasks.
Validation Guidance:
Checks based on documentation:
 Documentation covering limits of the proportionate runtime for not legally relevant tasks is
available for the programmer of the not legally relevant software part.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an acceptable solution:
The interrupt hierarchy is designed in a way that avoids adverse influences.

Risk Class B Risk Class C Risk Class D

15
I5-3: Additional Functionality
Additional functionality should not influence the legally relevant measurement functions as specified
by MID Annex VII (MI-005).
Specifying Notes:
Additional functionality is allowed provided it does not influence the legally relevant measurement
functions as specified by MID, Annex VII (MI-005).
Required Documentation:
See P8, U8 and S1 to S3.
Validation Guidance:
See P8, U8 and S1 to S3.
Example of an acceptable solution:
See P8, U8 and S1 to S3.

15
The manufacturer should always take into account the national requirements concerning additional functionality.
123
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I5-4: Back-up facilities
In the case of non-interruptible measuring systems there may be a facility that provides for periodic
back-up of measurement data, such as measurement values and the current status of the process.
This data shall be stored in a non-volatile storage.
The measuring system must be equipped with a backup source to ensure that all measuring func-
tions are carried out in case of failure of the main power supply or it must be equipped with means
to preserve and display the data so that the ongoing transaction can be terminated.
Specifying Notes:
The storage interval must be short enough that the difference between current and stored cumulative
measurement data is small.
Required Documentation:
 A brief description of what data is backed up and when this occurs.
 Calculation of the maximum error that can occur when you back up the cumulative measurement
data.
Validation Guidance:
Checks based on documentation:
 Check whether measurement data is saved to non-volatile storage and can be recovered.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an acceptable solution:
 Measurement data is backed up periodically (frequency depending on application) on a non-
volatile storage on a memory device.
 A hardware watchdog fires when it is not cyclically reset. This alarm actuates an interrupt in the
microprocessor. The assigned interrupt routine at once collects measurement data, state values
and other relevant data and stores them in a non-volatile storage e.g. an EEPROM or other
appropriate storage.
Note: It is assumed that the watchdog interrupt has highest interrupt priority and can dominate any
normal processing or any arbitrary endless loop, i.e., the program control always jumps to the inter-
rupt routine if the watchdog fires.

Risk Class B Risk Class C Risk Class D

I5-5: Software Download
During installation of the software, the measurement process shall be inhibited, or correct measure-
ment shall be appropriately guaranteed.
Specifying Notes:
 This requirement applies in addition to D1, D2, D3 and D4 if software download has been
realized.
 The additional requirement ensures that for real time applications of the meter measure-
ments are not interrupted.
Required Documentation:
See D1, D2, D3 and D4.
Validation Guidance:
See D1, D2, D3 and D4.
Example of an acceptable solution:
See D1, D2, D3 and D4.

124
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I5-6: Imprinted Software Identifier
The software identifier is usually presented on a display. As an exception for measuring systems for
liquids other than water, an imprint of the software identifier on the type plate shall be an acceptable
solution if the following conditions A, B and C are fulfilled:
A. The user interface does not have any control capability to activate the indication of the value
of the checksum or an alternative indication of software modification on the display or the
display does not allow technically showing these values (mechanical counter).
B. The instrument does not have any interface to communicate the software identifier.
C. After production of a meter a change of the software is not possible or only possible if also
the hardware or a hardware component that contains the software is changed.
Specifying Notes:
 The tag showing the software identifier shall be non-erasable and non-transferable
 The manufacturer of the hardware or the concerned hardware component is responsible
that the software identifier is correctly marked on the concerned hardware.
 All other Specifying Notes of P6 apply.
Required Documentation:
According to P2/U2.
Validation Guidance:
Checks based on documentation:
 According to P2/U2.
Functional checks:
 According to P2/U2.
Example of an acceptable solution:
Imprint of the software identifier on the type plate of the instrument.

Risk Class B Risk Class C Risk Class D

I5-7: Parameter Settings
 For the purpose of verification of a measuring instrument, it shall be possible to display or
print the current parameter settings that fix the legally relevant characteristics of the meas-
uring system.
 The parameters shall be protected, see P7 and U7. In the case of an audit trail the time
stamp shall be read from the clock of the device. The setting of the time and date shall be
protected.
Specifying Notes:
These requirements are stated in OIML R117-1:2019 section A.1.3.3.
Required Documentation:
Information regarding the parameter settings and verification possibilities.
Validation Guidance:
Check the parameter settings and verification possibilities of the measuring instrument.
Example of an acceptable solution:
The above criteria shall be met.

125
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I5-8: Ancillary and additional devices (AAD)
When AAD is part of measuring device that is possible to disconnect (deinstall/remove/unmount)
then extension T shall be applied.
Specifying Notes:
In cases when measuring devices contains AAD without legally relevant software then data from
AAD with not legally relevant software must be clearly distinguishable from data from AAD with
legally relevant software. In cases when AAD with the legally relevant software has the possibility of
being disconnected without breaking a seal that protects the connection to the measuring device
then extension T shall be applied.
Required Documentation:
 The list of AAD which contains legally relevant software with description.
 According to extension T.
 According to extension S (if applicable).
Validation Guidance:
Checks based on documentation:
 According to extension T.
 According to extension S (if applicable).
 Check if documentation contains complete list of AAD with LRSW.
Functional checks:
 According to extension T.
 According to extension S (if applicable).
Example of an acceptable solution:

Examples of legally relevant parameters, functions and data16

Access to means for modification of software, settings and/or parameters that influence
the determination of the results of measurements shall be secured.
Parameter Protected Settable Comment
Calibration factor x
Linearisation factor x
Legally relevant configuration of registers x
Other relevant parameters that can or might influence the x
measurement result, for example but not limited to:
 Number of decimal places for quantity indication
 Low flow cut off
 Service commands (Saving of peripheral unit IDs, Re-
setting of electronic totals, complete initialization of
memory - electronic summaries, statistics and history,
and transition of parameters to factory settings)
 Value measured by mass meter - setting L / kg
 Suppression of the dispensing hose dilation - setting
the hidden amount at the start of dispensing
 Correction factor of the meter
 Measuring time after hanging the nozzle
 pulse / L, pulse / kg
 Activating of the automatic temperature compensation
for individual nozzles (ATC) and calibration of temper-
ature sensors
 Fuel type or density

16
See also WELMEC Guide 10.6: Guide for securing of Fuel Dispensers
126
WELMEC Guide 7.2: 2023 Software Guide

 Assignment of temperature sensors to individual noz-

zles
 Configuration of the mass meter
 Setting the zero point of the mass meter
Software download of the legally relevant software x
Software setting/configuration in case of pulse signals x
Software setting/configuration in case of digital data x

Assignment of risk class

The following risk class is considered appropriate and should be applied if software
examinations based on this guide are carried out for (software-controlled) measuring
systems for liquids other than water:

- Risk class C for instruments of type P and U

127
WELMEC Guide 7.2: 2023 Software Guide

Weighing Instruments
Weighing instruments are divided into two main categories:
1. Non-automatic weighing instruments (NAWIs), and
2. Automatic weighing instruments (AWIs).
While most AWIs are governed by the MID, NAWIs are not; they are still governed by
the European Directive 90/384/EEC. Therefore, the software guide WELMEC
7.5applies to NAWIs, whereas this software guide applies to AWIs.
The specific requirements of this chapter are based on Annex MI-006 and the
normative documents mentioned in 10.6.1 as far as they support the interpretation of
MID requirements.

Specific regulations, standards and other normative documents

5 categories of automatic weighing instruments (AWIs) are subject to regulations in
MID Annex MI-006:
- Automatic catchweighers (R51)
- Automatic gravimetric filling instruments (R61)
- Discontinuous totalisers (R107)
- Continuous totalisers (belt weighers) (R50)
- Automatic rail weighbridges (R106)
The numbers in brackets refer to the respective OIML recommendations that are
normative documents in the sense of the MID. In addition, WELMEC has issued the
WELMEC Guide 2.6 that supports the testing of automatic catchweighers.
There is one category of AWIs that is not governed by the MID:
- Automatic instruments for weighing road vehicles in motion (R134)
AWIs of all categories may be realised as type P or type U, and all extensions could
be relevant for each category.
However, of these 6 categories, only discontinuous totalisers and continuous
totalisers (belt weighers) have been identified as requiring instrument-specific
software requirements (see 10.6.3). The reason is that the measurement is cumulative
over a relatively long period of time and cannot be repeated if a significant defect
occurs.

Technical description

Hardware Configuration
A discontinuous totaliser is a totalising hopper weigher that determines the mass of a
bulk product (e.g. grain) by dividing it into discrete loads. The system usually comprises
of one or more hoppers supported on load cells, power supply, electronic controls and
indicating device.
A continuous totaliser is a belt weigher that measures the mass of a product as the
belt passes over a load cell. The system usually comprises of a conveyor belt, rollers,
load receptor supported on load cells, power supply, electronic controls and indicating
device. There will be a means for adjusting the tension of the belt.

128
WELMEC Guide 7.2: 2023 Software Guide

Software Configuration
This is specific to each manufacturer but would normally expect to follow the
recommendations given in the main body of this guide.

Measuring Principle
In the case of a discontinuous totaliser the bulk product is fed into a hopper and
weighed. The mass of each discrete load is determined in sequence and summed.
Each discrete load is then delivered to bulk.
In the case of a continuous totaliser the mass is continually measured as the product
passes over the load receptor. Measurements are made in discrete units of time that
depend on the belt speed and the force on the load receptor. There is no deliberate
subdivision of the product or interruption of the conveyor belt as with a discontinuous
totaliser. The total mass is an integration of the discrete samples. It should be noted
that the load receptor could use strain gauge load cells or other technologies such as
vibrating wire.

Defects
Joints in the belt may generate shock effects, which can lead to erroneous results when
zeroing. In the case of discontinuous totalisers, single or all weighing results of discrete
loads may get lost before being summed up.

Specific software requirements (Discontinuous and Continuous Totalis-

ers)
MID Annex MI-006, Chapter IV, Section 8, and Chapter V, Section 6 deals with
electromagnetic disturbances. There is a need to interpret these requirements for
software-controlled instruments because the detection of a disturbance (fault) and
subsequent recovery are only possible through the co-operation of specific hardware
parts and specific software. From the software point of view, it makes no difference
what the reason of a disturbance was (electromagnetic, electrical, mechanical etc); the
recovery procedures are all the same.

129
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I6-1: Fault Detection
The software shall detect that normal processing is disturbed.

Specifying Notes:
On detection of a fault:
a. The cumulative measurement and other relevant legal data shall be automatically saved to non-
volatile storage (see Requirement I6-2), and
b. the hopper weigher or belt weigher shall be stopped automatically, or a visible or audible alarm
signal shall be given (see Required Documentation)
Required Documentation:
A brief description of what is checked, what is required to trigger the fault detection process, what action
is taken on the detection of a fault.
If, on detection of a fault, it is not possible to stop the transportation system automatically without delay
(e.g., due to safety reasons) the documentation shall include a description of how the non-measured
material is treated or properly taken into account.
Validation Guidance:
Checks based on documentation:
 Check whether the realisation of fault detection is appropriate.
Functional checks:
 If possible: simulate certain hardware faults and check whether they are detected and reacted
upon by the software as described in the documentation.
Example of an Acceptable Solution:
A hardware watchdog is reset by a cyclically processed microprocessor subroutine in order to inhibit the
firing of the watchdog. Before resetting, the subroutine checks the health of the system e.g., whether all
legally relevant subroutines have been processed during the last interval. If any function has not been
processed or - in the worst case - the microprocessor hangs in an arbitrary endless loop, the reset of
the watchdog does not happen, and it fires after a certain time span.

130
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

I6-2: Back-up Facilities
There shall be a facility that provides for the back-up of measurement data, such as measurement
values, and the current status of the process in case of a disturbance.

Specifying Notes:
a. The state characteristics and important data shall be stored in a non-volatile storage.
b. This requirement normally implies a controlled storage facility providing automatic back-up in
case of a disturbance. Periodic backing up is acceptable only if a controlled storage facility is not
available due to hardware or functional constraints. In that exceptional case the storage intervals
shall be sufficiently small, i.e., the maximum possible discrepancy between the current and saved
measurement data shall be within a defined fraction of the maximum permissible error (see
Required Documentation).
c. The back-up facilities should normally include appropriate wake-up facilities in order that the
weighing system, including its software, does not get into an indefinite state by a disturbance.
Required Documentation:
A brief description of the back-up mechanism and the data that are backed up, and when this occurs.
Specification or calculation of the maximum error that can occur for cumulative measurement data if a
cyclical (periodic) back-up is realised.
Validation Guidance:
Checks based on documentation:
 Check back-up facilities.
Functional checks:
 Check by simulating a disturbance whether back-up mechanism works as described in the
documentation.
Example of an Acceptable Solution:
A hardware watchdog fires when it is not cyclically reset. This alarm actuates an interrupt in the
microprocessor. The assigned interrupt routine at once collects measurement data, state values and
other relevant data and stores them in a non-volatile storage e.g., an EEPROM or other appropriate
storage.
Note: It is assumed that the watchdog interrupt has highest interrupt priority and can dominate any normal
processing or any arbitrary endless loop, i.e., the program control always jumps to the interrupt routine if the
watchdog fires.

Examples of legally relevant parameters, functions, and data

Table 11-1: Examples of legally relevant, device-specific and type-specific functions
and data (DF, DD, TF, TD) for AWIs in comparison with those of non-automatic
weighing instruments (R76). VV indicates variable values.

131
WELMEC Guide 7.2: 2023 Software Guide

Functions/data Type OIML Recommendation No

50 51 51 61 76 106 107
(X) (Y)
Weight calculation TF, TD X X X X X X X
Stability analysis TF, TD X X X X X X
Price calculation TF, TD X X
Rounding algorithm for price TF, TD X X
Span (sensitivity) DD X X X X X X X
Corrections for non-linearity DD (TD) X X X X X X X
Max, Min, e, d DD (TD) X X X X X X X
Units of measurement (e.g., g, kg) DD (TD) X X X X X X X
Weight value as displayed (rounded to VV X X X X X
multiples of e or d)
Tare, preset tare VV X X X X X
Unit price, price to pay VV X X X
Weight value in internal resolution VV X X X X X X X
Status signals (e.g., zero indication, TF X X X X X X X
stability of equilibrium)
Comparison of actual weight vs. preset TF X X
value
Automatic printout release, e.g., at TF X X
interruption of automatic operation
Warm-up time TF (TD) X X X X X X X
Interlock between functions TF X X
e.g., zero setting/tare X X X X
automatic/non-automatic operation, X
zero-setting/totalizing X X
Record of access to dynamic setting TF (VV) X X
Maximum rate of operation/range of DD (TD) X X X X X X
operating speeds (dynamic weighing)
(Product)-Parameters for dynamic VV X X X
weight calculation
Preset weight value VV X X
Width of adjustment range DD (TD) X X
Criterion for automatic zero-setting (e.g., DD (TD) X X X X X
time interval, end of weighing cycle)
Minimum discharge, rated minimum fill DD X X
Limiting value of significant defect DD (TD) X X
(if not 1e or 1d)
Limiting value of battery power DD (TD) X X X X X X X

Table 11-1: Examples of legally relevant, device-specific and type-specific functions and data
The marked functions and parameters are likely to occur on the various types of
weighing instruments. If one of them is present, it has then to be treated as “legally
relevant”. The table is, however, not meant as an obligatory list indicating that any
function or parameter mentioned has to be realised in each instrument.

Other aspects
None

132
WELMEC Guide 7.2: 2023 Software Guide

Assignment of risk class

For the present, according to the decision of the responsible WELMEC Working Group
(24th WG 2 meeting, 22/23 January 2004) risk class "B" shall be generally applied
to all categories of AWIs regardless of the type (P or U).
However, as a result of the WG 7 questionnaire (2004), the following differentiation
with regard to type P and U instruments, and to discontinuous and continuous totalising
instruments (=“totalisers”) seems appropriate:
- Risk class B for type P instruments (except totalisers)
- Risk class C for type U instruments and totalisers type P and U

133
WELMEC Guide 7.2: 2023 Software Guide

Taximeters
Taximeters are subject to regulations in MID. The specific requirements are in Annex
MI-007. These specific requirements, the normative document OIML R 21 (2007) and
WELMEC CT-007 (corresponding table) have been taken into consideration.

Specific regulations, standards and normative documents

OIML Recommendation R 21 on taximeters is a normative document in the sense of
the MID. WELMEC CT-007 about taximeters shows the correspondence between the
essential requirements of MID and OIML R 21. WELMEC 12.1 gives specific interpre-
tations of MID and corresponding clauses of OIML R 21.

Technical description
A taximeter as defined in MID measures the time, the distance (using the output of a
distance signal generator not covered by MID) and calculates the fare for a trip based
on the applicable tariffs.
Taximeters can use an embedded architecture, which means built-for-purpose instru-
ments (type P) in the sense of this guide or an architecture using universal devices
(type U).

Specific software requirements

MID Annex IX, 4:
A taximeter shall be able to supply the following data through an appropriate
protected interface(s):
— operation position: ‘For Hire’, ‘Hired’ or ‘Stopped’;
— totaliser data according to paragraph 15.1;
— general information: constant of the distance signal generator, date of
securing, taxi identifier, real time, identification of the tariff;
— fare information for a trip: total charged, fare, calculation of the fare,
supplement charge, date, start time, finish time, distance travelled;
— tariff(s) information: parameters of tariff(s).
National legislation may require certain devices to be connected to the
interface(s) of a taximeter. Where such a device is required; it shall be
possible, by secured setting, to inhibit automatically the operation of the
taximeter for reasons of the non-presence or improper functioning of the
required device.

MID Annex IX, 9:

In case of a reduction of the voltage supply to a value below the lower op-
erating limit as specified by the manufacturer, the taximeter shall:
– continue to work correctly or resume its correct functioning without
loss of data available before the voltage drop if the voltage drop is
temporary, i.e. due to restarting the engine,

134
WELMEC Guide 7.2: 2023 Software Guide

– abort an existing measurement and return to the position "For Hire"

if the voltage drop is for a longer period.
MID Annex IX, 15.2:
If disconnected from power, a taximeter shall allow the totalised values to be
stored for one year for the purpose of reading out the values from the taximeter
to another medium.
MID Annex IX, 19:
A taximeter and its installation instructions specified by the manufacturer
shall be such that, if installed according to the manufacturer’s instructions,
fraudulent alterations of the measurement signal representing the distance
travelled are sufficiently excluded.

Risk Class B Risk Class C Risk Class D

I7-1: Back-up Facilities
There shall be a facility that automatically backs-up essential data, e.g., measurement data and the
current status of the process if the voltage drops for a longer period.

Specifying Notes:
1) This data should normally be stored in non-volatile storage.
2) A voltage level detector to detect when to store measurement data is necessary.
3) The back-up facilities shall include appropriate wake-up facilities in order that the taximeter,
including its software, does not get into an indefinite state.
Required Documentation:
A brief description of which data is backed up and when this occurs.
Validation Guidance:
Checks based on documentation:
 Check whether all legally relevant data are saved in case of a disturbance.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked
errors.
Example of an Acceptable Solution:
The voltage level detector fires an interrupt when the voltage level drops for a time of 15 s. The
assigned interrupt routine collects measurement data, state values, and other relevant data and stores
them in a non-volatile storage e.g., EEPROM. After the voltage level rises again the data is restored
and the functioning continues or is stopped (see MI-007, 9.)
Note: It is assumed that the voltage level interrupt has a high interrupt priority and can dominate any
normal processing or any arbitrary endless loop, i.e., the program control always jumps to the interrupt
routine if the voltage drops.

135
WELMEC Guide 7.2: 2023 Software Guide

Risk Class B Risk Class C Risk Class D

7-2: Long term storage
There shall be a facility that automatically stores the totalised measurement data if disconnected from
power.

Specifying Notes:
1) The totalised measurement data should normally be stored in non-volatile storage.
2) The facility shall store the totalised measurement data continuously or with an update rate
covering the time to detect power down until the (internal) voltage drops below the operating
voltage.
Required Documentation:
A brief description of which data is stored and when this occurs.
Validation Guidance:
Checks based on documentation:
 Check whether all totalised measurement data are saved in case disconnection from power.
Functional checks:
 Confirm correct functioning in the presence of defined influencing quantities and provoked errors.
Example of an Acceptable Solution:
The voltage level detector fires an interrupt when the voltage level drops. The assigned interrupt
routine collects totalised measurement data and stores them in a non-volatile storage before the
internal voltage drops below the operating level.
Or the totalised measurement data are stored continuously in a non-volatile storage.
Note: It is assumed that the voltage level interrupt has a high interrupt priority and can dominate any
normal processing or any arbitrary endless loop, i.e., the program control always jumps to the interrupt
routine if the voltage drops.

Risk Class B Risk Class C Risk Class D

I7-3: fraudulent alterations
There shall be a facility that checks the plausibility of the distance measurement signals.

Specifying Notes:
1) The facility shall include appropriate routines to check that the pulses or information received are
plausible.
Required Documentation:
A brief description of how the routines check the plausibility.
Validation Guidance:
Checks based on documentation:
 Check if the routines check the plausibility and how.
Functional checks:
 Confirm correct functioning in the presence of provoked errors.
Example of an Acceptable Solution:
The output of the distance signal generator is continuously checked on its defined characteristics
regarding voltage level, pulse width and the relation of speed and frequency (stability of the signal).
Note: the output could be digital information, for example from the CAN bus of the vehicle.

Examples of legally relevant parameters, functions, and data

In addition to the functions mentioned in 11.8.2 the following typical parameters of tax-
imeters can be considered.

136
WELMEC Guide 7.2: 2023 Software Guide

Parameter Protected Settable Comment

Taximeter constant k x Impulses per km
Time / date x x -
Tariffs (including the pa- x x Currency Unit/km, Currency Unit/h
rameters for automatic
change of tariffs)
Country/region specific x x Currency Unit, calculation mode S / D, wording/lan-
guage, etc
Interface parameters x Baud-rate, etc

At least the tariffs have to be separately secured.

Also the following data can be considered
Data Comment
Interface parameters Baud-rate, etc
annex IX, 4:
Operation position For Hire’, ‘Hired’ or ‘Stopped’;
Totaliser data: according to point 15.1, (Currency Unit, km, h)
General information: constant of the distance signal generator, (impulses/km)
date of securing, (ddmmyyyy)
taxi identifier, (license plate number)
real time, (hh:mm)
identification of the tariff (checksum)
Fare information for a trip: total charged, (Currency Unit)
fare, (Currency Unit)
calculation of the fare, (Currency Unit, km, h)
supplement charge, (Currency Unit)
date, (ddmmyyyy)
start time, (hh:mm)
finish time, (hh:mm)
distance travelled (km)
Tariff(s) information: parameters of tariff(s), (Currency Unit/km, Currency Unit/h)

Other aspects
It is recommended that the Automotive Directive is revised, or any other regulation is
made to give requirements for the distance signal generators of vehicles used as taxi.
A preliminary proposal reads:
For vehicles intended to be used as taxi the following requirements apply:
1. The distance signal generator shall give a signal with a resolution of at least
2 m.
2. The distance signal generator shall give a stable signal at every speed
travelled.
3. The distance signal generator shall have defined characteristics regarding
voltage level, pulse width and the relation of speed and frequency.
4. Testability…

Assignment of risk class

For the present, according to the result of the WELMEC WG 7 questionnaire (2004)
and confirmed by the responsible WELMEC WG12 taximeters, the following risk class
shall be applied if software examinations based on this guide are carried out for (soft-
ware-controlled) taximeters:
137
WELMEC Guide 7.2: 2023 Software Guide

- Risk class C for type P instruments

- Risk class D for type U instruments
Material Measures
Material measures are subject to regulations in MID. The specific requirements are in
Annex MI-008.
Subject to future developments and decisions material measures in the sense of MID
Annex MI-008 are not considered to be software-controlled measuring instruments.
Thus, for the present, this software guide does not apply to material measures.

138
WELMEC Guide 7.2: 2023 Software Guide

Dimensional Measuring Instruments

Dimensional Measuring Instruments are subject to regulations in MID. The specific
requirements are in Annex MI-009. Neither these specific requirements nor any
normative documents have yet been taken into consideration.
Missing clauses will be filled in if considered necessary in the future.

10.9.6 Assignment of risk class

For the present, according to the result of the WELMEC WG 7 questionnaire (2004)
and subject to future decisions of the responsible WELMEC Working Group, the
following risk class should be applied if software examinations based on this guide are
carried out for (software-controlled) dimensional measuring instruments:

- Risk class B for type P instruments

- Risk class C for type U instruments

139
WELMEC Guide 7.2: 2023 Software Guide

Exhaust Gas Analysers

Exhaust Gas Analysers are subject to regulations in MID. The specific requirements
are in Annex MI-010. Neither these specific requirements nor any normative
documents have yet been taken into consideration.
Missing clauses will be filled in if considered necessary in the future.

10.10.6 Assignment of risk class

For the present, according to the result of the WELMEC WG 7 questionnaire (2004)
and subject to future decisions of the responsible WELMEC Working Group, the
following risk class should be applied if software examinations based on this guide are
carried out for (software-controlled) exhaust gas analysers:
- Risk class B for type P instruments
- Risk class C for type U instruments

140
WELMEC Guide 7.2: 2023 Software Guide

Pattern for test report (including checklists)

This is a pattern for a test report, which consists of a main part and two annexes. The
main part contains general statements on the object under test. It must be
correspondingly adapted in practice. The annex 1 consists of two checklists to support
the selection of the appropriate parts of the guide to be applied. The annex 2 consists
of specific checklists for the respective technical parts of the guide. They are
recommended as an aid for manufacturer and examiner to prove that they have
considered all applicable requirements.
In addition to the pattern of the test report and the checklists, the information required
for the type examination certificate is listed in the last sub-chapter of this chapter.

Information to be included in the certificate

While the entire test report is a documentation of the object under test, the validation
carried out and the results, a certain selection of the information contained in the test
report are required for certificate. This concerns the following information, which should
be appropriately included in the certificate concerning software:

1. Software type
• Indicate the version of WELMEC Guide 7.2, type (P or U), the risk class (A
to E) and the applicable extensions (L, T, S, D, Ix)
Risk class [A-E] P U L T S D Ix
_ [1-6] _

Figure 12-1: Indication of the selected type, the risk class as well as applicable exten-
sions

2. Software identification
• Indicate the validated value(s) of the legally relevant software identifier(s).
• Describe how to view the legally relevant software identifier(s).

3. Integrity software verification

• For risk classes C and more, indicate the checksum or alternative method
with the same level of requirement.
• For risk class C and more, describe precisely how to view the checksum
or alternative method with the same level of requirements.
• Note: a reference to a document (e.g., user manual) is not suitable.
• Describe how to view the audit trails, if applicable.
• Description of hardware sealing(s) and other types of sealing(s) in relation
with software, if applicable.
• Other means of integrity protection, if applicable.

141
WELMEC Guide 7.2: 2023 Software Guide

4. Software environment short description

• Indicate relevant information concerning:
• Software operating environment necessary to operate the software (e.g.,
Operating System).
• Modules under legal control (if software separation implemented).
• Hardware and software interfaces (e.g., infrared, Bluetooth, Wireless
LAN…).
• Electronic (hardware) parts references and their locations in the measur-
ing instrument including its securing and protection, if needed.

142
WELMEC Guide 7.2: 2023 Software Guide

Pattern for the general part of the test report

Test report no XYZ122344

Flow meter Dynaflow model DF101

Validation of Software

(n annexes)

Commission
The Measuring Instruments Directive (MID) gives the essential requirements for certain measuring
instruments used in the European Union. The software of the measuring instrument was validated
to show conformance with the essential requirements of the MID.
The validation was based on the report WELMEC MID Software Requirements Guide WELMEC
Guide 7.2, where the essential requirements are interpreted and explained for software. This report
describes the examination of software needed to state conformance with the MID.

Client
Dynaflow
P.O. Box 1120333
100 Reykjavik
Iceland
Reference: Mr Bjarnur Sigfridson

Test Object
The Dynaflow flow meter DF100 is a measuring instrument intended to measure flow in liquids. The
intended range is from 1 l/s up to 2000 l/s. The basic functions of the instrument are:
- measuring of flow in liquids
- indication of measured volume
- interface to transducer

According to the WELMEC Guide 7.2 version yyyy, the flow meter is described as follows:
- a built-for-purpose device (an embedded system)
- long-term storage of measurement data
The flow meter DF100 is an independent instrument with a transducer connected. The transducer
is fixed to the instrument and cannot be disconnected. The measured volume is indicated on a
display. No communication with other devices is possible.

Page 1 / 4

143
WELMEC Guide 7.2: 2023 Software Guide

Software Type
Risk Class [A-E] P U O L T S D Ix [1-6]
C x x I1
The embedded software of the measuring instrument was developed by
Dynaflow, P.O. Box 1120333, 100 Reykjavik, Iceland.
Software Identification
The version of the software validated is V1.2c. The checksum is 0xA07GT… (CRC32). Software
version and checksum can be checked on the LCD display vit button push if the meter is turned on.
The source code comprises following files:

main.c 12301 byte 23 Nov 2003

int.c 6509 byte 23 Nov 2003
filter.c 10897 byte 20 Oct 2003
input.c 2004 byte 20 Oct 2003
display.c 32000 byte 23 Nov 2003
Ethernet.c 23455 byte 15 June 2002
driver.c 11670 byte 15 June 2002
calculate.c 6788 byte 23 Nov 2003

The validation has been supported by following documents from the manufacturer:
- DF 100 User Manual
- DF 100 Maintenance Manual
- Software description DF100 (internal design document, dated 22 Nov 2003)
- Electronic circuit diagram DF100 (drawing no 222-31, date 15 Oct 2003)
The final version of the test object was delivered to National Testing & Measurement Laboratory on
25 November 2003.
Integrity Software Verification
• For risk classes C and more, indicate the checksum or alternative method with the
same level of requirement.
• For risk class C and more, describe precisely how to view the checksum or alterna-
tive method with the same level of requirements.
• Note: A reference to a document (e.g. user manual) is not suitable.
• Describe how to view the audit trails, if applicable.
• Description of hardware sealing(s) and other types of sealing(s) in relation with soft-
ware, if applicable.
• Other means of integrity protection, if applicable.
Software Environment Short Description
• Indicate relevant information concerning:
• Software operating environment necessary to operate the software (e.g. Operating
System).
• Software modules under legal control (if software separation implemented).
• Hardware and software interfaces (e.g. infrared, Bluetooth, Wireless LAN…).
• Electronic (hardware) parts references and their locations in the measuring instru-
ment including its securing, if needed.

Page 2 / 4

144
WELMEC Guide 7.2: 2023 Software Guide

Examination Procedure
The validation has been performed according to the WELMEC 7.2 Software Guide 2022
(downloaded at www.welmec.org).
The validation was performed between 1 November and 23 December 2021. A design review was
held on 3 December by Dr K. Fehler at Dynaflow head office in Reykjavik. Other validation work has
been carried out at the National Testing & Measurement Lab by Dr K. Fehler and M. S. Problème.
Following requirements have been validated:
- Specific requirements for embedded software for a built-for-purpose measuring
instrument (type P)
- Extension L: Long-term storage for measurement data
Checklist for the selection of the configuration is found in annex 1 to this report.
Risk class C has been applied to this instrument.
Following validation methods have been applied:
- completeness of the documentation
- examination of the operating manual
- functional testing
- software design review
- review of software documentation
- data flow analysis
simulation of input signals

Page 3 / 4

145
WELMEC Guide 7.2: 2023 Software Guide

Result
Following requirements of the WELMEC Software Guide 7.2 have been validated without finding
faults:
- P1, P2, P3, P5, P6, P7, P8
(Requirement P4 is considered to be non-applicable.)
- L1, L2, L3, L4, L5, L6, L7, L8
Checklists for the P-requirements are found in annex 2.1 of this report.
Checklists for the L-requirements are found in annex 2.2 of this report.
Two commands which were not initially described in the operator’s manual were found. The two
commands have been included in the operator’s manual dated 10 December 2003.
A software fault which limited the month of February to 28 days also in leap year was found in
software package V1.2b. This has been corrected in V1.2c.

The software of the Dynaflow DF100 V1.2c fulfils the essential requirements of the Measuring
Instruments Directive.
The result applies to the tested item only.

National Testing & Measurement Lab

Software Department

Dr. K.E.I.N. Fehler M. S.A.N.S Problème

Technical manager Technical Officer

Date: 23 December 2003

Page 4 / 4

146
WELMEC Guide 7.2: 2023 Software Guide

Annex 1 of the test report: Checklists to support the selection

of the appropriate requirement Sets
The first checklist supports the user to decide which of basic configuration P or U
applies for the instrument under test.

Decision on Instrument Type

(P) Remarks

1 Is the entire application software constructed for the measuring

purpose? (Y)
2 Are the requirements for the inclusion of an operating system or
subsystems of it fulfilled? (Y)
3 Is the user prevented from accessing the operating system if it is
possible to switch to an operating mode not subject to legal
(Y)
control?
4 Are the implemented programs and the software environment
invariable (apart from updates)? (Y)
5 Are there any means for programming?
(N)
Tick the empty boxes, as appropriate

If and only if all answers to the 5 questions can be given as in the (P) column, then the
requirements of the part P (Chapter 4) apply. In all other cases the requirements of the
part U (Chapter 5) are necessarily to apply.

The second checklist supports to decide which of the IT configuration applies for the
instrument under test.

Decision on Required Extensions

Req. Extension

Not applicable

Remarks
YES
NO

Is type U selected and is the instrument equipped with a legally

O
relevant operating system?
Does the device have the ability to store the measurement data
L either on an integrated storage or on a storage of universal device
or on a remote or removable storage?
Is measurement data transmitted via communication networks to a
T distant device where it is further processed and/or used for legally
relevant purposes?
Are there software parts with functions not subject to legal control
S AND are these software parts desired to be changed after type
approval?
Is loading of software possible or desired after putting the
D
measuring instrument into use?
I Are there instrument-specific software requirements?
Consider the required extension for each question answered with YES!

147
WELMEC Guide 7.2: 2023 Software Guide

Annex 2 of the test report: Specific checklists for the respective

technical parts
Checklist of basic requirements for type P instrument
Checklist for Type P Requirements
Requirement

Not applicable
procedures
Testing

Passed
Failed
Remarks*

Does the required manufacturer documentation fulfil the

P1
requirement P1 (a-f)?
Is a software identification realised and presented as required in
P2
P2?
Are commands entered via the user interfaces prevented from
P3 inadmissibly influencing the legally relevant software, device-
specific parameters and measurement data?
Do commands input via communication interfaces of the
P4 instrument not inadmissibly influence the legally relevant
software, device-specific parameters and measurement data?
Are legally relevant software, device-specific parameters and
P5 measurement data protected against accidental or unintentional
changes?
Is the legally relevant software protected against the inadmissible,
P6 intentional modification, loading or swapping of hardware
memory?
P7 Are device-specific parameters protected as required in P7?
Is the authenticity of the presented measurement data
P8
guaranteed?
* Explanations are needed if there are deviations from software requirements.

Checklist for basic requirements for type U instrument

Checklist for Type U Requirements
Requirement

Not applicable
procedures
Testing

Passed
Failed

Remarks*

Does the required manufacturer’s documentation fulfil the

U1
requirement U1 (a-g)?
Is a software identification realised and presented as required in
U2
U2?
Are commands entered via the user interface prevented from
U3 inadmissibly influencing the legally relevant software and
measurement data?
Do commands inputted via communication interfaces of the
U4 device not inadmissibly influence the legally relevant software,
device-specific parameters and measurement data?
Are legally relevant software and device-specific parameters pro-
U5
tected against accidental or unintentional changes?
Are legally relevant software and measurement data protected
U6
against inadmissible, intentional modification or replacement?
U7 Are device-specific parameters protected as required in U7?

148
WELMEC Guide 7.2: 2023 Software Guide

Is the authenticity of the presented measurement data

U8
guaranteed?
* Explanations are needed if there are deviations from software requirements.

Checklist for specific requirements extension O

Checklist for Requirements of Extension O
Requirement

Not applicable
procedures
Testing

Passed
Failed
Remarks*

Is the hardware part, which the legally operating system runs on,
O1
protected against intentional changes?
For category 1 components and complete instruments: does the
O2 boot process provide the same configured environment for the
execution of the legally relevant software?
Does the configuration of the operating system ensure that there
O3 are enough resources for the operation of the legally relevant
application?
Is the operating system configured in such a way that the legally
O4 relevant software application cannot be inadmissibly influenced by
functions of the operating system or by other software?
Do the operating systems functions accessible via open inter-
O5 faces not inadmissibly influence the legally relevant software, le-
gally relevant parameters or measurement data?
Are the operating system and the configuration of the operating
system identifiable?
O6 Are the identification of the operating system and the identification
of the configuration of the operating system presented on
command or during operation?
Is the operating system protected against intentional
O7
modifications?
* Explanations are needed if there are deviations from software requirements.

Checklist for specific requirements extension L

Checklist for Requirements of Extension L
Requirement

Not applicable
procedures
Testing

Passed
Failed

Remarks*

Is the stored measurement data accompanied by all relevant

L1
information needed for legally relevant purposes?
Is stored data protected against accidental and unintentional
L2
changes?
Is the stored measurement data protected against intentional
L3
changes?
Is the stored measurement data capable of being traced back to
L4 the measurement and measuring instrument that generated
them?
Are confidential information protected against changes, kept
L5
secret and protected against disclosure?
Is there a legally relevant component or module for retrieving,
L6
verifying, handling and indicating stored measurement data?

149
WELMEC Guide 7.2: 2023 Software Guide

Is the measurement data stored automatically when the

L7
measurement is concluded?
Does the long-term storage have a capacity which is sufficient for
L8
the intended purpose?
* Explanations are needed if there are deviations from software requirements.

Checklist for specific requirements extension T

Checklist for Requirements of Extension T
Requirement

Not applicable
procedures
Testing

Passed
Failed
Remarks*

Does transmitted data contain all relevant information necessary

T1 to present or further process the measurement result in the
receiving unit?
Is transmitted data protected against accidental and unintentional
T2
changes?
T3 Is transmitted data protected against intentional changes?
Is the transmitted measurement data capable of being traced back
T4 to the measurement and the legally relevant component or
module or measuring instrument that generated them?
Are confidential information protected against changes, kept
T5
secret and protected against compromise?
Is there a legally relevant component or module for receiving,
T6
verifying, handling and indicating transmitted measurement data?
Is it ensured that the measurement is not inadmissibly influenced
T7
by a transmission delay?
Is it ensured that no measurement data get lost if network services
T8
become unavailable?
* Explanations are needed if there are deviations from software requirements.

Checklist for specific requirements extension S

Checklist for Requirements of Extension S
Requirement

Not applicable
procedures
Testing

Passed
Failed

Remarks*

Is there a part of the software that contains all legally relevant

S1 software and parameters that is clearly separated from other parts
of software?
Is the legally relevant indication generated by the legally relevant
S2 software and is it clearly distinguishable from the not legally
relevant indication??
Is the interaction and data exchange between the legally relevant
S3 and not legally relevant software carried out exclusively via a
protective interface?
* Explanations are needed if there are deviations from software requirements.

Checklist for specific requirements extension D

Checklist for Requirements of Extension D

150
WELMEC Guide 7.2: 2023 Software Guide

Requirement

Not applicable
procedures
Testing

Passed
Failed
Remarks*

Do both phases of the software download, the transmission, and

D1 the subsequent installation of software, run automatically and do
they not affect the protection of legally relevant software?
Are means employed to guarantee that the downloaded software
D2
is authentic?
Are means employed to guarantee that the downloaded software
D3
has not been inadmissibly changed during transmission?
Is it guaranteed by appropriate technical means that downloads
D4 of legally relevant software are adequately traceable within the
instrument for subsequent controls?
* Explanations are needed if there are deviations from software requirements.

Cross reference for MID software requirements to MID

articles and annexes
(Related MID Version: DIRECTIVE 2014/32/EU, 26 February 2014)

151
WELMEC Guide 7.2: 2023 Software Guide

Given software requirement, reference to MID

Requirement MID
No Denotation Article / Annex No Denotation
(AI = Annex I)

Basic Type P
P1 Manufacturer’s Documentation AI-9.3 Information to be borne by and to
AI-12 accompany the instrument
Article 18 Conformity Evaluation
Technical Documentation
P2 Software Identification AI-7.6 Suitability
AI-8.3 Protection against corruption
P3 Influence via User Interface AI-7.1 Suitability
P4 Influence via communication In- AI-7.1 Suitability
terface AI-8.1 Protection against corruption
P5 Protection Against Accidental or AI-7.1, AI-7.2 Suitability
Unintentional Changes AI-8.4 Protection against corruption
P6 Protection Against Intentional AI-7.1 Suitability17
Changes AI-8.2, AI-8.3, AI-8.4 Protection against corruption
P7 Parameter Protection AI-7.1 Suitability
AI-8.2, AI-8.3, AI-8.4 Protection against corruption
P8 Presented measurement data AI-7.1, AI-7.2, AI-7.6 Suitability
AI-8.3 Protection against corruption
AI-10.2, AI-10.3, AI-10.4 Indication of result

Basic Type U
U1 Manufacturer’s Documentation AI-9.3 Information to be borne by and to
AI-12 accompany the instrument
Article 18 Conformity Evaluation
Technical Documentation
U2 Software Identification AI-7.6 Suitability
AI-8.3 Protection against corruption
U3 Influence via user interfaces AI-7.1 Suitability
U4 Influence via Communication In- AI-7.1 Suitability
terface AI-8.1 Protection against corruption
U5 Protection against accidental or AI-7.1, AI-7.2 Suitability
unintentional changes AI-8.4 Protection against corruption
U6 Protection against Intentional AI-7.1 Suitability
Changes AI-8.2, AI-8.3, AI-8.4 Protection against corruption
U7 Parameter Protection AI-7.1 Suitability
AI-8.2, AI-8.3, AI-8.4 Protection against corruption
U8 Presented measurement data AI-7.1, AI-7.2, AI-7.6 Suitability
AI-8.3 Protection against corruption
AI-10.2, AI-10.3, AI- Indication of result
10.4
Extension O
Extension L
L1 Completeness of stored data AI-7.1 Suitability
AI-8.4 Protection against corruption
AI-10.2 Indication of result
L2 Protection against accidental or AI-7.1, AI-7.2 Suitability
unintentional changes AI-8.4 Protection against corruption
L3 Integrity of data AI-7.1 Suitability
AI-8.4 Protection against corruption
L4 Authenticity of stored data AI-7.1 Suitability
AI-8.4 Protection against corruption
AI-10.2 Indication of result

17 Note: As regards contents, paragraph 7.1 of MID-Annex I is not an issue of “Suitability” but of “Protection
against corruption” (Paragraph 8)
152
WELMEC Guide 7.2: 2023 Software Guide

Requirement MID
No Denotation Article / Annex No Denotation
(AI = Annex I)
L5 Confidentiality of keys AI-7.1 Suitability
AI-8.4 Protection against corruption
L6 Retrieval of stored data AI-7.2 Suitability
AI-10.1, AI-10.2, AI- Indication of result
10.3, AI-10.4
L7 Automatic storing AI-7.1 Suitability
AI-8.4 Protection against corruption
L8 Storage capacity and continuity AI-7.1 Suitability
Lx All of Extension L AI-11.1 Further processing of data to
conclude the trading transaction
Extension T
T1 Completeness of transmitted data AI-7.1 Suitability
AI-8.4 Protection against corruption
T2 Protection against accidental AI-7.1, AI-7.2 Suitability
changes AI-8.4 Protection against corruption
T3 Integrity of data AI-7.1 Suitability
AI-8.4 Protection against corruption
T4 Authenticity of transmitted data AI-7.1 Suitability
AI-8.4 Protection against corruption
T5 Confidentiality of keys AI-7.1 Suitability
AI-8.4 Protection against corruption
T6 Handling of corrupted data AI-7.1 Suitability
AI-8.4 Protection against corruption
T7 Transmission delay AI-7.1 Suitability
AI-8.4 Protection against corruption
T8 Availability of transmission ser- AI-7.1 Suitability
vices AI-8.4 Protection against corruption
Extension S
S1 Realisation of software separation AI-7.6, Suitability
AI-10.1 Indication of result
S2 Mixed indication AI-7.1, AI-7.2, AI-7.6 Suitability
AI-10.2 Indication of result
S3 Protective interface AI-7.6 Suitability
Extension D
D1 Download mechanism AI-8.2, AI-8.4 Protection against corruption
D2 Authentication of downloaded AI-7.6 Suitability
software AI-8.3, AI-8.4 Protection against corruption
AI-12 Conformity evaluation
D3 Integrity of downloaded software AI-7.1, Suitability
AI-8.4 Protection against corruption
D4 Traceability of legally relevant AI-7.1, AI-7.6 Suitability
Software Download AI-8.2, AI-8.3 Protection against corruption
AI-12 Conformity evaluation
Extension I
(Instrument-specific Software Re-
quirements)
I1-1, Reliability
AI-6
I2-1, Specific Requirements for Utility
MI-001-7.1, MI-002-
I3-1, Fault Recovery Meters
3.1, MI-003-4.3.1,
I4-1,
MI-004-4
I5-1
I1-4,
AI-6
I2-3, Reliability
MI-001-7.1, MI-002-
I3-4, Back-up facilities Specific Requirements for Utility
3.1, MI-003-4.3.1,
I4-4, Meters
MI-004-4
I5-4

153
WELMEC Guide 7.2: 2023 Software Guide

Requirement MID
No Denotation Article / Annex No Denotation
(AI = Annex I)
I1-9,
I2-9, Internal resolution, suitability of MI-002-5.3, MI-003- Specific Requirements for Utility
I3-9, the indication 5.2 Meters
I4-9
I1-6, AI-8.5 Protection against corruption
I2-6, Inhibit resetting of cumulative
I3-6, measurement data
I4-6
I1-2, AI-7.6 Suitability
I2-2, Protection against corruption
I3-2, Dynamic behaviour
I4-2,
I5-2
I2-10 MI-002-5.2 Specific Requirements for Gas
Battery lifetime
Meters
I2-12 MI-002-9.1 Specific Requirements for Gas
Electronic volume converters
Meters
I2-11 MI-002-5.5 Specific Requirements for Gas
Test element
Meters
I6-1 Fault detection MI-006-IV, MI-006-V Discontinuous and continuous
Totalisers
I6-2 Back-up facilities Fault detection MI-006-IV, MI-006-V Discontinuous and continuous
Totalisers

154
WELMEC Guide 7.2: 2023 Software Guide

Interpretation of MID Articles and Annexes by MID-Software

Requirements
Software
MID
Guide
Article / An- Requirement
nex No Denotation Comment
No
(AI = Annex I)

Article Part
1, 2, 3 No specific software relevance
Transmission of measurement
Definitions, Arrangement of data ... T
4(b)
sub-assemblies Basic Guides applicable to sub-as- P, U
semblies
5 to 9 No specific software relevance
Documentation of design, manufac-
ture and operation. Enable assess-
ment of conformity.
General description of the instrument.
Description of electronic devices with
10 Technical documentation P1, U1
drawings, flow diagrams of the logic,
general software information.
Location of seals and markings.
Conditions for compatibility with inter-
faces and sub-assemblies.
11 to 27 No specific software relevance
Annex I
AI-1 to AI-5 No specific software relevance
I1-1, I1-2,
I2-1, I2-2,
Fault detection, back-up, restoring,
AI-6 Reliability I3-1, I3-2,
restart
I4-1, I4-2,
I6-1, I6-2
P3 – P8,
U3 - U8,
No features to facilitate fraudulent L1 – L5, L7, L8,
AI-7 Suitability use; minimal possibilities for uninten- T1 – T8,
tional misuse. S2, D3, D4,
I1-4, I2-8, I3-5,
I4-4
AI-8 Protection against corruption
No influences by the connection of
AI-8.1 P4, U4
other devices.
P6, P7, U6, U7,
AI-8.2 Protection; evidence of intervention
D1, D4
P2, P6, P7, P8
Identification of software; evidence of
AI-8.3 U2, U6, U7, U8,
intervention
D2, D4
P5 - P7,
U5 - U7,
Protection of stored or transmitted
AI-8.4 L1 - L5,
data
T1 - T8
D1 - D3
I1-3, I2-4, I3-4,
AI-8.5 No reset of cumulative registers
I4-3
Information to be borne by
AI-9 and to accompany the instru-
ment

155
WELMEC Guide 7.2: 2023 Software Guide

Software
MID
Guide
Article / An- Requirement
nex No Denotation Comment
No
(AI = Annex I)
Measuring capacity
AI-9.1 (rest of items not relevant for soft- L8
ware)
AI-9.2 No specific software relevance
Instructions for installation, ..., condi-
tions for compatibility with interface,
AI-9.3 P1, U1
sub-assemblies or measuring instru-
ments.
AI-9.4 to
No specific software relevance
AI-9.8
AI-10 Indication of result
Indication by means of a display or
AI-10.1 U8, L6, S2
hard copy.
Significance of result, no confusion P8, U8, L1, L4,
AI-10.2
with additional indications. L6, S2
Print or record easily legible and non-
AI-10.3 P8, U8, L6, S2
erasable.
For direct sales: presentation of the
AI-10.4 P8, U8, S2
result to both parties.
For utility meters: display for the cus- I1-3, I2-3, I3-
AI-10.5
tomer. 3/4, I4-3
Further processing of data to
AI-11 conclude the trading transac-
tion
Record of measurement results by a
AI-11.1 L1 - L8
durable means.
Durable proof of the measurement
AI-11.2 result and information to identify a L1, L6
transaction.
Ready evaluation of the conformity
P1, P2, U1, U2,
AI-12 Conformity evaluation with the requirements of the Di-
D2, D4
rective.
Annexes A1 to H1
A1 to No requirements to features of instru-
H1 ments
Annex MI-001
MI-001-1 to
No specific software relevance
MI-001-6
Fault detection
MI-001-7.1.1,
Electromagnetic immunity Back-up facilities I1-1, I1-2
MI-001-7.1.2
Wake-up facilities and restoring
MI-001-7.1.3
to No specific software relevance
MI-001-9
Annex MI-002
MI-002-1 to
No specific software relevance
MI-002-2
Fault detection
MI-002-3.1 Electromagnetic immunity Back-up facilities I2-1, I2-2
Wake-up facilities and restoring
MI-002-3.1.3
No specific software relevance
to MI-002-5.1
Acceptable solution for monitoring
MI-002-5.2 Suitability I2-5
battery lifetime
MI-002-5.3 Suitability Internal resolution I2-3
156
WELMEC Guide 7.2: 2023 Software Guide

Software
MID
Guide
Article / An- Requirement
nex No Denotation Comment
No
(AI = Annex I)
MI-002-5.4 to
No specific software relevance
MI-002-8
MI-002-5.5 Suitability Test element I2-7
MI-002-5.6 to
No specific software relevance
MI-002-8
Volume conversion devices Acceptable solution for monitoring
MI-002-9.1 I2-6
Suitability the gas volume converter
MI-002-9.2 to
No specific software relevance
MI-002-10
Annex MI-003
MI-003-1 to
No specific software relevance
MI-003-4.2
Permissible effect of transi- Fault detection
MI-003-4.3 ent electromagnetic phenom- Back-up facilities I3-1, I3-2
ena Wake-up facilities and restoring
MI-003-5.1 No specific software relevance
MI-003-5.2 Suitability Internal resolution I3-3
MI-003-5.3 to
No specific software relevance
MI-003-7
Annex MI-004
MI-004-1 to
No specific software relevance
MI-004-4.1
Fault detection
Permissible influences of
MI-004-4.2 Back-up facilities I4-1, I4-2
electromagnetic disturbances
Wake-up facilities and restoring
MI-004-4.3 to
No specific software relevance
MI-004-7
Annex MI-005

Annex MI-006
MI-006-IV, Discontinuous and continu- Fault detection
I6-1, I6-2
MI-006-V ous Totalisers Back-up facilities

Annex MI-007
Permissible influences of
MI-007-8 Back-up facilities I7-1
electromagnetic disturbances

Annex MI-008

Annex MI-009

Annex MI-010

157
WELMEC Guide 7.2: 2023 Software Guide

Remarks on measurement terminology

Note: This informative Annex is intended to illustrate the terms and definitions related to the
measurement process and their usage in this OIML Document.
In this Document, the definition of Measurement Result is a "set of quantity values being attributed to a
measurand together with any other relevant data", (i.e., Measurement Result Relevant Data). This is
illustrated in Figure A.1 as the Measured Quantity Value (MQV) and Measurement Result Relevant
Data (MRRD), both being part of the Measurement Result.
Together with the Measurement Process Data (MPD) these form the Measurement Data.

Figure A.1 – Visual representation of the Measurement Information

In general, this OIML Document distinguishes between measurement data and measurement metadata.
If both are used together, measurement data are put into context; hence, measurement data plus meas-
urement metadata equals measurement information.
This OIML Document also distinguishes between Measurement Result Relevant Information and Meas-
urement Process Information.
Figure A.2 contains a flowchart to illustrate the distinction between the data relevant to the Measurement
Result or data relevant to the Measurement Process.

Figure A.2 – Flowchart of a measurement process, giving examples for the different data rele-
vant to the Measurement Result or relevant do the Measurement Process.

158
WELMEC Guide 7.2: 2023 Software Guide

Figure A.2. also indicates the data composing the Measurement Result: Measured Quantity Value
(MQV) and the Measurement Result Relevant Data (MRRD), while the corresponding Measurement
Result Metadata needed for the correct interpretation of the result is shown in a framed, dashed rectan-
gle.
Figure A.2 shows a simple example of a measurement process. For each logical step (from data acqui-
sition by the sensor to indication of the result) the following parts are noted:
• the Measured Quantity Value (MQV) and Measured Quantity Value Metadata (MQVM);

• the Measurement Result Relevant Data (MRRD) and the Measurement Result Relevant
Metadata (MRRM);

• the Measurement Process Data (MPD) and the Measurement Process Metadata (MPM).
One strand of measurement information is related to the measurement result relevant information.
Data acquisition by the sensor delivers a raw counter value of 12 (MQV) with ‘counter’ as the Measured
Quantity Value Metadata (MQVM) needed to interpret the data.
The Measurement Result Relevant Information (MRRI) is the ADC’s quantiser 16 bits resolution,
• where 16 is the Measurement Result Relevant Data (MRRD),

• while ‘quantiser resolution’ is the Measurement Result Relevant Metadata (MRRM), needed to
interpret the data.
During processing, the Measured Quantity Value (MQV) with “integer value” as the Measured Quantity
Value Metadata (MQVM) is assigned ‘kWh’ as Measurement Result Relevant Data (MRRD) with ‘unit’
as Measurement Result Relevant Metadata (MRRM), as well as a time stamp ‘17-07-2017’ (MRRD)
with format ‘day-month-year’ (MRRM) and Mister X (MRRD) as customer ID (MRRM).
In both cases, during acquisition by the sensor and processing, the Measured Quantity Value (MQV)
and Measurement Result Relevant Data (MRRD) form part of the Measurement Result, while the
metadata is needed for the correct interpretation of the Measurement Result.
Another strand of measurement information is related to the measurement process: for acquisition of the
Measured Quantity Value (MQV) from the sensor, COM-Port number 4 is used, where
• ‘4’ is the Measurement Process Data (MPD) and

• the ‘COM-Port’ is the Measurement Process Metadata (MPM) needed to understand the data
element.
Indication of the result can be by means of a display or by printing.
The Measurement Process Data (MPD) ‘printing’ with the correspondent Measurement Process
Metadata (MPM) ‘display method’ are both necessary for the measurement process, but they will not
become part of the measurement result, nor the measurement result metadata.
It is up to the technical working groups to decide what Measurement Result Relevant Data is because
under certain circumstances, Measurement Process Data (MPD) might become Measurement Result
Relevant Data (MRRD).
In the given example, shown in Figure A.2, the COM-Port number 4 links the Measured Quantity Value
(MQV) to a customer Mr. X, thus turning the Measurement Process Data (MPD) into Measurement
Result Relevant Data (MRRD) during the processing step.

159
WELMEC Guide 7.2: 2023 Software Guide

Legally relevant properties

A legally relevant measuring instrument can have legally relevant software and under
certain conditions not legally relevant software, The same applies to parameters,
data, inscriptions and indications, they can either be legally relevant and under cer-
tain conditions not legally relevant.
With the definition above one can determine whether software, parameters, data, in-
scriptions and indications are legally relevant with regard to the MID and NAWID. Be-
low some examples are given with regard to the application of the definition.
• Those markings and inscriptions that have to fulfill the essential requirements are
according to the definition legally relevant.

• The securing and protection features, used to secure the measuring instrument,
software, parameters, measurement data, inscriptions and indications have to ful-
fill the essential requirements and are therefore legally relevant.

• Data, whether stored, transmitted, and/or indicated, used to construct the meas-
urement result has to fulfill the essential requirements and is therefore legally rel-
evant.

Note: Legally relevant data is called measurement data.

• If a component is used to construct, store, and/or transmit measurement data

and/or indicate the measuring result, then that component might influence the
measurement result and therefore have an influence on the compliance with the
requirements and is therefore legally relevant.

• Components to construct the measurement data includes for example the sen-
sor, analog data processing unit and digital data processing unit;
• Components to store or transmit measurement data, includes for example a
hard disk and network interface card;
• Components to indicate the measurement results, includes display and printer.

If a module is used to construct, store, and/or transmit measurement data and/or indi-
cate the measuring result, then that module might influence the measurement result
and therefore have an influence on the compliance with the requirements and is there-
fore legally relevant.

160
WELMEC Guide 7.2: 2023 Software Guide

References and literature

[1] Software Requirements and Validation Guide, Version 1.00, 29 October 2004,
European Growth Network “MID-Software”, contract number G7RT-CT-2001-
05064, 2004
[2] DIRECTIVE 2014/32/EU OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 26 February 2014 on the harmonisation of the laws of the Member
States relating to the making available on the market of measuring instruments
(recast), Official Journal of the European Union L 96/149, 29.3.2014
[3] Directive 2004/22/EC of the European Parliament and of the Council of 31 March
2004 on measuring instruments. Official Journal of the European Union L 135/1,
30.4.2004
[4] Internet Security Glossary, http://www.ietf.org/rfc/rfc2828.txt
[5] ISO/IEC JTC1/SC7 3941, 2008-03-14,
http://pef.czu.cz/~papik/doc/MHJS/pdf/IT-VOCABULARY.pdf

Revision history

No. Date Significant Changes

1 May 2005 Guide first issued.

2 April 2007 Addition and enhancement of terms in Section 2

Editorial changes in Sections 4.1 and 5.1
Amendment of a clarification for software identification in Section
4.2, Requirement P2 and Section 5.2, Requirement U2.
Amendment in Requirement L8, Specifying Note 1.
Addition of an explanation to Requirement S1, Specifying Note 1.
Replacement of Requirement D5 by a remark.
Change of the Risk Class for Measuring Systems for Liquids other
than Water.
Change of Risk Classes for Weighing Instruments.
Various minor editorial changes in the document.
Addition of this revision table.

3 March 2008 Addition of exceptions for the indication of the software identifica-
tion: new requirements I1-5, I2-9, I3-6, I4-5, and I5-1.

4 May 2009 Restriction of the application area of software download, clarifica-

tion of identification requirements in connection with software
download
Revision of requirements P2 and U2: Deletion of void text frag-
ments.

161
WELMEC Guide 7.2: 2023 Software Guide

5 May 2011 Revision of chapter 5 (part U): Advancement with respect to oper-
ating systems
Replacement of the term “component” by other appropriate terms
through the guide to avoid misunderstandings
Addition of requirement D1 in section 9.2 by introduction of a seal-
able setting for the download mechanism
Refinement of the specifying notes of requirements P2 and U2 in
section 4.2 and 5.2, respectively, with regard to software identifi-
cation
Extension of examples of acceptable solutions in requirement L2
(section 6.2) and in requirement U8 (section 5.2)

6 March 2015 Major revision:

- Character of the guide: The guide is considered a purely
technical document that interprets software-related es-
sential requirements. Statements that do not correspond
to this principle have been removed.
- Addressees of the guide: The guide addresses software
developers and examiners, but may be used as well by
other parties, in particular Market Surveillance Authori-
ties, wherever and whenever it is appropriate.
- It has turned out that the implementation of the two latter
updates requires much editorial work in detail. These
changes will lead to a better readability of the guide, but
not change technical specifications.
- Software identification (P2/U2): It shall not be anymore
required in the guide 7.2 that the software identifier has
to be provided by the software itself. It is sufficient to re-
quire that the software identifier has to be provided by the
instrument in a secured way.
- Differentiation between identification and integrity
(P2/U2, P6/U6): MID annex 1 distinguishes between
identification of software (annex 1, cl. 7.6) and integrity,
e.g. protection of software (annex 1, cl. 8.4). The differ-
entiation does not lead to weaker requirements.
- Support of conformity-to-type checks: The technical
means required for integrity of software are considered
suitable also to be used for the check of conformity to
type. The means required are e.g. checksums or equiv-
alent means at different levels for all instruments in risk
class C and higher.
- Risk classes: Risk class C has been changed so that now
the whole legally relevant software is considered fixed for
instruments in risk class C. In this way, ambiguities which
part of software is considered fixed have been removed.
In risk class C and higher identity of software on the bit
level (e.g. by checksums) must be implemented.
- Risk classification of instruments with universal devices
(U type instruments): Due to a basically higher risk asso-
ciated with U type instruments, their classification into

162
WELMEC Guide 7.2: 2023 Software Guide

risk class B is considered inappropriate. U type instru-

ments can only be classified into risk class C upwards.
- Acceptable security measures for high Risk Classes (D
and higher): Concerning algorithms and minimum key
lengths, the requirements or recommendations of the na-
tional and international institutions responsible for data
security have to be taken into consideration (e.g. NIST
(USA), DCSSI (France), CESG (United Kingdom), CCN
(Spain), NCSC (Netherlands), BSI (Germany)).
- Legally relevant software: It is not seen anymore the ne-
cessity to differentiate between legally relevant software
and fixed legally relevant software. All protection require-
ments in annex I are valid for legally relevant software.

7 March 2018 Expansion of P7 by an acceptable solution that ensures, that the

contents of the audit trail are shown on the display is added.
Expansion of U8 and inclusion of a corresponding P8 to describe
pairing and handshaking between units in a more general way.
Improved clarity of extension S by removing the definition for low
level / high level separation.

8 April 2019 Editorial changes concerning translation comparison and house-

keeping, clarification of the application of extension T, corrections
in P6, U6, T2, T6 and L2
Reorganization between “Acceptable Solutions” and “Specifying
Notes” on each requirement.
The two instrument-specific annexes 10.2 Gas Meters and Vol-
ume Conversion Devices and 10.3 Active Electrical Energy Meters
have been completely revised.
Chapter 11.1 “Information to be included in the type examination
certificate” was adapted.

9 October 2020 Revision of the annexes 10.1 Water meter, 10.4 Thermal energy
meters, 10.5 Measuring systems for the continuous and dynamic
measurement of quantities of liquids other than water and 10.7
Taximeters.

10 July 2021 Implementation of the changes of the terminology subgroup pre-

sented in the WG 7 meeting in 2021.
Reworded validation guidance for risk classes E (“appropriate” ->
“correct”), as presented in the WG 7 meeting in 2019.

11 March 2022 Addition of “Extension O”, detailing new requirements for measur-
ing instruments with operating systems. Subsequently, the whole
guide has been updated to incorporate the new extension.
Multiple requirements in the whole document have been clarified
to increase the readability and make them less ambiguous. The
technical specifications remain the same.
The template of the test report has been updated.

163
WELMEC Guide 7.2: 2023 Software Guide

12 March 2023 Implementation of OIML D31 terminology. Consequently, all re-

quirements have been reworked to coincide with the new termi-
nology.
Further clarifications regarding the addition of extension O have
been implemented in the introductory texts. The checklist for ex-
tension O has been added as well.

13 May 2024 Restoration of a missing specifying note in L3 due to an accidental

deletion during the revision of the 2022 version.

Table 17-1: Revision history

164