Legal Metrology

MID Extensions Explained: O/L/T/S/D Requirements for WELMEC Guide 7.2

In-depth analysis of the five extension modules in the MID Software Guide: Operating System O, Storage L, Transmission T, Separation S, Download D, covering technical requirements and Class C compliance points for each extension.

Published on March 14, 2026

12 min read

MID Extensions Explained: O/L/T/S/D Requirements for WELMEC Guide 7.2

In the MID (Measuring Instruments Directive) software compliance framework, Extensions are additional security requirements established for measuring instruments with specific functionalities or architectures. WELMEC Guide 7.2 defines five major extension modules: O (Operating System), L (Storage), T (Transmission), S (Separation), D (Download).

This article provides a comprehensive analysis of the technical requirements for these five extension modules, helping you understand the key software compliance points for Class C instruments.

Extension Overview

Extension Code	Name	Applicable Scenarios	Core Focus
Extension O	Operating System	Systems using general-purpose OS	OS security configuration
Extension L	Storage	Measurement data persistence	Data integrity protection
Extension T	Transmission	Remote data communication	Transmission security and integrity
Extension S	Separation	Coexistence of regulated/non-regulated functions	Software separation and access control
Extension D	Download	Remote software updates	Trusted download and version management

Extension O: Operating System Security Configuration

Scope

When measuring instruments run on general-purpose operating systems (such as Windows, Linux, VxWorks, etc.), they must meet the requirements of Extension O.

O1: Operating System Identification

Instruments must be able to uniquely identify the operating system version and configuration they are running:

Example identification information:
- OS name and version (e.g., Windows 10 IoT Enterprise 21H2)
- Security patch level
- Kernel version
- Key security configuration status

O2: Security Baseline Configuration

The operating system must be security-hardened according to the principle of least privilege:

O2.1 Account Security

Disable default accounts or enforce default password changes
Implement strong password policies (minimum length, complexity, expiration policies)
Enable account lockout mechanisms

O2.2 Service Management

Disable unnecessary services and ports
Restrict permissions for running services
Isolate service-to-service communication

O2.3 Network Protection

Configure firewall rules
Disable unnecessary network protocols
Restrict remote access

O3: Security Monitoring and Auditing

The operating system must record and monitor critical security events:

Monitoring Category	Key Events
Account Management	Login/logout, permission changes, account creation/deletion
System Configuration	Security policy modifications, service start/stop, configuration file changes
File Access	Regulated software directory access, configuration file modifications
Network Activity	Anomalous connections, port scanning, data transmission anomalies

Class C Special Requirements

For Class C instruments, Extension O also requires:

O4: Integrity Verification: Verify the integrity of critical operating system components at startup
O5: Recovery Mechanism: Provide secure configuration recovery or reset functionality
O6: Update Management: Verification, testing, and deployment processes for security updates

Extension L: Measurement Data Storage and Protection

Scope

When instruments store measurement data in non-volatile storage media, they must meet the requirements of Extension L.

L1: Storage Integrity

Stored measurement data must be protected from unauthorized modification:

L1.1 Data Structure Requirements

Recommended data storage format:
┌─────────────────────────────────────┐
│  Data Header                         │
│  - Data version number               │
│  - Instrument serial number          │
│  - Storage timestamp                 │
├─────────────────────────────────────┤
│  Measurement Data                    │
│  - Reading values                    │
│  - Measurement time                  │
│  - Associated parameters             │
├─────────────────────────────────────┤
│  Integrity Protection                │
│  - Digital signature or MAC          │
│  - Checksum/Hash value               │
└─────────────────────────────────────┘

L1.2 Write Protection Mechanisms

Atomic Write: Use transactions or logs to ensure data consistency
Pre-write Verification: Verify data validity before writing
Version Control: Retain historical versions or change logs

L2: Storage Security

Prevent unauthorized access to stored data:

L2.1 Access Control

