MID Type P vs Type U: Basic Requirements Comparison

Introduction

Under the European Union Measuring Instruments Directive (MID) framework, measuring instruments are classified into two basic types based on their hardware and software configuration characteristics: Type P (built-for-purpose device) and Type U (universal device). This classification not only reflects differences in technical architecture but also determines the different software compliance requirements they must meet.

WELMEC Guide 7.2 (2023 edition) establishes a detailed software requirements framework for these two device types. This article systematically compares the differences between Type P and Type U across 15 basic requirements, helping measuring instrument manufacturers and certification bodies accurately understand and implement relevant regulatory requirements.

Type P vs Type U: Core Definitions and Technical Characteristics

Type P: Built-for-Purpose Devices

Type P devices are embedded IT systems built specifically for metrological tasks, with typical characteristics including:

• Hardware Architecture: Dedicated computing platforms based on microprocessors or microcontrollers
• Software Design: All software modules are built for metrological purposes
• User Interface: Dedicated to metrological use, operating modes under legal supervision
• Operating System: May include an operating system or subsystem, but all communications must be controlled by legal metrology software
• Software Environment: Immutable,不允许加载或更改模块、参数或数据

Technical Advantage: Due to the closed and immutable software environment, Type P devices have higher inherent security and can be applied to risk levels from Class B to Class D.

Type U: Universal Devices

Type U devices are measuring instruments based on general-purpose computing devices, typically PC-based systems, with typical characteristics including:

• Hardware Architecture: Modular general-purpose computer architecture (can be part of standalone devices, closed networks, or open networks)
• Sensor Configuration: External sensors connected to the computer unit via communication links
• User Interface: Provides non-legal metrology functions in addition to metrological tasks
• Operating System: Typically runs general-purpose operating systems, may simultaneously run other software applications
• Storage Devices: Integrated or removable

Technical Challenge: Due to the open and modifiable software environment, Type U device software is more easily accessible. Regulations explicitly state that Class C is the minimum risk level for Type U devices, and Class B level, which only requires functional correspondence, is not permitted.

Comparison of 15 Basic Requirements

The following table summarizes the main differences between Type P and Type U across core requirements:

Requirement No.	Type P Requirement	Type U Requirement	Key Differences
P1/U1: Documentation Requirements	Software function description, user interface description, software identifier, system hardware overview, operation manual	Additional requirements: OS configuration documentation, more detailed system hardware overview (topology block diagram, computer type, network type)	Type U requires additional OS configuration documentation
P2/U2: Software Identification	Identifier should be permanently displayed, displayed on command, or displayed during operation	Same requirement, but emphasizes that OS part identification refers to O6 requirement	Identification requirements basically consistent
P3/U3: User Interface Impact	Commands must not improperly affect legal metrology software/parameters/data; undocumented commands must not have effects	Same requirement, but stricter protection requirements for open shell environments	Type U requires locking admin accounts and disabling user shells
P4/U4: Communication Interface Impact	Interface commands must not improperly affect legal metrology software/parameters/data; undocumented commands must not have effects	If OS allows remote control, U3 requirements apply to communication interfaces and connected remote terminals	Type U needs to consider remote access scenarios
P5/U5: Legal Metrology Software and Parameters Protection (Unintentional)	Prevent unintentional and accidental changes; detect changes caused by physical effects	Same requirement, emphasizes periodic verification and inspection mechanisms	Protection mechanisms basically consistent
P6/U6: Software and Measurement Data Protection (Intentional)	Prevent intentional changes; provide checksum or equivalent protection methods; prevent storage device replacement	Same requirement, measurement data considered adequately protected only if legal metrology software can process this data	Type U emphasizes data processing permission control
P7/U7: Parameter Protection	Prevent intentional modification; user-settable parameters must be protected by audit trail; parameters can be displayed/printed	Same requirement	Audit trail requirements consistent
P8/U8: Measurement Data Display	Ensure display authenticity; no fraudulent simulation possible; data clearly distinguished; accompanied by complete information	Same requirement: displayed legal metrology measurement data should be clearly distinguished from non-legal metrology data	Display requirements basically consistent

In-Depth Analysis of Core Requirements

1. Documentation Requirements (P1/U1)

Type P Documentation Requirements:

• Functional description of legal metrology related software
• Detailed description of user interfaces, menus, and dialog boxes
• Software identifier for legal metrology software
• System hardware overview
• Operation manual

Type U Additional Requirements:

• Operating system configuration documentation (see Extension O requirements)
• More detailed system hardware overview (topology block diagram, computer type, network type)

Implementation Points: Documentation is the foundation of certification assessment and should be prepared early in product development, ensuring accuracy and completeness. Documentation should clearly distinguish between legal metrology software modules and non-legal metrology software modules.

2. Software Identification (P2/U2)

Core Requirement: Legal metrology software must be clearly identified, with identifiers that should be permanently displayed through the instrument, displayed on command, or displayed during operation.

Identifier Characteristics:

• Uniqueness: Different software versions should have different identifiers
• Identifiability: Identifiers should be easily displayable without additional tools
• Permanence: Identification should be permanently displayed on a protected nameplate, displayed on command, or displayed at startup

Acceptable Implementation Methods:

