PROFINET is the industrial Ethernet standard of PROFIBUS & PROFINET International (PI), specified in IEC 61158 and IEC 61784. A controller exchanges cyclic process data with its field devices over standard Ethernet cabling, sharing the same medium with the TCP/IP traffic used for configuration and diagnostics.
Where PROFINET shows up on the plant floor
PROFINET is the default field network of current-generation Siemens controllers, so it turns up wherever control comes from that family: automotive and its supplier base, food and beverage, packaging, and broadly lines refurbished in the last two decades. You recognise it by the line or ring topology between cabinets, the managed switches built into decentralised I/O, and the fact that every device carries a station name as well as an IP address. That name matters: the controller finds its devices by name over DCP and assigns the IP address at startup, so replacing a module is a matter of giving it the right name rather than configuring the network by hand.
PROFINET versus PROFIBUS
They share a governing organisation, an engineering philosophy and a device model (slots, subslots, description files), but they are not the same bus and are not physically compatible. PROFIBUS DP is a serial bus over RS-485 twisted pair, with one master polling slaves in turn, addresses set on the device itself and segments that must be terminated at both ends. PROFINET uses switched Ethernet: every device gets a point-to-point link to a switch, the infrastructure is the same as IT, and process traffic coexists with HTTP or OPC-UA on the same cable. To bridge the two, a proxy presents an entire PROFIBUS segment as a single PROFINET device.
Getting data out of a PROFINET network
PROFINET real-time traffic is not a request/response protocol: it is Layer 2 Ethernet frames exchanged cyclically between controller and devices, and it is not routed off the segment. There is no register map an external client can poll the way it would with Modbus. Three practical routes exist.
The first is reading from the controller itself, which already holds the consolidated process image and usually exposes an OPC-UA server or a vendor protocol. It is the cleanest route and leaves the field network untouched, but it only reaches signals the program has mapped and it consumes CPU communication resources, so grouping reads beats firing one request per variable.
The second is passive capture: a mirror port on a managed switch, or a network TAP, plus an edge device with a listen-only interface. It adds no traffic and no extra node, but the cyclic frame is a flat block of bytes with no names attached. Making sense of it requires the controller hardware configuration and the device GSDML files, which say which offset belongs to which submodule. And because the network is switched, you only see traffic crossing the mirrored port, so where you tap decides what you can read.
The third is joining as a second controller through Shared Device, a standard feature that allows submodules of one IO device to be assigned to more than one IO controller. It is the only route that yields data the program does not expose, but it means changing the engineering and downloading the hardware configuration, which on many controllers requires a CPU stop and therefore a production window. On latency: the network cycle sits in the millisecond range, far below what any dashboard needs. The real bottleneck is the sampling rate you choose and the transport upwards, not PROFINET itself.
Related terms
PROFINET succeeded PROFIBUS and solves, with a different design, the same problem as EtherNet/IP: carrying cyclic process data over standard Ethernet. It coexists with OPC-UA on the same cable, hosts IO-Link masters as decentralised I/O, and typically relies on an industrial gateway when data has to leave the plant perimeter. At Captia Connect this is PLC connectivity: connection engineering across any brand, without replacing the control layer.