4layer: An Idea to Bridge the Gap Between

Machine Control Units and the Production

Planning System
Dr. Rolf Pfiffner, Mr. Hans Gfeller, Mr. Thomas Wildi, SW Developer / BYSTRONIC Maschinen AG
CH-4922 Bützberg, Switzerland

Keywords

1=Architecture 2=SW Concept 3=Data Interface 4=Machine Integration

Abstract factories have not such an equipment. again are supported by the machine
The reasons for this situation are manufacturer.

Process Design
Most present glass factories prepare
manifold, but the most important items The present situation is not specific
their production run with a planning
are the following: for the glass industry, various other
system that optimises the chronology
• The various machine manufacturers industries are facing the same problems
and minimises the waste. The planned
have their own job data format, no [1].
data are transferred by so-called batches
standard data format. Therefore, the In order to overcome the above
of cutting plans or production files. The
production planning system mentioned problems and to simplify
data transfer from the planning system
generates job files for each machine. the future software solution for glass
to the control units of the corresponding
• Today’s data structure for the cutting processing factories, BYSTRONIC
production lines (cutting or IG line) is
line and the IG line distinguish proposes in this paper the so-called
therefore based on an exchange of
basically. 4layer structure. The underlying model
electronic files. On the other side, the
• No standard interface to the various with the corresponding functionality of
status of the machines as well as the
production planning systems exists. each layer and the chosen architecture
progress of the production is usually not
Hence, the production planning is presented in Section 2. The proposed
known by the planning system. These
system cannot reobtain information data structure for jobs and the facility
circumstances are responsible for a
about the status and the schedule of is content of Section 3. A short outlook
quite low ability to react in case of not
the production. concerning possible productivity
foreseen events during production, e.g.
• Optimisation tools are typically not improvements and the future starting
broken panes, machine break down etc.
from the machine manufacturer, but and changing procedure is subject
Although a direct electronic connection
from third parties or the production of Section 4. A short summary will
between the planning system and the
planning system supplier. Other tools conclude the paper.
machine control units could solve the
problem, it is not yet applied due to the
high complexity and variety of the data,
interfaces and technologies used by the
machine manufacturers and production
planning system suppliers.
The 4layer concept is a first
attempt to overcome these problems
by structuring the whole production
process into 4 different layers and the
interfaces between them. A general
interface to the machine control unit
as well as to the production planning
system is proposed in order to reduce
the complexity/variety of the various
manufacturers and suppliers. The
realisation of this concept will lead to
a powerful integration of machines
from different manufacturers, a more
trackable production process, a higher
reaction rate, automatic configuration
of the production planning system and
various other advantages.

1. Introduction
On-line information about the
actual production progress and the
availability of the facility as well as the
chronological data acquisition of these
information are today’s basic conditions
for optimising the production process.
The former permits a high reaction rate,
while the latter can be used to evaluate
improvable items of the whole process. Figure 1:
Unfortunately, most present glass The 4layer model: A functional view to a glass processing facility.

GLASS PROCESSING DAYS 2005 - www.gpd.fi 1

 2. The model
