PROFINET Communication Channels [Tech Tip]

  • Post category:TECH TIPS
  • Reading time:8 mins read

PROFINET is great at moving information across a network – we never get tired hammering that message home. But exactly how PROFINET moves that information is still a gray area for a lot of users, and deserves a closer look here.


To understand how PROFINET moves information, it helps to keep in mind what kind of information it’s moving.  Does the information need to be delivered immediately?  Is it safety-critical? Is it a large amount of information that is only sent once?  These different types of information call for different transmission mechanisms, and those mechanisms make up “Communication Channels”  There are three Communication Channels in PROFINET: Real-Time (RT), Non-Real-Time (NRT), and Isochronous Real-Time (IRT).

Those communication channels rely on a lot of network protocols to exchange data across an Ethernet network.  Instead of lumping all of those protocols together in one basket, we’ll try to arrange them in to a framework to keep track of them.  That framework is called the OSI (Open Systems Interconnection) Model.  If you haven’t heard of the OSI model, don’t worry – the internet is full of great resources to help you wrap your head around it.

Filling Out the Protocol Stack

PROFINET uses a basket full of protocols to fill up the OSI model.  And each of these protocols has some data that has to be transmitted between communication partners.

The most fundamental layer, the Physical layer, is electrical.  Whether that’s via electrons bouncing down a wire, radio waves moving through the air, or photons careening through an optical fiber… there are a lot of ways to implement the Physical layer.  So, the PROFINET protocol has picked a couple of common Physical layer protocols that have been in place for decades.  The IEEE 802 protocol suite encompasses what we think of as wired Ethernet (802.3) and wireless Ethernet (802.11).

Building off of existing protocols is pretty common practice – why re-invent the wheel when someone’s already put a lot of work in to an open standard?  And so PROFINET specified regular old 802.3 Ethernet for the Data Link Layer.  That means that every PROFINET device has a MAC (Media Access Control) Address.

PROFINET relies on many standard protocols to move data across networks. And because those protocols have relative strengths and weaknesses, PROFINET only uses some when it absolutely has to.

PROFINET also uses the IP (Internet Protocol), UDP (User Datagram Protocol), and RPC (Remote Procedure Call) protocols for some communications. But those protocols come with increased overhead (more bytes on the wire, more processing time at the source and destination), and so PROFINET only calls them in to service when it absolutely has to.  However, they have some real benefits – just look at all of the address information packed in to a UDP/IP packet: MAC addresses, IP addresses, and UDP ports can all be used to help switch, route and process the PROFINET data.
There are two main problems using the entire OSI stack for all communications:

  1. Each layer of the stack means extra work has to be done to pack and unpack the PROFINET data at the source and destination
  2. Using the Network Layer adds some transmission delay between the sender and receiver

Both of these issues add to delays called “latency” (lag) and “jitter” on the network.  Latency is a predictable delay between a transmitter and receiver.  On large networks, it may be on the order of 10 – 100 ms.  Jitter is the variance in latency from one packet to the next.  For instance, if a packet arrived at the destination 20 ms after it was transmitted and the next arrived 30 ms after that, the network would be said to have a high amount of jitter.

Real Time (RT) Channel

PROFINET only uses OSI layers one and two to transmit real-time data. One the wire, that means that only the Destination and Source MAC addresses are packed in the frame, along with the Ethertype.

Latency and jitter are bad news for a “real time” industrial automation protocol.  So PROFINET designed the “Real Time” channel to try to reduce both of those values.  The RT channel skips the encapsulation steps in the Network, Transport and Session layers.  This means that the frames exchanged over the RT channel have both low latency and low jitter, but there’s a real drawback, too: there’s no IP address.  And that means that RT frames can’t be routed between LANs.

Non Real Time (NRT) Channel

PROFINET uses the NRT channel for less time-sensitive communications, like setting up a connection between a device and controller or accessing diagnostic data from an external network. But that added flexibility comes with increased data overhead – 108 extra bytes on each packet.

Routing restrictions can be a real problem on large networks, where diagnostic tools need to have access to PROFINET devices to keep tabs on the operating state of the PROFINET network.  So PROFINET also has a “Non Real Time” (NRT) communication channel.  It uses all the layers of the OSI model, and does have IP addresses.  So, PROFINET supervisors can access devices from across routing boundaries or even over the Internet.  But the tradeoff is higher latency and jitter for these NRT communications.

Isochronous Real Time (IRT) Channel

As stripped-down as the RT channel is, it still has some unavoidable jitter from transmission through standard Ethernet switches.  Switches can act like traffic intersections, funneling multiple streams of data down to one connection.  And just like a crowded intersection, switches can add unexpected delays to traffic.

IRT eliminates those delays by adding to the the rules used to switch Ethernet traffic and creating special rules for PROFINET traffic.  It adds some extensions to regular IEEE 802.3 Ethernet to implement something like a “HOV Lane” for IRT traffic.  Technically, it turns a stochastic CSMA-CD (Carrier Sense Multiple Access – Collision Detection) network in to a deterministic TDMA (Time Division Multiple Access) network – but that level of detail is best left to an article on IRT.

Making Sense of it All

If that sounds confusing, think about it in terms of how you communicate at work.  You actually have different types of communication channels with your co-workers.  If you work with someone every day as a peer and know the details of what they do, odds are you send pretty short emails when you have to ask questions.  You both know the context for the communication (what you’re working on, who you’re working with, what you’re trying to do), and because you have a common understanding of the context of the communication, you can make it brief and efficient.

But then think about raising an issue or asking a question of someone two or three levels up the org chart.  This person probably has no idea what you do day-to-day, and you don’t really know what they do, either.  So your communication has to include a lot of that context – you first have to bring them up to speed on a topic before you can ask for help or make a recommendation.

So you have two different communication channels, one for communication with a peer who shares some common “context” with you (RT), and one for communicating with folks who don’t share much of a “context” with you (NRT).  PROFINET does exactly the same thing.  It tries to keep things short and efficient, but it also has a way to be verbose when if necessary.


This article originally appeared as a lesson at PROFINET University