The Firmware Architecture of a Meter: four levels of customization, one word used for all of them

An OEM is evaluating three suppliers for a custom meter. All three state “customizable firmware” in the commercial datasheet. Six months later, across three separate projects, the three customizations turn out to be completely different things.

With the first supplier, customization means this: the customer opens a configuration tool, renames Modbus register labels, enables or disables some derived measurements, and exports a profile file. The firmware is never modified. Only initialization changes.

With the second, customization means this: the supplier takes its own code base, creates a dedicated fork, modifies the structure of the register table or the logic of an algorithm. The binary is recompiled, internal tests are repeated, and MID certification remains valid or lapses depending on what has been touched.

With the third, customization means this: the customer and supplier work in parallel on the firmware architecture of the meter, not on the application, but on the architecture. The supplier maintains control of the metrological core, while the customer contributes to the definition of the upper layers. The roadmap is shared. MID re-notification is planned in advance, not absorbed as an unexpected consequence.

Three commercially different offers, three technically different offers, three offers aimed at OEMs with different needs. One word to describe them all.

For an OEM writing specifications, understanding where a supplier sits on this spectrum is a strategic decision. For a supplier that wants to position itself seriously in the OEM market, clearly distinguishing the three offers is a matter of professional discipline.

The architecture: metrological core and application layer

The firmware of a MID-compliant energy meter is architecturally divided into two parts, separated by a boundary that the directive explicitly imposes.

The metrological core is the code block that performs functions subject to metrological verification: ADC sampling, active and reactive power calculation, energy integration, management of sealed accumulators, and generation of the certified value. This block is covered by MID certification and digitally signed. Its signature is verified at startup and periodically at runtime. Any modification, even a single line, invalidates the signature and requires a new conformity assessment procedure.

The application layer is everything the metrological core does not touch: communication management, communication protocol, register table structure, alarms and thresholds, non-metrological event logs, derived calculations (THD, power factor shown to the user, statistics), configuration interface and display management.

The separation between these two layers is not a design best practice. It is a regulatory requirement. WELMEC Guide 7.2, the European reference for software in legal measuring instruments, explicitly requires the isolation of metrologically relevant software from non-metrologically relevant software.

Understanding where this boundary falls is the first step in understanding what is truly customizable.

The four levels

In the OEM market, “customizable firmware” covers four levels of intervention, in increasing order of depth and regulatory impact.

• Level 1 — Configuration
  Everything the firmware allows to be modified at runtime, through a configuration tool or parameterization protocol. Typically: Modbus address, baud rate, tariffs, alarm thresholds, register labels, enabling/disabling optional functions. It requires no recompilation, requires no new certification, and is available on any serious product. When a supplier calls this level “customization”, it is selling product configurability as if it were a service.
• Level 2 — Application Mapping
  Modification of the communication register table, the order of measurements, the format of exposed data, and the network interface. This is intervention on the application layer: the application binary is recompiled, but the metrological core remains intact and the metrological signature remains valid. This is the level at which most “customized OEM” projects on the market sit, and it is sufficient for most use cases.
• Level 3 — Deep Application Customization
  Addition of non-metrological calculation logic, composite alarms, integration of external sensors, management of proprietary protocols, and custom event-driven behavior. It remains within the application layer, but requires dedicated development, functional validation, and possibly EMC compatibility testing if the hardware is touched. The metrological signature remains valid, but product documentation and functional tests must be reissued.
• Level 4 — Metrological Co-Engineering
  Intervention in the metrological core: changing the calculation window for DC applications, adding a measurement function not included in the starting standard, integrating a new primary sensor, or modifying the sealing procedure. This is the territory of truly strategic projects, where the OEM is not buying a meter: it is developing one.

A serious supplier explicitly states in the offer which of the four levels it is referring to. A supplier that uses “customization” as a generic term hides ambiguity behind the word.

What cannot be touched, and why that is a feature

An experienced OEM may sometimes ask to intervene in the metrological core for reasons that are legitimate from its point of view: optimizing latency, adding a measurement channel, modifying the averaging window.

The metrological core is locked down for reasons that protect the OEM customer first and foremost. Digital signature and code integrity are what make the value exported by the meter legally valid for billing. An “easily modifiable” core is a core that does not guarantee the meter’s metrological characteristics.

Traceability: the chain connecting code and certification

MID-certified firmware is not only a working binary. It is a traceability chain connecting:

• the source code (version, repository, commit hash);
• the compilation toolchain (compiler, version, flags, libraries);
• the produced binary (digital signature, cryptographic hash);
• the Notified Body test report;
• the issued MID certificate.

Every link in the chain must be reconstructable for the entire product life. If, five years from now, a market surveillance authority asks to verify that the binary in the field corresponds to the certified code, the supplier must be able to recompile the same binary bit by bit from the archived source. Reproducible builds are not a nice-to-have: they are a requirement of metrological practice.

For an OEM, this means that the quality of the firmware partner is measured not only by the quality of today’s code, but by the robustness of the processes that will keep it traceable for ten years.

What this means for an OEM

The question to ask a supplier is not “is your firmware customizable?” It is: “at which level does the modification we are requesting fall: configuration, surface-level application, deep application, metrological core, and for how long will it be maintained?”

A supplier that answers with the same structure, level, timing, certification, ownership and lifecycle has a mature OEM development process. A supplier that answers “let’s see, let’s talk, we’ll find a solution” is selling verbal flexibility instead of engineering discipline.

The word “customization” alone is no longer enough to distinguish one supplier from another. It has become a linguistic commodity. What distinguishes a supplier is the rigor with which it traces the boundary between what can be modified in the firmware of a meter and what, for metrological reasons, must remain locked down.

That boundary is not where commercial availability ends. It is where technical responsibility begins.