The underlying model ought to be a
schematic representation of a glass
processing factory. In order to get the
desired model, a listing of the required
functions of such a factory as well as
the allocation of them to different
hierarchical orders was performed. The
result can be examined in Figure 1.
The whole factory is separated into 4
layers which represent the hierarchical
order of it. Layer 1 to layer 3 represent
the branch of production, whereas layer
4 can be regarded as the office area.
Each layer in the branch of production
(layer 1 to 3) consists of several
elements of the underlying layer, but
at least of 1. Hence a plant with 2 lines
which both are made up of 3 machines,
is represented by 1 element in layer 3, 2
Process Design
elements in layer 2 and 2 x 3 elements
in layer 1.
The layers have a similar structure,
but consist of layer dependent
functions. Process data (Jobs) are
delivered from the next higher layer.
These process data are validated,
converted and distributed to the various
elements of the underlying layer. On the
other hand, events (facility information,
job status) from the underlying layer are
acquired, filtered and forwarded to the
next higher layer.
A predefined interface between each
of the corresponding layers guarantees
an easy expansion or changing of
elements in any layer, i.e. in order to add
a new machine to a line, an additional
element of layer 1 with a standard
interface to layer 2 included has to be
generated.
The whole architecture is designed
as a distributed system. Thus it will be
possible to access all of the functions in
the different layers from any computer
in the LAN. For this reason, a user- and
Figure 2:
Layer 1 and 2 for a vertical cutting line with an automatic loader each controlled by a separate PLC.
2 GLASS PROCESSING DAYS 2005 - www.gpd.fi
location-depending access limitation has
to be configured in order to guarantee a
save production.
2.1 Layer 1: machine
The smallest element in the proposed
fragmentation of the whole facility is a
so-called function unit (FU). Usually such
a FU is equal to a machine, but actually
it can be any part of a production
process that performs a discrete
action. Figure 2, for example, shows
a schematic line layout of a vertical
cutting and breaking line with a loader
in front of it (for more information cp.
[2]).
Each FU is represented by two
corresponding software objects,
one running at the PLC and one as
the physical mapping of this FU in
the lowest layer of the 4layer model
running at a PC. Only a predefined set
of commands can be processed at this
FU at the PLC in order to simplify the
Communication-Interface between the
PLC and the PC world. This interface is
different for any type of PLC, but will
be encapsulated by the PLC-Manager
in order to get independent of any type
of PLC hardware. Thus for integrating
any third party machines (FUs), only
the Communication-Interface to the
corresponding PLC-Manager and the
software object of this machine have
to be generated. Thereby, the software
object of each FU has to contain the
following properties:
• physical restrictions of the machine
• type of treatment that can be
performed
• physical restrictions of the product
for each treatment
• definition of a predefined small set of
commands that can be processed
• job data converter, i.e. converts the
job data into a list of the predefined
commands
• process variables
• operator interface
• appearance.
Usually, each FU has to synchronise
with its predecessor and/or its
successor. This so-called Sync-Interface
is standardised and kept very simple. In
case one or more of FUs will be running
at the same PLC, the communication is
made by variables, in case two different
PLCs are involved, the communications
is performed by few simple I/Os.
2.2 Layer 2: line
Each line consists of underlying FUs.
Thus the so-called LineManager of any
line only has to know of which FUs and
in what order the line is composed in
order to get every information of the
physical properties of this line. As a
matter of fact, the information available
by the properties of the FUs and by the
layout of the line suffice for a proper
operation of the LineManger.
The main element of the
LineManager is the JobList, cp. Figure
2. This list contains the job data of a
certain line. It can be manipulated either
by the operator via GUI or by any layer
2 or 3 component. The load function
for the JobList performs all relevant
validations and returns a detailed
report to the caller in order to enable a
purposeful error handling.
The LineManager is responsible to
distribute the appropriate job data
for each FU to perform a certain job
from the JobList. The other way round,
each FU supports the LineManager
with detailed information about the
actual production state of the current
job. Hence, a separate FailedItemList
is available, where the LineManager
collects the failed jobs (e.g. broken
panes) to enable a purposeful error
handling for the production planning
system or a simple optimisation/
planning tool which will be already
integrated in layer 2.
The GUI for the operator has to
support an easy manipulation of the
JobList as well as a creation of new
jobs. Hence a JobEditor with some
basic waste-minimisation has to be
integrated already in layer 2, at least for
the cutting line. In case the line has an
integrated storage device for residual
plates as in [2], the LineManager has to
provide updated inventory data for the
production planning system or a simple
optimisation/planning tool.
2.3 Layer 3: plant
A plant consists of underlying lines and
these lines again of underlying FUs as
described in Chapter 2.2. Therefore,
the same structure and functionality
as for layer 2 can be mapped to layer
3 but on a higher level. The so-called
PlantManager manages the plant jobs
received from the production planning
system. It also distributes the batches to
the corresponding LineManagers and
notifies the production planning system
in case it cannot manage the plant
jobs, e.g. breakdown of a line, machine Figure 3:
etc. In case the planned production The proposed tech-
can be handled within the plant by nological architecture
to realise the 4layer
using another line or other appropriate concept.
arrangements, the production planning
system will not be notified.

2.4 Layer 4: factory

Layer 1 (without the PLC part) to layer
3 represent the so-called Production
Control and Operating Software, see
Figure 3. This software is running
on distributed PCs in the branch of
production using remote technology.
On the other hand, the PPS as well
as the MIS are systems build up for
working in the office area. Therefore,
a sophisticated electronic interface
between them has to be provided by
layer 3. For that reason, XML Web- Figure 4:

Process Design
Services are chosen since they are Class design for the job
independent of the operating system data.
which the office applications are
running and they provide many useful
methods to get on-line information
about the available interface.
Since the PlantManager knows the
layout configuration of the whole plant
including all of its lines and FUs, this
information will be provided by layer
3 to configure the PPS directly. Other
information which are very useful to
exchange via this interface from layer 3
to layer 4 and vice versa are discussed in
Chapter 3.

3. Interface to production planning

