Accessible Engineering Innovation, home Talk to an engineer
PROFINET · EtherCAT · POWERLINK · EtherNet/IP · TSN · Ethernet-APL

Real-Time Ethernet Engineering

Real-time Ethernet stack integration for device makers, machine builders and chip vendors. We develop, port, tune and pre-compliance test PROFINET, EtherCAT, POWERLINK, EtherNet/IP and TSN on your silicon, train your team on it, and stay behind it afterwards.

Talk to an engineer Read our real-time Ethernet engineering notes
Audience

Who this is for

  • Device manufacturers

    Put a conformant real-time Ethernet interface into a transmitter, encoder, drive, IO block or gateway, without standing up a protocol team to do it.

  • Machine builders and system OEMs

    Refresh a machine or system platform onto deterministic Ethernet without redesigning the machine around it.

  • Silicon vendors and chip makers

    Prove a new part speaks industrial Ethernet, with a reference integration, a sample framework your customers can build on, and the benchmark numbers to publish alongside it.

Scope

What we do

  1. 01

    Stack development and porting

    Commercial and open-source stacks ported onto your MCU, SoC, FPGA or Linux platform and brought up against real traffic rather than a simulator, or a custom stack built where no existing one fits the constraint you are working to.

  2. 02

    Cycle-time tuning

    Driver, scheduler and NIC work to hold the cycle and jitter the application actually needs, measured under load.

  3. 03

    Small-footprint and SoC designs

    Interfaces built to fit the part you have chosen, from a compact MCU node to an FPGA fabric implementation or an SoC with a real-time subsystem.

  4. 04

    Drivers, BSP and middleware

    The layers beneath the stack, on Linux, Windows and RTOS platforms, because a protocol only holds its cycle if what sits under it does.

  5. 05

    Time synchronisation

    PTP / IEEE 1588 and 802.1AS integration, with sync accuracy verified across every hop on the path.

  6. 06

    TSN configuration and benchmarking

    Qbv gate schedules computed, pushed and then verified against what the network does under load, not what the datasheet claims.

  7. 07

    Pre-compliance testing

    Devices run against the protocol organisation's own test bundles and netload classes in-house, before you book the accredited lab.

  8. 08

    Training, co-development and long-term support

    Your engineers trained on what we deliver, the first implementation built alongside them, then third-line support behind your own first line for as long as the product ships.

Capability

Technology verticals

Our technology verticals
PROFINET · EtherCAT · Ethernet POWERLINK · EtherNet/IP · IEEE 802.1 TSN · 10BASE-T1L / Ethernet-APL
Platforms
FPGA · SoC with real-time subsystem · applications processor · MCU and small-footprint designs · real-time Linux · Windows with a PCIe NDIS miniport · RTOS
What you receive
The protocol-integrated device, machine or silicon itself · stack and build environment · driver and BSP sources · interoperability and performance benchmark reports · white papers carrying the test data · cycle and jitter measurement report · pre-compliance test log · integration notes · trained engineers

What do real-time Ethernet stack integration services cover?

Real-time Ethernet stack integration services develop, port, tune and pre-compliance test a device's protocol layer.

This is for device manufacturers, machine builders and silicon vendors. We develop, port, tune and pre-compliance test PROFINET (including IRT class C), EtherCAT, Ethernet POWERLINK, EtherNet/IP and IEEE 802.1 TSN on FPGA, SoC, applications-processor, MCU and real-time Linux platforms. Our team has delivered software masters at 80 µs cycle time, and multi-vendor PROFINET IRT register control with application synchronisation within 3 µs where hardware acceleration carries the timing. The engagement is usually one of these shapes:

  • A stack is developed or ported onto your platform and handed over with its build environment.
  • A stack you already have is tuned until it holds the cycle your application needs.
  • A part that has never run industrial Ethernet is brought up as a reference integration a vendor can publish, with a sample framework their customers can start from.
  • Your engineers are trained on the platform and protocol, with the first implementation built alongside them.

In each case the protocol layer is ours and the product stays yours, and the work runs from protocol selection through pre-compliance testing:

  • Selection weighs your installed base, target markets, silicon roadmap and certification cost, and ends in a prototype on your hardware rather than a recommendation slide.
  • Porting covers the stack, the driver beneath it and the build environment around it.
  • Tuning is measurement work: cycle time and jitter under load, not at idle, on the hardware that will ship.

