Prod. Eng. Res. Devel.
(2008) 2:39–46
DOI 10.1007/s11740-008-0083-7
COMPUTER AIDED ENGINEERING
Model-driven development of PLC software for machine tools
Michael F. Zaeh Æ Clemens Poernbacher
Received: 30 July 2007 / Accepted: 21 December 2007 / Published online: 19 February 2008

German Academic Society for Production Engineering (WGP) 2008
Abstract Developing PLC software for modern machine
tools is becoming more difficult because of the increasing
functionality and resulting complexity. An approach for
managing this is provided by the model-driven develop-
ment of the control software. However, this innovative
development method requires both a procedure that is
adapted to the specific application domain and suitable
modeling techniques. The article describes an approach
appropriate for machine tools. The focus is on introducing
the necessary description techniques and a methodology
for their use in product development.
Keywords Computer aided engineering

Programmable logic controller
Software development
1 Introduction
The development of highly productive machine tools is
characterized by the demand for high availability and an
increase in the functionality and degree of automation. This
leads to increased complexity of the machines, particularly
with regard to the software for activating, co-ordinating
and monitoring the individual machine functions. Manag-
ing the complexity requires interdisciplinary co-operation
between the various departments involved in development
[1]. For this reason—and for further reduction of time to
M. F. Zaeh (&)
C. Poernbacher
Institut für Werkzeugmaschinen und Betriebswissenschaften,
iwb, Technische Universität München, Boltzmannstraße 15,
85748 Garching, Germany
e-mail: michael.zaeh@iwb.tum.de
C. Poernbacher
e-mail: clemens.poernbacher@iwb.tum.de
market and product development costs—parallelizing and
synchronizing the development tasks (concurrent engi-
neering) is a basic premise for successful realization of
future production systems [2].
Concurrent engineering requires the use of modern
development methods and a redesign of established pro-
cedures. While model-supported static and dynamic design
of the machine structure through the use of FEM and MBS
methods is already widely used in industry, model-based
development of machine tool control software has not yet
caught on in the real world. This is particularly true for
PLC software, which implements both technological and
safety-related functions. The reasons for this include the
late integration of software engineering into machine
development and the unavailability of suitable develop-
ment tools. Additional obstacles are presented by
inadequate co-ordination between the disciplines involved
and the large amount of resources required to create the
necessary digital models. These can be traced back to the
lack of suitable interdisciplinary modeling mechanisms for
specifying the machine tool, and the lack of a continuous
procedure for developing the control software [3, 4].
The article will present an approach for the model-dri-
ven development of PLC software for machine tools.
Following a discussion on model-driven software devel-
opment in general, the requirements for the development
environment and methodology for this purpose will be
described. Thereafter, different abstraction levels for
modeling the software and hardware components of the
machine tool will be presented. These provide the basis for
presenting suitable modeling methods and integrating them
into an interdisciplinary development process. Further-
more, the simulation-based verification and optimization of
the developed control software will be discussed, using a
virtual prototype.
123
40
2 Model-driven software development (MDSD)
The model-driven development [5] of technical systems,
unlike development based on domain-specific documents,
uses abstract models to define the multilayered functional
relationships between system components (Fig. 1). These
are further detailed in the course of the development pro-
cess and enriched with information. Thereafter, special
generators create the necessary project documents directly
from the models [6].
For software development, the basic idea is to create an
executable functional model of the software at an early
stage of the development process based on requirements
specifications [7]. This serves as the starting point for all
subsequent analytical and design-related development
steps. Later, an implementation model is created on this
basis; finally, executable code is generated. A distin-
guishing feature of MDSD is that the created models are, at
first, platform-independent (PIM). The system behavior is
described separately from the later physical and software
technology-related implementation. A gradual refinement
of the models takes place towards the implementation of
models customized for the selected target platform (PSM).
The effort to create models can be reduced by automating
model transformations, and the concluding generation of
target code.
3 Key demands on model-driven development
of PLC software for machine tools
Model-driven development of PLC software requires a
practical real-world approach. At the same time, a number
of domain-specific requirements need to be taken into
consideration (Fig. 2). Due to the high level of complexity
of modern machine tools, a one-sided, software-oriented
point of view is no longer adequate when developing PLC
programs. Rather, the properties and structural design of
Fig. 1 Model-driven engineering (schematic representation)
123
Prod. Eng. Res. Devel. (2008) 2:39–46
the machine tool must be taken into consideration as soon
as development begins. The behavior of the electrome-
chanical, electrical, hydraulic and pneumatic components
of the machine (hereafter referred to as hardware compo-
nents) and software components and their interaction must
be modeled with sufficient accuracy and used to develop
the control functions. When selecting suitable modeling
mechanisms for this purpose, it is necessary to consider the
different ways of thinking of the various disciplines
involved. Mechanical design engineers are primarily
interested in the sequences of machine operations and the
design of its components and ensuring collision-free design
and ease of assembly. Software developers often have a
signal and logic-oriented point of view. Their focus is on
clear resolution of possible machine states and designing
error handling mechanisms.
Software developers must be given the opportunity to
validate and optimize the developed functions during the
early phases of development. This requires the provision of
simulation tools that permit verification and commission-
ing of the software based on a virtual model of the machine
tool. In order to allow a flexible adaption to the develop-
ment task, the simulation must both enable simple
sequences to be tested and visualized based on a three-
dimensional model and allow existing hardware and con-
trol components to be integrated.
To keep the effort required for modeling to a minimum,
it is necessary to reuse previously generated information
and to incrementally refine the model components during
the course of development. The prerequisite for this is a
formal or semiformal representation of the machine tool
system. This also allows mechanisms to be implemented
for consistency checks and model verification [8]. Fur-
thermore, a methodical procedure must be provided in
Fig. 2 Key demands on a model-driven development approach
Prod. Eng. Res. Devel. (2008) 2:39–46
High Level Modeling
- Functional Modeling
- Essential Functionality
- Machine Tool Structure
Refinement
Development Iteration
Verification
Detail Level Modeling
- Technical Solution
- Full Functionality
- Machine Tool Structure
Refinement
Target Artifacts
- Software Components
- Simulation Models
- Documentation
Fig. 3 Abstraction levels (schematic representation)
order to effectively use a model-driven development
approach. This must take into account both departmental
aspects and organizational constraints, and specify which
model concepts should be used at a certain development
stage and for what purpose [9].
4 Abstraction levels
For real-world implementation of a model-driven devel-
opment approach, a multilevel procedure is recommended
(Fig. 3). The first step is to define and model the essential
software functions in co-ordination with the mechanical
design team. Implementation, both on a software technol-
ogy and hardware design level, is of secondary importance
here. What is critical, is to clearly specify how the logical
sequence of certain functions appears, as well as to develop
a shared understanding of the machine functions, despite
the different terminology and ways of thinking of the
development domains involved. Even in this early devel-
opment phase, it is important to consider the structural
design of the machine tool. This allows the control pro-
grams to be made modular, making it easier to implement
adaptations for individual customers. At the same time, it is
easier to reuse existing software modules and avoid cost
and time-intensive development loops.
Once the essential software functions have been deter-
mined, the system model must be detailed and expanded
with additional functions. These particularly pertain to
software-related components such as adding watchdog
timing, interlocks or operating modes. In addition, complex
functions must be specified in detail. The objective is to
fully describe and formalize both the structure and the
behavior of the developed system. This must also take into
41
account the technical implementation. The result is a
platform-specific model of the hardware and software
components of the machine tool.
The last step is to generate the target code from the
platform-specific model. However, automatic code gener-
ation requires further refinement of the models. It is
necessary to define how the individual model constructs are
to be transformed into the target code, and which con-
straints need to be considered when doing so. The
integration of existing code fragments from libraries or
system providers must also be taken into account.
The mechatronic properties of a machine tool and the
resulting complexity require an iterative modeling process.
To keep the re-engineering effort required to a minimum, it
is necessary to integrate simulation methods at the various
abstraction levels. These allow the software functions to be
validated in early development phases, but must be adapted
to the specific degree of detail of the models.
5 Basic concepts for the modeling of machine tools
A system-theoretical approach [10] is recommended for
modeling the machine tools. The machine tool system—
both the PLC software and the hardware components of the
machine tool—are broken down according to their hierar-
chical structure. Each sub-system has defined inputs and
outputs that are connected to each other according to the
flow of information, material and energy between the
individual subsystems. In addition, a defined behavior can
be assigned to each sub-system. For modeling the machine
tool, notation elements from the unified modeling language
(UML) [11, 12], a standardized notation language for
developing software applications for personal computers
and embedded systems, is used. Elements of SySML [13,
14], an adaptation from the systems engineering field, are
also used. The following sections are a detailed examina-
tion of the individual steps for modeling and the constructs
used for this purpose.
6 Modeling machine tool structure
Despite the mechatronic nature of modern machine tools,
mechanical design still plays the dominant role during
development. It determines the structural design of the
machine, and models it in the form of a component dia-
gram (Fig. 4). The software developer expands this
diagram by adding corresponding software modules, thus
defining the structural design of the PLC program. In doing
so, special attention must be given to maintaining the
greatest possible symmetry between the software compo-
nents and the essential subassemblies of the machine. This
123
42 Prod. Eng. Res. Devel. (2008) 2:39–46

