MID Software Evaluation Introduction: Complete Guide to WELMEC Guide 7.2

Executive Summary

The European Union Measuring Instruments Directive (MID) 2014/32/EU is the core regulatory framework in the field of metrology in the EU, setting out comprehensive essential requirements for measuring instruments placed on the EU market. With the widespread application of software technology in measuring instruments, the reliability, security, and integrity of software directly affect the accuracy and credibility of measurement results. The WELMEC (European Cooperation in Legal Metrology) Guide 7.2 Software Guide provides manufacturers and certification bodies with a technical framework for understanding and implementing MID software requirements.

This article provides a comprehensive introduction to the core content of MID software evaluation from multiple dimensions, including MID directive overview, WELMEC Guide 7.2 framework, Type P/U classification system, risk class classification, compliance paths, and typical application scenarios, providing a systematic introductory guide for measuring instrument manufacturers and certification bodies.

I. MID Directive Overview

1.1 Regulatory Background and Objectives

MID 2014/32/EU was enacted on February 26, 2014, replacing the previous 2004/22/EC Directive, and is a mandatory regulation in the field of measuring instruments in the EU. The main objectives of this directive are:

• Protect Consumer Rights: Ensure that measuring instruments used for commercial transactions have sufficient accuracy and reliability
• Promote Market Unification: Eliminate technical barriers between member states and establish a unified EU market
• Prevent Metering Fraud: Prevent manipulation of measurement results through software vulnerabilities by technical means
• Ensure Fair Trading: Provide a credible metrological foundation for commercial transactions

MID applies to ten categories of measuring instruments, including water meters, gas meters, electricity meters, heat meters, weighing instruments, taximeters, etc. The measurement results of these instruments are directly used for trade settlement, legal evidence, or medical diagnosis, and their accuracy has significant social and economic impacts.

1.2 Essential Requirements of MID

MID Annex I specifies the Essential Requirements that all measuring instruments must meet, covering the following key areas:

Requirement Category	Main Content	Software Relevance
Suitability (Annex I-7)	Instruments must not have features that facilitate fraud	Highly relevant, prevent software tampering
Tamper Protection (Annex I-8)	Prevent external intervention and unauthorized modification	Core section, foundation of software protection
Result Display (Annex I-10)	Prominence, readability, and indelibility of measurement results	Requirements for software display functions
Reliability (Annex I-6)	Fault detection, backup and recovery capabilities	Software fault tolerance and recovery mechanisms

graph TD
    A[MID 2014/32/EU] --> B[Annex I: Essential Requirements]
    B --> C[Suitability I-7]
    B --> D[Tamper Protection I-8]
    B --> E[Result Display I-10]
    B --> F[Reliability I-6]
    B --> G[Conformity Assessment I-12]

    C --> H[Prevent Fraud Features]
    D --> I[Prevent Unauthorized Intervention]
    E --> J[Authentic Data Display]
    F --> K[Fault Detection Recovery]
    G --> L[Type Examination Procedure]

    style A fill:#e1f5ff
    style B fill:#fff4e1
    style D fill:#ffe1e1

1.3 Certification Process Overview

MID adopts a modular conformity assessment system, allowing manufacturers to select appropriate assessment modules based on product characteristics:

• Module B: EU-type Examination - The most commonly used module, where a third-party certification body (Notified Body) evaluates the instrument design
• Module D: Production Quality Assurance - Adds quality assurance requirements for the production process based on Module B
• Module F: Product Verification - Piece-by-piece verification of manufactured instruments

For software-related products, type examination (Module B) is the most common certification path. In this process, the certification body needs to verify whether the software design of the instrument complies with the essential requirements of MID, and WELMEC Guide 7.2 is precisely the technical guide for conducting this assessment.

II. WELMEC Guide 7.2 Framework

2.1 Guide Overview and Versions

WELMEC Guide 7.2, fully titled “Software Guide (EU Measuring Instruments Directive 2014/32/EU)”, is an official technical guide published by WELMEC for interpreting and implementing the software-related requirements of MID. The latest version of this guide is the 2023 edition, which is the authoritative reference document for MID software compliance review.

