Embedded SystemsB. Vogel-Heuser

Oldenbourg Industrieverlag

Embedded SystemsProf. 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 ContentsM. 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 ProgramsDr.-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-ProgrammenDie 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 = 1Figure 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

M

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). U E 0.6 U E 1.2 ...

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.

...

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 machinesDipl. Inf. (FH) Sebastian Diehm, ELAU AG, Software Development

Supporting the design of drive applications for packaging machinesEngineering 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 MaintenanceDr. Thomas Dreyer, Aucotec AG, Production CAE Andrea Schrder, FGH e.V., dpt. Power Equipment Technology

iSAS die Integration von Engineering, Inbetriebnahme und WartungDie 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

1

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 DiagrammS-TEN System Registration Registry Security