Rapid Prototyping Test-Bed of Logic Control Solutions for Reconfigurable Manufacturing Systems

Emanuele Carpanzano ITIA – National Research Council

Via Pisani, 1 27029 Vigevano (Pavia) e.carpanzano@itia.cnr.it

Andrea Cataldo, Marco Donà ITIA – National Research Council

Via Pisani, 1 27029 Vigevano (Pavia)

a.cataldo,m.dona@itia.cnr.it

Abstract

To properly deal with the increasing complexity of industrial distributed and agile manufacturing control systems, the use of methods and tools that support the designer in the definition, implementation and verification of intelligent logic control software is more and more necessary. Nowadays, many different software tools are available to face the rapid prototyping and closed loop simulation based verification of an automation system control software. Not so many hardware architecture are available to implement an hardware in the loop simulation where the controlled device consists of a real small scale industrial plant. In the present work a modular test-bed architecture which allows a complete simulation based verification of manufacturing plants logic control systems, and then its rapid prototyping, is discussed, whit reference to an application example in the shoe manufacturing sector.

1. Introduction

The ITIA laboratory in Vigevano is an industrial settlement characterized by an innovative plant for custom made shoes industrial production. Together with the actual plant, the industrial settlement is provided by an automatic control laboratory used for analyze, specify, design, implement and test advanced control system strategies for manufacturing plants.

The main requirement that leads to the study, design and implementation of an automatic control laboratory in the shoe production plant in Vigevano comes from the needs to verify the control software of the plant (in particular the logic control strategies) using closed-loop simulation techniques, in particular by “hardware-in-the-loop” simulations by means of Discrete Events Systems mathematical models. In order to satisfy the main functional requirement, knowledge in continuous and logic controls, in dynamic and discrete event simulation, electronic technologies for automation

systems (sensors, actuators, control systems and automation) are necessary. Furthermore hardware and software resources are needed in order to build a test-bed for the control algorithms verification. A possible list of such a resources is: − the small scale plant of the process to be controlled − the simulator of the process (mechatronic model or

dynamic simulation) − the control system emulator (running on the

control device – driver, CNC, PLC – or dedicated simulation)

− communication support among different control system devices

− cabling system connecting the control with the process

At last, opportune test cases must be generated so to verify the control code as well as interpret the consequent results.

The present work describes as first the prototyping test-bed, in particular its three different areas are illustrated.

Then the development and testing phases of a manufacturing plant logic control software are presented, by highlighting the use of the hardware devices and software tools.

An application example is carried out with reference to a molecular transport line.

At last the conclusions and future works are indicated.

2. The prototyping test-bed

2.1. General Architecture In order to realize “hardware-in-the-loop”

simulations it is necessary to design a system (control system area) that emulate the automation system control functionalities and that is connected to a second system (process simulator area) that simulate the physical behaviour of the real plant.

In particular the designed logic control, before to be configured into the plant control system devices are tested so to reduce the plant commissioning time and

0-7803-9402-X/05/$20.00 © 2005 IEEE

then the associated costs. The tests are carried out by emulating the control system logics in a opportune hardware and software environment. Such control system logics receives the information about the controlled process by means of measured process variables and they elaborate specific control actions, by means of input/output board.

Using more or less detailed models the behaviour of the process to be controlled is modelled. The main purpose of the process simulator is to verify the designed control system logics correctness by interfacing it to the control system. In response to the stress given from the control system (control actions) the process model evolves by modifying its variable values (among them there are the measured variables or the variables used as feedback for the control system).

In order to allow the information exchanging between the control system area and the process simulator area it is necessary to create an opportune communication structure.

It must be highlighted that the mathematical models used in the process simulator simplify the physical behaviour of the real plant: for example, normally, actuators or sensors failures are not considered in the models. In that cases, that happen during the real plant working function, it is not possible to verify the designed control system response. To be able do that it would be useful to have a small scale plant build by mechanical and electronic modules that reproduces the same real plant behaviour. Such a small scale device is intrinsically physic so it may not live out of consideration from unexpected behaviours deriving from possible failures that could happen on a real plant. The advantage respect the process simulator is that such working function conditions must not be modelled in any way. Therefore a third small scale plant area is present into the test-bed architecture, area which can be connected with the control system one, as like as it can be done for the process simulator area.

In figure 1 the general architecture of the test-bed is sketched.

Process simulator area

Small scale plant area

Matlab LabVIEW

Wires

Matlab Dymola

Control system area

