PROFINET IRT Hardware: Achieving 1µs Jitter in Real-Time

A hardware-based PROFINET solution uses dedicated silicon — application-specific integrated circuits (ASICs), FPGAs, or SoCs with on-chip EtherType/PTCP accelerators — to terminate real-time frames, schedule isochronous phases, and forward cut-through traffic with bounded latency. Compared with a software stack running on a generic Ethernet MAC under a general-purpose CPU, a hardware implementation removes the host interrupt path, eliminates queueing in non-real-time kernel space, and guarantees forwarding decisions inside deterministic time budgets. PROFINET specifications published by PROFIBUS & PROFINET International (PI) explicitly require this kind of hardware support for IRT (Isochronous Real-Time) operation in Conformance Class C and above, where the maximum permitted jitter from application cycle to bit on the wire is 1 µs.

PROFINET Protocol Classes and Their Hardware Requirements

PROFINET defines three real-time flavors — RT (Real-Time), IRT (Isochronous Real-Time), and the newer TSN-aligned profiles — plus a non-real-time channel used for parameterization, diagnostics, and HTTP/OPC UA. The hardware requirements increase sharply as you move from NRT to IRT.

Only RT (Conformance Class A and B) can be implemented fully on commercial off-the-shelf (COTS) silicon. IRT class devices must integrate a PROFINET IRT controller ASIC — most commonly the Siemens ERTEC family — and a managed switch core that supports scheduled cut-through forwarding. Reference: PI PROFINET Technology Overview.

The 1 µs Jitter Budget: What Actually Has to Fit Inside It

The headline number — 1 µs maximum jitter from application task dispatch to frame transmission — is the aggregate of every single delay element between the PLC cycle and the copper. To meet it, each contributor must be measured, allocated, and closed out:

1. PLC input image acquisition: ~10–50 µs depending on I/O backplane scan, but this latency is not jitter; only its variation matters. Hardware input filters and synchronous scan reduce variance to nanoseconds.
2. PROFINET stack processing (software path): 50–500 µs on a high-performance CPU. Its jitter alone can swallow the budget. Hardware offload reduces this to ~1 µs in the ERTEC path.
3. Wire entry (PHY + MAC): 0.5–2 µs, dominated by PHY serialization and preamble. The ERTEC integrates PHY-aware timing capture to remove preamble uncertainty.
4. Switch traversal per hop: < 5 µs for a cut-through switch; store-and-forward adds 10+ µs and is not usable for IRT. Each additional switch adds its own budget slice.
5. Wire propagation: ~5 ns/m. For a 100 m cable this is 500 ns each way — non-trivial over 7 hops of cable.
6. Receiving station framing: another 0.5–2 µs at the endpoint ASIC.

Software stack jitter on a typical industrial CPU ranges from 50 µs to several milliseconds depending on cache misses and interrupt coalescing — orders of magnitude beyond what IRT permits. A hardware implementation reduces the controllable slice to a single-digit microsecond figure, leaving the remaining budget to the deterministic parts of the topology.

Hardware Building Blocks: ERTEC, FPGAs, and Hybrid SoCs

The most widely deployed PROFINET IRT silicon is the Siemens ERTEC family, used both on Siemens PLCs (as the integrated PROFINET interface on S7-1500, ET200SP, and certain SINAMICS drives) and licensed to third-party vendors for IO-device integration.

Beyond ERTEC, three other implementation paths exist:

• FPGA-based IRT: reference designs from PI and FPGA vendors (Altera/Intel, Xilinx/AMD) provide the full IRT frame engine in programmable logic, used in custom I/O and safety controllers where off-the-shelf ASICs don't fit.
• Renesas RZ/T2M, RZ/N2L: industrial SoCs that integrate a PROFINET IRT MAC, ARM Cortex-R host core, and on-chip EtherCAT/EtherType accelerators — aimed at servo drives and motion controllers.
• TSN-capable SoCs: NXP i.MX RT1170, Texas Instruments Jacinto, and similar parts target Conformance Class D with 802.1Qbv scheduled traffic instead of legacy IRT.

The shared requirement across all of these is a hardware block that recognizes the PROFINET RT EtherType 0x8892, holds an IRT-scheduled time slice, and forwards the frame in cut-through mode while still meeting the store-and-forward correctness contract for oversized or erroneous frames.