What we do not do is commission a plant. We build the layer inside your product and integrate and test it with your engineers, onshore during integration and test and remotely afterwards.

One cycle drawn as a bar split into five segments — stack, OS and driver, NIC, wire and switch, and device turnaround — each labelled with the engineering decision that moves it, with the device segment marked as set by the slowest participant rather than by us

Where a cycle budget is actually spent, and which segment each engineering decision moves.

Each of them is the right answer somewhere, and the deciding constraint is usually not the protocol.

It is the installed base your customer already runs, and what their procurement documents name.

ProtocolWhat selects it
PROFINETThe broadest by installed base, covering discrete and process automation in one protocol, with IRT for the isochronous end
EtherCATDevice density and the shortest motion cycles. On the controller side silicon vendors supply no master, so EtherCAT master integration services means taking a third-party MainDevice stack and making it run correctly alongside your application
EtherNet/IPWhat North American procurement most often names
POWERLINKThe licence model matters, and an open-source stack can be maintained in-house
TSNUnderpins converged networks going forward, but it is a layer beneath these rather than a replacement for them

Our team has shipped device and master work across all of these families, so the selection conversation is not a pitch for whichever one we know. Where the requirement is a long sensor run at low power instead of a fast cycle, the decision sits at the physical layer, 10BASE-T1L and Ethernet-APL, not the protocol above it.

Four protocols as columns with the conditions that select each one rather than a ranking: PROFINET for a European installed base, DACH machine builders and PI certification; EtherCAT for tight cycles, high axis counts and low cost per node; EtherNet/IP for North American plants, ODVA ecosystems and Rockwell controllers; POWERLINK where the licence model matters and an open stack can be kept in-house; with TSN as a full-width band beneath them

Selection conditions, not a ranking. TSN sits beneath all four rather than beside them.

What cycle time is realistic on a given platform?

Datasheets and delivered systems diverge here, so we quote from measured runs.

As an example, for POWERLINK managing nodes, our team extended openPOWERLINK’s standard test setup into the application groups customers actually build for: 250 µs for motion and robotics with 3 to 10 controlled nodes at 32 bytes per cycle, 1 ms for machine IO with 10 to 20 nodes at 64 to 128 bytes, and 5 ms for process automation with 30 or more nodes at 128 to 256 bytes. Those three points describe the actual trade: cycle time, node count and payload per cycle move together, and any figure quoted without the other two is incomplete. On the master side, a tuned real-time Linux with a driver written for determinism reaches an 80 µs network cycle. Windows is a different problem with a different answer, and it is covered on the system software page, not glossed here.

What sets the jitter you can actually hold?

The hardware sets it, more than the operating system does, once the NIC is doing its part.

  • With hardware-timed transmit. Our measured network jitter is 40 ns on a tuned real-time Linux with an Intel i210 card. Published figures for this class of design usually sit nearer 100 ns, and the gap is deliberate: a specifiable number has to carry buffer for process and model variation, where a measured one does not. Both are valid; they answer different questions.
  • Without it, or with it disabled. The same software holds around 20 µs. That is the figure for a generic NIC without hardware launch timing, and it is a useful floor to know, because it is what a software-only design gets no matter how well the scheduler is tuned.

Contributors stacked with bars showing how far each can move the achievable jitter: application and scheduling largest, then OS preemption, then the driver and interrupt path, then the NIC and whether it timestamps in hardware, and the switch and wire smallest, with the smallest marked as the one blamed first

The layers blamed first move the number least. The slowest participant sets what everyone holds.

How do you know the synchronisation actually holds?

We measure it on the path the device will actually run on.

PTP and IEEE 1588 integration is straightforward to claim and easy to get wrong, because a sync guarantee is only as good as the weakest hop. One ordinary switch in the middle of an otherwise capable network removes it. We measure sync accuracy at every hop and report where it degrades. The same applies to TSN. Qbv gate schedules have to be computed, pushed to every switch, and then verified against what the network does under load. The verification step is the one most often skipped, and it is the one that catches the misconfiguration.

Is TSN ready to standardise on?

The profile industrial buyers were waiting for now exists.

  • What changed. IEC/IEEE 60802, the TSN profile for industrial automation, was published in June 2026. Before it, “TSN support” on a datasheet could mean almost any subset of the IEEE 802.1 features, and two compliant devices could still fail to interoperate. A named profile is what makes a procurement requirement writable.
  • What did not. A network does not become conformant because a profile now exists. We test against the equipment you actually run and report where it meets the profile and where it does not, so the gap is known before it is designed around.