Target

I/O I/O

Target

SWITCH Ethernet Ethernet

Host Target

Host

(PXI)

Wires

Figure 1. General test-bed hardware and software architecture

2.2. Control system area The control system area is based on two

environments that, independently one to each other, allow emulating both continuous and logical control logics. The environments are Matlab (by MathWorks) and LabView (by National Instruments). Both these systems are characterized by a structure based on two PC (more generally by a PC and a processor used to run the control code). The licenses of the software environments are installed on the HOST PC on which the control software is designed, configured and implemented. The second PC (TARGET) is used to run the designed control code in soft real-time.

Matlab environment. It uses a HOST PC and a TARGET PC. Once the

control system has been designed, configured and implemented, the regarding control software is downloaded on the TARGET PC, which is started by means a boot disk to run a specific real-time operating system. The HOST PC is able to monitor the control logic algorithms running on the TARGET PC by means of RS232 or Ethernet connection available for every PC located in the control laboratory. The TARGET PC has three digital Input/Output boards (NI PCI-DIO-96 by National Instruments), each one with 96 channels. It is possible to set up the channels as input or output grouped in 8 channel blocks. Through these boards the TARGET PC exchange standard TTL electric signals with the process simulator or with the small scale plant.

LabVIEW environment. It uses a HOST PC and a PXI device that looks like

an industrial PC on which a real-time operating system runs. Once the control system has been designed, configured and implemented, the regarding control software is downloaded on the PXI. Differently from the Matlab environment, PXI doesn’t require a boiot disk for starting because it already runs a real time operating system. By the Ethernet the HOST PC is able to monitor the control logic algorithms running on PXI. The PXI has three digital Input/Output boards (NI PXI-6508 by National Instruments), each one with 96 channels. It is possible to set up the channels as input or output grouped in 8 channel blocks. With these boards the PXI exchange standard TTL electric signals with the process simulator or with the small scale plant. This environment provides a tool (LabVIEW Simulation Interface Toolkit) for the integration with Simulink (a Matlab tool). In this way is possible to monitor a control software module developed in Simulink with LabView environment or transform it in a native LabView object and run it in real-time on the PXI.

2.3. Process simulator area The process simulator area is based on two different

software tools that can be integrated one into the other.

In this test-bed area it is possible to model manufacturing plant by means of discrete event systems. The two software tools used are Matlab (The MathWorks) and DYMOLA.

On the first PC (HOST) the two software licenses are installed and on which the process models are configured. The second PC (TARGET) is used to run in soft real-time mode the compiled software of the process model.

Matlab environment. As in the control area, process simulator area is

provided by Matlab environment for design, configuring and implementing simulation models of industrial processes. Hardware and software architecture is the same of the control system area. Also in the process simulator area the TARGET PC has three digital Input/Output boards (NI PCI-DIO-96 by National Instruments), each one with 96 channels. It is possible to set up the channels as input or output grouped in 8 channel blocks. With these boards the TARGET PC exchange standard TTL electrical signals with the control system area.

DYMOLA environment. It is a dynamic simulator with the same function of

Simulink, that is building simulation models of industrial plants. This environment does not allow to generate executable code to be run on TARGET PC. It is provided of two toolbox so to integrate its models with Simulink ones, obtaining in this way software code running on TARGET PC monitored by Matlab. Therefore, through Matlab environment, it is possible to interface Dymola process models with the control system by mean of the I/O boards.

2.4. Small scale plant area Small scale plant is made of mechanical devices

provided by actuators and sensors [4]. The connection of these actuators and sensors with the control system area is obtained by mean of physical I/O boards present inside the TARGET PC and the PXI device. Obviously the technological compatibility among actuators, sensors and I/O board is fundamental. The used I/O boards are based on TTL logic standard, that is not always the same for actuators and sensors located on the small scale plant.

2.5. Communication structure Connection between control system area –

process simulator area The connection between these areas is not difficult