Software model Machine model • By avoiding mixing hardware-specific behavior and

control behavior, reusing the generated models is made
SC::Tool
SC::Tool changer
changer HC::Tool changer
HC::Tool changer
substantially easier. The model of the machine tool’s
hardware components provides the basis for simulation-
SC::Security
SC::Security HC::Security
HC::Security based testing of the developed programs. Using existing
door
door door
door model components is also made easier.
• Discrete descriptive tools can be used to model the
behavior of the PLC software.
Port
• These have only limited suitability for mapping the
behavior of the hardware components. Hybrid descrip-
SC::User
SC::Use
input handlerr tive tools [15] are suitable for use according to their
input handler
physical behavior. These allow continuous and discrete
behavioral features to be specified.
Component

Namespace Connector Visualization

SC … Software Component HC … Hardware Component 7 High-level modeling of machine tool behavior
Fig. 4 Modeling machine tool structure
As part of the analysis phase, the requirements for the
functions to be implemented are recorded and structured. In
is dictated by the fact that future state-of-the-art machine
real-world practice, this is done by means of verbal agree-
tools will, to an increasing extent, be flexibly configured
ments and domain-specific documents. Differences in
from modular systems. The greatest possible equivalence
system understanding between the mechanical design and
of software and hardware and the definition of clear, nar-
software development areas, as well as misunderstandings,
row interfaces ensure the interchangeability and reusability
result in development flaws that go undetected until the
of individual software components.
software is put into operation on the real machine. The co-
In the component diagram, each subsystem is repre-
ordination can be improved by creating a formal specifica-
sented by one component. This provides clearly defined
tion of the functions to be implemented in the form of a
functionality by encapsulating and abstracting the behavior
functional model of the machine tool. To do so, we recom-
and structure of particular subsystems, and provides well-
mend using sequence diagrams (Fig. 5) in combination with
defined interfaces for communication with their environ-
a three-dimensional kinematic model and an executable
ment. These interfaces are represented by ports. While the
functional model of the machine’s hardware components.
ports describe only which information is needed by a
Such a functional model defines a set of abstract functions
component or made available by it, the flow of information
which a certain component must accomplish, without ref-
in the system is represented by connectors. These connect
erences to a specific implementation.
individual ports to each other and thus implement the
Sequence diagrams are a view of the model of the
relationships in the modeled system. A detailed specifica-
machine tool. They assign behavior-specific aspects of the
tion of the ports is possible by distinguishing whether a
system to its structural units. The focus is on showing the
port defines a required interface (system input) or an
interaction between individual subsystems. Sequence dia-
offered interface (system output). The assignment of
grams describe this in two dimensions. The communication
components to a namespace determines their allocation
partners (lifelines) are arranged from left to right. An
within the machine tool.
(imaginary) time axis extends from top to bottom. If the
Unlike existing approaches for developing automation
model is analyzed in a vertical direction, the sequence of
systems, modeling enforces a strict separation of machine
the individual communication steps is evident. This is
hardware and control software. This has the following
based on messages that are represented by arrows and are
advantages:
described by annotating a name. A message begins on the
• It ensures that the structure of the machine tool is lifeline of its sender and ends on the receiver’s lifeline. If a
mapped realistically. The interface between the control message is received from a sender that is unknown or lies
system and the hardware components of the machine is outside the context under consideration, or if it is sent to a
clearly visible. Therefore, this information can be used receiver of this type, it is not shown in the diagram.
for planning the necessary field components, such as Activities of a longer duration are identified in sequence
the I/O modules of the machine, and for control cabinet diagrams by a wider lifeline. In the context of specifying
design. PLC functions, these are particularly well suited for

