RFID-Middleware-Architektur: wo Geräte enden und Geschäftslogik beginnt

Zwischen Leser und ERP liegt eine Schicht, die niemand verantworten will: die Middleware. Sie empfängt tausende Roh-Leseereignisse pro Minute, die meisten davon Duplikate, und muss daraus wenige Geschäftstatsachen machen, die Finanzen und Betrieb verteidigen können.

Ist die Architektur falsch, sehen die Symptome wie Hardwarefehler aus – doppelte Lagerbewegungen, veraltete Mengen, ungeordnete Ereignisse oder ein Portal, das funktioniert, bis das Netz kurz aussetzt.

Was muss Middleware tatsächlich leisten?

Fünf Aufgaben, und nur die erste betrifft das Sprechen mit Lesern.

• Geräteabstraktion: Leser, Antennen, Leistung, Sessions und Firmware herstellerübergreifend verwalten.
• Ereignisnormalisierung: herstellerspezifische Lesungen in ein Schema mit Leser, Antenne, Zeitstempel, RSSI und EPC überführen.
• Filterung und Deduplizierung: wiederholte Lesungen desselben Tags in derselben Zone zu einem logischen Ereignis zusammenfassen.
• Geschäftsanreicherung: Lagerort, Richtung, Auftrag oder Palettenkontext anhängen.
• Zuverlässige Zustellung: puffern, wiederholen, erneut abspielen, damit das ERP nie ein Teilbild sieht.

Alles, was nicht zu diesen fünf gehört, ist Geschäftslogik und gehört in die Anwendungsschicht.

Was sind die vier Schichten?

Eine tragfähige Aufteilung ist Geräte-, Edge-, Geschäfts- und Integrationsschicht. Die Namen sind weniger wichtig als die Grenzen.

• Geräteschicht: LLRP oder Hersteller-SDK, Leserkonfiguration, Antenneninventar, Firmwarestand.
• Edge-Schicht: läuft vor Ort, puffert lokal, wendet Zonenregeln an, übersteht Netzausfall.
• Geschäftsschicht: Deduplizierungsfenster, Session-Logik, Richtungsinferenz, Ausnahmeregeln.
• Integrationsschicht: ERP-/WMS-Adapter, idempotente APIs, Mapping-Tabellen, Audit-Log.

Der häufigste Architekturfehler ist Deduplizierung in der Integrationsschicht. Sie läuft dann nach der Pufferung, und ein Replay erzeugt doppelte Geschäftsbelege.

Wo hilft LLRP, wo schadet es?

LLRP ist ein Standardprotokoll für Leserkonfiguration und Tag-Meldungen und die richtige Abstraktion bei mehreren Leserherstellem: ein Treiber, ein Datenmodell, ein Konfigurationspfad.

Es ist keine Universallösung. Manche Herstellerfunktionen – erweiterte Antennenumschaltung, Filterung im Leser, eigene Tag-Daten – sind nur über proprietäre SDKs verfügbar. Ein Hybriddesign ist normal: LLRP für die standardisierten 80 %, Hersteller-SDK für die spezifischen 20 %, hinter derselben internen Schnittstelle.

• LLRP für Konfiguration, Inventursteuerung und Standard-Tag-Meldungen.
• Hersteller-SDK für Funktionen, die LLRP nicht ausdrücken kann.
• Das SDK nie in die Geschäftsschicht durchsickern lassen; kapseln.

Wie sollen Pufferung und Offline-Betrieb funktionieren?

Netze fallen aus. Ein Portal, das 30 Sekunden die Verbindung verliert, darf nicht 500 Lesungen verlieren.

Die Edge-Schicht braucht eine lokale Warteschlange mit persistentem Speicher, Kapazität für mindestens eine Schicht und ein definiertes Verhalten beim Füllen: ältestes verwerfen, neuestes verwerfen oder die Linie blockieren. Eine Produktionslinie zu blockieren ist meist inakzeptabel, also definieren Sie es ausdrücklich.

• Persistente lokale Warteschlange, verschlüsselt gespeichert.
• Kapazitätsplan: Spitzenlesungen pro Stunde × Autonomiestunden.
• Ausdrückliche Overflow-Politik, dokumentiert und getestet.
• Replay mit Idempotenzschlüsseln gegen doppelte Belege.

Welche Filter- und Deduplizierungsregeln werden genutzt?

Drei Regeln decken die meisten Installationen ab, und sie sollten konfigurierbar sein, nicht hart kodiert.

Zeitfenster-Deduplizierung: derselbe EPC in derselben Zone innerhalb von N Sekunden zählt einmal. Richtungs-Deduplizierung: ein EPC, der erst an der Eingangsantenne und dann an der Ausgangsantenne gesehen wird, wird zu einer Bewegung statt zu zwei Lesungen. Zustandsunterdrückung: hat das ERP den Artikel bereits am Zielort, ist die Lesung ein No-op.

• Fensterlänge hängt vom Prozess ab: 2–5 s am Portal, 30–60 s beim Regal-Sweep.
• Richtungsinferenz braucht RSSI pro Antenne oder Sequenz, nicht nur Zeitstempel.
• Unterdrückte Ereignisse für Audits protokollieren, nicht still verwerfen.

Welche Überwachung braucht Middleware?

Middleware ist der Ort, an dem Sie die Wahrheit früh sehen – instrumentieren Sie sie.

Verfolgen Sie Lesequote pro Antenne, Ereignislatenz bis zum ERP-Commit, Warteschlangentiefe, Wiederholungszähler und Unterdrückungsquote. Alarmieren Sie auf Trends, nicht nur auf Ausfälle: Eine langsam steigende Warteschlange ist eine sterbende Festplatte oder ein wachsender Rückstau, Monate vor dem Ausfall.

• Lesequote und Nullläufe pro Antenne über die Zeit.
• Ende-zu-Ende-Latenz p95, nicht Durchschnitt.
• Warteschlangentiefe und Replay-Zähler.
• Firmware- und Konfigurationsdrift zwischen Lesern.

Fazit

Middleware existiert, um Rauschen in Fakten zu verwandeln: Geräte abstrahieren, Ereignisse normalisieren, filtern und deduplizieren, anreichern, zuverlässig zustellen. Legen Sie die Deduplizierung vor die Pufferung, halten Sie Herstellercode hinter einer Schnittstelle, definieren Sie das Offline-Verhalten bevor das Netz Sie prüft, und instrumentieren Sie die Schicht, damit Degradation sichtbar wird, solange die Behebung billig ist.