because they must be interfaced identical I/O boards one to each other. This is performed by connecting each I/O board of the control system area (either Target PC’s or PXI’s) with the complementary I/O board located in the process simulator area by means of dedicated multi-cables (these cables does not connect +5V potential pins of the interfaced I/O boards because

the TARGET PC PCI buses power lines would be put in short circuit.

Particular attention must be put in the 8 channel groups configuration (port configuration) of each I/O board. If a port is set up as input on a I/O board of a TARGET PC, for example the control system TARGET PC, the corresponding one on the simulator TARGET PC must be configured as output. According to that, a possible I/O board configuration could be the following one: − Control system area (both TARGET PC and PXI)

o Board 1 Port 0-5 Input

Port 6-11 Output

o Board 2 Port 0-5 Input

Port 6-11 Output

o Board 3 Port 0-5 Input

Port 6-11 Output − Process simulator area (only TARGET PC)

o Board 1 Port 0-5 Output

Port 6-11 Input

o Board 2 Port 0-5 Output

Port 6-11 Input

o Board 3 Port 0-5 Output

Port 6-11 Input With this configuration, the functional compatibility is guaranteed by simply interfacing the corresponding I/O boards 1, 2 and 3 of the two areas, see figures 2 and 3.

Process simulator area

Matlab LabVIEW

Matlab Dymola

Control system area

Target

SWITCH Ethernet Ethernet

HostTarget

Host

Board 1 (INPUT)

Board 2 (OUTPUT)

Board 3 (Port 0-5 INPUT) (Port 6-11 OUTPUT)

Board 1 (OUTPUT)

Board 2 (INPUT)

Board 3 (Port 0-5 OUTPUT) (Port 6-11 INPUT)

Figure 2. Connection between PCs TARGET.

Process simulator area

Matlab LabVIEW

Matlab Dymola

Control system area

PXI

SWITCH Ethernet Ethernet

Host Target

Host

>Board 1 (INPUT)

Board 2 (OUTPUT)

Board 3 (Port 0-5 INPUT) (Port 6-11 OUTPUT)

Board 1 (OUTPUT)

Board 2 (INPUT)

Board 3 (Port 0-5 OUTPUT) (Port 6-11 INPUT)

Figure 3. Connection between PXI and PC TARGET.

Connection between control system area – small scale plant area

To provide electrical connections, special 100 points clamps allow connecting 100 electrical wires (96 signal, 2 grounds and 2 +5V power lines) to the corresponding 100 pins of the multi-cables coming from I/O boards placed on the TARGET PC or PXI devices, see figure 4.

Small scale plant area

Matlab LabVIEW

Control system area

Target

SWITCH Ethernet

Host

PXI

Board 1 (INPUT)

Board 2 (OUTPUT)

Board 3 (Port 0-5 INPUT) (Port 6-11 OUTPUT)

Multi-cables

Wires

Figure 4. Connection between PXI / PC TARGET and small scale plant.

The configuration of the connection between the control system area with the small scale plant area depends on the electrical characteristics of the used sensors and actuators because of their technology. − TTL input signal acquisition

Acquiring a signal based on TTL logic does not require external power, because TTL logic provides the needed power to the signal. This acquisition is simply obtained by connecting the positive potential of the TTL circuit to a specified acquisition channel of the I/O board; the ground potential of the TTL circuit to the ground of the I/O board, see figure 5.

Figure 5. “TTL” input signal acquisition.

− “Dry contact” input signal acquisition The acquisition of a “dry contact” signal (for

example a switch) is obtained by connecting the terminals of the contact between the acquiring channel of the I/O board and the ground of this one, see figure 6. Actually, when configured as Input, the acquiring channel measures the difference potential at the contact ends by providing a 50µA current flowing through it towards ground.

Figure 6. “Dry contact” input signal acquisition.

− “TTL” output signal command Driving a TTL logic based circuit, see Figure 7,

does not require resistances in the command circuit since they work with standard potential threshold. The constraint that must be taken into account regards the current flowing through the command circuit, which value must not exceed the maximum allowed for the single board channel (4mA). The board channel set up as Output behaves as an ideal voltage generator providing a maximum current up to 4mA.

Figure 7. “TTL” output signal command.

− “No TTL” output signal command As like as TTL circuit driving the board channel

configured as Output can be considered as an ideal voltage generator providing a maximum current of 4mA. If the load requires a current higher than 4mA, an external power supply is necessary, see figure 8.

Port i(OUTPUT)

GND

50, 100

45

43

41

I/O Board

Board Clamp

NonTTLLoad

R

Figure 8. “No TTL” output signal command.

In this case it is a good procedure to decouple the load from the I/O board by means of an opto-isolator. Then it is enough to polarize the diode of the opto-isolator input circuit to drive the output one. An opportune resistance R must be inserted to limit the flowing current, as showed in figure 8. The value of the resistance R is calculated by means of the following formula:

IdVdVccR −= , with Id≤IMax

where Vd is the characteristic diode load voltage

while Id is the current flowing through it. It must be considered that Id must be less than IMax that is the maximum current flowing through the single board output channel (4mA).

3. Development and testing methodology

Nowadays, reliable and flexible automation systems are a crucial point for competitiveness of manufacturing systems [1]. Strong reusability and quick reconfigurability of developed control solutions are also fundamental elements to achieve agility, in order to reduce the costs and times needed to design and realize new production systems, or to modify existent ones. Such objectives can be reached by structuring the control solutions according to a modular approach and by encapsulating in each module the intelligence needed to provide a set of functionalities to other modules of the overall automation system. The structured development methodology for the design of manufacturing logic control systems that achieve the

mentioned objectives [5] can be applied to an application example like a molecular line control software development. In detail, the methodology is based on the following main design phases.

3.1. Specification, design and implementation In the first phase the process to be automated is described and the activities to be performed and the objectives of the automation system are defined. Often this task is carried out by means of informal languages. Sometimes formal languages are used so to have a standard representation of the automation system requirements and a more rigorous specification documents. To achieve properties like modularity, scalability, integrability and reconfigurability of the production system so increasing the overall flexibility of the plant, object-oriented concepts are often exploited for the control system development [6]. Moreover the tasks and the essential functions of the supervision and control system are defined and the control strategy is established.

The supervision and control systems are developed through suitable reference models for both the architectural and the functional design. In order to have the industrial plant characteristics above mentioned, a modular design approach is followed [7], that is an approach structured in different and well defined phases.

Then, the control code is generated, in automatic way or by translating the design specification.

3.2. Control software verification, integration and testing

In order to check the control software rightness, discrete simulation based methods are performed so to verify if the designed control functions meet the requirements [2].

Closed loop simulation The first step to verify the control software code

regard the interfacing of it with a simulator, by using the same environment. During this phase it is possible to eliminate the rough errors present in the control algorithms. In this case only the algorithms ideas can be verified because the control system is not physically connected with any other hardware device.

Hardware in the loop simulation By connecting the two PC TARGET as showed in

figure 2 or the PXI and the PC TARGET as showed in figure 3, the control software can be verified not only from the point of view of the algorithm ideas but also the communication layer can be tested. In particular the time delay introduced from the communication support influence the control algorithms evolution, allowing the designer to test the communication as like as on the real plant.

A further step towards the hardware-in-the-loop simulation consist in connecting the control system to

be teste to the small scale plant. The difference between the closed loop simulation with the PC TARGET simulator and the use of the small scale plant regards mainly the physical phenomenon that are not easily modeled in a process simulator (friction, damping, material elasticity, etc.). Moreover, even then the process model is accurate, often is very difficult to parameter it. On the contrary the small scale plant is a real model plant with the different mechanic and electronic components that are interfaced to the control system. This implies that the possible problems that can occur during the plant working function are already intrinsic in the small scale plant, by allowing to test the control code also respect possible components failure (devices mechanical breaking, electronic board malfunction, etc.)

The control code is implemented on the target controllers, and it is checked if the control system works on its devices, and if all the system's requirements are met.

4. Application example

An application example to apply the hardware-in-the-loop simulation by using a small scale plant to test a control software code has been carried out.

The small scale process to be automated and present in the ITIA automatic control laboratory consists of an innovative transport line, see figure 9, that is used to move the blocks representing semi-finished shoes from a machining station to another one according to a predefined operation schedule.

Figure 9. Small scale plant.

The innovative molecular structure of the transport line of the making department [3], see figure 10, enhances the modularity, scalability, integrability and reconfigurability properties of the production system, so increasing the overall flexibility of the plant. The basic element of the molecular structure is the “Tern”, which is constituted by two rotating tables, called “Table” and “Island”, and by a rotating three arms

manipulator. The Terns move the parts to be worked while the workmanships are performed by the machines collocated around the Islands. An initial warehouse inserts the forms in the system, and a final storehouse picks up the produced shoes. The Table is used to direct the semi-finished shoes either to the next Tern or to the Island of the same Tern. Each table houses twelve slots on which the semi-finished shoes can be placed. Moreover, it moves backward the lasts flowing back towards the warehouse (the last is the object around which the semi-finished shoe is built upon). The Island directs the semi-finished shoes towards the different machining stations, laid around the Island itself. Each island instead houses twenty-four slots. The transportations of the semi-finished shoes and lasts between Tables and Islands are carried out by the manipulators. In particular the reconfigurability of the system comes from the possibility to easily move and then re-design the mechanical structure of the system and then its logic control strategies.

16

1 21

1

2

31

7

1

1

2

3

17

1 19

1

2

3 1

7

1

1

2

3

1 8

1

1 2

3

1

6

1

1

2

3

TERN 1 TERN 3

TERN 2 TERN 4

TERN 5

TERN 6

Figure 10. Molecular transport line.

The transport line is controlled by interfacing the PXI device with the plant by the digital I/O boards and using the LabView software. The working stations are controlled by using the Matlab environment. Specific connection have been cabled allowing the communication between the two control systems by implementing an opportune communication protocol.

In this application example the user defines a sequence of operations (rotations, pusher actions, operations of working stations, all these operations are coded by means of specific LabView functions) and starts the control systems that executes it. The same application allows the visualization of the feedback signals from the field so it is possible to monitor the small scale plant working function.

The main part of the software control code has been developed by LabView so it is quite easy to setup a graphical user interface. The user creates a sequence of work, choosing the single operation to be done from the devices. In the first section of the user interface, see figure 11, it is possible to define the work sequence by filling the rows of an array with the operation type and the number of its repetitions. The operation types are

available in a drop down list so it is not necessary to know the physical connections (i.e. hardware address of digital I/O board) or the underlying code to make a device operating.

Figure 11. Work sequence definition.

The graphical user interface allows to monitor the status of every single sensor placed on the field and to drive each actuator during the running of the control sequence, see figure 12 in which part of the graphical user interface is showed. In particular Led are used to represent switches status while levers switches are used to drive the actuators. The monitoring section is split in six pages, one for each tern, for a better visibility of singles signal status.

Figure 12. Graphical user interface.

The last section of the interface allow to monitor the working stations status, see figure 13. This is performed because of the hard wired connections between the control systems, as stated above.

Figure 13. Working station monitoring.

The small plant, as the real one, has a modular structure an this has allowed to develop a modular control code, or a control code organized in modules each one with specific characteristics. For the transport line, basic functionalities have been specified and coded as standalone modules; these functions are: − rotations of tables − pusher actions − operation of working station

Each module can be invoked by passing to it some parameters that identify uniquely each plant device. In this way the code is highly reusable and the reconfiguration of the system is obtained by simply changing the sequence of work.

Another benefit of this approach is the minimal effort required to insert a new operation type. This can be done by coding the new operation in a new module and updating the list of choices used to build the sequence.

5. Concluding remarks

In the present work a test-bed for the control system logics verification has been described. In particular the hardware and software architecture has been analized.

Future works regard the extension of the control system area by mean of a soft-PLC tool, connected to a target PC, able to configure control system logics according to the IEC 61131 standard. Moreover an industrial PLC connected to remote input/output board via fieldbus, so to carry out activities and comparisons about different communication protocols.

References

[1] Bossi D., Carpanzano E., Cattaneo della Volta V. and Tilbury D. Modular Design of Logic Control Functions for RMS through Petri Nets and Sequential Function Charts. Proc. CIRP 2nd International Conference on Reconfigurable Manufacturing, Ann Arbor, Michigan, USA, paper A-22, 2003.

[2] Carpanzano E. and Ballarino A. “A structured approach to the design and simulation-based testing of factory automation systems”, Proceedings of the IEEE International Symposium on Industrial Electronics, ISIE2002, L' Aquila, Italy, July 8-11, pp. 181-186., 2002.

[3] Carpanzano E., Cataldo A., Airoldi F., Carlino G. Intelligent manufacturing logic control systems development: a case study, IMS 2004

[4] Donà M. Ideazione, progettazione e sviluppo di un dimostratore meccatronica per sistemi manifatturieri riconfigurabili. Tesi di laurea, Università degli studi di Padova, 2004

[5] Ferrarini, L. and Carpanzano, E., “A Structured Methodology for the Design and Implementation of Control and Supervision Systems for robotic applications”, IEEE Transactions on Control Systems, 2002

[6] Maffezzoni, C., Ferrarini, L. and Carpanzano, E. “Object-Oriented Models for Advanced Automation Engineering”, Control Engineering Practice, n° 7, pp. 957-968, 1999.

[7] Park, E., Khargonekar, P., and Tilbury D. A Modeling and Analysis Methodology for Modular Logic Controllers of Machining Systems Using Petri Nets Formalism. IEEE Transactions on Control Systems Technology, Vol. 31, N° 2, pp. 168-186, May 2001.