The core value of the guide lies in:

1. Unified Interpretation Standards: Provide unified technical interpretation for certification bodies of member states to avoid implementation differences
2. Provide Operational Guidelines: Provide specific design and implementation guidance for manufacturers
3. Establish Assessment Framework: Provide a systematic software assessment methodology
4. Reduce Compliance Costs: Reduce trial and error costs through clear acceptable solutions

2.2 Modular Structure of the Guide

WELMEC Guide 7.2 adopts a highly modular structural design, which allows software requirements to flexibly adapt to different types of measuring instruments:

WELMEC Guide 7.2 Structure
│
├── Chapter 3: Risk Class System
│   ├── Risk Factor Analysis (Protection, Examination, Conformity)
│   └── Class A-F Definitions and Application Scenarios
│
├── Chapters 4-5: Basic Configuration Types
│   ├── Type P: Built-for-purpose Device
│   └── Type U: Universal Device
│
├── Chapter 6: Operating System Extension (Extension O)
│   └── Security Configuration Requirements for General Operating Systems
│
├── Chapters 7-10: IT Function Extensions
│   ├── Extension L: Measurement Data Storage (L1-L8)
│   ├── Extension T: Measurement Data Transmission (T1-T8)
│   ├── Extension S: Software Separation (S1-S3)
│   └── Extension D: Software Download (D1-D4)
│
├── Chapter 11: Instrument-Specific Requirements (Extension I)
│   ├── I1: Water Meters
│   ├── I2: Gas Meters and Volume Conversion Devices
│   ├── I3: Electricity Meters (Focus)
│   └── I4-I11: Other Instrument Types
│
└── Chapter 13: MID Clause Cross-Reference
    └── Mapping Between Software Requirements and MID Regulatory Clauses

The advantage of this modular design is that manufacturers can apply only relevant extension requirements based on the specific functions of the product, without needing to meet all clauses. For example, if the instrument does not have data storage functionality, the requirements of Extension L do not apply.

2.3 Core Definitions and Concepts

Understanding WELMEC Guide 7.2 requires mastering the following core concepts:

Legally Relevant Software

Refers to software components that directly affect measurement results or compliance with MID essential requirements. Determining whether software is legally relevant requires considering the following factors:

• Whether it participates in the generation, processing, or display of measurement data
• Whether it affects the accuracy or stability of measuring instruments
• Whether it involves user-settable parameters (such as calibration factors)
• Whether it protects measurement data from unauthorized access

Device-Specific Parameters

Parameters related to specific instrument instances that directly affect the accuracy of measurement results, including:

• Calibration factors
• Linearization factors
• Transformer ratios
• Register configurations
• Other parameters affecting measurement results

Software Separation

Dividing the software of measuring instruments into legally relevant software modules and non-legally relevant software modules, communicating through a Protective Interface. This separation ensures that even if non-legal software exists, the integrity of legal software and the reliability of measurement data can be guaranteed.

Audit Trail

A timestamped logging system used to record legally relevant events (such as parameter changes, software updates). The audit trail should satisfy:

• Automatically generated without manual intervention
• Stored in non-volatile memory
• Cannot be deleted or modified without breaking the seal
• Can be displayed on a display or printed upon command

III. Type P and Type U Classification

3.1 Type P: Built-for-purpose Device

Type P (Built-for-purpose Device) refers to an embedded IT system built specifically for a particular metrology task, with core characteristics including:

Technical Characteristics

• Embedded IT System: Built based on microprocessors or microcontrollers
• Dedicated Software Environment: All software is built for metrology purposes
• Dedicated User Interface: Interface dedicated to metrology operations
• Immutable Software Environment: No internal or external programming tools
• Closed Architecture: Does not allow loading or changing modules, parameters, or data

Typical Applications

• Traditional electricity meters, water meters, gas meters
• Embedded metrology controllers
• Dedicated measuring instruments

Advantages and Limitations