Implement Role-Based Access Control (RBAC)
Log all data access operations
Restrict export of raw data

L2.2 Encryption Protection (Class C Requirement)

Use encryption algorithms compliant with FIPS 140-2 or equivalent standards
Key management: generation, storage, rotation, destruction
Recommended algorithms: AES-256 (encryption), SHA-256 (integrity)

L3: Storage Lifecycle Management

L3.1 Data Retention Policy

Data lifecycle:
Creation → Verification → Storage → Archive → Destruction
    ↑          ↑             ↑           ↑           ↑
 Integrity   Integrity    Access      Integrity   Secure
   Check      Check       Control      Check       Erase

L3.2 Data Recovery

Provide data backup and recovery mechanisms
Verify integrity of recovered data
Record recovery operations

Class C Special Requirements

L4: Tamper-Resistant Storage: Use tamper-resistant hardware or immutable logs
L5: Audit Trail: Complete audit log of storage operations
L6: Disaster Recovery: Data recovery capability in disaster scenarios

Extension T: Data Transmission Integrity and Security

Scope

When instruments transmit measurement data or control commands through networks, buses, or other means, they must meet the requirements of Extension T.

T1: Transmission Integrity

Ensure data is not tampered with during transmission:

T1.1 Protocol Requirements

Recommended protocol stack:

Application Layer: Custom protocol or standard protocol (Modbus, IEC 62056, etc.)
  ↓
Security Layer: TLS/DTLS or IPsec (optional, T3 requirement)
  ↓
Transport Layer: TCP/UDP
  ↓
Network Layer: IP

T1.2 Message Format

{
  "header": {
    "message_id": "MSG-2026-03-14-001",
    "timestamp": "2026-03-14T10:30:00Z",
    "source_id": "METER-12345",
    "destination_id": "SERVER-001"
  },
  "payload": {
    "measurement_data": {...},
    "control_commands": {...}
  },
  "integrity": {
    "signature": "HMAC-SHA256(hash)",
    "sequence_number": 1234
  }
}

T2: Transmission Reliability

T2.1 Error Detection and Handling

Checksum Mechanism: CRC, checksum, or MAC
Retransmission Strategy: Acknowledgment-Retransmission (ACK-NACK) mechanism
Timeout Handling: Set reasonable timeout periods

T2.2 Sequence Number Management

Each message contains a unique incrementing sequence number
Detect duplicate, lost, or out-of-order messages
Sequence number reset mechanism

T3: Transmission Security (Class C Mandatory)

For Class C instruments, transmission security must be implemented:

T3.1 Encryption Requirements

Scenario	Minimum Requirement	Recommended Solution
LAN Communication	TLS 1.2	TLS 1.3
Internet Communication	TLS 1.2 + Strong cipher suites	TLS 1.3 + mTLS
Serial/Bus Communication	Application-layer encryption	AES-128

T3.2 Authentication

Mutual authentication (mTLS) or certificate-based authentication
Certificate management: issuance, renewal, revocation
Key exchange: ECDHE, DHE

Class C Special Requirements

T4: Anti-Replay: Timestamp + sequence number + nonce combination
T5: Session Management: Session establishment, maintenance, termination
T6: Security Monitoring: Transmission security event monitoring and alerting

Extension S: Regulated/Non-Regulated Software Separation

Scope

When instruments simultaneously run regulated metrology software and non-regulated software, they must meet the requirements of Extension S.

S1: Software Separation Architecture

S1.1 Three-Layer Separation Model

┌────────────────────────────────────────────┐
│         Non-Regulated Software Layer        │
│  - User interface extensions                │
│  - Data analysis tools                      │
│  - Remote monitoring (non-measurement data) │
└────────────────────────────────────────────┘
                  ↑ Controlled Interface
