Log In Sign Up

Profi-Load: An FPGA-Based Solution for Generating Network Load in Profinet Communication

by   Ahmad Khaliq, et al.

Industrial automation has received a considerable attention for last few years with the rise of Internet of Things (IoT). Specifically, industrial communication network technology such as Profinet has played the role of a major game changer for such automation. However, industrial automation devices often have to exhibit robustness under dynamically changing network conditions and thus, demands a rigorous testing environment to avoid any safety-critical failures. Hence, in this paper, we have proposed an FPGA-based novel framework called "Profi-Load" to generate Profinet traffic with specific intensities for a specified duration of time. The proposed Profi-Load will facilitate the testing of the performance of automated devices under various network conditions. By using the advantage of inherent hardware parallelism and re-configurable features of FPGA, Profi-Load is able to generate Profinet traffic efficiently. Moreover, it can be reconfigured on the fly as per the specific requirements. We have developed our proposed "Profi-Load" framework by employing the Xilinx based "NetJury" device which is based on Zynq-7000 FPGA family. A series of experiments have been conducted to evaluate the effectiveness of Profi-Load and it has been observed that Profi-Load is able to generate precise Load at a constant rate for stringent timing requirements. Further, s suitable Human Machine Interface (HMI) has also been developed for quick access to our framework. The HMI at the client side can directly communicate with the NetJury device and parameters such as, required Load amount, number of packet(s) to be sent or desired time duration can be selected using the HMI.


page 1

page 5

page 6

page 7

page 8


FLAG: A Framework for FPGA-based LoAd Generation in Profinet Communication

Like other automated system technologies, PROFINET, a real-time Industri...

rIoT: Enabling Seamless Context-AwareAutomation in the Internet of Things

Advances in mobile computing capabilities and an increasing number of In...

Modelling machine type communication in IEEE 802.11ah networks

Wi-Fi was originally designed to provide broadband wireless Internet acc...

Machine Learning Methods for Device Identification Using Wireless Fingerprinting

Industrial Internet of Things (IoT) systems increasingly rely on wireles...

A Secure Dual-MCU Architecture for Robust Communication of IIoT Devices

The Industrial Internet of Things (IIoT) has already become a part of ou...

Towards a modeling and analysis environment for industrial IoT systems

The development of Industrial Internet of Things systems (IIoT) requires...

A Comprehensive Study on Load Balancers for VNF chains Horizontal Scaling

We present an architectural design and a reference implementation for ho...

I Introduction

A significant increase in the demand for Ethernet based infrastructure has been observed in the area ranging from automation technology to transport infrastructure [1]. In comparison to traditional office Ethernet based networks, the modern Ethernet technology use is much more challenging. Recent trends of technology exhibit the requirement of deterministic behavior of network. Amidst of such demand, Profinet [2] is found as one of the established real-time Ethernet based standard that is optimized for communication in automated industrial environment.

Industrial automation systems are complex in nature and usually structured into several hierarchical levels. Each of the level demands appropriate communication. These hierarchical levels can be categorized as 1) field-level networks, 2) control-level networks and 3) information-level networks [3]. At the automation field level, various sensors, actuators, I/O modules and drive units communicate via Profinet. Office- or information-level deals with centralized PCs for monitoring purposes. Automation control level includes controllers like PLC [4] that communicate with actuators and other IO devices with industrial field buses Profibus illustrated in Figure 2.

Fig. 1: Profi-Load in Nutshell

For instance, position control of electric AC motors is a widely adopted application in industrial automation environment. In this specific case, the control system requires real-time response within a strict duration. Hence, analysis of some significant network performance is required to evaluate the accomplishments of this requirement. To test the effectiveness of such applications, we need to test this application in rigorous testing environment, where we have to observe the performance of the application under various network conditions. Real-time characteristics and determinism issues, are the two uttermost important factors in Profinet based communication. To evaluate these two factors, one requires a framework which can generate specific network packets with stringent timing specification (commonly knows as net load or Load generation) [5].

