Die Firmware-Architektur eines Zählers: vier Ebenen der Customization, ein einziges Wort für alles

Ein OEM bewertet drei Lieferanten für einen kundenspezifischen Zähler. Alle drei schreiben auf dem kommerziellen Datenblatt «customizable firmware». Sechs Monate später stellt sich in drei unterschiedlichen Projekten heraus, dass diese drei Customizations technisch völlig unterschiedliche Dinge sind.

Beim ersten Lieferanten bedeutet Customization: Der Kunde öffnet ein Konfigurationstool, benennt die Labels der Modbus-Register um, aktiviert oder deaktiviert einige abgeleitete Messgrößen und exportiert eine Profildatei. Die Firmware wird nie geändert. Was sich ändert, ist nur die Initialisierung.

Beim zweiten Lieferanten bedeutet Customization: Der Lieferant nimmt seine Codebasis, erstellt einen dedizierten Fork, ändert die Struktur der Registertabelle oder die Logik eines Algorithmus. Das Binary wird neu kompiliert, interne Tests werden wiederholt, die MID-Zertifizierung bleibt gültig oder verfällt je nachdem, was berührt wurde.

Beim dritten Lieferanten bedeutet Customization: Kunde und Lieferant arbeiten parallel an der Firmware-Architektur des Zählers, nicht an der Applikation, sondern an der Architektur. Der Lieferant behält die Kontrolle über den metrologischen Kern, der Kunde wirkt an der Definition der oberen Schichten mit. Die Roadmap ist gemeinsam. Die MID-Neunotifizierung wird im Voraus geplant, nicht nachträglich erlitten.

Drei kommerziell unterschiedliche Angebote, drei technisch unterschiedliche Angebote, drei Angebote für OEMs mit unterschiedlichen Anforderungen. Ein einziges Wort, um sie alle zu beschreiben.

Für einen OEM, der Spezifikationen schreibt, ist es eine strategische Entscheidung zu verstehen, wo sich ein Lieferant auf diesem Spektrum befindet. Für einen Lieferanten, der sich seriös im OEM-Markt positionieren will, ist es eine Frage professioneller Disziplin, die drei Angebote klar voneinander zu unterscheiden.

Die Architektur: metrologischer Kern und Applikationsschicht

Die Firmware eines MID-konformen Energiezählers teilt sich architektonisch in zwei Teile, getrennt durch eine Grenze, die die Richtlinie ausdrücklich vorgibt.

Der metrologische Kern ist der Codeblock, der die metrologisch relevanten Funktionen ausführt: ADC-Sampling, Berechnung von Wirk- und Blindleistung, Energieintegration, Verwaltung versiegelter Akkumulatoren, Erzeugung des zertifizierten Messwerts. Dieser Block ist Gegenstand der MID-Zertifizierung und digital signiert. Seine Signatur wird beim Start und periodisch zur Laufzeit geprüft. Jede Änderung, selbst eine einzelne Codezeile, macht die Signatur ungültig und erfordert ein neues Konformitätsbewertungsverfahren.

Die Applikationsschicht umfasst alles, was der metrologische Kern nicht berührt: Kommunikationsmanagement, Kommunikationsprotokoll, Struktur der Registertabelle, Alarme und Schwellenwerte, nicht-metrologische Ereignislogs, abgeleitete Berechnungen (THD, dem Benutzer angezeigter Leistungsfaktor, Statistiken), Konfigurationsschnittstelle, Display-Management.

Die Trennung zwischen diesen beiden Schichten ist keine gute Designpraxis. Sie ist eine regulatorische Anforderung. WELMEC Guide 7.2, die europäische Referenz für Software in gesetzlichen Messgeräten, schreibt die Isolierung metrologisch relevanter Software von nicht relevanter Software ausdrücklich vor.

Zu verstehen, wo diese Grenze verläuft, ist der erste Schritt, um zu verstehen, was wirklich customizierbar ist.

Die vier Ebenen

Im OEM-Markt deckt «customizable firmware» vier Eingriffsebenen ab, in aufsteigender Reihenfolge von Tiefe und regulatorischer Auswirkung.

• Ebene 1 — Konfiguration.
  Alles, was die Firmware zur Laufzeit über ein Konfigurationstool oder ein Parametrierungsprotokoll ändern lässt. Typischerweise: Modbus-Adresse, Baudrate, Tarife, Alarmschwellen, Registerlabels, Aktivierung/Deaktivierung optionaler Funktionen. Erfordert keine Neukompilierung, keine neue Zertifizierung und ist bei jedem seriösen Produkt verfügbar. Wenn ein Lieferant diese Ebene «Customization» nennt, verkauft er Produktkonfigurierbarkeit als Dienstleistung.
