Werkspilot
    ← Blog

    OPC UA SBOM: Was BuildInfo und Typenschild über die Steuerung verraten

    Kurz gefasst · Stand: Oktober 2026

    Jeder OPC-UA-Server muss ServerStatus → BuildInfo führen: ManufacturerName, ProductName, SoftwareVersion, BuildNumber, BuildDate. Das beschreibt die Server-Software. Auf einer S7-1500 ist das der Steuerungs-Firmwarestand, auf einem Gateway nur der Stack. Das DeviceType-Typenschild der Companion-Spezifikation „OPC UA for Devices“ (Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, optional ProductCode) ist aussagekräftiger, existiert aber nur, wenn der Hersteller die Spezifikation umsetzt. Discovery läuft über GetEndpoints auf TCP 4840 und mDNS im Subnetz; Lesen braucht eine Sitzung und oft ein Zertifikat. Für die Anlagen-SBOM erfasst OPC UA die Steuerungs- und Maschinenebene, nicht die Feldgeräte dahinter.

    BuildInfo ist Pflicht, das Typenschild nicht

    OPC UA Part 5 definiert unter dem Server-Objekt den Knoten ServerStatus mit der Struktur BuildInfo, sechs Felder, die jeder Server füllen muss. Die Companion-Spezifikation OPC 10000-100 „Devices“ (DI) ergänzt ein Typenschild je Gerät:

    QuelleFelderPflichtBedeutung für die Geräteliste
    ServerStatus → BuildInfo (Part 5)ProductUri, ManufacturerName, ProductName, SoftwareVersion, BuildNumber, BuildDateja, jeder ServerHersteller und Version der Server-Software; auf Steuerungen meist der Firmwarestand
    DeviceType (OPC 10000-100, DI)Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, DeviceRevisionnur bei DI-Umsetzungechtes Typenschild – die Spalten der Anlagen-SBOM
    DeviceType optionalProductCode, ManufacturerUri, ProductInstanceUri (IEC 61406), AssetIdneinBestellnummer und eindeutige Instanz-URI, wenn gepflegt
    Companion-SpezifikationenPnIdentificationType (OPC 30140, spiegelt I&M0), IOLinkDeviceType (OPC 30120), Machinery (OPC 40001)je SpezifikationFeldgeräte und Maschinenidentität, wenn der Server sie abbildet

    Discovery auf Port 4840, Lesen nur mit Sitzung

    Ein OPC-UA-Server wird über GetEndpoints auf seinem Endpunkt (meist TCP 4840) gefunden; mit einem Local Discovery Server mit Multicast-Erweiterung zusätzlich per mDNS (_opcua-tcp._tcp) im Subnetz. Viele eingebettete Server registrieren sich nirgends. Praktisch wird Port 4840 je Adresse geprüft und GetEndpoints aufgerufen. BuildInfo ist häufig anonym lesbar; das DI-Typenschild unter Objects/DeviceSet verlangt oft Benutzer und Zertifikatsvertrauen. Sitzungen auf kleinen Steuerungen sind knapp (eine S7-1200 hat wenige), ein Inventarwerkzeug trennt deshalb sofort wieder.

    Was OPC UA gut kann: Steuerungen, HMIs, Gateways und IO-Link-Master mit OPC-30120-Server eindeutig benennen. Was es nicht kann: die Feldgeräte einer S7-1500 aufzählen. Deren I&M-Daten tauchen nur auf, wenn der Server OPC 30140 umsetzt, und das ist bei Steuerungen die Ausnahme.

    Was OPC UA nicht liefert

    • Feldgeräte: einfache I/O, Antriebe und Sensoren haben keinen Server; sie brauchen PROFINET-I&M0, EtherCAT über den Master oder IO-Link über den Master.
    • Einen normierten Hersteller: Manufacturer und Model sind Freitext; eine Registrierung gibt es nicht, nur URIs.
    • Eindeutigkeit zwischen Server und Gerät: BuildInfo kann den Stack eines Drittanbieters nennen, nicht die Gerätefirmware, für die SBOM ein Zuordnungsproblem.
    • Zugriff ohne Vorbereitung: Zertifikate, Benutzer und Vertrauenslisten müssen je Anlage eingerichtet sein; fehlgeschlagene Anmeldungen erzeugen Sicherheitsereignisse beim Betreiber.

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

    • OPC UA als Quelle für die Steuerungsebene nutzen: BuildInfo je Server lesen, DI-Typenschild übernehmen, wo vorhanden, und Server- von Gerätefirmware getrennt führen.
    • Zugangsdaten und Zertifikate für den Inventarzugriff bei der Abnahme einrichten. Nachträglich ist das der aufwendigste Teil.
    • Für die Feldgeräte die protokollnahen Verfahren nutzen; der Überblick steht im Beitrag zum Netzwerkscan je Steuerungswelt.
    • ProductInstanceUri (IEC 61406) übernehmen, wenn der Hersteller sie pflegt. Das ist die eindeutigste Gerätekennung, die ein Protokoll derzeit anbietet.

    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

    Pflicht ist ServerStatus → BuildInfo mit ProductUri, ManufacturerName, ProductName, SoftwareVersion, BuildNumber und BuildDate. Das beschreibt die Server-Software, auf Steuerungen meist den Firmwarestand. Setzt der Hersteller OPC UA for Devices um, kommt ein Typenschild je Gerät hinzu: Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, optional ProductCode und ProductInstanceUri.

    In der Regel nicht. Die I&M-Daten von PROFINET-Geräten erscheinen im Server nur, wenn er die Companion-Spezifikation OPC 30140 umsetzt; IO-Link-Geräte nur über einen Master mit OPC-30120-Server. Für Feldgeräte bleiben die protokollnahen Wege: PROFINET-I&M0, EtherCAT über den Master, IO-Link über den Master.

    Über GetEndpoints auf TCP 4840 je Adresse und, wo ein Local Discovery Server mit Multicast-Erweiterung läuft, per mDNS im Subnetz. Viele eingebettete Server registrieren sich nicht; praktisch wird Port 4840 geprüft. Das Lesen von BuildInfo ist oft anonym möglich, das DI-Typenschild verlangt meist Benutzer und Zertifikat.