POWERLINK and Real-Time Linux: A Perfect Match for
Contents
1. some of them are able to fullfill hard real time requirements needed for industrial applications One of these hard real time Industrial Ethernet protocols is POWERLINK 11 The availability of the openPOWERLINK network stack for the Linux operating system makes it very easy to implement a software based industrial control application on top of an standard PC running Linux However to provide sufficient accuracy for the network tim ing the operating system must provide some kind of real time capabilities Therefore the Realtime Preemption Patch RT Preempt provided by Ingo Molnar 7 is an ideal base to implement a determin istic POWERLINK master Managing Node using Linux Whereas most performance values for other eth ernet based fieldbusses are very theoretical this pa per shows the real cycle times which could be reached using openPOWERLINK on a real time Linux plat form The system load created by the protocol stack is analyzed and the accuracy of the POWERLINK network synchronisation is evaluated 2 POWERLINK 2 1 Communication Principle POWERLINK is a strict deterministic real time protocol based on Fast Ethernet 100 MBit 1 Time isochronous transfer of data is supported along with asynchronous communication between network nodes a part of network bandwidth is reserved for this Figure 1 shows a POWERLINK communica tion cycle mn soc JC i Esu POWERLINK V2 t FIGURE 1 POWERLINK cycle A POWE2. 6 31 12 rt21 e To H 2 Stress Tests Min Cycle Max Cycle Deviation g 5 L 3 Idle 460 3 us 548 8 us 48 8 us z es g CPU 474 6 us 525 9 us 25 9 us 2 3 Hard Disk I O 451 2 us 552 6 us 52 6 us D T m eS e a a e USB I O 443 5 us 556 5 us 56 5 us 8 E E Logon 5 Network 438 1 us 560 4 us 61 9 ps n A e Scheduling 447 4 us 553 2 us 53 2 us SA Lo Df Miscellaneous 445 7 us 552 4 us 54 3 us TABLE 4 SoC Jitter Intel Core2Duo ae By pa pa Re EA a Stress Tests FIGURE 7 SoC Jitter Intel Celeron o T A l T T g gt Le Conclusion gd T Le The measured SoC jitter is in the expected range On g ee 3 the high end system a maximum deviation of 61 9 pus 3d to oe could be reached On the embedded system a max S T 3 imum deviation of 109 2 us could be reached How g4 oo pae ever it was not clear why the jitter was so high on E or E an idle system and gets smaller if the CPU is heavily R 7 i 1 ft loaded to Le T T T T T T T IDLE CPU HDD USB NET SCHED MISC 5 Conclusion and Future Work Stress Tests The performance evaluation showed that the Linux FIGURE 6 SoC Jitter Intel Core2Duo operating system together with RT Preempt is an ideal platfrom for implementing a high quality POWERLINK MN The high resolution timers en sure a very high cycle time accuracy which is suffi ciant for many industrial applications However it is not clear why we get the best results for the SoC jitter measurement when the CPU
3. is heavily loaded Embedded System Intel Celeron The following test parameters were applied Reference Cycle Time 500 us Measured Cycles 10 10 This needs further investigation Clock Source hpet Linux Kernel 2 6 31 12 rt21 The cycle time could be lowered down to 250 us which allows the implementation of industrial sys Stress Tests Min Cycle Max Cycle Deviation tems which require very low cycle times such as mo Iide 396 1 us 5974 ps 103 9 us tion control systems The generated system load is CPU 473 2 ps 532 ps 32 ps low enough to implement small systems using an em Hard Disk I O 400 3 us 603 2 us 103 2 us bedded platform or medium systems by using high USB I O 397 2 us 609 2 us 109 2 us end industrial PCs Due to the measured values Network 456 8 us 543 us 43 2 us there is evidence that even larger networks could be Scheduling 463 7 ps 533 1 pus 36 3 ps realized without problems We will continue testing Miscellaneous 402 5 ps 600 5 ps 100 5 ps with larger networks and other architectures in the future to provide comprehensive performance values TABLE 5 SoC Jitter Intel Celeron With the openPOWERLINK stack an Open Source solution is available for Linux which allows everyone to implement a cost effective industrial con trol solution on top of a standard x86 PC The cur rent implementation of the open POWERLINK stack implements its own proprietary network interface driver Whereas this assures the maximum perfor manc
4. the quality of the POW ERLINK timing on the network 4 1 Test Environment The following test setup was used for the evaluation e MN APC810 industrial PC e CNs B amp R X20 BC0083 X20 DI4371 X20 D04322 e B amp R POWERLINK Analyzer X20 HB8815 Figure 5 shows the testsytem with three bus con trollers connected to the MN Linux POWERLINK MN APC 810 POWERLINK CN POWERLINK CN POWERLINK CN B amp R BC0083 B amp R BC0083 B amp R BC0083 Digital IN Digital IN Digital IN Digital OUT Digita OUT B amp R POWERLINK nalyze x Digital OUT POWERLINK Network FIGURE 5 POWERLINK Test System 4 1 1 POWERLINK MN The POWERLINK MN test systems were imple mented on B amp R APC810 industrial PCs 3 We used two differently equipped PCs to compare the results of a high end industrial PC with a solution in the range of current embedded platforms High End Industrial PC The first APC810 was equipped with a Intel Core2Duo U7500 dual core processor running at 1 06 GHz 1 GByte DDR2 PC2 5300 DRAM and a 40GB harddisk drive The Intel 945GME chipset contains the Graphics Media Accelerator GMA 950 The on board network interface based on a Realtek 8111B Gigabit Ethernet adapter was used for the network stress tests The POWERLINK network was con nected through the second onboard Intel 82573L based Ethernet controller Embedded PC The second APC810 was equipped with a Intel Celeron M 423 proces
5. POWERLINK and Real Time Linux A Perfect Match for Highest Performance in Real Applications Josef Baumgartner Bernecker Rainer Industrie Elektronik Ges m b H B amp R Strasse 1 5142 Eggelsberg Austria josef baumgartner br automation com Stefan Schoenegger Bernecker Rainer Industrie Elektronik Ges m b H B amp R Strasse 1 5142 Eggelsberg Austria Stefan Schoenegger br automation com Abstract In the automation industry many discussions around the various Industrial Ethernet concepts like POWERLINK Profinet and EtherCAT are based on theoretical performance studies This paper will outline the in reality achievable performance of the open source POWERLINK technology operating on a standard x86 PC with real time Linux and its potential application scenarios The evaluation will include a study on the synchronization quality as well as on the resulting CPU load for large scale applications generated by the network protocol 1 Introduction Ethernet has been the standard networking technol ogy in the home and office environment for years In the automation industry the conventional field busses are still the dominant communication tech nology This is because standard Ethernet could not provide the deterministic behaviour required by many industrial applications In the meantime there are several ethernet based fieldbusses available on the market Whereas some provide only soft realtime ca pabilities like PROFINET or EtherNet IP
6. Preemption Patch The standard Linux kernel only meets soft real time requirements but there are several real time exten sions available for Linux right now One of them is the Realtime Preemtpion Patch RT Preempt devel oped by Ingo Molnar Unlike other Linux real time extensions RT Preempt doesn t use a micro kernel but brings hard real time capabilities directly into the Linux kernel The big advantage of this solu tion is that the user can use his standard linux tools for development using the POSIX API for his ap plications and doesn t need to lern special real time APIs 3 2 High Resolution Timers Precondition for an accurate SoC timing in a POW ERLINK MN is a very accurate system timer The high resolution timers introduced by Thomas Gleixner are part of the Linux kernel since 2 6 16 The new timer system does no longer depend on the periodic tick of the operating system and allows nanoseconds resolution However the resolution de pends on the available timer hardware of the sys tem On an Intel X86 architecture there are differ ent clocksources available hpet tsc acpi pm which provide a usable timer resolution in the microsecond range 3 3 Interrupt Load Because the network load for POWERLINK is very high and many small packages will be transferred across the network the interrupt load is very high Therefore effective interupt handling is required in the operating system Furthermore the performance could
7. RLINK device can be a managing node MN or a controlled node CN A POWERLINK network has exactly one MN This regulates activity on the network All other devices in the network are CNs The SoC is sent as a multicast and can be received and processed by all other POWERLINK stations in the network No application data is trans ported in the SoC it is only used for synchronization Immediately after transmitting the SoC the MN addresses each CN in the network with a PReq poll request Each CN responds with a PRes poll re sponse The output data designated for a CN is transmitted in the PReq All stations are addressed in order by the MN with a PReq Immediately upon receiving the PReq the addressed station responds with a PRes This frame is sent as multicast and can therefore be received by the MN as well as by all other CNs in the network Therefore the PRes can not only send input data from the CN to the MN but also allows cross communication among the CNs Di rect cross communication allows the times for data exchange between stations to be reduced consider ably since the data need not be copied in the MN A CN only transmits when it receives a directly addressed request PReq from the MN The MN waits for the response from the CN This prevents collisions on the network and enables deterministic timing A fixed time is reserved in the network cycle for asynchronous data Asynchronous data differs from cyclic data in tha
8. Sum of all CNs Output size in Bytes 3 10 20 40 TABLE 1 Payload Size of test system 4 1 3 POWERLINK Analyzer Due to the limited accuracy network timing mea surment with WireShark was not sufficient There fore a B amp R POWERLINK analyzer was connected in order to get high quality network timing measure ments The implementation of a special MAC con troller openMAC in a FPGA makes it possible for the POWERLINK analyzer to measure timestamps of network frames with a resolution of 20ns 4 2 Cycle Time and System Load To evaluate which cycle times could be achieved and how much system load the POWERLINK stack gen erates with differently sized networks we connected a changing amount of CNs to the POWERLINK MN and measured the system load Table 2 and 3 show the results of the system load measurement Number of CNs 3 10 20 40 250 us 37 N A N A N A 500 us 18 28 43 N A 1 ms 8 14 21 39 2 ms 3 5 9 18 5 ms lt 1 1 4 6 10ms lt 1 lt 1 lt 1 2 TABLE 2 System Load Measurement High End PC Number of CNs 3 10 20 40 250 us 50 N A N A N A 500 us 25 29 50 N A 1 ms 11 14 23 41 2 ms 5 7 11 19 5 ms lt 1 2 3 7 10ms lt 1 1 1 3 TABLE 3 System Load Measurement Em bedded PC Cycle times of 250 us could be reached on both systems The measured system load is the load of all POWERLINK threads on a single core This means that the overall system load on the dual core system is much less
9. and leaves enough processing power for applications 4 3 SoC Timing Evaluation 4 3 1 Methodology We measured the SoC timing accuracy while the sys tem was stressed with different stress tests Figure 5 shows the test system which was used for the mea surements The following stress tests were applied 1 Idle The first measurement was done on an idle sys tem as a reference for the different stress tests 2 CPU load For the CPU stress test the tool cpuburn was used 9 It is designed to load X86 CPUs as heavily as possible for the purposes of system testing 3 Hard Disk I O Load The tool dd was used to read and write large amounts of data from and to the hard disk drive 4 USB I O Load As for the hard disk dd was used on an USB drive to produce USB I O load 5 Network Load Heavy network stress was caused by an exter nal flood ping on the first Ethernet interface 6 Scheduling load Heavy process scheduling load was caused by hackbench 10 It spawns over a hundred pro cesses which are communicating by sending sig nals to each other 7 Miscellaneous Load To cause miscellaneous system load a linux ker nel compilation was started 4 3 2 Results The following section shows the results of the SoC jitter measurements High End System Intel Core2Duo The following test parameters were applied Reference Cycle Time 500 us Measured Cycles 10 10 Clock Source hpet E Linux Kernel 2
10. be enhanced if the hardware provides interrupt throttling and the network driver is designed to sup ports this function 3 4 openPOWERLINK Stack The openPOWERLINK stack is a POWERLINK stack developed by SYS TEC electronic SYS TEC published the POWERLINK stack under the Open Source BSD license 11 openPOWERLINK con tains all functionalities and services required for im plementing a POWERLINK MN and CN It runs on Linux and other operating systems and plat forms Although there are Linux solutions available for other Ethernet based fieldbusses these are mostly Linux drivers for proprietary hardware With the openPOWERLINK stack a pure software based so lution is available which runs on a standard PC and no proprietary hardware is needed Figure 4 shows the software architecture of the openPOWERLINK stack The Linux implementa tion of the openPOWERLINK stack runs completely in kernel space The interface to the user space ap plication is provided by the EPL API Layer Ethernet Controller FIGURE 4 openPOWERLINK software architecture To provide maximum performance the open POWERLINK stack does not use the Linux net work drivers but provides its own optimized network drivers 4 Performance Evaluation In our evaluation we analyzed the lowest POWER LINK cycle times which could be achieved on a Linux POWERLINK MN with the current openPOWER LINK stack and how much system load it generates Additionally we measured
11. conventional PReq PRes nodes in combination with PResChain ing nodes Figure 2 shows a POWERLINK cycle with both PRes Chaining and conventional nodes PollResponse Chaining is specified in 2 mn soc resm cN PRes POWERLINK V2 _ FIGURE 2 POWERLINK cycle with Poll Response Chaining 2 3 Synchronization Parameters Because of the POWERLINK communication princi ple there is one critical timing parameters in a POW ERLINK communication cycle the SoC Jitter The MN generates the SoC frame to start a new POWERLINK cycle For a software solution the ac curacy of the SoC generation is mainly determined by the operating system and its network stack A high resolution timer is required to provide an accu rate cycle timing Additionally the delay generated in the network driver from receiving the packet un til it is sent out to the network determines the cycle quality teycte tcyae POWERLINK SoC timing MN SoC SoC FIGURE 3 3 Linux The requirements of industrial automation systems generate very high demands on the operating sys tem For this purpose POWERLINK was mainly implemented on real time operating systems such as VxWorks in the past As the real time capabilities of the Linux operating system were enormously en hanced in the last years it grew up to a comparable alternative platform for implementing a POWER LINK MN as a baseline for a competitive automation target 3 1 Realtime
12. e it limits the stack to use one of the few net work cards supported at the moment To avoid im plementing drivers for the huge amount of network cards available on the market the design of the stack should be changed to use standard Linux network drivers This may require some optimizations in the network subsystem like preallocated SKBs or a opti mized traffic shaper to get the needed performance for a deterministic real time Ethernet protocol Ad ditionally this whould assure compatibility with fu ture kernel versions B amp R will continously drive the further develop ment of the openPOWERLINK stack on Linux and its long term goal will be to bring POWERLINK functionality into the official kernel sources enabling everyone using a standard Linux machine to use it for industrial control applications References 1 EPSG Draft Standard 301 Ethernet POW ERLINK Communication Profile Specification 2008 Ethernet POWERLINK Standardisation Group V 1 1 0 2 EPSG Working Draft Proposal 302 C Ethernet POWERLINK Part C PollResponse Chaining 2009 Ethernet POWERLINK Standardisation Group V 0 0 3 3 APC 810 User s Manual Version 1 20 October 2009 Bernecker Rainer Industrie Elektronik Ges m b H Austria 4 X20 System User s Manual Version 2 10 9 6 BCO0083 Bernecker Rainer Industrie Elektronik Ges m b H Austria 5 X20 System User s Manual Version 2 10 9 6 DI4371 Bernecker Rainer Industrie Elektro
13. nik Ges m b H Austria 6 X20 System User s Manual Version 2 10 9 6 DO4322 Bernecker Rainer Industrie Elektronik Ges m b H Austria 7 The RT Wiki CONFIG PREEMPT RT Patch https rt wiki kernel org index php CONFIG_PREEMPT_RT_Patch 8 The RT Wiki High resolution timer de sign notes https rt wiki kernel org index php High_resolution_timer_design_notes 9 The cpuburn homepage http pages sbcglobal net redelm Robert Redelmeier 10 Hackbench homepage http devresources linux foundation org craiger hackbench 11 openPOWERLINK Protocol Stack Source http openpowerlink sourceforge net
14. sor The processor clock was re duced to 533MHz to simulate the processing power of an embedded system The remaining hardware con figuration was the same as with the first APC810 Software The installed operating system was a 32 bit version of Ubuntu 10 04LTS Desktop running a 2 6 31 12 rt21 kernel The current openPOWERLINK net work stack version 1 7 was installed 4 1 2 POWERLINK CNs For the POWERLINK CNs B amp R X20 BC0083 bus controllers 4 were used A digital input modul X20DI4371 5 and a digital output modul X20D04322 6 was connected to each bus controller The DI4371 module is equipped with four digital in puts the D04322 module is equipped with four dig ital outputs In contrast to other systems a B amp R POWERLINK CN is not restricted to a few I O ports If additional I O was needed one would typi cally add additional I O modules to one node Up to 253 I O modules could be connected to a single bus controller As we would like to evaluate the perfor mance on differently sized networks we used a chang ing amount of bus controllers and connected only one digital input and one digital output module The PResMN frame from the MN contains the data for the digital outputs The PRes frames from the CNs contain the data of the digital inputs and some ad ditional status information Table 1 shows the size of the payloed for the differently sized networks Number of CNs 3 10 20 40 Input size in Bytes 18 60 120 240
15. t it need not be configured in ad vance Asynchronous data is generated on demand by a POWERLINK station Examples are visualiza tion data diagnostic data etc One asynchronous frame can be sent per POWERLINK cycle The CNs can signal the MN in the poll response frame that they would like to send asynchronous data The MN determines which station is allowed to send and shares this information in the SoA Start of Asyn chronous frame Any Ethernet frame can be sent as an asynchronous frame ARP IP etc However a maximum length MTU Maximum Transfer Unit must not be exceeded 2 2 PollResponse Chaining The POWERLINK protocol supports an additional mode called PollResponse Chaining Instead of re questing the CNs sequentially through PReq frames the CNs are requested alltogether by the PResMN frame which is sent as multicast The data usually sent by the MN in the PReq frames is mapped into the PResMN frame of the MN This increases per formance if many nodes with small amount of pro cess data are connected because instead of sending many small packets only one packet containing the data for all CNs needs to be sent In the conven tional POWERLINK cycle a CN is only allowed to send a PRes frame after receiving its PReq frame With PRes Chaining this rule is obsolete Now the PRes frame is sent time triggered Each CN is config ured by the MN to send its PRes frame at a specific point in time It is still possible to use
Download Pdf Manuals
Related Search