Sie sind auf Seite 1von 108

Embedded Systems

B. Vogel-Heuser

Oldenbourg Industrieverlag

Embedded Systems
Prof. Dr.-Ing. B. Vogel-Heuser Editor in Chief

Oldenbourg Industrieverlag Mnchen

2008 Oldenbourg Industrieverlag GmbH Rosenheimer Strae 145, D-81671 Munich Phone: +49 89 45051-0 www.oldenbourg-industrieverlag.de This work, including all figures, is copyrighted. Any use outside the limits of the copyright law is not permitted without permission of the publisher and is punishable. This applies, in particular, to copying, translating, microfilming, and importing and editing in electronic systems. Editor: Elmar Krammer

Table of Contents
M. Bani Younis, A. Fay, G. Frey Automatic Re-Implementation of PLC Programs S. Diehm Supporting the design of drive applications for packaging machines T. Dreyer, A. Schrder, iSAS Integration of Engineering, Initial Operation and Maintenance W. Faulhaber, Integrating Real-Time Ethernet in Injection Molding Machines M. Finkbeiner Modularity in machinery Ch. Gemke IO-Link Communication at the Lowest Field Level M. Huelke, M. Hauke, J. Pilger SISTEMA: a Tool for the Easy Application of the Control Standard EN ISO 13849-1 F. Iwanitz Net diagnosis for Profinet IO J. O. Krah, Ch. Klarenbach IPC based closed loop control of decentralized Servo Drives with eXtreme Fast Control (EtherCAT XFC) U. Schnemann, Programming PLCs with an Object-Oriented Approach H. Thompson Flexible Control Systems Development and Integration Environment for Distributed Systems

Automatic Re-Implementation of PLC Programs


Dr.-Ing. Mohammed Bani Younis, Helmut-Schmidt-Universitt Hamburg, Fakultt fr Maschinenbau, Institut fr Automatisierungstechnik, Germany Prof. Dr.-Ing. Alexander Fay, Helmut-Schmidt-Universitt Maschinenbau, Institut fr Automatisierungstechnik, Germany Hamburg, Fakultt fr

J.Prof. Dr.-Ing. Georg Frey, Technische Universitt Kaiserslautern, FB EIT, JPA, Germany

Automatische Re-Implementierung von SPS-Programmen


Die Re-Implementierung von SPS-Programmen auf eine neue HW-Plattform ist oft erforderlich, um neue Produktionsanforderungen zu befriedigen oder eine veraltete SPS zu ersetzen. Dieser Beitrag beschreibt einen Ansatz fr die Re-Implementierung von bereits existierenden SPS-Programmen auf Basis formaler Methoden in Form von Automaten. Diese Automaten (FSM - Finite State Machines), die in diesem Ansatz im XML-Format vorliegen, werden danach in ein SPS-Programm in SFC (Ablaufsprache) gem IEC 61131-3 umgewandelt. Dieses Programm kann dann vom neuen SPS-Controller abgearbeitet werden. Keywords: PLC, Formal Methods, Re-Implementation, XML

1. Introduction Programmable Logic Controllers (PLCs) have been in use in machines and plants for several decades. In case of modernizations and re-structuring of machines, the necessity increases to modernize the installed PLC because it can no longer meet the increasing requirements, as well as spare part costs. Furthermore, it is often desirable (if not even required) to change not only the PLC type but also the PLC vendor, e.g. to adapt a machine to the preferences of a particular customer or to the preferences of a certain region where the machine is to be shipped to. The reimplementation of mature control programs on another, new PLC is still a laborious, cumbersome and error-prone manual task, even if it is supported by some industrial tools on a low abstraction level nowadays. The re-implementation results achieved by these state-of-the-art industrial tools offer only limited assistance, because they do not allow a fully automatic transfer onto a new platform. In addition, a functional check is not possible before the machine is in operation with the new PLC this induces a considerable risk for a timely re-start of production. In addition, the existing tools lack functionality for the re-documentation of changed code. This makes it difficult for the user to understand the changed code and to follow the algorithms used.

These obstacles have inspired researchers to investigate ways to analyze, verify, and simulate PLC programs on an abstract level before migrating them to the new controller running on the physical plant [1, 2, 3, 4]. In order to avoid the limitations and problems mentioned above, this work proposes a re-implementation approach based on formal methods. These formal methods allow: a formal analysis of the existing PLC control code, a documentation and visualization of the PLC control code, and a separation of the source and the target code, with a PLC-independent intermediate storage format.

The presented work in the scope of this paper uses Instruction List (IL) as the input code for the re-implementation and generates a functional equivalent code in Sequential Function Chart (SFC), according to IEC 61131-3. However, the approach presented here is not limited to these source and target languages. The rest of the paper is structured as follows. In Section 2, some more information on PLCs and STEP5 is given. The re-implementation approach is introduced in Section 3. Section 4 provides an example to illustrate the method. Section 5 concludes this paper and gives an outlook on future work. 2. PLCs and STEP 5

The presented approach is not based on the standard form of IL proposed by the IEC 61131-3 [5,6] but on the vendor-specific programming language STEP5 IL by Siemens. This language had been a quasi-standard in Germany for several years, with a large installed base of machines and plants, and the corresponding hardware is now no longer produced. This means that there is a good possibility for the application of re-implementation. The software on a STEP5 PLC is implemented in a hierarchical form using four main types of modules as follows: OB: Organization Block; serves for the management of the user program in form of a listing of the program modules to be worked on. PB: Program Block; in this module the user programs are located structured in groups. It includes only binary operations. FB: Function Block; this is often used to realize frequently used or complicated functions. The PLC operations in FBs are in a hybrid form i.e. digital and binary operations. DB: Data Block; this module contains data which the other Blocks operate on. In addition to these general modules STEP5 also holds special types of modules like timers and counters.

3.

Re-Implementation approach

The presented approach is an extension of previous work described in [7]. Figure 1 illustrates the individual steps for the re-implementation of PLC programs. The approach is implemented in Java and consists of the following four main steps (blocks in Figure 1): Step 1: The PLC text is converted into a raw XML mapping its tabular form [7]. Step 2: The raw XML is converted to an XML with instruction IDs. Based on the added information about the instructions, the assembler-like program is abstracted to a series of IF-THEN-ELSE statements. Step 3: Finite State Machines (FSMs) are derived from the IF-THEN-ELSE statements and are written in an XML format (this format is compatible with the format taken from the CodeProject [8]). Step 4: Conversion of the FSM in XML into ASCII format of the SFC (this step has not been described in previous publications). The four steps are further explained in the following sub-sections.

Figure 1: Steps of the Re-Implementation of PLC Programs.

3.1.

Conversion of the PLC text into XML

Given a PLC program in IL in ASCII format and in a tabular structure with separate columns for addresses, labels, instructions, operands and descriptions delimited by white-spaces, XSLT can convert it into a well-formed XML document. The XML document obtained through this transformation is a hierarchically structured document. The obtained XML as a result of the previous processing can be validated using a validating parser that confirms that the XML document in addition to being well-

formed conforms to the set of syntactic rules defined in context of the PLC programming language (cf. Figure 2).

Figure 2: XML-Schema describing the valid IL structure.

3.2.

Instruction Identification and Abstraction

XSLT is used to transform the well-formed and valid XML to another XML which as a result of identification of instructions has additional attributes appended to the instruction tags. This XML contains the Address, Label, Instruction, and Operand, together with the attributes of the instruction like the Instruction_Id, Type, Condition, and the Denotation. The Instruction_Id attribute notifies whether the instruction is a valid instruction of the concerned instruction set. The type attribute classifies the operations into different types. The main idea in the abstraction step is to merge several instructions. As an example, the case of binary operations is presented in the following: in an assemblylike language like IL, there are instructions that only influence the current state of the accumulator (not any other variables or output ports). However, the state of the accumulator is not of interest for the correct description of the algorithm. Therefore, operations that only influence the accumulator may be grouped until an operation arrives in the sequence that depends on the result of this calculation. The result of this abstraction is a sequence of IF-THEN-ELSE statements. A very simple example is the IL code shown in Figure 3: The operation U resembles a logical AND (and a load if it is the first operation in a sequence). The operation S sets the operand to 1 if the accumulator content is one, else it is not executed.
IL-Code: U M1 U M3 U M4 S M5 Resulting IF-THEN-ELSE Code IF (M1 AND M3 AND M4) = 1 THEN M5 = 1
Figure 3: Example for IF-THEN-ELSE abstraction.

3.3.

Formalization

The sequence of IF-THEN-ELSE statements generated in the abstraction step is converted to an FSM described in a further XML format. Basically, for each IF-THENELSE statement a state of a Mealy automaton is generated, and the THEN and ELSE parts form the arcs in the automaton. Details regarding the IF-THEN-ELSE abstraction algorithms and the generation of the corresponding FSMs can be found for binary algorithms in [9], for timers and counters in [10], and for non-binary algorithms in [11]. 3.4. Conversion into SFC

Most machines and plants operate in production cycles. Therefore, the PLC program has mainly the task to control the sequence of actions in these production cycles, including alternative sequences, and changes between different operation modes. To optimally design, test, implement and maintain these sequence control algorithms, the IEC 61131-3 standard provides the SFC language. It is therefore desirable to reimplement these sequence control algorithms in SFC. This step towards the conversion into SFC is an extension to the steps 1-3 described earlier in [7] and [9-11]. The FSM in XML format is converted into the ASCII format of SFC (in particular into the textual description of SFC in IEC 61131-3, as defined in [12]). The rules for the conversion of FSM XML into SFC are explained as follows: 1. The initial state of the FSM is converted into an initial step in the SFC. 2. The condition of the state transition is transformed into a new transition of the SFC which points to a new step in SFC. The outputs of the FSM transition are converted into actions of the step. For each output of alternative transitions, a new step has to be generated. A dummy transition has to be extra generated with a TRUE condition to represent a destination of the action step before. This transition has to point again to a dummy step. The latter is important in case multiple FSM transitions point to the same state. 3. The conversion of timers, counters and other functions (Non-binary functions) is implemented by means of the S action qualifier of SFC. An external action will be allocated for this qualifier which retrieves the logic of the function of the input PLC code of the conversion. In case of timers and counters, the allocated action is used for the start of the timer or counter. As pointed out above, the conversion of IL to SFC should only be applied to sequence control algorithms, but not to latches and interlocking control code, which is intended to be executed in every PLC cycle. It is therefore necessary to automatically distinguish sequence control code from interlocking control code. This is not trivial, since both look similar in IL. An important feature to distinguish whether a given piece of control code is of sequence control type is to investigate the FSM in XML for the use of variables or flags which store the information about which step is active. These flags are necessary to ensure the sequential behavior of the sequence control code. Whereas in SFC, the information about which step is active is stored internally. In each other PLC language, the PLC programmer has to program these flags (and their setting and re-setting) manually in the sequence control code (see for

example the flags M100.0, M101.0, M102.0, M103.0, and M104.0 in the example given in Figure 5). The four steps described above to convert IL code into SFC code will be expressed by means of an example in the next Section. 4. Example The proposed approach is illustrated in the following example: A mixing machine for two colors (cf. Figure 4) controlled by a Siemens Simatic S5 PLC programmed in STEP 5 Instruction List. The main aim of the PLC program is to control the production cycles of the mixing machine, i.e. it is a sequence control program that can be converted into SFC. This sequence control type is given using step flags (in Figure 5 e.g. UN M 102.0 followed by = M 101.0 where M102.0 represents STEP2 whereas M 101.0 represents STEP1). Note that the comments (explanations) listed in the right part of Figure 5 are only shown to illustrate the example, but are not interpreted in any way by the re-implementation algorithm.

Start S0

H0 Start LED

S6 Emergency Stop

Stirrer M1 with F1

Y1

Y2

Pump M2 with F2 B4 Sensor B2 Sensor B1 Sensor

Liquid 1

Liquid 2 Mixing Vessel

Figure 4: Mixing machine example.

The controlled production cycle is as follows: After actuation of the start button S0, the LED H0 is switched on, the valve Y1 is opened, and the pump M2 is started. When the liquid reaches the sensor B1, the valve Y1 is closed, and valve Y2 is opened. When the liquid reaches the sensor B2, the valve Y2 is closed, the pump M2 and the LED H0 are switched off, and the stirrer M1 is switched on. After six seconds, the stirrer M1 is switched off. After the described process, the system is in its initial state again. By means of the emergency stop S6, the thermal triggers F1 or F2, or by reaching limit switch B4, the plant can be switched off at any time. The control program consists of two modules: the Organization Block OB1 and a Program Block PB2. The OB1 only contains two lines of code (SPA PB2 to call PB2 and BE, the end statement of STEP5).The actual control algorithm is programmed in PB2 as shown in Figure 5, containing 12 groups of instructions. The steps for the re-implementation of PB2 start from the XML with instruction identification (cf. Segment given in Figure 6). From this XML the abstracted code in the form of IF-THEN-ELSE statements is generated (cf. Figure 7). The transformation

