Werkspilot
    ← Blog

    IO-Link SBOM: Was der Master über jeden Sensor liefert und was nicht

    Kurz gefasst · Stand: Oktober 2026

    IO-Link-Geräte hängen Punkt-zu-Punkt an einem Master und haben keine Netzadresse; ihre Identität liest der Master. Pflicht nach Spezifikation V1.1.3 sind VendorID und DeviceID (Direct Parameter Page) sowie VendorName (Index 0x10) und ProductName (0x12). ProductID (Bestellnummer), SerialNumber, HardwareRevision und FirmwareRevision (0x13–0x17) sind optional. Die großen Sensorhersteller füllen sie, garantiert ist es nicht. Nach außen gibt der Master die Daten über sein Feldbus-Submodul (PROFINET IOL_CALL), über OPC UA nach OPC 30120 oder über die REST-Schnittstelle „JSON Integration for IO-Link“ heraus. Für die Anlagen-SBOM ist IO-Link die dritte Stufe: erst der Master im Netz, dann die Sensoren über ihn.

    Vier Pflichtfelder, vier freiwillige

    ParameterZugriffPflichtBedeutung für die Geräteliste
    VendorID (Direct Parameter Page 0x07–0x08)Master beim Port-HochlaufjaHersteller als 16-Bit-Nummer, identisch mit der PI-Vendor-ID
    DeviceID (0x09–0x0B)Master beim Port-HochlaufjaGerätetyp, herstellerintern; Auflösung über die IODD (IODDfinder)
    VendorName (ISDU 0x10), ProductName (0x12)ISDUjaHersteller und Produktname als Text
    ProductID (0x13)ISDUneinBestellnummer oder Typenschlüssel – der Abgleichsschlüssel, wenn gefüllt
    SerialNumber (0x15), HardwareRevision (0x16), FirmwareRevision (0x17)ISDUneinSeriennummer und Stände – bei ifm, SICK, Balluff, Pepperl+Fuchs, Turck und Festo üblich, nicht garantiert

    IO-Link-V1.0-Geräte (RevisionID 0x10) führen oft keine ISDUs; dann bleiben VendorID und DeviceID. Die Zuordnung zum Produkt läuft dann über die IODD, öffentlich suchbar im IODDfinder.

    Drei Wege vom Master in die Geräteliste

    • Über den Feldbus des Masters: PROFINET-Master zeigen jeden Port als Submodul; VendorID und DeviceID stehen in den Port-Parametern, die ISDUs liest ein IOL_CALL aus der Steuerung oder ein Engineering-Werkzeug (S7-PCT, TIA-Portal-IO-Link-Tool). EtherNet/IP-Master bieten herstellerspezifische CIP-Objekte.
    • Über OPC UA nach OPC 30120: Der IOLinkDeviceType führt VendorID, DeviceID, VendorName, ProductName und SerialNumber (dort Pflicht); Hardware- und SoftwareRevision optional. Umgesetzt bei Mastern von ifm, Balluff, Turck und anderen.
    • Über JSON/REST: Die Community-Spezifikation „JSON Integration for IO-Link“ (10.222, V2 seit 2025 mit OpenAPI) definiert unter /iolink/v1 Gateway → Master → Ports → Devices mit Identifikationsobjekten. Balluff und Pepperl+Fuchs setzen sie um, ifm nutzt eine eigene REST-API (IoT-Core).

    Alle drei Wege sind lesend und während des Betriebs zulässig. Schreibende Parameterzugriffe, Portmodus-Änderungen oder Data-Storage-Uploads gehören nicht in ein Inventarwerkzeug.

    Was IO-Link nicht liefert

    • Garantierte Seriennummer und Firmware: optional nach Spezifikation; leere Felder sind zulässig.
    • Direkte Sichtbarkeit: ohne den Master gibt es keinen Weg zum Sensor, und der Master muss erst über PROFINET-DCP, EtherNet/IP oder einen IP-Scan gefunden werden.
    • Eine eindeutige Produktkennung ohne IODD: DeviceID ist nur zusammen mit VendorID eindeutig; ProductID ist Freitext.
    • Den Master selbst: Seine Firmware ist ein eigenes CRA-Produkt. 2026 gab es Advisories für IO-Link-Master von Phoenix Contact (IOL MA8); das steht im Beitrag zu Phoenix Contact und der Anlagen-SBOM.

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

    • Zuerst die IO-Link-Master im Netz erfassen (I&M0, Identity Object, SNMP), dann je Master die Portliste mit VendorID, DeviceID, ProductName und, soweit gefüllt, ProductID, Seriennummer und Firmware lesen.
    • DeviceID über die IODD in einen Produkttyp auflösen; die Vendor-ID ist dieselbe Nummer wie bei PROFINET und über die PI-Tabelle öffentlich.
    • Sensoren ohne Seriennummer als Positionen mit Master und Port führen. Das reicht für die Betroffenheitsbewertung je Anlage.
    • Bei der Abnahme festlegen, welcher Weg (Feldbus, OPC UA, REST) je Mastertyp genutzt wird; die Stufenlogik dazu steht im Beitrag zum Netzwerkscan.

    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

    Nach Spezifikation V1.1.3 sind VendorID und DeviceID (Direct Parameter Page) sowie VendorName (ISDU 0x10) und ProductName (0x12) Pflicht. ProductID (Bestellnummer), SerialNumber, HardwareRevision und FirmwareRevision (0x13–0x17) sind optional; die großen Sensorhersteller füllen sie in der Regel, garantiert ist es nicht.

    Nur über den IO-Link-Master. Der gibt die Gerätedaten über sein Feldbus-Submodul (bei PROFINET per IOL_CALL oder Engineering-Werkzeug), über OPC UA nach OPC 30120 oder über die REST-Schnittstelle „JSON Integration for IO-Link“ heraus. Zuerst muss der Master selbst im Netz gefunden werden, etwa per PROFINET-DCP oder EtherNet/IP ListIdentity.

    Die VendorID ist dieselbe Nummer wie die PI-Vendor-ID und über die öffentliche PI-Herstellertabelle auflösbar. Die DeviceID ist herstellerintern und nur zusammen mit der VendorID eindeutig; die Zuordnung zum Produkt liefert die IODD, öffentlich suchbar im IODDfinder der IO-Link-Community mit über 7.500 Gerätebeschreibungen.