Recently, with the advent of new hardware based solutions, FPGAs are emerging as a bright prospect for computation sensitive applications [6]. Due to its inherent parallelism feature, execution speed on this platform is much faster for an application in comparison to its software based execution on general purpose processor. Reconfigurability is another interesting feature that FPGAs exhibits. Due to this unique feature, the same system can be reconfigured multiple times by loading new configuration information (bitstream) as per the different requirements.

In this paper, we have provided an FPGA-based solution for Load generation in Profinet network. We coined our current traffic generation framework as “Profi-Load” shown in Figure 1. In order to make the framework efficient, we have chosen the FPGA-based Xilinx NetJury device [7], as our implementation platform. The experimental validation of our proposed framework on the aforementioned device showed that the Profi-Load can effectively achieve required amount of Load generation capacity with tight timing restrictions. The main contributions of this article can be stated as:

  • Define a framework, “Profi-Load” for generating specific amount of network Load for real-time Profinet communication.

  • Implemented the framework on the FPGA-based NetJury platform.

  • The HMI based user interface on the NetJury provides a friendly access environment to the user such that specific timing and Load generating parameters can be provided.

  • Profi-Load systematically exploits the reconfigurable feature of FPGA and thus, is capable to configure the NetJury device to assimilate user defined requirements.

  • The experimental validation and more specifically, Matlab, Hilscher netANALYZER and tektronix DPO4054B oscilloscope based analysis reveals the efficacy of our proposed framework on the NetJury device.

The remainder of the paper is organized as follows. Section II, gives a brief background about the Load generation strategy for industrial networks and related work. The Profi-Load framework is discussed in Section III by illustrating different user-defined cases. Section IV, provides a brief discussion of the NetJury device and its associated functionality. Section V, discusses on experimental outcome of the proposed framework with a discussion on the same. Finally, the paper concludes with Section VI.

Fig. 2: Profinet Network in an automation system [8].

Ii Background & Related Work

Ii-a Industrial Network Load Generator

Packet generator is a system which allows sending custom packets into the network with desired parameters, specified by the user. Similarly, a Network Load generator can also be considered as a special kind of packet generator which considers a specific rate to send the packet(s) into the network in order to achieve the specified Load. In general, packet generators can be broadly categorized into two types, based on the platforms on which it can be implemented. One type of generator is software based. There are many open source software-based packet generators including Pktgen  [9] , scapy [10], ostinato  [11] and all of these can run either on Linux or Windows with console or GUI. Another type is the hardware-based packet generator, this hardware-based solution involves processing elements like FPGAs, ASIC etc.

The basic hurdles for software-based solutions are its restriction on full line-rate testing. For example, proprietary products such as Ixia [12] are expensive and are not directly available to the open-source community. As an alternative, FPGA-based NetJury device allows an open-source implementation of packet generator along with a packet receiver operated at full Gigabit and Fast Ethernet line rates. However, such hardware or software based solutions while generating packets, do not consider the amount of Load to be maintained in the network, therfore, our proposed Profi-Load targets to generate traffic for desired Load specified by the user.

Ii-B Related Work