123
Prod. Eng. Res. Devel. (2008) 2:39–46 43

Next, the connection is made to a three-dimensional

SC::Tool SC::Security HC::Security kinematic model of the machine. This can be derived from
changer door door existing CAD models without great effort, and facilitates
discussion and shared specification of the machine func-
Ready Door closed
tions by the software developer, machine design engineer
Start Lifeline
and the customer. While movements are visualized by a
Elevate
Preparation direct coupling of position values with kinematic machine
Close valve axes, the static functionality is represented by a change in
Elevate door
0.5 s
the visualization of the corresponding components in the
Sensor on
kinematic model.
Once the behavior of the hardware components of the
Door opened
Is open machine has been defined and the connection to the kine-
Time matic model is established, the actual specification of the
constraint
Change
2.3 s
software functionality can take place. According to the
tool
desired functions, state invariants, messages and activities
close
are modeled step by step. By integrating additional simu-
Open valve
Close door lation functions into a suitable development tool, the
State invariant 0.4 s specified machine behavior can be observed, discussed and,
if necessary, corrected—directly on the three-dimensional
Door closed
model, in a clearly presented manner. Moreover, collisions
Closed
can be detected, and space and reachability analyses can be
Ready carried out.
MTSC::Tool MTSC::Security
Message MTHC::Security
Activity
changer door Door