What does pre-compliance testing save?

Pre-compliance testing saves a booking, and usually a launch date.

A conformance run is a multi-day lab engagement, quoted per device by the test lab and charged by effort. Several test iterations happen inside one booking, but a device that fails and has to be re-submitted is quoted again, against a schedule that has already been announced to customers. We run PROFINET, EtherCAT, EtherNet/IP and POWERLINK devices against the protocol organisation’s own certification test bundles and netload classes in-house first, using the same tools the accredited lab will use. The formal attempt is then not the first time anyone has seen the device fail. The certificate is still issued by the accredited lab.

FAQ

Frequently asked questions

Who does real-time Ethernet stack work for a device manufacturer?
We do, as the protocol layer inside your product rather than as a system integrator on your customer's floor. Your team keeps the application and the customer relationship. We take the part that needs a standing specialism, integrate and test it with your engineers onshore and remotely, and stay behind it as third-line support.
Can a standard PC act as an industrial Ethernet master?
Yes, with a tuned real-time Linux and a driver built for determinism. Our team has built custom NIC drivers reaching an 80 µs network cycle without socket buffers. Where the NIC supports hardware-timed transmit, network jitter comes down to tens of nanoseconds; on a generic NIC without it, the same software holds around 20 µs.
Which hardware should we choose?
Ask this early, because the route decides the achievable cycle more than any later tuning does. FPGA fabric gives the tightest timing at the cost of toolchain and bring-up effort. An SoC with a real-time subsystem gives application headroom alongside deterministic timing. A dedicated communications IC solves conformance in silicon and ties you to one part. We size the trade against your volumes, your cycle and your service life.
Do you work on our silicon or only on reference platforms?
Both. Our team has shipped real-time Ethernet on Altera Cyclone III, IV GX and V SoC, on Xilinx Spartan, Artix and Zynq, on STMicroelectronics parts, on an NXP Arm SoC, on a TI Sitara applications processor and on a dedicated industrial communications IC. We port to new parts as launch enablement for vendors.
Can you train our engineers rather than just deliver the code?
Yes, and it helps to say what training does and does not achieve. The first return is a shared vocabulary and a shared basis for design decisions, so your team and ours are not solving the same problem in two languages, and the questions that would otherwise surface late get asked early. From there your engineers can take on integration, troubleshooting, first-line support and application-level customisation on their own. Depth in a protocol stack itself is built across years and several products rather than in one course, which is why training is paired with third-line support behind your first line.
How long does it take to add a protocol to a device?
It depends on the architecture, the platform, whether you are using a third-party stack, and whether the silicon is a new family port or a migration of one already supported. Two reference points from our own work. A PROFINET IO-Device built on a third-party stack, with your existing application logic migrated into function blocks rather than rewritten, is typically around eight weeks. Stack porting and development from scratch is more like twenty-four.
What drives the cost of adding a protocol?
Four things, and only one of them is our engineering. The implementation route sets the floor, because a software stack on a standard MAC, an SoC with protocol acceleration and a dedicated communications IC are different orders of cost in both silicon and effort. The stack licence comes next, and its shape matters more than its headline, because a development licence is often free while production licensing is seated per node, so your volumes decide what it actually costs. Certification is a multi-day lab booking charged by effort, plus the certificate fee. Then the engineering, which scales with whether this is a new silicon family or a migration of one already supported. We will not quote a stack vendor's numbers for them. Tell us the protocol, the platform and the volumes and we will size the whole picture with you.
Do you handle certification?
No. We prepare a device through pre-compliance testing and accompany the formal test. The certificate itself is issued by the protocol organisation's accredited lab.
References
  • IEC 61158 / IEC 61784 — industrial communication network standards
  • IEEE 802.1Q (TSN: 802.1Qbv, 802.1AS) — time-sensitive networking
  • IEC/IEEE 60802 — TSN profile for industrial automation
  • PROFINET specification — PROFIBUS & PROFINET International (PI)
  • EPSG DS 301 — Ethernet POWERLINK communication profile
  • EtherCAT Technology Group (ETG) — EtherCAT specification and conformance
  • IEEE 802.3cg — 10BASE-T1L single-pair Ethernet
Go deeper

Ready to scope this for your product?

Start with our engineering notes, or talk directly to the team that will build it.

Contact us Read our real-time Ethernet engineering notes