In recent past, the research community has focused on developing and improving various aspects of industrial automation systems and Profinet played a pivotal role here [13]. Researches have spun off in various directions to incorporate various advance modification on Profinet’s performance. In [14], authors depicted the performance analysis of Profinet networks applied in a motion control application. In [15], an actual case study regarding a real PROFINET IO network for factory automation has been discussed. The outcomes from their experiments showed that Profinet is able to maintain strict timeliness even when the device is heavily loaded. Incorporation of FPGAs in the domain of industrial automation can be observed in[16]. Here, the embedded processor (Nios) inside the FPGA has been used to assimilate a Profinet software IP core. However, this work still belongs to software based implementation category as it did not involve FPGA fabrics for implementation. First attempt to devise a hardware based Profinet implementation can be found in [17]. This FPGA-based implementation reveals the fact that the proposed architecture is configurable and thus, suitable for high-end industrial requirements. Recently, in [18], the authors have shown the FPGA-based implementation of Media Access Control (MAC) and Physical layer system (PHY) for industrial automation systems. The presented architecture showed the efficacy of the proposed system. From the above discussion, it can be established that FPGAs are evolving as a promising platform for industrial automation devices. However, an FPGA-based solution which provides a user friendly access to generate specific network conditions is still in its infancy. Thus, in this paper, we have explored the FPGA-based NetJury device to devise a Load generator for Profinet communication. The next section will elaborate our proposed Profi-Load framework.

Iii Profi-Load Framework

In this section, we will describe how our proposed Profi-Load framework will function. In a nut-shell, the proposed framework generates packets (frames) 111In this paper, we have used the terms packets and frames interchangeably and place inter-frame gaps in such a way that the desired Load can be generated for a specific duration. Before describing the core theme of our strategy, we will now discuss the default parameters for generating the packet.

Iii-a Parameters of a Packet

A network packet contains header field which includes source and destination MAC addresses and we denoted this field as . Packet also contains Ethertype (denoted as ) i.e., for Profinet packet, Ethertype would be “0x8892”, optional vLAN tag (denoted as ; vlan id, vlan priority and vlan cfi), payload size (denoted as ) in bytes. MAC addresses , Ethertype and Payload are collectively represented as in equation (1). For ease of visualization, a basic packet structure is shown in Figure 3. Apart from these main parameters, a packet also contains some other parameters including preamble: , delimiter: , frame check sequence: and interframe gap: combined with the packet header fields to represent a single frame. We denote all such other fields as overhead (denoted as ) in equation (2). If the packet is vLAN tagged then it will be included in the overhead .

Fig. 3: Structure of a packet.

The overall size of a packet, will include both and in bytes as shown in equation 3. In this paper, varying payload , we have kept of size 60, 128, 256, 512, 1024, 1514 bytes.


Iii-B Load Generation Strategies

In this section, we will discuss the strategies adopted by the “Profi-Load” framework. As per the requirements of modern industrial automation devices, the Load generator should be able to generate Load with some specific constraints i.e., either by selecting the number of frames or the time duration.

CASE 1: Sending Specific Number of Frames for a Specified Load
Let us assume the case where Profi-Load has to send number of frames with % of Load. Here, as the number of frames is fixed so in order to maintain the fixed () Load, profi-Load will send frames with interframe gap (). Hence, a certain gap between two consecutive frames should be maintained. This can be calculated as:


In the equation 5, denotes the minimum interframe gap of 12 bytes between two frames. However, to maintain the desired percentage of Load, is the additional interframe gap in bytes to be added while sending specific numbers of consecutive frames (say, 3) as shown in Figure 4.

Fig. 4: Interframe gap between three consecutive frames to maintain desired Load in the network.

CASE 2: Generating Load for Specified Duration
Let us assume the case where the Profi-Load has to generate % of Load for the specified duration of time units 222time units could be hours, minutes or even micro seconds as per the requirements. Thus, Profi-Load will generate number of frames which will be passed through the Profinet network so that the specified Load can be achieved. The required number of frames can be calculated as:


In the equation 6, denotes the available network bandwidth which can be of speed 100 Mbps or of 1 Gbps. However, as per our experimental observation it has been observed that the elapsed time (T’) i.e., the actual time consumed for sending numbers of (obtained from equation 6) frame can be equal or slightly lower (of the order of microsec) than T. We will analyze this phenomena in detail (Refer, section V, Evaluation of CASE 2).

CASE 3: Generating Bursts of Specified Load
The third scenario will appear when it is required to send group of packets collectively at some desired Load for some specific interval. After sending the required number of packets, there will be some time-gap after which, a next set of packets will be transferred. The time duration in which the packets are being transferred is called as “Burst interval” and the time-gap in between two bursts of packets will be called as a “Sleep Interval”.