8 Detail level modeling of machine tool behavior

Fig. 5 Sequence diagram

After the technical implementation of the machine func-

representing the hybrid functional behavior of the hardware
components. Prerequisites for an interaction can be repre-
sented in the sequence diagram by what are known as state
invariants. Thus, a communication can take place only if
the sender and/or receiver fulfill the constraints represented
by the state invariants. Otherwise, the implementation of
the interaction would be faulty. In addition, time con-
straints can be specified. This makes it possible to spread
customer-dictated requirements for certain machine func-
tions to individual subfunctions.
The first step, in defining a function to be implemented
is to identify the communication partners involved. Due to
the invariable structure of the machine hardware and PLC
programs, these can be directly allocated to the compo-
nents of the machine tool. In a further step, the abstract
functions of the machine’s hardware components involved
in communication have to be modeled. Mathematical
relationships that define position values as a function of
time are particularly well suited for specifying movement-
related functions. Elements of Boolean logic are suitable
for defining static functions. Examples of this are the
activation of sensors and the switching of hydraulic or
pneumatic valves. When modeling, it is important to ensure
that the function is clearly defined and is provided as an
interface to the component, and thus can be coupled to the
messages in the sequence diagram.
tions is mechanically defined, a further refinement of the
model takes place. Unlike functional modeling with
sequence diagrams, in which the behavior of the system
components is modeled only in part, the complete defini-
tion of the behavior of the individual system components is
now in the foreground. Finite automatons have proven
useful for modeling the software behavior. Concretely,
specification in the form of state machine diagrams (Fig. 6)
is recommended. These diagrams, which are based on
Harel statecharts, are likewise part of UML and provide the
software developer with an adequate way of looking at the
machine tool system.
A state machine is defined by a finite number of states,
transitions, triggers and guards. It has precisely one active
state at any given time. Each state is declared with a name
that is unique within its structural context. The actions
(activities) to be executed at activation are annotated to this
name. These describe the exchange of information between
the components of the software model. They are also used
for declaration of simple arithmetic and Boolean opera-
tions. According to their execution, a distinction is made
between three types of activities. ‘‘Entry’’ and ‘‘Exit’’
activities are executed once when entering or exiting the
state. ‘‘Do’’ activities, on the other hand, are repeated until
the transition to the next state. To specify the transition
from an source state to a target state, transitions, triggers

