Can embedded MCUs handle the latest PROFINET spec?

With the advent of industrial Ethernet in the automation world, the requirements on computing power - and implementation complexity - have increased. While an 8-bit MCU may be sufficient for simple CANopen devices it may prove impossible for them to accommodate more complex protocols like PROFINET. This is partly due to the large volume of data and services which, besides the actual industrial Ethernet protocols, are also offered. It becomes important, therefore, to examine these loads in parallel to the standard control communication. However, before evaluating these challenges, it is worth providing a brief introduction to the general types of network traffic and how it is used by PROFINET.

Types of network traffic

In order to understand the test cases of load tests better, one should first consider (error) situations and the types of network traffic they may cause:

• Undirected Traffic, which is in fact not intended for the device under test, may involve broadcast (for all participants), multicast (for some participants) or unicast frames. Broadcast and multicast frames in the network are flooded at the Ethernet layer and can thus occur at any time in an Ethernet network; undirected traffic as unicast frames happens, generally, in the case of an error. Normally, an Ethernet switch refers to an internal address table. If the switch receives a frame with an unknown MAC source address, the port on which the frame was received is enlisted in the address table. This ‘address learning’ allows the switch to forward the unicast frames directly towards the target and not to flood these, as in the case of broadcast messages, to all ports. If however, the address table is full, any further address learning puts the switch into a fail-safe mode: the frames, like in the case of a hub, are forwarded to all ports. This behaviour is deliberately exploited in so-called MAC flooding (also known as Switch jamming). The attacker smuggles in Ethernet frames with spoofed source addresses till the address table of the switch is jam packed. A free Ethernet port on a switch is sufficient for this purpose. The goal of the attacker is to either generate overload intentionally or read along network information.

• Directed Traffic deals with the data traffic which is in fact intended for the device and was not, as in the case of undirected traffic, forwarded to the device mistakenly. This data can be sent via unicast, broadcast or multicast. In this traffic, the data can either be from a PROFINET connection or other services, for example from an HTTP server running on the device. In addition, there is also data from commonly used protocols such as ARP.

This data can be further subdivided as per Real Time (RT) and Non-Real Time (NRT) criteria. The RT traffic covers everything that serves to maintain a cyclic PROFINET connection. The NRT traffic includes the data from the PROFINET protocol itself as well as from other Ethernet frames (e.g. IP traffic).

A question of architecture

The MCU of a PROFINET device has thus to deal with a relatively high number of different frames. This load increases further with the increasing size of a projected network. In particular, in the start-up phase of the network, frames such as LLDP (Link Layer Discovery Protocol), ARP, etc. may frequently occur as burst. Both hardware and software should be designed properly to ensure reliable communication even in such situations. For a practical example therefore, it should first be considered which sequence of operations for processing a cyclic PROFINET communication are necessary.

Figure 1 shows an abstract from the timing diagram of PROFINET Stack from port on a Renesas RX63N. The data was obtained using the integrated tracing framework in the Stack. It shows the chronological course of the main process steps for transmitting an RT frame.

Figure 1 - Transmission of a cyclic PROFINET packet

On embedded platforms without an operating system, the Stack uses a timer routine in which all timers used are monitored in ms-interval with respect to their expiry. In Figure 1, the OAL_timer with a green line illustrates this. First, the timer for the cyclic packet processing is executed (illustrated in Figure 1 by the Cyclic with a yellow line). In Cyclic, the next frame to be transmitted is compiled and passed on to the Ethernet driver. When Cyclic is finished, further timers can be processed. In this case, the next LLDP frame to be transmitted is due. The LLDP is a Layer 2 protocol dealing with neighbourhood detection, and is not only used in PROFINET.

The frame is generated within the line marked as LLDP and passed on to the Ethernet driver. After completion of the timer, two further Ethernet interrupt activities can be identified; confirmation that both the frames (cyclic and LLDP) were transmitted. The marker reading on the top right in Figure 1 (highlighted by a red rectangle) shows that the entire action consumed only 119µs. If the interrupt context switching time were also to be taken into account, then the time would be around 125µs.

