See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228971344

Factory Layout Planner

Article · January 2010

CITATIONS READS

3 1,466

6 authors, including:

Giovanni Dal Maso Paolo Pedrazzoli

TTS - Technology Transfer System S.r.l. University of Applied Sciences and Arts of Southern Switzerland
12 PUBLICATIONS   70 CITATIONS    53 PUBLICATIONS   367 CITATIONS   

SEE PROFILE SEE PROFILE

Diego Rovere
University of Applied Sciences and Arts of Southern Switzerland
16 PUBLICATIONS   102 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Factory ECOMATION View project

CTC- Close To Customer View project

All content following this page was uploaded by Paolo Pedrazzoli on 21 May 2014.

The user has requested enhancement of the downloaded file.

 Factory Layout Planner
Ilario Francesco Ceruti1, Giovanni Dal Maso2, Giorgio Ghielmini2,
Paolo Pedrazzoli2, Diego Rovere2
1
Technology Transfer System s.r.l., via Pacini 15, 20131 Milan, Italy, ceruti@ttsnetwork.com
2
University of Applied Science of Southern Switzerland - SUPSI, Galleria 2, CH-6928 Manno,
Switzerland, {giovanni.dalmaso, giorgio.ghielmini, paolo.pedrazzoli, diego.rovere}@supsi.ch

Abstract
The Manufuture strategic research agenda identifies two fronts of intense and growing competitive pressure for
European manufacturing: in the high-tech sector, we face other developed countries and, on the other hand, in more
traditional sectors, low-wage countries pose a serious threat. One of the response envisioned and strongly promoted
is the development of ground-breaking Information and Communication Technologies meant to support new
approaches to industrial engineering. Clearly drawing inspiration from this vision, the tool presented in this paper, the
Factory Layout Planning, aims to be such kind of technology, enabling the multi-site, multi-level distributed design
of factory layout and performance simulation. This paper gives an overview on the main features, in terms of
concrete software characteristics of this tool, that can be considered one of the cornerstones for the Next Generation
Factory.

Keywords
Digital factory, layout planning, distributed, simulation

1 Introduction
Seek To Reform The Environment, Not Man [Full82].
This famous sentence clearly mirrors the objective of our research: we hold out to innovate the
environment in which a factory designer perform his activity, without constraining his creativity
(the man). The availability of innovative technologies, such as distributed applications or multi-
touch technologies, is enhancing the possibility to support collaboration in software applications,
and offers the opportunity to create innovative environments.
The tool, described in this paper, wedge technologies to become a real new environment
supporting the design lifecycle of a factory layout. The Factory Layout Planner (FLP) allows the
multi-user, network-based visual creation and management of a factory layout: the design team
can co-operate on the same layout both acting on a common multi-touch device, or collaborating
from different part of the world.
[Bat07][Boe06] have envisioned and presented the rise of a new generation of planning tools,
such as the FLP, as concrete solutions towards the cost-effective and rapid creation, management
and use of the Next Generation Factory. Moreover, a key element in this revolution, is the
capability to provide an “adherent to reality” representation of manufacturing process, as gain
highlighted in the “Manufuture Strategic Research Agenda” [EC04].
Based on this preliminary considerations, hereinafter the reader can find a complete overview of
the main features of this software solution: functionalities available, interaction modes, standards
adopted and hints on design choices, so to provide a comprehensive picture of the FLP.

2 State of the Art