123
44
Time trigger Trigger Region
Door closed
[t=1500] Elevate
entry/closed
Door is closing Door is opening Acknowledge
Do/open valve Do/close valve emerg. stop
Close Sensor [true]
Door opened
entry/opened
Transition Guard
Fig. 6 State machine diagram
and guards are used. While transitions merely define the
states between which transitions can be made, triggers
describe the events necessary for this purpose. In PLC
programs, changes of signal states of the machine (sensor
values), internal calls of the control system and user inputs
are used as events. A special kind of trigger is known as a
‘‘TimeTrigger’’. It can trigger a transition at or after a
certain amount of time. Additional constraints, called
guards, can be allocated to a trigger. These must be fulfilled
for a state transition to take place. The construct of regions
exists to represent concurrent activities. This allows the
cumulative behavior of a component to be described using
multiple partial automata, helping to reduce the
complexity.
When modeling the behavior of the hardware compo-
nents of the machine tool, the time behavior, logical
behavior and behavior resulting from errors are of primary
interest. Discrete, graph-oriented modeling mechanisms are
not suitable for specifying this behavior. It is true that
continuous/discrete behavior can also be modeled using
hybrid automata, such as in [16]. However, such techniques
can be understood by the physically oriented machine
design engineer only with difficulty. Instead, block-ori-
ented modeling of the machine behavior using timers,
simple mathematical functions, Boolean logic, lookup
tables (discrete allocation of input values to output values)
or its programming through script languages is favored.
Usually, mapping the hardware behavior using complex
differential-algebraic equations is not necessary for the
development of the PLC software.
The selection of the suitable model constructs depends
on the necessary degree of detail and the complexity of the
system behavior to be mapped. For specifying the function
of a simple gear, it is sufficient to determine the output
speed nout as a function of the speed ratio i and the input
speed nin (nout = nin/i). For modeling a complex cam disk,
123
Prod. Eng. Res. Devel. (2008) 2:39–46
State
Ready
Emergency
stop
failure
Do/close valve
Fig. 7 Modeling machine tool hardware
Activity
on the other hand, linking input and output variables based
on lookup tables has been found to be suitable Fig. 7.
The modeling of the system behavior and system
structure depends on the development task to be mastered.
When developing individual subassemblies of the machine
from scratch—such as a new tool magazine—the pure time
behavior may be sufficient in an early phase. If the missing
functions are further detailed in the course of development,
both the structure and the behavior of the software and
hardware components can be further refined. For modifi-
cation designs, existing models can be used. It is also
possible to use model libraries.
9 Target artefact generation
The next step of model-driven software development is
the target system-specific generation of the software, as
well as other development documents (artefacts), from the
models. In doing so, existing standards and the quality of
the software must be given equal consideration. There-
fore, the target code should conform to IEC 61131-3 [17].
This has several advantages. For example, it ensures that
the programs can run on PLCs from different manufac-
turers and that the necessary generators are generally
compatible. In this way, the effort for maintaining a
corresponding development environment can be signifi-
cantly reduced.
Due to the semiformal models and the need to consider
company-specific or customer specifications, the models
must be further refined by the developer for automatic
generation of the target code. For example, because of the
cyclical processing of the control programs by the PLC, it
is critically important to determine the call sequence for the
individual components. Likewise, data types and signal
properties must be defined. To implement the necessary
refinements using a development tool, various procedures
are recommended for model-driven development. A good
overview is provided in [18]. A method suitable for the
domain of machine tool development is described in [19].
Prod. Eng. Res. Devel. (2008) 2:39–46 45