Iv Profi-Load on FPGA (NetJury Device)

Iv-a Brief Description of Netjury

As the execution platform of our proposed Profi-Load framework, we have selected the NetJury device [7]. NetJury is based on Xilinx Zynq FPGA [19] integrated with a Dual-core ARM Cortex-A9 processors [20]. The FPGA fabric part is termed as PL (Programmable Logic) and ARM component is termed as Processing Systems (PS). PL is mainly responsible for hardware processing of real-time data and the PS is used to operate the PL logic unit in a Linux based environment. NetJury supports a proprietary scripting language, named as NetJury Scripting Language (NSL) to program the PL component. The overall architecture of the device is shown in Figure 5.

Fig. 5: Architectural view of the NetJury [7].

In Figure 5, the right block is the programming part (PL) and the left block (PS) provides the Linux environment on the ARM processor. The PL subsystem consists of four Ethernet ports operated at 1Gbps / 100Mbps. Within the scripting mode, packet generation with manipulation up-to the application layer can be carried out with all the Ethernet ports via NSL scipt, operated from the PS block. The Port L (eth1) is used to communicate between PS and PL. Monitor module helps the user to inspect and manipulate the traffic received on any of the FPGA ports. The user from the PS side can trigger the desired functionality in PL with NSL scripts generated and executed by high level programming language i.e. python. However, the user needs to turn on the scripting mode once at start for using the PL side of the NetJury.

Iv-B Profi-Load inside NetJury: Human Machine Interface

NetJury by default is designed to send traffic while expecting a particular number of frames to be received on any of the desired port. Hence, to employ the Profi-Load framework on NetJury the user need to specify all the required information. In order to generate the Load with certain specifications (as discussed in previous section via different cases) the user has to provide the following information (based on the requirements):

  • Load

  • Source MAC address

  • Destination MAC address

  • Ethertype

  • vLAN fields

  • Payload size

  • Load generating port of NetJury and its line rate

  • Functionality

    • Burst feature

    • Time feature

    • Frame feature

Upon receiving the user input, NetJury will attempt to generate load by calculating number of frames and the inter-frame gap. To access our Profi-Load framework efficiently, we have developed a web-based Human Machine Interface (HMI). This GUI interface will provide NetJury the required information for successful Load generation shown in Figure 7. Once the user successfully logged in (see Figure 6), the GUI will allow the user to provide the input arguments. However, the user can only make use of one feature at a time, i.e. it can either be Burst check, Time check or Frame check. Once the Load generated successfully, via HMI, NetJury will inform the user about the actual amount of feasible frames or time spent to generate required % of Load.

Fig. 6: HMI based Load generation using NetJury.

Fig. 7: Load generation Interface for user input.

Fig. 8: Profi-Load Setup.

V Experimental Validation

In this section, we will detail the measurements that were carried out to test the efficacy of our Profi-Load framework through real-time traffic generation. Inside the NetJury, the synthetic packets are created by using pythonic modules such as Scapy and translated into NSL syntax for Load generation. These packages are executed in Linux environment running on the PS side. As measurements tools, we have used Wireshark [21], Hilscher netANALYZER [22] and a tektronix DPO4054B Oscilloscope [23]. Moreover, accurate time measurements with Ethernet decoding are performed via MATLAB.

Figure 8 illustrates the running setup of Profi-Load employing NetJury. The management port of the NetJury is connected with the Intra-net from where any connected device such as Laptop and other mobile devices (say, user 1 and 2) with user credentials can access the HMI interface for load generation. Wireshark measurements are carried out by connecting the packet generating port (Port A, shown in Figure 8) of the NetJury to the Ethernet port of a PC running Wireshark application. Depending upon the OS level interrupt(s), the captured timestamps through Wireshark can vary from real-time measurements performed with Hilscher netANALYZER and tektronix DPO4054B oscilloscope.