┌────────────────────────────────────────────┐
│         Middleware/API Layer (Interface)    │
│  - Data access control                      │
│  - Permission verification                  │
│  - Audit logging                            │
└────────────────────────────────────────────┘
                  ↑ Controlled Interface
┌────────────────────────────────────────────┐
│         Regulated Software Layer            │
│  - Measurement algorithms                   │
│  - Metrology data processing                │
│  - Regulated records                        │
└────────────────────────────────────────────┘

S1.2 Interface Control Principles

Unidirectional Data Flow: Non-regulated software can read data but cannot modify it
Minimum Privilege: Expose only necessary API interfaces
Input Validation: Validate all inputs from non-regulated software

S2: Access Control

S2.1 Role Definition

Role	Regulated Software Access	Non-Regulated Software Access	Configuration Modification
Manufacturer	Full Access	Full Access	Allowed
Metrology Authority	Read Only	Read Only	Audit logs only
End User	Read Only	As configured	Prohibited

S2.2 Access Control Implementation

# Pseudocode example
def access_control_request(user, resource, operation):
    # 1. Verify user identity
    if not authenticate(user):
        return "FORBIDDEN"

    # 2. Check resource type
    if resource.type == "REGULATED":
        # 3. Strict check for regulated resources
        if not has_regulated_permission(user, operation):
            log_security_event(user, resource, operation, "DENIED")
            return "FORBIDDEN"
    else:
        # 4. Regular check for non-regulated resources
        if not has_permission(user, operation):
            return "UNAUTHORIZED"

    # 5. Log access
    log_access(user, resource, operation, "ALLOWED")
    return "ALLOWED"

S3: Separation Verification

S3.1 Architecture Verification Requirements

S3.1.1: Demonstrate that non-regulated software cannot bypass interfaces to directly access regulated software
S3.1.2: Verify the effectiveness of interface input validation
S3.1.3: Confirm the completeness and non-bypassability of access control

S3.2 Testing Methods

Test Type	Purpose	Method
Penetration Testing	Discover privilege bypass paths	Simulated attacker attempts
Interface Fuzzing	Verify input robustness	Abnormal input testing
Regression Testing	Ensure modifications don’t affect separation	Continuous integration testing

Class C Special Requirements

S4: Runtime Monitoring: Monitor the regulated software runtime environment to detect anomalies
S5: Integrity Protection: Integrity protection for regulated software code and configuration
S6: Emergency Isolation: Isolation mechanism when threats are detected

Extension D: Regulated Software Download

Scope

When instruments support remote updating or installation of regulated metrology software, they must meet the requirements of Extension D.

D1: Download Integrity

D1.1 Software Package Format

Regulated software package structure:
meter-firmware-v2.3.1.pkg
├── manifest.json          # Manifest file
├── firmware.bin           # Actual firmware
├── signature.der          # Digital signature
├── certificate-chain.pem  # Certificate chain
└── checksum.txt           # Checksum

D1.2 Manifest File Example

{
  "package_id": "FIRM-2026-03-14-v2.3.1",
  "version": "2.3.1",
  "manufacturer": "ACME Meter Co.",
  "target_hardware": ["METER-X1", "METER-X2"],
  "compatible_from": "2.0.0",
  "build_date": "2026-03-14T00:00:00Z",
  "components": [
    {
      "name": "firmware.bin",
      "size": 1048576,
      "sha256": "a1b2c3d4...",
      "signed": true
    }
  ],
  "signature": "RSASSA-PKCS1v15_SHA256"
}

D2: Download Security

D2.1 Download Process

1. Discovery Phase
   Instrument → Query latest version → Server
   Server ← Return version information → Instrument

2. Verification Phase
   Instrument → Request download → Server
   Server ← Return package + signature → Instrument
   Instrument → Verify signature and integrity

3. Installation Phase
   Instrument → Backup current version
   Instrument → Install new version
   Instrument → Verify installation result

4. Activation Phase
   Instrument → Restart or activate new version
   Instrument → Log update event