Advantages:

• Relatively closed software environment with higher security
• Fixed system functionality, easy to verify
• Lower resource requirements

Limitations:

• Limited functional extensibility
• Limited user interface customization capabilities
• More complex upgrades and maintenance

3.2 Type U: Universal Device

Type U (Universal Device) refers to measuring instruments built on general-purpose computing platforms (such as PCs, tablet computers), with core characteristics including:

Technical Characteristics

• General Operating System: Runs general operating systems such as Windows, Linux
• Open Software Environment: Can install multiple applications
• General User Interface: Uses standard input/output devices
• Programmable Environment: Supports software development and debugging tools
• Network Connectivity: Has multiple communication interfaces

Typical Applications

• PC-based metrology systems
• Tablet-based portable measuring equipment
• Industrial PC metrology workstations

Advantages and Limitations

Advantages:

• Strong functional extensibility
• User-friendly interface
• Convenient development and maintenance

Limitations:

• Open software environment with significant security challenges
• High system complexity, difficult to verify
• Requires stronger security measures

3.3 Comparison of Type P and Type U Requirements

Requirement Category	Type P	Type U	Main Differences
Documentation Requirements	P1	U1	U1 requires description of operating system configuration
Software Identification	P2	U2	Basically the same
User Interface Protection	P3	U3	U3 faces higher risks
Communication Interface Protection	P4	U4	U4 needs to consider network risks
Software Integrity	P5-P6	U5-U6	U5-U6 requires stronger protection
Parameter Protection	P7	U7	Basically the same
Data Display	P8	U8	Basically the same

Important Regulation: WELMEC Guide 7.2 explicitly stipulates that the risk class of Type U devices cannot be lower than Class C, meaning the minimum applicable class for Type U devices is Class C. This is because the software environment of universal devices is more open and faces higher security risks.

IV. Risk Class System

4.1 Three Dimensions of Risk Assessment

WELMEC Guide 7.2 conducts risk assessment based on three core dimensions:

Software Protection

The ability to prevent unauthorized software modification, divided into three levels:

• Low: No special requirements
• Middle: Prevent intentional modification using ordinary software tools (such as text editors)
• High: Prevent intentional modification using advanced tools (such as debuggers, disk editors)

Software Examination

Ensure that software can be verified and reviewed, divided into three levels:

• Low: Standard functional testing
• Middle: Documentation-based inspection + sampling testing
• High: In-depth analysis at source code level

Software Conformity

Guarantee the consistency between software and the certified type, divided into three levels:

• Low: Functionality consistent with type documentation
• Middle: Binary code of legal software identical to type-examined software
• High: Complete software binary code identical to type-examined software

4.2 Risk Class Classification

Based on the combination of the above three dimensions, WELMEC defines six risk classes (Class A-F):

Risk Class	Protection	Examination	Conformity	Typical Applications
Class A	Low	Low	Low	Reserved, not currently used
Class B	Middle	Middle	Low	Low-risk instruments
Class C	Middle	Middle	Middle	Electricity meters, water meters, gas meters
Class D	High	Middle	Middle	High-value transaction instruments
Class E	High	High	Middle	Reserved, not currently used
Class F	High	High	High	Reserved, not currently used

graph LR
    A[Risk Assessment] --> B[Class B]
    A --> C[Class C]
    A --> D[Class D]

    B --> B1[Low Conformity<br>Functional Consistency Sufficient]
    C --> C1[Middle Conformity<br>Binary Code Identical]
    D --> D1[High Protection<br>Prevent Professional Tool Attacks]

    style C fill:#ffe1e1
    style C1 fill:#ffe1e1

4.3 Detailed Explanation of Class C Risk Class

Class C is the most widely used risk class, applicable to most utility meters (electricity meters, water meters, gas meters, etc.).

Core Characteristics of Class C

• Software Protection: Middle level, needs to prevent intentional modification using ordinary software tools
• Software Examination: Middle level, documentation-based inspection + sampling testing
• Software Conformity: Middle level, requires binary code of legal software to be identical to type-examined software