Now we will describe our experimental observations on the performances of Profi-Load over different cases.

V-1 Evaluation of CASE 1: (40 long frames at 25% Load)

The frames are being sent with payload size, bytes. Along with payload, these packets have an extra 7 bytes preamble, 1 byte start delimiter, 4 byte frame check sum and for Fast Ethernet a default 12 bytes interframe gap and thus, according to equation 2, the overhead () is 24 bytes. Hence, the total size of the packet becomes bytes (refer, equation 3).

To send 40 packets with 25% of load, according to equation 4, becomes 4614 bytes and is 12 bytes. Hence, interframe gap () that we should maintain becomes 4626 bytes (refer, equation 5).

All these inputs for specific load generation will be given via HMI interface. After receiving all the input parameters, NetJury will calculate the number of frames, interframe gap and other parameters and will start operating. Figure 10 shows the Oscilloscope measurement of 40 long packets, it has been observed that the entire transmission of the 40 packets took 19.57 ms. We have also employed Wireshark to measure the transmission time and observed 19.17 ms for the transmission (please see Figure 12).

Matlab Based Analysis: Using Oscilloscope, we captured the Profi-Load generated packets with setup shown in Figure 9. P0 and P1 depict the probes/ports of Oscilloscope/Hilscher netANALYZER along with a PCB board specifically made for connecting probes and ports. Each captured packet has been further evaluated via MATLAB. For this evaluation, we have introduced two new parameters: which denotes packet lasting time in the Profinet network and which denotes the specific time-gap after which each frame will be sent periodically to maintain the specified load .

can be found out for Mbps link, as:


After finding the , we can find the as:


Theoretically, with the above two equations (equation 7 & equation 8), we can expect the values of and for load.

Fig. 9: Setup for capturing packets using tektronix DPO4054B Oscilloscope.

Experimentally, we have achieved the same results. In Figure 11, it can be observed that NetJury sent 40 packets with 25% load. A single packet lasts as expected for 123.04 and the NetJury sent each packet (upto 40 packets) after a specific time gap () of 492.161 .

From the above discussion, we can derive the fact, NetJury can effectively generate load with proper timing efficiency.

Fig. 10: Oscilloscope measurement of 40 long packets at 25% Load.

Fig. 11: MATLAB analysis of 40 long packets at 25% Load.

Fig. 12: Wireshark measurement of 25% load with 40 long packets.

Fig. 13: MATLAB analysis of 750 short packets at 25% Load.

Fig. 14: MATLAB analysis of 25% Load with 744 short packets in 20 ms.

Fig. 15: Wireshark measurement of 25% load with 750 short packets.

V-2 Evaluation of CASE 1: (750 short packets at 25% Load)

It has also been observed that the Profi-Load is capable of performing efficiently in case of generating short frames with a specified load. In this case, the short frame size () is 84 bytes, where is of 60 bytes and contains 24 bytes.

In Figure 15, it can be seen that Wireshark detected that the Profi-Load generates 750 short frames in 18.14 ms. A similar Matlab based analysis revealed the fact that NetJury generates 25% load by sending every frame with the interval of . Each packet lasts for (refer, Figure 13). This measurements is also matched with the theoretically expected values of and .

V-3 Evaluation of CASE 2: (Short packets at 25% Load for 20 ms)

After receiving the specific inputs from the user, the Profi-Load framework will calculate the required number of frames that need to be sent for maintaining the specified load () for specific duration ().

In this particular case, the size () of the frames are 84 bytes (payload and overhead is of size 60 bytes and 24 bytes, respectively). The speed of the network () is 100 Mbps. The required load () is 25% and the specified time duration () is 20ms. Hence, as per equation 6, the numbers of required frame () which have to be sent, can be calculated as 744.