of the program code into a FSM results in an XML description as shown in Figure 8. Finally, an SFC is generated describing the dynamics of the module (cf. Figure 9 for the ASCII SFC format and Figure 10 for the SFC imported into the IEC61131compliant tool CoDeSys). Note that in the STEP5 code, a timer operation is used to initiate the timer T51 (see network 12 in Figure 5). This timer is converted automatically using the S qualifier of an external SFC action, which is used to start a TP time function (cf. Figure 11 where SBE refers to the name of the state in the FSM).
[1 U U U UN = *** ] [2 U U O U U UN = *** ] [3 U U O U U UN = *** ] [4 U U

E E E E M

0.6 1.2 1.3 0.4 120.0

E M M M M M

0.0 100.0 101.0 120.0 102.0 101.0

M E M M M M

101.0 0.1 102.0 120.0 103.0 102.0

M E

102.0 0.2

O U U UN = *** ] [5 U U U = *** ] [6 O O U U UN = *** ] [7 O O U U UN =

M M M M

103.0 120.0 104.0 103.0

M T M M

103.0 51 120.0 104.0

M M M M M

101.0 100.0 120.0 104.0 100.0

M A M M A

101.0 1.0 120.0 103.0 1.0

***

] [8 O O U U UN = *** ] [9 U = *** ] [10 U = *** ] [11 U = *** ] [12 U L SI BE

M A M M A

101.0 2.1 120.0 103.0 2.1

Operand E0.0 E0.1 E0.2 E0.4 E0.6 E1.2

M A

101.0 1.1

E1.3 A1.0 A1.1 A1.2 A2.0 A2.1 M100.0 M101.0 M102.0 M103.0 M104.0 M120.0

M A

102.0 1.2

M A

103.0 2.0

M 103.0 KT 006.2 T 51

Comment Start Button Sensor B1 Sensor B2 Sensor B4 Emergency stop (Break contact) Thermal Actuator F1 (Break contact) Thermal Actuator F2 (Break contact) Start LED Valve Y1 Valve Y2 Stirrer M1 Pump M2 Start Flag STEP 1 STEP 2 STEP 3 STEP4 Off Flag

Figure 5: STEP5 IL program of the mixing machine (PB2).


<?xml version="1.0" encoding="ISO-8859-1" ?> <ILCodeBlock xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="IL" CodeName="PB2_absolute" xsi:schemaLocation="http://www.eit.uni-kl.de/frey/PLC/ILns.xsd" name="Code"> <ILRow> <Instruction Denotation="beeinf_VKE" Condition="no condition" Type1="typ2a" InstructionId="Logical Operator and binary">U</Instruction> <Operand>E 0.6</Operand> </ILRow> <ILRow> <Instruction Denotation="beeinf_VKE" Condition="no condition" Type1="typ2a" InstructionId="Logical Operator and binary">U</Instruction> <Operand>E 1.2</Operand> </ILRow> ...

Figure 6: Segment of the XML representation of IL with Instruction IDs.


IF E0.6 AND E1.2 AND E1.3 ANDN E0.4=1 THEN M 120.0=1 ELSE M 120.0=0 IF E0.0 AND M100.0 OR M101.0 AND M120.0 ANDN M102.0=1 THEN M 101.0=1 ELSE M 101.0=0 IF M101.0 AND E0.1 OR M102.0 AND M120.0 ANDN M103.0=1 THEN M 102.0=1 ELSE M 102.0=0 IF M102.0 AND E0.2 OR M103.0 AND M120.0 ANDN M104.0=1 THEN M 103.0=1 ELSE M 103.0=0 IF T 51,Bit 14!="Time is Running" THEN {IF M 103.0 AND M 120.0=1 THEN M 104.0=1 ELSE M 104.0=0} ELSE M 104.0=0 IF M101.0 OR M100.0 AND M120.0 ANDN M104.0=1 THEN M 100.0=1 ELSE M 100.0=0 IF M101.0 OR A1.0 AND M120.0 ANDN M103.0=1 THEN A 1.0=1 ELSE A 1.0=0 IF M101.0 OR A2.1 AND M120.0 ANDN M103.0=1 THEN A 2.1=1 ELSE A 2.1=0 ...

Figure 7: Segment of the IF-THEN-ELSE Abstraction of PB2.

<?xml version="1.0" encoding="UTF-8" ?> <fsm name="PB2_absolute"> <state name="S0"> <transition action="M 120.0=1" input="E0.6 AND E1.2 AND E1.3 ANDN E0.4" next="S1" /> <transition action="M 120.0=0" input="~( E0.6 AND E1.2 AND E1.3 ANDN E0.4 )" next="S1"/> </state> <state name="S1"> <transition action="M 101.0=1" input="E0.0 AND M100.0 OR M101.0 AND M120.0 ANDN M102.0" next="S2" /> <transition action="M 101.0=0" input="~(E0.0 AND M100.0 OR M101.0 AND M120.0 ANDN M102.0 )" next="S2" /> </state> ...

Figure 8: Segment of the FSM in XML format (States S0 and S1).


IEC_INITIAL_STEP S0: END_STEP TRANSITION FROM S0 TO S1_S:= E0_6 AND E1_2 AND E1_3 ANDN E0_4 END_TRANSITION IEC_STEP S1_S: M120_0(S); END_STEP TRANSITION FROM S1_S TO S1:= TRUE END_TRANSITION TRANSITION FROM S0 TO S1_R:= NOT (E0_6 AND E1_2 AND E1_3 ANDN E0_4) END_TRANSITION IEC_STEP S1_R: M120_0(R); END_STEP TRANSITION FROM S1_R TO S1:= TRUE END_TRANSITION IEC_STEP S1: END_STEP TRANSITION FROM S1 TO S2_S:= E0.0 AND M100.0 OR M101.0 AND M120.0 ANDN M102.0 END_TRANSITION IEC_STEP S2_S: M101_0(S); END_STEP TRANSITION FROM S2_S TO S2:= TRUE END_TRANSITION TRANSITION FROM S1 TO S2_R:= NOT(E0.0 AND M100.0 OR M101.0 AND M120.0 ANDN M102.0) END_TRANSITION IEC_STEP S2_R: M101_0(R); END_STEP TRANSITION FROM S2_R TO S2:= TRUE END_TRANSITION IEC_STEP S2:

Figure 9: SFC diagram (ASCII).

Figure 10: SFC diagram of S0 and S1 (screenshot taken from the CoDeSys tool).

Figure 11: SFC diagram of T51 timer (screenshot taken from the CoDeSys tool).

5. Conclusion and Outlook The re-implementation of PLC control code to a new PLC platform is important to meet new manufacturing demands or to substitute a PLC whose HW is no longer produced. The paper presents an approach for the re-implementation of existing PLC programs based on formalization and visualization. The FSM in XML format of the IL PLC program is transformed into IEC 61131-3 SFC. The next steps of the authors work are the extension of the re-implementation steps to be able to optimize the SFC, e.g. by means of hierarchal SFCs. References [1] L. Baresi, M. Mauri, A. Monti, and M. Pezze, PLCTools: Design, Formal Validation, and Code Generation for Programmable Controllers, in Proc. IEEE Conference on Systems, Man, and Cybernetics (SMC2000), Nashville, USA, Oct. 2000, pp. 2437-2442. [2] A. Mader and H. Wupper, What is the method in applying formal methods to PLC applications?, in Proc. of the ADPM 2000 Conference, Shaker Verlag 2000, pp. 165-171. [3] S. Lamprire-Couffin,O. Rossi, J.-M. Roussel, J.-J.Lesage, Formal Validation of PLC Programs: A SURVEY, in Proc. European Control Conference (ECC99), Karlsruhe, Germany, Sept. 1999, paper No. 741. [4] G. Frey and L. Litz, Formal methods in PLC programming, in Proc. IEEE Conference on Systems, Man, and Cybernetics (SMC2000), Nashville, USA, Oct. 2000, pp. 2431-2436. [5] International Electrotechnical Commission, IEC International Standard 1131-3, Programmable Controllers, Part 3, Programming Languages, 1993. [6] K-H. John, M. Tiegelkamp, IEC 61131-3 Programming Industrial Automation Systems, Springer, 2001. [7] M. Bani Younis and G. Frey, Visualization of PLC Programs Using XML, in Proc. of the American Control Conference (ACC2004), Boston, USA, June 30 July 2, 2004, pp. 3082-3087. [8] CodeProject web site XMLFSM http://www.codeproject.com/csharp/xmlfsm.asp [9] G. Frey, M. Bani Younis, A Re-Engineering Approach for PLC Programs using Finite Automata and UML, in Proc. IEEE International Conference on Information Reuse and Integration, IRI-2004, Las Vegas, USA, Nov. 2004, pp. 24-29. [10] M. Bani Younis, G. Frey, Formalization and Visualization of Non-binary PLC Programs, in Proc. of the 44th IEEE CDC-ECC 2005, Seville, Spain, Dec. 2005, pp. 8367-8372. [11] M. Bani Younis, G. Frey, Formalization of PLC Programs to Sustain Reliability, in Proc. of the 2004 IEEE Conference on Robotics, Automation and Mechatronics, RAM-2004, Singapore, Dec. 2004, pp. 613-618. [12] http://ww.plcopen.org/pc2/SFC-textual.doc

Supporting the design of drive applications for packaging machines


Dipl. Inf. (FH) Sebastian Diehm, ELAU AG, Software Development

Supporting the design of drive applications for packaging machines


Engineering tools that handle increased requirements of mechatronic packaging machines contribute to lowering engineering costs. One of the most complex tasks in this case is motion design. Previously, this required complicated and time-consuming procedures. Tools such as ECAM-4 provide an approach to performing motion design more comfortably. Secondary tasks are automated, leading to high-quality results and reducing time requirements. The electrical and mechanical dimensioning of the new intelligent iSH servo module with integrated electronics is possible with ECAM-4, too. In summary, ECAM-4 provides a holistic perspective to packaging machine automation especially for mechanical engineers. Motion Design, Drive Sizing, Holistic Engineering

1. Mechatronic system design In the past decade, packaging machine design has gone through a significant change caused by the changing consumer behavior and greater product diversity and more sophisticated product ideas offered as a response by e.g. the food and cosmetics industries. For packaging machine design this means that a machines flexibility has meanwhile become at least just as important as its velocity. Preferably, machines provide push button format changes so that one machine line can pack various products with short standstill times. This situation leveraged the so-called Gen3 packaging machines. They are fully software-controlled and motion control systems with integrated PLC functionality translate their commands into movements via servo drives. Program or parameter modifications respectively make product-specific machine changeovers largely automatic and more independent from format-specific modules. Electronic packaging machines have resulted in more flexibility but also in increased complexity which is reflected in longer engineering times and higher engineering costs for the OEM. Thus, efficient engineering tools that accommodate the increasing complexity of mechatronic systems can contribute to curbing engineering costs.

2. Holistic approach is the prerequisite for a real increase in efficiency One of the most demanding tasks in developing servo-driven machines is motion design: Motion sequences have to be defined and synchronized for all the servo drives involved in the process and their mechanic units implementing the rotary motions. The individual axes often carry out complex motions that are made up of individual segments. By applying motion laws, the segments transitions are preferably to be defined jerk-free, thus resulting in a harmonic movement. Standard motion-control functionalities mapping fixed pre-set motion laws onto software usually can not fulfill the task. Besides, motion design is but one aspect in developing synchronous servo systems; there are a number of definitely demanding steps between the definition of motion sequences and their implementation. Hence, a software tool for developing synchronous servo systems needs to take a holistic approach accommodating all the individual aspects ranging from motion design and drive sizing to their implementation in specific motor types and with necessary and tolerable currents respectively. The market for drive and servo technology offers numerous tools for motion design and drive sizing, however, none of those tools takes a holistic approach. Thus combinations of several tools are always required which in turn causes issues like differing user interfaces and definitions, transfer of data with different formats and no standardized data base.

3. Holistic approach realized with ECAM Now available, the VarioCam editor ECAM-4 represents the first tool ever that takes a holistic approach. A component of an engineering toolkit for Elaus PacDrive automation platform, the VarioCam editor integrates tools for motion design and for drive sizing of complex multi-axe systems. The tools functionalities also include power-circuit dimensioning functionalities for the DC bus coupling necessary for the practical implementation. Thus, tools for powercircuit dimensioning and the calculation of the interchange between the drives via the DC bus are available. A great support even today, power-circuit dimensioning will gain in importance in future: It is foreseeable that only a few Figure 1: Individual aspects in the years down the road integrated servo development of multi-axe servo systems drives with a shared central power supply unit will play a relevant role in packaging machine engineering drive solutions.

A consistent example below of a sealing unit of a forming, filling and sealing machine will show which benefits holistic engineering with ECAM offers for the engineer and others. Vertical forming, filling and sealing machines are used for filling and packaging of powdery, granular, chunky or liquid and soft products; the range of producible bag forms covers e.g. flat bags, stand-up pouches, block-bottom bags, and side gusset bags. Due to their clocked operation mode, intermittent forming, filling and sealing machines produce up to 150 bags per minute, continuous forming, filling and sealing machines up to 250 bags per minute.

Figure 2: Schematic diagram of a forming, filling and sealing machine

Figure 2 shows the operation principle of a continuous vertical forming, filling and sealing machine. The machine preforms a tube from an endless sheet of packaging material by means of a so-called forming shoulder; the overlapping seams are sealed by a longitudinal seam sealer. A temperature control and a constant contact pressure ensure consistent quality of the seams. The bulk goods are filled into the film tube through a dosing unit; the lateral seam sealer with two electronically controlled sealing clamps seals the filled bag while sealing the bottom seam of the next bag at the same time. The bag length is also defined via the lateral sealing process. A cutting device embedded in the sealing tools cuts off the finished bag from the endless film. During the sealing process, the lateral seam sealers are synchronized with the foil feed. After the foil has been sealed, the carriage slide with the lateral seam sealers returns to the home position in accordance with the principle of the flying saw. The filling and lateral sealing process results in two fundamental functional units for the sealing unit: On the one hand the lateral seam sealers themselves and on the other hand the carriage slide which transports the sealing clamps parallel to the film tube. Since the movement of the sealing clamps is a simple stroke movement, the following remarks will focus on the carriage slide whose movement is worth a more detailed elaboration 3.1 Mechanics mapping As a first step, the mechanical engineer will make a structural decomposition of the machine parts as he usually already has detailed knowledge of the structure from his CAD diagrams. Since the carriage makes a translatory movement, a corresponding

linear mechanical layout can be selected in ECAM. The belt drive represents a good approach.

Figure 3: Mechanical selection in ECAM-4

The screenshot shows the mechanical chains for the carriage slide. The motor is coupled to the carriage slide via a main drive. The mass of the load is given for the carriage itself. Due to the default inclination angle, both inertia and weight force are taken into account in the drive sizing. An additional translation is not necessary in this case. Various additional translations ranging from simple couplings and user-defined drives with free transmission ratios to flat belt drives can be modeled for other applications. Even for the basic mechanics a great selection of rotary and linear mechanical elements ranging from a simple rotary table to a crank are available. The corresponding transformations can be defined by means of the formula editor. A mass and drive editor respectively enables the user input of values for masses and inertias; by means of this editor complex bodies can be composed of simple geometries. More than 50 different materials are available to the user so that even e.g. plastic parts can be modeled. The parameter input supports iterative detailing of the mechanic model. Even if some parameters are not known from the beginning, the tool will still supply approximate values.

3.2 VDI2143-compliant motion design The VDI 2143 guideline defines motion laws for cam mechanisms which are the basis for motion design of servo axes. Up until a few years ago, it was still quite common to draw motion on millimeter paper. There is no need for that anymore even though examples can still be found. Given effective motion design tools like ECAM 4 it becomes clear that these software tools can only be of benefit if used by the OEMs engineering.

Figure 4: Motion diagram of the carriage slide and the sealing clamps

The process description above is the basis for developing a motion plan which gives a more exact definition of the carriage motion. Basically two motion phases can be identified: In the first motion phase, the carriage with the lateral seam sealers is moving synchronously with the foil feed; the lateral seam sealers carry out their stroke movement and seal the film. In the subsequent second phase, the carriage returns to the home position. Both these phases are mapped in the motion diagram (figure 4). In order to prevent the mechanical parts from damage during homing, the motion is executed according to a law that limits the jerk and is shock-free.

As elaborated in the VDI2143 guideline, shock is defined as an infinite acceleration singularity which occurs when the motion curve has a bend and the velocity curve is not continuous. A jerk, in contrast, represents a finite acceleration discontinuity occurring if the velocity curve shows a bend. Thus a cam will be shock-free if there is a single finite acceleration discontinuity at most. Generally, motion design not only needs to observe jerk-limited laws of motion but also the fact that the motion in the interfaces between the individual segments needs to be jerk- and shock-free. A 5th degree polynomial was used for the carriage of the forming, filling and sealing machine during homing; according to the VDI2143 guideline, the 5th degree polynomial is inherently jerk-free; thus it assures a high running quality. And on the boundaries of the motion segments, too, the jerk is limited as the velocity is steady. Hence, the motion is shock-free. In parallel to the synchronized movement of the carriage, the motion of the lateral sealing clamps is exemplarily shown in a second motion diagram. When the sealing clamps are in their sealing position, they exert sealing pressure on the film. This can be modeled in ECAM-4 as well. 3.3 Approximate motion design via positioning As an alternative to mapping motion in accordance with VDI2143 laws of motion, a first approximate motion definition can also be done by positioning. The individual segments can be defined by means of 5 different positioning modes; it is possible to string together segments here as well in order to design more complex motions.

Figure 5: Approximate motion design Modeling of the sealing clamp motion

The screenshot (figure 5) shows the modeling of the sealing clamp motion. The segment definition is enabled by virtue of the fact that the user only needs to enter maximum values for e.g. the velocity and the acceleration. ECAM uses these values together with the absolute target values for calculating the actual velocity and acceleration courses. The user can switch over between linear curves and S curves for the velocity ramps. Since the velocity course does not show any bends, the curves can be strung together jerk-limited. 3.4 Drive sizing As a next step, the selection of the optimal combination of motor and drive is based on the given mechanics and motion. Due to economic reasons, the mechanical engineer is often bound to specific motor and drive series. ECAM enables setting filters on drive and motor types and defining application-specific constraints for motor series and drive types. Thus it is possible to cut the number of possible combinations of currently about 100,000 combinations to several dozens or hundreds. The detailed data can then be read and examined on the result pages. This also supports an iterative process. The iterative refinement of the selection eventually leads to the optimal choice of a motor/drive/gear combination. 3.5 Power Circuit dimensioning At the end of the said process, the completed motion cam with the precise information on the combination of motor and drive as well as on the required gear is available. Hence, all the requirements for the practical implementation are given. In order to take into account the aspect of holistic engineering, however, electrical values have to be considered as well.

Figure 6: Incurring brake power requires an external braking resistor

With regard to the forming, filling and sealing machine, the said axes are examined as to circuit currents and breaking energies. To this end, the requirements are modified so that required machine performance is tightened: Instead of 500 mm, the bag length is to be 340 mm. The dimensioning of the intermediate circuit for the individual axes shows that the energy output of the carriage axis during the synchronized run is higher than can be buffered by the drives DC bus. The internal braking resistor needs to eliminate this energy; in case the internal braking resistor is too small, an additional external braking resistor is necessary. In practice, there is an effort to benefit from the surplus energy for other drives by interconnecting intermediate circuits. With ECAM-4 virtual energy interchange is also possible by means of the so-called DC bus. A new calculation with interconnected intermediate circuits yields the following: Interconnecting several drives via the DC bus leads to energy saving as less power needs to be taken from the mains. The energy loss via the internal braking resistor is reduced and, as a result, the external braking resistor is not necessary any longer. This clearly demonstrates the benefits of a holistic support of engineering with ECAM-4. And since the electrical dimensioning can also be done via the power circuit dimensioning, the interconnection of several axes via the DC bus in a complex project can be tested in the software in advance. Thus, the optimal DC bus interconnection can be determined. ECAM-4 also enables both the electrical and mechanical dimensioning of the new PacDrive iSH servo modules with integrated electronics. Based on an internal model, the tool calculates the necessary braking resistor power as well as the DC bus current at the power supply output and the mains currents necessary for dimensioning the mains filters and mains contactors. 3.6 Closely coupled engineering A further critical factor during the OEMs engineering process is the close cooperation between the different engineering disciplines, in particular at the interface between mechanical and software development. Modern engineering processes require these disciplines to pull together; ECAM-4 supports this interdisciplinary cooperation. The tool provides the software engineer with all the motion data compiled and defined by the mechanical engineer. The cam designed by means of ECAM-4 and compliant with VDI2143 can then be executed on an axis in the IEC project.

4. Motion design and drive sizing combined in a homogenous process With the VarioCam-Editor ECAM-4 the engineering toolkit for PacDrive provides a combined tool both for motion design and drive sizing for complex multi-axe systems. The tool enables the systematic solution for motion tasks for multi-axe systems on a graphic-oriented HMI. Positions, velocities, and accelerations are visualized; fast approximations of projected solution approaches are just as possible as the exact calculation of motion profiles. The possibility of running through various settings with differing laws of motion allows for an optimization based on different aspects. At the end of the process the complete movement and all the necessary data for the

practical implementation are available. In addition, the detailed project printout lists all the data on the selected motors, drives and gears necessary for the order process.

5. Basis for further optimization In the era of mechatronics, efficient development tools can only evolve with a holistic approach to engineering. The OEM can leverage suitable tools for reducing engineering time and cutting engineering costs. After all, it is only with this approach that the end users demand for flexible, dynamic and optimized machines can be satisfied with appropriate effort. The close cooperation of the engineering disciplines in particular remains a great challenge. Not only do different mind sets and approaches meet at the interfaces but also do the disciplines often use different lingos. This definitely leaves room for future improvement.

6. Sources VDI2143 Bewegungsgesetze fr Kurvengetriebe, Theoretische Grundlagen [Motion rules for cam mechanisms, theoretical fundamentals]

iSAS Integration of Engineering, Initial Operation and Maintenance


Dr. Thomas Dreyer, Aucotec AG, Production CAE Andrea Schrder, FGH e.V., dpt. Power Equipment Technology

iSAS die Integration von Engineering, Inbetriebnahme und Wartung


Die gegenwrtige Situation in den Bereichen Engineering, Inbetriebnahme und Wartung in der Elektrotechnik ist durch einen weitgehenden Mangel an Informationsintegration gekennzeichnet: Insbesondere fr die Inbetriebnahme und Wartung gehen aktuelle Erfahrungen de facto meist verloren, oder werden nur unzureichend dokumentiert. Das EU-Projekt S-TEN wurde initiiert mit dem Ziel, das Semantische Web fr naturwissenschaftliche und technische Applikationen zu nutzen und die heute fehlende Informationsintegration bereitzustellen. Die in dem Projekt entwickelte Technologie soll auf ihre Praxistauglichkeit hin berprft und gegen die prototypische Implementierung eines intelligenten Service-AssistenzSystems (iSAS) getestet werden, das den jeweils fr Inbetriebnahme oder Wartung Verantwortlichen effektiv untersttzen soll. Schlsselworte: Semantisches Web, best practise advice, prventive Wartung

Task Description

At present, the fields of application of engineering, initial operation and maintenance in the domain of electrical engineering are dominated by a lack of information integration: Especially, for initial operation and maintenance, not only this information integration is missing, but most actual experiences are lost or are at least inadequately integrated into the overall system documentation, and are, at least, not easily accessible in their context in comparable situations. Yet, a far reaching integration of all available data, the context in which they occur, and the capability to interpret them in a semantically correct way, are pre-conditions for a support of more advance approaches like context sensitive decision support or procedures to support failure prediction and preventive maintenance. S-TEN, an EU project initiated 2006 (FP6-IST-2005-027683, www.s-ten.eu) with the aim of using the Semantic Web for scientific and technical applications, and provided with the potential to enact the information integration missing today, was created not the least to deal with such limitations, and to support decision-makers in constantly changing technical environments. To evaluate project results concerning validity and practical relevance, S-TEN has made provisions for prototypal implementations of its technology: In this presentation,

the outline of a prototypal implementation of an intelligent service assist system (iSAS) will be presented. Based on high quality engineering data, it supports initial operation and maintenance through integrated access to design information, product data, instruction manuals, maintenance guidelines, and actual and historic system states. 2 State of the Art

The present situation in the fields of application of engineering, initial operation and maintenance in the domain of electrical engineering is, as already stated, dominated by a lack of information integration within and, especially, in between these domains. There are, in the field of engineering (ECAD world), trends to further Web integration and to advance documentation integration, to offer documentation suitable for production, and to condition available documentation for initial operation and maintenance; but, a real interlocking of operation and maintenance is not a given fact, yet. Rather, a traditional separation of these domains can still be observed today, to such a degree, to rightly speak of worlds apart. In operations, data access and data history are usually based on proprietary solutions often using OPC. Rudimentary, automated decision support is offered based on proprietary approaches; but, similar support systems for initial operation and maintenance, especially, from point of view of integration of engineering, design and operation information, are not available, yet. Early attempts towards preventive maintenance are still in their infancy. In particular, for initial operation and maintenance it can be stated that current experience is often lost or only insufficiently documented or is, at least, not easily accessible in its context in comparable situations. Yet, a real integration of all information of use for initial operation and maintenance, and a capability to interpret it semantically, is a necessary pre-condition for a sound basis for preventive maintenance and rule based decision support. 3 EU-Project S-TEN

S-TEN aims, in an environment of constantly changing networks of data sources and devices, to give these individual objects an individual presence on the Web or intranet with the capability to describe themselves, and to publish their data in a semantically interpretable form. This includes technical and administrative data, e.g. besides information about the data offered, also, access paths to offered services and its specifications. Because of a potentially large structural complexity of the data sources in question in principle, behind such an object even a complete plant may be hiding this may mean to access rather voluminous engineering information. To enable this in a semantically interpretable way, the creation of a bridge between two worlds apart up to now, OWL (Web Ontology Language) and STEP (STandard for the Exchange of Product data, ISO-10303), is part of the project plan, too. By applying formal rules and process knowledge to the semantic data published, decision and ' best practise support may be offered, and preventive maintenance

may made available without recourse to central, proprietary data-bases. By offering these technologies, S-TEN (FP6-IST-2005-027683; duration: 1st of April 2006 to 30th of September 2008) lays foundations for technical an environmental applications, suitable to overcome those restrictions and limitations stated above. To test project results for validity and practical relevance, S-TEN has made provisions for prototypal implementations of its technology in a showcase Demand Side Bidding and in four different application domains: 4 Environmental monitoring, control in distributed electrical networks, Secondary control in electrical networks, and initial operation and maintenance in electro-technical systems. Intended Results

Subsequently, the most important results reached or still to be met shall be presented with special emphasis on an outline of a prototypal implementation of an intelligent Service Assist System (iSAS) designed for the domain of initial operation and preventive maintenance.

4.1

Short Description of Results S-TEN Wants to Achieve

S-TEN aims to use the Semantic Web for scientific and technical applications, and to support persons in charge in bringing about a decision. In this it is supposed, that decision-makers in charge are confronted with constantly changing technical environments. Structures for a formal description of information are cast in the Semantic Web into so-called ontologies. As specification language to describe such structures, OWL (Ontology Web Language) is used. S-TEN enhances international standard ontologies already in use to make them fit for self-describing intelligent networks used for scientific and technical applications. In the framework of S-TEN, the preconditions for a definition of formal rules to support system operations are developed. On this basis problem related rules can be formulated and applied to data (measurements, human observations and design information) published in the Web. Essential in this context is that the available data does not have to be stored in a central data-base, but are associated with intelligent nodes capable to make their existence known individually. Besides, they are capable to publish their data and offer their services. In this way needed information is available in its context, and can be accessed by search engines. Should a specific event occur in such an environment, then, based on configurable rule systems e.g. an alarm could be raised automatically, and, based on information made available in its respective context, a well founded decision could be taken. The

currently valid state of the network under consideration would be included in this process. 4.1.1 Enhancement for AIDC Devices S-TEN ontologies are suited well to use them for storage of data on AIDC (Automated Identification and Data Capture) devices (bar-codes, smart cards, RFID, and so on). E.g., information about the role of a device within a network or historic data could be stored on a AIDC device , and, data made available in the Web could be updated by data stored on the AIDC device. 4.1.2 Bridge between OWL and STEP An important part of S-TEN is the intended creation of a bridge between STEP and OWL which were completely apart up to now. In this context, special emphasis is given to Life Cycle Support, assembly structures, and electrical connectivity. It should be pointed out that mere access to domain knowledge laid down in STEP application protocols is by itself important. Especially, for the iSAS prototype, data modelling and application experience laid down in AP239 (Life Cycle Support) should prove to be useful. 4.1.3 Innovations Aimed for and, partially, already achieved innovations of S-TEN can be summarised as follows: Definition of an ontology to enable arbitrarily complex data sources to make their existence, role, and position known within a network of other data sources, including functionality offered by them. Definition of an ontology to enable recording of human observations, their semantics based interpretation, and availability for automated processes. Development and application of rules to offer support in decision-making processes and other system operations (process supervision, preventive maintenance, decision support, ...). Bridging STEP and OWL, and use of STEP domain knowledge within planned prototypal implementations.

4.2

Prototype Description

The prototype presented in this paper is meant to enable an initial operation or maintenance engineer or technician to get, independent of his location, integrated access to design information, product data, instruction manuals, maintenance guidelines, and actual and historic system states. Designed to improve on initial operation and up-time, it attempts, not the least by recognition of comparable

situations of the past, to offer best practise advice founded on semantically interpretable information, and on rule based diagnosis or prognosis. 4.2.1 Overview ISAS implements in its core, as most important component, a S-TEN Network. Its core functionality is presented in the following Use Case Diagram:
Use Case Diagramm
S-TEN System Registration Registry Security <<include> <<include> Data Management <<include> <<include>

<<include>

Notification Data Source External Systems Event Handling

Data Source Manipulation

Figure 1

Use Case Diagram S-TEN Network

The fundamental idea behind a S-TEN Network is that all Data Sources e.g. after being switched on register within the S-TEN Registry, to afterwards enable External Systems to find them and to use registered Data Sources based on the spectrum of services offered to them. The following actors interact with a S-TEN System: Registry: The Registry stores information necessary to select and access services offered by S-TEN Systems. It checks periodically if the registered Data Sources are still active. Data Sources no longer active are deleted from the Registry. The Registry itself is based on a semantically annotated Web Service and a semantically annotated XML schema against which all information sent for registration is checked.

External Systems: Applications which are able to access Registry information, and are then, subsequently, able to interact with a S-TEN System are considered to be External Systems. Data Sources: Any data source which is administrated by a S-TEN System, and is accessible through the services offered in the Registry. A Data Source may offer control functions, too, but is not able to consume itself services offered by a STEN-System.

Against this background, a S-TEN System is a kind of interface between External Systems and Data Sources that may offer, in addition to data services, control functionality, too. 4.2.2 Technological Aspects From a technological point of view, iSAS comprises three main components: 1. Client application: The client application is based on an Eclipse rich client and comprises, in form of plug-ins, all components necessary to access the Registry, to browse its content, and, finally, to interpret the selected content in a correct way, access the server installation and all its modules, to interpret the accessed data correctly, and, where necessary, to present them, and to combine information drawn in a foreseen way to support the user.

2. Server installation: The different modules of the server installation - in its core the S-TEN System above - are partly accessed, like the Data Source services, via semantically annotated standard Web Services based on SOAP and SAWSDL (http://www.w3.org/TR/2007/REC-sawsdl-20070828/), partly via standard HTTP. The standard HTTP channels serve to transfer STEP data, SVG files (schematics) and product and maintenance information laid down in diverse standard formats like pdf, if they are not stored in the STEP data-base. Axis is used as middle-ware for standard Web Services. Security is based on WS-Security as implemented in Axis2. 3. Registry application: The Registry application uses semantically annotated standard Web Services, too. The data model for S-TEN System data stored in the Registry is based on an XML schema that is semantically annotated; this offers the advantage to combine semantics with conformity check and flexibility in a simple way. As middle-ware for Standard-Web-Services Axis2 is used here, too. In the same way, the security concept used, is based on WS-Security. All databases that support XML data types can be used. 4.2.3 Modules

The server installation physically not restricted to only one server comprises the following modules: Data Sources service module: Enables access to actual and historical data using semantically annotated standard Web Services. This includes control data flows, too. Internal access, e.g. access to PLC or sensor data, is carried out using locally available access software, e.g. using OPC. Life Cycle Support module: Operates on a STEP data-base and supports access, storage and interconnection of Life Cycle Support and design information like connectivity and product structure data as far as available on STEP side. 3D model module: Operates on a STEP data-base, too, and supports access, storage and interconnection of 3D design data with data from the Life Cycle Support module. Also, an interconnection with documents served by the document server module is, based on annotations, possible. For SVG documents navigation via editable links and, as far as available, common identifications is possible, too. Document server module: The document server module serves to offer and transfer documentation in various standard formats. Documents conforming with the SVG specification, allow for navigation and interconnection with product data. Based on availability of mapping tables, these documents allow for display of actual and historical measurement data attached to their respective resources. Conclusions S-TEN

5 5.1

The predecessor of S-TEN, ScadaOnWeb, has contributed to OWL version ISO 15926-2, and, by defining ontologies for engineering data, it helped advance the development of the Semantic Web. Beyond that S-TEN will create foundations for self-describing systems and decision support. In addition, S-TEN aims to close the gap between STEP and OWL, to create a bridge between these worlds up to now apart, and make domain knowledge up to now confined to the STEP world available to integrated Web applications. Finally, S-TEN aims at offering support in the decision making process within constantly changing technical environments. Technologies created by S-TEN will be tested in four different scenarios to prove their validity and practical relevance, and to confirm the feasibility of decision support in an environment of complex and constantly changing networks of data sources. 5.2 Integration of Engineering, Initial Operation and Maintenance

This contribution presents an outline and first steps towards a prototypal implementation of an intelligent Service Assist System (iSAS). Based on technologies created or on the way to be created by S-TEN, iSAS is on one hand a further step towards an integrated platform for all available information of an electrotechnical system or plant from engineering to realisation, operation and

maintenance - and, on the other hand, a first attempt to offer decision support based on detection of comparable past situations, semantically interpretable information, and rule based diagnosis and prognosis.

The S-TEN project is partly funded by the European Community in the framework of Information Society Technologies (IST) FP6-IST-2005-027683.

Integrating Real-Time Ethernet in Injection Molding Machines


Dipl. Ing. (FH) Werner Faulhaber, ARBURG GmbH + Co. KG, R&D Dept. Electrical Engineering

Integrating Real-Time Ethernet in Injection Molding Machines


The injection molding process requires an extremely close linking of measurement values such as axis positions, speed/rpm, pressure/force and temperatures, etc. These values must be read and processed in each cycle within 100s. Just one missing data transmission can lead to rejects or in extreme cases, damage to the machine or tool. Bearing these aspects in mind, what specific selection criteria were applied to achieve the right real-time Ethernet system for injection molding machines? High Performance, low costs, VARAN

1. Motivation As generally seen in automation technology, a combination of various interfaces is also found in injection molding machines. Drive interfaces such as SERCOS I & II, field bus systems like CAN, PROFIBUS and INTERBUS-S as well as companyspecific protocols based on RS232/422/485 are often used for internal communication. In an area where process data must be transferred in the 100s range or only analog measurement values are available, analog interfaces are still state of the art technology. Over these various connections, machine controllers communicate directly with the connected sensors, actuators or periphery on the lowest level of the automation pyramid. At the upper levels of this pyramid (cell control, control panel), the controls are normally connected over Ethernet. To establish continuous communication over all levels of the automation pyramid, they must be connected using Gateways. In relation to performance and costs, this is always a compromise. With the use of an industrial Ethernet system, a continuous and performing system offers vertical integration communication from the process control level down to the field level. A prerequisite is the selection of the optimal real time Ethernet system. The focus here is not only on a clean cross over of IP20 office technology to the raw world of the IP65/IP67 industry environment since, in the mean time, 21 different solutions for industrial Ethernet systems are known. For one of the leading and internationally successful producers of high-tech injection molding machines, the highest level of technical design with the goal of securing the future through innovation is a must. What did the specific selection criteria for the right real time Ethernet system for use in injection molding machines therefore look like? Which priorities were set and what compromises had to be made?

2. State of the Art Technology The injection process requires an extremely tight connection between measurement values such as position, speed/rmp as well as pressure, force, temperatures, etc. These values must be read and processed cyclically within a period of only 100s. Production cycles of under two seconds and a total injection time for plastic materials, which is frequently under 100ms, require dynamic actuators, sufficiently fast and accurate sensors, quick data transfers and precise regulation with cycle times of 200s. In the injection molding machine, the process is based on the control of three principle axes: injection, dosing, and mould clamping as well as two secondary axes: ejector and jet nozzle. Expanded with a multi-component format, core pullers and an integrated robot system, typically not more than 16 axes are employed that must be coupled in hard real time. One missing data transmission can already lead to rejects or, in extreme cases, damage to the machine or tool. Operating in harsh environments, high shock, vibration and electrostatic discharge caused by processing plastic material places high demands on the system communication as well as on the connections.

2.1 Definition of requirements for real time Ethernet in the injection molding machine For injection molding machines, there is a limited spectrum of sensors, actuators, safety devices and control elements as well as a number of branch-specific periphery modules that must communicate with the control in real time. This results in requirements that can sometimes be used throughout the entire industry and some that are branch specific.

2.1.1 Environmental Conditions High stress such as shock (20g), vibration (5g), and operating temperature ranges from 0 to > 60 C with passive cooling as well as IP65 / IP67 protection, dust contamination (partial electrical conductivity), humidity, moisture, industrial oil and aggressive gases place high demands on components, housings and connection technology. Static discharge caused by the plastic granulates fed through the machine as well as pulse-formed network disruptions and large E or M fields caused by pulsed mold heating or hot channels, for example, require a EMC tolerance that exceeds the standard industry requirements. The applicable standard EN 61000-6-2 industry area (EN 61000-4-2 to EN 61000-4-8 and EN 61000-4-11), for example, is expanded to values that are significantly higher than test level 4. For these tests, the evaluation criteria A (at surge B) are used. The EN 61000-6-3 standard for devices in residential, business and commercial areas or information technology equipment (EN 55022) is used for interference emissions. For self-designed control electronics, a response at least 6dB under the limit class B is required. The lifespan of the device is > than 10 years or > 40,000 operating hours under the conditions described above.

2.1.2 Installation Requirements, Topology The wiring and therefore the construction of the network are machine-specific. For smaller machines, a topology that is wired in a star configuration from the control (master) to the various axis modules would be the obvious choice. For electrical drives, a local linear structure is employed. Intermediate connections and wall bushing were deliberately excluded with these machines. The connection to the sensors and actuators is made over hybrid lines that contain the power supply as well as the bus lines. To conserve space, a maximum of ONE connector per sensor or actuator is used. Also for space and cost reasons, existing components such as CPUs, drives, etc. in the IP20 world should be expandable with the distributor function. For larger machines, the star topology is expanded. Using a star distributor, the axis modules can be distributed further over various function blocks to a tree structure.

2.1.3 Data Transfer Requirements: Speed isnt everything When one compares the current real time Ethernet systems, the differences in performance are grave, despite the standard use of Fast-Ethernet (100 Mbits/s). To control dynamic axes, smaller data packets have to be transmitted cyclically and as jitter-free as possible. Great value must be placed on isochronicity and network availability. For inter-processor communication, simple cross traffic is desirable. For an electrical injection axis, a 200s cycle, 22-byte set value and a 12-byte actual value is exchanged in the position control for example. When summed, the result is 34 bytes of isochronous data. All additional axes such as dosing, mold clamping and nozzle as well as the ejector, form height, core puller and robots with 1 to n axes have a comparable data streams but can be regulated in a slower cycle (i.e.1 ms). Peripheral devices such as Piezo load amplifiers, DMS and temperature amplifiers have similar performance requirements.

2.1.4 General System Requirements and Summary As a manufacturer of control electronics, the need for an open manufacturerindependent system is of the highest priority. Manager/Master as well as Client/Slave must be available from several manufacturers or implementable as firmware in an FPGA. For the slave module: space requirements and connection costs must not exceed present levels. The data transfer technology must be robust, which means erroneous data transmissions are repeated within the same cycle, if required. Standard safety requirements such as watchdog must be integrated. Downloading or system booting and software updates should also be possible over the network. For diagnostic purposes, direct access to each intelligent station should be possible (with a laptop and the corresponding software),

independent of the network status. Required are: simple addressing without rotary/dip switch or an IP address for every station. Flexibility in the selection of topology according to the application requirements and expansion possibilities such as hot plug and play are additional criteria. Known device profiles (such as CANopen) should be accessible for fast and simple integration of new stations and modules. Simple connection to the main level over a standard Ethernet port should be possible and the dialog must be transparent from above to below. However, a standard Ethernet participant connected (unintentionally) to the system must not be able to affect the real time communication. The bundling of these requirements in a user organization is important. This means real opportunities to participate in a strategic development of the system through the members.

3. VARAN As an Effective Ethernet System for Injection Molding Machines

3.1 An Open System Managers as well as clients or splitters/hubs are available as source code for FPGAs from various manufactures (currently XILINX and ALTERA have been tested). The VARAN Manager sees all bus stations as a 4-Gbyte memory space. Each station is allocated a 64 Kbyte memory area max. 65.000 participants.

Fig. 1: VARAN manager address area

The programming is compact with only 9 simple memory read/write instructions. The tight protocol is executed without the so-called padding bytes and ensures high net transfer rates.

Fig. 2: VARAN layout with reduced frame

Without the SOF and EOF identifications added by the PHY, the VARAN frame header consists of only 5 bytes including the CRC. To ensure efficient use of the commands, standard read/write instructions and combined commands are available. The user requires only one instruction to operate the VARAN components. In addition to the optimized frame construction, the short commands can be sent in three priority stages.

Fig. 3: Priority levels of the VARAN data transmission

The isochronous task, which starts at the beginning of each cycle, has first priority. In this task. control and time critical data are usually sent. The asynchronous task starts directly after the isochronous task and is used for non-critical data or slow sensors. During the lowest priority task, the administration task, miscellaneous tasks such as scanning for new stations or transfer of Ethernet IP cross traffic data is executed. To guarantee lowest bus cycle times, long TCP/IP cross traffic data is divided into small sections of up to 128 bytes and sent piecewise. Because no definite time frame must be specified for the administration task, significantly lower cycle times can be set despite TCP/IP cross traffic unlike in other Ethernet systems. Further, asynchronous direct access to a station can be obtained at any time using the Direct Access, which interrupts all other tasks. Mathematically (including runtime over hubs/splitter and cables), 512 bytes can be transmitted in a 200 s cycle with a bandwidth of 50% for isochronous data with VARAN. The fast injection axis represents a 6.6% busload with a 34-byte data stream (see 2.1.3). Normally no more than 50% of the bandwidth should be used for isochronous data. The remaining time is needed to transfer asynchronous data as well as administration tasks and to use a special feature of the VARAN bus: The ability to

repeat erroneous data transmissions within the same bus cycle. If a command is not answered within a certain period of time, the manager repeats the instruction immediately. At the end of the bus cycle, the data is always up-to-date and consistent. This significant advantage, which no other real time Ethernet system can claim, is an important criterion for selecting the right bus system.

Fig. 4: Data repetition within one cycle

The topology can be freely selected (star, tree, line or a combination thereof). The system boots over the network and each station has a data plate with - Vendor ID (manufacturer ID) - Device ID (product ID) - License number (unique) - Station-specific data (Data sheet, calibration data, etc.) The license numbers are given by the VNO (VARAN BUS USER ORGANISATION) and are subject to a minimal fee. The VARAN Manager addresses the stations automatically. With star configurations, however, special VARAN splitters must be used in which each port is clearly identifiable (automatic addressing with standard Ethernet is not possible). Connection errors or incompatible stations are identified through the data plate. Each station knows its neighbor. Non obligatory stations can therefore be added or removed during operation. In the administration task, new stations are identified and can then be addressed and linked (i.e. cavity pressure, temperature module, robot or additional injection axes). If an obligatory station is removed, an error message is generated for the application and safety measures can be taken. A disadvantage that must be mentioned is that because the narrow manager client structure with VARAN, cross traffic between the clients can only run over the master. This results in a higher date stream and a delay of one cycle. The effectiveness of the system is therefore dependent on the structure used, the number and size of the data blocks as well as the rate of the cross traffic. To implement the VARAN bus in components as fast and easily as possible, a CANopen image is processed in the VARAN bus in conjunction with the CiA. Existing design work can therefore be efficiently reused and the time to market is significantly reduced. Since the send via CAN instructions must only be replaced with write to VARAN memory, the programming time is short.

3.2. Connectors One of the goals of the VNO (VARAN BUS USER ORGANISATION) was the development of sensible connection technology which has already been implemented consequently. The requirements were derived from environmental circumstances and the structural properties of the machine: Contact safety IP65 / IP67 protection class Cable (field-)configurable and can be sprayed Integrated power supply for peripheral modules in the bus cable Various classes, 2A, 5A with secure layout Space saving and rotatable in </= 90 steps Inexpensive

Fig. 5: Hybrid connectors from TYCO, 5A per power contact, for hydraulic control valves or distributors

3.3. Examples of Possible VARAN Stations in a Standard Injection Molding Machine: In addition to existing components such as drives, measurement systems, hydraulic valves/pumps and I/Os, charge amplifiers and additional sensors will become available shortly. So components for all requirements of injection molding technology are available with VARAN bus connection.

3.4. Topology with VARAN System Components

3.4.1 Injection Molding Machine Topology

Fig. 6: Example of a VARAN topology: a typical injection molding machine

4. Conclusion VARAN offers a streamlined protocol with sufficient performance reserves for the future. The low costs for client modules allow network extensions up to simple 1-bit sensors. The hardware solution in the FPGA provides independence from manufacturers; complex drive software is not necessary. Secure data transfer and clean, defined connection technology qualifies the system for harsh industrial environments. The addition of power supply lines for sensors and actuators in the bus cable reduces the number of cables needed and makes the components more economic. The possible combinations of the topologies allow the configuration of a real time network without address switches. The VARAN bus can therefore be customized for any machine requirements. Market leaders in the European injection molding branch such as ARBURG, DEMAG, and KRAUS-MAFFEI have chosen the VARAN bus. This will automatically evolve into a standardization of branch-specific interfaces (from module profiles to connection technology). Module profiles were created and module groups such as managers, clients and splitters as well as sensor and actuator components are available.

Modularity in machinery
Dipl. Ing. Marcus Finkbeiner, technical sales manager at Baumller Nrnberg GmbH

Modularity in machinery
By making machinery modular, machine builders benefit from greater flexibility as regards the further development of their existing systems. Having a distributed configuration essentially makes it possible to break the machinery down into mechatronic units that can be logically mapped by means of software templates. However, the implementation of flexible machine concepts often hits a brick wall due to insufficient subject-specific knowledge on the part of machine builders. Normally, and particularly in the case of centralized machine architectures, if changes are to be made to machinery functions or if the machinery is to be expanded, the programming code has to be completely revised. Yet machine builders have to be able to implement expansions quickly so that a flexible response to customer requirements can be ensured. Within this context, a distributed configuration (i.e., a structure consisting of logical units) becomes essential, and this can itself only be achieved if the machinery is broken down logically into modules. In many sectors, machine builders still lack the relevant know-how and experience that is required to implement distributed solutions. One of the primary causes of major problems (from all kinds of perspectives) is the process of mapping the modularity within the software. Mechatronic, software, modules, decentralized architectures

1. The problem Normally, and particularly in the case of centralized machine architectures, if changes are to be made to machinery functions or if the machinery is to be expanded, the programming code has to be completely revised. Yet machine builders have to be able to implement expansions quickly so that a flexible response to customer requirements can be ensured. Within this context, a distributed configuration (i.e., a structure consisting of logical units) becomes essential, and this can itself only be achieved if the machinery is broken down logically into modules. In many sectors, machine builders still lack the relevant know-how and experience that is required to implement distributed solutions. One of the primary causes of major problems (from all kinds of perspectives) is the process of mapping the modularity within the software.

2. Using modularization to tackle the problem Decentralized architectures are the key to flexible machine design. If a machine is broken down into mechatronic units, software templates can be programmed for these units relatively quickly, easily, and cost-effectively. In this context, an awareness of which mechatronic units are reasonable and to what extent the machine is to be modularized is vital, as this can vary according to machine type. 2.1 Example: Functional description This paper uses the example of an injection molding machine to explain which functional units can be modularized. Injection molding is used to manufacture molded-plastic components such as casings for cell phones, for example. Up to six electrical axes are driven in a machine for this purpose. The required product shape is created by injecting molten plastic via a screw into a mold which is the inverse of the products shape. The machines various motional sequences can be grouped into process stages: The injection process itself consists of plasticizing the material and injecting it into the mold. A single motion definition can be used to close the mold and set the mold height. Once the plastic has hardened, the finished part is ejected (Figure 1).

Figure 1:

How an injection molding machine can be broken down into mechatronic units

2.2 Mechatronic modules It makes sense to break down the modules on an injection molding machine on the basis of injection unit, closing unit, and starting unit, as well as core pullers and core lifters. If each of these mechatronic modules is mapped in a dedicated software template, numerous variants can be generated, in order to implement rotary indexing or multi-station transfer machines, for example. Machine builders can use the resulting modular building block system to customize the design and construction of machines to meet prevailing requirements, thereby facilitating a flexible response to both the manufacturing process and the requirements of their customers (Figure 2).

Figure 2: The modular mechatronic building block system: How predefined modules can be used to implement various types of machine

The functional units have to be bundled sensibly for the control engineering. A mechatronic unit is created by combining motors, the encoder system, pressure sensors, and any limit switches that might be in use in other words, the mechanical system plus the control elements in the control cabinet. All that remains is the relatively quick and easy task of generating a software solution for this unit. Individual motion cycles are archived in libraries in the form of predefined templates and can be retrieved for reuse at any time.

2.3 Software blocks In order to build a machine based on a modular structure, you need to break your mechanical system down into mechatronic units. Furthermore, the modularization must be reflected in the corresponding software. In principle, any motion cycle can be mapped as a basic structure in software blocks. One machine functional unit is mapped to each software block. Each functional unit has a request module, a safety module, an execution module, and an I/O assignment list (Figure 3).

Figure 3:

The structural software architecture of the machine

The global control configuration is stored on a main controller superordinate to the functional units. The controller has a request processing center and a safety monitoring facility. The request processing center uses a multi-dimensional tabular system to manage pending tasks. The safety monitoring facility uses the same technique to verify whether the requested motion can be executed. To do this, it polls specific conditions such as whether all safety doors have been closed.

Another superordinate level is the configuration part. This is where the user stores the quantitative data and the function groups (options) existing on the machine in the form of a list. Various functional units can be added to the list manually. Every time the machine starts up, the list is processed and a check is carried out to see if new functions have been integrated in the machine, for example. Once the check is complete, a decision is made as to whether an execution module will be addressed by the request module (Figure 4).

Figure 4:

Configuration lists for each machine and mechatronic unit

Ready-made templates are added at configuration level. As a result, programming becomes much easier because there is no longer any need to reprogram everything whenever a change is made. Since the configuration units are more flexible, machine builders too can be more flexible in their response to changes in customer requirements by simply changing the configuration list accordingly (Figure 5).

Figure 5:

Fixed assignment in the software part (template) and modular crosslist for hardware

All the execution modules (?) required are stored in the software. Flexible I/O assignment makes it very quick and easy to link the modules. This is important in many regards, but not least for modularization of the I/O assignment and, thus in turn, for the wiring and the modular control cabinet layout.

3. Summary Since, on todays market, the demand for custom solutions far outstrips that for standard products, machine builders and automation suppliers need to show their mettle in this crucial sector. Decentralized machines broken down into modules and mapped in corresponding software blocks make solutions more flexible and increase individuality. The reuse of tested and stable blocks increases planning security and speeds up installation and startup. Less complexity means more machine usability.

IO-Link Communication at the Lowest Field Level


Dipl.-Ing. Christian Gemke MSc, Phoenix Contact GmbH & Co. KG, Automation Systems, Blomberg, Germany

IO-Link Kommunikation in die unterste Feldebene


Die Kommunikation zu dezentralen Peripherie-Gerten wie I/O-Stationen ist Stand der Technik. Die proprietre Umsetzung der Kommunikationsschnittstellen zu Sensoren und Aktoren erfllt allerdings nicht die Anforderung an eine durchgngige Kommunikation und Parameterdatenhaltung sowie ein einheitliches Tooling. Die fehlende Kommunikationsschnittstelle stellt ein Innovationshemmnis fr die Sensor/Aktorwelt dar. IO-Link lst das Kommunikationshemmnis bis in die Sensor-/Aktorebene als einheitliche Schnittstelle. Die fehlende system- und netzwerkunabhngige Engineering-Plattform schaffen FDT-basierende Konfigurations- und Diagnosetools wie der AutomationXplorer+. Entsprechende Gateway- und Endgerte-DTMs erstellen die durchgngige Kommunikation von der Leitebene bis zur Sensor/Aktorebene fr Kommunikationsstrecken, dezentrale I/O-Stationen und IO-Linkfhige Sensoren und Aktoren.

IO-Link, Software-Integration,

Introduction

Machines and systems are increasingly using the option of distributed "intelligence". One possible location for intelligence and increased functions is the actual sensor or actuator. The challenge is therefore to provide suitable communication paths that enable the systematic use of functions in the lowest field level. To guarantee a high level of both manufacturer and user acceptance, the usual features of machine installation must be ensured, such as: Free selection of the fieldbus system Good coverage of device functions Wide choice of manufacturers Easy installation Compatibility with the established standard

The operator interface in particular, i.e., integration in engineering tools, is one of the key factors for acceptance.

The Current Situation

What facts encourage manufacturers and users to tackle the next communication hurdle? On the one hand, their familiarity with fieldbus systems such as INTERBUS as well as dealing with Ethernet-based automation systems such as Profinet has given a new meaning to the motto "Increased productivity through improved integration and more information".

Figure 1: Seamless communication from the control level through to the sensor/actuator level

Previously it was virtually impossible to transport this amount of information via fieldbus systems and to process the information in control systems, but this can now be done very easily using Profinet and by integrating FDT/DTM technologies in engineering systems such as PC Worx.

2.1

Information

What information does the IO-Link interface provide? How is it forwarded and how does the information increase productivity? The installation topology of sensors and actuators under established networks now includes a variety of different I/O modules with various cable specifications. A binary switching sensor or actuator with a 3-pos. sensor/actuator cable (SAC) is easy to install. However, as soon as the number of signals to be transmitted from or to a

device increases, IO-Link considerably simplifies installation. For example, when installing a valve island with a multi-pos. cable or a complex cam controller, up to 32 individual wires have to be wired and diagnosed in the event of any damage; IO-Link performs this task with one 3-pos. SAC cable and by exchanging just one telegram. This installation advantage can also be transferred to the communication of analog values. For many sensors, the measured information of the physical sensor structure is already available in digital format in the device. Using the latest transmission principles this measured value is converted into a standardized analog signal (e.g., 4 20 mA), then transmitted using shielded cables, and the signal is converted back into a digital value at the distributed I/O device. Of course, a high level of data loss can be expected due, for example, to conversion inaccuracies. Using IO-Link technology, the measured value is exchanged in a telegram between the sensor and master, whereby transmission inaccuracy is eliminated by the data backup mechanisms of IO-Link communication. The measured value produced by the physical measuring structure is present directly in the control system in uncorrupted form. The transmission capabilities of IO-Link are used here. Parameterization is not required.

2.2

Diagnostics

The advantages for installation are just one aspect. Communication through to the last element in the automation pyramid the sensor or actuator also provides more information about the diagnostic status. Depending on the telegram frame, optional data can also be exchanged parallel to process data. This can be either parameter data or diagnostic data. Clear diagnostic states for the entire machine or system can thus be mapped through to the sensor/actuator level. In this way, the availability of the automation network is permanently increased thanks to the option of preventive maintenance and servicing.

2.3

Parameterization

Due to communication methods such as IO-Link, the demand for clear parameter maintenance has finally been met. Although users are familiar with carrying out parameterization using manufacturer-specific hand-held devices or interfaces to computer systems, this does not offer a universal solution for handling different types of sensors and actuators, which are supplied by various manufacturers.

Figure 2: Integrated parameterization of the entire network

The connection of sensor/actuator devices to the automation network via IO-Link enables the devices to be integrated into parameter saving concepts in the overall system. Data backup mechanisms and methods such as multi-device configuration enable all the setting options available in the network to be handled centrally. The parameter status is thus clear.

2.4

Engineering

The illustrated advantages of IO-Link do not result in increased installation and startup effort for machines or systems. The baud rate and the correct telegram frames and data constellations are negotiated in the background between the master and device during startup. On this basis, sensors with parameterization properties, i.e., recipients of service data or producers of process data, can be implemented using just a few bits of user data. In addition, bundles of outputs or complex hybrids such as analog input data or binary I/O data can be mapped. The IO-Link devices are always compatible with standard sensors. Moreover, the IO-Link sensors can also be operated on standard digital input modules. When using the new standard, not all sensors used have to have an IO-Link interface, as hybrids are supported. The full forwards and backwards compatibility of IO-Link devices thus safeguards the investments already made by manufacturers and users.

Figure 3: Parameterization with generic description files

What level of effort are users expecting to encounter? In the simplest case, a user will need to import a description file (FDCML, GSD, etc.) for the IO-Link master in the engineering system, set the process data width specified by the manufacturer of the IO-Link device, and start up the system. Here, startup is barely more complex than for a standard I/O module. If there are higher application requirements regarding diagnostics and parameterization, more powerful tools such as FDT/DTM can be used with the same hardware structure. When using the PC Worx engineering system, the user can choose between flat engineering and easy startup with a limited scope of functions or full-graphics parameterization and diagnostics via FDT/DTM.

2.5

Application Advantages

The use of IO-Link results in two important application advantages: 1: Simplified assembly and reduction in cabling costs The cyclic transmission of complex signals, such as the distance signal of a laser distance sensor, in an IO-Link telegram via an unshielded 3-wire connection highlights the advantages of IO-Link over shielded transmission of a 0 - 10 V signal with all the complexities of shield connection and analog/digital conversion. In addition, a wide range of signal forms (input, output, analog, binary switching, etc.) are made available to the network.

2: More information and greater integration If the application has very high requirements regarding availability and flexibility and there is a readiness to incorporate more engineering, IO-Link is the ideal interface for a flexible machine design and preventive diagnostics. The recording of changes in the transmission quality, which is already possible in an INTERBUS system based on fiber optics, can also be implemented for sensors and actuators with IO-Link. If an optical data link is dirty or the pressure falls at a pneumatic element, this is indicated to the control level, enabling maintenance to be carried out before the unit fails.

Figure 3: Extent of application-oriented engineering for IO-Link

3 Summary The following points speak in favor of the use of IO-Link: Point-to-point connection between master and device Existing cable topologies are maintained, which means that no new network structures are required. In addition, the system can be retrofitted. Standard sensor/actuator cable No special cables are required for installation; standard connection methods such as M12 connectors are sufficient. Installation is carried out according to proven principles. Seamless communication Both process data and service data can be transmitted between sensors/actuators and the control system. The system image will be completely transparent for process and parameter data. Mixed operation supported Since full compatibility with standard I/O components is ensured, investments in standard technology are safeguarded.

Easy startup Storing parameter data in the control system and seamless handling with FDT/DTM simplifies and speeds up startup. As a result of its seamless integration in existing systems and the low level of effort required for device integration, IO-Link will become established as the new standard in the lower field level.

SISTEMA: a Tool for the Easy Application of the Control Standard EN ISO 13849-1
Dr. Michael Huelke, BGIA Institute for Occupational Safety and Health of the German Social Accident Insurance, Division 5: Accident prevention - Product safety Michael Hauke, BGIA, Division 5: Accident prevention - Product safety Jan Pilger, BGIA, Division 5: Accident prevention - Product safety

SISTEMA: ein Tool zur einfachen Anwendung der Steuerungsnorm EN ISO 13849-1
In der neuen Norm fr sicherheitsbezogene Steuerungen, EN ISO 13849-1:2006, werden bewhrte deterministische Merkmale der Kategorien und neue Anforderungen zur Ausfallwahrscheinlichkeit auf praktikable Weise miteinander kombiniert. Das BGIA untersttzt die Einfhrung und Anwendung dieser Norm durch die Entwicklung und Bereitstellung der kostenlosen Software SISTEMA. Das Tool untersttzt Maschinenhersteller, Steuerungshersteller und Prfstellen bei der Gestaltung, Integration und Bewertung von sicherheitsbezogenen Teilen von Maschinensteuerungen. SISTEMA nutzt dabei ein verfeinertes Verfahren zur Bestimmung von genaueren Kenngren der Ausfallwahrscheinlichkeit. Funktionale Sicherheit, Steuerungssysteme, Maschinen, Software Werkzeug

1. Background For well over a decade, safety-related parts of machine controls have been designed and assessed in accordance with the EN 954-1 safety standard. The need for greater consideration to be given to new technologies such as electronics and software necessitated a thorough revision of this standard. In the revised standard, EN ISO 13849-1:2006 [1], proven deterministic characteristics of the categories and new requirements concerning the probability of failure (service life of the parts, quality of testing) are combined in a practicable manner [2], [3], [4]. As early as the mid-1990s, the BGIA was successful in acquiring knowledge and experience of quantification and in applying it in the testing of safety components, for example by its involvement in the European STSARCES project (Standards for Safety Related Complex Electronic Systems) [5]. This expertise has resulted in crucial input and groundbreaking work for the simplified analysis methods employed in the revised version of the standard. These analysis methods and the handling of reliability data are still relatively unknown in machine construction. Despite simple approaches, they remain complex in practice. Owing to its prevention mandate and with the background knowledge

gained during the revision, the BGIA is therefore supporting the introduction and application of this new standard by developing tools and making them available free of charge. One such tool is the SISTEMA PC program for the safe control of machines, which will be presented here. SISTEMA is the German acronym for "safety of controls on machines". Essentially, the purpose of SISTEMA is to enable the probability of failure of control systems, whether planned or already implemented, to be analyzed quickly and easily. Besides enhancing acceptance of the new methods, structured user guidance is to assure complete, error-free application of the EN ISO 13849-1 standard. With plausibility and consistency checks and a three-level indicator system, SISTEMA contributes to the avoidance of user errors. The tool assists machine manufacturers, control system manufacturers and test bodies in designing, integrating and assessing the safety-related parts of machine controls. It addresses all relevant control technologies. SISTEMA was funded by the German Fachausschuss Druck und Papierverarbeitung". The requirements for the program were defined following systematic examination of the standard in its final form, and with the incorporation of experience gained with a software prototype developed beforehand. The various methods set out in the standard were to be modelled in the software such that users need only enter their data in manageable input dialogs, and the result would be calculated continuously. A further important requirement was the separation of the user interface from the database for projects, safety functions and components. Besides robust computing functions, user-friendly functionality was implemented, such as the results prognosis and a database for standard components and control systems which have already been analyzed. The serviceability of the software is enhanced by documentation of the results in a report and by the use of a "wizard" by which users are instructed in the software's use. SISTEMA is initially available in German. The English version currently under development, and preparation for further language versions, will however enable the software to be used internationally in the near future. Testers at the BGIA trialled the program by analyzing real-case control systems. In addition, many example circuits have already been analyzed and are to be published in a BGIA Report. 2. How SISTEMA works The SISTEMA software tool provides developers and testers of safety-related machine controls with comprehensive support in the analysis of safety in accordance with EN ISO 13849-1. The tool, which runs on Windows, enables its user to model the structure of the safety-related control components based upon the designated architectures, and ultimately permits automated analysis of the reliability values at different levels of detail, including that of the attained performance level (PL). Input dialogs are used for the step-by-step input of relevant parameters such as the risk parameters for definition of the required performance level (PLr), the control system category, the measures against common-cause faults (CCF) on multichannel systems, the average component quality (mean time to dangerous failure, MTTFd) and the average test quality (average diagnostic coverage, DCavg) of components/blocks. Once the necessary data have been entered into SISTEMA, the

results are computed and displayed instantly. A practical advantage for the user is that the effects of each parameter change upon the system as a whole appear immediately in the user interface. Users are spared virtually all the time-consuming searching in tables and calculation of formulae (calculation of the MTTFd by means of the "parts count" method, symmetrization of the MTTFd for each channel, estimation of the DCavg, calculation of the PFH and PL, etc.). This enables them to "experiment" with parameter values in order to assess the global effect of modifications at no great effort. The final results are summarized in an overview ready for printout. Even with analysis by means of a tool such as SISTEMA, however, the user still faces certain challenges which can be overcome only with practice and experience. Before SISTEMA can be used, the safety functions must first be specified and the actual structure of a safety-related control system must be modelled. This model is described as a safety-related block diagram. In practice, the actual structures cannot always be modelled by the architectures employed in the standards. Following modelling, a second challenge is that of obtaining all the necessary data relating to the probability of failure of parts. A reasonable diagnostic coverage (DC) of discrete measures must also be estimated properly, particularly with wide variation in effectiveness (fault detection by the process: DC = 099 %). 3. SISTEMA in use SISTEMA processes basic elements from a total of six different hierarchical levels: the project (PR), the safety function (SF), the sub-system (SB), the channel (CH)/test channel (TE), the block (BL) and the element (EL). Their interrelationship between these levels is summarized below (Fig. 1).

Fig. 1: The hierarchical levels considered in SISTEMA The user first opens a project, in which he is able to define the machine or hazard point which is to be considered in greater detail. All necessary safety functions are

then assigned to the project. These can be defined and documented by the user, and a PLr assigned to them. The performance level (PL) of the parameterized SRP/CS (safety-related part of the control system) which is actually attained is determined automatically from the sub-systems which, connected in series, execute the safety function. The sub-systems are in turn based upon a "designated architecture" from the standard, as a function of the selected category. Among other things, the architecture determines whether the control system is of single-channel, singlechannel tested or redundant design, and whether a special test channel must be considered during analysis. Each channel can in turn be divided into any desired number of blocks, for which the user enters either an MTTFd value and a DC value directly, or, on the lowest hierarchical level, the values for the individual components from which the block is compiled. 4. The SISTEMA user interface The user interface of SISTEMA is divided into four areas (Fig. 2). The greater part of the area is occupied by the workspace on the right-hand side. Depending upon which view is active, the workspace contains an editable input dialog, or a partial view of the overview document.

Fig. 2: The SISTEMA user interface

The content of the active view is determined by the basic element selected from the hierarchy described above (Fig. 1), and is selected from a tree view on the left-hand side. Each branch in the tree view represents one basic element. Basic elements can be created, deleted, moved or copied in the tree view. The details of the selected basic element are entered in the input dialog in the editing view. Each input dialog is sub-divided further into different areas by tabs. The final tab in each input dialog contains a table summarizing all lower-level branches and listing the main information. If, for example, the user has marked a block in the tree view, this table shows all elements contained within it, together with their MTTFd and DC values. The tree view also shows status information for each basic element. The status information takes the form of a coloured dot adjacent to the branch. A red dot indicates that a condition of the standard is not satisfied, that a limit value is exceeded, or that a general inconsistency is present owing to which a required value cannot be calculated. A warning is output in this case. Yellow indicates a non-critical message (e.g. a basic element has not yet been named). All other basic elements are marked green. The colour marking is also always inherited to the branches higher up in the hierarchy, red having the highest and green the lowest priority. All warnings and information concerning the active basic element are displayed in the message window below the workspace. The area below the tree view shows the main context information for the selected basic element. This information comprises the PL, PFH, MTTFd, DCavg and CCF of the higher-level sub-system, and the PLr, PL and PFH of the higher-level safety function (this applies, of course, only to basic elements which are on lower hierarchical levels). The consequences of changes in the displayed parameters are thus displayed continually to the user. In addition to its flexibility, the SISTEMA user interface is notable for its ease of use and intuitiveness. Context help facilitates familiarization. The wizard supplied with the application offers further help: it supports new users step by step in the virtual modelling of their control systems, and assures rapid access. 5. Interfaces to users' and manufacturers' databases User-friendly library functions complete SISTEMA's range of features. The libraries supplied with the software contain a number of standard elements, blocks and complete sub-systems. They can however be extended as desired by the user, for example to form a database for parts which are frequently used. If desired, further library modules can be installed retrospectively; these include project-specific and machine-specific libraries from machine manufacturers, containing re-usable objects. SISTEMA enables the user to toggle between different libraries. The user can exchange library files with other SISTEMA users and incorporate them. Component manufacturers can also support their customers by creating write-protected libraries containing the reliability data of their products. In addition, SISTEMA provides a number of libraries containing the technical and organizational measures necessary for analysis of a control system. These libraries primarily contain the typical and most frequently applied measures, such as those

contained in EN ISO 13849-1. SISTEMA manages the following libraries for this purpose: The library of CCF measures: this library contains a list of measures against common-cause faults, including their point values for quantification of the CCF in accordance with Annex F of EN ISO 13849-1. This list can be extended as desired by the user. Library of DC measures: this library contains a list of diagnostic measures, including their DC values, in accordance with Annex E of the standard. This list can likewise be extended by the user as desired. Library of good engineering practice methods: this library provides MTTFd and B10d values, based upon good engineering practice, for various element types in accordance with Annex C of the standard. In this case, changes, deletions or additions to the list entries are not possible.

6. Refined analysis methods for performance levels The DCavg values obtained for a system are sometimes only slightly below one of the thresholds, i.e. "low" (60%), "medium" (90%) or "high" (99%). If the simplified quantification method from EN ISO 13849-1 is then applied, analysis must continue with the next-lower DCavg level, i.e. "none", "low" or "medium", as a purely formal requirement. This procedure results in estimation of the system erring on the side of safety. Owing to the low number of levels on the DCavg scale, however, a minor system modification which causes the DCavg value to fall just below one of the thresholds may on occasion result in a substantially inferior analysis result for the system. This may occur even when high-quality tested components (high DC) in a channel are replaced by better components (with a higher MTTFd). The minor improvement in the channel MTTFd is over-compensated for in this case by the reduction of the DCavg to the next lower value for formal reasons, as a result of which the measured PFH becomes poorer (greater). This effect, which appears paradoxical, is a consequence of the coarseness of the DCavg scale: in other words, it is ultimately attributable to the crudeness of Fig. 5 and Table K.1 of EN ISO 13849-1. The described effect can be prevented or alleviated by the use of an alternative diagram employing a finer gradation of the DCavg values than that shown in Fig. 5 of the standard. The superior gradation is shown at the bottom of Fig. 3. With consideration for the limited precision of DCavg values, the minimum possible DCavg values were also considered for all categories. SISTEMA uses this refined method to determine the PFH value, interpolating further values between the columns shown in Fig. 3 in the process. In general, this enables major downgrading of the DCavg value to be avoided, and often a PFH value to be determined which is both more precise and superior.

1,00E-03

PL a b

DCavg-Intermediate levels for categories 2, 3 and 4


MTTFd Low Medium High

1,00E-04

1,00E-05

c
1,00E-06

d
1,00E-07

e
1,00E-08

Column described in ISO 13849-1, fig. 5

DCavg 55 60 65 70 75 80 85 90 55 60 65 70 75 80 85 90 95 99 94 96 98 99 [%] 2 2 Category 2 2 2 3 3 3 Category 3 3 3 3 4 Cat.4 4 2 2 2 2 3 3 3 3 4 4


Fig. 3: Refined analysis method for the performance level 7. Conclusion and prospects Major aims of the harmonized standard EN ISO 13849-1:2006 are ease of use, transparency and reproducibility. The standard primarily employs quantification of component reliabilities, the quality of fault detection, and also requires the inclusion of common-cause faults in the analysis. In principle, EN ISO 13849-1 represents a carefully designed superstructure, placed over the proven core of EN 954-1, which equips the revised standard for all technologies of relevance today. Existing users of the 954 standard can therefore quickly become familiar with the new standard. In addition, EN ISO 13849-1 requires no particular mathematical knowledge, unlike IEC 61508. It is generically suitable for mechanical, electrical, electronic, microprocessor, pneumatic and hydraulic control technologies. The SISTEMA software tool provides developers and testers of safety-related machine controls with comprehensive support in the analysis of safety in accordance with EN ISO 13849-1. The tool, which runs on Windows, enables its user to model the structure of the safety-related control components based upon the designated architectures, and ultimately permits automated analysis of the reliability values at different levels of detail, including that of the attained performance level (PL). The BGIA supports the introduction and use of these new methods. This support includes the provision free of charge of further tools and publications. The PLC (performance level calculator) disc is available for straightforward calculation of the PL of safety-related machine controls, at http://www.dguv.de/bgia/de/pra/drehscheibe/index.html. The methods in the standard are illustrated by two discs of card which can be rotated against each other. The disc

was developed with the aid of the ZVEI (Zentralverband Elektrotechnik- und Elektronikindustrie)/Fachverband Automation and the German Engineering Federation (VDMA). Many safety engineering companies use this disc, with their own corporate design, in order to support their customers. The BGIA Report 6/97 concerning control systems was fully revised in 2007, in order to describe the application of EN ISO 13849-1 and the new hardware and software requirements. It once again describes numerous examples of controls, which are analyzed by means of the tool SISTEMA and are available in the form of project files. This new Report will appear in German under the title BGIA-Report 2/2008 Funktionale Sicherheit von Maschinensteuerungen Anwendung der DIN EN ISO 13849 (the English version is in preparation). The SISTEMA software will be available on the BGIA's website, from where it can be downloaded following registration. SISTEMA will initially be available in German only. The English version is in preparation; versions for other languages are to follow. The tool will be available as freeware for use free of charge. Up-to-date information and the link for the download can be found at http://www.dguv.de/bgia/de/pra/sistema/index.html. Information on the standard and all available tools can be found at http://www.dguv.de/bgia/13849 (in preparation). 8. Literature [1] EN ISO 13849-1:2006 "Safety of machinery Safety-related parts of control systems Part 1: General principles for design" [2] Plddemann, G.; Schaefer, M.; Hauke, M.: Im Wandel Vergleich und Verkettung unterschiedlicher Sicherheitsnormen, Elektrotechnik 89 (2007) No. 2, pp. 26-28 [3] Hauke, M.; Schaefer, M.: Sicherheitsnorm mit neuem Konzept, O + P lhydraulik und Pneumatik 50 (2006) No. 3, pp. 142-147 [4] Plddemann, G.: Sicherheitsgerichtete Funktionen im Maschinenbau Neue Norm bietet Lichtblicke, article in IEE (2005) No. 8, pp. 74-79 [5] M. Dorra, D. Reinert, Quantitative Analysis of Complex Electronic Systems using Fault Tree Analysis and Markov Modelling European Project STSARCES (Standards for Safety Related Complex Electronic Systems) , Contract SMT 4CT972191, Final report of Work Package 2.1, annex 6, published by: European Commission - DG XII, Brussels 2000

SISTEMA: a Tool for the Easy Application of the Control Standard EN ISO 13849-1
Dr. Michael Huelke, BGIA Institute for Occupational Safety and Health of the German Social Accident Insurance, Division 5: Accident prevention - Product safety Michael Hauke, BGIA, Division 5: Accident prevention - Product safety Jan Pilger, BGIA, Division 5: Accident prevention - Product safety

SISTEMA: ein Tool zur einfachen Anwendung der Steuerungsnorm EN ISO 13849-1
In der neuen Norm fr sicherheitsbezogene Steuerungen, EN ISO 13849-1:2006, werden bewhrte deterministische Merkmale der Kategorien und neue Anforderungen zur Ausfallwahrscheinlichkeit auf praktikable Weise miteinander kombiniert. Das BGIA untersttzt die Einfhrung und Anwendung dieser Norm durch die Entwicklung und Bereitstellung der kostenlosen Software SISTEMA. Das Tool untersttzt Maschinenhersteller, Steuerungshersteller und Prfstellen bei der Gestaltung, Integration und Bewertung von sicherheitsbezogenen Teilen von Maschinensteuerungen. SISTEMA nutzt dabei ein verfeinertes Verfahren zur Bestimmung von genaueren Kenngren der Ausfallwahrscheinlichkeit. Funktionale Sicherheit, Steuerungssysteme, Maschinen, Software Werkzeug

1. Background For well over a decade, safety-related parts of machine controls have been designed and assessed in accordance with the EN 954-1 safety standard. The need for greater consideration to be given to new technologies such as electronics and software necessitated a thorough revision of this standard. In the revised standard, EN ISO 13849-1:2006 [1], proven deterministic characteristics of the categories and new requirements concerning the probability of failure (service life of the parts, quality of testing) are combined in a practicable manner [2], [3], [4]. As early as the mid-1990s, the BGIA was successful in acquiring knowledge and experience of quantification and in applying it in the testing of safety components, for example by its involvement in the European STSARCES project (Standards for Safety Related Complex Electronic Systems) [5]. This expertise has resulted in crucial input and groundbreaking work for the simplified analysis methods employed in the revised version of the standard. These analysis methods and the handling of reliability data are still relatively unknown in machine construction. Despite simple approaches, they remain complex in practice. Owing to its prevention mandate and with the background knowledge

gained during the revision, the BGIA is therefore supporting the introduction and application of this new standard by developing tools and making them available free of charge. One such tool is the SISTEMA PC program for the safe control of machines, which will be presented here. SISTEMA is the German acronym for "safety of controls on machines". Essentially, the purpose of SISTEMA is to enable the probability of failure of control systems, whether planned or already implemented, to be analyzed quickly and easily. Besides enhancing acceptance of the new methods, structured user guidance is to assure complete, error-free application of the EN ISO 13849-1 standard. With plausibility and consistency checks and a three-level indicator system, SISTEMA contributes to the avoidance of user errors. The tool assists machine manufacturers, control system manufacturers and test bodies in designing, integrating and assessing the safety-related parts of machine controls. It addresses all relevant control technologies. SISTEMA was funded by the German Fachausschuss Druck und Papierverarbeitung". The requirements for the program were defined following systematic examination of the standard in its final form, and with the incorporation of experience gained with a software prototype developed beforehand. The various methods set out in the standard were to be modelled in the software such that users need only enter their data in manageable input dialogs, and the result would be calculated continuously. A further important requirement was the separation of the user interface from the database for projects, safety functions and components. Besides robust computing functions, user-friendly functionality was implemented, such as the results prognosis and a database for standard components and control systems which have already been analyzed. The serviceability of the software is enhanced by documentation of the results in a report and by the use of a "wizard" by which users are instructed in the software's use. SISTEMA is initially available in German. The English version currently under development, and preparation for further language versions, will however enable the software to be used internationally in the near future. Testers at the BGIA trialled the program by analyzing real-case control systems. In addition, many example circuits have already been analyzed and are to be published in a BGIA Report. 2. How SISTEMA works The SISTEMA software tool provides developers and testers of safety-related machine controls with comprehensive support in the analysis of safety in accordance with EN ISO 13849-1. The tool, which runs on Windows, enables its user to model the structure of the safety-related control components based upon the designated architectures, and ultimately permits automated analysis of the reliability values at different levels of detail, including that of the attained performance level (PL). Input dialogs are used for the step-by-step input of relevant parameters such as the risk parameters for definition of the required performance level (PLr), the control system category, the measures against common-cause faults (CCF) on multichannel systems, the average component quality (mean time to dangerous failure, MTTFd) and the average test quality (average diagnostic coverage, DCavg) of components/blocks. Once the necessary data have been entered into SISTEMA, the

results are computed and displayed instantly. A practical advantage for the user is that the effects of each parameter change upon the system as a whole appear immediately in the user interface. Users are spared virtually all the time-consuming searching in tables and calculation of formulae (calculation of the MTTFd by means of the "parts count" method, symmetrization of the MTTFd for each channel, estimation of the DCavg, calculation of the PFH and PL, etc.). This enables them to "experiment" with parameter values in order to assess the global effect of modifications at no great effort. The final results are summarized in an overview ready for printout. Even with analysis by means of a tool such as SISTEMA, however, the user still faces certain challenges which can be overcome only with practice and experience. Before SISTEMA can be used, the safety functions must first be specified and the actual structure of a safety-related control system must be modelled. This model is described as a safety-related block diagram. In practice, the actual structures cannot always be modelled by the architectures employed in the standards. Following modelling, a second challenge is that of obtaining all the necessary data relating to the probability of failure of parts. A reasonable diagnostic coverage (DC) of discrete measures must also be estimated properly, particularly with wide variation in effectiveness (fault detection by the process: DC = 099 %). 3. SISTEMA in use SISTEMA processes basic elements from a total of six different hierarchical levels: the project (PR), the safety function (SF), the sub-system (SB), the channel (CH)/test channel (TE), the block (BL) and the element (EL). Their interrelationship between these levels is summarized below (Fig. 1).

Fig. 1: The hierarchical levels considered in SISTEMA The user first opens a project, in which he is able to define the machine or hazard point which is to be considered in greater detail. All necessary safety functions are

then assigned to the project. These can be defined and documented by the user, and a PLr assigned to them. The performance level (PL) of the parameterized SRP/CS (safety-related part of the control system) which is actually attained is determined automatically from the sub-systems which, connected in series, execute the safety function. The sub-systems are in turn based upon a "designated architecture" from the standard, as a function of the selected category. Among other things, the architecture determines whether the control system is of single-channel, singlechannel tested or redundant design, and whether a special test channel must be considered during analysis. Each channel can in turn be divided into any desired number of blocks, for which the user enters either an MTTFd value and a DC value directly, or, on the lowest hierarchical level, the values for the individual components from which the block is compiled. 4. The SISTEMA user interface The user interface of SISTEMA is divided into four areas (Fig. 2). The greater part of the area is occupied by the workspace on the right-hand side. Depending upon which view is active, the workspace contains an editable input dialog, or a partial view of the overview document.

Fig. 2: The SISTEMA user interface

The content of the active view is determined by the basic element selected from the hierarchy described above (Fig. 1), and is selected from a tree view on the left-hand side. Each branch in the tree view represents one basic element. Basic elements can be created, deleted, moved or copied in the tree view. The details of the selected basic element are entered in the input dialog in the editing view. Each input dialog is sub-divided further into different areas by tabs. The final tab in each input dialog contains a table summarizing all lower-level branches and listing the main information. If, for example, the user has marked a block in the tree view, this table shows all elements contained within it, together with their MTTFd and DC values. The tree view also shows status information for each basic element. The status information takes the form of a coloured dot adjacent to the branch. A red dot indicates that a condition of the standard is not satisfied, that a limit value is exceeded, or that a general inconsistency is present owing to which a required value cannot be calculated. A warning is output in this case. Yellow indicates a non-critical message (e.g. a basic element has not yet been named). All other basic elements are marked green. The colour marking is also always inherited to the branches higher up in the hierarchy, red having the highest and green the lowest priority. All warnings and information concerning the active basic element are displayed in the message window below the workspace. The area below the tree view shows the main context information for the selected basic element. This information comprises the PL, PFH, MTTFd, DCavg and CCF of the higher-level sub-system, and the PLr, PL and PFH of the higher-level safety function (this applies, of course, only to basic elements which are on lower hierarchical levels). The consequences of changes in the displayed parameters are thus displayed continually to the user. In addition to its flexibility, the SISTEMA user interface is notable for its ease of use and intuitiveness. Context help facilitates familiarization. The wizard supplied with the application offers further help: it supports new users step by step in the virtual modelling of their control systems, and assures rapid access. 5. Interfaces to users' and manufacturers' databases User-friendly library functions complete SISTEMA's range of features. The libraries supplied with the software contain a number of standard elements, blocks and complete sub-systems. They can however be extended as desired by the user, for example to form a database for parts which are frequently used. If desired, further library modules can be installed retrospectively; these include project-specific and machine-specific libraries from machine manufacturers, containing re-usable objects. SISTEMA enables the user to toggle between different libraries. The user can exchange library files with other SISTEMA users and incorporate them. Component manufacturers can also support their customers by creating write-protected libraries containing the reliability data of their products. In addition, SISTEMA provides a number of libraries containing the technical and organizational measures necessary for analysis of a control system. These libraries primarily contain the typical and most frequently applied measures, such as those

contained in EN ISO 13849-1. SISTEMA manages the following libraries for this purpose: The library of CCF measures: this library contains a list of measures against common-cause faults, including their point values for quantification of the CCF in accordance with Annex F of EN ISO 13849-1. This list can be extended as desired by the user. Library of DC measures: this library contains a list of diagnostic measures, including their DC values, in accordance with Annex E of the standard. This list can likewise be extended by the user as desired. Library of good engineering practice methods: this library provides MTTFd and B10d values, based upon good engineering practice, for various element types in accordance with Annex C of the standard. In this case, changes, deletions or additions to the list entries are not possible.

6. Refined analysis methods for performance levels The DCavg values obtained for a system are sometimes only slightly below one of the thresholds, i.e. "low" (60%), "medium" (90%) or "high" (99%). If the simplified quantification method from EN ISO 13849-1 is then applied, analysis must continue with the next-lower DCavg level, i.e. "none", "low" or "medium", as a purely formal requirement. This procedure results in estimation of the system erring on the side of safety. Owing to the low number of levels on the DCavg scale, however, a minor system modification which causes the DCavg value to fall just below one of the thresholds may on occasion result in a substantially inferior analysis result for the system. This may occur even when high-quality tested components (high DC) in a channel are replaced by better components (with a higher MTTFd). The minor improvement in the channel MTTFd is over-compensated for in this case by the reduction of the DCavg to the next lower value for formal reasons, as a result of which the measured PFH becomes poorer (greater). This effect, which appears paradoxical, is a consequence of the coarseness of the DCavg scale: in other words, it is ultimately attributable to the crudeness of Fig. 5 and Table K.1 of EN ISO 13849-1. The described effect can be prevented or alleviated by the use of an alternative diagram employing a finer gradation of the DCavg values than that shown in Fig. 5 of the standard. The superior gradation is shown at the bottom of Fig. 3. With consideration for the limited precision of DCavg values, the minimum possible DCavg values were also considered for all categories. SISTEMA uses this refined method to determine the PFH value, interpolating further values between the columns shown in Fig. 3 in the process. In general, this enables major downgrading of the DCavg value to be avoided, and often a PFH value to be determined which is both more precise and superior.

1,00E-03

PL a b

DCavg-Intermediate levels for categories 2, 3 and 4


MTTFd Low Medium High

1,00E-04

1,00E-05

c
1,00E-06

d
1,00E-07

e
1,00E-08

Column described in ISO 13849-1, fig. 5

DCavg 55 60 65 70 75 80 85 90 55 60 65 70 75 80 85 90 95 99 94 96 98 99 [%] 2 2 Category 2 2 2 3 3 3 Category 3 3 3 3 4 Cat.4 4 2 2 2 2 3 3 3 3 4 4


Fig. 3: Refined analysis method for the performance level 7. Conclusion and prospects Major aims of the harmonized standard EN ISO 13849-1:2006 are ease of use, transparency and reproducibility. The standard primarily employs quantification of component reliabilities, the quality of fault detection, and also requires the inclusion of common-cause faults in the analysis. In principle, EN ISO 13849-1 represents a carefully designed superstructure, placed over the proven core of EN 954-1, which equips the revised standard for all technologies of relevance today. Existing users of the 954 standard can therefore quickly become familiar with the new standard. In addition, EN ISO 13849-1 requires no particular mathematical knowledge, unlike IEC 61508. It is generically suitable for mechanical, electrical, electronic, microprocessor, pneumatic and hydraulic control technologies. The SISTEMA software tool provides developers and testers of safety-related machine controls with comprehensive support in the analysis of safety in accordance with EN ISO 13849-1. The tool, which runs on Windows, enables its user to model the structure of the safety-related control components based upon the designated architectures, and ultimately permits automated analysis of the reliability values at different levels of detail, including that of the attained performance level (PL). The BGIA supports the introduction and use of these new methods. This support includes the provision free of charge of further tools and publications. The PLC (performance level calculator) disc is available for straightforward calculation of the PL of safety-related machine controls, at http://www.dguv.de/bgia/de/pra/drehscheibe/index.html. The methods in the standard are illustrated by two discs of card which can be rotated against each other. The disc

was developed with the aid of the ZVEI (Zentralverband Elektrotechnik- und Elektronikindustrie)/Fachverband Automation and the German Engineering Federation (VDMA). Many safety engineering companies use this disc, with their own corporate design, in order to support their customers. The BGIA Report 6/97 concerning control systems was fully revised in 2007, in order to describe the application of EN ISO 13849-1 and the new hardware and software requirements. It once again describes numerous examples of controls, which are analyzed by means of the tool SISTEMA and are available in the form of project files. This new Report will appear in German under the title BGIA-Report 2/2008 Funktionale Sicherheit von Maschinensteuerungen Anwendung der DIN EN ISO 13849 (the English version is in preparation). The SISTEMA software will be available on the BGIA's website, from where it can be downloaded following registration. SISTEMA will initially be available in German only. The English version is in preparation; versions for other languages are to follow. The tool will be available as freeware for use free of charge. Up-to-date information and the link for the download can be found at http://www.dguv.de/bgia/de/pra/sistema/index.html. Information on the standard and all available tools can be found at http://www.dguv.de/bgia/13849 (in preparation). 8. Literature [1] EN ISO 13849-1:2006 "Safety of machinery Safety-related parts of control systems Part 1: General principles for design" [2] Plddemann, G.; Schaefer, M.; Hauke, M.: Im Wandel Vergleich und Verkettung unterschiedlicher Sicherheitsnormen, Elektrotechnik 89 (2007) No. 2, pp. 26-28 [3] Hauke, M.; Schaefer, M.: Sicherheitsnorm mit neuem Konzept, O + P lhydraulik und Pneumatik 50 (2006) No. 3, pp. 142-147 [4] Plddemann, G.: Sicherheitsgerichtete Funktionen im Maschinenbau Neue Norm bietet Lichtblicke, article in IEE (2005) No. 8, pp. 74-79 [5] M. Dorra, D. Reinert, Quantitative Analysis of Complex Electronic Systems using Fault Tree Analysis and Markov Modelling European Project STSARCES (Standards for Safety Related Complex Electronic Systems) , Contract SMT 4CT972191, Final report of Work Package 2.1, annex 6, published by: European Commission - DG XII, Brussels 2000

Net diagnosis for Profinet IO


Dipl.-Ing. Frank Iwanitz, Softing AG, IAP, Haar, Germany

Ansatz zur Netzwerkdiagnose in PROFINET IO Netzen


Spezielle Monitoranwendungen werden heute fr die Netzwerkanalyse in Feldbussystemen genutzt. Diese Anwendungen werden fr das Finden von Implementierungsfehlern in Gerten, fr die Inbetriebnahme von Anlagen, einschlielich Kommunikationsoptimierung, das Lokalisieren sporadischer Fehler in laufenden Anlagen und zur berwachung des Zustandes des Produktionsprozesses und der Automatisierungsgerte verwendet. Real-Time Ethernet Systeme werden in Zukunft die heute verwendeten Feldbussysteme ergnzen und schlielich ablsen. Fr diese Systeme wird es ebenfalls Lsungen fr die Netzwerkanalyse geben mssen. Bezogen auf PROFINET IO werden im Folgenden spezielle Anforderungen an die Netzwerkanalyse in Real-Time Ethernet Netzen erlutert. Es wird ein Ansatz diskutiert, der diese Anforderungen bercksichtigt. Real-Time Ethernet, Netzwerkanalyse, Busmonitor 1. Net diagnosis today and tomorrow Communications systems are described in comprehensive specifications. During implementation of defined functionality in real devices and applications, but especially during connecting various devices and applications with each other, situations can occur that make communication impossible or a least restrain it. This is due to the fact, that specifications can be interpreted in different ways. Communication problems can also be based on configuration or parameterization errors or external influences like EMC disturbances. Monitoring devices are used to find communication errors and irregularities. These devices capture the network traffic, present rather comprehensive correlations concise and comprehensible and provide possibilities to locate errors. Long-term experience by using network monitors has shown that these devices are used in various phases of the life cycle of an automation system. Commissioning, optimization of network traffic and detection of sporadic errors in producing systems are additional use cases additional to error detection in devices. Network monitoring device are becoming more and more a consistent part of the automation system. Over the last years new applications have been created based on these permanent diagnosis devices. These applications are used to capture all the data traffic and retrieve information about the process and the devices controlling it. Real-Time Ethernet solutions will be used more and more over the next years. In the future, also for these systems a strong need for network monitoring devices will exist. A lot of conditions and requirements known from well established field bus systems will not change. This includes comprehensive specifications, need for optimization, and support during commissioning, comprehensible presentation of complex

correlations, detection of sporadic errors, need for permanent diagnosis solutions and much more. But there are some additional conditions, which require new concepts for network diagnosis. Some of these specialties will be explained by using PROFINET IO. Furthermore some solutions are proposed to fulfill new requirements. In the following chapters first conditions and requirements for the application of network monitoring devices are introduced. They are derived from the way how PROFINET IO works and different application scenarios. Later, solutions are presented and discussed. 2. Special requirements for net work diagnosis in PROFINET systems The use of Ethernet and additional IT protocols in control devices enables unrestricted, bi-directional exchange of data between different areas. Now, one can react very fast on special customer requirements, additionally most recent information about the process are available for decision making. During the development of Ethernet specific requirements of automation have not been taken into account. Only the use of switches and full-duplex data exchange allow to meet most of the requirements existing in automation. PROFINET IO devices always use switched, full-duplex Ethernet as communication means. Most of the data are exchanged as unicast frames between devices. These are the reasons, why frames can not be captured at every point of the network, but only in the path between sender and receiver.

Picture 1: Star topology with external switch

Two possibilities exist to capture data. A switch supporting port mirroring can be utilized, if a star topology is used as shown in picture 1. In this case all devices are connected to this switch. For capturing data through a mirror port, all incoming and outgoing traffic from one specific port is mirrored on another port. Most information is available, if the port to which the PLC is connected will be mirrored (the most left interface in picture 1).

Picture 2: Star topology with port mirroring

But there are also use cases, where a star topology is not suitable and a line topology (daisy chain) is used instead. Here, the switches are part of the devices itself and mirror ports are not available. Now, data can only be captured by using a passive T-Connector also called tap. For using the tap the existing Ethernet cable has to be opened and the T-Connector has to be integrated. In this case it is also recommended to introduce the tap between PLC and the first device. A tap must be non-reactive, i.e. it may not influence the data exchange in any case. This must also be guaranteed, when the power supply of the tap fails.

Picture 3: Line topology with tap

The PROFINET IO specification defines a big variety of functions to meet different requirements. These requirements include: - more than one PLC can interact with one device at the same time, - support of media redundancy, - topology upload, - device exchange without the need to reconfigure the system, - Applications with small cyclic times and jitter and much more.

Not all requirements exist for every application. Therefore, not all functionality is always necessary. By defining Conformance Classes with specified functionality, a way for end-users and manufacturers exist to implement and use devices with the needed functionality.

Picture 4: PROFINET IO conformance classes

But also new requirements for network monitoring emerge by the functions defined in the Conformance Classes. Device information is exchanged by using Link Layer Discovery Protocol (LLDP). This protocol only defines interactions between adjacent devices. On the other hand, use of various IT protocols opens new ways for network monitoring. The Simple Network Management Protocol (SNMP) provides access to Management Information Bases (MIB) and supports a way to retrieve information about the status of a device, its communication interfaces and the communication itself. 3. Various scenarios to use network monitoring applications In the beginning, network monitoring tools for field bus systems have been developed to check implementation in devices. Later, the tools have been used in additional scenarios, like commissioning, communication optimization and permanent diagnosis solutions. This will not change, when Real-Time Ethernet systems are more and more used. Therefore in the following part requirements for these three scenarios will be considered.

3.1 Scenario A Use of a net diagnosis tool during implementation test The user of a net diagnosis tool wants to check accuracy and completeness of the implementation. He runs this check in an existing test bed containing available devices from other vendors and if available, test applications. There are no restrictions regarding network structures. Probably the vendor will even check the behavior of the device both in star and in line topology. Respectively, data capturing can be done either by using a mirror port or a tap or both. There will be no difficulties regarding monitoring of data, exchanged between adjacent devices, since only one device is tested and not the overall system. In this case the tap has to be placed inbetween the two devices. A number of taps must be used, if the devices behavior is checked, when it is accessed by more than one PLC. There are products available in the market containing more than one tap in the same device. Furthermore, it is possible to verify devices implementing all Conformance Classes without any problems. 3.2. Scenario B - Use of a net diagnosis tool during commissioning, optimization of communication and error discovery Always, a given communication structure exists in this scenario. It depends from the application. In a worst case scenario, it will neither be possible to use a mirror port nor to place a tap somewhere. Mirror ports are only provided by switches market as managed switches. Different from unmanaged switches, they implement more functionality that is manageable through various user interfaces (Web, serial terminal). But there is also a price difference, managed switches are more expensive. Even if a used switch supports mirroring, it can happen that all ports are used for data communication. Leaving one port open for mirroring would again increase costs. The same problem can occur, if one wants to use a tap. After the installation has been finished and approved it is nearly impossible, to make changes and insert one or more taps. Probably, it makes much sense to structure the installation in a way that online net diagnosis becomes possible. Of course, in this case an approach must exist, how to perform network diagnosis Are there any possibilities for network diagnosis, if port mirroring is not available and taps can not be inserted? PROFINET specification defines a number of mandatory functions and objects that can be used to retrieve the actual state of the overall system. A monitor with an active component can be connected to the system at an available communication interface. The active component is used to gather information from the devices and the monitor application is used to show the status of the devices and the system. This component can search for available PROFINET IO devices; ask for their symbolic name, set IP addresses, device structure and properties of existing application and communication relationships. The current status of the system can be retrieved in this way. A technician can compare this state with the target state and find differences. Reasons, why an IP address is not set, a relationship could not be established, connections go down sporadically, devices are not available, can not find based on

this scenario. These problems can only be located, if the traffic can be captured. Information about the above listed problems is not available in the devices. PROFINET IO defines a logbook object. It is recommended to insert information about communication problems here, to have access to this information later. New requirements exist, if a mirror port is available or taps can be inserted. During start up phase of the system, IP addresses are set, relationships are established and parameter are written to the devices. Later, pure Ethernet is used for exchange of real time data. RTA and RTC are used, as shown in picture 5.

Picture 5: PROFINET IO Available protocols.

Now, only MAC addresses are used in the frames to define sender and receiver, neither IP addresses nor symbolic names can be found. It is more or less impossible; to retrieve any information about the system structure from captured data traffic. But this knowledge is necessary to provide a comprehensible presentation of the structure. Therefore, even in this scenario an active component as part of the diagnosis tool is needed. The component can retrieve the data and the available information can be combined with the captured data traffic. The scenario gets even more complicated, if more than one PLC is interacting with the devices. Now it is not sufficient to capture data at one mirror port or through one tap. Data has to be captured at different places and must by synchronized regarding logical and time sequence. Data capturing done by a diagnosis tool must be non-reactive, i.e. it should not influence the exchange of application data. This requirement exists for field bus systems and also for Real-Time Ethernet systems. Can there be any influence on the exchange of application data, if the above explained scenarios are used?

Forwarding of frames to appropriate participants based on static and dynamic rules is the main task of a switch. In the case, that a switch supports data mirroring it is the responsibility of the vendor, that data mirroring does not influence data forwarding. Therefore vendors do not give any guarantee that the mirrored data stream fully corresponds to the original data stream regarding logical and temporal sequence of information. Especially, if much bandwidth is used, one can assume that data is lost or passed in a different way. Furthermore, the following has to be considered. PROFINET uses full-duplex 100 Mbit/s Ethernet. In theory, 200 Mbit/s can be passed through one port. This amount of data can not be mirrored by a 100 Mbit/s port. By using a tap, no danger exists to influence the data traffic, since the tap works nonreactive by definition. There are two other points to consider: - placing a tap into the network means to change cabling; - The tap itself is also an active part of the installation. In the case of power loss this should not disturbe data traffic. Additional traffic occurs, if an active component is used to retrieve data from the devices. Does this data exchange influence the exchange of application data? This question can be denied. Frames used to transport real time data are prioritized. Frames used to access information from the devices are not, i.e. they have lowest priority. Switches always forward high prior data first. Additional, the recommendation exists to reserve 40 % of the available bandwidth for non-real time traffic in PROFINET systems. First investigations in real systems have shown that use of active monitor components does not influence exchange of application data. As a conclusion, it can be stated, that solutions exist to find errors during commissioning and optimize traffic. But some recommendations are given: - During system design the use of taps and/or mirror ports for data capturing should be planned as part of the installation. - Information should be available in the devices at defined places that describe communication problems. Devices implementing Conformance Class B and higher, must implement SNMP. By using this protocol data stored in MIBs can be accessed by monitoring applications. 3.3 Scenario C Use of a net diagnosis tool in a permanent diagnosis solution Two use cases exist in this scenario: - To find and localize the reason for sporadic or recurrent error or abnormal behavior, - To monitor the process and the control equipment by capturing exchanged information. In both cases overall traffic has to be captured over a long time and probably at different places. Intelligent taps are here the best choice. At the moment taps from different vendors are investigated regarding their potential usability in the context of traffic capturing in Real-Time Ethernet solutions. A tap must fulfill the following requirements: - Data must be captured without influencing exchange of application data, i.e. it must be non-reactive. All taps fulfill this requirement. - It must be possible to parameterize data capturing. Only specific frames are of interest for permanent diagnosis applications, e.g. frames informing about communication problems or frames containing process data. Filtering, combined with data capturing prevents the monitoring application to be

overloaded. Assume that such an application is responsible for 8 PROFINET subsystems. - Interaction with devices by using the tap must be possible. The reason has been explained above in scenario B. - Existence of an appropriate way to pass captured data to the monitoring application. Nearly all taps use Ethernet to pass data to other applications. The machine running the monitoring application has to be directly connected to the tap. In real systems, a monitoring application can be interfaced with more than one tap and they can be located at different places, for instance in a control cabinet. In this case, the direct connection becomes difficult. Passing the data over the existing network is technically not possible and would also contradict the non-reactive requirement. Probably, none of the existing taps can fulfill all these requirements. Additionally, also for permanent diagnosis, ideas have to be defined, how to integrate capturing devices in applications. 4. Conclusion This contribution describes requirements for net diagnosis applications and scenarios in which they can be used. Requirements are derived from the use of PROFINET IO and can be defined also for other Real-Time Ethernet systems. Some of the requirements can be fulfilled already today, especially in the case of device testing. In the case of commissioning and permanent diagnosis, a number of open issues still exist. Definition of appropriate concepts could be a task of the user organization.

IPC based closed loop control of decentralized Servo Drives with eXtreme Fast Control (EtherCAT XFC)
Prof. Dr.-Ing. Jens Onno Krah, M. Sc. Christoph Klarenbach, Cologne University of Applied Science Faculty of Information, Media and Electrical Engineering

Introduction By using an FPGA and analog to digital conversion (ADC) technology, a Servo Drive can combine the advantages of analog and digital control at no trade-off. Utilizing EtherCAT as an extremely fast Fieldbus and an Embedded PC with FloatingPoint-Unit (FPU), a Motion Control system with centralized feedback control can be built as open system. Motion Control is going to be freely programmable with the option of using Intellectual Property (IP). To customize Servo Loops there will be no need for interaction with a Servo Drive manufacturer any more. 1. Motion Control with Servo Drives For a long time, high performance motion control was associated with the direct current (DC) motor. The power stage consisted of four power electronic switches and analog current control was implemented using operational amplifiers. Even in the velocity loop analog circuits were often used and a separate tacho sensor generated the velocity feedback signal. Usually a dedicated motion controller was employed for the position control loop. The Motion Controller was feeding the velocity loop command of the of the Servo Drive. The actual value of the position was made available by an Encoder. Over the years the typical Servo Drive was modified step by step: To increase the reliability and to reduce the motor size electronic commutation (6-Step) is introduced. (Brushless direct current BLDC) To reduce the torque ripple, brushless motors are commutated sinusoidally. (Brushless alternating current BLAC) Further motor size reduction is achieved by introducing single tooth windings. Instead of using a separate analog tacho sensor the velocity feedback signal is generated by numerical differentiation of the digital feedback position signal. Current and velocity control loops are realized by sampling control and using Controller technology. Due to the digitalization parameters are exactly reproducible instead adjusting a potentiometer to 1:00 pm. Command values from analog inputs are replaced by digital fieldbus process data objects.

Digitalization also allows implementation of more complex control algorithms: Field oriented control (FOC) of BLAC and induction machines (IM). Predictive algorithms to reduce the switching frequency without reducing the control loop bandwidth (Smith Predictor).

Model based algorithms to increase the control loop gain. (Luenberger Observer) Consideration of non-linear behavior due to iron saturation in case of high current operation. Motion control functionality is implemented more and more as a software module inside the Servo Drive or the machine controller (PLC) / Industrial PC (IPC).

With Sercos the Servo Fieldbus closing all control loops inside the drive is more or less the open standard in the machine tool industry. By focusing on the control theory this decentralized approach is a great advantage because the dead time of the fieldbus is not reducing the bandwidth (phase margin) of the control loops. In many industrial applications this approach is successful used. A disadvantage of the Controller based digital control is the associated dead time of sampling control TD = TS/2 . The sampling time is usually in a range between 50 and 250 s. By using switching frequencies up to 10 kHz this is a good fit. With higher switching frequencies the sampling control can significantly limit the achievable current loop bandwidth. 2. Is the intelligent Servo Drive a dead end? Today, a competitive situation by offering the motion control functionalities has evolved between the producers of Servo Drives and the machine controller manufacturers in. The product management of the Servo Drive vendors did push more and more computing power into the Servo Drives. Thus, today most Servo Drives offer a more or less powerful PLC-functionality (IEC 61131) inside the drive. Due to different requirements there are only a few common application specific strategies visible: In CNC and robotic applications the motion control functionality is realized in nearly all solutions centralized inside the machine controller (IPC): + The algorithms of coupled Servo Drives are calculated with at least one fast CPU often with floating-point-unit (FPU). - High fieldbus bandwidth is required at least like Sercos. In special technology applications, like for example a flying saw the motion control functionality is often realized inside the Servo Drive: - The Servo Drive needs a powerful Controller with large memory + High fieldbus bandwidth is not required. In camming applications a clear trend is not visible. Closing the loops inside the drive is traditionally the preferred solution in Europe even with analog Servo Drives. In the US it is more preferred to close only the current loop inside the drive. Position and velocity loop are often closed by the machine controller.

Especially in applications with several axes the distributed computing power of the Servo Drives is utilized extremely inefficient: - There are no intentions to partition the algorithms (computing load) over the distributed CPUs. - The execution of the Servo Drive PLC programs is more similar to high level language interpretation (BASIC) than to executing a compiled program (C). (Only the Danaher Motion ServoStar is utilizing a drive internal compiler) [1].

- A significant part of the Controller computing power is also used by some fieldbus interfaces. (For example by Powerlink). Another disadvantage of closing all loops inside the Servo Drive is that the user can only parameterize the control loops, but he cant modify the control structure itself. The user can configure and parameterize Motion Control, but motion control is not freely programmable! This has lead to the situation that some Servo Drives offer up to 1000 parameters to configure these drives. This is unacceptable in terms of usability. Due to cost reasons Servo Drive vendors can only install fast Controllers in larger drives (> 1 kW) because of the additional effort of the computing power. But in nearly all applications the Servo Drive PLC functionality is not able to replace the machine controller PLC. Therefore, installing more and more computing power into Servo Drives is a dead end. 3. A new Approach: the FPGA based Servo Drive In this article a new approach is presented where the Servo Drive control functionality is not using a dedicated Controller any more. A Field Programmable Gate Array (FPGA) programmed in VHDL is used instead. This innovative approach is based on several new technologies: EtherCAT Fieldbus with Distributed Clocks (DC) and eXtreme Fast Control (XFC) -Modulator for Analog to Digital Conversion (ADC) Digital Encoder Interfaces (EnDAT 2.2, BiSS or just A quad B) FPGA based digital signal processing (DSP) Flexible 6-phase PWM in VHDL Soft Core Controller in FPGAs (System on a programmable chip: NIOS II) Embedded PC/PLC with Floating-Point-Unit

4. EtherCAT Fieldbus with Distributed Clocks (DC) and eXtreme Fast Control EtherCATTM is an Ethernet based real time fieldbus. The following list shows the special features oft the EtherCAT fieldbus [2]: Standard Ethernet hardware: RJ45 connector, transformer, cable and PHY (Also standard MAC in the IPC / EtherCAT Master) The slave interface connection needs only an ASIC or FPGA (I/O, drive, ) The protocol is open and standardized: EtherCAT is IEC standard (IEC/PAS 62407, IEC 61158) EtherCAT is part of ISO 15745-4 Distributed Clocks (DC) - high precision synchronization (<< 1 s) due to the continuous adjustment of distributed clocks within the slave interface eXtreme Fast Control: Within one sampling period - the actual values are first read via EtherCAT from a bus terminal (Encoder) - then the IPC calculates with the control algorithm a new command value - and these values are immediately send via EtherCAT to the bus terminal (Drive)

An EtherCAT-slave-interface is available as FPGA IP-Core (Intellectual Property). To save FPGA resources the design engineer can disable not requested functionality of

the IP-Core. Only two PHYs and two RJ45 connectors with some passive components are necessary in addition to the used FPGA logic elements. The process data, commands and actual values, are processed inside the FPGA according to a VHDL program (utilizing hardware) with no delay. Parameters like gains and monitor functions (EtherCAT: Mailbox) are processed from an FPGA internal soft-core-processor (NIOS II). 5. -Modulator for Analog to Digital Conversion (ADC) The quality of analog-to-digital conversion is a key factor of high performance Servo Drives. Especially the motor phase-current measurements are not trivial. Traditionally these currents are measured with compensated hall sensors. These sensors are converting the phase currents into proportional electrically isolated voltages/signals witch are feeding successive approximation (SAR) ADCs. Suppressing the current ripple with a low pass filter and its phase lag to avoid aliasing is not common. Instead, most drive suppliers sample the currents at a special point in time within the PWM cycle where the current value shows no distortion due to the ripple. Very often additional analog comparators are used to detect over current with no sampling delay to be able to disable the power stage as fast as possible.
Digital Filter
MDat

Shunt

MClk MDat

Modulator Output

Analog Input

Fig. 1: An integrated -modulator generates an isolated bit-stream (digital) from the analog input signal. Thanks to the new integrated -ADCs the current control quality can be significantly increased with less effort in cost and printed circuit board space. Several semiconductor suppliers are offering integrated circuits with internal galvanic isolation (Avago, Ti, Analog Devices), fig. 1. The differential analog input of these ICs can be directly connected to a shunt for current measurement. The (isolated) bit-stream is designed to be directly connected to digital circuits like an FPGA. Signal transmission, filtering and also sampling is carried out in the digital domain. If the modulator is placed very near to the shunt, signal distortion during transmission, filtering or sampling from the fast switching power stage (EMI) is by principle not possible. The bit-stream is processed within the FPGA with three parallel decimation filters in three channels: Very fast for over current detection (2% precision) Standard with about 12-Bit precision for the proportional-component of the PI-controller

High precision (integration over one PWM period) for the integral-component of the PI-controller

The patent of this new current control scheme is pending. 6. Digital Encoder Interfaces (EnDAT 2.2, BiSS, A quad B) Digital encoder interfaces allow a fast transmission of the high resolution position (motor shaft angle) data of modern sine-cosine-encoders. Even long cables are not reducing the position signal quality. In addition to the process data (position) these digital interfaces also allow to store and read encoder or motor parameters (electronic type plate). The optional transmission of the motor temperature sensor information can also save separate wires in the cables between motor and drive, fig. 2.
Position (Sensor Mode) Alarm, Warning Temperature Type plate Serial number Commutation, (Multi Cycle Data) (Register Mode) Motor Parameter

Fig. 2: Using a digital encoder interface the drive can also access additional parameters. Transmission of EMI sensible analog signals is not necessary. Classical Controllers offer special hardware support for standard A quad B (TTL) encoders. Most controllers have to use an interrupt to use the zero marker channel. Fine interpolation, EnDAT 2.2 (Heidenhain) or BiSS (IC Haus) are never supported by Controller hardware. An interface with fine interpolation (+6 Bit) for standard TTL-encoders and/or the EnDAT 2.2 / BiSS interface or a resolver digital conversion are perfect for FPGA implementations. These VHDL-modules are very cost efficient and need only a few external driver circuits [3, 4]. The EtherCAT distributed clocks functionality (sync-signal) is used to start / synchronize the encoder position latch process. This is also an FPGA internal VHDL program module. The position data is routed internally inside the FPGA with no additional delay to the EtherCAT IP-Core. The next EtherCAT-frame can transmit the process data to the PLC/IPC. It is not longer necessary to connect the feedback (encoder / resolver) directly to the Servo Drive. It is now also possible to close the servo loop by connecting the feedback to a separate EtherCAT bus coupler without bandwidth limitations. 7. FPGA based digital signal processing Signal processing like control algorithms are traditionally implemented with analog operational amplifiers or with digital signal processors (DSP). This functionality can also be done with digital FPGA signal processing blocks. Thanks to the massive parallel execution even complex algorithms can be executed in less than 100 ns. A CPU with its sequential processing is much slower in executing complex control algorithms. FPGA based control technology can combine the advantages of analog and digital control without any drawback:

- Analog control - DSP based control

no dead time, no aliasing reproducible parameters, complex algorithms

Using the FPGA DSP-functionality even a complex current controller with more than 20 kHz power stage PWM frequency can be realized completely digitally. A Controller based architecture would reduce the achievable bandwidth due to the slower sampling frequency. 8. Flexible 6-phase PWM in VHDL Several Controllers optimized for motion control offer a special 6-phase PWM for the 6 inverter switches (IGBT or MOSFET). A value in a register is compared with a triangular carrier signal for each motor phase. The blocking times for the three half bridges are also freely adjustable. Space vector modulation (inverse Clarke transformation) has to be carried out in software. Over modulation or block commutation is not possible [5]. These limitations disappear by implementing the 6-phase-PWM in VHDL. In addition to a standard PWM the following features are supportable: 9. Space Vector Modulation (SVM) Modified Space Vector Modulation (MSVM - one phase is not switching) Over modulation / Block commutation Boot strap gate driver model for each motor phase Optional PLL to synchronize the PWM with the motion controller On line configuration of the switching frequency in 1 Hz steps On line configuration of the blocking time in 20 ns steps Soft Core Controller in FPGAs

For initialization and to process the service data objects (SDOs) a Controller is still a successful approach. The system on a programmable chip soft-core microcontroller NIOS II from Altera is ideally suited for this purpose. The program for the Controller and the FPGA configuration can be permanently stored in a parallel flash memory. According to the selected FPGA type and the application requirements an additional external RAM can be necessary. The clock frequency of the soft-core Controllers NIOS II is usually in the range of 50 MHz. This is more than enough for initialization and service data processing [6, 7]. Fig. 3 shows the block diagram of a field oriented drive for FPGA implementation. To reduce the complexity not all signals for initialization and configuration are shown.

Flash [SRAM]
DC Bus
V Bus

sinc3

Nios II
Configuration Mailbox - SDO

Cyclone III 3C25


ud PI id iq uq u u i i
sinc3 Clark

IGBT

id*

EtherCAT

PDO

PHY

iq*

SVM
Clark-1

ej
Park

PHY

e-j

u v w

m phi speed Feedback + Observer / RS485

Shunt

FB

Fig. 3: Due to the new FPGA-based concept are in addition to the FPGA only a few integrated circuits necessary to build a Servo Drive

Feed forward
d dt
VFF Positioncontrol VelocityControl

Motor / Encoder
d dt
AFF Filter CurrentControl Motorwinding Inertia J

= dt

t -

Velocity Observer


f(, J, Kt)


- +

PLC Motion Controller (TwinCAD Embedded PC)

VHDL Drive IP (Altera Cyclone III)

Fig. 4: Using the standard cascade control only the current loop is closed inside the FPGA. Velocity and position loop of one or more servo axes are closed without additional dead time in the IPC via EtherCAT XFC.

The soft-core controller NIOS II can process EtherCAT Mailbox data to configure the drive functionality via the dual port RAM of the EtherCAT IP-Core. In case of a fieldbus error the CPU can shut down the servo motor according to a preconfigured stop modus. This can be done using a second velocity loop executed from the NIOS II controller, or with a controlled active current short cutting of the servo motor.
EtherCAT Cycle Time (62.5 s) DC Offset Encoder S&H EtherCAT Read I/O TwinCAT
Control Algorithm
8 MHz Request

Clock Burst

EtherCAT Read I/O

EtherCAT Write I/O

DC Event Sync Read: S&H Write: Latch

VHDL Control Algorithm

Fig. 5: Time schedule of velocity and position loop: 1. EtherCAT Read I/O to read the actual values 2. TwinCAT calculates the control algorithms 3. EtherCAT Write I/O to write the current command The FPGA internal synchronization uses the DC-sync signal: - Latch of the position - Latch of the new current command 10. Embedded PC/PLC with Floating-Point-Unit Today, most compact Programmable Logic Controllers (PLCs) use Intel compatible processors with Floating-Point-Unit (FPU). The Embedded PC CX1020 from Beckhoff Automation is such a compact PLC, fig. 4: Intel Celeron M ULV, 1 GHz Clock frequency 64MB DDR RAM (extendable up to 1 Gbyte) Microsoft Windows XP Embedded TwinCAT PLC IEC1131-3 Multi-PLC EK1110 EtherCAT Extension

The software TwinCAT PLC converts a standard PC with Windows operating system in a real time Programmable Logic Controller (PLC) with cycle times of 50 s and up. The task scheduler is configured in a way, that Windows gets only the remaining CPU time, that is not requested from the real time PLC tasks. Due to the really fast floating-point-unit even complex control algorithms for one or more servo axes are easily programmable in a high level language with excellent development support. The TwinCAT integrated development environment allows Monitoring, Powerflow, Breakpoint, Single-Step and ScopeView [8].

Conclusion In this paper a new FPGA based Servo Drive concept is presented, where the position loop and the velocity loop are closed in an IPC based PLC via EtherCAT with eXreme Fast Control (XFC) and Distributed Clocks (DC). The advantages of this EtherCAT / FPGA Servo Drives are: The Servo Drive can combine the advantages of analog and digital control at no trade-off due to digital signal processing inside the FPGA. The position feedback from motor and/or load can be connected via EtherCAT bus couplers to close the loops. A standard frequency inverter with an FPGA based EtherCAT interface can be part of a high performance Servo Drive. Customizing the control structure can be done easily in a IEC 61131 high level language by coding floating point algorithms. There is no bandwidth limitation by closing the loops via EtherCAT XFC up to 8 kHz switching frequency (Ta = 62.5 s) The open architecture is forcing innovations: Motion Control IP is possible.

Literature 1. www.danahermotion.net 2. www.ethercat.org 3. Jens Onno Krah, R. Vonderbank, J. Bcher, R. Berger: Resource Optimized BiSS Master Interface for High Resolution Encoders, PCIM Power Conversion Intelligent Motion, Nrnberg, June 2006 pp 479-484. 4. Jens Onno Krah, H. Schmirgel, M. Albers: FPGA Based Resolver to Digital Converter Using Analog to Digital Technology, PCIM Power Conversion Intelligent Motion, Nrnberg, June 2006 pp 931-936. 5. J. O. Krah, J. Holtz: High-Performance Current Regulation and Efficient PWM Implementation for Low Inductance Servo Motors. IEEE Transactions on Industry Applications, Vol. 35, No. 5, Sept/Oct 1999, pp. 1039-1049. 6. www.altera.com 7. J. O. Krah, K. Neumayer: System-on-a-Programmable-Chip Enhanced Solutions for High Performance Servo Drives, PCIM Power Conversion Intelligent Motion, Nrnberg, May 2003, pp. 105-110. 8. www.beckhoff.de

Programming PLCs with an Object-Oriented Approach


Ph.D. (MUN, Can.), Ulf Schnemann, 3S Smart Software Solutions GmbH, Memminger Str. 151, 87439 Kempten, Germany

SPS-Programmierung nach dem objekt-orientierten Ansatz


Heutzutage werden die meisten greren Softwareprojekte fr PCs mit objektorientierten Programmiersprachen realisiert. Deren erwiesene Vorteile krzerer Entwicklungszyklen und besserer Wiederverwendbarkeit werden zunehmend auch von Entwicklern grerer Steuerungsapplikation nachgefragt. Allerdings hat sich bei Industriesteuerungen mit der IEC 61131-3 ein klassischer, prozeduraler Programmierstandard etabliert. Analog zur Weiterentwicklung von C nach C++ kann eine kleine Erweiterung der IEC 61131-3 die entscheidenden objektorientierten Features verfgbar machen: Funktionsblcke werden zu Klassen durch untergeordnete Methoden-POEs; IMPLEMENTS und EXTENDS deklarieren Vererbungsbeziehungen; INTERFACEs mit Referenzsemantik und dynamischem Binden ermglichen Polymorphie. So eine Erweiterung wurde in CoDeSys V3 realisiert. Sie ist eine reine Option fr den Anwender und kann frei mit prozeduraler Programmierung kombiniert werden. Objektorientiertes Programmieren, SPS, IEC 61131-1, CoDeSys

1. Introduction
In desktop application development and in university education, object-oriented programming (OOP) in languages like C++ or Java is now common place. OOP has demonstrated its capability for handling complex software development problems in an elegant way and for producing flexible, reusable software components. It has reduced the development time of new software and simplified the solution of complex software tasks. Industrial controllers (PLC), on the other hand, are mostly programmed in the languages of the IEC 61131-3 standard. While some developers cannot wait to use OOP for PLC-programming, others may be sceptical about the adequacy of OOP for their PLC-projects. In order to address both parties, an object-oriented programming tool should satisfy the following requirements:

Integration in a PLC development environment: Integrated with the objectoriented programming itself, one should have integrated configuration of I/Os, direct access to I/O-signals, and online-debugging functionality with variable forcing and online change. Advantage: PLC-application development has many specifics, which exiting C++ development tools available for many target-CPUs do not address. Multi-paradigm programming: Object-orientation should be optional. Code programmed in the classical, procedural way should be mixable with objectoriented code. Advantage: This offers the sceptics a stepwise and reversible transition. OOP by extension of the IEC: Object-oriented PLC-programming should be supported by extending IEC programming with a small set of standard objectoriented features. Advantage: Not having to learn a completely new language avoids a steep learning curve for PLC-programmers. Multi-lingual: Object-oriented programming should be supported in all languages of the IEC 61131-3, not just in the textual IEC-language ST most similar to C++ and other known object-oriented languages. Advantage: Textual languages cannot represent clearly certain important aspects of PLC applications, like state machines and complex Boolean connection networks.

Such an object-oriented programming tool is available on the market in the form of the IEC-development environment CoDeSys V3 developed by 3S Smart Software Solutions. As opposed to other object-oriented languages, this object-oriented extension is not based on the generalization of the data record construct to a class construct (C++ generalized Cs struct, Ada95 generalized Pascals record). The IEC includes something much better than its STRUCT construct: Functionblocks. CoDeSys extends the FUNCTION_BLOCK-construct to a class construct by the addition of methods, properties and subclassing. And CoDeSys introduces the INTERFACE-construct for the declaration of abstract functionblock-types with polymorphic reference semantics. The new object-oriented features have already proved their practicality and usefulness in 3Ss advanced libraries (see table 1), where they were employed heavily with over 50 interfaces and over 130 object-oriented functionblocks.
Interfaces Functionblocks with methods (# extensions implementing an Not implementing an among them) interface (# interface (# extensions) extensions) I/O10 7 (2) 2 11 (1) 19 (4) 13 (1) 24 16 (3) 19 (1)
Table 1. OOP statistcs

SysLibs, driver Visualization Data server Others

21 38 (21) 8 (7)

In the following we will consider what defines object-oriented programming and look at the language extensions supported it.

2. The Elements of Object-Oriented Programming


Object-oriented programming (OOP) is best explained not in terms of programming language features but by its specific approach to organizing the software. A language can be called object-oriented if its linguistic elements allow the programmer to express such an organization. These are the three accepted elements of the object-oriented organization: 1. Objects organize the computational system into components 2. Classes organize objects by similarity 3. Subclassing organizes classes by degrees of similarity

2.1 The Object (Computational System = Composition of Objects)


The fundamental characteristic of OOP, as opposed to classical procedural programming (C, IEC), is a new way of thinking about the computational system: The procedural view separates the representation of the systems state through data components (variables) from the implementation of the systems behaviour through procedures. In the object-oriented view, the system is composed of interconnected objects. Each object is a small procedural system with its own state and behaviour (implemented through methods). An objects method can operate on its state and call the methods of other objects, to which it is connected by object references. Advantage: Assume a real object (e.g. a PUMP) or a virtual object (e.g. a SCROLLBAR) shall be managed by your system. Is it natural to think of this as an additional data structure, whose handle you have to pass into a Devices-API or a Windows-API? Or is it more natural to think of it as a new object that brings its behaviour with it and that you invoke directly on that object?
WindowsAPI.SetFocusTo(handleToMyScrollbar); // procedural myScrollbarObject.GrabFocus(); // object-oriented

Language feature: Dot-notation In CoDeSys V3, instances of functionblocks with methods (see below) are objects. Through the standard dot-notation for invoking a method, the notion is support that the method is a part of the functionblock instance. The following code shows a program invoking the Start method on a Pump object and on a MonitoredPump object:

Figure 1. Method calls

Note: In CoDeSys, as in most object-oriented programming languages, besides objects there are still other entities in the computational system, like global or static variables and global or static procedures.

2.2 The Class (Object = Instance of a Class)


Objects with the same data and behaviour belong to the same type, called class. All objects are instances of a class (even if no other object has the same data and behaviour). While objects are the components of the computational system, the definitions of their classes are the modules of the program code. Compare this to procedural programming: Here, typing is based solely on data. Data components (variables) with the same structure and value range are instances of the same data type, while each procedure is unique. Where one needs to type procedures, one can only use the combination of the data types of their inputs and outputs. Advantage: Instead of implementing a single PUMP object (and maybe later having to implement another one), we directly implement with the languages class construct PUMP objects in general and then create as many PUMP instances as we want. Language feature: Variables IECs functionblock construct is a good basis for a class construct since the variables declared therein define the representation of the instances state. These variables are protected by the IEC visibility rules: The functionblocks internal variables (VAR) can only be accessed within that same functionblock and its methods. The functionblocks input variables (VAR_INPUT) can be written from outside and read from within the functionblock and its methods. The functionblocks output variables (VAR_OUTPUT) can be written from within the functionblock and its methods and can be read from the outside.

This means, only internal variables can properly be used for the objects state representation. It follows, first, that the objects state is under the sole control of the objects methods (encapsulation). Advantage: No interference from somewhere else in the system can then unexpectedly destroy the consistency of the state representation maintained by the methods. Moreover, it follows that the state representation is not visible to the outside at all (information hiding). Advantage: The implementation decision how to represent an objects state is localized in its own methods. It can be revised invisibly to the rest of the system (provided the methods are adapted correctly). Language feature: Methods What is still missing to make a class construct out of IECs functionblocks is of course a method construct for the implementation of the objects behaviour. Methods in CoDeSys V3 may be seen as a hybrid of an IEC-action inside a functionblock and of an IEC-FUNCTION with result type, parameters and local variables. All IEC languages allowed for functions can be used for the implementation of methods (although in the following code samples, the implementation language is always ST). The following screenshot shows a program with two PUMP instances and the call of the Start method on them the PUMP functionblock declaring its instances internal variables the definition of the two PUMP-methods Start and GetState

Figure 2. Functionblock with methods

2.3 Subclassing (Class = Specialisation and/or Generalisation)


Subclassing finally is the highlight of object-oriented programming. It is an original, new feature without comparison in procedural programming. There are three aspects to it: class hierarchy class inheritance subclass polymorphism

2.3.1 Class hierarchy


Classes can be arranged into a hierarchy by subordinating more special classes (subclasses) under more general classes (superclasses). The commonality of two different specialized classes like CANDRIVE and ANALOGDRIVE can be factored out into a new common superclass DRIVE. Advantage: By declaring a classs superclasses, the multitude of the types of different objects in the system is brought to order. For general superclasses like DRIVE, without instances by themselves (abstract superclasses), the states representation and the behaviours implementation does not need to be defined; it suffices to declare the objects state and behaviour interface. Language feature: Interfaces For the declaration of abstract superclasses, the interface construct was introduced as a new variant of the POU construct. An interface is similar to a functionblock, with subordinate methods and properties. The difference is: the functionblock, the methods and the properties have no implementation part and declare no local variables. Language feature: Extends and Implements Subclass relationships are declared by the keywords EXTENDS and IMPLEMENTS in a functionblock or interface declaration part: EXTENDS in a functionblock makes it the subclass of one other functionblock. EXTENDS in an interface makes it the subclass of one or more other interfaces. IMPLEMENTS in a functionblock makes it the subclass of one or more interfaces. An IMPLEMENTS declaration requires that the functionblock has at least all the methods and properties which the named interfaces have (with the same parameter and result types). The new thing is that in the functionsblock, the methods and properties now must also have an implementation part! The following screenshot shows the CANDrive implementation of the IDRIVE interface. It implements the IDRIVEs Home-method by CAN-messages. Note the CAN-specific variables declared the CANDrive functionblock and the additional, CAN-specific methods MoveAbsolute and SetCANId. An AnlogDrive-implementation of IDRIVE, with the specifics of analog drives, could similarly be defined (not shown).

Figure 3. Implementation of an interface

2.3.2 Class inheritance


A subclass inherits the interface, state representation and behaviour implementation from its superclasses and can complete or selectively adapt it. Advantage: Reuse of declarations and code. Language feature: Inheritance If a functionblock is declared to extend another one, this implies that it inherits the all variables and methods from that one. On top of these, the sub-functionblock can of course define its own, additional variables and methods. The following screenshot shows a MonitoredPump subclass derived from the PUMP superclass by inheriting its variables (Enabled and Dir) and method (Start, GetState), and by extending it with a MonitoredPump-specific HasError method.

Figure 4. Inheritance

2.3.3 Subclass polymorphism


Instances of subclasses like CANDRIVE and ANALOGDRIVE are also instances of their superclass IDRIVE. This means, CANDRIVE and ANALOGDRIVE instances can be assigned to variables and parameters of type IDRIVE. When a method Start is called on a CANDRIVE object through the IDRIVE variable, the notion of methods as part of the object then ensures that it is still the CANDRIVE version of Start which will be executed (dynamic binding). Advantage: One can write code against the interface the general class DRIVE that works uniformly for instances of all its subclasses (CANDRIVE, ANALOGDRIVE, etc.). Where different behaviour is necessary for different cases of drives, the differences can now be defined as a method in the different ICASE implementations. This allows to get rid of a typical procedural programming maintenance problem: A program with CASE statements over all possible types of drives scattered throughout the code. Language feature: Reference semantics for interface types Polymorphism in CoDeSys V3 works only with interface. (Assignment to a variable of a functionblock supertype cannot create a polymorphic superclass access to subclass object, since each variable of a functionblock type is a new functionblock instance): Like a functionblock name, the name of an interface can be used as a type name in the declaration of variables (directly or as the basetype of an array). These declarations have reference semantics. That means, by this declaration we do not get a new object but only a new reference to a functionblock-instance declared elsewhere (initially NULL). The assignment of a functionblock instance to an interface variable makes that variable refer to the functionblock instance.

The following screenshot shows a classical functionblock with an IDRIVE input D that uses the methods Home and MoveAbsolute of the IDRIVE interface. It can be called with instances of both the CANDrive and the AnalogDrive functionblock and will do the same on both of them. Of course, the code executed when Home and MoveAbsolute are called, will depend on what functionblock instance the input D refers to.

Figure 5. Polymorphic function

The following screenshots shows the declaration of an array of instances of the interface IDRIVE the arrays initialization with instances of different functionblocks implementing IDRIVE (see next feature) the uniform processing of all these functionblock instances by a FOR-loop over the array

Figure 6. Polymorphic array loop

3. Conclusion
Even the small examples above should have been able to demonstrate some of the advantages of object-oriented programming: Better structured program code with separation of concerns and information hiding flexible extensibility by new types of objects (e.g. software representations of new types of drives), reuse of code for defining specialized subclasses (inheritance) reuse of code operating on different implementations of an interface (polymorphism) It has been shown that all the essential features of standard object-oriented programming are included in CoDeSys V3. A summary comparison with C++, Java and C# is given in table 2 below. Three more auxiliary features are included in CoDeSys V3, that we were not able to discuss here for space reasons: constructor and destructor methods (FB_Init, FB_Exit) THIS and SUPER in methods properties (as in C#) Four common features of object-oriented languages were not included in CoDeSys V3 in order to keep the OOP extension small and simple: dynamic allocation (keyword new) fine-grained access control for variables and methods (private, protected, internal, public) partially abstract classes with abstract methods (abstract) optional dynamic binding (virtual)
Language feature Multi-lingual Multi-paradigm Classes Methods Interfaces Dynamic binding Implicit reference semantics Constructor / destructor Properties Dynamic allocation (new) Access control Partially abstract classes IEC + ~ (FBs) ~ (actions) ~ (variables) CoDeSys v3 + + + + + + + (Interfaces) + + ~ (variables) C++ + + + +/+ + + + Java + + + + + + + + + C# + + + +/+ + + + + +

Table 2. Comparsion of languages

Flexible Control Systems Development and Integration Environment for Distributed Systems
Professor Haydn Thompson, Rolls-Royce University Technology Centre in Control and Systems, University of Sheffield, Sheffield, United Kingdom.

Entwicklung flexibler Kontrollsysteme und Integrationsumgebung fr verteilte Systeme


Die Entwicklung von verteilten Kontrollsystemen erfordert Werkzeuge, die mit hoher Komplexitt umgehen knnen und Integration von Design-Informationen aus mehreren Bereichen sowie Analyse-Mglichkeiten fr das gesamte Design ermglichen, welche sowohl technische als auch wirtschaftliche Performance mit einbeziehen. Momentan gibt es keinen integrierten Satz bergreifender Design-Werkzeuge, die dies leisten knnen. Mit dem FLEXICON-Projekt wurde ein Satz von Werkzeugen fr Anwendungen aus dem Schiffs-, Automobil- und Luftfahrtbereich (MAA) erstellt, welche die Simulation und Bemessung der Systemleistung vor Realisierung sowie den raschen Aufbau von Prototypen ermglichen. In diesem Schreiben wird die Anwendung der FLEXICON MAA-Werkzeuge fr Co-Simulation auf das Vorfhrmodell eines Hochgeschwindigkeits-Schiffes von Rolls Royce beschrieben. Schlsselbegriffe: Co-Simulation, verteilte Systeme, Zuverlssigkeit und Lebensdauerkosten 1 Introduction The move from a centralised system to a distributed system is often seen as high risk by Industry. A fundamental problem is that currently no integrated multidisciplinary design tools exist which can deal with high complexity, integration of design information from multiple domains and analysis of the overall design in terms of technical and commercial performance. The ability to simulate and assess system performance and rapidly prototype systems is critical to reduce risk and cost. The EU funded FLEXICON project (IST-2001-37269) aimed to reduce the development lifecycle and implementation cost for distributed control systems through provision of a toolset for Marine, Aerospace and Automotive applications (MAA). This integrated Commercial OffThe-Shelf (COTS) tools for the design and development of such applications (via cosimulation with hardware-in-the-loop. The tools integrated are ISaGRAF Enhanced, Simulink/Stateflow, ARTISAN RtSand Excel. Using these tools the toolset allows analysis of control system performance, fault tolerance, availability and through-life-cost. FLEXICON MAA uses open standards such as OPC, IEEE 1451, UML, IEC 61131-3, CORBA and NDDS [1]. In order to demonstrate the flexibility and scalability of the MAA toolset a demonstrator for a Marine application was built. The Marine application was of a waterjet driven high speed merchant vessel with five propulsion systems as described in [2] and Section 3 of this paper. To demonstrate the steering and reversing capability of the waterjets a scale model boat was used. The demonstrator was based on Pentium 4 processors for the integrated COTS tools

and also for the MAA tools developed (Co-simulation, Reliability & Through-Life-Cost, Configuration Management Database, Java Code Generator, VHDL Code Generator, System Builder, tool support for Co-simulation with Hardware-In-the-Loop, and Alarms and Warning Management). PowerPC, Tecla PLC and FPGA processors were used in the demonstrator with interfaces to sensors and actuators and interconnections via a variety of databus technologies such as Ethernet, CAN, Wireless Bluetooth and Serial connections. 2 FLEXICON MAA toolset

Fig. 1: FLEXICON Development Process Model with Co-simulation

Fig. 1 shows the development process model adopted in the FLEXICON project. This Vmodel was the result of several discussions and comparison of the development processes of the FLEXICON End User partners. For the MAA toolset, co-simulation is very important for requirements capture, performance analysis and costing, and also during the testing and commissioning phases. Code generation and the aftermarket phases are also supported. Conceptual requirements provided by the end-user are initially implemented using the MAA co-simulation environment. Using the tools performance analysis can be made. This not only includes control system performance and response to faults but also commercial metrics such as Reliability and Through-Life-Cost (R&TLC) providing useful feedback to the enduser at a very early stage in design. The requirements can then be refined based upon discussions with the customer and re-analysis. A detailed design of the system is then carried out via detailed modelling and co-simulation. After finishing the design phase, coding using the MAA code generators and COTS code generators is performed. Testing using cosimulation with Hardware-In-the-Loop is executed, checking again the design and analysis. If everything is okay, then commissioning of the system with co-simulation support and Hardware-In-the-Loop can take place. If the system integrators are satisfied with the tests then the system is passed to the end-user to carry out acceptance testing. The R&TLC can finally be re-calculated using the latest up-to-date data. 2.1 Co-simulation in the Specification and Design Phase Co-simulation is used in the specification and design phase and also in the specification and design verification phase. In the Specification and Design Phase, the control system is taken

from concept design to final design. Initially, specifications for the hardware and software designs are gathered. Candidate designs are then evaluated and analysed allowing the control system engineer to narrow down the possible designs to one that will be taken forward. The final hardware and software designs are then completed. During the Specification and Design Verification Phase, the hardware and software designs are evaluated and analysed to confirm that they meet the technical requirements for the product.

Fig. 2(a): Co-simulation vision and 2(b) Example of Reliability and Through-Life-Cost Calculation

Fig. 2a shows how the co-simulation can be used during these phases. In this example, the COTS tools integrated via co-simulation are: ISaGRAF Enhanced this is used for discrete control system modelling Simulink this is used as a continuous system model simulation tool ARTISAN RtS this is used as a model building and management tool Microsoft Excel this is used for reliability and through-life-cost calculation

The ISaGRAF and Simulink tools can be used to rapidly prototype the control system by testing discrete and continuous laws developed in both ISaGRAF and Simulink against a model of the plant in Simulink. UML modelling (with the ARTISAN RtS tool) is used to define the hardware architecture redundancy for fault tolerance and the functionality of the control system software. Here, it is also possible to add health monitoring functionality. Fault injection scenarios can be injected into Simulink to test out fault detection, isolation and accommodation strategies that are defined. Excel is used to perform reliability and throughlife cost modelling of the system. Here information is extracted from the Simulink, ISaGRAF and UML models. At a later stage co-simulation with Hardware-In-the-Loop is possible allowing integration testing of real system components within the prototyping environment. In order to calculate automatically the reliability and through-life-cost of several hardware system designs within the co-simulation environment, the Reliability &Through-Life-Cost (R&TLC) tool is used as shown in Fig. 2b. This tool allows calculation of system reliability figures through extraction of data from the design tools. Also, this tool calculates automatically the cost of the system as the systems architecture is defined in UML and control functionality is defined in Simulink and ISaGRAF. For instance, information on Safety Integrity Levels (SIL) and

sensor types (intelligent and dumb) built into the UML model is extracted. Fig. 2 also shows an example of the reliability and through-life-cost calculation for three different control system architecture candidate designs for the marine application. To integrate the COTS tools and the MAA tools to form the co-simulation environment a middleware technology was used. Originally, the Common Object Request Broker Architecture (CORBA)[3] middleware was used, however in 2004, the new Object Management Group (OMG)s middleware standard Data Delivery Service (DDS) based on a publisher-subscriber design became available and it was a mandated standard for use across the Department of Defence (DoD) in the USA. The first DDS-compliant product was Network Data Delivery Service (NDDS) by RTI [4]. Since then, NDDS has been adopted for marine and aerospace applications in the USA. Thus, NDDS was adopted within the FLEXICON MAA toolset instead of CORBA. Timing performance analysis performed for the Marine application by the University of Sheffield showed that NDDS outperforms CORBA for both small and large data sizes. 2.2 Code Generation

Fig. 3: Code Generation Phase

At the implementation Phase the hardware and software designs are implemented. For rapid systems development automatic code generation is used. Fig. 3 shows hardware and software implementation in UML (ARTISAN RtS tool), the dynamic models implemented in Simulink and ISaGRAF. Following this, the code generators are used to produce target specific code. A Java Code Generator and the VHDL Code Generator were developed that can both produce code from Simulink or ARTISAN. In addition, traceability and consistency checking is performed prior to code generation. In order to generate C code, e.g. a controller in Simulink, the Real-Time Workshop is used together with the Tornado tool (VxWorks Realtime Operating System and NDDS communication). For the ISaGRAF tool, Target Independent Code (TIC) was automatically generated. There is also a Configuration Management tool (as shown in Fig. 3). This allows saving or retrieval of information to and from the User Design Database. This information includes the requirements documentation, systems models, the reusable template libraries used by the MAA code generators, the code generated by the different tools and also different cosimulation configurations which are accessed by using the System Builder. The System

Builder, as its name suggests, is used to put a system together flexibility on different COTS hardware platforms. 2.2.1 Java Code Generation The Java code generator was designed to generate Java code for a given design model. The design model can come from two sources: the SIMULINK model or an ARTiSAN class diagram. If starting from a UML class diagram the user can start the UML-to-Java code generation by choosing ARTiSAN RtS from the Model menu. If the user selects Simulink, the SIMULINK-to-Java code generation will be started instead. Fig. 4 shows the GUI of the FLEXICON MAA Java Code Generator for an ARTISAN class diagram. Prior to code generation consistency and traceability checks are performed against the user requirements.

Fig. 4(a): Java Code Generator, Fig. 4(b) Example Health Monitoring Using a Web Browser

A Health Monitoring (HM) Web Service was built as part of the system requirements of the Marine application. However, this service can be easily adapted for another application. The HM is used to control and monitor the application equipment using the Ethernet. The HM structure was modelled in the ARTISAN tool using a class diagram. Thus, sensors can be added easily. FDIA and control algorithm libraries are used to allow the functionality of the sensors to be built automatically in Java using the MAA Java code generator. Once the health monitoring application is generated in Java, the compiled Java classes can be invoked by the Health Monitoring Web Service. In order to access the Web Service, a Web browser is used. In addition to the sensor data other parameters and trends can be displayed. This allows equipment to be operated optimally providing fuel economy, high reliability and availability. 2.2.2 VHDL Code Generation The VHDL code generator tool (See Fig. 3) is able to generate VHDL code for a specified XILINX FPGA device. Similar to the Java code generator a SIMULINK model and an ARTiSAN class diagram can be used as the design source. Simulink models can be designed using special XILINX FPGA blocks that are entered into Simulink. The XILINX System Generator has thus been integrated into the code generator in order to generate VHDL code from a SIMULINK model. Once a model is selected, the VHDL Code Generator will invoke the XILINX System Generator to complete the rest of the process. In the case of ARTISAN, the class diagrams are used as the source for VHDL generation. Consistency checking is also performed before code generation. If the consistency checking detects a problem the code generation process will be terminated immediately.

2.3 System Builder The System Builder is a user-friendly software tool that enables design engineers to dynamically configure the co-simulation for a distributed control system. It also gives designers the capability to manage the various hardware platforms and software packages for system co-simulations. The System Builder allows addition, removal and modification of hardware platforms and software packages for a co-simulation project. This tool provides a Software task manager, a Hardware Platform Manager and a Network Component Manager to manage the hardware and software packages. The hardware and software packages are managed on a project by project basis; however, they can be reused by a new project by simply adding them into it. This allows rapid development of new systems.

Fig. 4: Example of a Distributed System Architecture Using the System Builder Tool

In order to build a distributed system architecture, the System Builder provides a graphical tool that helps the engineer to put the architecture together. The user simply drags and drops the various hardware and network components into a drawing board. The System Builder will detect the connections automatically and update the design information accordingly. Using the System Builder it is possible to dynamically assign software tasks to a selected hardware platform. Thus, multiple software tasks can be allocated to a hardware platform by simply dragging and dropping them into the box in the drawing board. This tool also uploads software tasks over the distributed network. This means that software tasks of a co-simulation project can be uploaded to the corresponding hardware platforms automatically through the distributed network. This is very useful when the distributed network covers a large area and there is long distance between the configuration machine and each hardware platform. This is often the case in a large organisation. An advantage of this if that the designer does not have to go to each node and copy files into it. This functionality is particularly useful when security is considered in the system configuration, since all software tasks are uploaded automatically and finger errors of the designer can be avoided.

3 Marine Application Demonstrator

Fig.5: High-speed vessel

To provide a challenging and complex application a high-speed vessel propulsion system has been considered. Rolls-Royce Marine provided the University of Sheffield with the functional and non-functional requirements of their new generation of jet-powered highspeed vessels. The example vessel utilizes five propulsion trains and a sharp long hull that allows the ship to cut through waves at 50 knots rather than ride over them (see Fig. 5). The ship can thus maintain higher speeds even in mid-ocean and bad weather. In such a vessel crossing the Atlantic should take around 90 hrs whereas existing fast vessels (32 knots) take around a week [2]. The vessel consists of five propulsion trains, each one with a MT30 gas turbine, a Kamewa waterjet and a gearbox. This type of vessel is controlled by a complex, distributed, real-time, safety-critical Integrated Propulsion Control System (IPCS) for control and monitoring. The IPCS allows the operator to control and monitor all the propulsion train equipment as an entire system from the two control consoles (Bridge and Switchboard). This supervisory control system, at the top level, interacts with local equipment controllers that control the gas turbines, gearboxes and waterjets. The equipment is controlled by a Local Control console that can control starting, normal stop, shutdown and speed of the gas turbines, speed of the waterjets and their direction, as well as engagement and disengagement of the gearboxes. 3.1 Hardware Description

Fig.6: Marine Demonstrator

The Marine Application demonstrator was configured as shown in Fig. 6. The demonstrator consists of several Pentium 4s (PCs and laptops) used to execute some of the COTS tools (Simulink/Stateflow and ARTISAN RtS), two HMIs (Bridge/Switchboard Control Console and Local Control PCs with Touch Screens), the MAA tools (Reliability & Through-Life-Cost, Health Monitoring Web Service and CAN Controller-comparator/monitor) and a virtual simulation of the ship. Another processor used is the Tecla PLC that contains the Supervisory Control program that communicates with the HMIs. The Supervisory Control Software was implemented in the ISaGRAF tool and downloaded directly into the PLC. The control algorithm of one propulsion train runs in a PowerPC processor under the VxWorks Real-time operating system. This control was modelled first in the Simulink tool and then C code was generated using the RTW. The C code also includes the VxWorks and NDDS functionality. A smart sensor runs in a FPGA board. This board communicates to the PowerPC via the CAN Controller tool which transforms Serial data into CAN data. The CAN Controller also takes CAN messages from a duplex CAN network and compares these messages for fault tolerance purposes. The validated CAN messages are then sent to the scaled model boat via a remote control. Wireless sensors are also included in the demonstrator. These are located in the boat monitoring vibration and temperature of the motors. The COTS tools and the MAA toolset communicate with each other via Ethernet using the NDDS middleware. Finally, a joystick is used by the captain to input the steering, reverse and throttle commands to the virtual vessel. 3.2 Software Description ISaGRAF Enhanced is used in the Supervisory Control program Simulink is used for continuous model simulation of the ship dynamics, simulation of four propulsion trains and fault injection Stateflow is used for fault detection, isolation and accommodation ARTISAN is used for the hardware architecture modelling and reliability calculations and also for model functionality definition Microsoft Excel is used for Reliability & Through-Life-Cost (R&TLC) calculations HMI of ISaGRAF is used for the Bridge Control Console C++ .Net is used for the Local Control Console Simulink, RTW, VxWorks and NDDS communication is used for the controller of one propulsion train Virtual ship navigation simulation is used to allow the captain to navigate Web Service technology is used for the Health Monitoring ICHM Monitor is used for the Bluetooth Wireless Oceana sensors

3.3 Demonstrator Operation To operate the vessel, the operator at the bridge has a touch screen (Bridge Control Console) and a joystick. Using these interfaces, the operator can operate the vessel in different modes, control the speed of the propulsion trains, steering and reverse bucket of the waterjets, and pass control to the Local Control operator. The operator at the Local Control also has a touch screen that allows him/her to control each of the propulsion trains separately. The Local Control controls the gearboxes, gas turbines and shaft state. Also, the local operator can request maintenance mode and gain control from the operator at the Bridge. This is to avoid engines being started during maintenance work. The joystick interface connected to the Virtual Navigator tool helps the operator at the Bridge to navigate the vessel.

The dynamic simulation of the ship is controlled by Simulink. Fault injection and the simulation of propulsion trains are also executed in Simulink. The boats waterjets are controlled via the code running in the PowerPC. For this, CAN messages are transmitted to the remote control of the boat. A smart sensor (FPGA) filters the raw data and sends it back to the Health Monitoring Web Service. Apart from the sensor data, other parameters and trends of the propulsion system are displayed in the Health Monitoring GUI that will help the maintenance operator to monitor the equipment. The architecture model of the application is displayed in the ARTISAN tool and this information is used for the R&TLC calculations. 4 Concluding Remarks In this paper, the development process used to produce a Marine application utilising the FLEXICON MAA toolset has been presented. Results collected by Rolls-Royce during the demonstrator activities showed that a reduction of 30% in development time was achieved using the MAA toolset. The use of automatic code generation has an impact on the coding phase but the really significant benefit comes from being able to present requirements via co-simulation to a customer. Co-simulation thus has a great impact on getting requirements right at an early stage of design. It can also be used very effectively to perform design tradeoff studies of different controller and engine configurations. The co-simulation with Hardware-In-the-Loop also has an impact on reducing testing and integration time. 5 Acknowledgements The authors gratefully acknowledge the financial support of the European Unions Information and Science Technologies programme for the FLEXICON project IST-200137269 and Rolls-Royce plc. Additionally, the authors gratefully acknowledge the support provided by ARTISAN, Borland and WindRiver. 6 References [1] Thompson, H.A., D.N. Ramos-Hernandez, J. Fu, L. Jiang, I. Choi, K. Cartledge, J Fortune and A. Brown. (2007) A Flexible Environment for Rapid Prototyping and Analysis of Distributed Real-Time Distributed Safety-Critical Systems. Control Engineering Practice Journal, Vol. 15, Issue 1, pp. 77-94. Thompson H.A., D.N. Ramos-Hernandez, K. Cartledge, J. Fortune and A. Brown (2003). A Flexible Control Systems Development and Integration Environment for Distributed Ship Control, 13th International Ship Control Systems Symposium (SCCS), Orlando, USA, April 7-9. http://www.omg.org/gettingstarted/corbafaq.htm Access date: 06/06/05. http://www.rti.com/index.html Thompson, H.A. and D.N. Ramos-Hernandez (2004). A Flexible Control Systems Development and Integration Environment for Distributed Control. Proceedings Sixth Portuguese Conference on Automatic Control, Controlo 2004, Faro, Portugal, June 7-9. http://www.mathworks.com/products/simulink/ http://www.isagraf.com/ http://www.artisansw.com/

[2]

[3] [4] [5] [6] [7] [8]