Large PROFINET IO RT networks for factory automation: a case study P. Ferrari, A. Flammini, F. Venturini DII - University of Brescia Via Branze 38 25123 - Brescia - Italy
[email protected] Abstract The paper presents a case study regarding a real PROFINET IO network for factory automation. The aim of the study is the evaluation of the time related parameter of a real network. A large factory automation plant has been chosen as testbed since PROFINET IO RT Class 1 and 2 (unsynchronized) are mainly used in those applications. The analyzed network has a high number of distributed IO, actuators and sensors; its topology is complex (star and ring); and it is fully operative (in-production). The considered implementation stresses the PROFINET IO communication as no laboratory setup can do, giving meaningful information about real operative conditions on short-term. The results of this case study can be used both to improve simulation models of devices and to verify critical situations in real plants.
1. Introduction The applications of Real-Time Ethernet (RTE) in the factory automation fields are growing very quickly in the last years. Among the dozen of RTE protocols available in the market [1], the PROFINET IO is gaining popularity, thank to the large installed base of PROFIBUS, its parent technology [2]. The PROFINET IO approach is focused on the use of the same protocol for all the possible applications, from supervisory to motion control. Such an idea is applied in real plants using unsynchronized (called Real-time - RT) and synchronized (called Isochronous Real time - IRT) communications. The highest performance are possible with IRT; its behavior is well known since several research works investigated it [3][4]. On the other hand PROFINET IO RT is based on the best effort paradigm; hence its performance depends on network implementation. Generally speaking, the manufacturer provides engineering tools that conservatively estimate the behavior of the network, and try to suggest a design methodology to the user. The use of simulations for the verification of the design choice is not diffused at the end-user level. This
A. Augelli Siemens S.p.A I IA Sensor and Communication Dep. Via Piero e Alberto Pirelli 10 10126 Milano (Italy) is due to limited simulation models and lack of trusted simulation parameters from real devices/networks [5],[6],[7]. The aim of this paper is to gather information about the behavior of a real large PROFINET IO RT network by means of measurements directly taken during network operation. The timing parameters estimated from the case study may be used to feed simulation models, obtaining more effective simulation results. Suitable logging equipment has been used to minimize timestamp error during measurement campaigns. In Section 2, a brief overview of PROFINET IO RT is given. In Section 3, the network considered as case study is introduced and discussed. In Section 4, the experimental results are presented.
2. PROFINET IO RT (unsynchronized) The PROFINET IO protocol is one of the RTE communication profile family of the IEC61784-2. PROFINET IO covers three communication profiles CP 3/4, CP 3/5 and CP 3/6. PROFINET IO RT protocol refers to CP 3/4 and CP 3/5. More details can be found, for instance, in [8]. The PROFINET IO participants to a network are: IOControllers (i.e. the device that manage/coordinate the network, usually the PLC), IO-Devices (i.e. field devices like sensors, actuators, IO modules etc.) and IOSupervisors for configuration/diagnosis purposes. A real time data exchange is established between IOController and IO-Devices via real-time communication channels. Other data (e.g. configuration, statistics) are transferred using non-critical channel (i.e. UDP/IP). PROFINET IO RT devices cyclically transfer process data on the bus. The cycle time for real time data exchange may be different for each device. Anyhow, a device occupies the available bandwidth only for the time needed for transfer data. PROFINET IO RT specifications require that at least 40% of the bandwidth, in any link, must be left free of any kind of PROFINET traffic. The remaining bandwidth can be used by the non real-time communication, allowing coexistence of UDP or TCP traffic and real-time data on the same physical network.
ring switches (stars) or connected to drops (lines). The maximum drop length is 9 devices. The switches are configured as IO-Devices, so the total number of PROFINET IO-enabled devices in the network are 127. The ring is managed by means of the Media Redundancy Protocol (MRP). The redundancy manager is the switch # 1. The evaluation of the redundancy performance of the considered network is out of the scope of this paper.
PROFINET IO RT is often referred as “unsynchronized communication”; the stations are not synchronized among each other, so PROFINET IO RT stations do not begin bus cycles at the same time. A direct consequence is that no relation exists between the times at which inputs (outputs) are transmitted (received) on the network by each station. Moreover cycle duration relies on device local clocks, which have different frequencies, and hence also the phase between data transfers of different device is not constant. For all this reasons, at application level the data update jitter is equal to one cycle time. On the other hand the network infrastructure is not critical, provided that the sufficient bandwidth is allocated for PROFINET IO RT As a conclusion the PROFINET IO RT is a typical best effort approach, whose performance depends on the network design and its operating conditions.
3.1. Devices belonging to the network In the considered network there are products of different vendors. Some manufacturer provides multiple models, and among devices of the same model the hardware configuration is different. In order to keep the description in the paper as general as possible, the devices will be classified by model, not by manufacturer. A letter will be assigned to each model and the name of the manufacturer will remain undisclosed. The minimum length of the PROFINET IO payload is 40 bytes, due to the limit on the shortest Ethernet frames. Table 1 shows: the IO-Devices models; their associated configuration (nominal Data Exchange period TDE; Packet lengthPayload); and the relative number of instances.
3. Network description The considered network belongs to a sub part of the production line. The automation inside the considered subpart is managed by the IO-controller (Main_PLC) with PROFINET IO RT Class 1 and 2. The manufacturer of the Main_PLC is not relevant for the paper objective, so it will remain undisclosed. The information exchange between the subparts of the production line is achieved by means of gateways (AKA PN-PN couplers) that act as two IO-Devices, each one in a different network. As a consequence, there is a complete separation at the network level between subparts, and hence, the results obtained in this paper are independent on the condition of the rest of the plant. The topology of the considered network is shown in Figure 1. The network has a ring backbone (100Mbit/s) with 11 switches belonging to it. The 115 IO-Devices and the single IO-Controller are attached directly to the
IO-Device
Nominal TDE [ms]
A B C D E F G S (switch)
2 2 2 128 2 2 4 -
PROFINET Payload [Byte In/Out] 40/40 40/40 40/40 40/40 179/83 40/40 40/40 -
Table 1. IO-Devices in the network.
Switch IO-Device 1
2
3
4 IO-Controller
11
10
5
9
8
Instances
7
6
Figure 1. Topology of the considered network.
23 29 10 11 8 7 27 11
4. Experimental results The experimental setup is shown in Figure 2. In order both to minimize the impact of the measurement/logging system on the network, and to obtain accurate results, an Ethernet Tap (ProfiTap, Procentec) has been inserted in series with the link of the IO-controller. The more efficient approach proposed in [9] cannot be applied in the considered case because of safety rules (the plant is running at full production speed). The Tap is transparent to the packets flowing in both directions. It copies all the data, assigning a precise timestamp to them (resolution: 5 ns). The logged stream is sent to the monitor station (PC) that stores it as PCAP file (a widely diffused file format for Ethernet logging). All the timing parameters will be computed using the Tap clock as time reference. Due to the short duration of the network snapshot, the clock of the Tap can be considered stable and affected only by white noise. Hence, the statistical computation of mean and variance is meaningful. The temperature of each IO-Device is different, but the system can be considered stable from the thermal point of view: the network was operating since 3 hours before the measurements took place. IO-Controller
Monitor Station
Tap
11
1
2
Figure 2. Experimental setup. The traffic in the network has been recorded for 30 s. For each IO-Device the following “short term” parameters have been computed: • Average duration of the TDE, measured as the interarrival time between two packets of the same IO-Device. • Standard deviation of the TDE; • Jitter of the TDE, that is the difference between the shortest and the longest TDE in the observation period. Bandwidth usage in the IO-Controller link under test is 26% outbound (IO-Controller → IO-Device) and 30% inbound (IO-Device→ IO-Controller). The IO-Controller and ring switches can be classified as belonging to the “Net Load Class III” as indicated by PROFINET reference document [10]. Some non-PROFINET traffic
is also present in the network: it is accounted for the 0.15% in both directions, and it is composed of TCPUDP conversations for configuration and management. A variable number of packets has been considered for the computation of the timing parameters of the IODevices. For IO-Devices A, B, C, E, F, 14000 packets have been used; for Type G, 7000 packets; and for type D, 230 packets. The results are shown in Table 2 and Table 3, depending on the direction of the data exchange. For some models, more than one instance has been considered. The inbound traffic at the IO-Controller (Table 2) is prone to path delay variation in the network. For this reason, the standard deviation and the jitter have the highest values in the experiments. Excluding IO-Device D, the maximum jitter is lower than 0.6 ms and the maximum deviation from nominal TDE is about 1000 ppm (devices B and G) . The great jitter of IO-Device D is due to the implementation of the PROFINET IO stack in such a device: it seems its PROFINET stack is implemented in software. For sake of completeness, Figures 3 and 4 show the distribution of the TDE for devices B-1 and F-1 for inbound traffic: the B-1 device is farther from the IO-Controller than the F-1, hence its distribution is larger due to path delay variations. The outbound traffic from the IO-Controller (Table 3) shows a very regular behavior, as expected: the traffic cannot modify the delay in this link because it is before any switch. The maximum standard deviation is less than 6 μs. Some jitter values seems to be more frequent that others, suggesting the internal operation of the PROFINET stack is quantized with a time step of about 4.5 μs (greatest common divider of Jitter values). The number of missing packets is low but not equal to zero. The number of such events is low and always under the watchdog condition; hence the system operates correctly without any alarm. The main reasons for loss of packets may be: CRC errors; deadline violation in the firmware of the device; and frames lost by the measuring/sniffing tool. The actual experimental setup cannot reveal the exact cause, although results with light network traffic (not shown here) seem to indicate the frames are lost by the sniffing tool. However, new measurements campaign has been planned and will be carried out in the next future. The new measurements will be taken using multiple Taps and merged with the statistical information provided by the switches.
5. Conclusions The behavior of a real PROFINET IO RT network has been evaluated in this paper. Moreover, the considered factory automation system has been analyzed in the full production state. The preliminary results show the generally good timeliness of the devices involved in the network, which operate in a “heavy loaded” condition. The standard deviation of the data exchange
period from IO-Device to IO-controller is lower than 50 μs. The information about the timing that has been obtained in this case study may be used as input parameter for simulation tool of large networks. The sporadic phenomenon of some missing packet is visible and it will be investigated by means of further measurements, which have been already planned. IODevice A-1 A-2 B-1 C-1 C-2 D-1 E-1 E-2 F-1 F-2 G-1 G-2
Average TDE [μs ] 1999.999 2000.004 2002.342 2000.016 2000.000 128009.4 1999.995 1999.990 1999.915 1999.922 4005.276 4005.288
Std. Dev. TDE [μs] 22.069 53.520 43.049 31.832 29.055 3995.6 30.038 49.361 32.436 14.834 26.963 25.619
Jitter [μs] 214.085 276.965 595.125 231.440 214.165 10591.8 499.770 563.290 271.440 118.640 258.165 266.000
Missing packets 1 3 5 8 7 0 1 5 13 8 10 6
Table 2. Timing parameters: IO-Dev.→ IO-Con. 4000 3500 3000
Samples
2500 2000 1500 1000 500 0 1.85
1.9
1.95
2
2.05
2.1
2.15
2.2
TDE [ms]
Figure 3. Distribution of TDE for IO-Device F-1. 1400
1200
Samples
1000
800
600
400
200
0 1.7
1.8
1.9
2
TDE [ms]
2.1
2.2
2.3
2.4
Figure 4. Distribution of TDE for IO-Device B-1. IODevice A-1 A-2 B-1 C-1 C-2 D-1 E-1 E-2 F-1 F-2 G-1 G-2
Average TDE [μs] 1999.995 1999.995 1999.995 1999.995 1999.995 127999.7 1999.995 1999.996 1999.995 1999.995 3999.991 3999.991
Std. Dev. TDE [μs] 0.318 0.383 0.374 0.777 0.614 0.6 0.361 5.714 0.382 0.344 0.268 0.424
Jitter [μs] 27.840 32.640 32.640 84.320 81.465 13.4 27.840 27.520 32.640 27.840 23.280 27.840
Missing packets 12 1 3 16 3 3 10 11 3 17 14 2
Table 3. Timing parameters: IO-Con → IO-Dev. References [1]
M. Felser, “Real-Time Ethernet - Industry Prospective”, in Proc. of IEEE, Vol. 93, N. 6, pp. 1118-1129, 2005 [2] J. Jasperneite, J. Feld, "PROFINET: An Integration Platform for heterogeneous Industrial Communication Systems", Proc of IEEE ETFA2005, Sept. 2005 [3] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, F. Venturini, "Evaluation of timing characteristics of a prototype system based on PROFINET IO RT_Class 3", Proc. of ETFA 2007, Patras, Greece, Sept. 2007, pp. 1254-1261. [4] Z. Hanzalek, P. Burget, P. Sucha “Profinet IO IRT Message Scheduling”, Proc. of IEEE ECRTS 2009, pp.57-65, July 2009 [5] L. Liu, G. Frey, “Simulation approach for evaluating response times in networked automation systems”, Proc. of IEEE ETFA 2007, Sept. 2007, pp.1061-1068 [6] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, F. Venturini, "New Simulation Models to Evaluate Performance of PROFINET IO Class 1 Systems", Proc. of IEEE INDIN 2007, Vienna, Austria, July 2007, Vol. 1, pp. 237-242. [7] P. Ferrari, A. Flammini, S. Rinaldi, G. Gaderer, “Evaluation of clock synchronization accuracy of coexistent Real-Time Ethernet protocols”, Proc. of IEEE ISPCS 2008, pp. 87-91, Ann Arbor, 2008 [8] B. M. Wilamowski, J. D. Irwin, “The Industrial Electronics Handbook – PROFINET chapter ”, Vol. 2, CRC Press, 2010 [9] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, " A Distributed Instrument for Performance Analysis of Real-Time Ethernet networks ", IEEE Transactions on Industrial Informatics, Vol. 4, N. 1, pp. 16-25 , 2009 [10] PNO, “PROFINET IO Net load”, V1.0, Order. N. 7302, Nov. 2010