These 744 frames / packets have to be sent with the specific interframe gap () which can be calculated from equation 5. Here, can be found as

As per our previous measurement strategies, Figure 14 showed the Matlab based analysis. It has been observed that the NetJury generated frames with correct / expected specifications. Each frame lasts for and the time gap, after which each frame were sent was . Thus, by following this interval period () 744 packets / frames were sent for .

Critical Observation and Analysis:

We have previously mentioned in section IIIA, CASE 2 that the user specified duration () can slightly vary from the experimentally observed duration (). Here, we can calculate the time elapsed () for sending number of frames as:


From the equation 9, the actual elapsed time () for sending 744 frames becomes . From the Figure 14, it can be observed that this time difference (say, ) as:

This observation can be attributed to the fact that for the specific duration of 20 ms, Profi-Load found it feasible to send only 744 packets to maintain 25% load in spite of having a small . However, in order to compensate , if Profi-Load sends an extra frame then the elapsed time () would exceed the specified duration () as:

Hence, this observation shows how effectively the NetJury device operates for generating specified load with stringent time requirements.

Fig. 16: Wireshark measurement of 25% Load exhibiting the end of Burst and start of Burst with sleep time.

Fig. 17: Wireshark measurement of 25% Load exhibiting the total number of frames generated by 20 bursts.

V-4 Evaluation of CASE 3: (vLAN tagged 50% Load for 20 bursts)

In modern factory automation environment, different I/O devices demand different synchronizing/response times and thus, injecting a constant amount of load (by specifying certain number of frames or by specifying time duration) may force them to enter into the failure mode, thus, devices will stop functioning. Therefore, it will be effective to generate load with “burst feature”. This feature will enable user to specify number of bursts (each burst will contain a specific number of packets) to maintain the desired load. The burst will be transmitted for a specific duration (referred here as “Burst Interval”) and after the transmission, there will be a gap. This gap (time duration) between two consecutive bursts is referred here as “Sleep Interval”.

Consider a scenario where the user would like to send 50% vLAN tagged Profinet Load with 20 bursts. Both the “Burst Interval” and “Sleep Interval” are kept as . The payload of the packet is specified as 1020 bytes. Having an extra 4-byte vLAN tag, the overhead becomes 28 bytes. Hence, the total packet size () is of 1048 bytes.

After obtaining all these user specified parameters, Profi-Load will calculate the required number of frames to be sent using equation 6. It has been found that for maintaining 50% load there should be numbers of frame within a burst. Thus, overall 20 bursts will generate around frames.

If we look into the Figure 16, we can identify that the burst ends at frame. After the specified sleep interval of , burst start sending frames. It can also be observed that the Profi-Load can transmit VLAN tagged packets as well with specified priority (7, in this case). Figure 17 establishes the fact that the Profi-Load successfully generates the required number of bursts with specified duration. It is evident that total frames were sent within 39 seconds i.e 20 seconds for transmission and 19 seconds for the sleep interval.

Currently, the burst feature keeps the burst interval or sleep interval same for all the user defined number of bursts. However, this feature can be extended for variable burst interval or sleep interval, i.e., sleep interval between and burst and sleep interval between and burst with burst intervals of , and for , and burst. Moreover, our proposed Profi-Load can also be employed to generate Load other than Profinet-based packets by changing the Ethertype along with suitable payload size (please see Figure 7).

Vi Conclusion

The vast deployment of Profinet in modern industrial automation devices such as, Controllers and the associated IO Devices can lead to unknown and untested critical failures when network traffic flows unexpectedly higher than normal. Thus in this paper, we have proposed an FPGA-based Profinet Load generation framework, Profi-Load. This framework can generate desired load configurations such as, bits per second, the number and size of the packets and the foremost factor delay in between the packets or burst of packets to maintain the desired throughput. Comprehensive set of experiments on a Zynq-7000 FPGA based “NetJury” device, have showed that the proposed framework can effectively generate Load under various user defined scenario. Moreover, the framework can easily be accessed via web based interface for successful Load generation.