D2.2 Signature Verification

# Pseudocode example
def verify_software_package(package):
    # 1. Verify certificate chain
    if not verify_certificate_chain(package.certificate_chain):
        return "INVALID_CERTIFICATE"

    # 2. Verify signature
    if not verify_signature(
        package.manifest,
        package.signature,
        package.certificate
    ):
        return "INVALID_SIGNATURE"

    # 3. Verify hash
    for component in package.components:
        calculated_hash = sha256(component.data)
        if calculated_hash != component.sha256:
            return "CHECKSUM_MISMATCH"

    # 4. Verify compatibility
    if not is_compatible(package.version, current_version):
        return "INCOMPATIBLE_VERSION"

    return "VALID"

D3: Version Management

D3.1 Version Compatibility Rules

Backward Compatibility: New versions should be compatible with old version data formats
Upgrade Path: Support upgrades from multiple historical versions
Downgrade Protection: Prevent unauthorized downgrades

D3.2 Rollback Mechanism

Rollback Type	Trigger Condition	Implementation Method
Automatic Rollback	Installation failure, verification failure	Automatic backup restoration
Manual Rollback	Functional issues, performance problems	Command-triggered rollback
Emergency Rollback	Critical defects	Diagnostic port trigger

D4: Download Auditing

D4.1 Events That Must Be Recorded

Event Type	Recorded Content
Download Request	Timestamp, source IP, requested version
Download Start	Package ID, size, hash value
Verification Result	Signature verification, integrity verification results
Installation Process	Start time, completion time, error information
Installation Result	Success/failure, final version, rollback information

Class C Special Requirements

D5: Code Signing: Use EV code signing certificates
D6: Secure Boot: Secure Boot or equivalent mechanism
D7: Differential Updates: Support differential updates to reduce transmission volume
D8: Batch Updates: Secure batch update management

Extension Interactions and Combinations

Common Extension Combinations

Instrument Type	Typical Extension Combination	Description
Smart Electricity Meter	O+L+T+S+D	Full feature set
Simple Counter	L	Local storage only
Network Scale	T+S	Data transmission + separation
Portable Instrument	L+D	Storage + updates

Dependencies Between Extensions

                    Extension D (Download)
                          ↓
                    Extension O (OS)
                          ↓
    ┌─────────┬─────────┼─────────┬─────────┐
    ↓         ↓         ↓         ↓         ↓
Extension L  Extension T  Extension S  Other Features
  (Storage)   (Transmission)  (Separation)

Explanation:

Download (D) typically requires an Operating System (O)
Storage (L) and Transmission (T) can be implemented independently
Separation (S) depends on good architectural design

Implementation Recommendations

1. Early Planning

Consider extension requirements during the product design phase, not as an afterthought:

Requirements Analysis → Architecture Design → Extension Identification → Risk Assessment → Implementation Plan

2. Phased Implementation

Implement extension requirements in phases according to priority:

Phase	Priority Implementation	Rationale
Phase 1	L (Storage)	Basic functionality, minimal impact
Phase 2	S (Separation)	Architecture-related, requires early implementation
Phase 3	T (Transmission)	Feature enhancement
Phase 4	D (Download)	High complexity, implement last
Ongoing	O (OS)	Continuous maintenance

3. Documentation

Maintain complete extension compliance documentation:

Extension Identification Document: Explain which extensions apply to the instrument
Design Document: Detailed description of how each extension requirement is met
Test Reports: Evidence of extension implementation verification
User Manual: Explanation of extension-related features and usage methods

Summary

The five major MID extensions form important supplements to software compliance:

Extension O ensures secure configuration of general-purpose operating systems
Extension L protects storage integrity of measurement data
Extension T guarantees security and reliability of data transmission
Extension S achieves effective separation of regulated and non-regulated software
Extension D provides secure software update mechanisms

