LLRP hat den Ruf, schwierig zu sein, und dieser Ruf ist zur Hälfte verdient: Die Kodierung ist binär, der Nachrichtenkatalog ist lang, und die Dokumentation liest sich, als hätte ein Normungsausschuss sie geschrieben — weil genau das der Fall war. Aber die Teilmenge, die ein laufendes Deployment braucht, ist klein, und sobald sie verstanden ist, wird das Protokoll zum uninteressantesten Teil des Projekts.

Dieser Artikel ist die Landkarte dieser Teilmenge: was zu konfigurieren ist, in welcher Reihenfolge, und welche Felder das Verhalten des Lesers tatsächlich verändern.

Was LLRP ist und wo es sitzt

LLRP ist ein Host-zu-Leser-Protokoll, kein Anwendungsprotokoll, und diese Unterscheidung zu wahren spart viel Designverwirrung.

Es wird von EPCglobal definiert und als LLRP 1.0.1 standardisiert; Version 1.1 ergänzt feinere Steuerung und bessere Erweiterungen.
Es läuft standardmäßig über TCP auf Port 5084 und kodiert Nachrichten als binäre Type-Length-Value-Strukturen.
Seine Aufgabe ist es, das Funkgerät zu konfigurieren und Etikettenberichte zu liefern, nicht zu entscheiden, was eine Lesung bedeutet.
Nahezu jeder industrielle Festleser unterstützt es, weshalb LLRP-Code zwischen Marken portierbar ist.
Oberhalb von LLRP brauchen Sie weiterhin Ihr eigenes Gateway: Deduplizierung, Geschäftsmapping und ERP-Schreibvorgänge liegen außerhalb des Protokolls.

Das Nachrichtenmodell: Requests, Responses und Reports

Drei Nachrichtenfamilien decken alles ab, und zu wissen, welche welche ist, verhindert den größten Teil der Verwirrung.

Requests tragen eine Nachrichten-ID und erwarten genau eine Response mit derselben ID.
Responses tragen einen Statuscode; ein Erfolg mit unerwarteter Nutzlast ist häufiger als ein klarer Fehlschlag.
Reports kommen asynchron, sobald eine ROSpec läuft, und sind Antwort auf nichts.
Leserereignisse und Fehlermeldungen können ebenfalls asynchron eintreffen, der Client muss also immer lesen.
Ein Client, der erst nach dem Senden eines Requests liest, füllt irgendwann den Socket-Puffer und blockiert.

Leserkonfiguration: die fünf Nachrichten, die immer gesendet werden

Konfiguration ist eine Zustandsmaschine, und die Reihenfolge zählt mehr als die einzelnen Felder.

Lesen Sie zuerst die Fähigkeiten; sie sagen, welche Optionen der Leser unterstützt, und verhindern unzulässige Einstellungen.
Setzen Sie danach die Leserkonfiguration: Keepalive, Reportpuffer und die Standard-Antenneneigenschaften.
Fügen Sie die ROSpec hinzu, aktivieren Sie sie, dann starten Sie sie; eine aktivierte, aber nicht gestartete ROSpec tut nichts und sieht wie ein Fehler aus.
Fügen Sie die AccessSpec getrennt hinzu, und nur wenn ein Schreibvorgang oder ein Lock wirklich nötig ist.
Löschen und legen Sie eine ROSpec neu an, statt sie in place zu ändern; genau dort treten die Herstellerunterschiede auf.

ROSpec: eine Inventuroperation beschreiben

Eine ROSpec ist ein Container für eine Reportspezifikation und eine oder mehrere Inventarparameterspezifikationen.

Die Reportspezifikation wählt, welche Etikettenfelder zurückkommen und wie oft Berichte ausgegeben werden.
Die Inventarparameterspezifikation bündelt Antennenliste und Luftprotokollverhalten in einer Einheit.
Jede laufende ROSpec konkurriert um dasselbe Funkgerät; zwei ROSpecs auf einem Leser bedeuten meist, dass eine davon falsch ist.
Beobachtungsauslöser bestimmen, wann ein Etikett gemeldet wird: sofort, nach N Lesungen oder wenn es nicht mehr gesehen wird.
Halten Sie eine ROSpec pro Geschäftsverhalten, benennen Sie sie im Beschreibungsfeld, und behandeln Sie diesen Namen als Teil Ihres Konfigurationsvertrags.