Key Technical Requirements of Class C

Requirement Number	Requirement Name	Class C Focus
P2/U2	Software Identification	Legal software clearly identified, permanently displayed or command-displayed
P6/U6	Software Protection	Checksum mechanism, key length ≥ 4 bytes
P7/U7	Parameter Protection	Audit trail records parameter changes
P8/U8	Data Display	Authenticity and traceability of measurement data
L1-L8	Storage Protection	Integrity and traceability of stored data
T1-T8	Transmission Protection	Integrity and security of transmitted data

Binary Code Conformity Requirements of Class C

The core difference between Class C and Class B lies in the elevation of software conformity requirements:

• Class B: Only requires that the functionality of legal software is consistent with the type documentation, binary code need not be identical
• Class C: Requires that the binary code of legal software of individual instruments be completely identical to the type-examined software

This requirement ensures:

1. Prevention of circumventing type examination by replacing software
2. Every manufactured instrument undergoes the same verification as the certified design
3. Provision of a reliable foundation for metrological traceability

Implementing binary code conformity requires:

• Establishing a comprehensive software identification system
• Controlled software installation process
• Checksum or digital signature verification mechanism

V. Extension Requirement Modules

5.1 Extension L: Measurement Data Storage

Applicable to measuring instruments with functions for long-term storage of measurement data, ensuring the integrity, authenticity, and confidentiality of stored data.

Class C Key Requirements

Requirement Number	Requirement Name	Main Content
L1	Stored Data Integrity	Stored measurement data contains all relevant information
L2	Prevention of Accidental Changes	Protect stored data from accidental or unintentional changes
L3	Data Integrity	Use encryption, signatures, etc. to prevent intentional tampering
L4	Data Traceability	Stored data can be traced back to original measurement activities
L6	Data Retrieval	Legally relevant components must exist to retrieve, verify, and display stored data
L7	Automatic Storage	Measurement data is automatically stored at the end of measurement

Typical Application Scenarios

• Load profile recording of smart electricity meters
• Water consumption history data of water meters
• Daily consumption records of gas meters

5.2 Extension T: Measurement Data Transmission

Applicable to measuring instruments that transmit measurement data through communication networks, ensuring the security and reliability of data during transmission.

Class C Key Requirements

Requirement Number	Requirement Name	Main Content
T1	Transmitted Data Integrity	Transmitted data contains all necessary information
T2	Prevention of Accidental Changes	Protect transmitted data from accidental changes
T3	Data Integrity	Use encryption technology to prevent intentional tampering
T4	Data Traceability	Transmitted data can be traced back to original measurement activities
T5	Key Confidentiality	Transmission encryption keys are properly protected
T6	Corrupted Data Handling	Receiver can detect and handle corrupted data

Typical Application Scenarios

• AMI/AMR systems for smart grids
• Remote meter reading systems
• IoT metering devices

5.3 Extension S: Software Separation

Applicable to measuring instruments that need to coexist with legally relevant software and non-legally relevant software.

Key Requirements

Requirement Number	Requirement Name	Main Content
S1	Software Separation Implementation	Clearly separate legal software and non-legal software modules
S2	Mixed Display	Legal software displays and non-legal software displays are clearly distinguishable
S3	Protective Interface	Two types of software interact only through protective interfaces

Typical Application Scenarios

• Smart instruments with diagnostic functions
• Metering equipment supporting third-party applications
• Measuring instruments with user-customizable functions

5.4 Extension D: Software Download

Applicable to measuring instruments that allow downloading of legally relevant software after being put into service, ensuring the security of the download process.

Class C Key Requirements

Requirement Number	Requirement Name	Main Content
D1	Download Mechanism	Two phases of download (transfer and installation) run automatically
D2	Downloaded Software Authentication	Use technical means to ensure the authenticity of downloaded software sources
D3	Downloaded Software Integrity	Ensure downloaded software is not changed during transmission
D4	Download Traceability	Downloads of legally relevant software are appropriately traceable

