Werkspilot
    ← Insights

    OPC UA SBOM: what BuildInfo and the nameplate reveal about the controller

    In brief · As of October 2026

    Every OPC UA server must carry ServerStatus → BuildInfo: ManufacturerName, ProductName, SoftwareVersion, BuildNumber, BuildDate. This describes the server software – on an S7-1500 that is the controller firmware version, on a gateway only the stack. The DeviceType nameplate of the companion specification "OPC UA for Devices" (Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, optionally ProductCode) is more informative but exists only if the manufacturer implements the specification. Discovery runs via GetEndpoints on TCP 4840 and mDNS in the subnet; reading needs a session and often a certificate. For the plant SBOM, OPC UA captures the controller and machine level – not the field devices behind it.

    BuildInfo is mandatory, the nameplate is not

    OPC UA Part 5 defines the node ServerStatus with the structure BuildInfo under the Server object – six fields that every server must fill. The companion specification OPC 10000-100 "Devices" (DI) adds a nameplate per device:

    SourceFieldsMandatoryMeaning for the device list
    ServerStatus → BuildInfo (Part 5)ProductUri, ManufacturerName, ProductName, SoftwareVersion, BuildNumber, BuildDateyes, every serverManufacturer and version of the server software; on controllers usually the firmware version
    DeviceType (OPC 10000-100, DI)Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, DeviceRevisiononly with DI implementationA real nameplate – the columns of the plant SBOM
    DeviceType optionalProductCode, ManufacturerUri, ProductInstanceUri (IEC 61406), AssetIdnoOrder number and unique instance URI, if maintained
    Companion specificationsPnIdentificationType (OPC 30140, mirrors I&M0), IOLinkDeviceType (OPC 30120), Machinery (OPC 40001)per specificationField devices and machine identity, if the server maps them

    Discovery on port 4840, reading only with a session

    An OPC UA server is found via GetEndpoints on its endpoint (usually TCP 4840); with a Local Discovery Server with multicast extension additionally via mDNS (_opcua-tcp._tcp) in the subnet. Many embedded servers register nowhere – in practice, port 4840 is checked per address and GetEndpoints is called. BuildInfo is frequently readable anonymously; the DI nameplate under Objects/DeviceSet often demands a user and certificate trust. Sessions on small controllers are scarce (an S7-1200 has few), so an inventory tool disconnects again immediately.

    What OPC UA does well: naming controllers, HMIs, gateways and IO-Link masters with an OPC 30120 server unambiguously. What it cannot do: enumerate the field devices of an S7-1500 – their I&M data appears only if the server implements OPC 30140, and on controllers that is the exception.

    What OPC UA does not provide

    • Field devices: simple I/O, drives and sensors have no server; they need PROFINET I&M0, EtherCAT through the master or IO-Link through the master.
    • A normalised manufacturer: Manufacturer and Model are free text; there is no registration, only URIs.
    • Unambiguity between server and device: BuildInfo can name a third-party stack, not the device firmware – an assignment problem for the SBOM.
    • Access without preparation: certificates, users and trust lists have to be set up per plant; failed logins generate security events at the operator.

    What this means for the plant SBOM

    • Use OPC UA as the source for the controller level: read BuildInfo per server, take the DI nameplate where present, and keep server firmware separate from device firmware.
    • Set up credentials and certificates for inventory access at acceptance (FAT) – afterwards, that is the most laborious part.
    • For the field devices, use the protocol-level methods; the overview is in the article on the network scan per controller world.
    • Take over ProductInstanceUri (IEC 61406) if the manufacturer maintains it – that is the most unambiguous device identifier a protocol currently offers.

    All 13 manufacturers compared: SBOM by manufacturer →

    Trial Werkspilot Scan on your own plant.

    We are trialling the capture with a few plant builders on their test or reference plants, for four months, extended stage by stage around their controllers. The partner gets one plant of their choice as a plant SBOM: every reachable device with manufacturer, order number and firmware version, open items listed individually.

    Ask about the development partnership →

    Werkspilot Scan reads these fields from the maintenance PC, read-only and with a fixed request list, and keeps them per plant. This article describes the state of the specifications at the time of publication.

    Frequently asked questions

    Mandatory is ServerStatus → BuildInfo with ProductUri, ManufacturerName, ProductName, SoftwareVersion, BuildNumber and BuildDate – this describes the server software, on controllers usually the firmware version. If the manufacturer implements OPC UA for Devices, a nameplate per device is added: Manufacturer, Model, SerialNumber, SoftwareRevision, HardwareRevision, optionally ProductCode and ProductInstanceUri.

    As a rule, no. The I&M data of PROFINET devices appears in the server only if it implements the companion specification OPC 30140; IO-Link devices only through a master with an OPC 30120 server. For field devices, the protocol-level paths remain: PROFINET I&M0, EtherCAT through the master, IO-Link through the master.

    Via GetEndpoints on TCP 4840 per address and, where a Local Discovery Server with multicast extension is running, via mDNS in the subnet. Many embedded servers do not register; in practice, port 4840 is checked. Reading BuildInfo is often possible anonymously, the DI nameplate usually demands a user and certificate.