10 Software validation and optimization through The control software can be tested without additional
simulations effort required to model the behavior of the NC, PLC and
user interface. Likewise, labor-intensive and error-prone
Until now, the implemented control programs have usually adaptations to the control code can be avoided. The inte-
been verified and optimized using a real prototype of the gration of the familiar, complete control and operation
machine tool. Once the essential installation tasks are functionality ensures acceptance by the users of the simu-
complete, the control programs are loaded onto the lation system. Using standardized interfaces for the
machine control system and tested incrementally. Errors in integration of the control hardware ensures that the simu-
the software are identified and corrected onsite. The reason lation models of the machine tool are independent from the
for proceeding in this manner is that the control software control hardware used. The implementation of a system of
only works correctly when it interacts with the electro- this kind is presented in [21].
mechanical, electrical, hydraulic and pneumatic
components of the machine. Thus preceding system testing
is not feasible [20]. 11 Summary
The mentioned procedure means that great effort is
required to implement the suggestions for improvement This article has presented an approach for model-driven
that are gained while commissioning the software during software development. It has focused on describing a
machine development. Likewise, the enormous time pres- corresponding methodology as well as suitable modeling
sure during verification and optimization of the developed constructs for this purpose. Also the integration of
programs leads to lower software quality and high costs. appropriate simulation methods was discussed. Future
The objective, therefore, is to commission the control work will focus on the implementation of methods for
software using the virtual model of the machine tool’s automated model transformation, the further formaliza-
hardware components. Two possible approaches exist for tion of modeling constructs and their integration and
this procedure. For hardware-in-the-loop simulation validation based on complex examples from the indus-
(HILS), the real NC, PLC and HMI are connected to a trial field.
virtual model of the machine tool. Software-in-the-loop
simulation (SILS) does not use any real control hardware.
The behavior of these components is reproduced and References
emulated. Figure 8 shows a comparison of the two
approaches described above. 1. Weck M, Brecher C (2005) Werkzeugmaschinen—automatisie-
rung von maschinen und anlagen, 6th edn. Springer, Berlin
HILS has a few key benefits. One is that it enables 2. Gausemeier J, Lindemann U, Reinhart G (2000) Kooperatives
mapping of the real time behavior. Though this reduces the produktengineering. Bonifatius, Paderborn
possible complexity of the simulation models due to the 3. Gewald N, Mikk E (2003) Ein industrielles wiederverwendungs-
requirement for real-time ability, it allows the integration konzept für IEC 61131-3 auf der basis von UML. Atp—
Automatisierungstechnische Praxis 45(6):59–68
of real machine components and the display of the real 4. Bundesministerium für bildung und forschung BMBF (ed) (2005)
time behavior of the machine tool components. Positionspapier—forschungs-und handlungsbedarf für zuverläss-
ige mechatronische systeme. Forschungszentrum karlsruhe,
Karlsruhe
5. Kent S (2002) Model driven engineering. In: Buttler M (ed)
Proceedings of the 3rd international conference on integrated
Propertiesofofthe
Properties theapproach
approach HILS SILS
HILS SILS
formal methods, Turku (Finland). Springer, Berlin
Low
Low effort
effort for modeling
modeling and
andadaption
adaption 6. Rugaber S, Stirewalt K (2004) Model-driven reverse engineering.
IEEE Softw 21(4):45–53
Representation of real
Representation of real time
timebehavior
behavior 7. Schlingloff H, Conrad M, Dörr H, Sühl C (2004) Modellbasierte
Full
Full integration the control
integration of the controland
andhuman-
human- steuerungsgeräteentwicklung für den automobilbereich. In: Plö-
machine-interface functionality
machine-interface functionality derer E (ed) Automotive—safety & security 2004—Sicherheit
und Zuverlässigkeit für automobile Informationstechnik, Stutt-
Integration
Integration of real hardware
hardwarecomponents
components gart. Shaker, Aachen
8. Fischer K, Vogel-Heuser B (2002) UML in der automati-
High
High model
model complexity
complexity sierungstechnischen Anwendung—Stärken und Schwächen.
Widely
Widely accepted by users
accepted by users Atp—Automatisierungstechnische Praxis 44(10):3–69
9. Stahl T, Voelter M (2005) Modellgetriebene softwareentwick-
Independent target control
Independent from target controlhardware
hardware lung—techniken, engineering, management, 1st edn. dPunkt,
Heidelberg
Fulfilled Not Fulfilled PartiallyFulfilled 10. Zeigler BP, Praehofer H, Kim TG (2005) Theory of modeling and
simulation—integrating discrete event and continuous complex
Fig. 8 Hardware and software-in-the-loop simulation dynamic systems, 2nd edn. Academic Press, Amsterdam

123
46
11. Selic B (1998) Using UML for modeling complex real-time
systems. In: Mueller F, Bestravos A (eds) Languages, compilers
and tools for embedded systems, Montreal. Springer, Berlin
12. Object management group: UML superstructure specification—
version 2.0. \http://www.omg.org/docs/formal/05-07-04.pdf[
(15th February 2007)
13. Weilkiens T (2006) Systems engineering mit SysML/UML—
modellierung, analyse, design. dPunkt, Heidelberg
14. Object management group: systems modeling language specifi-
cation—version 1.0. \http://www.omg.org/docs/ptc/06-05-04.pdf
[ (15th February 2007)
15. Engell S, Frehse G, Schnieder E (2002) Modelling, analysis, and
design of hybrid systems. Springer, Berlin
16. Henzinger TA (1996) The theory of hybrid automata. In: Pro-
ceedings of the 11th annual IEEE symposium on logic in
computer science, Los Alamitos (CA). IEEE Press, New Bruns-
wick (NJ)
123
Prod. Eng. Res. Devel. (2008) 2:39–46
17. IEC 61131-3: programmable controllers—Part 3: programming
languages. Beuth, Berlin (2004)
18. Object management group: model driven architecture guide—
version 1.0.1. \http://www.omg.org/docs/omg/03-06-01.pdf[
(15th February 2007)
19. Braatz A (2003) From model to code—generation of PLC soft-
ware from UML. In: Schraft RD, Brandenburg G, Bender K,
Hoepf M (eds) SPS/IPC/DRIVES, Nuremberg. VDE-Verlag,
Berlin
20. Zaeh MF, Ehrenstrasser M, Poernbacher C, Wuensch G Emerg-
ing virtual machine tools. In: Shimada K (ed) Design automation
conference, ASME design engineering technical conferences,
paper no. DETC2003/DAC-48756
21. Zaeh MF, Poernbacher C (2005) A Model-based method to
develop PLC software for machine tools. Ann CIRP 54(1):371–
374