• Ebene 2 — Applikative Mapping-Anpassung.
  Änderung der Kommunikationsregistertabelle, der Reihenfolge der Messwerte, des Formats der ausgegebenen Daten, der Netzwerkschnittstelle. Es handelt sich um einen Eingriff in die Applikationsschicht: Das Applikations-Binary wird neu kompiliert, aber der metrologische Kern bleibt intakt und die metrologische Signatur bleibt gültig. Auf dieser Ebene liegt die Mehrheit der «OEM-customized» Projekte am Markt, und sie reicht für die meisten Use Cases aus.
• Ebene 3 — Tiefe applikative Customization.
  Ergänzung nicht-metrologischer Berechnungslogiken, zusammengesetzter Alarme, Integration externer Sensoren, Verwaltung proprietärer Protokolle, kundenspezifisches event-driven Verhalten. Sie bleibt in der Applikationsschicht, erfordert aber dedizierte Entwicklung, funktionale Validierung und gegebenenfalls EMV-Kompatibilitätstests, wenn die Hardware berührt wird. Die metrologische Signatur bleibt gültig, aber Produktdokumentation und Funktionstests müssen neu ausgestellt werden.
• Ebene 4 — Metrologisches Co-Engineering.
  Eingriff in den metrologischen Kern: Änderung des Berechnungsfensters für DC-Anwendungen, Hinzufügen einer Messfunktion, die im ursprünglichen Standard nicht vorgesehen war, Integration eines neuen Primärsensors, Änderung des Sealing-Verfahrens. Das ist der Bereich wirklich strategischer Projekte, in denen der OEM keinen Zähler kauft: Er entwickelt ihn.

Ein seriöser Lieferant nennt im Angebot ausdrücklich, auf welche der vier Ebenen er sich bezieht. Ein Lieferant, der «Customization» als generischen Begriff verwendet, verdeckt die Mehrdeutigkeit mit einem Wort.

Was nicht geändert werden kann, und warum das eine Eigenschaft ist

Ein erfahrener OEM möchte manchmal aus aus seiner Sicht legitimen Gründen in den metrologischen Kern eingreifen: Latenz optimieren, einen Messkanal hinzufügen, das Mittelungsfenster ändern.

Der metrologische Kern ist aus Gründen geschützt, die in erster Linie den OEM-Kunden schützen. Digitale Signatur und Codeintegrität machen den vom Zähler ausgegebenen Wert rechtlich für die Abrechnung gültig. Ein «leicht modifizierbarer» Kern ist ein Kern, der die metrologischen Eigenschaften des Zählers nicht garantiert.

Rückverfolgbarkeit: die Kette, die Code und Zertifizierung verbindet

Eine MID-zertifizierte Firmware ist nicht nur ein funktionierendes Binary. Sie ist eine Rückverfolgbarkeitskette, die Folgendes verbindet:

• den Quellcode (Version, Repository, Commit-Hash);
• die Build-Toolchain (Compiler, Version, Flags, Bibliotheken);
• das erzeugte Binary (digitale Signatur, kryptografischer Hash);
• den Prüfbericht der benannten Stelle;
• das ausgestellte MID-Zertifikat.

Jedes Glied dieser Kette muss über die gesamte Lebensdauer des Produkts rekonstruierbar sein. Wenn in fünf Jahren eine Marktaufsichtsbehörde prüfen möchte, ob das im Feld installierte Binary dem zertifizierten Code entspricht, muss der Lieferant in der Lage sein, aus dem archivierten Quellcode bitgenau dasselbe Binary neu zu kompilieren. Reproducible Build ist kein Nice-to-have: Es ist eine Anforderung der metrologischen Praxis.

Für einen OEM bedeutet das, dass die Qualität des Firmware-Partners nicht nur an der Codequalität von heute gemessen wird, sondern an der Robustheit der Prozesse, die diesen Code zehn Jahre lang rückverfolgbar halten.

Was das für einen OEM bedeutet

Die Frage an einen Lieferanten lautet nicht: «Ist Ihre Firmware customizierbar?» Sie lautet: «Auf welche Ebene fällt die von uns gewünschte Änderung – Konfiguration, oberflächliche Applikation, tiefe Applikation, metrologischer Kern – und wie lange wird sie gewartet?»

Ein Lieferant, der mit derselben Struktur antwortet – Ebene, Timing, Zertifizierung, Eigentum, Lifecycle -, verfügt über einen reifen OEM-Entwicklungsprozess. Ein Lieferant, der mit «wir schauen, wir sprechen darüber, wir finden eine Lösung» antwortet, verkauft verbale Flexibilität statt technischer Disziplin.

Das Wort «Customization» allein reicht nicht mehr aus, um einen Lieferanten vom anderen zu unterscheiden. Es ist zu einer sprachlichen Commodity geworden. Was unterscheidet, ist die Strenge, mit der ein Lieferant die Grenze zieht zwischen dem, was in der Firmware eines Zählers geändert werden kann, und dem, was aus metrologischen Gründen geschützt bleiben muss.

Diese Grenze liegt nicht dort, wo die kommerzielle Verfügbarkeit endet. Sie liegt dort, wo die technische Verantwortung beginnt.