The timer interrupt is triggered about every 1ms. With that, the RX63N still provides plenty of computing time outside the PROFINET communication process for handling the data to be sent next. Further, in this period, other services, such as TCP for an HTTP server can be processed. This was a simple example without additional data traffic. How does the system behave when additional data is received?

Figure 2 - Cyclic communication and ARP Flood

For this purpose, using the ‘tcpreplay’ tool, pre-recorded ARP packets are fed back additionally into the network as quickly as possible, illustrated in Figure 2. The ARP packets can be recognised as a frequently triggered Ethernet interrupt (red line). However, as can be seen, the additional traffic hardly affects the cyclic communication. How can this be explained? For one, for such a realisation, it takes an MCU which allows prioritisation and interruption of interrupts. These features have been implemented correctly in Renesas RX63N. The processing or generation of cyclic frames is the most important task of the device, therefore, the timer interrupt has been assigned the highest priority. It thus triggers even while the device is busy processing a packet in the Ethernet interrupt routine and interrupts this.

Secondly, a smart feature of the RX63N that can largely relieve the CPU, especially during the high Ethernet network load, plays a role here. The RX63N is equipped with its own dedicated DMA controller (EDMAC) for the Ethernet controller (ETHERC). It spares the CPU from the task of copying the Ethernet frames to be sent or received. By means of descriptors, the CPU points to the memory area, in which the packet to be transmitted is located, or where the received packet is to be stored. The CPU can then process the packets. Thus, it is possible to process a packet while the EDMAC is already receiving or transmitting further packets.

There is no doubt that, in the future, load tests shall be a part of every release test if not of every certification. Here, it is important not only to test the simple communication case, but also to simulate the error conditions in the network. In PROFINET, the load tests are to become part of the certification in the near future. In Net load test, besides the RT data, different protocols are also fed additionally into the network traffic per unicast, broadcast, and multicast, thereby simulating different load levels ranging from the regular network traffic through to network overload. This is done depending upon the desired performance class (Net load class). Also the MCU and the Stack vendors must do their homework; software and hardware must be prepared to handle the error case, like it is in the RX63N.

Getting started

For an inexperienced user, the previous sections might sound relatively complicated. For the first steps, an RSK (Renesas Starter Kit) RX63N is recommended because together with the PROFINET Stack from port it offers a Ready-To -Go solution leading to immediate success and allows rapid prototype development. The Renesas E1 JTAG debugger and e2Studio development environment are available as development tools. The e2Studio development environment integrates all the tools necessary to write and debug the software, the demo application is shipped with all the necessary project files and thus contributes towards a smooth start with the starter kit.

Figure 3 - RX63N block diagram

The RSK carries an RX63N MCU having 2MB on-chip Flash and 128KB on-chip RAM. This group of products ​​with 165DMIPS at 100MHz CPU and Flash operation achieves high computing performance. To address a broad range of requirements this group is widely scalable; derivatives with integrated Flash memory from 0.5 to 2Mbytes Flash and 128 to 256KB RAM are available. Also with respect to the package variants, LQFP, LGA as well as BGA package versions are available.

In addition to the Ethernet MAC IEEE 802.3 compatible interface with MII and RMII for simple connection to a PHY, these components offer CAN 2.0B compliant interfaces with up to three channels (a CANopen solution from port is also available), two USB full speed hosts, USB OTG and device functions.

These RX products aim to provide the integration density, cost structure and extremely fast embedded Flash technology needed for applications running large communication stacks, such as PROFINET, in a single-chip without external memory. The detailed documentation on this can be downloaded from the Internet and is, of course, attached to the starter kit. Under the RXMAX program, the combination of Renesas' RX63N 32-bit MCU and port’s PROFINET protocol Stack offers a particularly attractive start in the field of PROFINET applications. The RX63N MCUs from Renesas can be operated with port's PROFINET without restrictions, thus enabling the development of powerful and cost-effective PROFINET I/O (CC -A, RT-1) devices. The cost advantage can extend through the simplified network structure right up to the system integrator and its customers. In principle, solutions such as CANopen, EtherNet/IP, POWERLINK and EtherCAT are possible on the same platform.