Typical Application Scenarios

• Remote software upgrade (OTA)
• On-site software updates
• Dynamic loading of functional modules

VI. Compliance Path and Implementation

6.1 Type Examination Preparation

Before conducting MID type examination, manufacturers should prepare the following technical documentation:

Core Documentation Checklist

1. Software Function Description

   • Division of legally relevant software modules
   • Data flow description
   • Key algorithm description

2. Software Identification Documentation

   • Software identifier generation rules
   • Identifier display methods
   • Identifier protection mechanisms

3. System Hardware Overview

   • Topology block diagram
   • Computer types
   • Network configuration

4. User Interface Description

   • Menu structure
   • Dialog box functions
   • Operation procedures

5. Operation Manual

   • Safety instructions
   • Calibration procedures
   • Maintenance guidelines

Documentation Preparation Points

• Clearly distinguish between legal software modules and non-legal software modules
• Provide sufficient technical details to support software examination
• Include the overall design concept of software architecture
• Describe the implementation methods of all protection mechanisms

6.2 Software Identification System Implementation

Software identification is a core requirement of Class C compliance, and the following should be considered during implementation:

Identifier Design Principles

• Uniqueness: Each software version should have a unique identifier
• Verifiability: Identifiers should be capable of being verified and inspected
• Persistence: Identifiers should remain valid throughout the lifecycle
• Readability: Identifiers should be easy to read and recognize

Acceptable Identification Methods

1. Checksum

   • CRC-32 with secret initialization vector
   • SHA-256 hash value
   • Other algorithms with sufficient collision resistance

2. Version String

   • Formatted string including version number
   • Example: “v1.2.3-build456”

3. Hybrid Identifier

   • Legal software uses real identifier
   • Non-legal software uses placeholder (such as “xx”)
   • Example: “abc1.xx” (abc1 is legal software)

Identifier Protection Requirements

• Identifiers are device-specific parameters and should be protected against unauthorized modification
• If the identifier is inextricably linked to the software itself, no additional protection is required
• Otherwise, other protection means (such as seals, encryption) need to be adopted

6.3 Checksum Mechanism Implementation

Checksum is the core technical means of Class C software protection.

Technical Implementation Points

1. Algorithm Selection

   • CRC-32 or stronger algorithms are recommended
   • Key length should be at least 4 bytes
   • Consider national security recommendations for key length requirements

2. Coverage Scope

   • Checksum calculation should cover all legal software modules
   • Clearly define the boundaries of legally relevant software
   • Ensure no critical modules are omitted

3. Self-Check Mechanism

   • Software modules should be able to calculate their own checksums
   • Compare with stored expected values
   • Take appropriate action when self-check fails (prevent execution or trigger alarm)

4. Display Mechanism

   • Checksum or modification indication should be displayable upon command
   • Display method should be clear and understandable
   • Facilitate verification by inspectors

Typical Implementation Scheme

Checksum Protection Implementation Example:
┌─────────────────────────────────────┐
│ 1. Executable code passes checksum protection │
│    - Module calculates its own checksum         │
│    - Compare with expected value hidden in code│
│    - Block module execution if self-check fails │
├─────────────────────────────────────┤
│ 2. Use CRC-32 with secret initialization vector│
│    - Initialization vector hidden in executable │
│    - Provide sufficient collision resistance   │
│    - Key length ≥ 4 bytes                      │
└─────────────────────────────────────┘

6.4 Parameter Protection and Audit Trail

Protection of device-specific parameters is another key requirement of Class C.

Audit Trail System Requirements

Requirement	Description
Automatic Generation	Each parameter change is automatically recorded by legal software
Indelible	Stored in non-volatile memory, cannot be deleted or modified
Complete Content	Includes parameter identifier, parameter value, and timestamp
Accessibility	Can be displayed on a display or printed upon command

Audit Trail Record Content

• Parameter identifier (name)
• Value before parameter change
• Value after parameter change
• Timestamp of change
• Operator identifier of change (if applicable)

Acceptable Implementation Schemes