Luftprotokoll-Einstellungen: die Felder, die das Verhalten ändern

Der C1G2-Inventarbefehl ist der Ort, an dem das Leserverhalten tatsächlich entschieden wird.

Sendeleistung und Kanal- bzw. Hop-Tabelle kommen zuerst; Leistung ist regulatorisch gebunden, kein Stellknopf.
Die Empfängerempfindlichkeit tauscht ein breiteres Hörfenster gegen Rauschen, und Standardwerte sind in einem dichten Gang selten optimal.
Die Wahl der Singulationssitzung bestimmt, ob Etiketten schnell erneut gemeldet oder ruhig gehalten werden; Sitzung zwei passt zu bewegter Ware.
Die Etikettenzahlschätzung hilft dem Leser bei der Wahl der Q-Werte; eine falsche Schätzung kostet Zeit, nicht Korrektheit.
Etikettenfilter verkleinern die Population vor der Singulation und sind die billigste verfügbare Leistungsverbesserung.

AccessSpec: Tag-Speicher lesen und schreiben

Zugriffsoperationen werden sparsam eingesetzt, und jede hat ein eigenes Fehlerprofil.

Eine AccessSpec zielt auf einen Filter, sie sollte also nie ohne einen laufen, außer Sie wollen jedes Etikett im Bereich beschreiben.
Das Lesen eines Speicherbank ist die sichere Diagnose; das Schreiben von EPC oder Anwenderspeicher ist die Operation, die Daten beschädigt.
Schreibvorgänge sollten in derselben Sitzung durch ein anschließendes Lesen verifiziert werden, nicht aus einem Erfolgsstatus angenommen.
Zugriffspasswörter müssen als Geheimnis behandelt werden; ein Lock ohne dokumentiertes Passwort ist ein irreversibler Fehler.
Eine fehlgeschlagene Zugriffsoperation liefert einen Statuscode, und dieser Code ist oft nützlicher als ein Wiederholungsversuch.

Fehlerbehandlung: Statuscodes, für die sich Verzweigungen lohnen

Die meisten LLRP-Clients behandeln jeden Nicht-Erfolg als generischen Fehler, was die Felldiagnose unmöglich macht.

Unterscheiden Sie Parameterfehler von Zustandsfehlern: Ersterer heißt, die Nachricht war falsch, Letzterer, der Leser war im falschen Zustand.
Eine Fähigkeitsabweichung sollte durch Rückfall auf eine unterstützte Option behandelt werden, nicht durch Abbruch des Deployments.
Wiederholte Timeouts bedeuten meist eine abgebrochene TCP-Sitzung, nicht einen langsamen Leser; prüfen Sie den Socket vor dem Wiederholen.
Protokollieren Sie die Nachrichten-ID zusammen mit dem Statuscode; ohne sie lässt sich eine Multinachrichten-Sequenz nicht debuggen.
Behandeln Sie auch einen unerwarteten Erfolg als Bug — eine erfolgreiche Antwort mit leerer Nutzlast heißt oft, dass der Leser den Request ignoriert hat.

LLRP-Code herstellerübergreifend portabel halten

Portabilität ist eine Designentscheidung am Anfang und teuer nachzurüsten.

Verwenden Sie nur Standardnachrichten und Standardparameter, wo der Standard Ihren Bedarf deckt.
Erkennen Sie Funktionen über die Fähigkeitsnachricht, statt anzunehmen, ein Hersteller unterstütze eine Option.
Kapseln Sie Herstellererweiterungen hinter einem dünnen Adapter, damit der Rest des Gateways sie nie importiert.
Testen Sie dieselbe Konfiguration gegen eine zweite Marke, bevor Sie das Design festschreiben; Unterschiede zeigen sich früh und billig.
Versionieren Sie Ihre Konfigurationsdateien, denn eine funktionierende ROSpec ist ein Asset, das einen Leserwechsel überleben sollte.