Correctly understanding and implementing these extension requirements is key to ensuring measuring instruments comply with the MID Directive and successfully enter the EU market.

References

WELMEC Guide 7.2 - Software Guide (Measuring Instruments Directive 2014/32/EU)
MID 2014/32/EU - Directive 2014/32/EU of the European Parliament
OIML D 31 - General requirements for software-controlled measuring instruments
EN 12439 - Software for household weigh scales

This document provides an overview interpretation of MID extension requirements. For specific implementation, please refer to official guidelines and consult professional metrology authorities.

MID Electricity Meters: MI-003 Requirements and Software Assessment

In-depth analysis of software assessment requirements for active energy meters under the MID framework, including MI-003 standard, fault detection and recovery, accumulated data protection, multi-tariff registers, software download time limits, and other key technical points.

March 14, 2026

MID Software Evaluation Introduction: Complete Guide to WELMEC Guide 7.2

Detailed explanation of software requirements for the EU Measuring Instruments Directive MID 2014/32/EU. This article covers the core content of WELMEC Guide 7.2, Type P/U classifications, risk class system, and compliance requirements.

March 14, 2026

MID Risk Classes Explained: Class B/C/D Requirements Analysis

Detailed explanation of the MID software risk classification system (Class B/C/D). This article provides an in-depth analysis of requirements across three dimensions: software protection, examination, and consistency, with a focus on the critical binary code consistency requirements for Class C.

March 14, 2026

Back to Knowledge

MID Extensions Explained: O/L/T/S/D Requirements for WELMEC Guide 7.2

MID Extensions Explained: O/L/T/S/D Requirements for WELMEC Guide 7.2

Extension Overview

Extension O: Operating System Security Configuration

Scope

O1: Operating System Identification

O2: Security Baseline Configuration

O2.1 Account Security

O2.2 Service Management

O2.3 Network Protection

O3: Security Monitoring and Auditing

Class C Special Requirements

Extension L: Measurement Data Storage and Protection

Scope

L1: Storage Integrity

L1.1 Data Structure Requirements

L1.2 Write Protection Mechanisms

L2: Storage Security

L2.1 Access Control

L2.2 Encryption Protection (Class C Requirement)

L3: Storage Lifecycle Management

L3.1 Data Retention Policy

L3.2 Data Recovery

Class C Special Requirements

Extension T: Data Transmission Integrity and Security

Scope

T1: Transmission Integrity

T1.1 Protocol Requirements

T1.2 Message Format

T2: Transmission Reliability

T2.1 Error Detection and Handling

T2.2 Sequence Number Management

T3: Transmission Security (Class C Mandatory)

T3.1 Encryption Requirements

T3.2 Authentication

Class C Special Requirements

Extension S: Regulated/Non-Regulated Software Separation

Scope

S1: Software Separation Architecture

S1.1 Three-Layer Separation Model

S1.2 Interface Control Principles

S2: Access Control

S2.1 Role Definition

S2.2 Access Control Implementation

S3: Separation Verification

S3.1 Architecture Verification Requirements

S3.2 Testing Methods

Class C Special Requirements

Extension D: Regulated Software Download

Scope

D1: Download Integrity

D1.1 Software Package Format

D1.2 Manifest File Example

D2: Download Security

D2.1 Download Process

D2.2 Signature Verification

D3: Version Management

D3.1 Version Compatibility Rules

D3.2 Rollback Mechanism

D4: Download Auditing

D4.1 Events That Must Be Recorded

Class C Special Requirements

Extension Interactions and Combinations

Common Extension Combinations

Dependencies Between Extensions

Implementation Recommendations

1. Early Planning

2. Phased Implementation

3. Documentation

Summary

References

Tags

Share this

You might also like

MID Electricity Meters: MI-003 Requirements and Software Assessment

MID Software Evaluation Introduction: Complete Guide to WELMEC Guide 7.2

MID Risk Classes Explained: Class B/C/D Requirements Analysis