• Calculate checksum on executable code
• Use strings containing version numbers
• Use any combination of numbers, letters, or other characters

3. Interface Protection (P3/P4 vs U3/U4)

User Interface Protection:

• Each command should have a clear correspondence with the function or data change it triggers
• Commands not documented in documentation must not have effects
• Modules interpreting commands are considered legal metrology software

Communication Interface Protection:

• Type U special requirement: If the operating system allows remote control or remote access, user interface protection requirements apply to communication interfaces and connected remote terminals
• Operating system policies for serial and network connections firewall settings prevent improper command execution

Class C Acceptable Solutions:

• Legal metrology module filters unacceptable commands
• Only that module receives commands and cannot be bypassed
• Use command whitelist mechanism

4. Data Protection (P5/P6 vs U5/U6)

Unintentional Change Protection (P5/U5):

• Detect changes caused by physical effects (electromagnetic interference, temperature, vibration, etc.)
• Implement protection measures against user interface misuse
• Detect accidental modifications through periodic checksum calculation and automatic comparison with stored nominal values

Intentional Change Protection (P6/U6):

• Provide checksum or equivalent protection level methods to support software modification detection
• Calculated checksums should be displayable on command for control purposes
• Storage devices containing software and measurement data should be protected from replacement

Class C Special Requirements:

• Checksum algorithm should have a key length of at least 4 bytes
• Key handling should reference L5 and T5 requirements
• Measurement data is considered adequately protected only if legal metrology software can process this data

5. Audit Trail (P7/U7)

Core Requirement: Device-specific parameters should be protected against intentional modification. Certain device-specific parameters may be set by users but must be protected by facilities that automatically and indelibly record any adjustments.

Audit Trail Recording Content:

• Parameter identifier (such as name)
• Parameter value (current value or value before change)
• Timestamp of change

Implementation Points:

• Audit trail is an information record stored in non-volatile memory
• Each entry is automatically generated by legal metrology software
• Audit trail cannot be deleted or modified without breaking seals
• Audit trail content can be displayed on a display or printed on command

Extension O: Special Requirements for Type U

When Type U instruments are equipped with legal metrology related operating systems (i.e., operating systems used to meet MID basic requirements or capable of affecting compliance), Extension O (General Operating System Extension Requirements) must be applied simultaneously.

Extension O Main Requirements

Requirement No.	Requirement Content
O1: Hardware Protection	Hardware running legal metrology operating system should be protected against intentional changes
O2: Boot Process	Boot process configuration should provide the same configuration environment for legal metrology software execution; boot configuration should be protected from modification
O3: System Resources	Operating system configuration should ensure legal metrology applications have sufficient resources to run
O4: Protection During Use	Operating system configuration should prevent legal metrology software from being improperly affected by OS functions or other software
O5: Protective Interfaces	Operating system functions accessible through open interfaces must not improperly affect legal metrology software, legal metrology parameters, or measurement data

Implementation Points: Operating systems should have multi-user capability and administrator mode. Focus should be on verifying that operating system-level access control configurations are correct.

Risk Levels and Compliance Requirements

Class C Level Definition

Software Protection Level: Middle protection

• Prevent intentional changes using easily available simple general-purpose software tools (such as text editors)
• Basic software protection mechanisms (such as software seals, access control) are necessary

Software Examination Level: Middle examination

• Software examination based on documentation
• Actual testing (spot checks) can be used to verify documentation reasonableness and protection measure effectiveness

Software Conformity Level: Middle conformity

• Binary code of legal software on individual instruments should be identical to legal software from type examination
• Software separation is permitted but must comply with limitations in Extension S

Type P vs Type U Risk Level Differences

Device Type	Minimum Risk Level	Rationale
Type P	Class B	Dedicated software environment provides higher inherent security
Type U	Class C	General-purpose platform software is more easily accessible, must achieve higher protection levels

Conclusions and Recommendations

The core differences between Type P and Type U stem from the different characteristics of their hardware platforms. Type P devices are built specifically for particular metrological purposes, with closed and immutable software environments; Type U devices use general-purpose computing platforms, with open and modifiable software environments. This difference has profound implications for software protection.

Based on WELMEC Guide 7.2 requirements, manufacturers are recommended to focus on the following during product development:

1. Accurately Identify Device Type: Correctly determine whether the device belongs to Type P or Type U based on hardware and software configuration characteristics

2. Establish Comprehensive Documentation Management System: For Type U devices, additionally prepare operating system configuration documentation

3. Implement Multi-Layer Security Protection System: User interfaces and communication interfaces should implement command filtering and verification mechanisms

4. Establish Complete Testing and Verification Process: Testing should cover both normal operation and abnormal scenarios

5. For Type U Devices: Must simultaneously evaluate compliance with Extension O requirements, focusing on operating system-level protection measures

References

1. WELMEC Guide 7.2 Software Guide (EU Measuring Instruments Directive 2014/32/EU) Version 2023
2. MID 2014/32/EU - European Measuring Instruments Directive
3. WELMEC Guide 7.2 Chapter 4: Type P Built-for-Purpose Device Software Requirements
4. WELMEC Guide 7.2 Chapter 5: Type U Universal Device Software Requirements