Requirements for the evaluation of software in software-controlled measuring devices

Category:
Issue date: YYYY-MM-DD
Effective date: YYYY-MM-DD
Revision number: n/a
Supersedes: n/a

Table of content

  • 1.0 Purpose
  • 2.0 Scope
  • 3.0 Authority
  • 4.0 Citing this document
  • 5.0 Definitions
  • 6.0 General requirements
  • 7.0 Requirements for software in software-controlled measuring devices
  • 8.0 Requirements specific to configuration and technical features

    1.0 Purpose

    This document establishes requirements for the evaluation of software in software-controlled measuring devices that are approved for use in trade. These requirements will be used in conjunction with the other specifications applicable to the device type. These requirements supersede any previous requirements prescribed in S-EG-05—Specifications for the Approval of Software-Controlled Electricity and Gas Metering Devices under the Electricity and Gas Inspections Act (EGIA).

    2.0 Scope

    The requirements in this document apply to the software in all software-controlled measuring devices that are approved for use in trade pursuant to section 3 of the Weights and Measures Act (WMA) or section 9 of the Electricity and Gas Inspection Act (EGIA).

    3.0 Authority

    For measuring devices that are subject to the WMA, software-controlled measuring devices may be approved on a temporary basis in accordance with section 3(2) of the WMA.

    For software-controlled measuring devices that are subject to the EGIA, this document is issued under the authority of section 12 of the Electricity and Gas Inspection Regulations.

    4.0 Citing this document

    This document may be cited as follows:

    1. In the context of the WMA, the Terms and Conditions for Software in Software-Controlled Measuring Devices
    2. In the context of the EGIA, the Provisional Specifications for Software in Software-Controlled Measuring Devices

    5.0 Definitions

    Accidental change

    (modification accidentelle)

    Change to a software-controlled measuring device caused by a physical effect such as electromagnetic interference, temperature and vibration.

    Attestation

    (attestation)

    Legally binding document which declares that a specific requirement of this document has been met.

    Authentication

    (authentification)

    Validation of the declared or alleged identity of a user, process, or device, in particular, to ensure that downloaded software is legitimately linked to the approval applicant or device manufacturer as identified in the notice of approval.

    Authenticity

    (authenticité)

    Result of the process of authentication (passed or failed).

    Communication interface

    (interface de communication)

    Part of a device that enables information to be passed between measuring devices, components of measuring devices or other external systems. Communication interface can utilize wired, optical, radio, or similar communication and they are usually designed to use a specific protocol.

    Component

    (composant)

    Identifiable hardware part of a device that performs a specific function or functions.

    Data domain

    (domaine de données)

    Location in memory that each program needs for processing data.

    Device-specific parameter

    (paramètre spécifique à l'appareil)

    Legally relevant parameter with a value that depends on the individual device. Device-specific parameters comprise calibration parameters, metrological parameters and configuration parameters.

    Durability

    (durabilité)

    Ability of the measuring device to maintain its performance characteristics over a period of use.

    Dynamic module

    (module dynamique)

    Software module of legally relevant software whose functional behaviour depends on predefined device-specific parameters that may change over time during use.

    Event logger

    (enregistreur d'événements)

    Secure form of audit trail containing a series of records where each record contains a number corresponding to the occurrence of a specific event.

    Fixed legally relevant software

    (Logiciel à caractère légal fixe)

    Part of the legally relevant software that is and remains identical in the executable code to that of the approved device type.

    Integrity

    (intégrité)

    Assurance that the software, measurement data, or parameters have not been subjected to any unintentional, accidental, or inadmissible changes while in use, transfer, storage, repair, or maintenance.

    Intentional change

    (modification intentionnelle)

    Change to a software-controlled measuring device resulting from the deliberate action of the user such as modifying or loading or updating the device software.

    Interface

    (interface)

    Point of interaction between two functional units defined by various characteristics pertaining to functions, physical interconnections, signal exchanges, and other characteristics of the units (as applicable).

    Legally relevant

    (caractère légal)

    Software, hardware, data, or a part thereof, which interferes with or affects properties subject to regulation under the Weights and Measures Act and Regulations or the Electricity and Gas Inspections Act and Regulations.

    Legally relevant parameter

    (paramètre à caractère légal)

    Parameter of a measuring device, component or software module subject to regulation under the Weights and Measures Act and Regulations or the Electricity and Gas Inspections Act and Regulations.

    Legally relevant software

    (logiciel à caractère légal)

    Legally relevant software includes:

    • software modules that perform legally relevant functions or that contain legally relevant data domains and are part of the legally relevant software of a device. More specifically, this includes all software modules that:
      • contribute to or have an impact on the calculation of the measurement result,
      • contribute to functions such as displaying, securing, transmitting, and storing legally relevant data,
      • identify the software, or
      • perform software download,
    • all fixed variables or parameters that have an impact on the establishment of a measurement result,
    • dynamic modules that are part of the measurement process and have an impact on the measurement result, including markings, indications and legally relevant data that is produced, displayed, transmitted, and stored as a result of the algorithms of the dynamic modules of legally relevant software.
    Measurement data

    (données de mesure)

    Data used during the measurement process. It includes the measured quantity value and data relevant to the measurement process and result.

    Measurement result

    (résultat de mesure)

    Quantity or set of quantities that are legally relevant and are attributed to a measurand and may include any other data relevant to the measurand.

    Open interface

    (interface ouverte)

    Interface which is accessible while the device is in service. Open interface includes:

    • network interface (open and closed ports, used protocols and commands, policies)
    • serial interface (command interpreter of the application, policies for user account control)
    • software interface of the operating system (access control commands)
    Open network

    (réseau ouvert)

    Network of devices with arbitrary functions. The number, identity, and location of a device can be dynamic and unknown to the other devices.

    Operating system

    (système d'exploitation)

    Software to control program operation and provide services for resource allocation, task scheduling, input-output (I/O) control, data management and tasks including access control and security.

    Pairing parameter

    (paramètre d'appariement)

    Parameter that is necessary to connect and run the separated components that form the measuring device. This includes a parameter that is used as part of a software seal to prevent exchanging or spoofing components.

    Protection

    (protection)

    Means to protect the measurement data, parameters, measuring device, component, or software module with the intention of making an intervention impossible or evident.

    Protective interface

    (interface de protection)

    Legally relevant software module that handles all data flow to the legally relevant software modules in order to prevent inadmissible influences.

    Sealing

    (scellage)

    Means intended to protect the measuring device against any unauthorized modification.

    Securing

    (sécurisation)

    Means to prevent unauthorized access to hardware, software, parameters, or measurement data.

    Significant defect

    (défaut significatif)

    Incident that has an undesirable impact on the compliance of the measuring device or a fault.

    Software

    (logiciel)

    Set of instructions, data, parameters or programs used to operate computers and execute specific tasks. This also includes what is often referred to as firmware.

    Software-controlled measuring device

    (appareil de mesure commandé par logiciel)

    Device constructed specifically to execute a metrological task that incorporates software, or device that is not constructed for that purpose but that can be adapted to a legally relevant task by software, or a combination of the two.

    Software identification

    (identification du logiciel)

    Discrete set of characters that are inextricably linked to the software or software modules (e.g. name, version number, checksum).

    Software interface

    (interface logicielle)

    Program code which receives, filters, or transmits data between software modules. A software interface could be legally relevant.

    Software module

    (module logiciel)

    Software entity such as a program, subroutine, library, parameter, data set, object and operating system part, including their data domains that may be in a relationship with other entities.

    Software protection

    (protection du logiciel)

    Protection of measuring device software or data domain by a hardware or software implemented seal with the intention of making an intervention impossible or evident.

    Software separation

    (séparation logicielle)

    Separation of software in measuring devices, which can be divided into legally relevant modules and legally non-relevant modules. These modules communicate via a software interface.

    Storage device

    (dispositif de stockage)

    Device used for storing measurement data that are necessary to construct the measurement result.

    Traced update

    (mise à jour traçable)

    Procedure to modify, reinstall or update approved legally relevant software in an examined or a verified device after which a subsequent examination or verification is not necessary. The procedure comprises several steps such as loading, integrity check, authenticity check, installation, logging, and activation.

    Transmission of measurement data

    (transmission des données de mesure)

    Electronic transportation of measurement data via communication interface(s) to a receiver.

    Type-specific parameter

    (paramètre spécifique au type)

    Legally relevant parameter with a value that depends on the type of device, component or module subject to legal control.

    Unintentional change

    (modification involontaire)

    Change to a software-controlled measuring device resulting from the action of the user that was not deliberate.

    User interface

    (interface utilisateur)

    Interface that enables information to be interchanged between the user and the measuring device or its components or software modules.

    Verification triggering event

    (événement déclencheur de vérification)

    Event deemed by Measurement Canada to require the examination or verification of a device before it is permitted to be used or to continue to be used in trade. The recording of a verification triggering event is similar to breaking the device’s physical seal.

    Verified update

    (mise à jour vérifiée)

    Procedure to reinstall or update approved legally relevant software in an examined or a verified device after which the subsequent examination or verification is necessary. The procedure for software update comprises loading and installation as two different steps or combined into one, depending on the needs of the technical solution.

    6.0 General requirements

    Software evaluation is required as part of the type approval of software-controlled measuring devices for use in trade. In addition to the software requirements, these devices must also meet all applicable device-specific requirements.

    Section 7.0 sets out the general approval requirements that apply to the design, construction and performance that apply to all software-controlled measuring devices or components.

    Section 8.0 sets out additional approval requirements for the design, construction, and performance of software-controlled measuring devices or components that have specific configurations or technical features identified in that section.

    Where the specific configuration or technical feature applies to a device, the requirements of the subsection must be met in entirety.

    7.0 Requirements for software in software-controlled measuring devices

    7.1 Software identification

    7.1.1 Clarity and accuracy of identification

    The legally relevant software of a device or a device component must be unambiguously and clearly identified.

    7.1.2 Identification of legally relevant software

    The software identification must be inseparably linked to the legally relevant software. A new software identification must be generated and updated automatically when the legally relevant software is modified in any way.

    7.1.3 Display of the software identification

    The device or device component must be capable of showing the legally relevant software identification:

    • on the display, either at startup (where devices are capable of being turned on and off) or during operation, or
    • in print form (where a printer is part of the measuring system).

    Where the device or device component has neither a display nor a printer, the software identification must be sent via a communication interface to be displayed or printed on another legally relevant component.

    When a device is in service, the software identification must be easily accessible and readable for verification and examination purposes by use of the standard user interface or through equipment allowed for use with the device by specifications or by a notice of approval.

    Software identification may be marked and permanently affixed in a manner allowed for the device by specifications or by a notice of approval if it meets all of the following conditions:

    1. The user interface does not have the control capability to activate the indication of the software identification on the display, or the display does not technically allow the identification of the software to be shown,
    2. The device or the device components do not have an interface to communicate the software identification, and
    3. After the device or a device component is manufactured, any change of the software is not possible, or only possible if the hardware is also changed.

    7.1.4 Display of software identification for legally non-relevant software

    Where legally relevant software is separated from legally non-relevant software and the software identification of legally non-relevant software is required for technical purposes, the legally non-relevant software must be clearly identified, and means must be provided for the software identification to be accessible for verification and examination.

    7.2 Correctness of algorithms and functions

    The measuring algorithms and functions of a measuring device must be appropriate and functionally correct for the given application and device type.

    It must be possible to examine algorithms and functions through testing and documentation review.

    7.3 Protection of legally relevant software, parameters and measurement data

    7.3.1 Evidence and prevention of intervention

    7.3.1.1 Legally relevant software

    Legally relevant software must be protected and secured against unintentional, accidental, and intentional changes.

    7.3.1.2 Measurement data

    During processing, measurement data must be protected and secured. Commands entered through the user or communication interface must not cause any inadmissible influence on the processing of measurement data.

    7.3.1.3 Legally relevant parameters

    Legally relevant parameters must be protected and secured in such a way that evidence of an intervention must be available.

    Where the legally relevant parameters used by a device do not reside in the device, the retrieval of the legally relevant parameters must be logged in the event logger that is accessible through the device.

    7.3.2 Prevention of modification, loading or swapping

    A device must be designed such that the legally relevant software is protected against inadmissible influence due to modification, loading, or changes by swapping of the hardware memory components.

    7.3.3 Interface

    7.3.3.1 User interface

    All inputs from the user interface must be through a protective interface. Any function that can be activated by the user interface must not cause any inadmissible influence on the legally relevant characteristics of a device.

    All functions activated through a user interface which may affect the measurement process must be clearly documented.

    7.3.3.2 Communication interface

    All inputs from the communication interface must be through a protective interface. Any function that can be activated through a communication interface must not cause any inadmissible influence on the legally relevant characteristics of a device.

    All functions activated through a communication interface which may affect the measurement process must be clearly documented.

    7.3.4 Sealing

    The following requirements apply:

    7.3.4.1 Software

    Software must be protected in such a way that evidence of intervention is available. The provisions for software protection must comprise appropriate sealing of hardware, software, and/or cryptography, making an intervention impossible or evident.

    7.3.4.2 Storage device

    Storage devices that contain legally relevant software, parameters, and measurement data must be protected in such a way that evidence of intervention is available.

    7.3.4.3 Event logger

    The event logger, which is part of the legally relevant software, must be secured and protected, and it must not be possible to delete or make an inadmissible change to the information in the event logger.

    7.4 Prevention of misuse

    A device must be designed and constructed in a manner that minimizes the possibility for unintentional, accidental or intentional misuse or perpetration of fraud.

    7.5 Demands on the user

    The software of a measuring device must be designed in such a way that no unreasonable demands are required from the user to obtain a correct measurement result.

    7.6 Dynamic modules of legally relevant software

    7.6.1 Appropriateness of dynamic modules

    The dynamic modules of the legally relevant software must be appropriate and functionally correct for the given application and device type.

    7.6.2 Identification of dynamic modules

    A measuring device or systems that incorporate or depend upon the dynamic modules of legally relevant software must be equipped with a feature that identifies this information.

    7.6.3 Measurement result

    Where a measurement result is the product of a measurement process that incorporates or depends upon the dynamic modules of legally relevant software, the indication of the measurement result must include information regarding the use of those modules in the measurement process.

    7.6.4 Verification and examination

    It must be possible to verify and examine the dynamic modules of the legally relevant software by appropriate tests and documentation review.

    7.7 Support of hardware features

    7.7.1 Detection of defects

    If software is involved in the detection of significant defects, the software must appropriately act upon any detected defect.

    7.7.2 Detection of durability error

    If software is involved in durability protection, the software must appropriately act upon any detected durability error.

    8.0 Requirements specific to configuration and technical features

    8.1 Software separation

    8.1.1 Design

    The following requirements apply:

    1. Where software separation is implemented, the legally relevant and legally non-relevant software must be unambiguously and uniquely identified.
    2. If the separation of software is not possible or needed, the software is legally relevant as a whole.
    3. Where a legally relevant software has been separated from legally non-relevant software, the legally relevant software must be designed in such a way that another device, component, or legally non-relevant software which may reside or run on a device must not cause any inadmissible influence on it.
    4. Legally relevant software must process the legally relevant information. Measurement data must not be modifiable by a legally non-relevant software prior to primary indication.

    8.1.2 Protective interface

    The following requirements apply:

    1. All legally relevant software modules must communicate with other software modules through a protective interface. The protective interface must not be capable of being circumvented and all communication must be performed exclusively via this interface.
    2. A device must be designed such that all interactions and communications through a protective interface do not result in any inadmissible influence on the legally relevant software.
    3. A device must be designed such that each command sent via the protective interface to the initiated function or data change in the legally relevant software must be unambiguously assigned.
    4. The protective interface must prohibit all undocumented interactions, communications, and data flow.

    8.1.3 Priority level

    Under normal operating conditions, the legally relevant software must have priority using the resources over the legally non-relevant software. Legally non-relevant software must not inadmissibly interrupt the legally relevant process. The measurement operation, performed by the legally relevant software, must not be delayed or blocked by other processes.

    8.2 Separation of components

    8.2.1 Design

    The following requirements apply:

    1. Components of a measuring device that perform legally relevant functions and their interrelations must be identified, clearly defined, and documented.
    2. A device must be designed such that the components that perform legally relevant functions are protected against any inadmissible influence by another device, components, or software modules.

    8.2.2 Protective interface

    The following requirements apply:

    1. A legally relevant software-controlled component must communicate with other components or devices through a protective interface.
    2. A legally relevant software-controlled component must be designed such that all interactions and communication through the protective interface do not inadmissibly influence the legally relevant software, parameters, or measurement data.
    3. Each command sent via the protective interface to the initiated function or data change in the legally relevant software-controlled component must be unambiguously assigned.

    8.2.3 Pairing parameters

    The following requirements apply:

    1. If the exchange of legally relevant components is protected by software means, the pairing parameters must be secured and protected in such a way that evidence of intervention is available.
    2. The legally relevant software-controlled components must check the authenticity, integrity and availability of another software-controlled component. If the authenticity and integrity check fails or the component is not available, the software must appropriately act upon the detected defect.

    8.2.4 Legally relevant components with limited functionality and protection

    If legally relevant components have limited functionality and limited securing and protection capabilities, they must use the measurement data without modification or further processing. There must be a legally relevant component that can be fully secured and protected for retrieving, verifying, handling and indicating stored and transmitted measurement data. This component must ensure that the data are complete and protected.

    8.3 Mixed indications

    The legally relevant indication must be generated by the legally relevant software.

    The presentation of legally relevant information must be unambiguous for all parties affected.

    8.4 Storage of data

    8.4.1 Completeness of stored data

    The stored measurement data must include all relevant information that is required for legally relevant purposes.

    8.4.2 Protection of stored data

    The following requirements apply:

    1. Appropriate means must be used to protect the stored measurement data to guarantee authenticity and integrity. The software that displays or further processes the measurement data must check the authenticity and integrity of the data after having read them from storage.
    2. The stored measurement data must be protected against accidental changes.
    3. The stored measurement data must be secured and protected against unintentional and intentional changes.

    8.4.3 Automatic data storage

    The following requirements apply:

    1. Where data storage is required, measurement data must be stored automatically when the measurement is taken.
    2. The software must regularly check the availability of the storage device and must appropriately act upon any detected defect.
    3. No measurement must be possible if the data storage device is unavailable.
    4. The data storage device must have sufficient capacity for the intended application. If the storage capacity limit is reached, further measurements must be disabled.
    5. Measurement data must not be deleted until all subsequent expected actions for a legal for trade transaction are complete.

    8.4.4 Traceability of stored data

    The stored measurement data to be used for legally relevant purposes must be capable of being assigned back to the measurement and the measuring device that produced them.

    8.4.5 Permanency

    The storage device must have sufficient permanency to ensure that the stored data is not corrupted under normal storage conditions.

    8.5 Data transmission

    8.5.1 Completeness of transmitted data

    The transmitted measurement data must include all relevant information that is required to present or further process the measurement data for legally relevant purposes.

    8.5.2 Protection of transmitted data

    The following requirements apply:

    1. Transmitted measurement data must be protected to guarantee authenticity and integrity. The software that displays or further processes the measurement data must check the authenticity and integrity of the data received from a transmission channel. If an irregularity is detected, the software must act appropriately upon the detected defect.
    2. The transmitted measurement data must be protected against accidental changes and secured against unintentional changes.
    3. For open networks, the transmitted measurement data must be protected against intentional changes.

    8.5.3 Traceability of transmitted data

    For open networks, the transmitted measurement data to be used for legally relevant purposes must be capable of being assigned to the measurement and the measuring device or component that produced them.

    8.5.4 Transmission delay or interruption

    The measurement data must not be subject to any inadmissible influence caused by a transmission delay or interruption. If network services become unavailable or slow, no measurement data must be lost.

    8.6 Compatibility of the operating system and hardware

    If an operating system is part of the software-controlled measuring device, each of the following requirements must be met on an application level, by the operating system, or a combination of both.

    8.6.1 Boot process

    If a secure boot process is needed to ensure the protection of the legally relevant software, the following requirements apply:

    1. The boot process must ensure the integrity and authenticity of the legally relevant software.
    2. If a chain of trust is established over the individual parts of the boot process to ensure integrity and authenticity, the processing of the chain of trust can be interrupted, as long as its integrity is preserved.
    3. The boot configuration must be secured and protected.
    4. The device must not be able to boot via open interfaces.

    8.6.2 System resources and suitable environment

    The following requirements apply:

    1. The operating system and the legally relevant software must be configured to ensure that there are enough resources for the operation of the legally relevant application.
    2. The manufacturer must identify the hardware and software environment that is necessary to guarantee the correct functioning of the legally relevant software.
    3. If minimum resources or suitable configuration requirements are not met, appropriate means must be provided to prevent the operation of the legally relevant software.

    8.6.3 Protection during use

    The following requirements apply:

    1. The operating system must be configured to ensure that the legally relevant software cannot be subject to any inadmissible influence by the functions of the operating system or by other software.
    2. The operating system must be protected against intentional changes.
    3. The access control feature of the operating system must be configured in such a way that it prevents inadmissible influence on the intended use.
    4. The administration tasks of the legally relevant software must be protected.
    5. The legally relevant software must be protected during all reconfiguration and updates of the operating system.

    8.6.4 Communication between the operating system and the legally relevant software

    The following requirements apply:

    1. Communication between the operating system and the legally relevant software must be through a protective interface.
    2. Communication via user or communication interface must not result in any inadmissible influence on the legally relevant software, parameters, or measurement data.
    3. Open interfaces must be protected by appropriate means. The configuration of the interfaces must be secured and protected in such a way that evidence of any intervention is available.

    8.6.5 Identification and traceability

    The following requirements apply:

    1. The configuration of the operating system must be identifiable, and means must be provided for the identifier to be accessible for verification and examination.
    2. Changes to the legally relevant configuration settings of the operating system must be protected and traceable.

    9.0 Software update

    9.1 General

    9.1.1 Software versions

    Only the versions of the legally relevant software listed on the Notice of Approval are legal for use in trade.

    9.1.2 Software protection

    Upon completion of the software update process, the software protection environment must be at the same level as exhibited by the device prior to the occurrence of the software update. It must not be possible to make undetectable unauthorized modifications using the capabilities of the device, its operating system (if applicable) or other readily available and manageable tools.

    9.1.3 Device design

    A device must be designed such that the software update process is not capable of affecting the device performance and measurement accuracy of the device.

    A device must be designed such that the software update process is not capable of affecting any legally relevant measurement data.

    9.1.4 Update process

    A software update can be performed locally (directly on the device) or remotely via a network (subject to sealing requirements). The update process must be automatic such that human intervention is not required beyond the initiation of the process.

    9.1.5 Restriction

    Software updates are not permitted unless the requirements in 9.2 or 9.3 are met.

    9.2 Verified update

    9.2.1 Examination or verification

    After an update of the legally relevant software, the device must not be used in trade before an examination or a verification of the device has been performed by an inspector or an accredited meter verifier and the sealing provisions have been renewed.

    9.2.2 Protection measure

    An update must not take effect unless a seal (hardware or software) is broken such that the seal provides evidence of an intervention.

    9.3 Traced update

    9.3.1 Event logger

    9.3.1.1 Devices approved under the Weights and Measures Act and Regulations

    Devices that are approved to perform traced updates under the WMA and WMR must be equipped with an event logger which complies with the requirements of Measurement Canada's Terms and Conditions for the Approval of Metrological Audit Trails.

    9.3.1.2 Devices approved under the Electricity and Gas Inspection Act and Regulations

    Devices that are approved to perform traced updates under the EGIA and EGIR must be equipped with an event logger which complies with the requirements of Measurement Canada's Specifications Relating to Event Loggers for Electricity and Gas Metering Devices.

    9.3.1.3 Legally relevant software

    If a device uses traced updates of the legally relevant software, it must have an event logger.

    9.3.2 Traced update

    The following requirements apply:

    1. A traced update must not affect existing type specific parameters.
    2. The device must:
      1. have fixed legally relevant software that cannot be updated during the traced update,
      2. be able to guarantee the authenticity of the loaded software, and
      3. be able to ensure the integrity of the loaded software.
    3. The traced update must be recorded in an event logger.
    4. During the software download or installation process, the device must be capable of continuing to function and measure as intended or inhibit the measurement functions.
    5. Where the software to be loaded on a device fails to ensure integrity or authenticity, the device must be designed to abort the software loading process and ensure that the previous approved version of the software is maintained on the device. Alternatively, the device may switch to an inoperable mode where measuring functions are inhibited. However, the download process, in accordance with the traced update requirements, may be re-initiated.

    9.3.3 Failure to update software

    The following requirements apply:

    1. A device approved for performing software updates must be capable of detecting if the software update fails or is not completed successfully.
    2. A failed traced update must be recorded as an event in the event logger.
    3. In the case of an unsuccessful software update or installation or if the software update or loading is interrupted, the original status of the device must be unaffected, or the device must be inoperable. However, the download process, in accordance with the traced update requirements, may be re-initiated.

    9.3.4 Modifications to legally non-relevant software

    A device may be approved with the capability of updating its legally non-relevant software without a traced update, where:

    1. the device has been designed and constructed such that the legally non-relevant software is distinctly separated from the legally relevant software, and
    2. the entire legally relevant part of the device cannot be modified without breaking a seal or utilizing a traced update.

    Modifications to legally non-relevant parameters are not verification triggering events.

    9.4 Modifications to legally relevant parameters

    All modifications to legally relevant device-specific parameters are verification triggering events, unless a device is secured with an event logger and is approved with the capability of modifying its configurable parameters, where:

    1. the modifications to legally relevant device specific parameters use values that were previously examined or verified, and
    2. a legally relevant function has been specifically approved as a function that is intended to be utilized with configurable parameters whose values fall within an approved range, all discrete values of that parameter which lie within that range are legally relevant and must be considered as having examined or verified as part of a device's examination or verification process.

    10.0 Documentation

    The device manufacturer must provide an attestation and the following documentation to Measurement Canada in support of their approval request:

    1. A description of the legally relevant software and how the requirements are met, including:
      1. i a list of legally relevant software modules and their version numbers;
      2. ii a description of the software interfaces of the legally relevant software and of the commands and data flows via this interface;
      3. iii a list of parameters to be protected and a description of protection means.
    2. A description of suitable system configuration and minimum required resources.
    3. A description of the security means of the operating system, if applicable.
    4. A description of the protective means.
    5. A description of the system hardware (e.g., visual representation of device components, connections, type of computer, and type of network). Where a component is deemed legally relevant or where it performs legally relevant functions, this must also be identified.
    6. A description of the correctness of the measuring algorithm(s).
    7. A description of the user interface, menus, and dialogues.
    8. A description of the software identification and instructions for obtaining it from the device in use.
    9. A list of commands of each hardware interface of the measuring device or component.
    10. A list of durability errors that are detected by the software and, if necessary for understanding, a description of the detecting algorithm.
    11. A description of the sealing method(s).
    12. A description of how the authenticity of the software identification is guaranteed.
    13. A description of how the integrity of the software is guaranteed.
    14. A description of how it is assured that the downloaded software is approved for the type of device to which it has been downloaded.
    15. A description of data sets stored or transmitted.
    16. A list of significant defects that are detected and a description of detecting algorithm.
    17. A description of how the device ensures that the legally relevant software, device specific parameters and measurement data are not subject to any inadmissible influence by commands received via the interface(s).
    18. Where a device has interfaces for communicating with other electronic devices, a list identifying the interface(s), menu(s), and dialogue(s).
    19. If an event logger is realised in the software, a description of how to access the event logger.
    20. If dynamic modules of legally relevant software are present:
      1. a description of the prioritization of using all legally relevant parts, including dynamic modules of legally relevant software;
      2. a description of the means to validate the conformity of devices in use even in the presence of dynamic parameter changes;
      3. Detailed description of dynamic module's algorithm design, training process, and the used training datasets.
    21. The operating manual(s).

    11.0 References

    • OIML D 31: General Requirements for Software-Controlled Measuring Instruments (2023)
    • WELMEC 7.2: Software guide (Measuring Instruments Directive 2014/32/EU) (2023)
 Report a problem
Date modified: