← Blog8. Oktober 2026

EtherNet/IP SBOM: Wie ein ListIdentity-Broadcast jedes Gerät im Subnetz identifiziert

Kurz gefasst · Stand: Oktober 2026

Jedes EtherNet/IP-Gerät führt das CIP Identity Object (Klasse 0x01) mit Vendor ID, Device Type, Product Code, Revision (Major.Minor), Status, Seriennummer und Produktname. Ein ListIdentity-Broadcast (UDP 44818) im Subnetz liefert alle acht Attribute jedes Geräts in einem Durchgang, ohne Sitzung und ohne Steuerung. Genau das tut RSLinx beim „Browse“. Für die Anlagen-SBOM ist das die schnellste Erhebung überhaupt. Zwei Lücken: Der Product Code ist eine herstellerinterne Zahl, die Katalognummer steht meist nur im Produktnamen, und Module in einem ControlLogix-Chassis antworten nicht einzeln.

Das Identity Object ist in jedem CIP-Gerät vorhanden

Das Identity Object (Klasse 0x01, Instanz 1) gehört zum Pflichtumfang jedes Geräts, das den ODVA-Konformitätstest besteht. Die Attribute 1 bis 7 sind Standard:

Attribut	Inhalt	Bedeutung für die Geräteliste
1 Vendor ID	UINT	Hersteller als ODVA-Nummer (1 = Rockwell Automation); Auflösung über Herstellerlisten
2 Device Type	UINT	Geräteprofil (0x0E Steuerung, 0x0C Kommunikationsadapter)
3 Product Code	UINT	herstellerinterne Produktnummer, nicht die Katalognummer
4 Revision	Major.Minor	Firmware-Revision, der Vergleichswert für „prior to 36.013“ in Rockwell-Advisories
6 Serial Number	UDINT	Seriennummer, eindeutig nur zusammen mit der Vendor ID
7 Product Name	bis 32 Zeichen	Produktname – enthält bei Rockwell meist die Katalognummer („1756-L83E/B“)

Ein Attribut für die Hardware-Revision oder ein eigenes Feld für die Bestellnummer gibt es nicht. Die Katalognummer muss aus dem Produktnamen gelesen werden, dessen Format der Hersteller bestimmt.

ListIdentity erfasst das Subnetz in einem Durchgang

Der Encapsulation-Befehl ListIdentity (0x63) braucht keine registrierte Sitzung. Als UDP-Broadcast an Port 44818 gesendet, antwortet jedes EtherNet/IP-Gerät im lokalen Subnetz mit seiner IP-Adresse und den Identity-Attributen. Über Router hinweg funktioniert dasselbe per Unicast je Host. Das Verfahren ist Schicht 3, lesend und so verbreitet, dass jedes Gerät damit umgehen muss. Es ist der Mechanismus hinter dem RSWho-Fenster. Werkzeuge wie nmap --script enip-info oder die Bibliotheken pycomm3 und EIPScanner sprechen ihn direkt.

Für die vollständigen Attribute (etwa Attribut 8 State oder herstellerspezifische Erweiterungen) ist Explicit Messaging mit Get_Attributes_All über TCP 44818 nötig; für die Geräteliste reicht ListIdentity.

Was EtherNet/IP nicht liefert

Module im Chassis: Ein ControlLogix-Rack oder eine POINT-I/O-Station zeigt eine Identität je IP-Adresse; die Module dahinter sind nur per CIP-Routing über Port und Slot erreichbar. Sie kommen aus dem Studio-5000-Projekt oder einem gezielten Routing-Scan.
Die Katalognummer als Feld: Product Code ist herstellerintern; der Produktname ist Freitext mit 32 Zeichen. Rockwell schreibt die Katalognummer hinein, andere Hersteller nicht immer.
Die Firmware-Notation: Revision 36.13 im Identity Object entspricht „36.013“ im Advisory. Die führende Null muss ergänzt werden, sonst scheitert der Vergleich.
Eine öffentliche Herstellerliste: Die ODVA vergibt Vendor IDs, veröffentlicht aber keine einfache Tabelle; Werkzeuge wie nmap und Wireshark führen eigene Listen mit rund 1.500 Einträgen.
Unterdrückte Antworten: Einige Steuerungen lassen sich so konfigurieren, dass sie auf ListIdentity nicht antworten. Dann bleibt der Weg über das Projekt.

Was das für die Anlagen-SBOM heißt

Bei der Abnahme je Subnetz einen ListIdentity-Broadcast fahren und Produktname, Revision und Seriennummer je Gerät übernehmen; Katalognummer aus dem Produktnamen ableiten.
Chassis-Module aus dem Engineering-Projekt ergänzen und als Positionen unter der Adapter-IP führen.
Die Firmware als Major.Minor mit dreistelliger Minor speichern, damit Rockwell-Advisories ohne Nacharbeit vergleichbar sind. Details im Beitrag zu Rockwell und der Anlagen-SBOM.
Stratix-Switches zusätzlich per SNMP erfassen; dort stehen Seriennummer und Firmware in der ENTITY-MIB.

Alle 13 Hersteller im Vergleich: SBOM je Hersteller →

Werkspilot Scan an Ihrer eigenen Anlage erproben.

Wir erproben die Erfassung mit wenigen Anlagenbauern an deren Test- oder Referenzanlagen, vier Monate lang, Stufe für Stufe um ihre Steuerungen erweitert. Der Partner bekommt eine Anlage seiner Wahl als Anlagen-SBOM: jedes erreichbare Gerät mit Hersteller, Bestellnummer und Firmwarestand, offene Positionen einzeln ausgewiesen.

Entwicklungspartnerschaft anfragen →

Werkspilot Scan liest diese Felder vom Wartungs-PC aus, lesend und mit fester Anfrageliste, und führt sie je Anlage. Dieser Beitrag beschreibt den Stand der Spezifikationen zum Zeitpunkt der Veröffentlichung.

Häufige Fragen

Vendor ID (ODVA-Nummer, 1 = Rockwell), Device Type, Product Code (herstellerintern), Revision als Major.Minor, Status, Seriennummer und Produktname mit bis zu 32 Zeichen; optional den Zustand. Die Attribute 1 bis 7 sind in jedem konformen CIP-Gerät vorhanden. Eine Hardware-Revision oder ein eigenes Katalognummern-Feld gibt es nicht; die Katalognummer steht bei Rockwell im Produktnamen.

Mit einem ListIdentity-Broadcast (Encapsulation-Befehl 0x63) als UDP-Paket an Port 44818. Jedes Gerät im Subnetz antwortet ohne Sitzung mit IP-Adresse und Identity-Attributen, derselbe Mechanismus, den RSLinx beim Browse nutzt. Über Router hinweg braucht es Unicast je Host. Module in einem Chassis antworten nicht einzeln und müssen per CIP-Routing oder aus dem Projekt ergänzt werden.

Nein, das ist ein lesender Standarddienst, den Engineering-Werkzeuge ständig senden. Riskant sind Port-Scans und fehlerhafte Pakete auf alten Stacks; ein Inventarwerkzeug sollte ausschließlich ListIdentity und lesende Get-Attribute-Dienste verwenden, mit fester Portliste und ohne Schreibzugriffe.