1. Non-Volatile Storage

   • Use non-volatile memory such as Flash, EEPROM
   • Ensure data is not lost after power failure

2. Seal Protection

   • Audit trail cannot be deleted or modified without breaking the seal
   • Seal can be physical seal or electronic seal

3. Circular Buffer

   • When storage is full, oldest records can be overwritten by new records
   • Ensure recent important events are always traceable

VII. Typical Application Scenarios

7.1 Electricity Meters (MI-003)

Electricity meters are the most widely used area for MID software requirements, usually classified as Class C risk class.

Software Characteristics of Electricity Meters

• Hardware Configuration: Voltage/current measurement, power calculation, energy integration
• Software Configuration: Follows Type P or Type U basic requirements
• Measurement Principle: Continuous accumulation of consumed energy
• Key Functions: Fault detection and recovery, load profile recording, remote meter reading

Class C Electricity Meter Specific Requirements (I3 Series)

Requirement Number	Requirement Name	MID Reference	Class C Focus
I3-1	Fault Recovery	MI-003 Art. 4.3.1	Resume normal processing after interference
I3-2	Non-Legal Software Dynamic Behavior	-	Protection against Adverse Effects
I3-4	Backup Facilities	MI-003 Art. 4.3.1	Regular backup of measurement data
I3-5	Software Download	-	Download time limit (≤1 minute)
I3-6	Cumulative Data Reset Prohibition	MID Annex I Art. 8.5	Prevent reset of measurement data
I3-7	Measurement Result Reading	MID Annex I Art. 10.5	Multi-rate register display
I3-8	Tamper Protection	MI-003	Checksum identification display
I3-9	Display Digits	MI-003 Art. 5.2	Sufficient digits to ensure range

Typical Architecture of Smart Electricity Meters

Smart Electricity Meter Architecture Example:
┌─────────────────────────────────────────┐
│           Legally Relevant Software Modules      │
│  ┌──────────┐  ┌──────────┐  ┌────────┐ │
│  │Metrology Core│  │Data Protection│  │Communication Module│ │
│  │(I3-1/2)  │  │(I3-4/6)  │  │(T1-T8) │ │
│  └──────────┘  └──────────┘  └────────┘ │
│         ↕ Protective Interface (S1-S3)              │
│  ┌──────────┐  ┌──────────┐             │
│  │Load Profile│  │Diagnostic Functions│             │
│  │(L1-L8)   │  │(Non-Legal)  │             │
│  └──────────┘  └──────────┘             │
└─────────────────────────────────────────┘

7.2 Water Meters (MI-001)

Water meters typically adopt Type P architecture and are classified as Class C risk class.

Software Characteristics of Water Meters

• Measurement Principle: Flow sensor signal acquisition and processing
• Typical Architecture: Embedded microcontroller system
• Key Functions: Cumulative flow recording, leak detection, remote communication

Class C Water Meter Specific Requirements (I1 Series)

Requirement Number	Requirement Name	MID Reference	Class C Focus
I1-1	Fault Detection	MI-001 Art. 7.1.1	Electromagnetic Immunity
I1-2	Fault Recovery	MI-001 Art. 7.1.2	Backup facilities, wake-up facilities
I1-3	Cumulative Data Reset Prohibition	MID Annex I Art. 8.5	Prevent reset of measurement data
I1-4	Backup Facilities	MID Annex I-6	Regular backup of measurement data
I1-9	Display Digits	MI-001 Art. 5.2	Sufficient digits to ensure range

7.3 Gas Meters (MI-002)

Gas meters also adopt Type P architecture and are classified as Class C risk class.

Software Characteristics of Gas Meters

• Measurement Principle: Volume conversion and temperature compensation
• Typical Architecture: Embedded microcontroller system
• Key Functions: Volume correction, temperature compensation, remote communication

Class C Gas Meter Specific Requirements (I2 Series)