Performance Tradeoffs: Hardware vs. Software PROFINET

Where a software-only PROFINET RT stack is acceptable, it can run on virtually any industrial CPU with a 100 Mbit/s or 1 Gbit/s Ethernet MAC. The question is not "does it work" but "does it meet my cycle and jitter targets."

The decision is therefore not "hardware or software" but "which parts of the system carry real-time traffic." A typical architecture pairs a hardware PROFINET IRT controller (e.g. ET200SP IM 155-6 PN HF with ERTEC 400P) with a higher-level controller running Ethernet/IP or Modbus TCP on the same cable, where software latency is tolerable.

Topology Constraints for IRT Networks

Because IRT depends on deterministic forwarding, the network topology must be engineered — not discovered. PI's PROFINET Installation Guide imposes the following practical limits:

• Line depth: Typically up to 50 IRT switches in series for Conformance Class C, with each switch synchronized via PTCP (Precision Time Protocol, IEEE 1588 derivative) on the sync master. Greater depths require explicit latency admission by the planning tool.
• Update time / reduction ratio: The ratio SendClock = 31.25 µs and ReductionRatio = N define the application cycle. A reduction ratio of 32 yields a 1 ms cycle, 8 yields 250 µs, 4 yields 125 µs, 1 yields 31.25 µs (boundary case requiring every IO device to support the full IRT bandwidth reservation).
• Phase length reservation: Each switch along the IRT path must be told, at planning time, the exact length of the time slice reserved for the IRT phase. This reservation is added to the GSDML file descriptor of the device and read by the controller's planning tool (e.g. TIA Portal with the IRT option).
• Real-time channel bandwidth: In a 100 Mbit/s IRT network, the maximum usable real-time channel is ~80 Mbit/s after preamble, IFG, and sync overhead. Real deployments reserve 50–60 Mbit/s.

Integration with Siemens Controllers and Third-Party PLCs

The most common path to a hardware PROFINET solution is via the Siemens ET200SP or ET200MP distributed I/O system, where the interface module (IM 155-6 PN HF or IM 155-6 PN HS) carries the ERTEC and exposes the IRT capability to the host CPU.

// Typical TIA Portal hardware configuration (parameter examples)
PROFINET interface:
  Subnet: 192.168.0.0/24
  Device name: im155-6pn-hf-1
  Conformance class: C (IRT)
  SendClock: 31.25 µs
  ReductionRatio: 32          // application cycle = 1 ms
  Watchdog time: 3x SendClock * ReductionRatio = 3 ms
  Synchronization role: Sync master
  Port 1 (topology): "Line", partner auto-detect
  Port 2 (downstream): "Line", partner auto-detect
IO devices in this IRT phase:
  - DO 8x24VDC (DQ 8x24VDC/0.5A HF)
  - AI 4xU/I/RTD/TC ST
Each device GSDML:
  <IRTPhase> reserved-by-controller: yes</IRTPhase>
  <MaxBridgeDelay> 3000 ns</MaxBridgeDelay>

Third-party controllers that need PROFINET IRT — typically high-speed motion controllers — either license the ERTEC IP directly from Siemens or load it onto an FPGA-based mezzanine. ABB, B&R, Beckhoff, and Bosch Rexroth have all shipped motion systems with ERTEC variants or equivalent silicon; consult the vendor's PROFINET conformance certificate in the PI product catalog for the certified Conformance Class.

When Hardware Acceleration Is Overkill

Before specifying a hardware solution, verify that the application actually requires it. The following cases generally do not benefit from IRT:

• I/O-only systems with cycle > 1 ms: PROFINET RT Class 1 over a managed switch is sufficient and supports the full PROFINET IO device catalog without IRT licensing.
• Drive systems running non-isochronous speed setpoints: With standard PROFIdrive telegrams and cycle < 4 ms, RT plus priority tagging is commonly adequate and avoids the planning-tool overhead.
• Process plants with analog update rates of 100–500 ms: Hardware IRT provides no benefit; the latency is dominated by field devices and the engineering gain is in diagnostics.

The cases that do require hardware IRT are isochronous motion (synchronization between axes with sub-millisecond tolerance), high-speed assembly with vision triggering, printing and converting machines, and any application where the application cycle approaches the underlying network jitter of a software implementation.

