外文翻譯--基于物理實(shí)驗(yàn)Simatic ® PLC運(yùn)行的實(shí)時(shí)顯示測(cè)量 英文版.pdf

IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 51, NO. 3, JUNE 2004 489Measurement of Real-Time Aspects of SimaticPLCOperation in the Context of Physics ExperimentsHarald Kleines, Janos Sarkadi, Frank Suxdorf, and Klaus ZwollAbstractToday, most slow control systems for physics ex-periments at Forschungszentrum Jlich are implemented withProgrammable Logic Controller (PLC) technology and fieldbussystems. In many cases, even deterministic response is requiredfrom the PLCs. This raises the question about the real-timeperformance that can be expected from a PLC. Response-timemeasurements of SimaticPLCsmanufactured by the worldmarket leader Siemensare presented. Influence of programstructure and hardware configuration on performance anddeterministic behavior of a PLC is discussed.I. PROGRAMMABLE LOGIC CONTROLLERS (PLCS) INEXPERIMENT CONTROL SYSTEMSTODAY, industrial automation technology is well estab-lished in infrastructure systems for physics experiments,e.g., in water or gas supply systems. This leads to the heavy useof Programmable Logic Controllers (PLCs), which typicallyare the intelligent automation stations forming the core ofindustrial systems 1. Main reasons includelow prices induced by mass market;robustness;long term availability and support from manufacturer;professionality (connectors, conformance to standards,)Beyond the scope of pure infrastructure systems, PLCs are in-creasingly becoming central components of experiment controlsystems, replacing VME- or PC-based real-time systems 2,3. This is caused by the following features of modern PLCfamilies.High degree of scalability: Modern PLC families have awide spectrum of CPU types, that is scalable not only withregard to performance, but also with regard to function-ality and form factor. For outdoor or fault tolerant appli-cations special versions are available.Extensibility: The modular design of PLCs enablesthe extension with a wide range of digital and analogI/O modules. Additionally, integrated technology mod-ules are available for different application areas, e.g.,stepper motor controllers, servo motor controllers, or PIDcontrollers.Extensive communication capabilities: Modern PLCshave at least one integrated communication port and canbe extended by a variety of communication controllersManuscript received May 16, 2003; revised October 1, 2003.The authors are with Zentrallabor fr Elektronik, Forschungszentrum Jlich,D-52425 Jlich, Germany (e-mail: h.kleinesfz-juelich.de).Digital Object Identifier 10.1109/TNS.2004.828504for different field and process bus systems, thus enablingconnection of other industrial devices. A key issue isthe extension of a central PLC system with decentralperiphery via special fieldbusses (e.g., PROFIBUS DP),that allows the transparent connection of “unintelligent”I/O-modules. Thus a PLC program can access this decen-tral periphery in the same way as central PLC periphery.Powerful development environment: Modern PLC fami-lies come with a homogeneous cross development envi-ronment, that supports all the major IEC 1131 program-ming languages 4. Typically, representations in instruc-tion list (IL), function block diagram (FBD) or ladderdiagram (LD) can be switched dynamically. The develop-ment tools allow semigraphical hardware configuration,offer strong debugging mechanisms and allow incrementaldevelopment by the exchange of blocks during runtime.Today, in FZ Juelich, all new and advanced experiment con-trol systems are heavily PLC-based 3, as illustrated by the ar-chitecture of a neutron spectrometer control system shown inFig. 1.Because the world market leader Siemens dominates theEuropean market, SimaticS7 PLCs are used in FZ Juelich,almost exclusively. The midrange series S7-300is mostpopular. The high-end series S7-400is targeted at applicationswith extreme performance requirements and supports alsomultiprocessor configurations. The mini PLC series S7-200is rarely used, because it got the name S7 by pure marketingreasons and its programming environment is incompatible tothe other S7 devices. Instead of the S7-200, the IM151/CPUserves as a mini PLC. The IM151/CPU is an intelligentcontroller for the decentral periphery family ET200S. Alsothe decentral periphery systems ET200Land ET200Mareused commonly in Jlich. The SoftPLC WinAChas only beentested in the Lab, so far.The responsible planning of PLC-based control systems re-quires knowledge on their real-time features.What is the magnitude of PLC response time, dependingon PLC type?Can deadlines be guaranteed?What programming rules have to be followed?The paper addresses these issues by measurements at dif-ferent PLC types of the SimaticS7 family. The standard IEC1131 defines a common framework for PLC functionality andprogramming languages 4, which all the major PLC manufac-turers conform to. Thus general results can be generalized alsoto their PLC families.0018-9499/04$20.00 2004 IEEE490 IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 51, NO. 3, JUNE 2004Fig. 1. Control system architecture of the neutron spectrometer KWS3.Fig. 2. Block calling hierarchy.II. SIMATICS7 PROGRAMMING MODELClassical real-time applications in research are implementedwith real-time kernels like OS-9 or VxWorks, that follow anasynchronous parallel programming approach, as defined inPOSIX 5, for example. The software developer structureshis program in tasks according to the logical structure of theproblem to solve. These tasks are executed quasiparallel by theoperating system, and the execution is basically event-triggered.By assigning priorities to the tasks the programmer gives hintsto the operating system about the desired execution order. Thusthe programmer does not have to plan the scheduling details.On the other hand it is difficult to understand the executionorder and to decide, if a specific task can meet its deadlines.The programming mechanisms in PLC systems are totallydifferent, because they follow the older approach of syn-chronous programming 6. Here, the execution of tasks iscompletely time-triggered, and the programmer has to organizehis program into tasks according to the time, when a task hasto run. So he must plan the execution order himself, which ismore complicated but also gives more control.In Step7, the development environment of the S7, all codeexists in blocks, as defined in IEC1131. Tasks are representedby Organization Blocks (OBs). OBs are the schedulable items,that are called by the operating system of the PLC at certainevents, e.g., when a timer expires or an error occurs. Thus, theOBs are the interface of the operating system to the user pro-gram. As indicated in Fig. 2, OBs can call Functions (FCs),which are blocks that correspond to functions in a procedurallanguage. FCs can call other FCs or system functions (SFCs),which correspond to operating system calls in a POSIX environ-ment. Function Blocks (FBs)/System Function Blocks (SFCs)are FCs/SFCs with an assigned data block for static functiondata.A “normal” PLC program is contained in OB1, which iscalled cyclically by the operating system, as indicated in Fig. 3.Before OB1 is called the operating system transfers data fromthe input modules to a memory area called process imagetable. After OB1 has been called, data from the process imagetable is copied to the output modules. The indirect access toI/O-modules via the process image table reduces access timeand increases consistency.KLEINES et al.: SIMATICPLC OPERATION 491Fig. 3. Execution of main program scan cycle OB1.The execution time of OB1 is monitored, and if a preconfig-ured maximum is exceeded, the time error OB80 is called.On S7-400and WinACalso a minimum for the cycletime of OB1 can be configured. If the execution time forOB1 is less then , the background OB90 is called, whichhas the lowest priority. The priority of all other OBs increaseswith its number. Only on S7-400and WinACthis default pri-ority can be changed. Each OB can be interrupted by OBs witha higher priority. Table I lists the possible OBs. Availability ofOBs depends on the CPU type. If more OBs of a certain typeare required, a more expensive CPU has to be bought.Time-of-day interrupt OBs are started at a preconfiguredtime, e.g., end of a shift, whereas time delays interrupt OBs arestarted at the expiration of a one-shot-timer. Cyclic interruptOBs are started with a fixed frequency. The time interval andthe phase offset can be configured with a granularity of 1 ms.Hardware interrupts OBs are started by a an event at an input orfunction module, e.g., detection of the rising edge of a digitalsignal. This functionality is only available with so-called “HighFeature” input modules. Synchronous error OBs are startedby errors in the user program, whereas asynchronous errorinterrupt OBs are started by PLC faults, like power failure,module failure or time errors. A time error occurs, when an OBcannot meet its scheduled start time, and is an unique featureof PLCs.III. REAL-TIME PERFORMANCE MEASUREMENTSA. Performance Evaluation GoalsA key issue of real-time performance is the reaction time toexternal events. Because PLC systems basically conform to asynchronous programming model, this is directly determined bythe cycle time , which has to be analyzed for the free runningcycle OB1 and cyclic interrupts; e.g., OB35. To determine theapplication area of PLC classes, the minimum of has to bemeasured for different PLC types. The actual value of in aspecific application depends on the amount of code in the cyclicOB, of course.TABLE IOB TYPES OF A SIMATICS7TABLE IIPLCS UNDER TESTDeterministic behavior of a PLC is determined by the jitter of, which is of primary interest for cyclic interrupts.With “High Feature” input modules, also hardware interruptsare possible. Here the minimum response time , which isdefined as the time to activate OB 40, and its jitter has to bemeasured.In order to get a complete picture, the measurements have tobe conducted for a mini PLC, a midrange PLC and a high-endPLC. Table II shows the CPUs, that have been selected for themeasurements in this paper. The time for a floating point addi-tion has been measured by repeating it times, in order toconvey an impression of their relative performance, which dif-fers considerably.Because of the distributed nature of PLC-based systems, theimpact of PROFIBUS communication to response time is an im-492 IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 51, NO. 3, JUNE 2004Fig. 4. Experiment setup.Fig. 5. Histogram of OB1 cycle time at IM151/CPU.portant issue. Thus the additional delays introduced by commu-nication as well as the additional jitter have to be analyzed. Butpresentation of communication-related measurements would gobeyond the scope of this paper and will be covered by a futurepublication.The analysis of the response time as a function of the systemload, e.g., induced by harddisk activity, communication or back-ground computing, is a key issue on conventional POSIX-likereal-time systems. This is not an issue on PLC systems be-cause of their synchronous cyclic operation. Even the commu-nication on fieldbusses like PROFIBUS DP V0 or AS-Interfaceis cyclically, thus inducing a constant load. For asynchronoustype of communication, e.g., TCP/IP, intelligent communica-tion controllers are used, thus offloading the CPU. An exceptionfrom this rule is the MPI (Multipoint Interface, a proprietaryfieldbus), that is integrated in each CPU. But in Jlich MPI isonly used for programming.B. Measurement ScenarioAccording to Fig. 4 the inputs of the PLCs under test (listedin Table II) are connected to a pulse generator. OB40 is acti-vated by a rising edge of the input signal and toggles a outputsignal. The output of the pulse generator and outputs of thePLC under test are connected to the National Instruments analoginput module NI6062 E. The signals are sampled with a fre-Fig. 6. Histogram of OB1 cycle time at CPU314C-2DP.quency of 100 kHz. Matlab code has been developed that de-tects rising edges in the sampled signals, computes the requiredtime differences and forms an histogram of the measured data.Thus the distribution of the response time of the PLC can bemeasured. The distribution of the cycle time is measured inan analogous way. Alternatively, the signals are connected to theTDC module SIS 3400 from Struck Innovative Systems. Thusthe correctness and the sufficient precision of the measured datacould be verified.C. Measurements of the Main Program Scan Cycle OB1Figs. 57 show the distribution of for OB1 measured onthe first three PLC in Table I. There was no other activity onthe system than OB1, which only contained code for toggling adigital output directly without using the process image table.The minimum for and its jitter are caused by operatingsystem activities and get better with increasing performance ofthe PLC under test. Although me value and variance of forthe S7-300are much better than for IM151/CPU the worstcase is comparable. CPU412-2 is almost determistic, basicallytaking two discrete values. This is not necessarily caused byCPU behavior, because at these frequencies the behavior of thedigital outputs gets significant, too. This caused artifacts onthe CPU414-1 where we measured a minimum cycle time of0.2 ms. But in this situation the time between two state changesKLEINES et al.: SIMATICPLC OPERATION 493Fig. 7. Histogram of OB1 cycle time at CPU412-2.Fig. 8. Histogram of OB1 cycle time at CPU412-2 with background load.of the output was several milliseconds with a extremely highjitter. When we increased the minimum duration of OB1 at theCPU414-1 to 1 ms, the time between output changes becamemuch lower, and cycle time on the CPU was consistent with thespeed of the outputs. This illustrates, that I/O modules have tobe selected carefully. Standard modules have delays in the orderof milliseconds, because of protection circuits, additional elec-tronics to reduce electromagnetic noise, filters for stable read ofswitches, etc.As expected, Fig. 8 shows that the jitter of for OB1 mea-sured at CPU412-2 increases with constant background load in-duced by OB35 (called every ms). Again the distribution ofis almost discrete, which indicates that there must be some in-ternal cycle of about 0.2 ms. Because of the synchronous oper-ation of a PLC, the maximum of can be estimated when theduration of each OB is known. The results show that OB1 is notadequate for applications, which require a fixed scan rate, e.g.,in a control loop. Section III-D examines if a cyclic interruptOB can meet these requirements.Fig. 9. Histogram of OB35 cycle time at CPU314C-2DP.Fig. 10. Histogram of OB35 cycle time at CPU412-2.D. Measurements of the Cyclic Interrupt OB35Figs. 9 and 10 illustrate that the cyclic interrupt OB35 hasan extremely low jitter, compared to OB1. Again CPU412-2exhibits an almost discrete distribution of . Cyclic activationof tasks with a frequency of 1 kHz at a precision better than0.1 ms is a unique feature of PLCs, that is even not possiblewith LynxOS on a Pentium II platform 7. The smallest possibleOB35 cycle time of IM151/CPU is 2 ms, because of the lowperformance of this CPU.E. Hardware Response-Time MeasurementsFigs. 11 and 12 show , the activation time of OB40with a rising edge of the input, including all hardware-relatedtime fractions, measured at CPU314C-2DP and IM151/CPU.Because we had no “High feature” input for the S7-400,we could not measure this metric for the S7-400series. Themean value of and its variance measured at IM151/CPUare unsatisfactory, even for a low-end PLC. The values of494 IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 51, NO. 3, JUNE 2004Fig. 11. Histogram of OB40 response time at IM151/CPU.Fig. 12. Histogram of OB40 response time at CPU314-2DP.measured at CPU314C-2DP are about five times worse than aPOSIX system on Pentium II platform 7, but are sufficient fortypical PLC application scenarios.IV. CONCLUSIONIt was shown, that usage of PLCs in physics experiments of-fers numerous advantages. They operate in a synchronous cyclicway with high predictability. With regard to their real-time prop-erties, they are adequate for application scenarios, that require adeterministic response time in the order of a few milliseconds.Response times of 1 ms or eve