Requirement Number	Requirement Name	MID Reference	Class C Focus
I2-1	Fault Detection	MI-002 Art. 3.1	Electromagnetic Immunity
I2-2	Fault Recovery	MI-002 Art. 3.1	Backup facilities, wake-up facilities
I2-3	Internal Resolution	MI-002 Art. 5.3	Meet metrological accuracy requirements
I2-4	Cumulative Data Reset Prohibition	MID Annex I Art. 8.5	Prevent reset of measurement data
I2-6	Gas Volume Converter	MI-002 Art. 9.1	Applicable solutions

VIII. Summary and Recommendations

8.1 Core Points of MID Software Evaluation

Through a comprehensive analysis of WELMEC Guide 7.2, the core points of MID software evaluation can be summarized as:

1. Risk Class Selection is the Foundation

   • Correctly selecting the risk class is the first step of compliance
   • Type U devices have a minimum of Class C
   • Electricity meters, water meters, and gas meters are typically Class C

2. Binary Code Conformity is Key

   • Class C requires binary code of legal software to be identical to type-examined software
   • This is the core difference between Class C and Class B
   • Need to establish a comprehensive software identification and version control system

3. Checksum Mechanism is Core Technology

   • Checksum is the primary means of detecting software modification
   • Algorithm should have sufficient key length (≥4 bytes)
   • Should implement self-check mechanism and display mechanism

4. Documentation Preparation is Certification Foundation

   • Complete technical documentation is a prerequisite for type examination
   • Documentation should clearly distinguish between legal software and non-legal software
   • Should include detailed descriptions of all protection mechanisms

5. Extension Requirements Applied as Needed

   • Only apply extension requirements relevant to product functions
   • Extension L/T applies to devices with storage/transmission functions
   • Extension S applies to devices with software separation needs

8.2 Manufacturer Implementation Recommendations

Product Design Phase

• Define the basic configuration type of the product (Type P or Type U)
• Determine the applicable risk class (usually Class C)
• Identify extension requirements that need to be applied (L/T/S/D)
• Design software architecture to meet protection requirements

Software Development Phase

• Establish a comprehensive software identification system
• Implement checksum protection mechanisms
• Design parameter protection and audit trail
• Ensure software separation (if applicable)

Type Examination Preparation Phase

• Prepare complete technical documentation
• Establish software testing plans
• Conduct internal pre-assessment
• Prepare proof materials for acceptable solutions

Production and Service Phase

• Establish controlled software installation processes
• Ensure shipped software is consistent with type examination samples
• Establish software update management procedures
• Maintain audit trail records

8.3 Certification Body Assessment Recommendations

Assessment Process

1. Documentation Review

   • Verify completeness and accuracy of documentation
   • Check whether the division of legal software modules is reasonable
   • Evaluate whether the design of protection mechanisms is sufficient

2. Functional Testing

   • Verify display and uniqueness of software identification
   • Test effectiveness of checksum mechanisms
   • Check parameter protection and audit trail functions

3. Security Testing

   • Attempt unauthorized software modification
   • Test protection of user interfaces and communication interfaces
   • Verify effectiveness of software separation

Assessment Focus

• Binary code conformity of Class C devices
• Implementation quality of checksum mechanisms
• Completeness and reliability of audit trails
• Uniqueness and verifiability of software identification

---

References

1. WELMEC Guide 7.2 - Software Guide (EU Measuring Instruments Directive 2014/32/EU) Version 2023 - Official software guide published by WELMEC

2. DIRECTIVE 2014/32/EU - Measuring Instruments Directive - EU official measuring instruments directive regulatory text

3. MID Annex I - Essential Requirements - Essential requirements clauses

4. MID Annex MI-003 - Active Electrical Energy Meters - Electricity meter specific requirements

5. WELMEC Guide 7.2 Chapter 3 - Risk Class Definitions - Risk class definitions

6. WELMEC Guide 7.2 Chapter 4 - Type P Requirements - Type P requirements

7. WELMEC Guide 7.2 Chapter 5 - Type U Requirements - Type U requirements

8. WELMEC Guide 7.2 Chapter 7-10 - Extension Requirements - Extension requirements