Sizing: Devices, Cycle Time, and CPU Headroom

Quantify the requirement before selecting silicon. As a rule of thumb:

For IRT networks, the controller CPU is typically freed of nearly all real-time processing — only the IRT stack initialization and configuration runs there. The runtime frame handling, forward scheduling, and timing measurement all live in the ERTEC and the configured switches. This is the decisive advantage in dense applications: a single S7-1518 can coordinate >200 IRT devices without crossing a 50% CPU threshold.

Selection Procedure: From Specification to BOM

1. Define the cycle and jitter requirement. If jitter > 1 ms is acceptable, stop — you need RT, not IRT. If jitter < 100 µs is required, IRT is mandatory.
2. Draw the line topology in TIA Portal (or equivalent). Insert intended SCALANCE XF-200 (IRT) or SCALANCE XC/XB-200 (RT) switches; verify each supports the desired conformance class.
3. Pull certified GSDML files. Every IRT candidate IO device must carry a PI certificate for Conformance Class C. Check the PI Certified Products Database for the vendor and part number.
4. Configure send clock and reduction ratios per device. Devices that cannot meet the fastest send clock are placed in a separate IRT phase or demoted to RT.
5. Run the topology editor's latency check. The planning tool computes worst-case bridge delay for each device and validates the schedule window.
6. Order with the correct firmware revision. For example, ET200SP IM 155-6 PN HF must be at firmware V3.0 or later for full IRT top-up; below that, only the older IRT operator is supported.
7. Provision spare ports and IRT-capable switches. Adding a non-IRT switch mid-life will collapse the schedule window and force a redesign.

Verification and Commissioning Tests

After installation, run these verification steps before declaring the line production-ready:

1. Topology check: TIA Portal "Go online → Topology" view must show all expected peers at the expected ports. Mismatches indicate a miswired patch panel.
2. Watchdog drop test: Pull the sync master's sync line and observe the synchronized slaves enter a defined state within one WatchDogTime.
3. Jitter measurement: Use the PROFINET diagnostic record 0x800A (IRT timing) to read the actual jitter each device reports relative to the sync master. The maximum across all IRT devices must remain below 1 µs.
4. Non-RT load test: Flood the network with 80 Mbit/s of TCP traffic during an isochronous phase and confirm the IRT jitter number is unchanged.
5. Cable length check: PI specifies a maximum segment of 100 m for copper (Cat 5e or better) and 50 km for single-mode fiber with media converters. Anything between must be measured with a cable certifier against ISO/IEC 11801 Class D or better.

Troubleshooting Matrix

Migration Path: From RT to IRT and From IRT to TSN

Many plants running RT today will eventually need IRT (or, increasingly, TSN). The migration is not a forklift upgrade — it can be staged per device:

• RT to IRT: Replace controller-side IRT-firmware-capable managed switches in place. Each IRT-capable device supports a mixed phase (IRT devices scheduled, RT devices run in the leftover band).
• IRT to TSN (CC-D): Requires 802.1AS grandmaster and 802.1Qbv-capable switches, typically the SCALANCE XC-200 / SCALANCE XR-500 generation. Existing IRT devices can co-exist on the same cable as TSN-only devices if the switch supports TSN-shaper fall-back behavior; consult Siemens application note PROFINET over TSN — Configuration Guidelines for the exact migration rules.
• Stand-alone TSN without IRT: Suits very high speed or low-latency applications but loses backward compatibility with installed PROFINET IO devices and is rarely the right choice for plant retrofits.

Key Takeaways

• Hardware-based PROFINET is non-negotiable for IRT — the 1 µs jitter budget cannot be closed in a software stack on a general-purpose CPU.
• Siemens ERTEC 200/400 are the reference implementations; FPGA and SoC paths exist for embedded and motion-control vendors.
• Topology, switch scheduling, and send-clock configuration are pre-planned — IRT does not auto-negotiate.
• CPU side wins from hardware offload are real but secondary to the determinism guarantee; choose IRT only when the application cycle and jitter demand it.
• Audit PI-certified GSDML files, firmware revisions, and SCALANCE switch part numbers before commissioning; the IRT plan is only as good as the weakest link in the line.

Frequently Asked Questions