City, University of London Institutional Repository
Citation: Houyou, A. M., Huth, H-P., Kloukinas, C., Trsek, H. and Rotondi, D. (2012). Agile
manufacturing: General challenges and an IoT@Work perspective. In: UNSPECIFIED (pp.
1-7). IEEE. ISBN 978-1-4673-4735-8
This is the accepted version of the paper.
This version of the publication may differ from the final published
version.
Permanent repository link: https://openaccess.city.ac.uk/id/eprint/12635/
Link to published version: http://dx.doi.org/10.1109/ETFA.2012.6489653
Copyright: City Research Online aims to make research outputs of City,
University of London available to a wider audience. Copyright and Moral
Rights remain with the author(s) and/or copyright holders. URLs from
City Research Online may be freely distributed and linked to.
Reuse: Copies of full items can be used for personal research or study,
educational, or not-for-profit purposes without prior permission or
charge. Provided that the authors, title and full bibliographic details are
credited, a hyperlink and/or URL is given for the original metadata page
and the content is not changed in any way.
City Research Online: http://openaccess.city.ac.uk/ publications@city.ac.uk
City Research Online
Agile Manufacturing
General Challenges and an IoT@Work Perspective
Amine M. Houyou, Hans-Peter Huth
Siemens AG, Corporate Technology
Munich, Germany
(amine.houyou/ hans-peter.huth)@siemens.com
Christos Kloukinas
Department of Computing
City University London
London, United Kingdom
C.Kloukinas@city.ac.uk
Henning Trsek
inIT - Institut Industrial IT
Ostwestfalen-Lippe University of Applied Sciences
Lemgo, Germany
henning.trsek@hs-owl.de
Domenico Rotondi
TXT e-Solutions SpA
Valenzano, Bari, Italy
Domenico.Rotondi@TXTGroup.Com
Abstract— This paper describes the potential impact of the
Internet of Things (IoT) technologies and architecture on factory
automation. Whereas, IoT use cases range from intelligent
infrastructure and smart cities to health care and shopping
assistants, it is important to note that factory automation could
benefit as well from an IoT approach. In this paper, we argue
that there will not be one IoT but many IoTs that could differ in
the type of infrastructure they are running or applications they
support. In IoT@Work we focus on the potential of making
manufacturing environments more agile and flexible. We explain
how the IoT-centric architecture for manufacturing also needs a
deep understanding of the manufacturing system and its state
today. We, therefore, do a reverse engineering based on the
requirements and the description of the agility expected in the
automation system itself.
Keywords-component; Internet of Things; Automation; Agility;
Modular factory; Auto-configuration; Plug-and-Play.
I. INTRODUCTION
The term agile manufacturing is often interpreted
differently from the various stakeholders or experts managing
production systems. To some extent machine and mechanical
setups could be made agile by increasing the number of
combinatory sets of mechanical, electrical and software
parameters a machine can have. This should make the machine
adaptable to many needs and many types of end products.
However, agility could also be approached in making the
production system as modular as possible, with independent
and intelligent components or units cooperating with each
other, to create the large number of combinatory
configurations. The manufacturing setup is meant to be
reusable, smart, and could be shared by many production
processes at the same time.
We, therefore, present the needs for automation devices and
computing systems to offer and support this flexibility and
agility. For this we also see one enormous hurdle to achieve
this, which is in the high cost and complexity of configuring
and reconfiguring the IT and communication part of the
automation system. One of the promising approaches that
should ease this complexity and cost problems could be based
on adapting the Internet of Things (IoT) to support automation
systems, in general, and more specifically, manufacturing.
The IoT [1] has recently gained a lot of interest from
numerous industries, where large numbers of devices,
machines, sensors, or simple things should become integral
part of the Internet, open to new distributed applications and
connected with IT services or the cloud. The industrial interest
in IoT arises from its promise to simplify initialization and re-
configuration tasks, reduce the complexity of the tasks
performed by humans and lead to faster response times for the
adaptations required, while at the same time minimizing
configuration errors and the associated system downtime. For
example, an automation expert will no longer need to assign IP
addresses for new devices manually and configure the QoS
characteristics of the network that they use. The challenge is to
achieve this within the strict safety critical and highly
expensive manufacturing environment, instead of the non-
critical environments that IoT has been targeting traditionally.
The vision of IoT@Work is to be able to configure large
numbers of intelligent devices in an automatic manner similar
to the way you plug and play a USB stick today. The device is
just plugged-in physically in the system, and to the network.
The latter takes care of the rest, until the device is made ready
for operation. This is one of the ways to achieve system
flexibility and agility. This paper provides an example of a
pilot setup to understand the constraints and limitations of
today’s technologies. This analysis is also used to extract
requirements and key performance indicators for IoT
architecture.
II. I
OT-ENABLED AGILITY
Configuration of automation systems relies today on
discrete engineering steps, which are carried out at the design
phase using a complex engineering environment. The latter
tools offer different views of the same engineered project, each
view presenting a given parameter set, such as the CAD layout
of the manufacturing setup, the PLC programming, the network
design, etc. The resulting engineered project details are then
transferred to the physical setup in several iterative steps
triggered by the engineer manually. This may in some cases
lead to errors, which are very hard to locate and debug given
the amount of complexity involved. The approach also assumes
a tightly coupled definition of the IT services and applications
running on top of the field level. The applications interaction
with the production is taking place through well established
gateways and filtering points, often defined in PLCs. These
gateways are the only entry points to richer IT appliances or
services running at enterprise (ERP) and manufacturing
execution (MES) levels, which deal with the logistics of the
production or materials, for instance. This leads to the pyramid
model for automation depicted in Figure 1. , which explains the
separation between the production system and its IT.
An IoT-enabled agile manufacturing system, in contrast, is
less rigid since it should rely on autonomous units offering
different resources, such as production capabilities, computing
power for complex PLC logic, or other type of services in a flat
and networked way. The system is characterized by:
• Highly modular production: where each module can
function in an isolated manner, can be replaced or
turned off, and whose hardware or software
components can be easily adapted and exchanged.
• Each module is automatically configured by interacting
with the network autonomously.
• Each module can be booted and configured in two
main phases; (1) basic connectivity and preparation for
further configuration, which includes addressing and
naming steps according to local conventions and to
administrative rules, in a way that a module can be
uniquely identified by the configuration tools or
programming environment; and (2) further
parameterization of modules, where modules can
receive the parameters of the applications and services
to be executed.
Figure 1. IoT enabled Automation
Thus the role of the network moves past from simply
offering communication, to also incorporating some
configuration intelligence in the form of configuration scripts,
policies, discovery or negotiation protocols [4].
The following introduces some general concepts that are
required for achieving agility, followed by a model factory at
the Institut Industrial IT that is then used to discuss agility-
related requirements and how these are met by the IoT@Work
architecture.
Figure 2. Setup of the LMF
A. Example of an Agile Factory
The Lemgo Model Factory (LMF) (see Figure 2. ) is a
hybrid manufacturing process, i.e. with process and factory
automation elements, in a small scale. It is used at the inIT labs
(Institut Industrial IT) to test new automation technologies in a
real industrial manufacturing process. In its first configuration
the complete LMF comprised five individual production cells.
Each of these provided some functionality for processing corn
seeds and producing at the end packaged pop-corn, illustrating
a complete manufacturing process.
B. Automation Aspects of Transformation
A state of the art production facility is typically realized in
a hierarchical structure. Every manufacturing cell is controlled
by one main PLC that executes control software. The overall
production process is controlled by a manufacturing execution
system (MES). The connection between PLCs and IO devices
in the manufacturing cell is realized with an industrial
communication network, commonly referred to as a fieldbus or
an industrial ethernet, which provides deterministic
communication with real-time guarantees (See Figure 3. ). In
an agile manufacturing environment, the bus structure changes
when new components are attached, or existing ones removed.
Such a change in the state of the production system requires
two steps of engineering. These are (i) a new import of the
modified fieldbus topology, including the assignment of
variable names, and (ii) a modification of the PLC program to
provide new sub-functionalities regarding the process to be
controlled. This is caused by the fact that the software executed
is always specialized to a particular production facility and its
corresponding physical process.
Figure 3. Network Architecture of the LMF
.
The software is implemented by an automation engineer or
a technician, using hardware vendor specific tools. Typically
these programming tools are based on the standard IEC 61131
[2]. This standard describes the programming methodologies of
PLCs and the widely accepted usual workflow. For example,
the available programming languages are defined in IEC 61131
part 3. Applying this standard helps to avoid very specialized
programming languages and programming workflows that are
different among PLC vendors. The typical workflow of
automation software development is shown in the following
list.
•Read bus configuration
•Assign IO ports to variable names
•Modify the current PLC program/project
•Compile the modified PLC program/project
•Download PLC program/project to PLC
In the first step of programming the control software of a
plant, all available devices must be included in the
programming tool. This is necessary to get detailed knowledge
about the attached devices and to make the inputs and outputs
of the all IO devices controlled by this PLC available in the
programming tool. The device structure can either be
automatically read by the engineering station or can be
assembled manually by the programmer using graphical tools.
If all devices connected to the bus are available in the bus
structure of the programming tool, variable names have to be
assigned to the ports of each device. This is necessary to make
data available to the PLC programs.
Since each available device provides only a general naming
of its IO ports, a meaningful name is normally used to make
programming easier and also easier to understand for later
changes or maintenance. In addition to the variable names, also
a description regarding the function of the variable can be
provided. This step of engineering can take a long time,
depending on the number of involved devices and the
documentation of the plant structure. A detailed documentation
helps associate devices with their functionality in the plant and
avoids additional effort for figuring out device responsibility.
C. Analysis of the Lemgoer Modellfabrik Agility
The modules of the Lemgoer Modellfabrik have been
analyzed with respect to their agility. The current results of this
analysis are presented below. However, some of the items of
interest are not yet clarified and have to be further investigated
as this project is progressing.
1) inIT stakeholder view:
• Agility through modular process;
• Modules are moveable and can be added to an existing
setup depending on production needs.
2) Technological view point:
• Module is connected through wireless network to main
PLC;
• Module has its own PLC, which makes it independent
of the rest of the setup;
• Agility is currently simulated and restricted through
PLC/SPS programming, where variables and code are
pre-engineered and pre-configured with the exact setup
of the mobile module. Currently once the new module
is added and establishes its connections, the PLC
program can call the process of the mobile module and
trigger it to start working. This is achieved by
introducing a library of function blocks for the
expected component classes. A function block
encompasses communication interfaces, services, data
structures (object models), and can be dynamically
instantiated. A lower end new component has to
register to its virtual function block instance, in order
to subscribe to certain services and publish its own
ones. All existing components need to know the
changes in the system in order to use available services
and to ignore unavailable services. Initially, the
manufacturing process of the modular “Lemgo Model
Factory” achieved this by extending PCWorX (the
utilized engineering software [7]) by a function block
(AR). This function block encompasses the Profinet
configuration of a single unit. Currently, a specialized
firmware at the IO controller is required, that enables
the PLC to sense continuously if the function block is
in an active or inactive state. In case of a dynamic
configuration change, this function block iss either
enabled or disabled for the running project.
• Other data-centered applications like events or process
monitoring have to keep track of the availability of the
mobile module;
• How to trigger the event-driven application running in
the local PLC and connected to a MES application?
And how to link both automatically?
3) Network view point:
Wireless connection has to deliver the same reliability as
wired Profinet, when used to connect an automation process.
• Real-time communication can be supported;
• Auto-configuration supported at network level,
involving mapping variables of the PLC program to
TCP connections. Currently the modules are
hierarchical building blocks, whose complexity
(variables, connections, controller/actuator/sensor
interactions) is hidden from the main PLC. The
number of variables that are manipulated by the central
PLC is limited.
• Can mobility lead to IP domain change? For instance
moving to another NAT subdomain?
4) Research view point:
• What is restricting full agility technologically?
• Can PLC programming be simplified by a more
service oriented-architecture?
o Can we encapsulate PLC software in a web
service?
o Can we enable invoking PLC services in a
more service oriented manner? I.e., less
detailed knowledge of the function blocks
and variables of both
sensors/actuators/controllers.
• Network services are pre-configured using engineering
tools – does this result into configuration files that need
to be made available to the mobile module in advance?
Could this be replaced by an on-the-fly negotiation
with the network manager that provides the
communication services requested by higher layers?
III. S
CENARIO-DRIVEN REQUIREMETS
Through the analysis of a number of different types of
manufacturing systems the IoT@Work project [3], [8] has
identified and is targeting eight high-importance general
requirements.
• A-G1.Allow system modifications at run-time, if the
remaining production subsystem is not affected.
• A-G2.Support fast re-initialization if the system
modifications are performed at an offline system state.
• A-G3.Allow controlled initialization when modifying
the system at run-time.
• A-G4.Support re-configuration of network paths in the
case of path faults, through a redundancy protocol.
• A-G5.Provide an easy and autonomous system
bootstrapping.
• A-G6.Support device migration through fast device re-
configuration.
• A-G7.Decrease the manual effort required for
configuration and re-configuration.
• A-G8.Enable the system to perform automated
decision making in response to faults.
At the same time, the project has identified four high-
importance requirements that are specific to automotive
manufacturing.
• A-A1.Provide a graphical network configuration
system, e.g., allowing drag & drop device
configuration.
• A-A2.Provide a graphical network maintenance
system, e.g., highlighting network faults and localizing
them at the port and wire level.
• A-A3.Provide a fast and reliable semantic addressing,
avoiding static IP addresses.
• A-A4.Support secure remote maintenance, potentially
by external companies.
The general requirements for agility (A-G1 – A-G8) target
the fast configuration of devices and network resources that is
needed either when these are introduced into the system for the
first time or when they need to be adapted to respond to system
faults. This configuration needs to be fast when the system is
offline, so as to decrease the overall system downtime, and it
specifically needs to be fast when the device re-configuration is
done during run-time. In the latter case it is crucial to be able to