system
A main goal of the 4layer system
is to have unique interfaces to the
production planning system for the
cutting line as well as for the IG line.
The backward compatibility of the so
far used production file (IG line) and
XYZ-cutting code (cutting line) obviously
has to be supported. In order to supply
a platform and language independent
communication, the interfaces will be
based on web-services and/or COM
technology. Thus, a main advantage
using the proposed structure results in
supporting a direct access with powerful
functions such as validating and loading
job data.
Another advantage will be the
transmitted data structure, which will
be always XML-based with appropriate
XML-schemes. Hence, the data structure
is split into a very flexible basic part and
into a specific part for the cutting line
and the IG line, respectively.
The supported data can be separated
into two categories: job data and facility
data. The following sections give a short
survey of the most important aspects.
3.1. Job data structure
The job data comprises every
information concerning the job to be
performed. Using this job data structure,
the following contents can be managed:
• the job data itself (a batch of cutting
plans or IG units)
• the status of a certain treatment as
feedback to the production planning
system
• list of broken panes as feedback to
the production planning system
• free forms (explicit coordinates) and
parametrised forms (coordinates
based on parameters).
Free forms and definitions for
parametrised forms will have also a
unique XML-based structure and will
therefore replace the so far used F99
and FFM code.
The fundamental design of the
proposed job data structure is depicted
in Figure 4. The following characteristics
can be recognized:
• an applied composite pattern enables
a flexible grouping of the job items
• a job item represents a physical unit
to be manufactured
• CLite, CSpacer and CMuntin
represent basic components that can
be composed with any composite
• derivations of CJobComposite
represent specific nodes that could
contain any basic components (CLite,
CSpacer…) or again composites
• each job item can hold a list of
treatments with its own geometric
attributes, form parameters and
shape geometry
• the treatment contains information
about the type, the current state etc.
• each job item and treatment can
hold a dynamic list of attributes.
In order to illustrate an example of the
job class design, Figure 5 shows an
object tree for a cutting plan and an IG
job with IG units. The main benefit of
the proposed data concept is the fact
that the cutting and the IG job data are
built up with the same basic elements
(e.g. lite and geometry attribute), but
possess line specific composite nodes.
The nodes in the cutting job object tree
have the following characteristics:
• the root object is a batch that
contains a number of jobs
• a job represents a plan how to cut a
plate
• a job is usually composed of X-, Y-, Z-
and W-nodes that define the
locations of the lites on the plate
• a job can also have subjobs as
children to group a certain number
of X-nodes, used for example for the
subplate-wise cutting on a verticut
(not shown in the example depicted
in Figure 5).
The characteristics of the nodes of the
IG job object tree are as follows:
• the root object is an IG job that
contains a number of IG units
• an IG unit can be composed of lites,
spacers, muntins etc. (in an unlimited
variety of combinations).
A powerful improvement of this
structure is the fact that a lite object
used in an IG unit and planned on a

GLASS PROCESSING DAYS 2005 - www.gpd.fi 3

 Figure 5:
Object trees for a cutting job and an IG unit applying the proposed class design.
Process Design
certain cutting job can be identified and
clearly assigned by a unique ID.
The possibility to extend the proposed
concept in a flexible way, when new
basic components or specific composites
need to be added, is another advantage
worth mentioning.
3.2. Facility data structure
The facility data comprises every
information concerning the status and
the conditions of the hardware (i.e.
machines, lines etc.) as well as superior
services and informations of the
production. The following contents and
services will be managed:
• a catalogue of standard or
customized forms, grouped in
categories
• a complete description of the custom
specific layout configuration of the
whole plant
• an actual updated inventory of any
storage device
• a current list of broken lites with
additional information (e.g. failure
reason) that permits a purposeful
error handling for the production
planning system
• a job validation which considers the
current state of the line and
machines
• statistic information about
productivity rate, operation and
maintenance times etc.
A unique layout data structure of all
the production lines will be the basis
to enable an automatic configuration
4 GLASS PROCESSING DAYS 2005 - www.gpd.fi
of the production planning system for
the parts that are machine-dependent
like restrictions, capabilities, line and
plant layouts, etc. As mentioned above,
all these XML-based data structures
will have defined XML-schemes which
enable a proper data validation already
in the production planning system. Since
the data structure uses XML-schemes,
additional services and other data can
be introduced in a similar manner as the
proposed examples.
4. Outlook regarding productivity
improvement and starting
procedure
The major contribution of the proposed
software system to improve productivity
is definitely the on-line acquisition
of any information occurring at
the production plant. This acquired
information enables the system itself
and/or the superior software, e.g. PPS or
MIS, to supervise the actual production,
to react fast to unforeseen events (e.g.
if broken panes occur) as well as to
schedule automatically residual plates
of an integrated storage device. In
addition, the chronological recording
of machine interferences as well as
other logistic relevant data are the basic
requirements to analyse/optimise the
whole production process.
Since the proposed system provides
the actual information of the whole
factory, an automatic configuration
of the production planning system
will decrease enormously the starting
procedure time. The same advantage
will arise by changing the machine
layout of the factory.
5. Conclusions
The new software model proposed in
this paper is a first attempt to simplify
the whole software variety of a glass
processing factory as well as to enable
a work flow from the machine control
unit to the production planning
system and vice versa. The presented
architecture and data structure are
designed to work for cutting lines
as well as for IG lines so that the
complexity of the data structure can
be simplified. Using such an integrated
software solution will generate
productivity improvements and gives the
necessary conditions to analyse/optimise
the whole production process.
BYSTRONIC has realised this software
concept for a vertical cutting line
presented in [2] and will extend this
concept to future products.
References
[1] M. Rader: XML WebServices
lösen Integrationsprobleme in der
Automatisierungstechnik, wt Werkstattstechnik
online, issue 9, pages 609-613, 2003.
[2] H.Gfeller and R. Pfiffner: Process Orientated
Glass Cutting – Vertical Solution “Verticut
with Feeder”, Proceedings of the 9th
International Conference on Architectural and
Automotive Glass (Glass Processing Days),
Tampere, Finland, 2005.