State of the art technology in layout design and simulation is represented by some huge software
suites that aim to provide a comprehensive support from the product to the process design and
management. The most important references are Dassault Systemes – Delmia V6 [DEL], and
Siemens - Tecnomatix 9 [TEC], that support both layout design and simulation, and integrate
tools for task programming and production process management; Visual Components [VIS]
supports 3D components programming and assembly for an easy layout design and simulation. It
does not support any type of collaboration.
Other tools that historically were born to support Discrete Events Simulation are moving towards
3D simulation. Some examples are Rockwell Automation – Arena 13.0 [ARE], a DES software
for complex production plants, whose 3D design and simulation of layout is partially supported
by additional packages; Simio Simulation Software [SIM], a DES software with built in support
to 3D layout assembling but limited simulation capabilities. Some minor 3D configuration
software tools have been recently developed for product variants management. These tools can
be easily adapted to layout design but they don’t support any simulation of the plant and are not
meant to be collaborative.
Additionally, layout planning is considered in many different European projects. Some of them
considered “ad hoc” solutions for simulating validation scenarios factories (EuroShoe) while
others where more related to the planning of a generic production plant like Difac (Digital
Factory for Human Oriented Production System, http://www.difac.net/). Eupass (Evolvable
Ultra-Precision Assembly Systems, http://www.eupass-fp6.org/) project dealt with the
reconfiguration of single production lines, while in CEC-made-shoe (Custom, Environment, and
Comfort made shoe, http://www.cec-made-shoe.com/) discrete events simulation was applied to
the analysis of the material and products flows.
In KoBaS (Knowledge Based Customized Services for Traditional Manufacturing Sectors
Provided by a Network of High Tech SMEs, http://kobas.ttsnetwork.com/), 3D simulation was
meant to support huge layout simulations but the aspects of the layout composition and DES
analysis were not supported. The aspect of multi-site factory and related logistics planning was
not considered in these previous projects, while it is present in the VFF (Virtual Factory
Framework, http://www.vff-project.eu/) project, in which the layout management represents a
keystone concept of the project.
Moreover, no other European project applied large multi touch devices to the collaborative
aspect of the factor layout planning. Advancement over SOA FLP innovation is mainly related to
the collaborative aspects, and to the integration of the new touch technologies into the layout
design process. In fact, collaboration is supported at 2 different levels:
• remote: FLP is a distributed application, hence providing means to teams at different
locations to work at the same time on the same layout simulation;
• local: FLP moves the 3D simulation on multi touch table devices (also studying the new
gestures related with planning), then many individuals of the same team can actively
cooperate on the same layout using the same device.
Moreover, FLP aims at being an integrated solution providing both DES and 3D simulation as
built-in distributed functionalities.

3 Client Application Showcase

The Factory Layout Planner is a client/server application that enables the collaborative
development of a factory layout. There are three key features of the FLP: the 3D visual editing
of the layout, the possibility to act on the same layout in a distributed environment, the ability to
perform Discrete Events Simulation (DES) on the layout that the user is composing.
As mentioned the collaboration on the layout can be both remote and local: while the first allow
user distributed all over the world to cooperate in the layout creation, the latter allow users to act
on the same device in the same time on a common model. This functionality can be achieved
thanks to the integration of multi-touch tables.
The FLP aims to cover both the aspect of the collaboration issue, that is a more sensible issue in
the nowadays global market; despite this in this paper only the fist aspect of the collaboration
will be deeply described: the possibility to collaborate on a common layout, in the same time,
over a network architecture.
The architecture of this application is a two-level architecture with a fat client: the server is
mainly a synchronization manager and a repository, while, on the client side, the most of the
computation is performed: this enables the optimal usage of the computing resources. As an
example, with this architecture it is possible to minimize the network data flow and exploit the
hardware potentiality of the client (e.g. graphics card). Performance is a key factor when dealing
with complex 3D model and real time requirements.
The following pictures shows the main user interface elements of the FLP.

Figure 1 : Connect dialog

Figure 2 : FLP client application

The user connects to a server using the dialog show in Figure 1 and can choose to create a new
document or edit an existing one. The documents are stored on the central server and the
application maintains an updated local copy. Once the connection to the server is established, the
application also synchronizes its local copy of the catalogue of available equipments (templates)
that are presented in the catalogue browser (left of the working area in Figure 2). This update is
done in background, without blocking the usage of the application while the entire catalogue is
downloaded. On the contrary, if some template is required to open an existing document, the
download of such element is prioritized to ensure that the latest version of the resource is
available.
Beside the catalogue, an inventory of factory elements represented as a hierarchical tree list is
available with a list of all the users currently connected to the same server. The catalogue is
managed with drag & drop support: new objects can be added to the virtual scene simply
dragging the icon from the catalogue to the 3D view. Properties of any element, its position and
orientation, are all available by double clicking on the element itself.
Most of the application window is occupied by the 3D view of the layout. The user can interact
with it using the mouse and the desired interaction mode:
• Camera: in this mode, the mouse is used to explore the layout: pan, zoom and rotate
function are available for natural navigation in the 3D scene.
• Edit: this is the main mode used to modify the layout. The objects can be selected,
grouped, moved, rotated and their properties viewed and edited. A snap grid can
optionally be enabled to assist the positioning of the objects.
• Connection: when this mode is enabled, the user can connect objects to create logical
relationship useful for the DES simulation. The available ports are shown and the user
can connect then tracing lines from one port to the other.
3.1 Data storage
The catalogue is a collection of different type components (machines, resources, operators…)
used for the layout, described by a set of files. For each component the FLP stores:
•Image file (JPEG) used to visualize the component in the catalogue browser
•XML file defining objects relationships with frames1 and joints and referring to
geometrical aspect (3D XML)
• VRML file to define the 3D appearance of the objects (such file format is usually easy
exportable from any CAD system)
• Java class in a JAR file that describe the behaviour of a component
• Properties file for DES parameters and ports.
An important aspect of the data concerns naming. In fact the FLP can handle components
without the need of knowing their details (the catalogue is dynamically extensible without
changing the FLP); further the files building a component come from different independent
sources (e.g. CAD system, XML editors, Java programming environment). For those reasons, it
happens that the same item (port, frame or property) is cross referenced in more than one file.
This requires a consistent naming within a template.
For example: a new component “roughing machine” has a specific parameter “roughing-level”.
Defining this parameter as a property in the properties XML file enables the FLP to show the
parameter in a dialog and let the used change its value. The same parameter is used in the Java
class defining the behaviour of the component during DES simulation.
Finally all the files mentioned above are listed in a catalogue.xml with the version used by client:
this technique allows to discover if the user local copy is synchronized with the server one. Thus
for each item it is specified the template name, a label, the URL of the 3D XML, the URL of the
preview image, the URL of the properties file, the template category, a description, the version
number and a list of URLs of required resources. The XML of the catalogue is validated against
XSD [XSD04] (catalogue.xsd) to ensure the data to be coherent with the data model used by the
FLP.
The FLP uses a XML file for each factory layout. This file contains all the instances of objects
that are in the layout. Those objects are described by an identifier (ID), a reference template
name, the properties values, a position and all the connections to other objects.

1
Positioning reference: represents a reference system in terms of location and orientation
Once again, data binding between files is done by an unique name: data contained in the
catalogue are referred thanks to the template name, that is unique in the layout XML file. Thus,
for a complete description of the system, both the layout and the catalogue information are
needed.

4 Distributed Collaboration Engine

At the core of the distributed collaboration engine, there is a set of interfaces that are
implemented by the server and client applications. The choice of RMI (detailed in the next
chapter) as the client/server communication protocol, brings the FLP undoubted advantages. For
this standard protocol, an application (e.g. the client) needs only to know interfaces to call on a
remote application (e.g. the server), leaving the mechanism of communicating with the real
object implementing the functionality to the Java RMI framework.
Thus a description of the interfaces available is here reported: this allows the reader to have a
showcase of the server functionalities, that actually realize the distributed collaboration that is a
key brick for the FLP.
The entry point of this engine can be surely represented by the IModelServer interface: this
allows the client application to get an object representing the catalogue (IFactoryCatalogue), a
list of existing models, and to open model obtaining a IFactoryModel object.
The IFactoryCatalogue object contains the information necessary for the connection to the FTP-
server, through which the catalogue files can be downloaded thanks to a standard FTP session.
This session is, for example, initialized to synchronized the local and remote copy of the
catalogue.
The communication from the client to the server is done using the IFactoryModel interface,
while the communication of the server to the client are done by instances of the IModelObserver
interface.
The IFactoryModel interface (that is on the server), offers the following functionalities:
• save: Saves the current state of the model is saved on the server and can be reused later
on.
• getFactoryElementIds: Returns the list of the identifiers of the factory elements that
populate this model. Either the element at root level only or all the elements.
• getFactoryElement: Accesses the stub of the factory object on the server through the
object ID.
• addFactoryObject: Adds a new factory object defined by the corresponding template
name to the model in the specified position.
• removeFactoryElements: Removes the specified elements from the model.
• modifyFactoryObject: Changes some properties for the specified factory object.
moveFactoryElements: Moves the specified factory objects inside the model.
• group/ungroup: Group a list of elements together.
• onMotionFactoryElements Gives the temporary position of a list of objects on motion.
• connectFactoryObjects: Connects two factory objects by defining a from and a to port. It
also check if the ports can be connected (i.e. if the ports are of a compatible type and they
are not already used).
• disconnectFactoryObjects: Disconnects two factory objects. If the objects are not
connected, no notification will be sent nor an exception will be arisen.
• lockFactoryElement/unlockFactoryElement: Requires or release a lock on the specified
factory object. Needed to perform operations that change the state of an object.
• Undo/Redo: Requires a undo/redo of the last operation done by the client. Cannot
undo/redo an action done by others. Can be called more than once. Undo/redo will fail if
there is no more actions that can be undone/redone or if another client changed the model
 in a way that an undo/redo would result in an inconsistent state. In a collaborative
environment it is not usual that different clients operate on the same resource. Redo will
fail also if the client performed a new action (this cleans the "redo buffer").
• lockForDemonstration: Enables the demonstration mode. In this mode only one
application (master) can control the model and the camera and the other clients (slaves)
replicates all the actions performed of the master.
• moveCommonCamera: Moves the camera common to all clients, when the demo mode is
active.
• lockForSimulation: Enables the DES simulation mode. No other client is allowed to
modify the model that is simulated.
• updateServerCatalog: Notifies the server that there is a change in the catalogue, i.e. you
add a new machine.
The IModelObserver interface is implemented by the local application and it is used by the
server to communicate with the clients. The methods of the interface mostly reassemble the
methods available in the IFactoryModel interface and it is used to notify common events that
happens either when the catalogue has been modified, or the interaction mode is changed
(editing, demo, DES) or an object has been modified (added, removed, grouped, ungrouped,
moved, ...). All the events are directly notified to each client listening: moreover the presence of
pending changes happened while the client was disconnected, are notified too.
In a distributed application, it is very important that every change is propagated to all the
involved actors. To obtain such a synchronization, we have chosen a centralized architecture
where the server is also an FTP service provider. The local copy of the catalogue is checked
against the server copy using the metadata available in the catalogue.xml in order to find which
resources needs to be updated. This resources are first inserted in a list of files to be downloaded
and then retrieved by the client through a standard FTP session. The order of this list can be
changed, to prioritize the download of resources that are needed to open a layout document.

5 Discrete Event Simulation (DES)

The FLP can run DES simulation on a layout. Besides the layout and connections, to perform a
DES simulation the FLP needs also a production plan and the operation flows. Both are stored in
XML files: while the first contains the plan in term of product codes and quantities, the second
contains the sequence of operations needed by each product. These information are used to
construct a complete DES model: the approach is to be as much as possible independent from the
simulation execution library.
Each system is considered to be a set of interacting processes: these are connected together by
ports and communicate with each other by passing events. A central system class controls all the
threads, advances the simulation time, and delivers the generated events. The progress of the
simulation is recorded through trace messages produced by the entities and saved in a report file.
 Figuree 3 : A layoutt connections for DES sim
mulation
The layout shown in i Figure 3 and Figure 4 is a footw wear manuffacturing linne: there aree sources
(the greeen cone), sinks (the red cones),, transporteer, machinnes (lasting machine, roughing r
machinee, brushing machine,
m lasst slipping machine,
m reaactivation ovven).
For the DES simulaation, each machine is characterizeed by the foollowing parrameters: cy ycle time
(definedd by its meaan value andd variance), MTBF (Meean Time BeforeB Failurre), failure duration,
d
maintennance intervaal and duratiion.

Figure 4 : A running DE
ES simulationn

To run a simulatioon, the user needs to define

d a test bed in whhich the seedd (used for pseudo-
random numbers generation),
g the transiennt interval, the producction plan aand the duraation are
configurred.
The simulation results contains the statistics associated with the entities: throughput, residence
time, waiting time, service time, utilization, queue length, arrival rate. Not all values are
available for all types of entities (e.g. the operator entity has only the usage statistics)
During the simulation, a brief overview of the most important statistics is visualized on
informative labels positioned over the machines as shown in Figure 4.

6 Software Design Choices

The Factory Layout Planner, having particular requirements, and wanting to answer to particular
needs, was born after an accurate design phase. During that phase some choices have been made
to acquire the expected results.
The main choice has been to relay on well established standards:
• Java Remote Method Invocation (RMI) [RMI]: this protocol (as mentioned before)
enables to create distributed applications, in which the methods of remote Java objects
can be invoked from other Java virtual machines, possibly on different hosts.
• Java Web Start [JWS]: this is a mechanism for program delivery through a standard web
server. Using Java Web Start (JWS) technology we can distribute our client side
application with a hyperlink, with the only requirement of the presence of the Java
Runtime Environment (JRE) installed on the PC. All the other required resources are
downloaded automatically by the JWS framework. Once deployed, the program do not
need to be downloaded again, and it can automatically download updates on start-up
without requiring the user to go through the whole installation process again.
• File Transfer Protocol (FTP) [RFC959]: this is a standard network protocol used to
exchange and manipulate files over a TCP/IP-based network, such as the Internet.
As said before, our architecture is a centralized one: the server is the point where other clients
can connect. The presence of this server is exploited to provide an universal access point even for
user without an FLP client: in fact any user can point their Java enabled internet browser to the
server address and, thanks to Java Web Start technology, the required libraries and resources are
automatically downloaded. This actually happens only at the first connection to the server: from
now on, each time the user connect to the same address, the application is launched immediately
because all the required files are cached on the user PC.
The trustworthiness of the origin of the application is ensured by digital code signing [JPSA].
Moreover, applications launched with Java Web Start are, by default, run in a restricted
environment where they have limited access to local computing resources, such as storage
devices and the local network. In this sandbox environment, Java Web Start can guarantee that a
downloaded and potentially untrusted application cannot compromise the security of the local
files or the network.
Concerning the DES simulation engine, in our prototype system we have chosen to use SimJava
[How98] because the approach adopted to this simulating systems is similar to the one we
adopted for the modelling in the FLP.

7 Usage scenario
In this section we will describe a sample usage scenario of a reconfiguration of a shoe factory
plant: we can assume that two teams, one at the headquarters and one at the plant location, must
cooperate to evaluate the performance of a new layout. They can use their browser to open the
page of FLP from the company intranet and start the application clicking on the appropriate link.
If necessary, the application is downloaded and installed or update to ensure that both team use
the same version. The headquarter team has worked on different layout proposal and saved them
on the FLP server and now they can discuss with the remote team. They enable the Demo mode -
to gain control of the camera - and show to the remote team the changes they want to implement.
 When finished they exit the Demo mode and the remote team can propose, for example, a
different number of working station because they know they have more workers that are able to
do a certain task: they can modify it on their PC and the changes appears immediately on the
other PC. Lastly, it is possible to activate the DES mode to evaluate the throughput of the new
layout using the DES simulation.

8 Conclusions
This paper has presented an innovative tool for the factory layout planning. The capability to
support a collaborative editing of the layout (possibly distributed) in a 3D environment, and the
integrated DES possibilities, makes FLP to be an high value adding tool for cost-effective and
rapid creation, management and use of the Next Generation Factory.
This paper highlights how all the efforts in the design and development of this tool went in the
direction of creating a comfortable environment for the layout designer and his team.
The possibility to interact with the FLP from different part of the world, for person belonging to
different department of a company, allow to state that this tool allow multi-site multi-user multi-
level collaborative and distributed management of a factory layout.

Acknowledgement
This work has been partly funded by the European Commission through NMP Project DOROTHY: Design Of
customeR dRiven shOes and multi-siTe factorY (No. FP7-NMP-2007-SMALL-1). The authors wish to acknowledge
the Commission for their support. We also wish to acknowledge our gratitude and appreciation to all the DOROTHY
project partners for their contribution during the development of various ideas and concepts presented in this paper.

References
[Full82] Fuller, R.B. (1982): Synergetics: Explorations in the geometry of thinking. EJ Applewhite, Macmillan Pub
Co (Ed.)
[EC04] European Commission, MANUFUTURE – a vision for 2020, November 2004
[Bat07] Bathelt, J., Boër, C.R., Chryssolouris, G., Constantinescu, C., Dépincé, P., Pappas, M., Pedrazzoli, P.,
Rovere, D., Westkämper, E. (2007): High Value Adding Virtual Reality Tools for Networked Customer-
Driven Factory. Proceedings of the 4th International Conference on Digital Enterprise Technology, pp.
347-352. September 19-21, Bath, United Kingdom. Maropoulos, Paul (Ed.), CIRP u.a
[Boe06] Boër, C.R, Jönsson, A., Pedrazzoli, P., Sacco, M., (2006): Virtual Factory Framework: key enabler for
future manufacturing. Digital enterprise technology: perspectives and future challenges, pp 83-90,
Springer, 1
[How98] F. Howell, R. Mcnab, “simjava: A Discrete Event Simulation Library For Java”, In International
Conference on Web-Based Modeling and Simulation, 1998, pp 51—56.
[XSD04] XML Schema, W3C Recommendation 28 October 2004, http://www.w3.org/XML/Schema
[RMI] Java Remote Method Invocation, http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp
[JWS] Java Web Start Technology, http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp
[JPSA] Java Platform Security Architecture,
http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html
[RFC959] J. Postel, J. Reynolds, File Transfer Protocol, Request for Comments number 959, Internet
Engineering Task Force, October 1985, http://www.ietf.org/rfc/rfc959.txt
[DEL] DELMIA Digital Manufacturing & Production, http://www.3ds.com/products/delmia/
[TEC] Siemens Tecnomatix 9, http://www.plm.automation.siemens.com/en_us/products/tecnomatix/
[VIS] Visual Components, http://www.visualcomponents.com/
[ARE] Rockwell Automation Arena, http://www.arenasimulation.com/
[SIM] Simio Simulation, http://www.simio.com/

View publication stats