We gratefully acknowledge the support of Frederic Depuydt (Project Engineer / Researcher at KU Leuven, Technologiecampus Gent), the INCASE project partner for sharing knowledge in carrying out measurements with Hilscher netANALYZER and tektronix DPO4054B Oscilloscope used for this research.


  • [1] R. Zurawski, Industrial communication technology handbook. CRC Press, 2014.
  • [2] J. Feld, “Profinet-scalable factory communication for all applications,” in IEEE International Workshop on Factory Communication Systems, 2004. Proceedings., pp. 33–38, IEEE, 2004.
  • [3] J. Jasperneite and J. Feld, “Profinet: an integration platform for heterogeneous industrial communication systems.,” in ETFA, 2005.
  • [4] H. Kleines, S. Detert, M. Drochner, and F. Suxdorf, “Performance aspects of profinet io,” IEEE Transactions on nuclear science, vol. 55, no. 1, pp. 290–294, 2008.
  • [5] “netload.”
  • [6] E. Monmasson, “Fpgas: Fundamentals, advanced features, and applications in industrial electronics [book news],” IEEE Industrial Electronics Magazine, vol. 11, no. 2, pp. 73–74, 2017.
  • [7] “Netjury website.”
  • [8] “Profinet network.”
  • [9] “Pkt-gen.”
  • [10] “scapy.”
  • [11] “ostanito.”
  • [12] “ixia.”
  • [13] M. Antolovic, K. Acton, N. Kalappa, S. Mantri, J. Parrott, J. Luntz, J. Moyne, and D. Tilbury, “Plc communication using profinet: experimental results and analysis,” in 2006 IEEE Conference on Emerging Technologies and Factory Automation, pp. 1–4, IEEE, 2006.
  • [14] A. L. Dias, G. S. Sestito, and D. Brandao, “Performance analysis of profibus dp and profinet in a motion control application,” Journal of Control, Automation and Electrical Systems, vol. 28, no. 1, pp. 86–93, 2017.
  • [15] P. Ferrari, A. Flammini, F. Venturini, and A. Augelli, “Large profinet io rt networks for factory automation: A case study,” in ETFA2011, pp. 1–4, IEEE, 2011.
  • [16] L. Dürkop, H. Trsek, J. Jasperneite, and L. Wisniewski, “Towards autoconfiguration of industrial automation systems: A case study using profinet io,” in Proceedings of 2012 IEEE 17th International Conference on Emerging Technologies & Factory Automation (ETFA 2012), pp. 1–8, IEEE, 2012.
  • [17] H. Flatt, S. Schriegel, T. Neugarth, and J. Jasperneite, “An fpga based hsr architecture for seamless profinet redundancy,” in 2012 9th IEEE International Workshop on Factory Communication Systems, pp. 137–140, IEEE, 2012.
  • [18] T. T. T. Nguyen, Y. Nagao, T. Uwai, N. Sutisna, M. Kurosaki, H. Ochi, and B. Sai, “Fpga implementation of wireless lan system for factory automation,” in 2018 International Conference on Advanced Technologies for Communications (ATC), pp. 78–83, IEEE, 2018.
  • [19] V. Rajagopalan, V. Boppana, S. Dutta, B. Taylor, and R. Wittig, “Xilinx zynq-7000 epp: An extensible processing platform family,” in 2011 IEEE Hot Chips 23 Symposium (HCS), pp. 1–24, IEEE, 2011.
  • [20] W. Wang and T. Dey, “A survey on arm cortex a processors,” Retrieved March, 2011.
  • [21] A. Orebaugh, G. Ramirez, and J. Beale, Wireshark & Ethereal network protocol analyzer toolkit. Elsevier, 2006.
  • [22] “Hilscher netanalyzer.”
  • [23] “tektronix dpo4054b.”