Erasmus
Erasmus
Erasmus
manufacturing
Citation for published version (APA):
Erasmus, J. (2019). The application of business process management in smart manufacturing: towards dynamic
allocation of manufacturing resources. Technische Universiteit Eindhoven.
Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please
follow below link for the End User Agreement:
www.tue.nl/taverne
Jonnro Erasmus
This thesis is part of the PhD thesis series of the Beta Research School for Operations Management
and Logistics (onderzoeksschool-beta.nl) in which the following universities cooperate: Eindhoven
University of Technology, Maastricht University, University of Twente, VU Amsterdam, Wageningen
University and Research, KU Leuven and Universiteit Hasselt.
ISBN: 978-90-386-4889-7
This research described in this thesis was part of the HORSE Project and received funding from the
European Union’s Horizon 2020 research and innovation program under grant agreement no. 680734.
The application of business process
management in smart manufacturing
PROEFSCHRIFT
door
Jonnro Erasmus
The research presented in this thesis explores the use of business process management (BPM) to
manage dynamic manufacturing processes. It is argued that BPM can complement current operations
management techniques by providing dynamically adjustable control, depending on the type of
activities and resources in the manufacturing processes. BPM is also utilised to drive integration
between business management, operations management, and the activities performed by humans,
robots and other machines. Lastly, BPM is positioned as an enabler for human-robot collaboration.
The technology-agnostic nature of BPM allows for flexible selection and assignment of resource
coalitions to perform manufacturing activities, based on the requirements of the activities and the
capabilities of resources.
Design science research is performed to investigate how BPM can be applied in smart manufacturing
operations. Thus, existing knowledge is adapted and extended for a new problem domain. The
research results in packages of knowledge, named artefacts, that can be utilised by practitioners to
apply BPM in manufacturing. The following three artefacts are presented in this thesis: 1) guidance
on the modelling of manufacturing processes to support the dynamic process management, 2)
guidance on the definition of versatile, collaborative human and robotic resources, and 3) a method
to select and assign resources to perform tasks. These three contributions are incorporated into a
process management system and demonstrated at three diverse factories across Europe. This
demonstration serves as proof of concept and leads to the conclusion that BPM, enhanced with
allocation of humans and robots, can be used to manage smart manufacturing processes.
v
PREFACE
I will not attempt to disparage the challenge I experienced during the four years that culminated in
this dissertation. More surprisingly, rather, is the source of the challenge. Despite the intricacies of
the scientific scope of my work, I consistently overcame technical problems and maintained steady
progress throughout the four years and, perhaps, even did too much in the end. Instead, it was the
duration and unfettered freedom that posed the real challenge. The PhD programme offered by my
supervisors, and the Eindhoven University of Technology in general, offers astonishing freedom to
craft your research objectives and activities. Even though my work was part of the affectionally named
HORSE Project, I still had ample space to manoeuvre and settle on my eventual research topic. Such
freedom inevitably leads to uncertainty, at least in my case. Although my supervisors frequently
allayed my fears, I could never quite dispel my concerns about the novelty and significance of my
work. Looking back now, I recognise that such concerns are not helpful, but perhaps natural. Attaining
a PhD is meant to demonstrate your capability as an independent scientific researcher, after all. That
independence is accompanied by the responsibility to make difficult decisions and stay the course,
even in the face of uncertainty and fatigue. Fortunately, independence does not equal solitude and I
am quite certain that this dissertation would not exist without support from the many colleagues,
friends and family who helped me over the last four years and before.
I don’t often have a chance to express gratitude quite so permanently and will therefore use this
opportunity as best I can. I must start with those who contributed most directly to my work. To Irene,
as my co-promotor and daily supervisor, your fortitude and “no-nonsense” approach to getting things
done kept me on track and allowed me to focus on the content, rather than getting tied down with
administration. I realise that I am not always the easiest person to work with, but your ability to see
the structure in the chaos helped me to keep things ticking over and eventually reach the end.
Complimentarily, Paul, as my promotor and mentor, you provided invaluable guidance through the
thought process and helped me to find my voice in the complex and confusing intersection of business
process management and manufacturing operations management. Your incessant praise and humour
also helped me to quickly regroup when doubt crept in. And then to my closest colleague, Kostas. I
have no doubt that this dissertation, in its final form, would not exist without your collaboration. I
truly hope you can build on what we have done so far and gain some personal benefit from it. After
all, you deserve to be rewarded for your patience and perseverance.
I was fortunate to be part of two larger groups of colleagues. I thank my colleagues in the TU/e
Information Systems group for sharing your extraordinary knowledge and for enduring my cynicism.
A special thanks to Bilge, Caro, Jason, Paulo, Rick and Sander (in alphabetical order) for your friendship
and camaraderie in a new career, new country and new continent. To my HORSE colleagues, I thank
you for extensive collaboration over the last four years, without which my thesis would have remained
an idea, instead of the demonstrable results that we achieved together. A special thanks to Ruud
Keulen; you unwittingly became the hidden heart of my entire thesis. Your ceaseless passion for your
work, your colleagues and manufacturing in general inspired me to develop something that, I hope,
can be applied to solve problems.
Moving to the people closest to me. None of this would be remotely possible without the
opportunities afforded to me by my mother and father. It is impossible to list everything I am grateful
vi
for, but I hope that using the opportunities that you gave me does at least partially offset your many
sacrifices. You devoted so much of your lives for the sake of my brother and I, that all we can really
do is thank you and do the best with what you gave us. Speaking of my brother, Eraum, I do not need
to say much. You are my oldest friend and I fully expect that we shall be part of each other’s lives until
time eventually catches up with us.
Lastly, and most importantly, my wife Trish. I will forever be grateful for your unwavering support.
You never complained about my many moments of lament and dread. I still maintain that ‘doing a
PhD’, as it were, is selfish. I found it to be such an isolated endeavour that I couldn’t even properly
explain the challenge. Nevertheless, you kept me motivated and your patience never depleted. I can
only promise that I will continue to do my best to make you happy.
As for the reader, I hope you find value in this dissertation. I can’t claim that it is an easy read, but it
is certainly filled with many interesting developments and, I hope, compelling results. I did my best to
present the work in a digestible and comprehensible fashion, but unfortunately science does not
always play nice. Although I wanted to simplify the useful parts of the work, it is my solemn duty to
protect the integrity of the work, rather than enhance the presentability. In the end, I will be content
if my work somehow contributes to the manufacturing industry, the lifeblood of any economy.
vii
TABLE OF CONTENTS
Table of figures ................................................................................................................................... xiii
Table of tables ................................................................................................................................... xvii
1. Introduction ................................................................................................................................... 1
1.1 Research context..................................................................................................................... 2
1.2 Problem description ................................................................................................................ 6
1.3 Proposition .............................................................................................................................. 8
1.4 Research scope ....................................................................................................................... 9
1.4.1 Manufacturing operations management ...................................................................... 9
1.4.2 Business process management ................................................................................... 10
1.4.3 The HORSE Project ...................................................................................................... 12
1.5 Research objective ................................................................................................................ 12
1.6 Research design .................................................................................................................... 14
1.7 Thesis outline ........................................................................................................................ 19
1.8 Publications related to this thesis ......................................................................................... 20
2. Problem Analysis ......................................................................................................................... 22
2.1 Background and the state of manufacturing ........................................................................ 22
2.1.1 Classification of production ......................................................................................... 22
2.1.2 Manufacturing operations management .................................................................... 24
2.1.3 Manufacturing information systems ........................................................................... 26
2.1.4 Types of manufacturing systems ................................................................................. 29
2.1.5 Smart manufacturing................................................................................................... 32
2.1.6 Key technologies in a smart factory ............................................................................ 37
2.1.7 Recent developments .................................................................................................. 39
2.1.8 The problems impeding smart manufacturing ............................................................ 42
2.2 Practical cases ....................................................................................................................... 44
2.2.1 Thomas Regout International ...................................................................................... 45
2.2.2 Sand-casting foundry in Poland ................................................................................... 55
2.2.3 Automobile parts assembly in Spain ........................................................................... 62
2.3 Findings: Problems in smart manufacturing ......................................................................... 69
2.4 Chapter conclusion ............................................................................................................... 70
viii
3. Design of a manufacturing process management system ........................................................... 71
3.1 Chapter outline ..................................................................................................................... 72
3.2 The case for unified process management in smart manufacturing ..................................... 73
3.2.1 Typical information systems in manufacturing ........................................................... 74
3.2.2 Process management in manufacturing information systems .................................... 77
3.2.3 Unified process management in manufacturing ......................................................... 78
3.3 Design of the manufacturing process management system ................................................. 81
3.3.1 Design process ............................................................................................................. 81
3.3.2 Design principles ......................................................................................................... 82
3.3.3 Logical view of the MPMS ........................................................................................... 85
3.4 Chapter conclusion ............................................................................................................. 100
4. Design of executable manufacturing processes ........................................................................ 102
4.1 Chapter outline ................................................................................................................... 103
4.2 Related work ....................................................................................................................... 104
4.2.1 Process modelling and enactment in manufacturing ................................................ 105
4.2.2 BPMN in manufacturing ............................................................................................ 106
4.2.3 General process modelling and enactment techniques ............................................ 106
4.3 Manufacturing operations .................................................................................................. 107
4.4 Necessary concepts to represent manufacturing operations as process models ............... 113
4.5 Manufacturing operations modelled with BPMN2.0 .......................................................... 116
4.5.1 Manufacturing process fragments ............................................................................ 117
4.5.2 Design of manufacturing processes as a combination of process fragments ............ 122
4.6 Evaluation ........................................................................................................................... 123
4.6.1 Completeness of the taxonomy of manufacturing operations and corresponding
process fragments ..................................................................................................................... 124
4.6.2 Execution suitability of the manufacturing process models ...................................... 124
4.6.3 Comprehension suitability of the manufacturing process models ............................ 126
4.7 Findings ............................................................................................................................... 128
4.8 Chapter conclusion ............................................................................................................. 128
5. Definition of manufacturing resources ...................................................................................... 130
5.1 Chapter outline ................................................................................................................... 131
5.2 Related work ....................................................................................................................... 131
ix
5.3 Classification of resources and activities............................................................................. 133
5.4 Agent attributes .................................................................................................................. 134
5.4.1 Human attributes ...................................................................................................... 134
5.4.2 Robot attributes ........................................................................................................ 142
5.4.3 Common agent attributes ......................................................................................... 156
5.5 Task requirements .............................................................................................................. 160
5.6 Tailoring the lists of agent and task attributes .................................................................... 162
5.6.1 Dynamism of attributes ............................................................................................. 163
5.6.2 Attribute changes ...................................................................................................... 164
5.6.3 Default attribute values for humans ......................................................................... 165
5.7 Method to define agents and tasks .................................................................................... 165
5.7.1 Definition of resources .............................................................................................. 166
5.7.2 Definition of tasks...................................................................................................... 166
5.8 Implementation in the MPMS ............................................................................................. 167
5.9 Evaluation ........................................................................................................................... 169
5.10 Chapter conclusion......................................................................................................... 172
6. Dynamic agent allocation .......................................................................................................... 173
6.1 Chapter outline ................................................................................................................... 173
6.2 Related work ....................................................................................................................... 174
6.2.1 Human resource allocation ....................................................................................... 174
6.2.2 Robot allocation ........................................................................................................ 175
6.3 Process view of the agent allocation module ..................................................................... 178
6.3.1 Data retrieval ............................................................................................................. 180
6.3.2 Pre-filtering of agents ................................................................................................ 181
6.3.3 Coalition formation ................................................................................................... 181
6.3.4 Coalition eligibility check ........................................................................................... 183
6.3.5 Coalition performance comparison ........................................................................... 184
6.4 Development view of the agent allocation module ............................................................ 186
6.5 Implementation .................................................................................................................. 189
6.6 Proof of concept.................................................................................................................. 190
6.6.1 Thomas Regout International .................................................................................... 191
6.6.2 Foundry in Poland ..................................................................................................... 194
x
6.7 Chapter conclusion ............................................................................................................. 196
7. Realisation and evaluation ........................................................................................................ 197
7.1 Chapter outline ................................................................................................................... 197
7.2 Realisation of the MPMS ..................................................................................................... 197
7.2.1 Physical view of the MPMS architecture ................................................................... 198
7.2.2 The MPMS as the core of the HORSE System ............................................................ 206
7.3 Evaluation ........................................................................................................................... 212
7.3.1 Practical demonstration of process enactment in smart manufacturing .................. 212
7.3.2 MPMS verification ..................................................................................................... 222
7.3.3 Technology acceptance evaluation ........................................................................... 223
7.4 Findings ............................................................................................................................... 226
7.5 Chapter conclusion ............................................................................................................. 228
8. Reflection and conclusion .......................................................................................................... 229
8.1 Research summary .............................................................................................................. 229
8.1.1 Design of the MPMS .................................................................................................. 230
8.1.2 Definition of executable manufacturing processes ................................................... 231
8.1.3 Definition of resources and tasks .............................................................................. 231
8.1.4 Allocation of resources to tasks during process run-time ......................................... 232
8.1.5 Realisation and evaluation ........................................................................................ 232
8.2 Scientific relevance ............................................................................................................. 232
8.3 Practical relevance .............................................................................................................. 233
8.3.1 Practical relevance enhanced by the HORSE Project ................................................. 234
8.3.2 Accessibility enhanced by the cloud .......................................................................... 235
8.4 Closing remarks ................................................................................................................... 235
8.4.1 Limitations ................................................................................................................. 235
8.4.2 Prospects ................................................................................................................... 236
8.4.3 Takeaway message .................................................................................................... 237
Bibliography....................................................................................................................................... 238
Appendix A: Terms and Abbreviations .............................................................................................. 258
Appendix B: Taxonomy of Human Abilities ....................................................................................... 260
Appendix C: Fleishman Job Application Survey ................................................................................. 264
Appendix D: Raw list of robot attributes ........................................................................................... 292
xi
Appendix E: Excluded robot attributes .............................................................................................. 302
Appendix F: Degree of protection ..................................................................................................... 307
Appendix G: Level of autonomy ........................................................................................................ 308
Appendix H: Agent Definition form ................................................................................................... 309
Agent description .......................................................................................................................... 309
Agent attributes............................................................................................................................. 310
Authorization ............................................................................................................................. 310
Tenancy ..................................................................................................................................... 310
Ability......................................................................................................................................... 310
Terrain traversability ................................................................................................................. 314
Functional attributes ................................................................................................................. 314
Non-functional attributes .......................................................................................................... 315
Appendix I: Task Definition form ....................................................................................................... 316
Task description ............................................................................................................................. 316
Task requirements ......................................................................................................................... 317
Authorization ............................................................................................................................. 317
Tenancy ..................................................................................................................................... 317
Ability......................................................................................................................................... 317
Terrain traversability ................................................................................................................. 321
Functional requirements ........................................................................................................... 321
Non-functional attributes .......................................................................................................... 322
Appendix J: Results of agent definition forms completed by participants ........................................ 323
Appendix K: Results of task definition forms completed by participants .......................................... 330
Appendix L: Combination Generator code ........................................................................................ 337
Appendix M –Technology Acceptance Model translated to Dutch for interviews ............................ 339
Waargenomen bruikbaarheid........................................................................................................ 339
Waargenomen gebruiksgemak ...................................................................................................... 339
xii
TABLE OF FIGURES
Figure 1: Interacting forces towards flexibility (adapted from (Grefen, 2015) ...................................... 3
Figure 2: Indicative comparison between dedicated, flexible and reconfigurable manufacturing
systems, based on cost, flexibility and volume. ..................................................................................... 4
Figure 3: Framework depicting various types of flexibility in manufacturing (Sawhney, 2006) ............ 6
Figure 4: Functional hierarchy of control in manufacturing enterprises (IEC, 2013). .......................... 10
Figure 5: BPM lifecycle according to (Dumas et al., 2013)................................................................... 11
Figure 6: Knowledge contribution framework of design science research, as proposed by (Gregor and
Hevner, 2013). ..................................................................................................................................... 13
Figure 7: The information systems research framework of Hevner et al. (2004). ............................... 15
Figure 8: Legend for symbols used in the research framework ........................................................... 15
Figure 9: Framework for this research, based on a combination of Verschuren and Doorewaard
(2010) and Hevner et al. (2004). .......................................................................................................... 16
Figure 10: Amalgamation of four artefacts into a design theory for the application of BPM in smart
manufacturing operations. .................................................................................................................. 18
Figure 11: Indication of the content contained in the thesis chapters. ............................................... 19
Figure 12: V-model showing the mirrored structure of the thesis. ..................................................... 20
Figure 13: Woodward's classification of production (Woodward, 1980). ........................................... 23
Figure 14: A indicative comparison of the manufacturing process complexity of unit production
(group 1) and mass production (group 2) according to Woodward (1980). ........................................ 24
Figure 15: Reference physical hierarchy of manufacturing equipment (IEC, 2013) ............................ 25
Figure 16: Primary functions of the MES (Ugarte et al., 2009) ............................................................ 28
Figure 17: Different order penetration points used to show different product delivery strategies.
Forecast-driven activities are depicted with dotted lines, whereas order-driven activities are
depicted with solid lines. ..................................................................................................................... 29
Figure 18: Example of a dedicated manufacturing line (courtesy of https://www.wisegeek.com/
under fair use policy). .......................................................................................................................... 30
Figure 19: Example of an FMS, with a lathe, mill, conveyor and robotic arms (courtesy of
www.hytechworld.com/ under fair use policy). .................................................................................. 31
Figure 20: Example of an RMS, showing multiple configurable work cells (courtesy of
https://intelligentsystems.eee.ntu.edu.sg/ used under fair use policy).............................................. 32
Figure 21: Features of industry 4.0 (Carvalho et al., 2018). ................................................................. 34
Figure 22: Reference architecture for manufacturing industry 4.0 (Hankel and Rexroth, 2015) ........ 34
Figure 23: Roles of selected technologies in smart manufacturing ..................................................... 37
Figure 24: Conventional vs. cooperative decision making (adapted from (Mařík and McFarlane,
2005)) .................................................................................................................................................. 41
Figure 25: A TRI telescopic slide on the left and a typical application of the product on the right
(reused with permission from TRI). ..................................................................................................... 45
Figure 26: TRI production process divided into three phases. ............................................................ 46
Figure 27: Steps of production phase 1: a) Load steel coil in the machine, b) Cut steel coil into profile
lengths, c) Stamp holes and bend lips, d) Finished Profile. ................................................................. 47
Figure 28: Pictures of production phase 2. Profiles on rack (left), and vats for surface treatment of
profiles (right). ..................................................................................................................................... 48
xiii
Figure 29: Photo of the automated assembly line in production phase 3. .......................................... 48
Figure 30: Physical hierarchy of TRI, with three work cells highlighted to indicate the location of the
application scenarios. .......................................................................................................................... 49
Figure 31: TRI manufacturing process, showing tool preparation and three phases of production. .. 50
Figure 32: Hardware and software systems of TRI, according to the levels of the functional hierarchy
of IEC62264:2013-1. ............................................................................................................................ 51
Figure 33: Tool assembly process at TRI. ............................................................................................. 53
Figure 34: Profile stacking and transport to storage. .......................................................................... 53
Figure 35: Loading of profiles onto racks in production phase 2. ........................................................ 54
Figure 36: Unloading of profiles from racks in production phase 2. .................................................... 54
Figure 37: Selected SCF castings for various applications and industries (used with permission from
SCF). ..................................................................................................................................................... 55
Figure 38: Physical hierarchy of SCF, with one work cell highlighted to indicate the location of the
scenario. .............................................................................................................................................. 56
Figure 39: Cross-functional manufacturing process of SCF, showing sales and marketing, engineering
and operations. ................................................................................................................................... 57
Figure 40: Hardware and software systems of SCF, with problem areas highlighted. ........................ 59
Figure 41: Manual operations of separating castings off gating systems (used with permission from
SCF) ...................................................................................................................................................... 59
Figure 42: Grape separation scenario at SCF, with teaching-by-demonstration technology. ............. 61
Figure 43: Typical product of APA (retrieved from www.horse-project.eu). ....................................... 62
Figure 44: Physical hierarchy of APA, showing the area of focus highlighted in blue.......................... 63
Figure 45: Overall manufacturing process of front wiper systems at APA. ......................................... 64
Figure 46: Depiction of the hardware and software systems of APA, showing a lack of integration
between level 3 systems. .................................................................................................................... 65
Figure 47: Visual Inspection of label presence, no damages of 4 link ball sockets and screening covers
(dust caps) not clamped up to 4 pieces ............................................................................................... 66
Figure 48: Two activities of the APA case, showing a) assembly handing and b) placing an assembly in
the container. ...................................................................................................................................... 66
Figure 49: Process model of the scenario at APA. ............................................................................... 68
Figure 50: Outline of chapter 3. ........................................................................................................... 72
Figure 51: Progressive modularization of information systems, illustrating that process management
can be relinquished to a business process management system (adapted from (van der Aalst, 1998)).
............................................................................................................................................................. 74
Figure 52: Software and hardware systems related to the functional hierarchy of IEC62264:2013-1
(IEC, 2013). .......................................................................................................................................... 77
Figure 53: Eleven MES functionalities according to MESA (1997). ...................................................... 78
Figure 54: Infrastructure and application layers, showing three typical information systems in the
infrastructure layer. ............................................................................................................................. 79
Figure 55: Architecture layers shown as a horizontal axis, with a single functional level shown for the
application layer. ................................................................................................................................. 79
Figure 56: Process-centric architecture for computer integrated manufacturing showing MPMS as an
orchestration hub for level 2, 3 and 4 systems. ................................................................................... 80
Figure 57: Cross-section view of the infrastructure and application layers to explain how the
infrastructure systems facilitate connectivity. .................................................................................... 81
xiv
Figure 58: Kruchten 4 + 1 framework (Kruchten, 1995). ..................................................................... 82
Figure 59: The Reference Architecture for Industry 4.0 (RAMI4.0) as presented in DIN SPEC
91345:2016-04. ................................................................................................................................... 83
Figure 60. Illustrative physical hierarchy of a manufacturing enterprise based on the hierarchy levels
dimension of RAMI4.0. ........................................................................................................................ 84
Figure 61: Evolution from a traditional asset to an industry 4.0 component (DIN Deutsches Institut
für Normung, 2016). ............................................................................................................................ 85
Figure 62: Modernized variation on the Truijens 5 aspects framework (Grefen, 2016). ..................... 86
Figure 63: Process lifecycle phases ...................................................................................................... 87
Figure 64: Illustrative process lifecycles exemplify differences based on product .............................. 87
Figure 65: Activity diagram showing the states of processes, tasks and resources. ............................ 89
Figure 66. Illustrative physical hierarchy of a manufacturing enterprise showing the different control
regimes applied at different levels of the enterprise. ......................................................................... 90
Figure 67: MPMS in the context of IoT, showing the potential for inter-organizational process
management. ...................................................................................................................................... 91
Figure 68: Data aspect of the MPMS, at aggregation level 1. .............................................................. 92
Figure 69: Location-related portion of the data aspect model of the MPMS. ..................................... 93
Figure 70: Resource-related portion of the data aspect model of the MPMS. .................................... 95
Figure 71: Activity-related portion of the data aspect model of the MPMS........................................ 96
Figure 72: Reference architecture of a workflow management system (Hollingsworth, 1995). ......... 97
Figure 73: The MPMS in the context of the functional hierarchy levels, with interfaces to application
systems. ............................................................................................................................................... 99
Figure 74: Software aspect of the MPMS architecture showing the new (coloured blue) and
enhanced (coloured green) logical system modules. ........................................................................ 100
Figure 75: The MPMS software aspect architecture, showing how system modules relate to
subsequent chapters in this thesis. ................................................................................................... 101
Figure 76: Overview of research approach. ....................................................................................... 104
Figure 77: First three levels of the taxonomy of manufacturing operations. .................................... 110
Figure 78: Sand casting process according to Groover (2016)........................................................... 122
Figure 79: Sand casting process of Groover (2016) modelled as a combination of model fragments.
........................................................................................................................................................... 123
Figure 80: Model for the wiper system inspection and packaging process, comprised of multiple
process model fragments. ................................................................................................................. 125
Figure 81: Results of homomorphism related questions. .................................................................. 127
Figure 82: Questions and results related to model understandability. ............................................. 127
Figure 83: Introduction of characteristics as additional criteria for resource allocation. .................. 131
Figure 84: Overview of the data aspect model of the MPMS. ........................................................... 133
Figure 85: Proposed taxonomy of human resource allocation criteria of Arias et al. (2017). ........... 135
Figure 86: Extract of the taxonomy of human abilities (Fleishman, 1975), showing selected abilities in
each of the four categories. ............................................................................................................... 139
Figure 87: Measurement scale for one of abilities of the taxonomy of human abilities, extracted from
(Fleishman and Reilly, 1995). ............................................................................................................. 140
Figure 88: Progressive refinement of the SLR results. ....................................................................... 144
Figure 89: Depiction of the method to specify tasks and agents in terms of attributes. ................... 166
Figure 90: Data tables used to store agent attribute information for allocation. ............................. 168
xv
Figure 91: Data tables used to store task requirement information for resource allocation. ........... 168
Figure 92: Results of the method evaluation, based on responses from 11 participants.................. 171
Figure 93: Taxonomy of task allocation in multi-robot systems (Gerkey and Matarić, 2004b). ........ 175
Figure 94: The fourth dimension of the ITax, introduced by Korsah et al. (2013) as an enhancement
of the taxonomy of (Gerkey and Matarić, 2004b). ............................................................................ 176
Figure 95: UML sequence diagram of the agent allocation algorithm. ............................................. 179
Figure 96: The devil's quadrangle of Brand and Van der Kolk (1995). ............................................... 185
Figure 97: UML class diagram of the agent allocation algorithm. ..................................................... 187
Figure 98: Illustrative process model showing one task without dynamic allocation and one with
dynamic allocation............................................................................................................................. 189
Figure 99: The process model called by all tasks designated for dynamic agent allocation. ............. 190
Figure 100: Photo of the TRI tool assembly process, post-intervention. ........................................... 191
Figure 101: Tool assembly scenario at TRI after introduction of a mobile robot and augmented
reality................................................................................................................................................. 192
Figure 102: Comparison of the tool assembly process duration comparison without agent allocation
and with agent allocation enabled. ................................................................................................... 193
Figure 103: Duration of the assembly and disassembly tasks as performed by different agents...... 193
Figure 104: Duration of fetch and return tasks, as performed by different agents. .......................... 194
Figure 105: Grape separation scenario at SCF in Poland. .................................................................. 195
Figure 106: Simplified representation of Camunda BPM architecture (Camunda Services GmbH, n.d.).
........................................................................................................................................................... 200
Figure 107: Mapping between modules of the MPMS and Camunda BPM. ..................................... 201
Figure 108. Overview of cloud support for the MPMS. ..................................................................... 204
Figure 109. Technology stack showing the MPMS as an IoT application. .......................................... 205
Figure 110: Software aspect of the HORSE System (Grefen et al., 2016). ......................................... 207
Figure 111: HORSE Design Global logical architecture, aggregation level 4. ..................................... 209
Figure 112: Global Execution module software architecture, aggregation level 4 ............................ 210
Figure 113: The HORSE System positioned in the functional hierarchy of IEC62264:2013-1. ........... 211
Figure 114: TRI manufacturing process, showing tool preparation and three phases of production.
........................................................................................................................................................... 213
Figure 115: Executable model of the 'place profiles in bin' subprocess. ........................................... 214
Figure 116: Screenshot of the SCF during execution. ........................................................................ 215
Figure 117: Executable model of the P2 loading' subprocess............................................................ 216
Figure 118: Executable model of the cross-functional process, including sales, marketing,
engineering and operations activities. .............................................................................................. 218
Figure 119: Executable model of separation process in the finishing production area. .................... 219
Figure 120: Executable model of the inspection and packaging process at APA. .............................. 221
Figure 121: 7-point Likert scale for usefulness and ease of use. ....................................................... 223
Figure 122: Graph showing the response averages and standard deviations. .................................. 225
Figure 123: Software aspect of the MPMS architecture, showing the chapters dedicated to its
extensions.......................................................................................................................................... 230
Figure 124: Overview of the method to describe agents and tasks. ................................................. 309
Figure 125: Overview of the method to describe agents and tasks. ................................................. 316
Figure 126: 7-punt likert schaal ......................................................................................................... 339
xvi
TABLE OF TABLES
Table 1: Push and pull mechanisms driving manufacturing flexibility (Ahuett-Garza and Kurfess,
2018; Monostori, 2014; Oztemel and Gursev, 2018). ........................................................................... 3
Table 2: Indication of how BPM may help to alleviate some of the problems identified in smart
manufacturing. ...................................................................................................................................... 8
Table 3: Core concepts of this research. .............................................................................................. 14
Table 4: Levels of contributes in design science research, according to (Gregor and Hevner, 2013). . 18
Table 5: Scientific publications and associations to chapters in this thesis. ........................................ 20
Table 6: Comparison of the smart and traditional factory (Wang et al., 2016). .................................. 35
Table 7: List of topics discussed for each practical case, with references to the specific sections
where those topics are introduced...................................................................................................... 44
Table 8: Main activities in the semi-automated process at APA. ........................................................ 67
Table 9: Requirements of the MPMS as derived from literature and practice. ................................... 69
Table 10: Information systems associated with the functional hierarchy levels of IEC62264:2013-1. 75
Table 11: System design principles derived from the three RAMI4.0 dimensions. ............................. 85
Table 12: Definitions of entities as extracted from the formal framework for agency of Luck and
d’Inverno (1995). ................................................................................................................................. 94
Table 13: MPMS requirements mapped to extended system functions. ............................................ 97
Table 14: Operation types and descriptions of production operations. ............................................ 110
Table 15: Operation types and descriptions of inventory operations. .............................................. 112
Table 16: Operation types and descriptions of maintenance operations. ......................................... 112
Table 17: Operation types and descriptions of quality operations .................................................... 113
Table 18: Production operations decomposed into input, activity and output elements. ................ 114
Table 19 : Inventory operations decomposed into input, activity and output. ................................. 115
Table 20: Maintenance operations decomposed into input, activity and output. ............................ 115
Table 21: Quality operations decomposed into input, activity and output. ...................................... 116
Table 22: Process model fragments of production operations ......................................................... 117
Table 23: Process model fragments of inventory operations ............................................................ 119
Table 24: Process model fragments of maintenance operations ...................................................... 120
Table 25: Process model fragments of quality operations. ............................................................... 121
Table 26: Mapping of Prat et al. (2014) and Moody (2009) criteria. ................................................. 126
Table 27: Analysis of the criteria for human resource allocation of Arias et al. (2017) to determine
which criteria can be considered task specific. ................................................................................. 136
Table 28: Self-determined expressions for the remaining 22 human attributes. Author is unable to
determine how to express five of the attributes, leaving 17 human attributes. ............................... 140
Table 29: Incremental refinement of the SLR search term. ............................................................... 142
Table 30: Six robot attribute definitions retrieved from the Handbook of Industrial Robotics (Ceroni
and Nof, 1999). .................................................................................................................................. 145
Table 31: Twelve robot attributes newly defined in consultation with robotics experts. ................. 146
Table 32: Ten attribute definitions from original literature improved in consultation with robotics
experts. .............................................................................................................................................. 146
Table 33: Sources of attribute definitions in three groups. ............................................................... 147
Table 34: Overview of attributes eliminated in the interest of set consistency ................................ 148
xvii
Table 35: Overview of attribute elimination because of consistency check and undefined attributes.
........................................................................................................................................................... 149
Table 36: Remaining 73 robot attributes that are either defined or the meaning can be inferred from
the attribute name. ........................................................................................................................... 149
Table 37: 39 robot attributes and corresponding definitions excluded as a result of the comparison
to manufacturing operations. ............................................................................................................ 152
Table 38: Final list of 34 robot attributes, with descriptions and units of measurement. ................. 154
Table 39: List of robot ten attributes that are comparable to human attributes and a decision of
whether to keep the human or robot attribute. ............................................................................... 156
Table 40: Calculation of the eventual number of agent attributes. .................................................. 156
Table 41: Two attribute names changed to better reflect their nature. ........................................... 157
Table 42: Attribute definition improvements to make more sense as attributes for agent allocation.
........................................................................................................................................................... 157
Table 43: Final list of 41 agent attributes for resource allocation, in alphabetical order. ................. 158
Table 44: Twelve agent attributes that can't be expressed as task requirements, with reasons given.
........................................................................................................................................................... 160
Table 45: List of 29 attributes that can be used to specify task requirements. ................................. 161
Table 46: Relative frequency at which different attributes are updated. ......................................... 163
Table 47: Questions used to structure the interview and gauge the practitioner’s acceptance of the
method. ............................................................................................................................................. 169
Table 48: Classification of the agent allocation algorithm, derived from features of the MPMS
architecture. ...................................................................................................................................... 177
Table 49: Guidance on the retrieval of data and storage in containers that can be used by the
algorithm. .......................................................................................................................................... 180
Table 50: Merging of agent attributes to determine coalition attributes. The eight attributes used for
pre-filtering, as explained in Section 6.3.2, are included, in case those attributes were not used to
filter the agents before coalition formation. ..................................................................................... 182
Table 51: Processing of eligibility attributes to determine whether a coalition can perform a task. 183
Table 52: The nine coalition attributes that can be used for performance comparison, with an
indication for how each attribute can be used. ................................................................................. 185
Table 53: Weighted comparison of four prominent BPMSs. ............................................................. 198
Table 54: Advantages and disadvantages of SaaS, PaaS, and on-premise models in relation to the five
considerations for cloud-support. ..................................................................................................... 202
Table 55. Application of the five considerations for cloud-support for the modules of the MPMS. . 203
Table 56: Technology decisions for the realisation of the MPMS...................................................... 207
Table 57: Explanation of HORSE Design Global modules not included in the MPMS. ....................... 209
Table 58: Explanation of HORSE Exec Global modules not included in the MPMS. .......................... 211
Table 59: MPMS requirements from Chapter 2, as derived from scientific literature and practical
cases. ................................................................................................................................................. 222
Table 60: Questions asked during interviews with average ratings by interviewees. ....................... 224
Table 61: Definitions for terms that feature prominently in the thesis. ............................................ 258
Table 62: Clarification of abbreviations used in this thesis. .............................................................. 259
Table 63: Full list of robot attributes retrieved during the SLR. ........................................................ 292
Table 64: Eleven attributes Excluded because they are too abstract. ............................................... 302
Table 65: 58 attributes Excluded because they are a subset of another attribute. ........................... 302
xviii
Table 66: Fifteen attributes excluded because they are a duplicate of another attribute. ............... 305
Table 67: Nine attributes Excluded because they are a superset of other attributes. ...................... 305
Table 68: Thirteen attributes excluded because they describe a component, rather than an output or
capability. .......................................................................................................................................... 306
Table 69: Agent identification information. ...................................................................................... 310
Table 70: Task identification information. ......................................................................................... 316
xix
Chapter 1
1. INTRODUCTION
Manufacturing enterprises have sought process improvement since the dawn of the industrial age.
Production lines and division of labour brought early gains in productivity. Automation further
increased productivity, especially when paired with computer control systems. Now, a new wave of
technologies, centred around the ubiquitous internet, is expected to further enhance the prowess of
manufacturing facilities. Manufacturing enterprises want to harness these new technologies to
improve their processes and increase customer satisfaction.
Customer satisfaction is inherently a vicious cycle though. As with most human endeavours, the
satisfaction derived from the consumption of a service or acquisition of a product tends to be short
lived. The consumer shifts focus to a next source of satisfaction almost as soon as the previous goal is
attained (Sutton and Davidson, 1997; Haidt, 2006). This fleeting nature of consumers causes a
situation where products and services must improve indefinitely. In the domain of business
management, this is often termed continual improvement and it is widely recognised as essential to
sustained success (Bessant et al., 1994, 2001). Along with our inherent curiosity, this fleeting nature
is also one of the fundamental forces behind the success of humanity. We always strive for more or
better on our insatiable drive for comfort, pleasure and satisfaction.
When considered systemically, this phenomenon can be described as an "escalation" archetype, with
multiple competitors vying for a finite number of customers (Senge, 2006). The escalation archetype
is quite common in free market systems, due to the competitive nature of capitalism. Simply put,
competing vendors stubbornly reduce their prices or improve their offering to attract more
customers. The global arms race can be used to explain this archetype, with multiple countries
competing for military superiority, ultimately resulting in an exponential increase in the total stockpile
of weapons (Mrotzek and Ossimitz, 2008). Fundamentally though, the escalation archetype consists
of two or more reinforcing loops, where action is taken by one party to control an outcome relative
to another party. Each party attempts to gain relative control, but the net result is an escalation of the
total system magnitude, whether it is an increase in quality, price or the stockpile of weapons
(Wolstenholme, 2003).
Comparing healthy competition in the marketplace to an arms race is perhaps a bit unkind, but the
underlying systemic structure is similar. However, the similarities end with the stimuli that drive the
reinforcing loops. Where an arms race is motivated by negative stimuli such as fear and destruction,
capitalistic competition is driven by market share and revenue – profoundly more positive motivators.
Product vendors and service providers persistently improve the value of their offerings to either
increase the satisfaction of their current customers or to satisfy the expectations of additional
customers.
From the customer’s perspective, the value of the offering is essentially the ratio of benefits to
outlays, even though those two quantities are most often only based on the customer’s perception
(Naumann and Jackson, Jr, 1999). This measure of customer satisfaction is the consumer orientation
1
to quality, focussing on human expectation and the performance of a product in the market (Shewfelt,
1999). Zeithaml (1988) showed that this perception of quality is also heavily influenced by factors such
as brand name, advertising and the price of the product. In contrast, enterprises tend to take a more
objective view of quality, essentially boiling down to conformance to requirements and the
prevalence of defects (Crosby, 1979). This product orientation to quality, based on the attributes and
ingredients of the product, may be more objective than the consumer orientation to quality, but both
orientations are based on the values of the consumers and managers (Zeithaml, 1988).
Values are changing though, for both customers and managers. Personalisation is quickly gaining
importance alongside high performance and low price. Increasingly, customers expect the
opportunity to customise a product to suit their personal needs (Kroes et al., 2009). This customer
expectation can be an opportunity for a manufacturing enterprise. The customer can be embraced as
a collaborative partner, gaining better understanding of unique customer behaviour and co-creating
more innovative products (Salunke et al., 2011; Herrera, 2015). Managers are also under increased
scrutiny for the working conditions of personnel and the environmental impact of their factories.
Although automation shows no sign of slowing, new technologies such as wearable devices and
augmented reality are also changing human-centric operations.
Changing expectations and new technologies are particularly disruptive to the manufacturing process.
New tools and techniques are introduced to produce more varied products, while maintaining high
volume and quality. The extent of the variation is also increasing, with customers exploring the
possibilities of truly personalised products (Wang et al., 2017). Such variability necessitates greater
process flexibility and versatile production resources. Factories must modernise and embrace the
internet in their operations, forming one of the cornerstones of the fourth industrial revolution
(Carvalho et al., 2018).
Increased product customisation and variation places new demands on manufacturing systems. The
following effects have been identified, but more adverse effects are expected (Khan and Turowski,
2016):
• Batch sizes are shrinking to accommodate more product variation, leading to frequent
production downtime for system reconfiguration and tool change-over.
• More product variation necessitates more versatile production operations, as a larger
variety of material and product transformations are needed.
2
• A wider range of product specifications and more production possibilities introduce
significantly more complexity into the planning and operations management.
• More complexity leads to uncertainty, because the manufacturing processes and resources
have a more unpredictable impact on the product.
The pursuit of more flexibility in manufacturing is an enduring trend (Gerwin, 1987; Mishra et al.,
2014). The need is even strengthening with the accelerated rate of change in the market and customer
expectations. Demand fluctuation and mass customisation pulls manufacturers towards volume and
product flexibility. Meanwhile, new technologies push factories towards technology and equipment
flexibility. Thus, we see a requirements-pull force and a technology-push force that reinforce each
other (as shown in Figure 1), leading to increasing speed in developments.
The push and pull forces can be elaborated a bit more, by referring to the specific stimuli. Table 1
shows a few stimuli but makes no attempt to be exhaustive.
Table 1: Push and pull mechanisms driving manufacturing flexibility (Ahuett-Garza and Kurfess,
2018; Monostori, 2014; Oztemel and Gursev, 2018).
Responding to both push and pull mechanisms, various types of manufacturing systems have been
created. A manufacturing system is “the arrangement and operation of elements (machines, tools,
materiel, people and information) to produce a value-added physical, informational or service product
whose success and cost is characterized by the measurable parameters of the system design” (Suh et
al., 1998). Dedicated manufacturing systems led to the rise of mass produced and more affordable
products. Flexible manufacturing systems (not to be confused with the concept of manufacturing
flexibility, i.e. the drive for more responsive operations) responded to the need for factories that can
produce a large variety of products at small scales. These systems represented two extremes: 1)
3
dedicated manufacturing systems with low flexibility and low cost per product, and 2) flexible
manufacturing systems with high flexibility and high cost per product.
Eventually, the need arose for dedicated manufacturing systems to be more flexible, to be able to
respond to fluctuations in market demand and availability of materials and resources (Koren et al.,
1999). The response was a new class of manufacturing systems that make use of configurable tools.
Reconfigurable manufacturing systems have the following three important characteristics (Landers et
al., 2001):
• The system and its machines are designed for adjustable structure that enable system
scalability in response to market demands.
• The system and its machines are adaptable to new products. The structure may be adjusted
at the system level and at the machine level.
• The manufacturing system is designed around the part family, with the customized flexibility
required for producing all parts of this part family.
Figure 2 indicates how reconfigurable manufacturing systems compare to dedicated and flexible
manufacturing systems. This chart is purely indicative, as it illustrates the trade-off between cost,
volume and flexibility, with reconfigurable systems aiming for a good middle ground between
dedicated and flexible manufacturing systems.
Flexible
manufacturing
systems
Reconfigurable
Cost
manufacturing
systems
Dedicated
manufacturing
systems
Bubble size
indicates volume
Flexibility
Reconfigurable manufacturing systems are well suited for fluctuating market demand and inventory
availability (Koren and Shpitalni, 2010). The systems achieve small production runs and reasonably
4
quick change-over between production runs. However, the desire for personal and individual products
is leading to a rapid increase in the demand for mass customisable products. Mass customization and
personalization is approaching a state where every instance of a product may be unique. For example,
certain luxury vehicles are offered with such an extensive list of options and extras that it is
conceivable that no two instances of that vehicle will have exactly the same specifications. This is most
certainly more evident in high-tech products of high value, such as automobiles and aircraft, but the
phenomenon is even spreading to traditional products (Kroes et al., 2009).
With customers expecting more personalised products, the production batches are shrinking to an
individual level. Manufacturers again responded by introducing smaller cells in the manufacturing
process. A piece of equipment can apply a wide range of effects if that particular step in the process
is granular enough. For example, a robot can install a wide range of screws if it is only installing screws.
Thus, high flexibility can be achieved by combining many small steps with dedicated equipment for
each step. Plainly though, this will result in high capital and operating cost, which is unacceptable for
smaller enterprises. It is also a high-risk situation because the probability of equipment failure is
directly proportional to the amount of equipment. The unavailability of any of the high number of
manufacturing cells will halt the entire process. Equipment is not easily swapped or replaced in such
an aggregated system.
To keep cost down while reaching for more individualised products, manufacturers want to do more
with less equipment and operating personnel (Mehrabi et al., 2000). Modern industrial robotics offer
the versatility needed to perform the wide range of activities necessary to produce highly
customisable products (Jeschke et al., 2017). The versatility can be leveraged by the ubiquitous
connectivity offered by the IoT, resulting in a manufacturing system that is smarter. Davis et al. (2012)
proposes that smart manufacturing assists with management of complexity in manufacturing,
dynamic demand and product variability. Gilchrist (2016) argues that a smart manufacturing system
can dynamically configure itself according to production requirements, drastically decreasing the
change-over time between product variances.
The rise of smart manufacturing indicates that a new age of manufacturing is upon us. In Europe, this
age is designated as Industry 4.0, signifying its place in the fourth industrial revolution. This new
industrial age stems from the rise of the internet-of-things, cyber-physical systems and cloud
computing (Lu, 2017). It is expected that mass customized products will be produced by advanced
robotics in dynamic processes, promising significant gains in production output, product
customizability and manufacturing flexibility (Hofmann and Rüsch, 2017). However, any change is
5
accompanied by uncertainty and unexpected problems. This is especially true for a disruptive change,
such as the revolutionary change brought about by Industry 4.0.
Pérez et al. (2016) uses the framework to delineate external and internal flexibility. External flexibility
takes a broad perspective, focussed on the supply chain (supplier flexibility) and time to market
(customer flexibility), shown outside of the box in Figure 3. In contrast, internal flexibility refers to the
ability of a firm to economically and effectively change operations, with a focus on the flexibility of
alternative process configurations and technologies. In Figure 3, internal flexibility is shown inside the
box, composed of input, process and output flexibility.
6
This research is primarily interested the internal flexibility of an enterprise. More specifically, in
process-related issues that inhibit the flexibility needed for Industry 4.0. By focussing on the process
stage in the Sawhney (2006) framework, the process-related issues can be identified on the following
three levels:
1. Poor interoperability of the input, process and output stages of a manufacturing system
limits the capacity to respond to demand and supply uncertainties.
2. Insufficient process flexibility decreases the ability to adapt to changes in the manufacturing
system caused by internal or external uncertainties.
3. Inflexible utilisation of resources (humans, equipment, tools, etc.) limits the versatility
needed to produce varied products.
Interoperability has a significant impact on flexibility (Panetto and Molina, 2008). Internal flexibility,
as defined by Pérez et al. (2016), is affected by the interoperability of the input, process and output
stages of the manufacturing system. Stated differently, flexibility is affected by the broad
manufacturing process, stretching across multiple business functions, including supply chain
management, operations, product delivery and after-sales support. Consequently, cross-functional
process integration is a crucial step towards smart manufacturing, but remains a problem with no
clear solution (Malte et al., 2011; Qin et al., 2016; Weyer et al., 2015).
Lastly, the people and machines that participate in the processes must be able to adapt to the changes
caused by demand fluctuation, product customisation and dynamic reconfiguration. In fact, the
increased versatility offered by smart devices and mobile technology are expected to be a key enabler
for Industry 4.0 (Heyer, 2010; Longo et al., 2017; Rus et al., 2002). However, the control systems of
machines and robots are not well suited to frequent changes in the environment and production
specifications (Newman et al., 2008). Control systems are typically dedicated to a specific set of
activities in a predefined area of a factory. Allowing operators and equipment to cross functional
barriers goes beyond the capabilities of current control systems. These systems also tend to be
proprietary, resulting in fragmented resource control in a technologically heterogeneous factory
(Bruyninckx, 2001). Thus, a factory seeks the ability to dynamically alter the configuration of human
operators, machines and activities, but can’t effect such changes from a central point of control.
In summary, the following process-related problems emerge in smart manufacturing, all contributing
to an inability to increase of flexibility in an enterprise:
7
• Smart technologies, such as versatile robots and autonomous guided vehicles, are under-
utilized, because the rigid process design and management does not encourage rapid
reconfiguration and reassignment of resources.
• The number of hardware and software systems continue to increase, based on different
control regimes from different vendors. These systems are difficult to integrate and utilise
together in the same process.
The three emerging problems can be distilled into a single problem statement, by focussing on
manufacturing process management as the common factor. Therefore, the following problem
statement is used as the central motivation in this thesis:
Current manufacturing process management techniques and technologies are not well equipped for
the flexibility needed in Industry 4.0.
1.3 Proposition
Business process management arose from the positive results achieved by industrial process
engineering to improve performance and decrease cost of operations (Dumas et al., 2013; Lindsay et
al., 2003). It is odd then, that the two practices have drifted apart so quickly. Today, the competencies,
methods, standards, techniques and tools applied are remarkably different, even though both
practices are applied with the same goals.
Although industrial process engineering has been practiced considerably longer than business process
management, most of the scientific and professional progress has been confined to localised
optimisation and improvement (Cameron and Ingram, 2008; Moro, 2003). The focus is typically on the
technological development of specific nodes or portions of the process, to improve overall process
efficiency and effectiveness. In contrast, business process management, as the name suggests, is more
concerned with the management of the large number of processes typically found in a modern
enterprise (Dumas et al., 2013). Business processes re-engineering is usually motivated by a change
in business objectives or driven by alignment to the information technology of the enterprise. The
most optimal sequence of tasks is sought, to achieve business objectives. It is this integration of
business processes and the orchestration of the various tasks that is of interest here.
It is proposed that business process management (BPM)1 can be applied for manufacturing processes,
to alleviate the problems encountered in smart manufacturing. Indeed, BPM holds distinct advantages
of interest in this research, especially for small and medium enterprises. Table 2 shows how BPM may
help to alleviate the problems identified in Section 1.2 of this chapter.
Table 2: Indication of how BPM may help to alleviate some of the problems identified in smart
manufacturing.
Problem Solution
Process management in manufacturing is fragmented, BPM is often deployed to improve
with different techniques applied to different parts of enterprise integration (van der Aalst,
the enterprise. 2013).
8
Smart technologies are under-utilized, because the BPM is often used for dynamic
rigid process design and management does not processes (Krumeich et al., 2014; von
encourage rapid reconfiguration and reassignment of Ammon, 2009).
resources.
The number of hardware and software systems BPM can orchestrate the activities of
continue to increase, based on different control different resources, because it is
regimes from different vendors. These systems are technology agnostic (Hepp et al., 2005).
difficult to integrate and utilise together in the same
process.
The solutions listed in Table 2 often rely on a business process management system (BPMS). Such a
system can be used to manage hundreds of unique process instances across multiple business units
and can assign work items to specific resources, based on the logic encoded into the process models.
Furthermore, a BPMS can utilise general-purpose technology integration approaches (e.g.
middleware) to interact with a variety of enterprise information systems. These information systems
are versatile and mature, prompting the proposal that they might benefit manufacturing.
To be clear, this research proposes the addition of BPM in manufacturing, rather than replacing
current techniques and technologies. Manufacturing processes are typically performed according to
a strict schedule and in adherence to policies and procedures. BPM techniques and technologies can
be used to define and enact the manufacturing processes, in accordance to the schedule, policies and
procedures. Thus, the BPMS supports execution of the manufacturing operations as planned in the
schedule.
9
Figure 4: Functional hierarchy of control in manufacturing enterprises (IEC, 2013).
At the top of the hierarchy, level 4 is concerned with the broader business management, including the
resource, financial and supply chain management functions. Level 3 is responsible for the planning,
directing, coordinating and monitoring of operations in the factory. Levels 1 and 2 are shown together,
representing the actuators and sensors (on level 1) and their control systems (on level 2). Finally, Level
0 is not a control level, but represents the process itself, i.e. the flow of material and product through
the factory.
Medina-Mora et al. (1992) advocates a differentiation between business process and material
processes, based on the processing of information and physical items, respectively. Level four is
concerned with strategic and administrative control of the enterprise and therefore contains only
business processes. Level three is concerned with control of the workflow on the factory floor and
therefore contains material processes, in addition to business processes. Levels zero to two represent
activities performed by single humans or machines, thus of less interest from a BPM point of view.
BPM is sufficiently proven and substantially adopted for level four of the functional hierarchy (Wohed
et al., 2006), seeing as this level contains only business processes. Therefore, the research presented
in this thesis will focus on the management of processes situated at level three of the functional
hierarchy, named manufacturing operations management. The primary focus is on the manufacturing
operations processes of small and medium enterprises.
10
“A business process is the combination of a set of activities within an enterprise with a structure
describing their logical order and dependence whose objective is to produce a desired result.”
Business processes enable the achievement of corporate objectives and often start by a trigger, which
initiates a set of predefined workflow steps. Every enterprise must manage its business processes to
deliver a product or service to its customers (Dumas et al., 2013). The set of activities regarding the
management of business processes can be captured in the term Business Process Management (BPM).
The following definition for BPM is provided by Van der Aalst et al. (2003):
“Supporting business processes using methods, techniques, and software to design, enact, control, and
analyze operational processes involving humans, organizations, applications, documents and other
sources of information."
Dumas et al. (2013) also gives an overview of the BPM lifecycle, shown in Figure 5. The lifecycle starts
with identification of all the business processes performed in an organisation. Any organisation
performs business processes, whether documented or not. Next, the processes are investigated to
understand their structure and logic. This phase typically results in a set of models describing the
current situation. Process analysis follows, to find problems and opportunities. Those problems and
opportunities are then used to drive re-engineering of the processes, typically in the form of a set of
process models describing the targeted future situation. Implementation entails changes to the
organisation to transform the current situation into the targeted situation and, finally, the new
situation is monitored to identify deficiencies and identify more opportunities for improvement.
Those deficiencies and opportunities are then used to drive a new cycle, establishing the practice of
continual improvement.
The research presented in this thesis covers the entire lifecycle shown in Figure 5, except for Process
identification. The practical cases that serve as problem inspiration and evaluation environments
(introduced in Section 1.6) already have operational processes and therefore do not require
identification. Nevertheless, the research includes process discovery, analysis, redesign,
implementation and evaluation, to varying degrees, with the purpose of demonstrating improved
manufacturing flexibility.
11
In the interest of clarity, process implementation is often supported with a BPMS. Such a system will
be used as a testbed for concepts and developments of this research. The following definition of a
BPMS is provided by Van der Aalst et al. (2003):
“A software system that is driven by explicit process designs to enact and manage operational business
processes. The system should be process-aware and generic in the sense that it is possible to modify
the processes it supports. The process designs are often graphical, and the focus is on structured
processes that need to handle many cases.”
The project consortium includes fourteen organisations across Europe, including universities, research
institutions and commercial enterprises. Three of the fourteen organisations are commercial factories
located in The Netherlands, Spain and Poland. These three factories will serve two purposes related
to this research: 1) Serve as inspiration for the problems encountered when introducing smart
manufacturing technology, and 2) Serve as appropriate environments to implement and evaluate the
research in this thesis. The scenarios that serve these two purposes are discussed in Chapter 2.
The research presented in this thesis forms a core part of the HORSE Project. The processes of the
three factories in the consortium are designed using the guidance set out in this thesis and the various
manufacturing technologies are orchestrated by the process management system presented in this
thesis.
This research compliments and builds on those previous efforts, but aims for a more comprehensive
theory on the application of BPM in smart manufacturing operations. This work is more
comprehensive because it adds the following elements that remain unaddressed until now:
12
1. Modelling of manufacturing processes is approached from an exhaustive, theoretical
perspective.
2. The resources that participate in a process will be considered, in addition to the process
itself.
3. The manufacturing processes are modelled with execution as the primary purpose, with
emphasis on the flexible allocation of resources to perform activities.
4. The theory and technology are applied to and evaluated with real cases in the
manufacturing domain.
This research proposes the use of BPM in manufacturing operations management. Manufacturing
operations management is undergoing disruption though, with the advent of smart technologies. As
such, the existing knowledge of BPM is applied to the new problems encountered in manufacturing.
Gregor and Hevner (2013) refer to this type of research as exaptation, as a subset of design science
research. Figure 6 shows the four types of design science research defined by Gregor and Hevner
(2013). Exaptation is a term borrowed from evolutionary biology, referring to the repurposing of
existing traits for new problems.
13
In conclusion, the stated objective of this research is the following:
To develop a theory for the exaptation of business process management in smart manufacturing
operations.
The information systems research framework of Hevner et al. (2004) is used to frame and position the
core concepts listed in Table 3. This framework, shown in Figure 7, advocates for due consideration
of the business needs from the environment and applicable knowledge from the scientific knowledge
base. The environment and knowledge base also serve as avenues for the output of the research.
Developments should be applied in an appropriate environment and generated knowledge should be
added to the knowledge base.
14
Figure 7: The information systems research framework of Hevner et al. (2004).
The environment, research and knowledge base lanes of the Hevner et al. (2004) design science
research framework are used to structure the ingredients, activities and core research concepts
advocated by Verschuren and Doorewaard (2010). The environment provides the business needs to
be addressed and an appropriate environment for evaluation of the research. The research lane
depicts the two major activities to be performed: development and evaluation. Lastly, the knowledge
base provides established scientific literature and methodologies. Figure 8 shows the four symbols
used in the framework. The core research concepts, as listed in Table 3, are depicted in orange and
activities are coloured green. Ingredients are shown in two colours, differentiating between
ingredients that exist and those that must be developed as part of this research.
Figure 9 shows the resulting research framework. At the top, it starts with identification of problems
encountered in the stated research context. These problems are sourced from both real-world
practice and scientific literature. The problem is framed by designating the object under consideration
and applying a novel research perspective. This framing leads to the proposition that BPM can help to
alleviate the problems encountered in smart manufacturing. This proposition is then followed by
enhancing existing BPM technology with essentials for the research object (manufacturing processes).
The enhancement requires the following three ingredients: guidance on the modelling of
manufacturing operations, guidance on the description of resources, and a mechanism to enable
dynamic allocation of resources to activities. The enhanced BPM technology is implemented and
evaluated in real-world manufacturing scenarios, finally yielding the pursued theory for the exaptation
of BPM in smart manufacturing.
15
Environment IS research Knowledge base
Context: Increased
complexity in
Problems Problems
manufacturing due
encountered in encountered in
to mass
practice at three smart
customisation and
factories. manufacturing.
the rise of smart
technologies.
Analyse problems
encountered in
smart
manufacturing
processes
Problem statement:
Current manufacturing
process management
techniques and
technologies are not well
equipped for the flexibility
needed in Industry 4.0.
Research object:
Perspective:
Smart
Consider the
manufacturing
complete process,
operations
rather than localised Business process
processes populated
improvements. modelling notation.
by versatile actors.
Modelling of
Proposition: BPM can manufacturing
be applied for operations as
manufacturing business processes.
processes, to alleviate Literature on
the problems manufacturing
encountered in smart operations.
manufacturing.
Manufacturing Mechanism to
processes of three allocate resources to Literature on
factories. manufacturing resource allocation
activities.
Evaluate in a real
manufacturing
system. Research objective:
Develop a theory for
the exaptation of
Resources at three
business process
factories
management in smart
manufacturing
operations.
Figure 9: Framework for this research, based on a combination of Verschuren and Doorewaard
(2010) and Hevner et al. (2004).
As with all scientific research, the purpose of design science research is to create useful knowledge.
The knowledge created in this case is prescriptive knowledge to help practitioners solve problems,
rather than descriptive knowledge used to explain observed phenomena. The research framework
illuminated a few ingredients that are currently unavailable, but necessary to reach the research
16
objective. These unavailable ingredients can be formulated as research questions, to guide the
creation and codification of knowledge. The following two research questions are answered in this
thesis:
1. How can manufacturing operations processes be designed and enacted using established
business process modelling notation?
2. How can resources (both humans and machines) be dynamically allocated to manufacturing
activities, to enhance process flexibility?
The two questions represent the two aspects of manufacturing processes. Processes consists of
activities that transform inputs into outputs (International Organization for Standardization, 2015),
but resources are necessary to perform the activities.
For information systems research, Hevner et al. (2004) argues that design science is inseparable from
behavioural science. Behavioural science attempts to explain phenomena related to business needs,
through the development and justification of theories. In contrast, design science aims to meet the
identified business need, through the building and evaluation of artefacts. These artefacts are
packages of prescriptive knowledge that help practitioners confront problems encountered in
practice. March and Smith (1995) define the following four types of artefacts:
• Constructs: A language or framework within which problems and solutions can be studied,
analysed and communicated.
• Models: Applied constructs that represent a real-world scenario or phenomenon. Models
are used by practitioners to aid understanding of problems, solutions or the relationship
between elements of a system.
• Methods: Guidance on actions to be executed in practice. The guidance can range from
textual descriptions of activities to be performed by humans to formal, mathematical
algorithms to be executed by computers.
• Instantiations: Implementations of constructs, models or methods. Implementations enable
more thorough assessment of artefacts.
Adhering to this naming convention, the following artefacts are developed as part of this research
thesis (artefacts one and two correspond to question one, and artefacts three and four correspond to
question two):
Gregor and Hevner (2013) use Table 4 to explain that design science research can also deliver different
levels of contributions. The four artefacts presented in this thesis are each at level two, individually.
Each level two artefact provides knowledge that helps the user to address specific problems in
17
practice. For example, artefact three guides the user through several steps to describe a resource such
that it can be determined whether that resource can perform certain manufacturing activities.
Table 4: Levels of contributes in design science research, according to (Gregor and Hevner, 2013).
The four artefacts together form a design theory on the application of BPM in smart manufacturing
operations, i.e. a level three contribution. It is argued that the four artefacts together provide enough
knowledge to define and enact manufacturing processes, as shown in Figure 10. Artefacts 1 and 2
correspond to the activities side of the equation, to help the user define the processes and the
information system that can be used to enact the processes. Artefacts 3 and 4 correspond to the
resources side, guiding the user through the definition of resources and then using those definitions
to assign resources to activities. The four artefacts are then implemented in an information system
and deployed at three factories to demonstrate the application of the theory as a whole.
Figure 10: Amalgamation of four artefacts into a design theory for the application of BPM in smart
manufacturing operations.
18
In summary, this research investigates the applicability of BPM knowledge and technology for
manufacturing, resulting in four artefacts that together form the theory for the exaptation of BPM in
smart manufacturing operations.
Context: Increased
complexity in
Problems Problems
manufacturing due
encountered in encountered in
to mass
practice at three smart
customisation and
factories. manufacturing.
the rise of smart
technologies.
Analyse problems
encountered in
smart
manufacturing
processes
Chapter 2
Problem statement:
Current manufacturing
process management
techniques and
technologies are not well
equipped for the flexibility
needed in Industry 4.0.
Research object:
Perspective:
Smart
Consider the
manufacturing
complete process,
operations
rather than localised Business process
processes populated
improvements. modelling notation.
by versatile actors.
Chapter 4
Modelling of
Proposition: BPM can manufacturing
be applied for operations as
manufacturing business processes.
processes, to alleviate Literature on
the problems manufacturing
encountered in smart operations.
manufacturing.
Chapter 3
Chapter 5 Chapter 6
Manufacturing Mechanism to
processes of three allocate resources to Literature on
factories. manufacturing resource allocation
activities.
Evaluate in a real
manufacturing
system. Research objective:
Develop a theory for
the exaptation of
Resources at three
business process
factories
management in smart
Chapter 7 manufacturing
operations.
19
The resulting structure of the thesis is reminiscent of the V-shape often used in systems engineering
(Erasmus et al., 2015). Chapter 1 explores the implications of new technologies on manufacturing
operations and proposes the BPM solution. Chapter 8 mirrors the problem and solution identification
by completing the relevance cycle with reflection on the problem and solution. Chapter 2 presents
problem analysis to define system requirements, while Chapter 7 completes the rigor cycle by
verifying the solution against those requirements. In between, Chapter 3 can be thought of as the
conceptual design of the system, followed by chapters 4, 5 and 6 as the detailed development of
individual components of the system. Figure 12 shows the chapters of the thesis portrayed on a V-
model flattened to a U-shape, to emphasise the different levels of the research.
Chapter 8: Reflection
Chapter 1: Problem and conclusion about
Validation
Relevance and solution the application of
identification BPM in smart
manufacturing.
Chapter 7:
Chapter 2: Analysis
Implementation and
of problems
Verification evaluation of the
Rigor encountered in
manufacturing
smart
process management
manufacturing.
system
Chapter Article
1 Vanderfeesten, I., Erasmus, J., Grefen, P., 2016. The HORSE Project: IoT and Cloud
Solutions for Dynamic Manufacturing Processes, in: ESOCC 2016 Workshops. Springer
International Publishing, Vienna, Austria, pp. 303–304. https://doi.org/10.1007/978-3-
319-72125-5
2 Vanderfeesten, I., Erasmus, J., Traganos, K., Bouklis, P., Garbi, A., Boultadakis, G.,
Dijkman, R., Grefen, P., 2019. Developing process execution support for high tech
manufacturing processes, in: Empirical Studies on the Development of Executable
Business Processes. Springer International Publishing.
3 and 7 Erasmus, J., Vanderfeesten, I., Traganos, K., Grefen, P., 2018b. The Case for Unified
Process Management in Smart Manufacturing, in: EDOC 2018. Presented at the 22nd
International Enterprise Distributed Object Computing Conference, IEEE, Stockholm,
Sweden, pp. 218–227. https://doi.org/10.1109/EDOC.2018.00035
20
Erasmus, J., Grefen, P., Vanderfeesten, I., Traganos, K., 2018a. Smart Hybrid
Manufacturing Control Using Cloud Computing and the Internet-of-Things. Machines
6, 62. https://doi.org/10.3390/machines6040062
4 Erasmus, J., Vanderfeesten, I.T.P., Grefen, P.W.P.J., to appear. On the suitability of
business process modelling for manufacturing operations. Computers in Industry.
5 and 6 Erasmus, J., Vanderfeesten, I., Traganos, K., Jie-A-Looi, X., Kleingeld, A., Grefen, P.,
2018c. A method to enable ability-based human resource allocation in business
process management systems, in: Proceedings of PoEM 2018, Lecture Notes in
Business Information Processing. Presented at the 11th IFIP WG 8.1 Working
Conference on the Practice of Enterprise Modelling, Springer, Vienna, Austria, pp. 37–
52. https://doi.org/10.1007/978-3-030-02302-7_3
21
Chapter 2
2. PROBLEM ANALYSIS
The topic of this research is the application of BPM for manufacturing processes to alleviate some of
the typical problems encountered in modern manufacturing. The research results in four artefacts
that provide prescriptive knowledge that help practitioners alleviate the encountered problems. As
explained in the research design (see Section 1.6), the research must be grounded in scientific theory
and based on problems encountered in practice. Therefore, this chapter explores the scientific
literature to provide background and identify problems commonly encountered in smart
manufacturing. Thereafter, three practical cases are investigated to identify problems encountered in
factories pursuing smart manufacturing. The problems from literature and practice are then
compared and combined to form a set of requirements that the artefacts must satisfy. Lastly, the
chapter is concluded with a view of the chapters that follow.
22
Figure 13: Woodward's classification of production (Woodward, 1980).
1. Small batch and unit production: systems that produce a single or a few products
collectively, such as artwork, facility construction or aeroplane fabrication.
2. Large batch and mass production: systems that produces a large number (in the order of
thousands or more) of identical products based on routines and standard procedures, such
as automobile assembly and consumer electronics production.
3. Continuous process production: systems that execute ongoing, non-discrete, capital
intensive production processes that require minimal manual involvement, such as chemical
plants and oil refineries.
Manufacturing, as an abstract term, generally refers to groups 1 and 2 of the Woodward classification
(see Figure 13). Continuous process production (group 3) tends to be used in oil refineries and
chemical production plants, thus not usually considered as part of manufacturing. This research does
not explicitly exclude continuous process production, but it is firmly focussed on the types of
production systems that produce batches or discrete products (groups 1 and 2). Indeed, the discourse
will mostly revolve around unit and small batch production (group 1 in Figure 13), as these systems
pursue the flexibility needed to produce mass customised products.
The technical complexity referred to in Figure 13 is related to the manufacturing process only,
irrespective of the complexity of the larger business or supply chain. For example, Woodward (1980)
argues that the complexity of the following attributes are higher for mass production (group 2) than
for unit production (group 1): span of control, formalized procedures, centralization and routine.
Inversely, group 1 production relies more on the expertise of workers and the use of verbal
communication.
23
Control
Communication Formality
Group 1
Group 2
Skills Centralisation
Routine
Figure 14: A indicative comparison of the manufacturing process complexity of unit production
(group 1) and mass production (group 2) according to Woodward (1980).
Woodward (1980) finds strong correlation between the technical complexity and the degree of
mechanisation, where unit technology is the least mechanised and the process production is almost
entirely automated. As a result, unit and small batch production requires more non-routine behaviour
and human intervention, while mass and process production rely heavily on automation technology
and standard operating procedures. Figure 14 shows the difference of technical complexity between
group one and two production systems according to Woodward (1980).
The limited mechanisation in unit and small batch production is rapidly changing though. Industrial
robots are becoming affordable, even for small and medium enterprises (SME’s) (Lucke et al., 2008).
Such robots unlock many opportunities for factories, such as higher production volume and decreased
physical burden on the personnel. However, robots also introduce new complexity into a factory.
Robots are controlled by software systems and require detailed commands to perform tasks, as
opposed to humans who learn organically. Software and data can be somewhat foreign to
manufacturing personnel, especially in smaller factories. Thus, some manufacturing operations
managers now face the daunting prospect of introducing robotic technology into factories devoted to
rapid change in response to fluctuating demand and mass customisation.
24
2013) provides standardised terminology and ontology for the manufacturing domain (Chen, 2005).
It advocates physical and functional hierarchical views of a manufacturing system to facilitate
understanding and communication.
The physical hierarchy, as shown in Figure 15, is a reference framework that helps to designate the
equipment utilised in manufacturing facilities. Equipment in this case refers to all non-human objects
used to process material or products during manufacturing operations, including machines, tools,
vehicles and containers. The hierarchy advocates five levels of aggregation to refer to physical objects.
It is aggregation instead of composition, because the constituent parts exist even if not part of the
system. For example, a manufacturing site persists, without existence of the enterprise. The site can
therefore be transferred between enterprises. The physical hierarchy and the concept instilled therein
are revisited in Chapter 3, as part of the information system architecture development.
The functional hierarchy is already referenced in the research scope delineation in Section 1.4 and
shown in Figure 4. This hierarchy is a reference framework to classify the various types of control
found in modern factories, ranging from the management of a complete enterprise to control of
individual devices (Chen, 2005). To reiterate, the research presented in this thesis is concerned with
the management of manufacturing operations processes, located in level 3 of the functional
hierarchy.
Both the physical and functional hierarchies refer to the classification of production discussed in 2.1.1.
Levels one and two are divided into batch, continuous and discrete control, signifying different types
of control applied for different classes of production. Unfortunately, the IEC62264:2013-1 standard
does not provide further information on different types of control. Compensatory, Leitão (2009)
considers how resources (e.g. humans, machines, robots and tools) are controlled in manufacturing
25
systems by placing the control architectures of Dilts et al. (1991) in the context of manufacturing. The
following four types of control architectures can be distinguished:
• Centralised control is characterised by single decision-node for all data processing and
decision-making. This control architecture allows extensive optimisation of resources but
suffers in terms of speed of response, tolerance to faults and expansibility.
• Hierarchical control is characterised by levels of control, by allowing distributed decision-
making across hierarchical levels. This control architecture provides better robustness,
predictability and efficiency, but performance may suffer in case of disturbances in the
system.
• Modified hierarchical control attempts the response to disturbances by adding horizontal
interfacing between resources at the same level of the hierarchy. This addition also
improves the extensibility of the control architecture, at least in terms of addition of
resources.
• Heterarchical control is characterised by local decision-nodes in autonomous resources,
without the global optimisation of the other control architectures. This control architecture
provides better response to system disturbances and easy extensibility, because only the
affected part of the system is concerned with changes.
The control applied largely depends on the class of production. Mass production systems employ
centralised control in the interest of optimisation of the entire system. Small batch and unit
production facilities typically apply hierarchical control, relying on the competence and performance
of individual resources to fulfil the expectations from the next higher level in the hierarchy. However,
the need for higher manufacturing flexibility and the opportunities afforded by modern technology
make the modified hierarchical and heterarchical control architectures more attractive.
Communication between resources allows improved collaboration and localised decision-making in
response to disturbances in the system (Leitão, 2009). However, interaction between automated
resources is dependent on the computer hardware and software that facilitates such interaction.
26
• Human resource management
• Materials and inventory management
• Production planning on a monthly, weekly or daily basis
• Supplier interactions
• Parts purchasing and payments
The content of PLM data includes the Engineering Bill of Material (eBOM), technical data, 3D models
and manufacturing specifications. From a factory floor perspective, PLM is an engineering system
which maintains product descriptions, drawings, models, technical data, etc. Some of this information
will undoubtedly be used to conceive the activities necessary to produce a product.
The MES is meant to act as a messenger between the factory floor, engineering (PLM), and planners
(ERP). Ideally, an operator should be able to request data via the MES, which in-turn fetches the
necessary data from either the ERP or PLM and presents it to the operator. Additionally, the MES
provides the ERP system with the real-time data needed to maximize enterprise processing, planning
and scheduling activities. Ugarte et al. (2009) presents a depiction of the role and functions of MES,
as shown in Figure 16.
27
Production Resource allocation
orders
Scheduling
Process - Machines / Labour
S
Resource allocation
and status 1 management - Tasks / Products H
11 2
Performance
O
Resource Document
status
analysis 10 3 control Process P
E status
R Product
9
MES 4 F
Data collection/
P tracking and
acquisition
Tracking genealogy Resource L
8 5 status
Maintenance Labour O
management management
Produced
7 6 O
Dispatching Quality
quantities
production units management
Events R
The eleven MES functions shown in Figure 16 are based on the findings of a survey (MESA, 1997) by
the Manufacturing Enterprise Systems Association (MESA). These eleven functions are thought to
adequately capture the full purpose of an MES, but it is acknowledged that an MES does not
necessarily have to provide all eleven functions. MESA provides the following descriptions of the 11
functions:
28
2.1.4 Types of manufacturing systems
Manufacturing systems can also be described in terms of targeted delivery of the product. Olhager
(2003) uses the concept of order penetration point to distinguish the four product delivery strategies
shown in Figure 17. Make-to-stock is common for mass production products, such as consumer
electronics or clothing, because these products offer little to no customisability and can therefore be
stored as finished products. However, volatile markets discourage large inventory holding. Instead,
assemble-to-order or make-to-order strategies are embraced, where production is initiated in
response to predicted demand or actual orders from customers (Sarkis and Parsaei, 1999).
Figure 17: Different order penetration points used to show different product delivery strategies.
Forecast-driven activities are depicted with dotted lines, whereas order-driven activities are
depicted with solid lines.
The positioning of the buffer is also influenced by the customisability of the product. Small batch or
singular products, such as modern luxury automobiles or industrial equipment, offer extensive
customisability. These products are therefore produced (make-to-stock) or even designed (engineer-
to-stock) on receipt of a customer order.
The different product delivery strategies also dictate the type of manufacturing system. Landers et al.
(2001) argue that the selection of manufacturing system type is based on the following three factors:
Three types of manufacturing systems can be distinguished (Koren et al., 1999). Mass produced goods
are usually produced on dedicated manufacturing lines, while highly-customised products tend to be
produced with flexible manufacturing systems. Reconfigurable manufacturing systems are a relatively
recent advancement, intended to find a middle-ground between cost-effectiveness of dedicated
manufacturing systems and the versatility of flexible manufacturing systems (Mehrabi et al., 2000).
The three major types of manufacturing systems are discussed to indicate the shortcomings of current
manufacturing practices.
29
machining stations (called "gang drilling"), while the material or product moves from one station to
the next, to achieve a high rate of production. Figure 18 shows and example of a dedicated
manufacturing line, in the automotive industry sector.
When the product demand is high, the cost per part is low. DMLs remain cost effective if demand
exceeds supply, meaning the lines can operate at full capacity. This cost effectiveness has directly led
to the rise of mass produced, cheap consumer goods. However, with increasing pressure from global
competition and over-capacity, there may be situations in which dedicated lines do not operate at full
capacity (Koren et al., 1999).
30
Figure 19: Example of an FMS, with a lathe, mill, conveyor and robotic arms (courtesy of
www.hytechworld.com/ under fair use policy).
The combination of high equipment cost, and low throughput makes the cost per part relatively high.
However, the general-purpose nature of the machines and tools also allow for unmatched
manufacturing flexibility. Therefore, higher flexibility is traded for lower production capacity and
higher initial cost (Koren et al., 1999).
31
Figure 20: Example of an RMS, showing multiple configurable work cells (courtesy of
https://intelligentsystems.eee.ntu.edu.sg/ used under fair use policy).
Reconfigurable manufacturing systems aim to find a compromise between dedicated and flexible
manufacturing systems. These systems are typically used to produce smaller batches (on the order of
hundreds or thousands) of products and should satisfy the following criteria (Landers et al., 2001):
Small quantities, high level of customisation, and delicate craftsmanship is often associated with hand
made products. While handmade often conveys a sense of quality and luxury, it poses issues in terms
of health of the factory worker and the use of modern manufacturing techniques. Smart
manufacturing makes it possible to deploy automated equipment that can perform the wide range of
32
activities necessary to produce highly customisable products. Deploying smart technologies in
manufacturing is an attempt to gain more value from investment and assets. Davis et al. (2012) argues
that smart manufacturing assists with management of dynamic demand and product variability.
It can be argued that smart manufacturing is simply part of the ongoing technological progress of
manufacturing. However, smart manufacturing is given more credence as it is seen as a cornerstone
of the fourth industrial revolution (Li et al., 2017). In Europe, the term “Industry 4.0” is widely used to
refer to the fourth industrial revolution, from a manufacturing perspective. To be clear, Industry 4.0
only refers to the manufacturing related portion of the fourth industrial revolution. Therefore,
revolutionary advancements in other industry sectors may be part of the fourth industrial revolution,
but not part of Industry 4.0. For example, smart grids, smart home and smart health are advancements
that can be compared to smart manufacturing, at least in terms of the technological drivers, but are
not included in Industry 4.0.
In the pursuit of higher flexibility, Industry 4.0 marks a shift from automated production, the third
industrial revolution, to intelligent production, the fourth industrial revolution (Thoben et al., 2017).
Essentially, the shift to intelligent manufacturing is achieved by connecting the various machines and
devices to the internet (Kamble et al., 2018). The communication enabled by internet connectivity
brings a myriad of potential benefits. Carvalho et al. (2018) point to features by which the benefits of
Industry 4.0 can be recognised, as shown in Figure 21. Through increased flexibility, interoperability
and real-time response, the manufacturing system can fulfil individual customer requirements
effectively (Thoben et al., 2017) .
33
Figure 21: Features of industry 4.0 (Carvalho et al., 2018).
Industry 4.0 is certainly complex and difficult to comprehend. Predictably, there is no unanimous
definition or even agreement on the constituent parts. Authors tend to apply a certain perspective
that is suitable to their area of interest. For example, Moeuf et al. (2018) focusses on the tactical
intelligence afforded by technologies such as the Internet-of-Things (IoT), cloud computing and big
data. In contrast, Lu (2017) is more interested in the new level of value chain integration across the
entire product lifecycle.
To give some structure to the rapidly developing and changing industry, the Reference Architecture
for Manufacturing Industry 4.0 (RAMI4.0) was established (Hankel and Rexroth, 2015). This reference
architecture brings together the business, life cycle and hierarchical views of a factory, by relating
their concepts on three orthogonal dimensions. Figure 22 shows the primary model of RAMI4.0.
Figure 22: Reference architecture for manufacturing industry 4.0 (Hankel and Rexroth, 2015)
As shown in Figure 22, the RAMI4.0 reference architecture distinguishes between three dimensions:
• The layers dimension covers the business-to-technology spectrum. It starts from the
business layer and ends in the asset layer. It is comparable to technology abstraction
models, such as 4-tier architecture models in information system design – but it takes the
hardware assets into account explicitly, as these have an important role in manufacturing.
• The hierarchy levels dimension covers the aggregation dimension, ranging from the
connected world (i.e., networks of manufacturing organizations in their eco-systems) via
stations (manufacturing work cells) to devices and products. This dimension functions as a
reference framework for the physical assets found in manufacturing enterprises and is
based on the physical hierarchy of IEC62264:2013-1 (IEC, 2013) shown in Figure 15.
Additional levels added at the top and bottom for the connected world and the product.
• The life cycle value stream dimension covers the life cycles of all the physical assets in the
hierarchy levels dimension. This dimension distinguishes between the type and instance of
34
an item, i.e. between design-time and run-time aspects. For example, a product type is first
developed (during design-time), then multiple product instances of the same type are
produced (during run-time).
RAMI4.0 covers the complete smart manufacturing landscape, from supply chain partners in a
connected world to a single product instance. However, this is certainly not the only view on the
relationship between smart manufacturing and industry 4.0. Depending on the scope that is applied,
smart manufacturing can either be encapsulated within Industry 4.0 or equal to it (Yao et al., 2017).
The National Institute of Standards and Technology (NIST), another standardisation body, also
considers smart manufacturing as a complete ecosystem across the entire product life cycle, then
smart manufacturing equitable to Industry 4.0 (Kusiak, 2018). Nevertheless, a more modest view, such
as the use of data and information technology to improve operations on the factory floor is also a
valid view of smart manufacturing (Wang et al., 2016).
This research is concerned with adaptation in the manufacturing system, regardless of the stimuli that
prompt adaptation. In other words, the mechanism of change is under consideration, rather than the
cause of a change. Therefore, the concepts and objectives of smart manufacturing inside a single
factory are embraced in this thesis and further explored in the next section.
Lee (2015) defines a smart factory as “the integration of all recent IoT technological advances in
computer networks, data integration, and analytics to bring transparency to all manufacturing
factories”. NIST defines a smart factory as a “fully integrated, collaborative manufacturing system that
respond in real time to meet changing demands and conditions in the factory, in the supply network
and in customer needs” (Lu et al., 2016). Wang et al. (2016) take a comparative approach, by
juxtaposing a smart factory to a traditional manufacturing system. The six differences between a
smart and traditional factory are enumerated in Table 6.
Table 6: Comparison of the smart and traditional factory (Wang et al., 2016).
35
resources should be reconfigured
automatically and on line.
3 Shop Floor Control Network. The Comprehensive Connections. The machines,
field buses may be used to connect products, information systems, and people
the controller with its slave stations. are connected and interact with each other
But communication among machines through the high-speed network
is not necessary. infrastructure.
4 Separated Layer. The field devices Deep Convergence. The smart factory
are separated from the upper operates in a networked environment where
information systems. the wireless network and the cloud integrate
all the physical artefacts and information
systems to form the IoT and services.
5 Independent Control. Every machine Self-Organization. The control function
is pre-programmed to perform the distributes to multiple entities. These smart
assigned functions. Any malfunction entities negotiate with each other to
of single device will break the full organize themselves to cope with system
line. dynamics.
6 Isolated Information. The machine Big Data. The smart artefacts can produce
may record its own process massive data, the high bandwidth network
information. But this information is can transfer them, and the cloud can process
seldom used by others. the big data.
Kamble et al. (2018) are more interested in the integrative nature of a smart factory. The following
three features are offered to recognise the realisation of a smart factory: 1) horizontal integration of
value networks, 2) vertical integration of manufacturing systems, and 3) end-to-end digital
integration. Horizontal integration occurs between enterprises, to achieve integration of resources,
systems and processes. Vertical integration focuses on integration of manufacturing systems within
the factory production (Carvalho et al., 2018). The end-to-end digital integration is a result of the
horizontal and vertical integration, to achieve product customization (Pereira & Romero, 2017). The
various integrations happen throughout the entire value chain and help to achieve the goals of
Industry 4.0.
Regardless of the precise features and components of a smart factory, the goal is ultimately to
increase intelligence, flexibility and cost-effectiveness (Douaioui et al., 2018; Pereira and Romero,
2017). The integration of machines products and resources should improve the self-optimization of
the production process and meet customer requirements by enabling mass customization (Douaioui
et al., 2018; Pereira & Romero, 2017).
For the purposes of this research, a smart factory is defined as a manufacturing system utilising at
least one of the following technologies:
• Actors (both human and automated) that are connected to the factory control systems,
adaptable and able to collaborate to perform manufacturing tasks.
• Manufacturing processes that can dynamically reconfigure for each instance of a product.
• Object recognition technology to assist human and automated actors to identify,
manipulate or modify highly variable products.
36
2.1.6 Key technologies in a smart factory
The new industrial age stems from the coincident development of several technologies. The main
technological drivers are cloud computing, the Internet-of-Things (IoT), and smart devices (Lu, 2017).
It is expected that mass customized products will be produced by smart robotics in dynamic processes
managed in the cloud (Zhang et al., 2014). It is even conceptually understood how these technologies
should work together to achieve smart manufacturing and deliver on the promises of Industry 4.0 (Qu
et al., 2016b; Tao and Qi, 2018). Computation that is not time-critical is relegated to the cloud. The
IoT facilitates commands and responses to and from devices and teams of humans and smart robotics
perform sophisticated operations. Figure 23 gives an overview of the main technologies and their
roles in smart manufacturing.
Connectivity
facilitated by the
Internet-of-Things
Smart devices
The three technologies shown in Figure 23 are elaborated further in this section, but they certainly do
not act alone. The following supplementary technological developments also play a role in a smart
factory (Kang et al., 2016; Mittal et al., 2017; Oztemel and Gursev, 2018):
• Wireless connectivity, primarily cellular and Wi-Fi networking, enable mobility of actors in
the manufacturing system.
• Proximity, photoelectric and various other sensor advancements that provide more
information about the manufacturing system and possibly improve safety.
• High performance computing and big data techniques to process the large amounts of data
generated by the actors and sensors on the factory floor.
• Augmented reality can superimpose a computer-generated 3D image in physical real-world
environments, to present topical and real-time information to the operator.
• Virtual Reality creates a virtual environment with the help of computer and 3D images. The
user can interact with the virtual environment as if it is part of the virtual space.
37
opportunities afforded by computing services (Foster et al., 2008; Hayes, 2008). Suddenly, varying
levels of information technology were offered as services. Instead of acquiring the hardware needed
to host enterprise information systems, computing resources can be hired to host the information
systems. The following cloud computing models are now widely available and adopted (Shawish and
Salama, 2014):
The wide availability of cloud computing services has made high performance computing more
accessible to manufacturing enterprises, especially small and medium enterprises. The availability has
inevitably led to interesting ideas and developments. For example, virtual manufacturing uses
computers to model and simulate the manufacturing to create a digital-twin (Ahuett-Garza and
Kurfess, 2018). The digital-twin can be used to quickly evaluate changes to the manufacturing system,
without committing physical resources and capital investment (Oztemel and Gursev, 2018). Another
interesting possibility offered by cloud computing is improved supply chain collaboration. Supply
chain partners can share product and production data in the cloud, increasing collaboration
effectiveness (Bruque-Cámara et al., 2016).
To emphasise the significance of the IoT for industrial applications, the term Industrial Internet of
Things (IIoT) is often used (Thoben et al., 2017). Zhong et al. (2017) identifies three main components
of the IIoT: machines, analytics and people. These components form a network that allows interaction
between machines and people, using data storage, analytics and visualization to achieve the smart
factory. The IIoT aims to bring together the industrial internet and the IoT. The industrial internet is
an initiative that is driven by the Industrial Internet is the Industrial Internet Consortium (IIC), a
consortium of large multinational organisations (Lu et al., 2016). The scope of the initiative is larger
than manufacturing, as it strives to unify the physical and digital worlds in industry and beyond.
38
finding (Semini et al., 2015), clever end-effectors (Homberg et al., 2015) or even a modular structure
(Rus et al., 2002).
Although most attention is paid to robotics, it is certainly not the only smart device. In fact, it is
generally accepted that humans will continue to have an important role in smart factories (Kang et
al., 2016). The challenge is connecting humans to the information-rich internet. For the purposes of
this research, handheld devices and other human augmentation is considered part of smart devices.
Therefore, the following smart devices can generally be expected in a smart factory:
• Robotics in various forms, ranging from multi-axial arms to collaborative robotics, also
referred to as cobots (Heyer, 2010).
• Handheld devices, such as smartphones, to provide information to the operator and allow
for tracking of manufacturing tasks performed by humans (Babulak, 2009).
• Operator augmentation devices, such as virtual reality, to provide information to the
operator in a topical and interactable manner (Khan et al., 2011).
• Autonomous guided vehicles (AGV) that can transport materials, products and tools in and
around the factory, without human intervention (Le-Anh and De Koster, 2006).
A smart device may operate independently, such as an AGV, or may be operated by a human, such as
a handheld device. The more important characteristic of these devices is network connectivity, as this
gives the manufacturing system its cyber-physical nature (i.e. a system with hardware and software
attributes). The physical devices constantly provide data and can be represented in the digital realm
leading to various opportunities, including the following:
• Improved predictions and decision-support, from data generated by the physical devices
and simulations in the digital world (Ahuett-Garza and Kurfess, 2018).
• Real-time insight into the status of the manufacturing system and the production orders
(Pereira and Romero, 2017).
• Quick response to changes based on the real-time information and the data-processing
services (Yao et al., 2017).
• Improved manufacturing flexibility, due to the modular structure of the smart factory. This
modular structure supports the “plug-and-produce” concept, which enables a fully flexible
production setting at a high speed (Oztemel and Gursev, 2018).
• Distributed decision-making is enabled by smart devices which make use of the situational
information and connectivity to coordinate their actions, supported by Internet-of-Things
technology (Yajun and Cecil, 2016).
39
2.1.7.1 Intelligent manufacturing
The concept intelligent manufacturing is often considered to be similar to smart manufacturing, as
they both apply the same broad scope (Zhong, Xu, Klotz, & Newman, 2017). However, looking at
another definition of intelligent manufacturing “the ability to self-regulate and/or self-control to
manufacture the product within the design specifications” shows that intelligent manufacturing
enhances more technological aspects (Thoben et al., 2017). According to Lu et al., (2016), the main
enabling technology of intelligent manufacturing is artificial intelligence. The goal of intelligent
manufacturing is a production system that automatically adapts to the changing market requirements
(Lu et al., 2016). This implies that intelligent manufacturing covers just a part of the smart
manufacturing characteristics. Nevertheless, Zhong et al., (2017), argue that intelligent manufacturing
facilitates the entire product life cycle using new technologies such as smart sensors and data
analytics, which again emphasizes a broader scope.
Two other related concepts to this paradigm are IoT-enabled manufacturing and cloud manufacturing
(Zhong et al., 2017). IoT-enable manufacturing is based on converting every production resource to a
smart object (Zhong et al., 2017). According to Zhong et al. (2017), the smart objects have the ability
to interact with each other and the process to automatically execute the production logistics. This
relates strongly to the smart product and smart machine aspects mentioned in the Industry 4.0 and
smart factory paradigm. IoT-enabled manufacturing is an enabler of the larger smart manufacturing
paradigm.
The same holds for cloud manufacturing. Cloud computing is applied to manufacturing, such that
resources are transformed to services and are accessible to various participants in the value chain
(Zhong et al., 2017). The intelligent resources can be connected into the cloud and can be used to
increase efficiency and respond to variable customers demand (Zhong et al., 2017). Other key enabling
technologies for cloud manufacturing are IoT, existing systems in the company that must connect to
the cloud, service-oriented technologies and virtualization (Kang et al., 2016; Lu et al., 2016). Both the
cloud technology and the IoT are important technologies for Industry 4.0, but the picture is
incomplete. Smart devices and augmented human workers are equally crucial, otherwise status
information is not available to the cloud.
Many such event-driven management systems make use of data-aware workflow engines (Krumeich
et al., 2014). This entails a workflow engine which can receive information during process run-time
and render such information useful for control-flow purposes. Interfaces to external systems are
necessary to make useful information available to the workflow engine. Progress towards integration
with other information systems eventually led to the integration of separate workflow engines.
Integration between the workflow engines of individual organisations makes it possible to streamline
a supply chain and improve adaptability to market changes (Paul Grefen et al., 2009).
40
Manufacturing has also enjoyed the attention of event-driven process management efforts (Estruch
and Heredia Álvaro, 2012). The advantages of a responsive manufacturing systems are widely
recognised and pursued. Developers of manufacturing execution systems have also taken note of the
advantages (Grauer et al., 2011). Event-driven process management in manufacturing operations rely
on technology which can provide awareness or situational data. For example, sensors on the factory
floor can provide temperature readings or detect when vehicles move to certain parts of the factory.
Such data can then be used to trigger events defined in the process models. This enables situationally
aware process management systems, but also the potential to integrate between suppliers and
customers.
Figure 24: Conventional vs. cooperative decision making (adapted from (Mařík and McFarlane,
2005))
In manufacturing, the agent-based concept has seen sustained interest. Agent-based manufacturing
has been studied and proposed repeatedly, with limited practical implementation (Leitão, 2009).
Refreshed efforts have endeavoured to distinguish themselves with new names, including holonic
manufacturing (Colombo et al., 2006) and self-organising manufacturing (Schild and Bussmann, 2007).
These efforts are entirely interesting and admirable, but have failed to garner great interest from
industry. Some technical barriers have been overcome to realise the vision of agent-based process
management, but ultimately complexity remains a problem. It is difficult to comprehend and manage
a manufacturing system populated by autonomous, heterogeneous agents who act independently
from central command. As with any autonomous system, the lack of transparency is also unacceptable
to most manufacturing operations managers.
41
2.1.8 The problems impeding smart manufacturing
Manufacturing operations managers face the daunting prospect of introducing several new
technologies into their factories to remain competitive in the face of a changing market. Some of the
technologies are already established and widely available, such as cloud computing and Wi-Fi, but
most are still only emerging. However, it is difficult to envisage how the technologies should inter-
operate and progressively habituate new technologies that emerge.
This section decomposes this challenge, from the scientific literature investigated in this chapter, into
short problem descriptions that will be used as reference point for the practical cases discussed in
Section 2.2. These problems are then combined with the problems identified in the practical cases, to
establish a set of requirements that will drive the artefact development and verification in the rest of
the thesis.
The physical nature of manufacturing further aggravates the difficulty to integrate old and new
technologies. The spatiotemporal properties of the physical world, which means the location and time
of an object matter, make the integration with computing systems more difficult (Zhou et al., 2015).
Yet, Industry 4.0 clearly aims at an integration of the digital and physical world as well as a horizontal,
vertical and end-to-end integration (Xu et al., 2018; Zhou, Liu, & Zhou, 2015). Xu et al. (2018) state
simply that the current ICT infrastructures are not ready to support the digital transformation.
This problem can be described as inertia. An existing enterprise can only change as fast as its structure
allows. More importantly, the people who must bring about such change will struggle if they do not
fully understand the new technologies and how to implement those technologies in the existing
enterprise structure.
42
2) Utilising actors (both humans and autonomous equipment) with a wider range of abilities. The first
option is prohibitively expensive for most manufacturing enterprises and both options lead to an
increase in system complexity anyway.
Increased complexity in a system typically makes the system more difficult to comprehend and thus,
to manage (Snowden, 2005). Complex systems are characterised by unpredictable emergent
behaviour and dynamic relationships between system elements, both of which are hard to deal with
from a management perspective (Kurtz and Snowden, 2003). This causal relationship is well known in
higher level systems (according to the schema of (Boulding, 1956)). Tainter (2000) recognised the
following primary constraints to the development and problem-solving of organisations:
As enterprises become more complex, human limitations will increasingly restrain growth and
improvement. The number of options, possibilities and variables are simply surpassing our ability to
make accurate and informed decisions. A factory containing many actors, with the option to
collaborate for certain tasks, in an increasing number of potential process configurations, is a good
example of too many variables. Yet decisions must be made, during planning and execution, during
normal operation and in response to unexpected events. Those decisions must also be translated into
actions, by delivering instructions and other necessary information to the involved actors.
The problem faced in smart manufacturing systems can thus be described as a management problem.
Production must be planned and controlled based on the availability of resources, actors and other
equipment. Effective planning and control are dependent on accurate and timely information
regarding the status and performance of the system. Manufacturing systems must become more
intelligent and use their resources more efficiently. However, autonomous actors in smart
manufacturing systems are not optimally utilised because of the following factors:
1. Difficulty to determine the most appropriate set of actors and equipment to produce a
specific product.
2. Complexity in planning the production in a system with highly configurable manufacturing
processes populated by adaptable actors that can collaborate for specific tasks.
3. Lack of insight into the current status of production orders and actors in the system.
4. Uncertainty regarding the continued normal operation of the production process that may
be interrupted by a large number and range of unrelated events.
5. Lack of concise, relevant, timely and accurate instructions and information available to
actors in a production line.
6. Safety risks caused by actors that may be autonomous, adaptable and mobile.
43
by rapid development of the market and technologies. These manifestations are due to, at least in
part, a lack of standardisation. Standardisation bodies have the unenviable task of reaching global
consensus in a rapidly evolving landscape. Agreed definitions for complex phenomena are slow to
emerge because it requires agreement across industry sectors and countries (Xu et al., 2018).
Communication standards and protocols must be developed and evaluated, considering the myriad
of existing and new technologies (Luthra and Mangla, 2018; Xu et al., 2014). Lastly, enterprise
architectures must be developed that can handle the pace of change (Ren et al., 2019).
This section addresses the first two purposes, by first analysing each case and then combining all
identified problems, from literature and practice, into a more general, yet concrete problem
description. Stated differently, the resulting problem description contains elements of the specific
problems mentioned in literature and identified at the practical cases. For this purpose, each case
description follows a clear outline by referring to topics discussed in the literature analysis of Section
2.1. This is similar to the approach taken by the author of this thesis in Vanderfeesten et al. (2019).
Table 7 gives an outline of the case descriptions with references to the specific sections where the
topics are introduced.
Table 7: List of topics discussed for each practical case, with references to the specific sections
where those topics are introduced.
44
6 A description of the scenarios in which the research output will be None
evaluated. These scenarios are presented as detailed process models
with annotations highlighting the problems that are addressed.
Figure 25: A TRI telescopic slide on the left and a typical application of the product on the right
(reused with permission from TRI).
The product is aimed at industry-grade applications, in a wide range of industry sectors, including
automotive, aerospace and heavy machinery. As such, product quality is of utmost importance, to
maintain a solid base of return customers and steady growth. More importantly, the competitive
advantage of TRI is the ability to deliver a small batch of highly customised slides within two weeks of
order receipt.
45
1. Cold forming of steel coils into profiles.
2. Surface treatment of the steel profiles, to reduce susceptibility to corrosion.
3. Final assembly of slides by combining several profiles and ball-bearings.
Production phase 1 shapes coils of steel sheets into the three or four profiles that are assembled into
the telescopic. Photos of production phase 1 are shown in Figure 27. This phase includes the following
activities:
46
Figure 27: Steps of production phase 1:
a) Load steel coil in the machine, b) Cut steel coil into profile lengths,
c) Stamp holes and bend lips, d) Finished Profile.
The production activities in phase 1 may be executed on different equipment, depending on the
dimensions of the steel profiles. Approximately 60% of profiles are processed on the automated
production line, named Profistans, consisting of a computer operated crane to switch between coils
and a series of hydraulic presses. The remaining 40% of profiles are either too small or large for the
automated line, thus necessitating manual execution at three human-operated production lines,
specialised for different product dimensions. In a small minority of cases, due to special customisation
requirements, some manual operations are still necessary after processing on the automated
production line.
Production phase 2 improves the corrosion resistance of the profiles with Electro-galvanic zinc plating.
Photos of production phase 2 are shown in Figure 28. This phase includes the following three activities:
This phase is largely manual, as both the loading and unloading activities are completely manual, while
the zinc plating is automated by an overhead crane. Consequently, human workers are strained with
a high physical load during loading and unloading of the racks. Automation of these activities is
particularly difficult, because the profiles must be hooked on through small holes.
47
Figure 28: Pictures of production phase 2. Profiles on rack (left), and vats for surface treatment of
profiles (right).
Production phase 3 assembles the prepared steel profiles and ball-bearings into the finished
telescopic slides. Photos of production phase 3 are shown in Figure 29. This phase includes the
following three activities:
The activities involved in production phase 3 can be executed on three production lines. About 60%
of products are assembled on the fully-automated assembly line populated by eight robots, although
the constituent parts are loaded into and unloaded from this line by human workers. About 35% of
the products are assembled on the recently installed semi-automatic line, populated by a mixture of
humans and robots. The remaining 5% of products are assembled completely manually via a series of
specialised work cells.
48
2.2.1.2 Focus area description
The three production phases are most accurately interpreted as production areas, in terms of the
equipment hierarchy presented in IEC 62242-1:2013 (see Figure 15). These production areas are
decomposed into production lines, which in turn can be decomposed into work cells (following the
terminology of discrete and small batch production). Additionally, a Tool Preparation production area
accompanies the production phase 1, to assemble tools for the cutting, stamping and bending
operations. Lastly, two storage zones are also located in the factory. Figure 30 the physical hierarchy
of TRI, with two work cells highlighted to indicate the area of focus for this research.
Enterprise TRI
Site Maastricht
Tool Surface
Production area preparation
Cold forming Buffer
treatment
Assembly Warehouse
Semi-
Two parallel Three manual Four parallel Automated Manual
Production line lines
Profistans
lines lines assembly
automated
assembly
assembly
Figure 30: Physical hierarchy of TRI, with three work cells highlighted to indicate the location of
the application scenarios.
The first highlighted work cell, single tool assembly, is occupied by highly skilled personnel who build
configurable tools according to product requirements. Each production batch utilises six such tools
for the cutting, stamping and bending operations executed in production phase 1. The scenario in this
work cell is discussed in more detail in section 2.2.1.6.1. The second highlighted work cell is dedicated
to stacking profiles in bins for transport and storage. The third highlighted work cell is where profiles
are loaded onto and unloaded from racks, before and after galvanisation. This scenario is discussed in
section 2.2.1.6.3.
49
Figure 31: TRI manufacturing process, showing tool preparation and three phases of production.
The straight-forward mapping between production areas and process pools indicates that the physical
constraints of manufacturing remain the dominant considerations in the factory. Production progress
is a function of the location of the product in the factory, rather than the operations performed.
A major contributor to the production throughput time is the chaotic way the product is transported
from one production phase to the next. Profiles are simply dumped in a crate and placed in storage.
At the next production area, the product is manually picked out of the crate and placed orderly for
the next step in the process. Additionally, the picking of product instantiations and loading at P2 puts
a heavy burden on the operator. Every instantiation is individually picked up and hanged on hooks to
prepare for surface treatments in the chemicals behind a safety divider. This loading for P2 is a slow
and arduous task, placing significant physical burden on the operator. The total mass moved by an
operator in a typical shift exceeds the regulatory limit, but TRI is given a concession because a
reasonable (financially and technically) solution is not available.
50
is not possible, because the local control systems are not connected to any centralised system. More
importantly, real-time progress and performance data gathered by these information systems are not
available to production planning.
The only cross-functional system in TRI is the ERP system, Microsoft Dynamics. This system is used to
receive and process customer orders, generate production orders and manage company resources.
Once a production order is created, the production schedule is updated in a proprietary information
system. From this system, work instructions are generated, printed and delivered to each work cell.
The work instructions include product drawings, developed in the computer-aided design (CAD)
package, and manually loaded into the ERP system.
Figure 32 shows a depiction of the TRI hardware and software systems, according to the functional
hierarchy of IEC62264:2013-1. All three items on level three are highlighted to indicate the problem
areas. The production planning system works well for TRI, but it is not connected to lower level
systems. The other two items are more concerning, as these functions are not supported by any
information system. Work instructions are printed from the ERP system and delivered to work cells,
while information from the factory floor is gathered by supervising personnel and verbally
communicated back to operations management.
Bespoke Manual
Level 3 production
planning system
Printed work
instructions
information
gathering
Figure 32: Hardware and software systems of TRI, according to the levels of the functional
hierarchy of IEC62264:2013-1.
The TRI factory makes extensive use of ad-hoc communication between employees, due limited
software support and poor integration. This situation is typical for a factory reliant on personnel
competence, rather than automation and strict control. This is certainly an impediment on the road
towards smart manufacturing, because dynamic configuration and assignment of resources is not
feasible without accurate insight into the situation on the factory floor.
51
2. High manufacturing flexibility to produce small batches, according to customer
expectations.
3. Quick response to ensure short delivery times.
The extensive customisation offered by TRI is problematic, with regards to the pursuit of smart
manufacturing. Extensive customisation is achieved thanks to two primary mechanisms: skilled
employees and configurable manufacturing tools. Although many manufacturing tasks can be
automated, it is particularly difficult and expensive to replace highly skilled employees. It is even more
difficult to find automation solutions with enough versatility to produce the substantial number of
product variances. The reliance on human workers causes several problems in the factory, including
the following:
• A general lack of timely information regarding the execution of activities and the utilisation
of resources.
• Heavy physical burden on employees who perform manufacturing operations.
• Difficult to retain or replace highly skilled employees.
The high number of product variances and small batches also demands frequent change-over of
machines and tools. As a result, the manufacturing system is relatively under-utilised, as a ratio of
production to change-over time. This problem is an artefact of machines with poor versatility. The
current machines are highly specialised to perform specific tasks, rather than quickly adapt to produce
different products.
Lastly, shortening of delivery time is hindered by the disconnected nature of the production areas.
Products can spend days, or even weeks in extreme cases, in the buffer, waiting for the appropriate
machines and tools to be available. More versatile machines and improved workflow management
are sorely needed to improve the delivery times.
TRI has appreciation for the importance of becoming a smart factory. To remain competitive, the
company must innovate and improve value to its customers. The general goal of TRI is to achieve flow
production between the three production phases. Instead of three disconnected production phases,
with products waiting in-between, TRI wants a situation where a customer configures a product on
the online portal, then the factory should adjust accordingly to deliver the product as fast as possible.
However, TRI also recognises the challenges inherent to automation of some of its more skill-
dependent manufacturing operations.
1. Single tool assembly, prior to production phase 1, transitioning from completely manual
assembly to augmented reality and robot supported assembly.
2. Stacking of profiles in bins at the end of production phase 1, transitioning from completely
manual to completely automated.
52
3. Loading and unloading at production phase 2, transitioning from completely manual to
partially automated.
The three scenarios are represented by four process models, because the third scenario entails
loading and unloading of profiles. The four processes are shown in the context of the overall
manufacturing process, with bold borders in Figure 31.
The process will undergo significant changes, due to the introduction of modern technologies. The
following three changes will be made:
1. The task ‘assemble tooling block’ will be supported by augmented reality, guiding the
operator through the steps of assembling a tool.
2. The task ‘fetch tooling parts from storage’ will be performed by a mobile robot, allowing the
human worker to focus on the assembly task.
3. Introduction of process management technology to orchestrate the activities of the human
and robot.
53
The process will undergo significant changes due to the complete automation. The following two
changes will be made:
1. The task ‘pick profiles from machine and place in bin’ will be performed by two robots. The
first will pick up the profiles and place them on a conveyor belt, then the second will pick up
the profiles form the conveyor belt and place them, in an orderly fashion, in the bin.
2. The remaining two tasks (transport bin to storage zone and place bin in storage) will be
performed by an autonomous guided vehicle that is specifically designed to transport bins.
Figure 35 shows the process model for the loading of profiles. Apart from the last task (crane moves
filled rack to baths), the process is completely manual and performed by a single worker. Figure 36
shows the process model for unloading. As with loading, this process is completely manual and
performed by a single worker, except for the last task performed by the overhead crane.
The two processes will undergo similar changes. Two robots and a conveyor will be introduced to
support the existing human worker. One robot will pick profiles from the bin and place it on the
conveyor, then the second robot will pick it from the conveyor and hook it onto the rack. This leaves
the human worker to focus on quality assurance activities and perhaps even attend more than one
work cell.
54
2.2.2 Sand-casting foundry in Poland
The second case is a sand-casting foundry in Poland. The company name is omitted for confidentiality
reasons and will henceforth be referred to as SCF, for sand-casting foundry. SCF annually produces
approximately 16 thousand tons of iron castings with weight ranges of 2 to 100 kg in different
configurations and for various industries. The company has approximately 990 active product
numbers at any time, some of which are shown in Figure 37.
Figure 37: Selected SCF castings for various applications and industries (used with permission from
SCF).
55
Enterprise SCF
Site Site 1
Finished
Materials Pre-
Production area storage production
Casting Finishing products
storage
LORA HWS
Core Pattern Sand Surface
Production line preparation preparation
Melting shop
preparation
(vertical
casting)
(horizontal
casting)
Shot blasting Separation Fettling
treatment
Figure 38: Physical hierarchy of SCF, with one work cell highlighted to indicate the location of the
scenario.
As shown in Figure 38, the separation production line contains four identical work cells, with one
highlighted to the indicate the area of concern. Separation is a glaring exception in foundry, in that it
is almost entirely manual. The operators make use of equipment such as grinders and pneumatic
wedges, but the cast is lifted and moved manually, and hammers are used extensively. SCF is
interested in the use of modern technologies to partially or fully automate this manufacturing
operation. SCF has considered several possible automation solutions, but the following constraints
cause difficulty:
• The single load to be lifted by an operator (or multiple operators) can be up to 150kg. The
total mass moved in a shift is not as much a problem as this single load is.
• The shapes and sizes vary considerably between product numbers, making it difficult to find
equipment to help the operator.
• The separation step follows the shot blasting, where the sand is removed from the casting.
This results in a dusty environment for which most robotic technology is not designed.
56
Figure 39: Cross-functional manufacturing process of SCF, showing sales and marketing,
engineering and operations.
57
2.2.2.4 Hardware and software systems of SCF
Almost all information related to a customer and production orders is captured in an information
system called GUSSinfo. This is an ERP system made specifically for foundries. It is currently used to
capture the following information:
• Customer information
• Customer order
• Production order
• Production plan (monthly, weekly and daily)
• Production order status (at which step in the process an order is)
• Invoice
Considering the type of information captured and managed, GUSSinfo is primarily at level 4 of the
functional hierarchy of IEC62242-1:2013 (see Figure 4). It is mostly concerned with resource
management and plant production scheduling on a monthly, weekly and daily time frame. Currently,
the detailed production planning on an hourly and minutely time frame is left to the operators of the
various work cells. This is not necessarily a problem, as this approach gains benefit from the
considerable experience of the operators. However, as with most enterprises, global competition and
new technologies will increase the complexity in the SCF manufacturing operations.
The absence of an information system to assist with level three control makes integration between
enterprise control (level four) and manufacturing control (levels one and two) unpredictable and
unreliable. Research suggests that it may further result in sub-optimal production planning and
exception handling, because relationships between events are not known and therefore not detected
(Grauer et al., 2011).
On level 2 of the functional hierarchy, several SCADA and PLC systems are present, as can be expected
in a mostly automated foundry. However, these control systems are localised to their respective
production lines and therefore function in isolation. Figure 40 shows the hardware and software
systems of SCF, with one level three system highlighted to show the lack of integration between levels
two and three.
GUSS Info
Level 4 (ERP system)
Observation and
Surface
Level 2 Core making PLC Furnace control LORA SCADA HWS SCADA Grinding PLC
treatment PLC
verbal
communication
Automated Surface
Core making
Level 1 system
Furnace LORA machines HWS machines grinding
machines
treatment
machine
58
Figure 40: Hardware and software systems of SCF, with problem areas highlighted.
The lack of level three information systems is an impediment to the deployment of modern
manufacturing technologies. Almost all new equipment embraces the cyber-physical paradigm and
must therefore be part of a larger information systems ecosystem.
The current process of separation is performed on floor space of approximately 20 square metres
and involves the following three activities, as shown in Figure 41:
1. The operator takes out the full “grape” from the pallet using a manual labour or
manipulator.
2. The operator uses a heavy grinder or 15 kg hammer to separate castings off the gating
system.
3. The operator puts all excess material back on the pallet to be transporter to scrap
processing.
Figure 41: Manual operations of separating castings off gating systems (used with permission from
SCF)
Products arrive at the separation work cells ostensibly ad-hoc, as prior production activities are
completed. The operators also have no insight into upcoming arrivals. The products constantly
59
change, because SCF mostly produces batches smaller than 100 castings. Operators simply have to
respond to arrivals, read the instructions and perform the tasks. Naturally, such unpredictable work
is not conducive self-optimisation of duties. More worryingly, a worker assigned to separation
operations can move up to six tons of material in one shift.
Clearly, the separation process is ripe for automation, but two faces two major obstacles: 1) the
frequency and extent of product variability demands automation technology that is both versatile and
can adapt quickly, and 2) any automation technology depends on clear commands, especially if it is
necessary to frequently adapt its mode of operation.
1. The operator unloads a grape from the pallet and places it in the designated clamps, within
the working area of the robot.
2. If it is new product variant, the operator enables teaching mode and teaches the cutting
plan to the robot.
3. The operator performs a safety check and, if acceptable, enables execution mode.
4. The robot uses a grinding disk to separate individual castings.
5. The separated castings fall onto a conveyor that transports them to the pallet where the
operator loads them for transportation.
The proposed solution is clearly dependent on data. If a known product variant arrives, the existing
cutting plan must be sent to the robot. If a new cutting plan is taught, the plan must be stored for
reuse. The process management system will facilitate this data flow and orchestrate the activities of
the human and robot. Figure 42 shows the model to enact the process of grape separation. This
process will be used to demonstrate the complete vertical integration, from level 4 down to level 1 of
the functional hierarchy.
60
Figure 42: Grape separation scenario at SCF, with teaching-by-demonstration technology.
61
2.2.3 Automobile parts assembly in Spain
The third and final practical case is an automobile parts assembly plant in Spain. As with the second
case, the company name is omitted to maintain confidentiality. The company will be referred to as
APA, for Automobile Parts Assembly company. The factory produces front and rear wiper assembly
systems for automobiles, with an example shown in Figure 43. Whilst TRI shapes steel and CSF
produces castings, APA assembles its product from 10 main components (and some sub-components),
procured from suppliers.
According to the classification of production of Woodward (1980), as discussed in section 2.1.1, APA
can be classified as a small batch producer, or type 4 in group 1. As for manufacturing system type,
the assembly plant most closely resembles a dedicated manufacturing system (see Section 2.1.4). The
high product variability is mostly thanks to the expertise of workers, rather than significant use of
reconfigurable tools.
• Packaging storage area where customer packaging is held until requested by a production
line.
• Final assembly storage area where finished products are held until sent for delivery.
• Two intermediate storage areas between pre-assembly and final assembly. Parts produced
by pre-assembly are stored here until final assembly production lines pick up the
necessary subassemblies for further processing.
62
• Components storage area where the various components of the front and rear assembly
systems are held.
This research will focus on the final assembly of front wiper systems. Figure 44 shows the physical
hierarchy for APA, based on the reference hierarchy of IEC62242:2013, with the area of focus
highlighted in blue. This hierarchy is not exhaustive, as it focusses on the final assembly of front wiper
system assemblies.
Enterprise Holding
company
PL2.1: Semi- PL2.2: Semi- PL2.3: Semi- PL2.4: Semi- PL2.5: Semi-
Production line automated line
1
automated line
2
automated line
3
automated line
4
automated line
5
PL2.6: Manual
line 1
PL2.7: Manual
line 2
PL2.8: Manual
line 3
WC2.1.13:
Work cell 12 preceding
work cells
Inspection and
packaging
Figure 44: Physical hierarchy of APA, showing the area of focus highlighted in blue
Each production line must be capable of processing significant product variability, leading to a mixture
of automated and manual work cells. A single final assembly line contains 13 work cells, of which
seven are fully automated, one is semi-automated and five are manual. The production line works in
a linear sequence by progressively attaching parts to the work piece and ends with quality assurance
and packaging. This last work cell, dedicated to quality assurance and packaging, is the area of focus
for this practical case.
Figure 45 shows the high-level, end-to-end view of the front wiper system assembly process. The
logistics, pre-assembly and final assembly functions are shown to operate independently, with
information flow (mostly in the form of Kanban cards) between them. The assembly process for read
wiper systems is not shown in the interest of model simplicity.
Due to the steady sales of APA, most products are kept in stock to be delivered upon order. Once an
order is received, the stock must be replenished by producing the product. The Kanban cards that
accompany the product is added back into the production planning of final assembly, indicating the
stock to be replenished. Final assembly will pick up parts from the supermarket, as necessary, to
assemble the final product. The pre-assembly production lines will in turn respond to the removal of
parts from the supermarket and plan replenishment of the appropriate parts.
63
Figure 45: Overall manufacturing process of front wiper systems at APA.
The practical case of APA is in one of the five semi-automated production lines of the front wiper
system assembly process. The position of the practical case is indicated with a bold border in Figure
45.
2
https://www.boschrexroth.com/en/xc/products/engineering/opencoreengineering/index
64
control automated equipment. This software package includes all the level 2 and 3 control
functionality for the various machines in the factory.
Level 4 SCM
SAP suite
(ERP)
PLM
Open Core
Level 3 Engineering
MES
Canban cards WHMS
Open Core
Level 2 Engineering
PLC
Human
workers
Figure 46: Depiction of the hardware and software systems of APA, showing a lack of integration
between level 3 systems.
Although APA makes extensive use of Open Core Engineering, especially the machine control and data
collection functionality, the factory is not centrally operated from this single system. The
unpredictability of demand currently makes it infeasible to establish complete flow production.
Instead, the pre-assembly and final assembly production areas operate disjointedly. The two pre-
assembly areas essentially function as the suppliers to the two final assembly areas. Coordination
between the two halves of the factory is managed using six sigma principles. Canban cards function
as requests and responses between the production areas.
1. Unloading: The operator picks up the WSA with both hands from the conveyor belt.
2. Quality assurance: The operator holds the WSA with both hands and visually inspects
three to six key features, depending on the WSA design. In most cases, the WSA must be
rotated to see the key features. The operator checks at least the label, ball sockets and
screening covers (dust caps), as shown in Figure 47.
3. Packaging: If the WSA is conformant, the operator places it in the nearby container. The
operator must strictly follow instructions regarding the placement of assemblies, as
specified by the customer.
4. Replenish container: Paperboard is placed between layers of assemblies. The operator
must place a paperboard once a layer is full and replace the container once it is full.
65
Figure 47: Visual Inspection of label presence, no damages of 4 link ball sockets and screening
covers (dust caps) not clamped up to 4 pieces
Apart from the excessive mass and speed of work, the operator also reaches in the container and
spends a full shift standing. Figure 48 shows the standing and reaching positions of an operator
performing the quality assurance and packaging process.
Figure 48: Two activities of the APA case, showing a) assembly handing and b) placing an assembly
in the container.
66
To alleviate the strain on the operator, APA is investigating automation options for the work cell. The
automation will consist of a robot to handle the assemblies and a camera system for the quality
assurance. This automation solution must overcome the following challenges:
• The robot must be able to handle assemblies with highly variable sizes and shapes.
• Information regarding the gripping position must be propagated to the robot.
• Information regarding the inspection for each unique assembly must be propagated to both
the robot and the camera system. The robot must manoeuvre the assembly such that the
camera can ‘see’ the inspection points.
• The robot must receive an inspection result from the camera system to determine the next
activity to be performed.
• Information regarding the packaging must be propagated to the robot.
The most significant requirement of the APA case is the need for collaboration between the robot
arm and camera system for the visual inspection activity. The two automated actors must be
assigned to the activity, sent the necessary information and their actions must be synchronized. This
is especially difficult considering the large amount of product variants.
The other important requirement is the responsiveness needed in the process. If a WSA is flagged as
nonconformant, the process flow must be directed towards the responsible operator. However, if
this operator does not respond within one minute, the case must be escalated to the responsible
manager. If the manager also does not respond in a timely fashion, then the WSA is rejected to allow
the process to proceed. This rejection opens new possibilities. If another WSA is rejected while the
previous one is still awaiting a response, the process must be immediately halted to prevent
deficient product quality. These various possibilities must be coordinated by the information system
responsible for process management.
67
Figure 49: Process model of the scenario at APA.
68
2.3 Findings: Problems in smart manufacturing
This section serves as a summary of the chapter, with the goal of extracting requirements from the
literature and practical cases, presented in sections 2.1 and 2.2, respectively. The requirements drive
the design of the manufacturing process management system, presented in Chapter 3, and its more
detailed components presented in Chapters 4, 5 and 6. Lastly, the requirements are referenced during
evaluation in Chapter 7, to demonstrate that the proposed solutions satisfy the requirements.
Fundamentally, the problem faced in factories pursuing smart manufacturing is a lack of preparation.
Change is slow and costly in factories, especially when the promise is vague and difficult to understand
(section 2.1.8.1). The confusion surrounding smart manufacturing and the lack of standardisation
make it difficult for management to plan for the impending arrival of new technologies and techniques
(section 2.1.8.4). In addition, the current information technology systems and infrastructure are found
to be ill suited for dynamic situations (section 2.1.8.2). Even if new technologies are embraced and
acquired, current operations management practices are not well equipped for the increased
complexity (section 2.1.8.3). Indeed, Luthra and Mangla (2018) show that current information systems
are not well suited for the type of dynamic situations that are expected in Industry 4.0. Witsch and
Vogel-Heuser (2012) also cast doubt on the preparedness of process management techniques and
systems to deal with dynamism.
The objective of this research is to develop a theory for the exaptation of BPM for smart
manufacturing. The objective is pursued by showing that BPM knowledge and technology are
applicable to manufacturing operations. A manufacturing process management system is designed,
based on the foundation of existing technology, and deployed at the three practical cases discussed
in section 2.2. Table 9 shows the requirements of the MPMS, with literature and practical cases listed
as sources of the requirement. The requirements are stated according to the “Easy Approach” syntax
(Mavin et al., 2009; Mavin and Wilkinson, 2010).
The verification type listed in the fifth column of Table 9 indicates how evidence will be obtained that
the requirement is satisfied. INCOSE (2015) advocates the following seven types of verification:
inspection, analysis, demonstration, test, analogy, simulation and sampling. The work presented in
this thesis relies heavily on demonstration to gather evidence for requirement satisfaction.
Demonstration “shows correct operation of the system against operational and observable
characteristics without using physical measurements.” It is notoriously difficult to show measurable
improvements in manufacturing processes, due to the myriad of other influences on the process.
Therefore, the majority if verification actions will be performed as demonstrations.
69
R03 The MPMS integrates the main Section None System None
technologies that drive smart 2.1.6 realisation
manufacturing.
R04 The MPMS can be used to define Section TRI Demonstrate All
dynamic manufacturing processes. 2.1.8.2 APA
R05 The MPMS can enact dynamic Section TRI Demonstrate All
manufacturing processes. 2.1.8.2 APA
R06 The MPMS can be used to define Section None Demonstrate TRI
manufacturing resources, such that 2.1.8.3
it can be determined which
resource is needed for an activity.
R07 The MPMS can select resources for Section None Test TRI
activities, based on the task 2.1.8.3
requirements and resource
attributes.
R08 The MPMS can coordinate the Section TRI Demonstrate All
activities of heterogeneous actors 2.1.8.3 CSF
(humans and different robots). APA
R09 The MPMS can assign multiple Section SCF Demonstrate SCF
actors to a single activity. 2.1.8.3 APA APA
R10 The MPMS can respond to changes Section APA Demonstrate APA
in the manufacturing processes. 2.1.8.3
A few exceptions in Table 9 are highlighted. R03 was not elicited from any practical case, because the
personnel at the factories are interested in obtaining results, not in the particular technologies
involved. R06 and R07 were also not explicitly mentioned by the people responsible for the practical
cases. Nevertheless, the TRI case relies on selection of resources and will therefore be demonstrated.
Lastly, R09 was not identified in the scientific literature, even though collaborative robotics is
extensively discussed. Allocation of multiple actors to a task is required for both the SCF and APA cases
though and will be demonstrated there.
This research sets out to show that existing BPM techniques and technology can help to achieve smart
manufacturing. The BPM techniques are used to define dynamic processes and the resources that
populate those processes. BPM technology is adapted for the physical nature of manufacturing and a
manufacturing process management system is developed and deployed. This chapter defined the
requirements that the MPMS must satisfy, by extracting problems from literature and practice. The
requirements are used to drive the development presented in chapters 3, 4, 5 and 6, and referenced
in the evaluation in chapter 7.
70
Chapter 3
3. DESIGN OF A MANUFACTURING PROCESS
MANAGEMENT SYSTEM
The technologies that underpin Industry 4.0 are increasingly appealing and accessible to
manufacturing enterprises. Cloud computing and internet connectivity are prevalent in industrialized
countries and robots are becoming increasingly intelligent and affordable (Kang et al., 2016; Lucke et
al., 2008). Future scenarios are proposed where humans and robots harmoniously collaborate to
perform irregular and complicated tasks (Marvel et al., 2015). Even small and medium enterprises
(SMEs) now consider user-friendly automation solutions. For example, a robot that can be
programmed by a demonstration may still need initial installation by an robotics expert, but thereafter
it can be configured for new activities by factory personnel (Dillmann and Friedrich, 1996).
Although more accessible, affordable and available, these technologies are applied independently and
remain largely detached. The separate technologies can be acquired and even implemented, but it is
unclear how to unlock the promised benefit of an integrated solution. Monostori (2014) argues that
it is unclear how these new technologies fit into existing automation approaches. Thus, the adoption
of new manufacturing technology is hindered by utilization and integration, instead of acquisition. In
fact, the absence of out-of-the-box solutions that combine the different technologies is considered a
primary impediment on the path towards smart manufacturing (Kang et al., 2016).
The symptoms of the problem manifest most fervently on a factory floor with a mixture of humans
and robots. The activities of humans and robots are controlled differently. Humans receive written,
oral, or visual instructions while machines are compelled to action via their control systems. These
control regimes function independently (Tsarouchi et al., 2016), making it difficult to transfer tasks
between humans and robots even if their capabilities would allow this (Bauer et al., 2008; Gerkey and
Matarić, 2004a). Furthermore, robot control is often poorly integrated with cross-functional processes
management (Erasmus et al., 2018). Robot control follows a vertical orientation focused on the
operations within a work cell. Process management follows a horizontal orientation focused on the
operations across work cells and in the context of enterprise information processing. Thus, current
robot control does not support simple reassignment of robots to different work cells. The most
apparent symptom is the increased safety hazards introduced by automation. Robots must be
equipped with extensive safety precautions to allow close collaboration with humans (the accident in
a car factory (“Worker at Volkswagen Plant Killed in Robot Accident,” 2015) is well known in the
domain). To compensate, human working spaces are usually physically separated from areas
containing automation. These symptoms and concerns hamper mainstream adoption of human-robot
collaboration technology (Bauer et al., 2008; Heyer, 2010).
To address, or at least alleviate the problem, it is proposed that business process management
knowledge and technology can be applied in manufacturing processes. More specifically, a business
process management system (BPMS) can be used to orchestrate the activities performed by humans,
robots and other machines on the factory floor. Although the BPMS is based on existing technology,
71
it must be adapted to the specific requirements of manufacturing processes. This chapter presents
the conceptual design of the manufacturing process management system (MPMS) that satisfies the
requirements defined in Section 2.3, with emphasis on the underlying technology and its suitability
for smart manufacturing. Chapters 4, 5 and 6 present the detailed design of the extensions required
for manufacturing processes and Chapter 7 covers the realisation and evaluation of the MPMS.
•Chapter conclusion.
•System modules that must be developed for smart manufacturing
Section 3.4 process management.
Section 3.4 in Figure 50 mentions system modules that must be developed for smart manufacturing
process management. This line eludes to the overall role of this chapter in the thesis. The architecture
presented in this chapter corresponds to the conceptual design of an information system. The
conceptual design identifies system modules that must be further developed, i.e. undergo detailed
design in Chapters 4, 5 and 6. Eventually, the complete system and its detail designed modules is
realised, implemented and evaluated in Chapter 7.
72
3.2 The case for unified process management in smart
manufacturing
This section aims to satisfy the requirement that the exaptation of BPM knowledge and technology in
smart manufacturing operations should be interesting. Interesting is interpreted as giving ‘compelling
justification for undertaking the research.’ In other words, it should be shown that the application of
BPM for smart manufacturing operations holds promise beyond current practice. As mentioned in
Chapter 1, BPM has three major benefits over current manufacturing process management practices:
1) BPM is often deployed to improve enterprise integration (van der Aalst, 2013), 2) BPM is often used
for dynamic processes (Krumeich et al., 2014; von Ammon, 2009), and 3) BPM can orchestrate the
activities of different resources, because it is technology agnostic (Hepp et al., 2005).
For this chapter, the integrative potential of BPM is embraced as the primary justification for the
research. Its integrative potential has not gone unnoticed by scholars in the manufacturing domain.
Prades et al. (2013) make the case for integration between enterprise resource planning (on level four
of the IEC62264:2013-1 functional hierarchy) and manufacturing operations management (on level
three), by using Business Process Model & Notation (BPMN) for process modelling in both levels.
Gerber et al. (2014) also pursue integration, but rather opt for translation from level 4 BPMN models
to level 3 sequential function charts.
Those two studies ponder BPM purely from a process modelling perspective, contemplating the use
of business process models on levels three and four of the functional hierarchy. Rather than repeating
work, the process modelling argument is complemented with an architectural argument in this section
and Section 3.3 follows up with process execution support. It is proposed that a single process
management system should orchestrate activities across levels three and four of the functional
hierarchy and interface directly to level two systems. Instead of multiple information systems with
process management functionality, the functionality is unified in a centralized process management
system. Accordingly, the impact of centralized process management on the enterprise architecture of
computer integrated manufacturing is explored here.
The proposal conforms to the ongoing modularization of information systems (van der Aalst, 1998),
as illustrated in Figure 51. Instead of each application system containing database and process
management functionality, that functionality is unified in standalone systems that serve all application
systems. As transpired with enterprise application systems, process management functionality can be
moved out of manufacturing operations management applications and housed in a standalone
process management system. Thus, the process management responsibility is relinquished to a
unified process management system.
73
User User
Application system
interface interface
Application system
BPM system
Application
Application
system
system
Database Database Database
system system system
The proposition is predicated on the advancement of cyber-physical systems and the internet-of-
things. Previously, manufacturing equipment was either static (e.g. dedicated manufacturing lines) or
required frequent human intervention and control (e.g. flexible manufacturing systems) (Koren et al.,
1999; Koren and Shpitalni, 2010). A new age of versatile robots can quickly adjust their mode of
operation and even adapt to changing conditions (Heyer, 2010; Rus et al., 2002). Those robots are
connected to the network to receive instructions from the process management system and perform
the required work independently.
The case for unified process management is made in three steps, corresponding to the following three
sections:
• Section 3.2.1: Investigate the information systems used to support business functions in
manufacturing enterprises.
• Section 3.2.2: Argue for unified process management by recognizing the prevalence of
process management within the manufacturing information systems.
• Section 3.2.3: Present an updated enterprise architecture of computer integrated
manufacturing to show the impact of unified process management.
74
and sensors (on level 1) and their control systems (on level 2). Finally, Level 0 is not a control level,
but represents the process itself, i.e. the flow of material and product through the factory.
The functional hierarchy is also often used to arrange the information systems used in a
manufacturing enterprise. This is not necessarily a robust classification of computer integrated
manufacturing, but rather an expedient way to position hardware and software systems in relation to
each other. In this section, the typical hardware and software systems are positioned on the hierarchy
by briefly investigating each level of the hierarchy.
The positioning of information systems is discussed in this section, but Table 10 provides an overview
of the most important systems at a quick glance. A few of the largest vendors (SAP, Dassault Systèmes,
Siemens, etc.) are attempting to create integrated software systems that include all the functionality
a factory might use. However, the cost of acquisition, implementation and support of these systems
make them inaccessible to small and medium enterprises.
Table 10: Information systems associated with the functional hierarchy levels of IEC62264:2013-1.
IEC62264:2013-1 (IEC, 2013) does not explicitly list the functions of level 4, but rather assumes all
functions not included in levels 1, 2 and 3 to be part of the enterprise level (level 4). Levels 1, 2 and 3
are collectively named the manufacturing operations and control domain, indicated in blue in Figure
4. This domain includes any control function or activity that directly interacts with the product or the
equipment used to produce the product. Monk and Wagner (2013) list the following four functional
areas of an enterprise and state that an enterprise resource planning (ERP) system may support all
four: marketing and sales, supply chain management (SCM), accounting and finance, and human
resource management. Indeed, ERP systems have undergone significant expansion of scope over the
last two decades (Nwankpa, 2015; Schlichter and Kraemmergaard, 2010; Seethamraju, 2015). Modern
ERP systems effectively include the functionality of all level 4 functions, and in some cases even
beyond that (Kurbel, 2013; Møller, 2005). Concurringly, Ugarte et al. (2009) present a simple mapping
of ERP to level 4 and Manufacturing Execution System to level 3. Cadavid et al. (2015) follow suit with
their vision for a smart factory. Thus, it can be concluded that the ERP system adequately represents
75
the functionality of level 4 information systems. This generalization does not dismiss other
information systems, but rather opts for simplicity in the interest of clarity.
Compiling a single list of information systems in level 3 of the functional hierarchy is difficult.
Manufacturing operations management is supported by a variety of specialized information systems,
offered by vendors with different approaches and philosophies. For the sake of standardization,
IEC62264:2013-1 recognizes four categories of manufacturing operations: production, inventory,
maintenance and quality operations (IEC, 2013). The activities involved in those categories of
operations differ quite substantially and are therefore generally supported by the following four
specialized information systems: manufacturing execution systems (MES), warehouse management
systems (WHMS), computerised maintenance management systems (CMMS) and quality
management systems (QMS).
Level 2 includes the control systems of individual devices and supervisory control to keep the process
stable. Alexakos et al. (2006) list three types of control systems at level 2 of the functional hierarchy:
programmable logic controller (PLC), numerical controller (NC), and more modern robot controllers.
Modrák and Mandulák (2009) present a mapping of MES functionality to level 3 and reinforce the
importance of integration to level 2 systems, including supervisory control and data acquisition
(SCADA) and distributed control systems (DCS). Finally, level 1 represents the hardware that
manipulate and monitor the process (Chen, 2005), including manual manipulation and sensing,
robotic actuators, automated sensors and vehicles. To keep
To lend some confirmation, two studies offer mappings of systems across multiple levels. Unver
(2013) uses the hierarchy to propose that a manufacturing intelligence system can be situated across
levels 3 and 4. Nagorny et al. (2012) present a rather complete architecture for manufacturing
automation by positioning each information and hardware system within one of the levels of the
hierarchy. Both these studies position the ERP system on level 4, MES and CMMS on level 3, and
SCADA, PLC and DCS on level 2.
76
Other
Level 4
ERP
information
system
systems
Level 3
Human Human
SCADA DCS PLC
interface interface
Level 1
Figure 52: Software and hardware systems related to the functional hierarchy of IEC62264:2013-1
(IEC, 2013).
The mapping of hardware and software systems to hierarchy levels is pleasingly consistent and helps
to construct the enterprise architecture of computer integrated manufacturing shown in Figure 52.
Completeness can’t be claimed, but good representation of the typical systems is achieved based on
the existing literature. The resulting architecture conforms to the layered architecture pattern as
defined by Bass et al. (2013). This pattern follows the principle of functional abstraction, with each
layer making use of functionality in the layer directly below it.
Interfaces between information systems are often facilitated by middleware. For example, an
enterprise services bus can be used to facilitate many-to-many interfaces, without establishing all
point-to-point interfaces between the individual systems. For the sake of simplicity, such middleware
is excluded from Figure 52. The architecture presented in Figure 52 will be used to point out the
prevalence of process management throughout computer integrated manufacturing.
77
Production Resource allocation
orders
Scheduling
Process - Machines / Labour
S
Resource allocation
and status 1 management - Tasks / Products H
11 2
Performance
O
Resource Document
status
analysis 10 3 control Process P
E status
R Product
9
MES 4 F
Data collection/
P tracking and
acquisition
Tracking genealogy Resource L
8 5 status
Maintenance Labour O
management management
Produced
7 6 O
Dispatching Quality
quantities
production units management
Events R
For level 3, IEC62264:2013-1 (IEC, 2013) lists process management as one of 12 activities of
manufacturing operations management. Thus, process management is an important function of each
of the four categories of manufacturing operations (i.e. production, inventory, maintenance and
quality operations). The Manufacturing Enterprise Systems Association (MESA) views the MES as the
equivalent of a Manufacturing Operations Management System (MOMS) (MESA, 1997). In such a
broad definition, an MES includes functionality to manage maintenance, inventory and quality
operations (Cottyn et al., 2011). Regardless of the disagreement about system scope, process
management still features prominently as one of the 11 functions of a MES, as shown in Figure 53.
With process management prominently featured across levels 3 and 4 of the functional hierarchy, it
is sensible to consider the interoperability of those process management functions. The dispersed
process management functions are likely to be poorly aligned, as it is based on the requirements of
the host system. The following problems can be expected with multiple, separate process
management functions:
• Different modelling approaches and notations, such as Business Process Model & Notation
(BPMN) for level 4 systems and Value Stream Mapping (VSM) for level 3 systems (Grewal,
2008).
• Poor visibility of the status of customer orders, as a single order might involve multiple
information systems.
• Difficulty to coordinate cross-functional work, because activities may cross the barriers of
business functions and, therefore, the purview of individual process management systems.
Several scholars pursue integration between process management functions (Prades et al., 2013;
Gerber et al., 2014), but a bolder approach is proposed here: The process management functionality
across levels 3 and 4 should be unified in a single process management system. This unified system
can then orchestrate business management and operations activities, as a single case from order to
delivery.
78
application 3 , as it does not directly contribute to the business activities, but rather enables the
efficient execution of activities. Thus, a BPMS is positioned as an infrastructure component, as defined
by Leymann and Roller (2000).
Infrastructure
layer BPMS DBMS
Middleware
Application layer
Figure 54: Infrastructure and application layers, showing three typical information systems in the
infrastructure layer.
Layers are used to illustrate the relationship between infrastructure and applications. Figure 54 shows
two architecture layers, namely infrastructure and application layers, with information systems
depicted within those layers. A BPMS is shown alongside a database management system (DMBS) and
middleware as typical infrastructure systems. To avoid confusion between the functional hierarchy
(Figure 4 in Chapter 1) and architecture layers (Figure 54), a two-dimensional view is adopted. The
vertical dimension features the levels of the functional hierarchy, ranging from level 1 to 4, while the
horizontal dimension features the infrastructure and application layers. The layout of the two
dimensions and two illustrative application systems are shown in Figure 55.
Infrastructure layer
Application layer
Functional
Application Application
level
system system
Figure 55: Architecture layers shown as a horizontal axis, with a single functional level shown for
the application layer.
A unified Manufacturing Process Management System (MPMS) can serve multiple application
systems. Instead of integrating different process management subsystems of several application
systems, a single process management system can deliver the process management functionality to
all application systems. This concept is illustrated by exposing the infrastructure layer behind the
computer integrated manufacturing architecture. The MPMS serves as a central hub of orchestration
between information systems, human interfaces and robot control systems, as shown in Figure 56.
3 To be clear, the term ‘information system’ is used here to refer to any system that processes
information. An application system is a type of information system. Thus, it is argued that a BPMS is
an information system, but not an application system.
79
The middleware and other infrastructure systems are omitted from Figure 56 in the interest of
simplicity.
Other
Level 4
WHMS QMS
Level 3
MPMS
MES CMMS
Level 2
Figure 56: Process-centric architecture for computer integrated manufacturing showing MPMS as
an orchestration hub for level 2, 3 and 4 systems.
The MPMS initiates a process instance for a customer or production order, based on the schedule
defined in the ERP or MES. The MPMS then sends work items and instructions to application and
control systems, as specified in the process model. A human interface and two automated agent
control systems are shown in Figure 56 to illustrate the potential for heterogeneity. The MPMS can
send work items to a variety of different control systems and human interfaces as necessary. The
central role of the MPMS should be embraced as far as possible, but it does not preclude other
interfaces, as illustrated with the direct connection between the MES and a PLC on the left of Figure
56.
The same application systems feature on levels 3 and 4 of Figure 56, as in Figure 52. However, those
application systems are now all connected to the MPMS. Again, these interfaces are illustrative, to
explain the central role of the MPMS. To be more precise, the application systems and MPMS will be
connected via middleware. Figure 57 shows a cross-section of the enterprise architecture to explain
how systems on the infrastructure layer will facilitate connectivity and orchestration. The application
and infrastructure systems are all connected to the middleware, instead of point-to-point interfaces
between systems.
80
Infrastructure
layer BPMS DBMS
Middleware
Application layer
Auto agent
ERP Human
MES control
system interface
system
Figure 57: Cross-section view of the infrastructure and application layers to explain how the
infrastructure systems facilitate connectivity.
Information systems architecture design practice and principles are applied to give structure to the
design effort. The design process is first discussed, followed by design principles derived from
literature. Then, the design is described according to the design approach. The design description is
divided into logical and physical views, as dictated by the design process.
1. The logical view is concerned with what the system should do. It specifies the functionality
of the system in the form of modules and relationships between modules. The main
stakeholders are the end users of the system.
2. The development view is concerned with good software management. It specifies how the
software system is organized in a developmental environment. The main stakeholders are
programmers and software managers.
3. The process view is concerned with the performance and scalability of the system. It
specifies the concurrency and synchronization of the system modules. The main
stakeholders are the integrators of the system.
4. The physical view is concerned with realization and deployment of the system. It specifies
the allocation of hardware resources to software modules. The main stakeholders are the
engineers who are responsible for installing and maintaining the system.
Separate views with different stakeholders can result in a divergence of ideas and an understanding
about the system. To avoid such a divergence, the four views are reconciled by a fifth concept:
81
5. Scenarios represent user cases of the system that demonstrate system functionality and
performance. The scenarios should be specific and practical enough to facilitate discussion
about the expected operation of the system in its intended context.
End-user Programmers
Functionality Software management
Development
Logical view
view
Scenarios
The Kruchten 4 + 1 framework is used to sequence the MPMS development. The scenarios, shown in
the middle of Figure 58 are described in detail in the three practical cases as discussed in Section 2.2
of Chapter 2. The first view, the logical view, is used to specify the functional structure of the system
without reference to specific implementation techniques, technologies, or deployment. The main
input of this design is a clear description of the scenarios (Section 2.2) and the problems faced in those
scenarios (Section 2.3). The output of this phase is the logical architecture design, presented in Section
3.3.3 of this chapter.
The development and process views are concerned with a good software engineering practice and
system scalability. These considerations are less important for scientific inquiry in the context of this
research and are, thus, not explicitly presented in this thesis. However, the detailed development of
the agent allocation module presented in Chapter 6 does include considerations of the development
and process views.
In the physical view, it is determined how and where the software will run, i.e. the system realisation
and implementation. The physical view of the MPMS is presented in Chapter 7 of this thesis, to retain
the conceptual nature of the discussion in the current chapter.
82
Figure 59: The Reference Architecture for Industry 4.0 (RAMI4.0) as presented in DIN SPEC
91345:2016-04.
Central control also implies simultaneous control of multiple processes, at varying lifecycle stages, and
the participants in those processes, spread across the work cells of a factory. RAMI4.0 brings together
the process lifecycle, control hierarchy and equipment hierarchy in a single architecture. The
reference architecture was recently adopted in DIN SPEC 91345:2016-04 (DIN Deutsches Institut für
Normung, 2016) to give structure to the rapidly developing and changing technologies in
manufacturing. According to the standard, “the fundamental purpose of Industry 4.0 is to facilitate
cooperation and collaboration between technical objects, which means they have to be virtually
represented and connected.” The reference architecture brings together the business, life cycle, and
hierarchical views of an asset by relating the concepts on three orthogonal dimensions (Hankel and
Rexroth, 2015):
• The life cycle and value stream dimension “represents the lifetime of an asset and the value-
added process.” This axis distinguishes between the type and instance of the factory and its
elements. For example, the digital design of a product and its instantiation as a
manufactured product.
• The hierarchy levels dimension is used to “assign functional models to specific levels” of an
enterprise. This axis uses aggregation to establish enterprise levels that range from the
connected world (i.e., networks of manufacturing organizations in their eco-systems) via
stations (manufacturing work cells) to devices and products.
• The layers dimension is more formally referred to as the architecture axis. This axis
“represents the information that is relevant to the role of an asset.” It covers the business-
to-technology spectrum by relating different aspects of an asset to layers of the enterprise
architecture.
83
The life cycle and value stream dimension of RAMI4.0 distinguishes between the type and instance of
a product and its value-added processes (DIN Deutsches Institut für Normung, 2016). For the product
itself, the difference between type and instance is obvious. A product is developed and specified,
representing the type, then multiple of those product types are produced, or instantiated. The same
can be applied to the process. Type can be equated to the design of a process, then multiple instances
of the process are executed to produce multiple product instances. This type-instance dichotomy is
common in BPM standards (Ko et al., 2009).
Enterprise
Site 1 Site 2
Production Production
line 1 line 2
Figure 60. Illustrative physical hierarchy of a manufacturing enterprise based on the hierarchy
levels dimension of RAMI4.0.
The architecture axis is mostly concerned with the digital representation of assets in the factory. In
fact, the axis shows that all levels of the physical hierarchy can be represented from multiple
architectural perspectives. For example, a work centre can be represented as a set of business goals
(business layer), as a process (functional layer) or as a collection of machines (asset layer). DIN SPEC
91345:2016-04 further elaborates on this concept by insisting that all assets should be enveloped in
an administration shell, as shown in Figure 61. This principle is reminiscent of the concept of
encapsulation in service-oriented thinking (Howells, 2004). The same can be applied to the
84
manufacturing process. The activities executed, actors involved, and equipment utilised can be
represented from multiple perspectives, including physical and functional perspectives.
Figure 61: Evolution from a traditional asset to an industry 4.0 component (DIN Deutsches Institut
für Normung, 2016).
Separation of concerns is widely used to manage complexity in system design (Garcia et al., 2004;
Kulkarni and Reddy, 2003; Moreira et al., 2005). The technique allows the designer to consider some
aspect of the system separately from the rest of the system, which decreases local complexity. The
technique is applied to establish three separations in the MPMS, derived from the three dimensions
of RAMI4.0. The three design principles derived from RAMI4.0 are listed in Table 11.
Table 11: System design principles derived from the three RAMI4.0 dimensions.
85
• The process aspect describes the lifecycle of items processed by the information system.
This is typically expressed as process flow diagrams showing the phases that an information
item can cycle through.
• The organization aspect describes how the information system is embedded into an
enterprise. This is typically expressed as an organisation chart, with positions and roles, and
use cases for those roles.
• The platform aspect describes hardware and software that the information system relies
on, e.g. operating systems, database management systems and middleware.
• The data aspect describes the how the data of an information system is organised, typically
expressed as data structure diagrams or specifications.
• The software aspect describes the structure of the software of the information system,
typically expressed as class or block diagrams.
Figure 62: Modernized variation on the Truijens 5 aspects framework (Grefen, 2016).
The design-time and run-time phases can be further subdivided to represent a more detailed process
lifecycle. Figure 63 shows a typical process lifecycle, with the first two phases part of the design-time
and the final two as part of run-time. Therefore, process definitions are created during design-time,
then potentially multiple process instances are generated during run-time.
86
Design-time Run-time
• Conceive: The production process is identified based on the product to be produced. For a
product that has been produced before, the existing process may simply be used.
Alternatively, for a completely new product, a new process is required.
• Design: The process is designed, based on the required production activities. For a variation
of an existing product, this may only involve parameterisation of an existing process. For a
new product, it will be a more comprehensive process design.
• Production execution: Activating the selected or designed process to initiate production.
This phase includes the enactment of the work flow, the allocation of agents to the tasks
and the handling of exceptions that may arise.
• Process evaluation: Review of the completed process to discover problem causes and
improvement opportunities.
Figure 64 shows a few illustrative process lifecycles that attempt to show that the phases may differ,
depending on the type of product to be produced. Some products will only require process
parameterisation, but a completely new product may require physical and functional process changes.
In most manufacturing enterprises, these different lifecycles will not occur equally frequent.
Four hypothetical production orders are shown in Figure 64, within a time span of 14 days. The four
orders can be summarised as follows:
1. Order 1 arrives first and requires an adjustment to a product that the factory currently
produces. The production process is correspondingly parameterised, and the order is for a
large quantity.
87
2. Order 2 arrives third, after a lengthy negotiation with the client, because it involves
introduction of a completely new product family. This also involves a lengthy design of a
new production process and only a short production run.
3. Order 3 arrives second and is a rush order. It is for a product that is currently offered by the
factory and production is expedited.
4. Order 4 arrives last, but at about the same time as order 2. It requires more adjustment than
order 1 and re-configuration of parts of the production process. Even though it arrives about
the same time as order 2 and it requires much less process design, it still finishes later.
The lifecycle perspective helps to understand how the MPMS must handle processes and resources.
The terminology established by van der Aalst and van Hee (2004) can be used to construct the activity
model shown in Figure 65. The model contains three lanes, one for process and resource each, and
one for the actual execution of work by the resource. In the process lane, a process definition is
defined and contains task definitions. A task definition contains the actions that must be performed,
referred to as a work item. In the work execution lane, a process instance is instantiated from the
process definition and contains task instances. An assigned task instance contains the work to be
performed, named an activity instance. In the resource lane, resource definition starts separately from
process definition, because resources (physical) and activities (functional) are independent. The
resource is activated when the resource is made available to perform work. When an active resource
is assigned to a task instance, it becomes an assigned resource. Once the assigned resource starts
execution, as per the activity instance, the resource is occupied. Finally, once the activity instance is
completed, the resource is released to be assigned to other task instances. Task failures are omitted
from this model in the interest of understandability.
88
Figure 65: Activity diagram showing the states of processes, tasks and resources.
By considering the execution of manufacturing processes with the MPMS, the following two
interesting concepts are illustrated: asynchronous production and process variation. Asynchronous
production refers to the possibility that more than one process instance may be (and will be in most
cases) active at the same time in the factory. The states (lifecycle phase) of those process instances
may be different. The physical limitations of a factory will be an important consideration here. In most
cases, a single production line, work cell or production resource can only accommodate a single
production order at a time. Additionally, mechanics are involved in the flow of materials, parts and
products flows through the factory floor, instead of only information flow. As for process variation,
Figure 64 shows that the actions performed within the different lifecycle phases depend on the nature
of the production order. For example, the extent to which a process is designed or changed
(reconfiguration or parameterisation) depends on the product ordered (new product or
customisation).
89
control is concerned with the actions performed by a single resource or a team of resources within a
single work cell of the factory. The different control regimes are indicated in Figure 66. Thus, global
and local control is separated to account for different control regimes. Global control is concerned
with the coordination of activities that may be spatially dispersed while local control is concerned with
the sub-second synchronization of the actions of resources.
Site 1 Site 2
Production Production
line 1 line 2
Team of
Resource 1
resources
Local control
Figure 66. Illustrative physical hierarchy of a manufacturing enterprise showing the different
control regimes applied at different levels of the enterprise.
The physical hierarchy, as shown in Figure 66, also guides a naming convention for entities in the
manufacturing enterprise. For example, production line 1 contains two work cells, simply named work
cells 1 and 2. More importantly, this naming convention assists with creation of a location specification
of a factory. It is important to specify the location of activities and resources in a factory, due to the
physical nature of manufacturing. This concept is further elaborated in the data aspect in section
3.3.3.4.
90
expected that mass customized products will be produced by smart robotics in dynamic processes
managed in the cloud (Zhang et al., 2014). It is even conceptually understood how these technologies
should work together to achieve smart manufacturing and deliver on the promises of Industry 4.0 (Qu
et al., 2016b; Tao and Qi, 2018). Computation that is not time-critical is relegated to the cloud. The
IoT facilitates commands and responses to and from devices and teams of humans and smart robotics
perform sophisticated operations.
To give some structure to the complicated set of technologies, the technology stack of Wortmann and
Flüchter (2015) is placed within the two layers of Figure 57 to produce Figure 67. The infrastructure
layer is elaborated to distinguish cloud and connectivity layers. Additionally, Figure 67 includes two
stacks for two separate physical sites, emphasizing the potential for inter-organizational collaboration
via the internet. Thus, the MPMS becomes part of the collaboration infrastructure, as developed in
the CrossWork project (Paul Grefen et al., 2009). A single MPMS can serve multiple supply chain
partners alongside the cloud-based data storage of the information hub model (Gerhard et al., 2001;
Lee and Whang, 2000). The MPMS is aware of all potential work assignees and receives real-time data
from the different facilities.
Cloud
Cloud data
MPMS Analytics
storage
Resource allocation and task instructions
Figure 67: MPMS in the context of IoT, showing the potential for inter-organizational process
management.
91
3.3.3.4 Data aspect
The third design principle of Section 3.3.2 is applied to distinguish between the data related to physical
and functional aspects of the manufacturing system. The MPMS is responsible for the coordination of
activities (functional) performed by resources (physical). Thus, the MPMS must have information
regarding the resources and activities in the manufacturing system. Furthermore, the location
(physical) of the resources and activities must also be known to determine whether the resource can
perform the expected activity. Using the moment of actual work execution in Figure 65, the assigned
resource, activity instance and location can be related to each other using the UML class diagram
shown in Figure 68. An activity instance is performed by one to many assigned resources. An assigned
resource can only perform one activity instance at a time. Furthermore, both the assigned resources
and the activity instance has one location each; most likely the same location given the physical nature
of manufacturing activities.
All three the main entities can be further subdivided. Starting with the location entity, the physical
hierarchy of IEC62264:2013-1 is again referenced as per the naming convention mentioned in the
organisation aspect (see section 3.3.3.2). Thus, the location is a generalisation of any item in the
physical hierarchy, including enterprise, site, area, work centre and work unit. Figure 69 shows the
portion of the data aspect model related to the location entity.
92
Figure 69: Location-related portion of the data aspect model of the MPMS.
The location entity in Figure 69 shows some properties that should be known about a location, three
of which can be derived from the physical hierarchy of IEC62264:2013-1. The location_id is
constructed from the enterprise and a sequential integer. For example, TRI-1-1-2 is production line 2,
in production area 1 of site 1 of the TRI enterprise. Location_name is any name the enterprise uses to
refer to the location. Location_type is derived directly from the physical hierarchy. Lastly, the
location_contains property caters for the recursive nature of locations. The enterprise has one or
more sites. A site contains one or more areas. Thus, an information map of the entire enterprise is
created as a set of locations.
The most interesting and complicated portion of the data aspect model is related to resources. Typical
business processes have only human participants, supported by application systems. In a factory
though, resource can refer a variety of physical objects, including machines, vehicles, sensors and
humans. Essentially, resources comprise all objects in levels below “work units” in the physical
hierarchy of IEC62264:2013-1 (see Section 2.1.2 in Chapter 2).
It is important to differentiate between resources that perform activities and resources used to
perform activities, because activities must be assigned to resources that can perform those activities.
Thus, activities should be assigned to resources that can act independently. The formal framework for
agency of Luck and d’Inverno (1995) is a well-defined and congruent frame of reference to define
different types of resources in a system. Table 12 lists the relevant definitions of entities, as extracted
from the framework of Luck and d’Inverno (1995).
93
Table 12: Definitions of entities as extracted from the formal framework for agency of Luck and
d’Inverno (1995).
Term Definition
Action A discrete event that which changes the state of the environment.
Agent An instantiation of an object together with an associate goal or
set of goals (it does not have to be its own goals, but simply that it
satisfies some goals/purpose).
Attribute A perceivable feature.
Autonomous agent An instantiation of an agent together with an associated set of
motivations.
Goal A state of affairs to be achieved in the environment.
Motivation Any desire or preference that can lead to the generation and
adoption of goals and which affects the outcome of the reasoning
or behavioural task intended to satisfy those goals.
Object An entity that comprises a set of actions and a set of attributes.
Applying the differentiation between objects and agents results in the data model shown in Figure 70.
Resource is the general entity that can be specialised as either an object or agent. All resource
definitions have an identifier and name. An object definition, as a specialisation of resource definition,
has an identifier, name and type. Object type can be a tool, product or material. Agent definition is
also a specialisation of resource definition and has an identifier, name and type. For agents, the type
can be human or automated (e.g. machine, industrial robot, autonomous guided vehicle). Resource
definitions are converted into activated resources when the resource if available to perform work.
Activated resources can also be part of coalitions, to perform collaborative tasks. Agent coalitions are
further explored in Chapters 5 and 6. One or more resources are assigned to a task instance and then
perform the work specified in the work item instance.
94
Figure 70: Resource-related portion of the data aspect model of the MPMS.
The third entity, activity, refers to the actions performed in the manufacturing enterprise, including
manufacturing operations and business processes. Figure 71 shows the activity-related portion of the
data aspect of the MPMS architecture model. The research presented in this thesis makes use of
Business Process Model and Notation 2.0 (BPMN2.0) to model processes. BPMN2.0 uses processes
and tasks to represent activities (Object Management Group, 2013). To cater for sub-processes, a
process can also contain processes. A task also contains work items to be performed by resources.
The first design principle listed in Table 11 is again applied to separate type and instance. Processes,
tasks and work items are all separated into definition and instances. The MPMS creates activity
instances upon process activation. A work item is instantiated as an activity instance, according to the
terminology of van der Aalst and van Hee (2004). An assigned resource then performs the actions
required to complete the activity instance.
95
Figure 71: Activity-related portion of the data aspect model of the MPMS.
The data aspect of the MPMS architecture raises the following interesting observations about the
MPMS:
1. The three main entities are independent. Activities are performed in locations, but a
location persists even if no activity is active. Similarly, a resource can be activated even when
not assigned a task instance. This reinforces the third design principle: separation of physical
(resources and locations) and functional (activities) aspects of the manufacturing system.
2. Resources and locations are persistent, i.e. these entities are not instantiated. Activities are
performed as instantiations of activity definitions. The definition-instance dichotomy
reinforces the first design principle: separation of type and instance.
3. Resources and activities are transient, i.e. these entities can change state. Locations states
are not used in this design.
4. Resources can move between different processes instances and locations.
5. Activities can be instantiated in different locations.
6. Activities and resources have definition and instance data. Definition data changes
infrequently (such as abilities, authorizations, etc.) and are defined during design-time,
while instance data that changes frequently (such as performance, workload, etc.) and are
captured during run-time.
96
A BPMS is used to orchestrate the activities in an organization by allocating resources to perform
those activities. The information system that is designed as part of this research is based on such a
BPMS. Consequently, the design will not start from scratch, by defining system functions that satisfy
the established requirements. Instead, a reference architecture model of a BPMS is used as starting
point and extended as necessary for smart manufacturing processes.
Figure 72 shows the workflow management system (WfMS) reference architecture model of the
Workflow Management Coalition (WfMC) (Hollingsworth, 1995). This architecture model is often used
to depict the basic structure of a BPMS (Pourmirza et al., 2017) and used as starting point in of the
software aspect model.
Process
definition
tools
IF1
Workflow API and
interchange formats
Workflow enactment Other workflow
Administration IF5
& monitoring
service enactment service
IF4
tools Workflow Workflow
engine(s) engine(s)
IF2 IF3
Workflow
Invoked
client
applications
applications
This research is primarily concerned with highly configurable, flexible manufacturing processes
involving human and robotic participants. All three scenarios, as discussed in chapter 2, feature
processes with cooperation between humans and robots. Therefore, the MPMS interfaces with a
variety of humans, robots, and sensors that participate in the manufacturing processes.
The WfMS reference architecture model specifies all functionality necessary to model and enact
business processes. However, manufacturing processes impose additional requirements on a process
management system, as established in section 4 of chapter 2. These additional requirements must be
satisfied with new functionality or enhancements to existing functionality. Table 13 shows how the
requirements established in Chapter 2 are mapped to new or enhanced system functions of the
MPMS.
97
R# Requirement Function New or
enhanced?
R01 The MPMS can be integrated into the existing Interfaces. Enhanced
enterprise architecture of a manufacturing
enterprise.
R02 The MPMS enables vertical integration, i.e. control Interfaces. Enhanced.
across levels 2, 3 and 4 of the functional hierarchy
of IEC62264:2013-1.
R03 The MPMS integrates the main technologies that Interfaces. Enhanced
drive smart manufacturing.
R04 The MPMS can be used to define dynamic Process definition. Enhanced.
manufacturing processes.
R05 The MPMS can enact dynamic manufacturing Process engine. Existing.
processes.
R06 The MPMS can be used to define manufacturing Resource definition, New.
resources, such that it can be determined which Task definition,
resource is necessary for an activity. Location definition
R07 The MPMS can select resources for activities, Agent allocation. New.
based on the task requirements and resource
attributes.
R08 The MPMS can coordinate the activities of Process engine. Existing.
heterogeneous actors (humans and different
robots).
R09 The MPMS can assign multiple actors to a single Agent allocation. New.
activity.
R10 The MPMS can respond to changes in the Process engine. Existing.
manufacturing processes.
Placing the WfMS reference architecture in the context of a manufacturing enterprise yields Figure
73. The function named “interfaces” represents the various touch-points between the MPMS and
other software systems. This enhancement is necessary to place the existing process management
technology in the manufacturing context. The process engine interfaces to systems of levels 2, 3 and
4. The process engine will initiate activities performed by personnel supported by the ERP and
manufacturing operations management systems (IF3). For example, the production planner will
determine the schedule, then indicate that production planning is completed. Once operations are
initiated, the process engine will send work items to humans and automated agents on the factory
floor (IF2). Process models and information of agents can be updated using the process definition
tools (IF1) and the administration and management tools (IF5), respectively. Interfaces to other
workflow engines (IF4) are purposefully excluded, for the sake of simplicity.
98
Level 4
ERP system
IF3
IF2 IF2
Automated agent
Human agent interface
control system
Figure 73: The MPMS in the context of the functional hierarchy levels, with interfaces to
application systems.
Even though automated agents are controlled by software systems, the control systems of automated
agents are purposefully positioned as client applications (IF2), instead of invoked applications (IF3).
This decision establishes parity between the humans and automated agents, in line with the increasing
collaboration between humans and robots on the factory floor (Bauer et al., 2008).
At long last, the MPMS software architecture can be elicited by going an aggregation level deeper.
Figure 74 shows the three subsystems of the MPMS: definition tools, process enactment service and
administration & management tools. Definition tools is elaborated with four system modules, and the
process enactment service has two system modules. Administration & management tools is not
further elaborated because no changes to the reference architecture are required.
99
ERP system
MES / QMS /
MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Automated
Human agent
agent control
interface
system
Figure 74: Software aspect of the MPMS architecture showing the new (coloured blue) and
enhanced (coloured green) logical system modules.
The two new system functions listed in Table 13 leads to four new system modules. The first new
function, resource definition, leads to an expansion of the definition tools module of the reference
architecture. Instead of only process definition tools, the architecture now has modules to define
tasks, resources and locations, in line with the design established in the data aspect (see section
3.3.3.4). The second new function, agent allocation, introduces a new module in the process
enactment service subsystem. The existing process engine is accompanied by a new “agent allocation”
module, dedicated to the selection and assignment of agents to tasks.
The MPMS architecture that is described in this chapter contributes in two ways: 1) it shows how a
unified process management system can help to drive integration across levels three and four of the
functional hierarchy, and 2) it provides guidance on the design and realisation of a process
management system that utilises recent developments in Industry 4.0.
100
ERP system
MES / QMS /
Chapter 4 MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Chapter 6
Chapter 5 Human agent
Automated
agent control
interface
system
Figure 75: The MPMS software aspect architecture, showing how system modules relate to
subsequent chapters in this thesis.
The MPMS requires functionality beyond that provided by a typical BPMS (as described by the
WfMC reference architecture (Hollingsworth, 1995)). Although the process aspect discussed the
enactment of manufacturing processes in Section 3.3.3.1, the design of such processes is not
discussed in this chapter. Furthermore, two new system functions are identified in Table 13 and
designated as four new system modules. Lastly, interfaces to robotic systems and other advanced
manufacturing technologies are also explored as part of the system realisation. These topics are
discussed in subsequent chapters, as indicated in Figure 75. The following three topics are discussed
in the subsequent chapters:
101
Chapter 4
4. DESIGN OF EXECUTABLE MANUFACTURING
PROCESSES
The challenge and appeal of improved integration between manufacturing operations and business
management functions is well understood (Hausman et al., 2002; Tang, 2010) and extensively
discussed in Chapter 3. The techniques, skills and information systems employed to manage business
activities can differ significantly from those used to manage operations, leading to deficient
throughput and flexibility (Sawhney, 2006; Tang, 2010). For example, the lean manufacturing
principles often applied in operations management are not easily transferrable to resource or financial
management. The performance benefit of improved integration between business and operations
management is extensively studied, but these studies focus on the alignment of planning to achieve
maximum production throughput (O’Leary-Kelly and Flores, 2002; Sale et al., 2017).
Business process management (BPM) is often employed to cross the boundaries of business functions
and improve integration (Berente et al., 2009; Hanson et al., 2002; Kobayashi et al., 2003). The same
need exists in the manufacturing industry, but it suffers from disparate and fragmented process
management across multiple information systems (Erasmus et al., 2018). Indeed, Prades et al. (2013)
make the case for integration between enterprise resource planning and manufacturing execution
systems, by using Business Process Model & Notation (BPMN) for process modelling in both
information systems. Conversely, Gerber et al. (2014) investigate how process models can be
converted between the information systems that support business management and operations
management. More recently, a single business process management system for business and
operations management is proposed and demonstrated (Pauker et al., 2018).
While these studies embrace the ambition of cross-functional process management, the suitability of
existing process modelling techniques remains unproven. Manufacturing enterprises perform
material processes in addition to business processes, according to the differentiation of Medina-Mora
et al. (1992). BPMN, as the de-facto standard for business process modelling (Decker and Barros, 2008;
Takemura, 2008), is shown to be suitable for business processes (Wohed et al., 2006), but its suitability
for material processes remains unproven. Thus, it is prudent to determine whether BPMN can be used
for manufacturing operations processes, i.e. the material processes performed by manufacturing
enterprises.
Hommes and Reijswoud (2000) proposes eight metrics for the assessment of modelling techniques,
divided between the way of modelling and the way of working. This research is concerned with the
modelling of manufacturing operations, i.e. the way of modelling. The way of modelling has the
following two metrics:
• Completeness: The degree to which all necessary concepts of the application domain are
represented in the way of modelling.
102
• Suitability: The degree to which a given modelling technique is specifically tailored for a
specific kind of application domain.
The application domain referred to in both the completeness and suitability metrics is set to
manufacturing operations. Accordingly, this research demonstrates the suitability of BPMN for
manufacturing operations processes, by presenting model fragments of operations processes.
Apart from assessing the suitability of BPM for manufacturing operations processes, it is the objective
of this thesis to develop a theory on the exaptation of BPM for manufacturing operations processes.
As such, the result of the suitability assessment should also provide prescriptive knowledge that can
be applied when designing manufacturing operations processes. The set of model fragments is the
prescriptive knowledge contribution of this chapter. Consequently, this chapter serves two purposes:
1) to assesses the suitability of BPMN for the material processes, i.e. the manufacturing operations
processes, and 2) to provide guidance on the use of BPMN to model executable manufacturing
operations processes.
To assess suitability, manufacturing operations must ultimately be modelled using BPMN2.0. Thus,
this chapter demonstrates the use of BPMN2.0 for manufacturing operations. This is done by creating
a taxonomy of manufacturing operations, based on literature. As an intermediate evaluation, three
factories are analysed to check whether the taxonomy of manufacturing operations is complete.
Secondly, the manufacturing operations of the taxonomy are decomposed into concepts to identify
the building blocks of manufacturing processes. The concepts are then compared to the elements of
the BPMN meta-model, to determine whether any manufacturing concepts can’t be represented with
BPMN (denoted as modelling deficiencies). The manufacturing operations are finally modelled using
BPMN2.0, resulting in a set of process model fragments. To evaluate the research, those model
fragments are used and combined to model and enact processes at the three factories.
Figure 76 illustrates the approach taken in this chapter, based on the design science research
framework of Hevner et al. (2004). Three columns are used to depict the environment, research and
knowledge base. The environment represents the practical context of the research, i.e. the
manufacturing industry. The research lane includes the activities performed in this work, with
indication of the section where those activities are reported. Lastly, the knowledge base represents
the collective scientific literature related to the research topic.
103
Environment Research Knowledge base
2. Identify necessary
modelling concepts Modelling deficiencies
(completeness)
Section 4.4
BPMN2.0
The modelling effort, shown as the third research activity in Figure 76, results in a set of process model
fragments for manufacturing operations. The set of fragments is the main contribution of this research
and is evaluated in practice (the environment). These fragments can be used as building blocks when
modelling manufacturing operations processes. Thus, the set of process model fragments is the
artefact, in design science research terminology, that is contributed to the knowledge base.
This article is organised according to the research methodology shown in Figure 76. Section 4.2 briefly
explores related work to see what can be learned from similar research. Section 4.3 presents the
taxonomy of manufacturing operations created during the first step of the research methodology.
Section 4.4 then shows the decomposition of the items in the taxonomy into modelling concepts to
determine whether BPMN2.0 can express all the necessary concepts. Section 4.5 presents the process
model fragments of all items in the taxonomy of manufacturing operations. Section 4.6 presents the
application and evaluation of the manufacturing process model fragments in three factories across
Europe. Lastly, the results of the evaluation are discussed in section 4.7 and conclusions are drawn in
section 4.8.
104
outlier is the healthcare sector, where patient handling processes are often modelled and enacted
using a business process management system (BPMS) (Reichert, 2011; Van Gorp et al., 2013).
Regarding the notation under consideration, BPMN has achieved remarkable penetration in
information processing enterprises, both as a description of processes and as notation for process
automation (van der Aalst, 2013). The wide adoption of BPMN has inevitably led to extension
proposals. Although the notation is quite capable of representing complex processes, domain-specific
symbols and constructs are appealing to audiences confined to specific industry sectors. Such
extension proposals are prevalent enough to warrant a survey by Braun and Esswein (2014). The
survey found 30 extensions, classified according to conformance to the BPMN2.0 standard and
organised per application domain. The survey found that four out of five extensions do not conform
to the BPMN2.0 standard. Only one extension proposal was related to manufacturing (Zor et al., 2011)
and it was found to lack an abstract syntax and contained semantic conflicts with the standard. Braun
and Esswein (2014) do not offer an explanation, but it can be concluded that either there is little need
for an extension for manufacturing, or there is little need for BPMN in manufacturing.
It is therefore necessary to investigate existing process modelling and enactment techniques in the
following three steps:
Value stream mapping (VSM) is quite ubiquitous in the manufacturing sector thanks to the sheer
success of lean manufacturing principles (Grewal, 2008). It’s entrenchment in production enterprises
has even led to proposals for adoption in business functions of a more administrative nature (Keyte
and Locher, 2004). Furthermore, as with most business and process modelling notations, it is
eventually found wanting and the inevitable proposals for extensions arise (Braglia et al., 2006). More
importantly, neither IDEF nor VSM include formal execution semantic to enable process enactment.
S-BPM is a relatively new development aimed at handling the complexity of multi-agent systems, with
emphasis on manufacturing (Fleischmann et al., 2013). S-BPM is a process modelling technique which
emphasises the different perspectives of independent agents and communication between them. The
activities and states of agents are modelled as a unit (a subject in this terminology), with the possibility
of extensive communication between agents. The concept of communication between independent
agents is equally relevant for communication between agents in a single organisation or agents across
organisations (Fleischmann et al., 2015).
105
S-BPM shows promise in the manufacturing domain, especially in the new subject of smart factories
(Cadavid et al., 2015). Vertical integration between process management and individual agents has
been demonstrated (Neubauer et al., 2014) and practical evaluations have been successful (Neubauer
and Stary, 2017). Additionally, S-BPM benefits from its mathematical underpinnings and natural
language (Subject, Predicate, Object) structure (Fleischmann et al., 2015).
Given the apparent advantages of S-BPM, the limited uptake of the notation and approach it is
surprising. Practical demonstration has been successful, but it remains comparatively isolated.
Scientific research on the topic has also been slow to spread outside its place of origin, as evidenced
by the overlap of authors referenced in this section. It is perhaps too early to say whether critical mass
will be reached, but one significant barrier stands in its way: the growing popularity and enthusiasm
for BPMN. BPMN also offers the possibility of modelling processes as independent units (pools in this
terminology) with communication between agents and is supported for enactment in many
information systems. Simply stated, BPMN has reached a de-facto standard level of penetration and
enjoys global support from organisations (Decker and Barros, 2008; Takemura, 2008; Chinosi and
Trombetta, 2012).
Witsch and Vogel-Heuser (2012) also compared BPMN to other notations, but rather as the
foundation for the formal specification framework of manufacturing execution systems (MES). BPMN
compared favourably to flowcharts, petri-nets, Unified Modeling Language (UML) and Systems
Modelling Language (SysML) This effort resulted in extensive modification of BPMN though, to cater
for the specific requirements of the considered cases. Similarly, Zor et al. (2011) present BPMN
extensions for manufacturing processes, but these are again specific to the single case study.
It is clear that BPMN is a candidate for manufacturing process modelling and enactment. It has been
considered from various perspectives, including as the formal execution semantic for an MES and as
a modern replacement for IDEF3. However, these considerations are somewhat ad-hoc and disparate.
This research aims to give structure to the adoption of BPMN for manufacturing, by proving that the
notation is suitable for manufacturing processes, thereby laying foundation for further research and
application in practice.
106
refined in multiple steps and there is no a priori end-to-end execution path (Meyer et al., 2014).
However, PCM aims to reduce the need for a skilled knowledge worker to push a case forwards by
using rigid process fragments and object-centric process definitions. These process fragments are
syntactically very similar to BPMN, though with more attention paid to data nodes. The data nodes
are used to model pre- and post-conditions of activities, providing a basis for linkage between the
process fragments. An implementation of PCM exists and is presented in the work of Haarmann et al.
(2015).
Chung et al. (2003) developed a Task Based Process Management (TBPM) system that uses a library
of plans that are linked together using process models. A plan represents one of potentially multiple
ways of achieving a task, by breaking it down into a structure of sub tasks.
The Aspect-Oriented (AO) approach (Jalali et al., 2013) attempts to reduce complexity of the main
process by separating concerns into aspects. An aspect contains one or more advices, specified as
process model fragments. At run-time, aspects are interwoven with the main process, forming the to-
be-followed execution flow.
The activities specified in the model fragments must ultimately be performed by resources. Some
techniques aim to reduce the specificity of the process models to empower the resources. ConDec
(Pesic and van der Aalst, 2006) refrains from specifying control flow between activities and rather opts
for constraints that must be met as relationships between the activities. As most declarative
languages, ConDec takes a so-called outside-in approach, meaning that all behaviour is allowed unless
explicitly forbidden by a constraint. Similarly, Dynamic Condition Response Graphs (DCR Graphs)
(Hildebrandt et al., 2012) contain events and five types of relations between them. Nested sub graphs
can alternate between completed and uncompleted state, particularly suitable for the manufacturing
domain where rework can be a common occurrence in processes.
A third technique focuses on offering microservices, which provide a certain functionality. These
microservices are called by autonomous agents that intend to achieve a (process) goal (Oberhauser
and Stigler, 2017). Agents navigate the landscape of microservices, which can be represented as a
dependency graph. The structure of microservices maps well to the physical domain, where a machine
or resource typically provides certain functionality that is required as input requirement by a
downstream production step.
Two conclusions can be drawn from these research efforts, corresponding to the two approaches: 1)
There is precedent for the development of process model fragments to assist with the modelling of
processes, and 2) there is interest in the more goal-oriented process modelling, giving process
participants more autonomy to pursue those goals. This fits well with the current rise of autonomous
machines and robots seen in the manufacturing industry.
107
The widely adopted international standard series IEC 62264:2013 (IEC, 2013) provides standardised
terminology and ontology for the manufacturing domain (Chen, 2005). It advocates a functional
hierarchy to classify the activities performed in a manufacturing enterprise, as shown in Figure 4. Level
four of the functional hierarchy is concerned with business management, including the resource,
financial and supply chain management functions. Level three is named manufacturing operations
management and refers to the work flow control to produce the desired products (Chen, 2005). All
material processes are situated in level three of the hierarchy, as those are the processes that directly
contribute value to the product. Level three is therefore the focus and scope of this research. The
following four categories of manufacturing operations are included in level three of the functional
hierarchy (Chen, 2005):
• Production operations: the functions that convert raw materials, energy, and in-formation
into products, with the required quality, safety, and timeliness.
• Inventory operations: coordinates, directs, controls, and tracks inventory and material
movement within manufacturing operations.
• Maintenance operations: the functions that maintain the equipment and tools to ensure
their availability for manufacturing and ensure scheduling for periodic or preventive
maintenance.
• Quality operations: coordinates, directs, and tracks the functions that test materials and
equipment to measure and verify quality measures.
While these four categories provide a good overview of manufacturing operations, additional detail
is needed to identify the concepts necessary to create process models. Unfortunately, IEC 62264:2013
(IEC, 2013) does not provide additional detail and a single taxonomy of manufacturing operations does
not exist, because scholarly work tends to focus on a subset of operations. Therefore, a taxonomy of
manufacturing operations with definitions must be constructed from several sources, with good
representation as a goal, rather than absolute completeness.
Starting with ‘production operations’, the hierarchy of Groover (2011) is highly cited and detailed. This
taxonomy is structured according to the nature of the operations, with a first differentiation between
shaping and non-shaping operations. Shaping operations are then further subdivided between
operations that conserve the mass of materials, reduce the mass of materials, or join multiple parts
to form a new shape. Non-shaping production represents the type of operations that improve the
surface of the material or enhances the material properties, without altering its geometry. In pursuit
of good representation, the hierarchy of Groover (2011) is complemented with DIN 8580:2003-09 (NA
152-06-10 AA National Committee, 2003) and Todd (1994). The resulting production operations is
shown at the top of Figure 77.
Unfortunately, well documented and structured lists of inventory, maintenance and quality
operations prove to be rather elusive. Thus, several authoritative sources must be consulted to
complete the taxonomy of operations. The references sources were selected for clarity and
comprehensiveness. Every effort is made to consult as many sources as possible, but manufacturing
operations can be described in any number of ways, so the goal is to establish a single sensible and
practical list, rather than attempt to address contradictions and ambiguity in the literature.
108
Starting with inventory operations, Langford (2007) lists the following four logistics functions:
packaging, materials handling, warehousing and storage, and transportation. In comparison, Ghiani
et al. (2013) use the term internal logistics and define it as the activities carried out in the production
plants, consisting of the following: receiving and storing materials, collecting from the warehouse to
feed the production lines, moving the semi-finished goods up to packaging, and finally storing the
finished product. Packaging, handling, storage and transportation (PHS&T) is a grouping that is widely
adopted and used by logistics support engineers (Defense Acquisition University, 2011; INCOSE, 2015)
and compares favourably to the four functions of Langford (2007). Thus, these four activities will form
the first level of decomposition under inventory operations.
Maintenance and quality operations are often grouped together in literature. It may even be difficult
to determine whether an operation is considered a maintenance or quality operation. For example,
testing can be performed on equipment or the product. This differentiation is applied to separate the
two operation groups, as advocated by the category definitions of IEC 62264:2013 (IEC, 2013):
operations related to equipment are grouped under maintenance operations, while process and
product related operations are grouped under quality. Then, the Integrated Product Support Element
Guidebook (Defense Acquisition University, 2011) is queried to define the detail of those operations.
Maintenance is subdivided into modifications, corrective, and preventive maintenance. Quality
operations differentiates between process and product related operations. The resulting hierarchy of
manufacturing operations, showing the first three levels of decomposition, is shown in Figure 77.
109
Mass-conserving
shaping
Mass-reducing
Production shaping
operations
Assembly
Non-shaping
Packaging
Manufacturing operations
Handling
Inventory
operations
Storing
Transporting
Corrective
Maintenance
Preventive
operations
Modification
Process quality
Quality operations
Product quality
The next level of decomposition is again pieced together from several sources. For production
operations, two sources (Groover, 2011; NA 152-06-10 AA National Committee, 2003) provide
extensive detail, including descriptions and example processes. Table 14 lists the ten operation types
of production operations, each with a description and its source.
110
Assembly Permanent Form a joint between components that Groover, 2011
joining cannot be easily disconnected.
Mechanical Fasten two (or more) parts together in Groover, 2011
fastening a joint that can be disassembled if
needed.
Non-shaping Heat treatment The application of thermal energy to DIN 8580
enhance the properties of the work
material, without altering its shape or
mass.
Cleaning Processes that remove soils and Groover, 2011
contaminants that result from previous
processing or the factory environment.
Surface Application of a thin layer of material to Groover, 2011
coatings the exterior surface of the work part.
Surface Mechanical and physical operations Groover, 2011
treatments that alter the part surface in some way,
such as improving its finish or
impregnating it with atoms of a foreign
material to change its chemistry and
physical properties.
Predictably, inventory operations prove difficult to delineate as a taxonomy. Ray (2008) distinguishes
between three types of packaging: shop, bulk and shipping containers. Conversely, Groover (2011)
distinguishes between containers used to hold individual items and equipment used to make up unit
loads. For the purposes of manufacturing processes, those two categories are applied: placing a single
item in a container and placing multiple items in a container (unitizing). These two types of packaging
can be inversely applied for unpacking of containers.
Ray (2008) also extensively discusses manual and robotic handling. The following five handling
activities are identified: preparatory, feeding, positioning, manipulating and removing. Regarding
storage, two types can be distinguished based on the purpose: buffering is intended to synchronise
the flow of material between work centres that may have unequal throughput, while preservation is
intended to hold materials and products until needed (Defense Acquisition University, 2011).
For transport, Stock and Lambert (2001) identifies the following five modes: road, rail, air, water, and
pipeline. Their perspective was one of intra-company transport though, instead of inter-factory
transport. This breakdown is quite common for transport analysis or optimisation projects, such as
Davidsson et al. (2005). Similarly, the European Union distinguishes between six modes by
differentiating between sea and inland waterways. The United Nations has a similar approach and
differentiates between seven modes of transport: Maritime, rail, road, air, multi-model, fixed
installation and inland water transport (Centre for Trade Facilitation and Electronic Business, 2001).
Fixed installation transport in this case includes pipe and cable transport, such as for petroleum and
electrical power. For the second level of aggregation of transport, the equipment classification of Ray
(2008) is applied for the modes of transport. Road, rail, air and water are treated as vehicular
transport, while conveyors, pipelines, cables and cranes are part of the fixed installation category.
Table 15 shows the resulting operation types and descriptions for inventory operations.
111
Table 15: Operation types and descriptions of inventory operations.
Maintenance and quality operations are again treated together. A single authoritative source, the
INCOSE Systems Engineering Handbook (INCOSE, 2015) is used to define the lowest level of detail of
maintenance operations. Table 16 shows the operation types and descriptions for maintenance
operations. The source column is omitted because only one source is used for all maintenance
operations.
112
Preventive Servicing An activity which returns the capability of an asset that has
maintenance not failed to a level of performance equal to, or greater
than, that specified by its functions, but not greater than its
original maximum capability.
Scheduled A maintenance task to replace a component at a specified,
replacing pre-determined frequency, regardless of the condition of
the component at the time of its replacement.
Condition The use of specialist equipment to measure the condition of
monitoring equipment to assess whether it will fail during some future
period.
System Sustaining An activity which extends the expected life of an asset
modifications beyond its original expected useful life.
Upgrading An activity which enhances the capability of an asset beyond
its original maximum capability.
Table 17 shows the operation types and descriptions of quality operations. Again, the source column
is omitted, because all operation types and descriptions are based on the systems engineering
handbook (INCOSE, 2015).
113
represented with BPMN2.0. ISO9000:2015 (International Organization for Standardization, 2015)
defines a process as “a set of interrelated or interacting activities which transforms inputs into
outputs.” To give some structure to the decomposition, each operation type is described as inputs,
activities and outputs, based on the descriptions from the literature. Table 18 shows the results of the
decomposition for production operations. In the interest of consistency and clarity, the following two
terms are used to refer to inputs and outputs:
Table 18: Production operations decomposed into input, activity and output elements.
Each inventory operations can also be decomposed into input, transformation and output. Table 19
shows the results of this decomposition, making use of the same terminology as with production
operations.
114
Table 19 : Inventory operations decomposed into input, activity and output.
Notably, only packaging operations transform the inputs into a different output. All other inventory
operations involve activities that move, manipulate or hold items, without changing it in any way.
Furthermore, the five types of handling operations are collapsed into a single entry in Table 19,
because there was no discernible difference in terms of input, transformation and output.
Table 20: Maintenance operations decomposed into input, activity and output.
115
Upgrading Asset. Enhance the capability of an Asset with
asset beyond its original enhanced
maximum capability. capability.
Maintenance operations are difficult to describe in terms of input, transformation and output,
because of uncertainty regarding the activities involved. Most notably, the two modification
operations, sustaining and upgrading, can involve multiple activities, perhaps even performed by
multiple people. Comprehensive maintenance jobs may even be planned and managed as projects.
Nevertheless, the inputs and outputs can be inferred from the descriptions in Table 16 and the
transformation descriptions in Table 20 are not limited to single activities.
Lastly, quality operations are also decomposed and shown in Table 21. Predictably, the input and
output of each quality operation does not change, because these operations involve various
verifications, rather than transformation of materials or products.
Table 21: Quality operations decomposed into input, activity and output.
According to the BPMN2.0 standard (Object Management Group, 2014), a process is “depicted as a
graph of flow elements, which are a set of activities, events, gateways, and sequence flow that adhere
to a finite execution semantics.” The goal of this step of the research is to determine whether
manufacturing operations can be expressed as a combination of those four flow elements: activities,
events, gateways, and sequence flow. Based on the descriptions of manufacturing operations
presented in Table 18, Table 19, Table 20 and Table 21, all concepts can be represented as a flow
element. Therefore, it is concluded that BPMN2.0 is sufficiently complete for manufacturing
operations.
116
in the taxonomy, presented in Section 4.3, is modelled with BPMN2.0. This modelling effort results in
a set of manufacturing process model fragments, presented in Section 4.5.1. The set of fragments is
the practical contribution of this research as it can be used as a set of building blocks to model
manufacturing processes. The combination of several fragments to model a process is illustrated in
Section 4.5.2 and evaluated in Section 4.6.2. Notably, these process fragments are intended to give
the correct execution behaviour, in addition to accurate representation of the process for
understandability and communication purposes.
Forming
Material removal
117
Separating
Permanent joining
Mechanical fastening
Heat treatment
Cleaning
Surface coatings
Surface treatment
It can be argued that the permanent joining operation requires joining material, analogous to the
fragment for mechanical fastening. However, permanent joining is typically achieved with continuous
or standardised material, such as adhesive or welding gas. Conversely, mechanical fastening often
involves discrete parts, such as bolts and widgets. Thus, fastening material is shown as a distinct
inflow, whereas joining material is assumed to be present at the work station.
118
A similar assumption is made with all four non-shaping operations, i.e. heat treatment, cleaning,
surface coatings, surface treatment. These operations may require production consumables, such as
coating materials, but it is assumed that such consumables will be abundantly available at the place
of application. For example, coating operations are often performed by submerging a work piece in
the coating material. In such a case, it does not make sense to model the coating material as an inflow.
As a result, the four non-shaping operations can be represented with the same process model and are
therefore listed as a single entry in Table 22.
Individual packaging
Unitizing
119
Buffering
Preservation
Vehicular transporting
The process fragment for fixed installation transport is quite unique. It is the only fragment that
necessitates time passage on a connecter, instead of an activity or event. It is modelled this way,
because the transport operation is not assigned to, and therefore not performed by, an agent. For
example, a conveyor belt that transports parts from one point to another is not assigned a task to
perform the transportation. The belt simply rolls, carrying the parts with it. Time passage on a
connector is not supported by BPMN2.0. As such, it is considered a deficiency regarding the suitability
for manufacturing operations.
The third category of operations, namely maintenance operations, are modelled as business processes
and presented in Table 24. All seven maintenance operations can be modelled without difficulty,
albeit not without uncertainty. The uncertainty is due to the extensible nature of maintenance work,
especially work involving equipment modification. For example, the upgrading operation is modelled
as a single task in Table 24, but upgrading a piece of equipment may involve several tasks, perhaps
even performed by multiple people. Significant maintenance work is typically managed as a project,
subject to planning of the tasks to be performed. The process fragments presented in Table 24
represent single maintenance tasks that may be duplicated or combined for more significant
maintenance jobs.
Repairing
120
Replacing
Servicing
Scheduled replacing
Condition monitoring
Sustaining
Upgrading
Lastly, quality operations are also modelled as process fragments and presented in Table 25. The
seven quality operations can be conveniently grouped into process, equipment and product related
operations. These groupings allow us to use only three process fragments for quality operations.
Equipment calibration, inspection and testing can be modelled as a single fragment and the same can
be done for product inspection, measuring and testing.
121
Process measuring
Equipment calibration
Equipment inspection
Equipment testing
Product inspection
Product measuring
Product testing
Except for fixed installation transporting (see Table 23), all manufacturing operations can be
accurately represented with BPMN2.0. Thus far, the analysis is confined to individual manufacturing
tasks that must be used in conjunction to model real manufacturing processes.
122
The manufacturing process fragments can be used to model the sand-casting process using BPMN2.0.
The fragments are combined by stitching together the inflows and outflows according the process
description. Figure 79 shows a model of a sand-casting process, as a combination of manufacturing
process fragments with BPMN2.0.
Figure 79: Sand casting process of Groover (2016) modelled as a combination of model fragments.
The BPMN model shown in Figure 79 is certainly more complicated than the diagram shown in Figure
78, but it also less ambiguous. In Figure 78 it is not clear whether all inflows to the pouring activity
must be simultaneously active or only a single inflow can trigger the pouring activity. In Figure 79 this
relationship is clarified by an AND-gateway, clearly indicating that mould and core must be ready, and
the material must be melted, before pouring can commence.
A realistic manufacturing process can thus be accurately represented with BPMN2.0, as a combination
of model fragments. It can be concluded that BPMN2.0 is suitable to represent manufacturing
operations, but the execution suitability will be assessed as part of the evaluation, in Section 4.6.2.
4.6 Evaluation
This research is extensively evaluated to emphasise the practical relevance. To give some structure,
the evaluation is presented in three parts, corresponding to completeness, execution suitability and
comprehension suitability. Completeness is assessed by modelling the complete end-to-end
manufacturing processes of three factories, with the goal of identifying any operations that are not
included in the taxonomy of manufacturing operations. For execution suitability, lower level processes
of those factories are modelled and enacted, to demonstrate that the correct execution behaviour is
achieved. Lastly, comprehension suitability is gauged by assessing the ease with which typical users
understand the process models.
123
4.6.1 Completeness of the taxonomy of manufacturing operations and
corresponding process fragments
As a first safeguard, the completeness of the manufacturing operations taxonomy is evaluated at the
three factories that participate in the HORSE Project. The complete end-to-end processes of the
factories are considered as a set of manufacturing operations and matched to items in the taxonomy.
The manufacturing process models of the three factories are already shown as part of the practical
case analysis in Section 2.2 of Chapter 2.
Every activity in all three factories can be matched to an item in the taxonomy of manufacturing
operations. Although this evaluation does not prove completeness, it does improve confidence that
the taxonomy is complete enough for practical purposes.
Only the process model of case 3 (see Section 2.2.3 of Chapter 2) is included in this section, because
the remaining two cases are used for further evaluation in Chapter 7. Confidential names are replaced
by generic labels, but all other process details are shown as originally captured. Figure 80 shows the
model for the final inspection and packaging of wiper system assemblies process, with indications of
the different model fragments used to construct the model. Interestingly, this process requires
collaboration by an industrial robot and camera system, to perform the task labelled ‘visual
inspection’. Such low-level synchronisation can’t easily be controlled by a BPMS, because of slow
response times. This issue is further explored in Chapter 7, where the MPMS is complemented with a
control system dedicated to the synchronisation of agents. Evidence of the task execution is also
provided in Chapter 7, verifying the capability of the MPMS to drive execution of real manufacturing
processes. Nevertheless, this points to a general lower limit for the process management engine.
Actions that require sub-second synchronisation can’t reliably be controlled by a BPMS.
124
Multiple packaging
Handling
Handling
Product
quality
Product
quality
Handling
Handling
Figure 80: Model for the wiper system inspection and packaging process, comprised of multiple
process model fragments.
125
4.6.3 Comprehension suitability of the manufacturing process models
Apart from obtaining correct process behaviour, process models are also used as an enabler of
understanding and communicating. For this purpose, it is important that the model not only
accurately represents the process, but that the model is also comprehensible for the intended
audience. In the case of manufacturing operations processes, the intended audience is any party that
is involved with process improvement or equipment installation. Notably, process participants are not
necessarily considered as part of the intended audience, because factory workers will often undergo
on-the-job training or at least perform tasks without detailed knowledge of the process model.
Process models are not necessarily used as instruction or training material. Therefore, it is pertinent
to evaluate the comprehension of people involved in process improvement and equipment
installation, to determine whether a business process model is an accurate and understandable
representation of a manufacturing process.
Prat et al. (2014) recommends eight criteria for the evaluation of models: self-reported competence,
completeness, simplicity, clarity, style, homomorphism (fidelity of a model to modelled phenomena),
level of detail, and consistency. Completeness is treated comprehensively in this chapter (see sections
4.4 and 4.6.1) and style is not important for a suitability assessment. The physics of notation
advocated by Moody (2009) is intended to help creation of new notations, but it can also be used to
evaluate an existing notation (Polderdijk et al., 2017). More importantly, Moody (2009) also provides
clear descriptions of the criteria, helping to create a questionnaire. Table 26 shows the mapping of
criteria of Prat et al. (2014) and Moody (2009), with descriptions.
Table 26: Mapping of Prat et al. (2014) and Moody (2009) criteria.
A form with ten questions and space for comments was from the descriptions in Table 26. The form
was completed by 18 respondents from 11 different organisations. All 18 respondents were involved
in the modelling of executable manufacturing processes. The 11 organisations included four
manufacturing companies, four universities and three research organisations.
126
Figure 81: Results of homomorphism related questions.
Figure 81 shows overwhelmingly positive results for homomorphism. The four questions assess the
fidelity of a model to a modelled phenomenon and are directly based on the criteria advocated by
Moody (2009). Similarly, Figure 82 shows highly positive results regarding model understandability.
Fifteen respondents also added comments when completing the questionnaire. The comments
reflected the general enthusiasm of the respondents, but a few cautionary entries were also recorded.
In the interest of brevity, only a summary of the comments is discussed here. One respondent
remarked that it's easy to create business models but difficult to create executable models, while
another respondent appreciates the power of subprocesses to limit the number of elements on a
diagram. Three respondents mentioned that BPMN is easy to learn, but also complained about a lack
of good learning material. Two respondents found it difficult to distinguish manufacturing tasks from
each other, because the same symbol is used for any task. It is especially difficult to see which tasks
are performed by humans or machines.
Most notably, three respondents found it difficult to relate to the notation, due to a lack of
manufacturing specific symbols. They commented that the following concepts can’t easily be
represented with BPMN: buffers, queues and flow of material. Although those concepts can be
captured in a roundabout way, such techniques are not intuitive.
127
4.7 Findings
The comments from the respondents in the comprehension suitability evaluation (Section 4.6.3) raise
a few interesting topics. The mentioned notation deficiencies contradict the findings of the suitability
assessment (see Section 4.5). The flow of physical material was found lacking in the suitability
assessment (see the fixed installation transporting operation in Table 23), but the other two
deficiencies (buffers and queues) were not identified. In fact, the buffering operation fragment in
Table 23 explicitly makes use of the concept of queuing to release material according to a
predetermined condition. Thus, the difference between the manufacturing process fragments and the
experience of the respondents strengthens the argument that the notation is not intuitive for
manufacturing processes. While all concepts can be represented with BPMN, some process fragments
are rather obscure and difficult to understand.
The comment regarding the development of executable models is also worth discussing. It is quite
clearly more difficult to create executable models, considering the need to control the activities of
humans, robots and machines. However, the expressiveness of BPMN helps with the complexity of
manufacturing processes. For example, the repetitive nature of some manufacturing activities can be
modelled as multi-instances, as is done for the multiple packaging operation, shown in Table 23.
This approach to the modelling of manufacturing operations allows extensive flexibility and design
freedom. All activities shown on a single view of the process do not have to represent similar levels of
detail. For example, the “removal of sand mould” and “transport to storage area” activities shown in
Figure 79 may represent different magnitudes of work. “Removal of sand mould” may have a
complicated subprocess, while the transport activity is a singular action. This freedom makes it
possible to use multiple instances at different levels of process aggregation to accurately capture the
repetitive nature of certain manufacturing activities.
The use of business process management in manufacturing operations will not replace current
practices. Detailed scheduling and resource management will remain as important and expedient for
the foreseeable future. The prospect is rather to add an additional perspective that can be used to
view and manage the activities of the manufacturing system, independent of the location where those
activities happen and who/what is involved in those activities. The additional perspective is
contemplated in anticipation of the continued increase of complexity in factories (Ugarte et al., 2009).
The suitability assessment is divided into two parts: 1) Determining whether manufacturing
operations contain concepts that can’t be represented by the elements that BPMN2.0 is comprised
of, and 2) Showing that manufacturing operations can be accurately represented as executable
business process models, using BPMN2.0. Both assessments, corresponding to completeness and
suitability as advocated by Hommes and Reijswoud (2000), rely on a notion of all manufacturing
128
operations. This notion is addressed by creating a taxonomy of manufacturing operations from various
scholarly sources. The taxonomy itself is also evaluated for completeness, by checking the end-to-end
manufacturing processes of three commercial factories. As such, the taxonomy of manufacturing
operations is a contribution in its own right. A single list of manufacturing operations, with
accompanying descriptions, can act as a frame of reference for further research endeavours.
The more substantial contribution and second purpose of this chapter is the set of manufacturing
process fragments, presented in section 4.5. These fragments can be used as building blocks to create
executable process models. This capacity is demonstrated by modelling and enacting the processes of
real-world manufacturing enterprises. This modelling effort also serves as completeness assessment,
because no operations were identified that did not match an item in the taxonomy of manufacturing
operations.
In conclusion, BPMN was found to be at least partially suitable for manufacturing operations. The only
definitive deficiency identified is related to the flow of material. More specifically, it is related to the
time it takes for material to flow. If some physical items must flow from one location to another,
between two manufacturing operations, BPMN is incapable of representing the time that elapses for
the material to move. Apart from that definitive deficiency, some respondents of the evaluation
questionnaire found the notation unintuitive for manufacturing processes, due to a lack of specific
manufacturing symbols. The author of this thesis did not experience the same difficulty and concede
that this discrepancy may well be due to a difference in familiarity.
As a suitability assessment, this work is positioned as a stepping stone towards more research and
practical implementation. The current assessment is limited to manufacturing operations, thus
excluding other production types, such as continuous production. The same methodology can be
performed for other domains related to manufacturing. More interestingly, the set of model
fragments can be implemented as a dictionary of operations in a process modelling tool to help users
design manufacturing process models.
129
Chapter 5
5. DEFINITION OF MANUFACTURING RESOURCES
A new class of industrial robots is emerging. These robots can sense their environments, adapt to a
changing situation and perform a variety of tasks as needed. Several vendors already offer versatile
robots, such as the Motoman HP20 that can perform any of the following operations with the
appropriate end effector attached: Arc welding, assembly, cutting, dispensing, machine tending, part
transfer, pressing, forming, material removal, picking and packing. As expected, scientific research is
not lagging, with proposals for multi-limbed robots (Bandyopadhyay et al., 2018), path finding (Semini
et al., 2015), extensible end-effectors (Homberg et al., 2015) or even a modular structure (Rus et al.,
2002) to improve the versatility of industrial robots. Furthermore, large international projects such as
EUSmart and PIROS, both part of the Horizon 2020 programme of the European Commission,
investigate complete work cells with versatile robotics (EuRoC, 2018).
These new robots are not alone though. Humans are still prevalent on the factory floor and our
numbers are not necessarily dwindling. The advent of wearable and augmented reality technologies
can even enhance the already considerable capabilities of operators (Longo et al., 2017). Thus, it is
not uncommon for a factory to be populated by an assortment of humans and versatile robots,
possibly from multiple vendors. As the manufacturing activities adapt to changing customer
expectations and new technological opportunities, the link between the activities and resources
(human and automated workers) inevitably loosens. With enough change, or even entirely new
activities, it becomes difficult to determine which resource, or set of resources, is best suited for the
activity. This difficulty is driven to the extreme when the manufacturing system must also respond to
fluctuating demand or produce a high mixture of products. The activities to be performed simply
change too fast for traditional production planning and work allocation.
It has been shown that improved resource allocation can lead to improved process performance
(Macris et al., 2008). More specifically, it is suggested that resource characteristics can be used for
advanced resource allocation (Vanderfeesten and Grefen, 2015). Although the potential benefit of
more advanced resource allocation based on resource characteristics is generally accepted (Mejía and
Montoya, 2010; Shen et al., 2003), guidance on the specification of resource characteristics is lacking.
This chapter addresses this deficiency in the form of a step-by-step method to specify resource
attributes. These attributes can then be used to select resources for activities, based on the
requirements of the activity. Figure 83 shows the extension, from basic resource allocation based on
role, to a more advanced mechanism making use of attributes in addition to role. Instead of selecting
any resource with a certain role, additional information is queried to select a specific resource with
that role.
130
Basic resource allocation Advanced resource allocation
This chapter is dedicated to the definition of resources and activities, for the purpose of resource
allocation. Afterwards, Chapter 6 ventures into the resource allocation mechanism itself, showing how
the definitions are used to select resources for tasks.
Most contemporary BPMSs only consider availability and organizational information (such as role,
department or position) of the resource during resource allocation (Russell et al., 2005). Even well-
established allocation principles, such as separation of duties and case handling, are not widely
supported (Russell et al., 2005). Researchers have identified the need and benefit of more intelligent
allocation based on more detailed and complementary resource information (Mejía and Montoya,
2010; Shen et al., 2003), but only few studies elaborate on this. Resource allocation essentially consists
of two parts: (1) design-time description of resources and activities such that it is possible to
131
determine which resource can perform an activity, and (2) the mechanism that makes use of the
descriptions to allocate resources to activities during process run-time (Zeng and Zhao, 2005). This
chapter is concerned with the first part (description of resources), while Chapter 6 presents a
mechanism to allocate resources to activities.
In addition to the standard organizational information (position, role, etc.), some manual techniques
are used to describe resources, in terms of preferences (Cabanillas et al., 2013) and job experience
(Kabicher-Fuchs and Rinderle-Ma, 2012). Similarly, approaches to describe task requirements (Ouyang
et al., 2010) and constraints (Senkul and Toroslu, 2005) are also proposed. Kumar et al. (2013) present
a model to capture compatibilities between resources to improve collaboration between resources in
the same workflow. Oberweis and Schuster (2010) present a detailed meta-model for the description
of resources and their competence, skills and knowledge. While all these studies present compelling
arguments to extend resource description, the content of competence, skills, knowledge, etc. is left
completely to the user to define. Cabanillas et al. (2012) provide a domain specific language called
Resource Assignment Language as a complement to BPMN2.0. This language improves the
expressiveness of resource description, enabling more advanced resource allocation, but the content
is again left entirely open.
To overcome the lack of guidance on resource description, several researchers turn to process mining
to discover information about tasks and resources. Liu et al. (2008) show how an event log of manual
assignment can be used to semi-automate subsequent assignment. Arias et al. (2016) extends the
concept to allocate a resource to a block of interrelated activities. Huang et al. (2012) show how to
measure resource behaviour in terms of four perspectives, i.e., preference, availability, competence
and cooperation, based on process mining. The results of those measurements can then be used to
improve resource allocation. Pika et al. (2017) expands the allocation criteria by extracting
information about the skills, utilization, preferences, productivity, and collaboration patterns of
resources from process event logs. Though process mining is used effectively, these studies are still
focused on how to retrieve information, instead of what information to retrieve.
More recently, Arias et al. (2017) offer a holistic overview of criteria that can be used in human
resource allocation. Their taxonomy distinguishes between nine factors, including role and expertise.
Although these factors are identified, the taxonomy provides no guidance on how it should be used
to describe resources. For example, expertise is defined to include resource capabilities,
competences, skills, and knowledge, but those sub-factors are not further elaborated. In fact, clear
guidance on the specification of resources and tasks is strikingly absent throughout the literature. The
research presented in this paper provides exactly such guidance in the form of a method to specify
the abilities possessed by resources and required to perform activities.
132
with distinct names and a range of possible values. The method presented in this chapter includes
such a dictionary and gives guidance on how to use it to define resources and activities.
Chapter 5
Chapter 6
Agents are resources with goals, regardless of the source of those goals. Thus, an agent (such as a
human, robot or autonomous guided vehicle) may be given goals, in the form of tasks instance
assignments. The goal is to complete the task instance, by performing the work specified in the work
item instance. A task instance may require multiple agents to collaborate though, forming a coalition
or team. In this research, the coalition is treated as temporary and only exists for the duration of the
task. A task instance may also require an agent to use an object, such as a spanner or drilling machine.
Therefore, multiple resources, both agents and objects, may be required to perform a single task
instance.
The definition of agent also helps to establish the definition of task. A task instance is a set of actions
assigned to an agent or coalition of agents. Consequently, the scope of a task instance is determined
133
by the agent or agents it can be assigned to. If two sequential activities must be performed by the
same agent or coalition, those activities may be part of a single task, if no other factors cause
separation.
A short note on automated agents should be mentioned. As this research is specifically interested in
the allocation of versatile agents, “robot” will be used to represent the type of automated agents that
should be defined for allocation. Robot, in this sense, refers to automation technologies comprised of
the following (Nof, 1999; Rus et al., 2002; Heyer, 2010):
• Computing hardware and software actuators and sensors with at least three joints, usually
with three or more degrees of freedom, allowing movement in two- or three-dimensional
space.
• Autonomy with some degree of intelligence for decision making, as set by the necessary
degree of human intervention.
• Adaptability for changes in circumstances in the operating environment. Although
autonomy is still fairly limited now, robots will perform increasingly well in unstructured
environments.
• The possibility to be reconfigured, usually when the robot is not in operation, for a new task
or environment.
• The ability to cooperate with humans is increasingly important, as is cooperation with other
machines (including other robots).
Figure 84 also shows the content of Chapters 5 and 6. The current chapter is concerned with the
creation of resource definitions and activity definitions. Most attention will be given to agent
definitions and task definitions, because ultimately agents are assigned to tasks. However, the agent
definitions will contain information on the use of objects. This chapter therefore presents a method
to define agents and tasks, to enable allocation of agents to task instances. This method consists of a
step-by-step guide and, more importantly, agent and task models that helps the user to determine
information to specify and how to specify that information. The agent and task models are
constructed from scientific literature and evaluated in practice.
134
is also the only such study that can be found at the time of submitting this thesis. The taxonomy is the
result of a recent systematic literature review of resource allocation in business process management.
The taxonomy consists of 27 resource allocation criteria, with 23 criteria grouped into five categories
and four ungrouped criteria. Figure 85 shows the taxonomy proposed by (Arias et al., 2017).
Figure 85: Proposed taxonomy of human resource allocation criteria of Arias et al. (2017).
The Arias et al. (2017) also provides a description, from the assessed literature, for each criterium in
the taxonomy of human resource allocation. Although the taxonomy is not infallible, it is at least
recent, and it is the only such study that could be found. Given the comprehensive results, it seems
illogical to repeat the work in a new literature study. The 27 criteria and their descriptions are used as
the starting point for a set of human attributes.
The increased demand for mass customised products leads to a manufacturing system that must
rapidly adjust and adapt to changing customer expectations. Consequently, the set of activities will
change rapidly, enforcing the need for looser coupling between agents and tasks. Agent attributes
should be defined independently of task requirements, as much as is reasonable. It shouldn’t be
necessary to update agent attributes every time the set of activities are changed. Table 27 shows the
analysis of the remaining nineteen criteria of the Arias et al. (2017) taxonomy, with the goal of
determining which criteria are too task specific.
135
Table 27: Analysis of the criteria for human resource allocation of Arias et al. (2017) to determine
which criteria can be considered task specific.
136
Social position Resources form various social communities and No.
take different social positions while participating
in business processes.
Workload Availability An existing resource is available, busy or not No.
available.
Occupancy Consider the actual idle level of a resource. No.
consider how a resource is occupied executing
activities.
Workload The capacity of resources to perform specific No.
activities is constrained.
Work Schedule Refers to different types of work schedules (e.g., No.
shift plan, part time or full time).
It is not necessarily the ambition of this thesis to provide guidance for all the criteria identified in the
taxonomy of Arias et al. (2017). Instead, the objective is to create a method that helps a user define
the attributes possessed by agents and required by tasks. More importantly, the method guides the
user to define agent attributes without any consideration of tasks that the agent might perform. With
that in mind, four of the criteria can be considered too task specific: amount, trustworthiness, quality
and WF execution history. WF execution history is a valuable source of resource performance
information, but it only gives information on the execution of specific tasks. These four criteria are
therefore declared out of scope for the method to define agents and tasks, presented in Section 5.7.
Research regarding the capacity of humans to perform work is available though. These studies are
related to the expertise category of the Arias et al. (2017) taxonomy. The expertise category contains
five criteria: Cognitive attributes, expertise, functional attributes, non-functional attributes, and work
variety. Thus, the expertise category contains a criterium also named expertise. This expertise
criterium is then defined as “resource capabilities, competences, skills, and knowledge.” This
definition does precious little to clarify the criterium and, more concerningly, refers to four wildly
different concepts in the definition.
Skills are specific personal attributes that are largely dependent on learning and represent the product
of training in particular tasks, i.e. they are practiced acts (Koschmider et al., 2011). Competences refer
to combinations of knowledge, skills, abilities and other characteristics that are needed for effective
performance in a wide range of jobs (Boyatzis, 1983; Campion et al., 2011). The starting point for
developing competence models usually lies in the organizational goals and job outcomes, rather than
the specific tasks to be carried out. Knowledge, in the context of performing work, is the awareness
of or familiarity with something (Nerland and Karseth, 2015), making it specific to a subject or task.
Capability is difficult to define, because it simply refers to the ability to do something. Ability is better
defined in industrial psychology, as an enduring attribute of an individual’s capability to perform a
range of different tasks (Carroll, 1993; Fleishman, 1982). For example, whereas ‘written expression’ is
137
an example of an ability, associated skills could be proficiency in LaTeX functionalities or using in-text
citations.
Abilities are more general than skills and knowledge, but more focused on the actual tasks than
competences. Thus, a single set of abilities may be applicable to various activities or even different
industries. Skills and knowledge are highly context specific and practically unlimited in number,
impeding their universal applicability. Conversely, competences are not specific enough to support
selection of resources for specific tasks. Additionally, abilities have the benefit that they exhibit
stability over time, with only gradual improvement with exposure to development stimuli (Snow and
Lohman, 1984).
Various theories and taxonomies are used to describe abilities, mostly related to the cognitive area of
human performance (Cattell and Horn, 1978; Guilford, 1956; Spearman, 1927; Thurstone, 1938). The
Taxonomy of Human Abilities of Fleishman (Fleishman, 1975) stands out, as the most comprehensive
taxonomy and its validity is established in various studies (Fleishman and Mumford, 1991). It consists
of 52 abilities in four categories: cognitive (21), psychomotor (10), physical (9) and sensory (12)
abilities. Cognitive abilities represent the general intellectual capacity of a person. Psychomotor
abilities combine cognitive and physical traits dealing with issues of coordination, dexterity and
reaction time. Physical abilities focus solely on the muscular traits of a person. Lastly, sensory abilities
are the physical functions of vision, hearing, touch, taste, smell and kinesthetic feedback (noticing
changes in body position) (Fleishman and Reilly, 1992). Figure 86 shows the 52 human abilities
grouped in the four categories. The list of abilities and their descriptions is included in Appendix B.
138
Human abilities
Figure 86: Extract of the taxonomy of human abilities (Fleishman, 1975), showing selected abilities
in each of the four categories.
The Taxonomy of Human Abilities is accompanied by a tool to determine the ability requirements of
various jobs. The Fleishman Job Analysis Survey (F-JAS) guides experts to determine whether an ability
is necessary for a job, how important an ability is for a the job, and on what level the ability is required
(Fleishman and Reilly, 1995). This can be done for each of the 52 abilities present in the Taxonomy of
Human Abilities.
Figure 87 is an extract of F-JAS, showing the scale for a single ability chosen at random (i.e. the written
comprehension scale as one of the 21 cognitive abilities). The specific ability and its description are
shown at the top, followed by two scales: one to measure the importance of the ability (A) and the
other to measure the required level of an ability (B). The importance of an ability is measured on a 5-
point Likert scale. By comparing an applicants’ abilities with the importance of a required ability, a
recruiter can determine whether the applicant is suitable for a job. The level follows a 7-point Likert
scale to indicate to what extent a certain ability must be possessed by an individual. Reference anchors
are provided to help the user determine the required level. The full F-JAS is available in Appendix C.
139
Figure 87: Measurement scale for one of abilities of the taxonomy of human abilities, extracted
from (Fleishman and Reilly, 1995).
The taxonomy and accompanying rating scale are widely used in human performance studies (Kanfer
and Ackerman, 1989; Stajkovic and Luthans, 1998) and it is the foundation of the Occupational
Information Network (O*NET), the primary job description database of the United States (Peterson et
al., 1999). The reliability and validity of the measurement scales and anchors are confirmed through
several studies (Fleishman and Mumford, 1991). In this thesis, the use of the taxonomy and rating
scale is used as part of the method to define agent and tasks. While this is not its original intention, it
is indeed designed to describe humans in relation to work.
Table 28: Self-determined expressions for the remaining 22 human attributes. Author is unable to
determine how to express five of the attributes, leaving 17 human attributes.
140
Functional Resource behaviour characteristics Unknown.
attributes (e.g., adaptability).
Non-functional Other attributes that may influence Unknown.
attributes the performance of the resources
(e.g., environmental factors and
technical aids).
Work variety Analyses similar and dissimilar tasks List of tasks
done by a resource in a day. performed during
current operating
cycle.
Previous Cost Evaluates cost attributes such as A monetary unit per
performance resource total cost. time unit.
Feedback Resources give their feedback to Boolean, to accept or
accept or refuse the work done by refuse.
other resources.
Reputation Evaluates resource social standing Unknown.
within a resource network based on
previous performance.
Time Evaluates time attributes such as Estimated duration to
execution time. complete a task.
Role Authorizations Constraints regarding to a specific Special allowances,
person or role to allocate, and such as licenses or
authorization privileges. certificates.
Location Resources has attributes to describe Location in the
its location and the structure of facility.
activities that it can perform in a
workflow.
Organizational Constraints regarding to a specific Identifier of a
position organizational position. position in the
organisation
structure.
Responsibilities Set of responsibilities on a resource List of
to perform specific activities. responsibilities.
Social Collaboration Measures resource collaboration and Boolean, whether the
context cooperation. agent can collaborate
with other agents.
Compatibility Measures resource compatibility. List of objects that
the agent can interact
with.
Influence Degree of the influence that a Unknown.
resource has on some other
resources.
Social position Resources form various social Unknown.
communities and take different social
positions while participating in
business processes.
Workload Availability An existing resource is available, busy Resource status.
or not available.
141
Occupancy Consider the actual idle level of a Ratio of busy to idle
resource. consider how a resource is time.
occupied executing activities.
Workload The capacity of resources to perform List of tasks in queue.
specific activities is constrained.
Work Schedule Refers to different types of work Duration that the
schedules (e.g., shift plan, part time agent is available.
or full time).
The author is unable to determine how the following five attributes can be used to determine whether
an agent can perform a task: functional attributes, non-functional attributes, reputation, influence
and social position. Those five attributes have no guidance one the type or format of information that
should be captured for that human attribute. The five attributes will therefore be eliminated from
further consideration. Nevertheless, seventeen of the remaining 22 attributes can be comprehended
and interpreted from the descriptions provided in the taxonomy. These seventeen attributes will be
considered for inclusion in the method to define agents and tasks for dynamic agent allocation.
Which attributes can be used to select an industrial robot to perform a manufacturing task?
142
Robot And (Select* OR compar* OR Choose* OR chos* OR 1746 1905
rank*)
Robot And (Select* OR compar* OR Choose* OR chos* OR 21 174
Rank*) AND (criteri* OR attribute*)
Robot And (Select* OR compar* OR Choose* OR chos* OR 145 503
Rank*) AND (criteri* OR attribute* OR Specification* OR
Requirement* OR characteristic* OR Feature*)
Naturally, the final search term yielded many scholarly articles that could not be included for further
investigation. The list of 648 articles was further abridged according to the following steps, as shown
in Figure 88:
1. Remove research published 15 years before the SLR was conducted (i.e. before 2003). Given
the rapid pace of robot technology development, 15 years is considered enough time to get
a good representation of robot attributes.
2. Articles for which the full-text could not be accessed.
3. Duplicates between the two databases.
4. Relevance check: Based on the research title and abstract, removing items that are judged
to be irrelevant to the research.
143
Search term
ScienceDirect Scopus
Remove papers
145 papers
503 Paper retrieved published before or
Retrieved
in 2003
Remove papers
published before or Remove papers
in 2003 where more than 2
terms between
Robot and Select-
123 papers Term
95 papers remaining
remaining
Remove dublicates
147 paper
remaining
Remove papers that
are certainly not
relevant for this
research based on
title
Longlist of 84 Google Scholar
articles
Remove papers that
are not relevant for
this research based
on titleon title
and abstract
Shortlist of 40 Snowballing . 1
articles paper found
Shortlist of 41
articles
The snowballing action shown at towards the bottom of Figure 88 can be thought of as an insurance
policy. The reference list of all articles in the shortlist are checked for any relevant research.
144
Additionally, citations of the articles in the shortlist are also checked for relevance. Fortunately, this
snowballing only revealed one additional article that was added to the shortlist.
Ultimately, the SLR yielded 203 unique attributes. The full list of attributes is presented in Appendix
D, showing the number of times an attribute was found in the literature. Attribute definitions and
sources of definitions are also provided, if available.
1. Part twelve of Handbook of Industrial Robotics (Ceroni and Nof, 1999) is consulted to find
attribute definitions.
2. Three experts in the field of industrial robots, who collaborated in the HORSE Project, are
consulted to define attributes that are not defined in the original literature.
3. The same three experts are consulted to improve poor definitions.
Part twelve of Handbook of Industrial Robotics (Ceroni and Nof, 1999) provides definitions of many
terms commonly used with regard to industrial robotics. Table 30 shows the six attribute definitions
that could be retrieved from the handbook.
Table 30: Six robot attribute definitions retrieved from the Handbook of Industrial Robotics
(Ceroni and Nof, 1999).
Attribute Definition
Autonomy The capability of an entity to create and control the execution of its own plans
and/or strategies. For instance, in mobile robots the ability of the robot for
determining the trajectory to reach a specific location or pose.
Manipulator Mechanism, usually consisting of a series of segments, or links, jointed or sliding
relative to one another, for grasping and moving objects, usually in several
degrees of freedom. It is remotely controlled by a human (manual manipulator)
or a computer (programmable manipulator). The term refers mainly to the
mechanical aspect of a robot.
Man-machine Same as user interface. The interface between the robot and the operator
interface through devices such as a teach pendant or PC. It provides the operator with
the means to create programs, jog the robot, teach positions, and diagnose
problems.
Path A part of the mechanical construction of each axis which provides the position
Measuring coordinate for the axis. Typically, for translational axes, potentiometers or
Systems ultrasound are used for path measuring systems. But for rotational axes,
resolvers, absolute optical encoders, or incremental encoders are used. A path
measuring system may be located directly on a robot axis or included with the
drive system.
Precision A general concept reflecting the robot’s accuracy, repeatability, and resolution.
Resolution The smallest incremental motion which can be produced by the manipulator.
Serves as one indication of the manipulator accuracy. Three factors determine
the resolution: mechanical resolution, control resolution, and programming
resolution.
145
121 attributes remain undefined, after the six definitions from the Handbook of Industrial Robotics
(Ceroni and Nof, 1999) are counted. These 121 attributes were presented to three robotics experts
who collaborated in the HORSE Project. Unfortunately, only twelve more attributes could be properly
defined by these experts. Table 31 shows the twelve new attribute definitions.
Table 31: Twelve robot attributes newly defined in consultation with robotics experts.
Many attribute definitions from original literature are vague and ambiguous. The author of this thesis
took the opportunity to improve and clarify these definitions with the robotics experts. Table 32 shows
the ten attribute definitions from original literature that were improved.
Table 32: Ten attribute definitions from original literature improved in consultation with robotics
experts.
146
Overload Maximum capacity that the robot Load capacity beyond the
capacity of the can lift. recommended specification.
robot
Power How much power does the robot Amount of electric energy consumed
Consumption use during operation.
Programming while programming flexibility refers Programming flexibility refers to a
Flexibility to a robot’s ability to accept robot’s ability to accept different
different programming codes. programming codes.
Recommended Recommended humidity around Range of humidity within which the
Operating the robot. robot functions as expected.
Humidity
Velocity Is used as Maximum Tip Speed in 1. Maximum movement speed of the end
effector.
Table 33 shows the results of the attribute definition improvement exercise. 90 attributes now have
definitions and 113 remain undefined.
Attributes Number of
attributes
Attributes with definitions from original source 72
Definitions added from the Handbook of Industrial Robotics. 6
Definitions added by experts 12
Defined attributes 90
1. If an attribute is a duplicate of another attribute. For instance, connection type is exactly the
same as mounting position.
2. If an attribute is a subset of another attribute and the excluded attribute is unnecessarily
precise for task allocation. For instance, AC power consumption is a subset of power
consumption.
3. If an attribute is a superset of another attribute and the excluded attribute is unnecessarily
abstract for resource allocation. For instance, external state sensors include slip and tactile
sensors, but it states nothing about the function of the external state sensors.
4. If an attribute is too abstract to use for resource allocation. For instance, usage of robot is
too general and can’t conceivably be used to select a robot for a task.
5. If an attribute is a component attribute of a robot, rather than an output attribute of the
robot. Resource allocation is concerned with the function and performance of a robot, not
with the way it is constructed or what it consists of.
The five steps are performed with all 203 original attributes, whether defined or not. This is to ensure
that attributes aren’t eliminated prematurely. Table 34 shows the number of excluded attributes for
147
each of the criteria. In total, 106 attributes are excluded, resulting in 75 remaining attributes.
Appendix E lists the complete set of 106 attributes with the criteria applied to each.
Unfortunately, 24 attributes still could not be defined, and their meanings can’t be inferred from the
name alone. The following attributes are therefore excluded from further consideration:
73 robot attributes remain and are defined. Table 35 provides a quick overview of the attributes
eliminated up to this point in the analysis.
148
Table 35: Overview of attribute elimination because of consistency check and undefined
attributes.
The 73 remaining robot attributes are shown in Table 36. These attributes are either defined or the
meaning can be inferred from the attribute name. These 73 attributes will be used in the next step of
the analysis.
Table 36: Remaining 73 robot attributes that are either defined or the meaning can be inferred
from the attribute name.
149
Force Output Amount of force a robot can generate.
Horizontal Reach Reach of the robot of the horizontal axis.
Implementation easiness
Internal state sensors The ability of the robot to detect the current status of its internal
operation.
Joint Orientations
Joint Sequence
Learning
Life expectancy Duration which the robot is expected to maintain full performance.
Load Capacity Load capacity is the maximum load that a manipulator can carry
without affecting its performance.
Maintenance Costs Cost for maintaining the robot
Man-machine interface Same as user interface. The interface between the robot and the
operator through devices such as a teach pendant or PC. It provides
the operator with the means to create programs, jog the robot, teach
positions, and diagnose problems.
Material Of robot What material does the outer surface of the robot consist of.
Maximum Tip Speed Maximum tip speed is the speed at which a robot can move in an
inertial reference frame.
Means used for rotary to
linear motion conversion
Memory Capacity Memory capacity of a robot is measured in terms of number of points
or steps that it can store in its memory while traversing along a
predefined path.
Mounting Position Mounting position represents the ability of a robot to fasten it
securely on a given surface during the working cycle,
Noise Delivery The maximum noise output of the robot during runtime.
Number of end effectors Number of tips that the robot can use to manipulate something.
Number of in and output
channels of the controller
Operation Costs Total cost of running the robot.
Operation Time Duration of continual operation without required rest.
Overload capacity of the Load capacity beyond the recommended specification.
robot
Path Measuring Systems A part of the mechanical construction of each axis which provides the
position coordinate for the axis. Typically, for translational axes,
potentiometers or ultrasound are used for path measuring systems.
But for rotational axes, resolvers, absolute optical encoders, or
incremental encoders are used. A path measuring system may be
located directly on a robot axis or included with the drive system.
Power Consumption Amount of electric energy consumed during operation.
Power Source Type of power delivery that the robot needs.
Requirement
Processor
RAM
Recommended Operating Range of humidity within which the robot functions as expected.
Humidity
Reliability Such as reliability can be expressed by Mean Time Between Failure
(MTBF) or Mean Time To Repair (MTTR)
150
Repeatability Repeatability is the measure of the ability of a robot to return to the
same position and orientation over and over again.
Resolution The smallest incremental motion which can be produced by the
manipulator. Serves as one indication of the manipulator accuracy.
Three factors determine the resolution: mechanical resolution,
control resolution, and programming resolution.
Rest Time Time required by the robot to reset between operations.
ROM
Sensing Range Distance to recognise a predefined shape, image or event.
Service
Simplicity
Slip Sensors Any slip sensors that the robot might have.
Space Requirements Space needed for the robot to be able to function correctly.
Stability This is the measure of absence of oscillations at termination of arm
movement.
Tactile Sensors Any tactile sensors that the robot might have.
Terrain Traversability Terrain over which the robot can traverse.
Training Delivery Period Delivery time of the training
Type of Cables used
Type of Control System The type of control system that the robot has.
Type of end effectors Type of end effectors used.
Type of flexible drive
system used
Type of Joints Type of joints that the robot has.
Type of memory
Type of Robot
Vendor's Service Vendor’s service quality refers to the level and variety of services
(Contract) offered by a robot vendor.
Vendor's training
Versions of robot
Installations
Vertical reach Vertical reach of the robot
Warranty
Weight of the Robot
Wrist reach distance Maximum distance in which the end effector of the robot arm
reaches in the work envelop
151
1. Consider one of the manufacturing operations. It is important to make sure that the
operation and corresponding actions are known and understood. Its description is used,
complemented by any literature used in the development of the taxonomy of
manufacturing operations.
2. Answer the following two questions for each of the 73 attributes:
a. Is this attribute of any importance to determine whether a robot can execute the
task?
b. Can the attribute be used to determine which of two robots can perform a task
better?
If both questions are answered with a ‘no’, the attribute is marked as not applicable
for that manufacturing operation.
3. Repeat step one and two for all remaining manufacturing operations.
An example is discussed to make the procedure more relatable. Consider a hypothetical assembly
operation. Three metal parts are permanently attached to form a product. Two attributes are
deliberated to display the two possible results. Firstly, the material of robot attribute: it is difficult to
conceive of any way that this attribute is important for the assembly operation. It is therefore marked
as not applicable for the operation under consideration. The second attribute, precision, is clearly
important for an assembly operation, considering the precise movements that may be required to
attach parts to each other. Therefore, this attribute is marked as applicable for the manufacturing
operation under consideration.
The procedure is performed for all 73 attributes for each item in the taxonomy of manufacturing
operations. The analysis results in 34 attributes that are used for at least one operation, while the
remaining 39 attributes are never used. Table 37 shows the excluded attributes with their
corresponding definitions.
Table 37: 39 robot attributes and corresponding definitions excluded as a result of the comparison
to manufacturing operations.
Attribute Description
Communication Bandwidth Range of bandwidth on which the robot can communicate
Communication Range Range of the communication system of the robot
Computational Capacity Capacity of the robot to make calculations.
Convenience of use How easy to use?
Convertibility (design for How easy to change robot for different functionalities
functionality changes)
Customization product How customized the robot can be delivered
delivery
Delivery Time Delivery Time of the robot
Dexterity The ability to change position and orientation of the end
effector, between two different configurations of the robotic
structure.
Drive Systems Electric/Hydraulic
Implementation easiness How easy to implement the robot
Internal state sensors The ability of the robot to detect the current status of its
internal operation.
152
Attribute Description
Joint Orientations Joints
Joint Sequence Joints
Learning Ability of the robot to learn from previous activity execution.
Life expectancy Expected Life range
Maintainability/regular Ease and cost of maintenance.
maintenance
Man-machine interface Same as user interface. The interface between the robot and the
operator through devices such as a teach pendant or PC. It
provides the operator with the means to create programs, jog
the robot, teach positions, and diagnose problems.
Means used for rotary to Joints
linear motion conversion
Memory Capacity Memory capacity of a robot is measured in terms of number of
points or steps that it can store in its memory while traversing
along a predefined path.
Number of in and output Controller
channels of the controller
Path Measuring Systems A part of the mechanical construction of each axis which
provides the position coordinate for the axis. Typically, for
translational axes, potentiometers or ultrasound are used for
path measuring systems. But for rotational axes, resolvers,
absolute optical encoders, or incremental encoders are used. A
path measuring system may be located directly on a robot axis
or included with the drive system.
Power Source Requirement The type of energy consumed by the robot.
Processor Processor
RAM RAM
ROM ROM
Service Service provided by producer
Simplicity How easy is the robot
Training Delivery Period Delivery time of the training
Type of Cables used Types Of Cables
Type of Control System Control System
Type of flexible drive system Drive system used
used
Type of Joints Which Type of Joints used
Type of memory Type of memory used
Type of Robot Robot Type
Vendor's Service (Contract) Vendor’s service quality refers to the level and variety of
services offered by a robot vendor
Vendor's training Training from producer
Versions of robot Installations Version of software
Warranty Warranty Period
Weight of the Robot Weight of the Robot
153
Thus, a unit of measurement or similar descriptor is needed for the attributes to be defined clearly
and consistently.
For most attributes, the unit of measurement is obvious, widely adopted, or perhaps even formally
standardised, e.g. noise delivery is measured in decibel (dB). However, two of the 34 attributes are
particularly interesting in this respect. The first attribute, autonomy, denotes the level of
independence of an agent to perform activities. Humans have full autonomy, because we have
motivations, but robot or machine autonomy is not as easily measured. Beer, Fisk and Rogers (2014)
propose a framework for levels of robot autonomy, ranging from manual to full autonomy. The
framework is shown in Appendix G and is used as the unit of measurement for the autonomy attribute.
The second attribute, degree of protection, denotes the fortification of sensitive parts against ingress
of foreign objects and water. The International Electrotechnical Commission (2001) recommends
using the IP-codes (Ingress Protection codes) to describe degree of protection. The code is composed
of IP followed by two integers corresponding to predefined object sizes and water force. The tables
for IP-code are shown in Appendix F.
The final list of robot attributes is thus complete. A total of 34 attributes are included in the list as
shown in Table 38, each with a definition and a unit of measurement.
Table 38: Final list of 34 robot attributes, with descriptions and units of measurement.
154
Load capacity Load capacity is the maximum load that a manipulator can kg
carry without affecting its performance.
Material of robot What material does the outer surface of the robot consist List of
of. materials
Maximum tip Maximum tip speed is the speed at which a robot can mm/sec
speed move in an inertial reference frame.
Mounting Mounting position represents the ability of a robot to List of
position fasten it securely on a given surface during the working surfaces
cycle,
Noise delivery The maximum noise output of the robot during runtime. dB
Number of end Number of tips that the robot can use to manipulate Integer
effectors something.
Operation cost Total cost of running the robot. Monetary
unit per time
unit.
Operation time Duration of continual operation without required rest. seconds
Overload capacity Load capacity beyond the recommended specification. kg
of the robot
Power Amount of electric energy consumed during operation. kWh
consumption
Recommended Range of humidity within which the robot functions as Range (%)
operating expected.
humidity
Reliability Such as reliability can be expressed by Mean Time MTTF/MTTR
Between Failure (MTBF) or Mean Time To Repair (MTTR)
Repeatability Repeatability is the measure of the ability of a robot to mm
return to the same position and orientation over and over
again.
Resolution The smallest incremental motion which can be produced mm
by the manipulator. Serves as one indication of the
manipulator accuracy. Three factors determine the
resolution: mechanical resolution, control resolution, and
programming resolution.
Rest time Time required by the robot to reset between operations. seconds
Sensing range Distance to recognise a predefined shape, image or event. mm
Slip sensors Any slip sensors that the robot might have. Yes/No
Space Space needed for the robot to be able to function mm3
requirements correctly.
Stability This is the measure of absence of oscillations at mm
termination of arm movement.
Tactile Sensors Any tactile sensors that the robot might have. Yes/No
Terrain Terrain over which the robot can traverse. List of terrain
traversability
Type of end Type of end effectors used by the robot. List of end
effectors effectors
Vertical reach Vertical reach of the robot. mm
Wrist reach Maximum distance in which the end effector of the robot mm
distance arm reaches in the work envelope.
155
5.4.3 Common agent attributes
The two sets of attributes must be merged to establish a single set of attributes that can be used to
describe any agent in a manufacturing process, whether human or automated. The human attribute
analysis yielded 17 attributes, as discussed in Section 5.4.1.3 and the robot attribute analysis yielded
34 attributes, as discussed in Section 5.4.2.5. The two sets will invariably contain overlapping and
conflicting items.
The larger list of 34 robot attributes is used as the master list to compare the 17 human attributes.
The comparison yields nine overlapping attributes. Table 39 lists the nine overlapping robot attributes
and the comparable human attributes.
Table 39: List of robot ten attributes that are comparable to human attributes and a decision of
whether to keep the human or robot attribute.
Of the 34 robot attributes, ten were found to be comparable to human attributes. Seven of those
ten are comparable to abilities included in the Taxonomy of Human Abilities (Fleishman, 1975). In
the final set of agent attributes, the corresponding human abilities will be kept, rather than the
robot attributes, to keep the Fleishman taxonomy consistent and complete. For the remaining three
robot attributes that can be compared to human attributes, namely operation cost, operation time
and type of end effectors, the robot attribute will be kept, because it has a definition.
156
As a quick note, the names of the cost and time attributes are found to be too abstract. Cost can refer
to many different types of cost, such as operating cost, acquisition cost, maintenance cost, etc. For
the purposes of resource allocation, the cost of assigning the agent is important. Therefore, the
attribute is renamed to operating cost. A similar action is performed for the time attribute. Table 41
shows the two name changes.
Table 41: Two attribute names changed to better reflect their nature.
Some of the attribute definitions are also rather unwieldy. These definitions are improved, based on
the author’s understanding of the attributes, to better reflect the purpose of agent allocation. Table
42 shows the eleven improved attribute definitions.
Table 42: Attribute definition improvements to make more sense as attributes for agent
allocation.
157
Workload The capacity of resources to List of tasks in the agent’s queue.
perform specific activities is
constrained.
Finally, the complete list of agent attributes can be compiled. The agent attributes are grouped to
make the set more digestible. The functional and non-functional attributes from the original Arias et
al. (2017) taxonomy are repurposed as attribute categories. Table 43 shows the final list of 41 agent
attributes that can be used to define agents for allocation to tasks.
Table 43: Final list of 41 agent attributes for resource allocation, in alphabetical order.
158
Number of Number of tips that the agent can use to Integer
end effectors manipulate something.
Overload Load capacity beyond the recommended kg
capacity of the specification.
robot
Reliability Such as reliability can be expressed by MTTF/MTTR
Mean Time Between Failure (MTBF) or
Mean Time to Repair (MTTR).
Repeatability Repeatability is the measure of the mm
ability of an agent to return to the same
position and orientation over and over
again.
Rest time Time required by the robot to reset seconds
between operations.
Slip sensors Any slip sensors that the agent might Yes/No
have.
Tactile Sensors Any tactile sensors that the agent might Yes/No
have.
Terrain Terrain over which the agent can List of terrain
traversability traverse.
Type of end Type of end effectors used. List of end
effectors effectors
Vertical reach Vertical reach of the agent. Mm
Wrist reach Maximum distance in which the end Mm
distance effector of the agent reaches in the
work envelope.
Location Current location in the facility or locations that the agent List of locations
has access to.
Non-functional Ambient Range of temperature within which the Range (⁰C)
attributes temperature agent functions as expected.
Environmental Impact that the agent has on its CO2/Day
impact environment during operation.
Material of What material does the outer surface of List of materials
robot the agent consist of.
Mounting Mounting position represents the ability List of surfaces
position of an agent to fasten securely on a given
surface during the working cycle.
Noise delivery The maximum noise output of the agent dB
during runtime.
Operation cost Total cost of running the agent. Monetary unit
per time unit.
Operation Duration of continual operation without seconds
time required rest.
Power Amount of electric energy consumed kWh
consumption during operation.
Recommended Range of humidity within which the Range (%)
operating agent functions as expected.
humidity
Space Space needed for the agent to be able to mm3
requirements function correctly.
159
Occupancy Ratio of busy to idle time. Ratio
Organizational The position in the organisation structure held by the Position name.
position agent.
Preference Resource preference for executing certain types of List of task
activities. types that the
agent prefers.
Responsibilities Set of responsibilities on a resource to perform specific List of
activities. responsibilities.
Work schedule Duration that the agent is still available for future tasks. Seconds
Work variety List of tasks performed during current operating cycle. List of tasks.
Workload List of tasks in the agent’s queue. List of tasks.
Table 44: Twelve agent attributes that can't be expressed as task requirements, with reasons
given.
With twelve attributes eliminated, 29 attributes remain that can be used to specify task
requirements. Table 45 lists the 29 attributes and updated definitions to reflect their use as task
requirement attributes.
160
Table 45: List of 29 attributes that can be used to specify task requirements.
161
Environmental Maximum allowed impact that the agent CO2/Day
impact may have on its environment during
task execution.
Material of The material that the outer surface of List of materials
robot the agent must consist of to perform the
task.
Mounting The required ability of an agent to List of surfaces
position fasten securely on a given surface during
the working cycle.
Noise delivery The maximum noise output allowed of dB
the agent during runtime.
Operation Estimated task duration seconds
time
Power Maximum amount of electric energy kWh
consumption that may be consumed during
operation.
Recommended Range of humidity within which the Range (%)
operating agent must function to perform the
humidity task.
Space Space available for the agent to perform mm3
requirements the task.
Organizational The position in the organisation structure that must be Position name.
position held by the agent.
Responsibilities Set of responsibilities that an agent must have to perform List of
the task. responsibilities.
Activities are combined to produce a product or set of products. As such, the nature of the product to
be produced may have implications on the activities. These implications are typically encoded in the
production order and product requirements. In small batch or discrete manufacturing systems these
implications are even more important, due to the potential variation between subsequent production
runs.
In BPM terminology, a single instance of a process is called a case. Thus, any additional requirements
imposed by the production order or product itself can be thought of as case requirements. As with
task requirements, production orders and products are too diverse to define a uniform set of
attributes that can be used to specify case requirements. It is therefore advisable to specify case
requirements in terms of agent attributes, where possible. For example, the product mass may differ
wildly for two production runs. The difference in mass can be expressed as a requirement to lift, carry
or manipulate a certain mass, instead of simply specifying the product mass. This is only applicable to
case requirements used for task allocation. Clearly, the production order and product requirements
will contain additional information that is not necessary for task allocation.
162
The lists of agent and task attributes are certainly comprehensive but can never claim absolute
completeness. All manufacturing systems and processes are unique, to some extent, and may require
additional attributes to be defined. Similarly, some of the attributes may not be necessary to
accurately represent the agents and tasks in a specific factory. The agent and task attributes are,
therefore, extensible. In fact, it is encouraged that the lists are tailored to make them more
representative and perhaps reduce the effort involved in agent and task definition.
The author of this thesis decided to tailor the lists of attributes to fit the rest of the research better.
The attributes are used as part of the method to define agents and tasks, discussed in Section 5.7.
Furthermore, the output generated by the method is used in the agent allocation algorithm presented
in Chapter 6. Therefore, the agent and task definitions created when performing the method should
be compatible with the resource allocation mechanism they are intended for. The following steps are
taken to reduce the effort involved in agent and task definition:
163
Noise delivery
Number of end effectors
Operation cost
Operation time
Organizational position
Overload capacity of the robot
Preference
Power consumption
Recommended operating humidity
Reliability
Repeatability
Responsibilities
Rest time
Slip sensors
Space requirements
Tactile Sensors
Terrain traversability
Type of end effectors
Vertical reach
Wrist reach distance
Operating cost
6 35
The significance of the different time-scales is indicative of when the attribute values are determined
for a particular agent, and more importantly, how much effort can be spent defining those attributes.
It is easier to justify the effort involved in the definition of attributes that remain stable over time and
change infrequently. Conversely, attributes that change frequently should be easy to define or, ideally,
automatically captured by devices or information systems.
This comparative analysis does not disqualify any of the attributes, but rather eludes to the subset of
attributes that should be included in the method to define agents and tasks. As the method requires
significant effort, only the stable attributes (the grouping labelled ‘infrequently’ in Table 46) are
included. The six attributes that require frequent updates should be captured automatically and are,
therefore, not included in the forms to define agents and tasks, included in Appendices H and I,
respectively. For example, the current location of an agent can be tracked and recorded in real time,
using global positioning or radio frequency systems.
• Collaboration
• Experience
• Feedback
• Compliance
• Overload capacity of the robot
164
• Reliability
• Repeatability
• Slip sensors
• Tactile Sensors
• Material of robot
• Noise delivery
• Power consumption
• Organizational position
• Preference
• Responsibilities
With these fifteen attributes removed, the remaining 36 attributes are featured in the forms to define
agents and tasks. The forms are included in Appendices H and I.
Two of the attributes are also changed slightly, to better reflect the method to define agents and
tasks. Location is renamed to tenancy, to allow the user to specify all the locations that the agent has
access to. The current location of an agent should be tracked automatically, if possible. Secondly,
environmental impact is changed to air pollution, to clarify the attribute’s meaning.
165
Agent
Performed for each Performed for each Agent-related
data table
agent available for run- attribute possessed by data tables
time allocation an agent
Start End
T1: Identify T3: Determine
task(s) which T2: Describe the the required
require task value for each
allocation attribute
Performed for each Performed for each Task-related
task that requires run- attribute required to data tables
Task time allocation perform the task
data table
Figure 89: Depiction of the method to specify tasks and agents in terms of attributes.
In the interest of clarity, the following nomenclature is used purposefully: steps, tasks, user and agent.
The method is comprised of steps performed by the user. The output of the method are specifications
of tasks and agents.
Step A1: Identify agent(s) for task allocation. Not all resources in an organization will benefit from
run-time task allocation. Only resources that can perform various tasks should be designated for
specification. Such resources are invariably agents, following the distinction between agents and
objects presented in section 5.3, because tasks can only be assigned to agents. Selecting an agent
implies that the user must be able to determine which attributes are possessed by the agent. Given
the variety of human competences and industrial technologies, specification of agents may require
different experts.
Step A2: Describe the agent. For each agent designated for allocation in step A1, the user completes
section 1 of the agent specification form (see Appendix H). The user provides additional information
regarding the agent, including agent type, the enterprise that employs or utilises the agent, and a
short textual description of the agent.
Step A3: Specify the attributes of the agent. The user completes section 2 of the agent specification
form (see Appendix H). This step requires substantial effort and knowledge of the agent under
consideration. Counsel from someone with such knowledge is recommended if not possessed by the
user.
166
Step T1: Identify task(s) which require allocation. Not all tasks will benefit from run-time allocation.
For example, a small factory with a single stamping machine will always allocate stamping tasks to
current shift worker operating that machine. However, some tasks may be ad-hoc or the product
variability may require frequent changeover of agents. During identification, the user needs good
understanding of the tasks.
Selecting a task implies that the user must be able to determine which attributes are required to
perform the task. This can be particularly problematic if task variations exist in an enterprise. It is
essential that the user can identify and scope a task such that its required attributes can be specified
for all conditions.
Step T2: Describe the task. For each task designated for allocation in step T1, the user completes
section 1 of the task specification form agent specification form (see Appendix I). The user provides
additional information regarding the task, including task type, a short textual description, and the
process and enterprise that the task is part of.
Step T3: Determine required abilities level. The user completes section 2 of the task specification
form (see Appendix I). The form provides extensive guidance on the specification of requirements,
but the user still needs extensive knowledge of the task to express its requirements in terms of agent
attributes.
Intermediate tables are used for both the agent and task definitions. Intermediate tables ensure
that the same set of attributes are used to define agents and tasks, thus enabling direct comparison
of agent definitions to task requirements.
167
Figure 90: Data tables used to store agent attribute information for allocation.
As with the agent information, task information should be available to the MPMS. Figure 91 shows
the database schema for task requirements.
Figure 91: Data tables used to store task requirement information for resource allocation.
168
The definition of resources and tasks represent two system modules of the MPMS presented in
Figure 74. Both resource definition and task definition modules are part of the definition tools
subsystem, shown on the left of Figure 74. These modules are realised by implementing the agent
definition and task definition forms (Appendices H and I, respectively) in electronic forms. These
forms contain the same information as the forms shown in Appendices H and I, but the information
captured by the user is immediately stored or updated in the MPMS database.
5.9 Evaluation
The method to define agents and tasks is intended for use in a manufacturing enterprise. As such, the
evaluation will embrace practical utilisation of the method. The method was performed by people not
involved in the research, to define agents and tasks. This approach gave detailed insight into the
usefulness and ease-of-use of the method.
As this is a substantial amount of work, the method is performed by only six participants from four
different enterprises. Two of the participants are manufacturing personnel from TRI (one of the
practical cases discussed in Chapter 2). Three participants are researchers in the field of robotics. The
last participant is from a manufacturing company unrelated to the HORSE Project.
The researcher used the forms presented in appendices H and I to guide the practitioners through the
definition of agents and tasks, respectively. Once completed, the practitioner was interviewed to
gauge the effectiveness, ease of use, usefulness and intention to use of the method. The interview
was structured according to the Method Evaluation Model (Moody, 2003) and the sixteen questions
were also rated by the practitioner. Table 47 shows the questions asked during the interview to gauge
the practitioner’s acceptance of the method.
Table 47: Questions used to structure the interview and gauge the practitioner’s acceptance of the
method.
Actual efficiency:
How long (in minutes) did it take to fill in the form?
Actual effectiveness: Agree Disagree
I think the set of attributes adequately describe the 5 4 3 2 1
agent attributes for the purposes of task allocation.
169
Perceived usefulness: Agree Disagree
I believe that this method would reduce the effort 5 4 3 2 1
required to describe an agent.
Agent attributes represented using this method would 5 4 3 2 1
be more difficult for users to understand.
This method would make it easier for users to determine 5 4 3 2 1
whether an agent can perform a task.
Overall, I found the method to be useful. 5 4 3 2 1
Comments:
The values provided by the participants can be found in Appendix J for agent definition and
Appendix K for task definition. These appendices summarise the responses and the complete forms,
as completed and signed by the participants, can be requested from the author of this dissertation.
Figure 92 shows a chart of the evaluation ratings provided by the participants. It should be noted
that the set of statements contained both positive and negative statements. Therefore, a negative
statement should rate low (towards 1), while a positive statement should rate high (towards 5).
Although the sample size is small, the results still indicate a general positive view of the method.
170
Figure 92: Results of the method evaluation, based on responses from 11 participants.
The evaluation participants were highly enthusiastic about the method and associated agent and task
attributes, even though it requires considerable effort. The participants appreciated the richness of
the set of attributes and the ability to describe any agent or task with the same set of attributes.
However, most of the participants expressed difficulty with some of the attributes, in relation to
certain agents or tasks. This is especially true for the human abilities in relation to automated agents.
The following attributes were highlighted as causing difficulty:
This difficulty isn’t entirely surprising. The human abilities are obviously more relatable to humans,
but it was more the scope of the robot that caused concern. The participants found it difficult to
consider a robot, its control system and any peripheral sensors as one agent. The author of this
research is confident that this difficult will subside with repeated execution of the method.
A similar observation can be made for the task definition, although to a lesser extent. The participants
found it helpful to state the task requirements, when approached from the point of view of a human
171
performing the task. The non-functional attributes proved more problematic for task definition. The
participants found it difficult to state the requirements for operating time, configuration duration, air
pollution and operating humidity. In many cases the participant simply didn’t know the requirement
related to these attributes.
The method to define agents and tasks only has three steps each for agents and tasks, but still
represents substantial work to perform. This was abundantly clear from the interviews performed
during the evaluation, with interviews ranging from 45 minutes to two hours. It is unlikely that a
company will spend as much effort to create definitions for a multitude of agents and tasks, given the
lack of truly versatile, commercial industrial robotics. Nevertheless, the method represents a
significant stride towards clear guidance on the definition of resources and tasks. The potential benefit
of more advanced resource allocation based on resource characteristics is generally accepted (Mejía
and Montoya, 2010; Shen et al., 2003), but the method presented in this chapter is the first
comprehensive guidance on the definition of resource characteristics and task requirements.
Ultimately, the method serves as a template for further elaboration. Vendors of process
management software can elect to build some or all of the attributes into their software systems,
perhaps leading to a competitive advantage. Alternatively, manufacturing enterprises can use the
method as a starting point and tailor it according to their needs. It is certainly not a strict
requirement that all the attributes must always be used, promoting the possibility to adapt it to
specific needs. It is with this spirit that the agent and task attributes will be used as input into the
agent allocation algorithm presented in chapter 6.
172
Chapter 6
6. DYNAMIC AGENT ALLOCATION
This chapter presents a mechanism to allocate agents to tasks, using the output of the method
presented in Chapter 5. The mechanism takes the form of a dynamic agent allocation algorithm,
because this thesis is dedicated to the investigation of fast-changing manufacturing processes, as
discussed in Chapter 1. Dynamic allocation is a class of resource allocation in which the assignment of
the resources to tasks may need to be continuously adjusted in response to changes in the
environment or system performance, such as changes in number of tasks or status of resources
(Lerman et al., 2006). The agent attributes and task requirements produced by the method of Chapter
5 are equally applicable to agent allocation during process design or production planning, but
allocation during process run-time is demonstrated here, as the most responsive alternative.
The dynamic agent allocation algorithm is the artefact presented in this chapter, as it contains
prescriptive knowledge on how to use agent attributes and task requirements to enable allocation of
agents to tasks. The artefact presented in this chapter is not given a special name, but is rather
referred to as ‘the dynamic agent allocation algorithm’, because it is not the only solution to the
problem of dynamic allocation. Numerous changes can be made to the algorithm presented here, or
perhaps even complete alternatives can be developed. However, the prescriptive knowledge on the
use of the attributes and requirements remain applicable.
The prescriptive knowledge is also implemented into an operational algorithm, to make the allocation
mechanism more relatable by showing how the the agent attributes and task requirements are used.
As proof of concept, the operational algorithm is demonstrated with utilisation in two of the practical
cases discussed in Section 2.2. As the operational algorithm makes no claim regarding optimality, the
following criterium will be used to claim successful demonstration: An agent is allocated to every task
that is designated for agent allocation.
It is important to note the different purposes of Sections 6.3 and 6.4, compared to Section 6.5 i.e. the
algorithm design and implementation sections. Sections 6.3 and 6.4 gives guidance on the
development of an algorithm that utilises the agent attributes and task requirements presented in
Chapter 5. The discussion is purposefully general, to allow any number of different implementations.
In design science research terminology (see Section 1.6), this is prescriptive knowledge on the design
173
of an algorithm. In contrast, Section 6.5 is descriptive, as it elaborates on the specific implementation
of the agent allocation algorithm.
The research presented in this thesis is concerned with manufacturing processes populated by both
humans and machines (specifically versatile machines, i.e. robots). As with the definition of resources,
allocation of humans and robots represent largely exclusive fields of research. These two fields are
therefore briefly investigated.
The research presented in this thesis is more interested in run-time allocation of resources, as the
problem domain is set to dynamic manufacturing processes. Allocation of resources during process
run-time is the most responsive allocation approach and therefore more appropriate to this research.
Although the expected benefit of more sophisticated allocation mechanisms is acknowledged (Macris
et al., 2008), current approaches remain basic, because they only consider general organizational
information, such as the role, position or business unit of a resource (Zur Muehlen, 2004). This proves
problematic, because significant variation can be found between resources in the same role, position
or business unit (Kumar et al., 2002). Such mechanisms are espoused under various names, including
resource allocation (Cabanillas et al., 2013), actor assignment (Illibauer et al., 2015) or role resolution
(Zeng and Zhao, 2005). To find some common ground amongst the various approaches, some
categorisations have been proposed. Zur Muehlen (2004) distinguishes between push and pull
resource allocation patterns. Push occurs when the system compels a resource to start working on a
174
work item, while pull occurs when a resource requests a work item from the system. The Russell et al.
(2005) catalogue of resource management patterns recognizes four categories of allocation patterns:
push, pull, detour and auto-start patterns.
Although the potential benefit of more advanced resource allocation based on resource
characteristics is generally accepted (Mejía and Montoya, 2010; Shen et al., 2003), current approaches
consider only limited characteristics. The mechanism in this chapter goes beyond current approaches
by combining the following three characteristics:
1. It utilises the large number of agent attributes and task requirements generated by the
method presented in Chapter 5,
2. It is a run-time allocation mechanism that follows the push pattern of the Russell et al.
(2005), to gain maximum responsiveness in the manufacturing processes. With a pull
pattern it may be unclear when an agent will perform the task.
3. It composes coalitions of humans and robots, as inspired by the coalition formation work of
Shehory and Kraus (1998).
Figure 93: Taxonomy of task allocation in multi-robot systems (Gerkey and Matarić, 2004b).
The first criterium is task type, which covers the number of robots required to execute the tasks within
the process. When all tasks require exactly one robot, task type will be single robot (SR), but when at
least one task within the process requires multiple robots, the task type is multi robot (MR). The
second criterium is the robot type, which covers the number of tasks that the robots within the
process can execute simultaneously. When all robots can execute at most one task at a time, the robot
type will be single-task (ST). Otherwise, when at least one robot is capable to execute multiple tasks
at the same time, the robot type is multi-task (MT). The third criterium is the allocation type, which
covers how often the tasks will be allocated to the robots. The allocation type is Instantaneous
175
assignment (IA) when the available information of the system allows only one assignment, without
any planning for future assignments. When such information is available, for instance the arrival of
tasks over time, the allocation type is time-extended (TA).
Although the taxonomy is widely-adopted (cited 1224 times), Gerkey and Matarić (2004) acknowledge
that their taxonomy is not complete, since it does not capture problems with interrelated utilities and
task constraints. Korsah et al. (2013) agree and contend that the most important constraints missing
are the precedence constraints, which may specify that one task must be performed before another.
Korsah et al. (2013) introduce a degree of interdependence to the taxonomy, and rename it iTax. They
also use the iTax taxonomy to investigate and classify the most prominent robot allocation techniques.
Figure 94: The fourth dimension of the ITax, introduced by Korsah et al. (2013) as an enhancement
of the taxonomy of (Gerkey and Matarić, 2004b).
In iTax, four degrees of dependencies are differentiated, as can be seen in Figure 94. These degrees
are defined as the following:
A key enabling technology of smart manufacturing is collaborative robotics (Heyer, 2010). These
robots can perform activities near human workers without the need for physical separators (Johnson
et al., 2014). Even more enticing is the prospect of true collaboration, where the robot can perform
the activity in conjunction with the human, leveraging the physical prowess of the machine and the
cognitive abilities of humans. As such, it is necessary for the dynamic allocation algorithm to form
coalitions, or temporary teams, of agents and assign such a coalition to a task.
Furthermore, the dynamic allocation algorithm is part of the process enactment subsystem of the
MPMS (see Figure 74 in Chapter 3). The MPMS instantiates tasks according to the logic encoded in
the process model. As tasks are instantiated, the agent allocation module uses the task requirements
and agent attributes to find an agent (or coalition of agents) that can perform the task. Thus, the
MPMS design has direct implications for the agent allocation algorithm. These implications can be
codified according to the iTax taxonomy of Korsah et al. (2013), as shown in Table 48.
176
Table 48: Classification of the agent allocation algorithm, derived from features of the MPMS
architecture.
The algorithm presented in this chapter can therefore be classified as XD [ST-MR-IA], as per the iTax
taxonomy of Korsah et al. (2013). Unfortunately, Gerkey and Matarić (2004) contend that any ST-MR-
IA problem is strictly NP-hard and therefore optimality can’t be proven. As a result, no current XD [ST-
MR-IA] are available that can be adopted in this research. At any rate, it is not the objective of this
research to develop an optimal solution, but rather to provide knowledge on the development of an
agent allocation algorithm that uses the agent attributes and task requirements presented in Chapter
5.
To compensate, single-robot approaches (ST-SR-IA) are investigated to see what can be gleaned from
them. The M+ system of Botelho and Alami (1999) uses a market system in which each robot that is
not yet selected as best candidate for another task makes an offer on the task. The robot with the
best offer will be the “best candidate”. The robot will be in the best candidate state until the robot
starts on the task or when another robot has made a better offer for that particular task. After that,
the robot will return to the so-called evaluation state, in which the robot is able to send offers for
tasks. The system deals with dependency by showing only the executable tasks, of which the
antecedents have been achieved. However, the M+-system does not show how to decide in which
order the executable tasks will be offered to the robots.
Lemaire et al. (2004) proposes an approach in which simple ordering constraints between tasks are
used. One of the tasks is offered to a robot, which makes this robot the “master”. This task determines
the start time of the other connected tasks. The robots that get those other tasks assigned will be the
“slave” robot, which means that this robot will follow every change that the master robot will make
for this task sequence.
MacKenzie (2013) proposes a variant of the market-based approach. Several tasks are made available
and the agents submit bids with cost expressed as a function of constrained variables such as location
and time. After submitting all bids, the auctioneer uses a cost minimization algorithm to determine
the allocations of tasks to the agents and the values of the constrained variables. The limitation of this
approach is that it only supports instantaneous assignment.
As for mechanisms that do not use a market-based approach. Chien et al. (2000) offer a solution to
the robot routing problem corresponding to a scenario in which a team of robots must perform a set
177
of activities (one robot per activity). Cross-schedule constraints between the robots are considered to
find the optimal assignment arrangement. Mosteo et al. (2008) consider routing problems while
assuming that the mobile robots have a limited communication range. In this approach, the schedule
of an individual robot is coupled with other resources in such a way that ensures connectivity for
communication.
Of those five approaches investigated here, three are based on auctioning techniques (Botelho and
Alami (1999), Lemaire et al. (2004) and MacKenzie (2013)) and two are concerned with routing
problems (Chien et al. (2000) and Mosteo et al. (2008)). Unfortunately, none of those approaches are
relevant to type of allocation mechanism discussed in this chapter, but the guidance of the iTax
taxonomy will invariably be valuable.
The process view is concerned with the concurrency and synchronization of the system modules.
Consequently, the agent allocation module is described in terms of the steps it must take to fulfil its
purpose. The purpose of agent allocation is to select and assign an agent or coalition of agents to
perform a task in a manufacturing process. For the remainder of this explanation, coalition will be
used to refer to the assignee, even if the coalition contains only one agent. The algorithm uses the
output generated by the method presented in Section 5.7. The method includes 78 attributes that can
be used to define agent attributes and task requirements.
The attributes are not entirely homogenous though, as two groups can be identified: 1) attributes
indicating whether a coalition can perform a task and, 2) attributes indicating how well a coalition can
perform a task. These two groups of attributes will be referred to as eligibility and performance
attributes, respectively. For example, a task may require an agent to possess the authorization to work
with hazardous chemicals, clearly indicating that authorization is an eligibility criterium. Conversely,
an agent with a high workload (a large number of tasks in queue) is still eligible to perform a task, but
may take longer to complete the task compared to an equivalent agent with a lower workload.
The dynamic allocation algorithm performs allocation in seven steps, two of which correspond to
using the eligibility and performance attributes. The following seven steps are executed by the
algorithm:
1. Identification information of the relevant task, process and case instances is passed from
the process engine to the dynamic allocation algorithm, to allow retrieval of the correct
requirements.
178
2. Relevant data are retrieved from the data stores. This includes the full list of agent
definitions with their attributes, and task, process and case definitions related to the
identifiers received in step 1.
3. The list of agents is pre-filtered to minimise the number of potential coalitions that can be
composed. The attributes considered in the pre-filtering are discussed in Section 6.3.2.
4. All potential coalitions are composed by creating all combinations of all the agents that
remain after step 3. Coalition composition also entails combining the attributes of coalition
members, as discussed in Section 6.3.3.
5. Each potential coalition is checked for eligibility, based on the combined attributes of the
coalition members.
6. All eligible coalitions are compared to each other, in the context of the task requirements
and process objectives, and a single coalition is selected.
7. Identification information of all members of the selected coalition are returned to the
process engine so that the work item instance(s) can be sent to the selected agents.
The first step is performed by the process engine module of the MPMS. The remaining six steps are
performed by six sub-modules of the agent allocation module. Figure 95 shows a UML sequence
diagram with the process engine and six agent allocation sub-modules, with interactions between
them. The diagram shows the sequence of steps performed by the logical system sub-modules of the
agent allocation module of the MPMS. Please note that these sub-modules are situated at aggregation
level 3 of the MPMS architecture. The process engine module is also shown to elucidate the
interaction between the process engine and agent allocation modules.
The process engine module of the MPMS passes task and case identifiers to the agent allocation
module. The data query sub-module uses the identifiers to retrieve task, case, process and agent
information from the data stores of the MPMS. The agent pre-filter sub-module lists all candidate
agents. The coalition formulation sub-module uses the agent information to form all potential
coalitions from the candidate agents. The eligibility check sub-module then compares the attributes
of the coalitions to task and case requirements to eliminate all ineligible coalitions. The eligible
coalitions are then compared to each other, in the context of the process objectives, to find the best
coalition. Identifiers of the selected coalition members are then passed back to the process engine to
complete the allocation.
179
Five of the seven sub-modules shown in Figure 95 are briefly discussed to give more insight into their
purpose and behaviour. The process engine and assignment functions are not further discussed,
because these functions represent integration with the MPMS. Integration with the MPMS is
discussed in Chapter 7.
Table 49: Guidance on the retrieval of data and storage in containers that can be used by the
algorithm.
180
The location attribute has been split into two separate attributes, namely location and tenancy. This
change is made to cater for portable agents, such as humans, vehicles and mobile robots. It is
necessary to know the current location of an agent and the locations that agent has access to. For
example, a certain operator may be assigned to work cell 1-1 for the current shift, but he or she may
assist throughout production line 1. Thus, the current location and accessible locations of an agent
are captured in two attributes, namely location and tenancy, respectively.
The attributes used to specify task requirements are discussed in Section 5.5. During process run-time,
task requirements consist of the task and case definitions. Any attribute included in the case definition
simply overwrites the same attribute in the task definition. For example, a task may require an agent
to have a horizontal reach of 30cm to handle the product. However, a case might require a reach of
50cm, because an exceptionally large product must be processed. Therefore, the task requirement of
50cm will be used for horizontal reach.
This elimination only applies to attributes that must be possessed by all coalition members. The
following eight agent attributes can be used for pre-filtering, before coalitions are formed:
• Availability
• Ambient temperature
• Authorization
• Degree of protection
• Operating humidity
• Organizational position
• Responsibilities
• Space requirements
• Tenancy
• Terrain traversability
Rosen (2018) presents equations to generate combinations of elements in a set. The algorithm
progressively combines each element of a set with every other element, with an increasing
combination size. The result is stored as a set of sets of combinations. If each Agent is an element in
181
a set, then the set Agents is a set containing all agent identifiers. Any coalition must therefore be a
subset of the set of agents. All coalitions must also be stored in a set of Coalitions.
All the possible coalitions are all possible combinations of all the agents. Therefore, Coalitions is the
power set of Agents.
𝐶𝑜𝑎𝑙𝑖𝑡𝑖𝑜𝑛𝑠 = 𝑃(𝐴𝑔𝑒𝑛𝑡𝑠)
The coalition size can range from zero to the total set of agents in a single coalition. Although the
empty set is always a possible subset, an empty coalition will simply be ignored because it doesn’t
possess any attributes and is therefore not eligible to perform any task. It is expected that only a small
number of agents will be considered for coalition formation, after the extensive pre-filtering explained
in Section 6.3.2. The coalition size can also be limited to alleviate any fears that the computation will
take unreasonably long.
Each coalition will be considered for task assignment, based on the attributes possessed by the
coalition members. Therefore, the attributes of coalition members must first be merged into a single
set of attributes. However, not all agent attributes are treated the same during the merger. Table 50
shows the operation performed for each attribute, indicating the result used for the coalition.
Table 50: Merging of agent attributes to determine coalition attributes. The eight attributes used
for pre-filtering, as explained in Section 6.3.2, are included, in case those attributes were not used
to filter the agents before coalition formation.
Agent Operation
attribute
Agent ability Highest value of each ability is used as ability level for
coalition.
Agent authorization Only authorizations that are common for all coalition
members are kept.
Availability False if any coalition member is not available.
Functional Operation time Shortest operating time is used.
attributes Rest time Longest rest time is used.
Type of end effectors Aggregate of all end effector types.
Number of end effectors Sum of all end effectors.
Mounting position Aggregate of all mounting positions.
Degree of protection Lowest degree of protection used.
Configuration duration Longest configuration duration used.
(adaptability)
Autonomy Highest level of autonomy is used.
Degrees of freedom Highest degrees of freedom used.
Horizontal reach Greatest horizontal reach is used.
Vertical reach Greatest vertical reach is used.
Wrist reach distance Greatest wrist reach is used.
Terrain traversability Only terrain that is common for all coalition members
are kept.
182
Non- Operating cost Sum of agent operating costs.
functional Air pollution Sum of air pollution.
attributes Ambient temperature Most restrictive ambient temperature is used.
Space requirements Sum of all space requirements.
Operating humidity Most restrictive operating humidity.
Occupancy Average of occupancy rates.
Organizational position Only positions that are common for all coalition
members are kept.
Responsibilities Only responsibilities that are common for all coalition
members are kept.
Tenancy Only locations that are common for all coalition
members are kept.
Work schedule Most restrictive work schedule is used.
Work variety Aggregate of all tasks performed during the last shift.
Workload Longest task queue is used.
Table 51: Processing of eligibility attributes to determine whether a coalition can perform a task.
183
Work schedule All coalition members must be available for the
estimated duration of the task.
As established in Section 5.5, the requirements of a production order (referred to as the case in BPM
terminology) can have implications on the requirements of a task. Therefore, task and case
requirements must be merged to determine the final set of requirements. This merger is significantly
simpler than the merger of agent attributes though. Assuming task and case requirements are
expressed with the same set of attributes, as prescribed in Chapter 5, then the case requirement will
always overwrite the task requirement, if it exists. For example, a task might require the agent to lift
a product with a mass of 5kg, but the production order specifies that the product weighs 7kg. In this
case, the lifting requirement is 7kg and can therefore only be performed by an agent or coalition of
agents that can lift a product of 7kg.
The devil’s quadrangle of Brand and Van der Kolk (1995) is used here as the basis for such a value
system. The devil’s quadrangle is often used to assess the impact of process improvements on four
orthogonal dimensions: time, flexibility, quality and cost (Mansar and Reijers, 2007). The four
dimensions are orthogonal, but dependent. This is intuitive, because time, flexibility, quality and cost
can be measured independently, but a change in one dimension is bound to have an impact on one
or more other dimension. Figure 96 shows the devil’s quadrangle, with an illustrative example
showing how a decrease in process time (or duration) can lead to, or be the result of, increased cost.
184
Figure 96: The devil's quadrangle of Brand and Van der Kolk (1995).
For the agent allocation algorithm, the four dimensions of the devil’s quadrangle are used as an
indication of the importance placed on process dimensions. The relative importance can be expressed
as weighted integers. For example, if a company is primarily concerned with lower costs, then the cost
dimension can be prioritised to the detriment of one or more other dimensions. Therefore, the cost
objective can be assigned a value of 3, while keeping the quality, time and flexibility values as 1. In
such a case, the cheapest coalition will mostly likely be assigned, leading to increased throughput time
or decreased quality.
Eligibility attributes vastly outnumber the performance attributes, with only nine attributes that can
be used to compare expected performance of coalitions. Table 52 shows the nine attributes and gives
an indication of how each attribute should be used to determine the best coalition for the task.
Table 52: The nine coalition attributes that can be used for performance comparison, with an
indication for how each attribute can be used.
185
Air pollution Quality The sum of the air pollution caused by all coalition
members.
Occupancy Flexibility and Coalition with the lowest busy to idle ration should be
quality assigned, if all other criteria are equal.
Work variety Flexibility and Coalition with the lowest variety of tasks performed
quality should be assigned, if all other criteria are equal.
Workload Time Coalition with the lowest workload is most likely to
complete the task the fastest.
Terrain Time The speed component of the attribute can be used to
traversability calculate the time for coalition members to reach the
task location and start execution.
Terrain traversability is interesting in this regard, because it has two components. The capability to
traverse a certain type of terrain is an eligibility criterium, but the speed of traversal is a performance
criterium. The speed of traversal can be used to calculate the time it will take an agent to reach the
task location or the time it will take to complete a transport task. Regardless, both of these possibilities
ultimately contribute to the estimated task time. Consequently, ten attributes (nine in Table 52 plus
terrain traversability) can be used to compare the expected performance of eligible coalitions.
The agent allocation algorithm utilises the following four sets of data, as established in section 6.3.1:
• Agent attributes: The set of criteria used to describe an agent, divided into eligibility and
performance criteria.
• Task requirements: The set of criteria used to describe a task, divided into eligibility and
performance requirements.
• Case requirements: The same set of criteria used to describe a task, that may be used to
overwrite task requirements to cater for production and product variability.
• Process objectives: The value system used to determine the relative importance of time,
flexibility, quality and cost.
The four sets of information must be combined in such a way to determine which coalition is best
suited to perform the task. Agent attributes must be compared to task and case requirements to
calculate which coalition of agents best support the process objectives. Therefore, the following five
objects are identified and marked as blue in Figure 97: agent, task, case, process, and coalition.
186
Figure 97: UML class diagram of the agent allocation algorithm.
The CombinationGenerator is not a contribution of this research, as it is directly used from Rosen
(2018). The programming code, as retrieved and used, is included in Appendix L.
187
The object named Selection performs most of the calculations of the algorithm. It retrieves the task
identifier from the process engine, filters the agents per Section 6.3.2, then sends all candidates to
CombinationGenerator. CombinationGenerator returns the list of potential coalitions to Selection.
With a list of potential coalitions created, the Selection object performs the following three functions:
1) it checks the eligibility of all potential coalitions, 2) compares the eligible coalitions in context of
the process objectives, and 3) it returns the identifiers of the members of the selected coalition to the
process engine. This series of operations are expressed with pseudo code below.
188
coalition.quality = MAX(coalition.member.quality)
coalition.flexibility = MAX(coalition.member.flexibility)
coalition.performance = coalition.cost + coalition.time + coalition.quality +
coalition.flexibility
// Select best coalition. Start with a performance rating of zero and move up.
Coalition selectedCoalition
selectedCoalition.performance = 0
FOR EACH coalition IN coalitions
IF coalition.performance > selectedCoalition.performance
THEN selectedCoalition = coalition
6.5 Implementation
The agent allocation algorithm must be invoked by the process engine of the MPMS. As established
in Section 5.7, not all tasks benefit from dynamic allocation. Figure 98 shows an illustrative process
model using BPMN2.0. The first task, named Task A, is not designated for dynamic agent allocation
and will therefore use conventional resource allocation. Conversely, Task B is designated for dynamic
agent allocation and will therefore call the dynamic agent allocation integration model, shown in
Figure 99.
Figure 98: Illustrative process model showing one task without dynamic allocation and one with
dynamic allocation.
The agent allocation algorithm must be invoked once the process engine reaches a task designated
for dynamic agent allocation (illustrated with Task B in Figure 98). However, the algorithm only returns
identification information of the members of the selected coalition. Those members must still be
assigned to a task by the process engine. The process model shown in Figure 99 is used to invoke the
agent allocation algorithm, then assign the selected coalition members to the task under
consideration. This same model can be used for all tasks designated for dynamic agent allocation.
189
Figure 99: The process model called by all tasks designated for dynamic agent allocation.
The first task in Figure 99, named Select Coalition, invokes the agent allocation algorithm. This is a
normal service task, in BPMN2.0 terminology, that calls the algorithm and passes it the task_id,
case_id and process_id. This task ends once a result is returned and stored as an assignee variable.
Four different result types are possible: 1) a coalition with only automated agent members, 2) a
coalition with only human members, 3) a coalition with a mix of human and automated agent
members, and 4) no eligible coalition found. The different coalition compositions are differentiated
because the process engine assigns agent types differently. Humans receive task assignments via a
user interface showing task information. Automated agents are assigned via data exchange between
the process engine and the agent control system.
1. The TRI case is used to demonstrate that the algorithm can select an agent, from multiple
options, to perform a task.
2. The Sand-Casting Foundry case is use to demonstrate that the algorithm can assign a
coalition of multiple agents to a task.
190
This section is purposefully named proof of concept, rather than evaluation, to avoid misrepresenting
the development presented in this chapter. The agent allocation algorithm in this chapter does not
make any claims regarding optimality or superiority compared to other algorithms.
Figure 101 shows the new process, with tasks spread across two roles for tool assembly and parts
transport. The confusing layout is somewhat unavoidable due to the dependencies between tasks and
page size limit. All four tasks in the ‘tool collector’ lane are designated for agent allocation, thus calling
the re-usable process model shown in Figure 99.
4 https://youtu.be/bqTDEZvOdVI
191
Figure 101: Tool assembly scenario at TRI after introduction of a mobile robot and augmented
reality.
192
The objective of this proof of concept is to demonstrate that the agent allocation algorithm, as
presented in this chapter, can use the agent and task definitions to assign of agents to tasks. To that
end, the same scenario will be used to compare process duration without the algorithm and with the
algorithm. Without the algorithm, the tool engineer tasks will always be allocated to the operator
assigned to the work cell and the tool collection tasks will always be assigned to the mobile robot.
With the algorithm, every time one of the fetch or return tasks in the ‘tool collector’ lane is
instantiated, the agent allocation algorithm is executed to find the best coalition for the task. In this
case, the coalition will always consist of only one agent, either the mobile robot or the human
operator currently assigned to the tool assembly work cell. Figure 102 shows the result of the test,
with four instances of the process without the allocation algorithm and four with the algorithm
enabled.
01:01:07 01:01:15
00:52:50
00:51:26
00:47:41
00:45:37 00:46:03
00:41:11
human1, KMR human2, KMR human3, KMR human4, KMR human5, KMR human6, KMR human7, KMR human8, KMR
Figure 102: Comparison of the tool assembly process duration comparison without agent
allocation and with agent allocation enabled.
The results displayed in Figure 102, and the subsequent Figure 103 and Figure 104, are directly
extracted from the event log of the MPMS.
17:17 08:38
14:24 07:12
11:31 05:46
08:38 04:19
05:46 02:53
02:53 01:26
00:00 00:00
Figure 103: Duration of the assembly and disassembly tasks as performed by different agents.
193
Figure 103 shows the duration of assemble and disassemble tasks, performed by different agents. No
significant difference can be found between the duration of tasks performed by the two groups of
operators. Moving on to the fetch and return tasks, the durations are shown in Figure 104. In this case
a clear difference is visible between the fetch and return tasks performed by the mobile robot and the
human operator. The difference in process duration shown in Figure 102 can be directly attributed to
the difference in fetch and return task duration. Essentially, the agent allocation algorithm determined
that the faster fetching and returning performed by the human is sometimes more supportive of the
process objectives set by the process supervisor.
00:00 00:00
Figure 104: Duration of fetch and return tasks, as performed by different agents.
Although the results obtained from the demonstration are quite compelling, no process performance
improvement can be proven. The sample size is too small, due to the lengthy duration of a single
process execution. Nevertheless, the results do demonstrate that the implemented agent allocation
algorithm achieves the success criteria defined at the start of this chapter: An agent is allocated to
every task that is designated for agent allocation.
194
Figure 105: Grape separation scenario at SCF in Poland.
195
As evidence for the execution of a coalition task, video footage of the teaching-by-demonstration task
is available online5. The task was performed under laboratory conditions, but the role of the MPMS is
not affected. The agent allocation algorithm can select multiple agents for a single task.
The algorithm has been implemented and realised as part of the MPMS and deployed at two
operational factories. Although the proof of concept is limited, the results are certainly indicative of
the potential benefit of dynamic allocation of agents. This is especially true for processes that require
rapid and frequent change, such as those emerging in Industry 4.0. The benefit can be further
enhanced by catering for coalitions of agents, as demonstrated with the second proof of concept in
Section 6.6.2. Regardless of the specific implementation and options, the presented allocation
algorithm is a significant improvement over current techniques that rely solely on organisational
information.
The design presented in this chapter represents the process and development views of the Kruchten
4+1 framework (Kruchten, 1995). This framework is discussed in Chapter 3 and is used as the overall
structure of the developments in this thesis. The process view corresponds to Section 6.3 and the
development view to Section 6.4 of this chapter. These views will feed into the physical view of the
MPMS, as presented in Chapter 7.
5 https://youtu.be/Oks28m0sP4Q
196
Chapter 7
7. REALISATION AND EVALUATION
As the name implies, this chapter serves two purposes. First, a realisation of the MPMS is presented.
It is purposefully referred to as “a realisation” because it isn’t the only or even definitive realisation
of the system architecture presented in Chapter 3. Instead, the objective of this chapter is to
demonstrate that the system architecture is viable, i.e. it can be realised as an operational system.
The second purpose of this chapter is to report on the evaluation of the overall research study. In
Chapter 1 the research outcome is positioned as a theory for the exaptation of BPM for smart
manufacturing operations. It is also argued that the theory includes the following four artefacts:
Artefacts two, three and four are individually evaluated in Chapters 4, 5 and 6. However, artefact one
and the overall design theory remain untested. Therefore, this chapter reports on the evaluation of
the MPMS architecture and the theory for the exaptation of BPM for smart manufacturing operations.
197
technology remains the same. To round-off the system realisation, the MPMS is presented as the
central orchestration hub of the HORSE System, demonstrating an information system that is
deployed and utilised in real factories.
6The Pega Business Cloud is not just for process design, but can also handle process execution.
7Bizagi Xpress Edition does not offer options for fault tolerance and clustering. Only in Enterprise
editions they are possible.
198
(SOAP, (SOAP, WebSphere
JMS, etc.) JMS, etc.) Message
Broker
Features and Inclusion of 2 + + + +
actual enactment engine
development Process Modeller 2 + + + +
Process language, 2 BPMN 2.0 Own BPMN 2.0 Unknown
syntax and notation DMN 1.1 notation /
support CMMN 1.1 Rule-based
modelling
Supports agent 2 + + + +
management
Dashboard / Cockpit 2 + + + +
features for runtime
overview
8 Simulation is available both at the skeleton process level and at whole process level. However, this support is
fairly basic (Craggs, 2011).
9 Integration to backend services, databases and applications is cumbersome in PRPC, frequently requiring hand
coding in Java and Pegasystems consultants to assist on projects (AVIO Consulting, 2013).
10 IBM Websphere ESB is included for BPM but is restricted and not available for general use unless purchased
199
Camunda BPM emerged as the most suitable BPMS to form the basis for development of the MPMS.
Camunda BPM is an open source platform for workflow and business process management. It is highly
extensible and includes native support to model and enact BPMN 2.0 models. Camunda BPM is used
to show how the MPMS can be realised, based on existing technology.
Figure 106: Simplified representation of Camunda BPM architecture (Camunda Services GmbH,
n.d.).
Figure 106 shows a simplification of the software aspect of the Camunda BPM information system
architecture. The following components come as standard part of the package:
• Modeler: Modelling tool for BPMN 2.0 and CMMN 1.1 diagrams as well as DMN 1.1
decision tables.
• Process Engine: A Java library responsible for executing BPMN 2.0 processes, CMMN 1.1
cases and DMN 1.1 decisions. It has a lightweight POJO (plain old Java object) core and
uses a relational database for persistence. ORM mapping is provided by the MyBatis
mapping framework.
• REST API: Allows you to use the process engine from a remote application or a JavaScript
application.
• Tasklist: A web application for human workflow management and user tasks that allows
process participants to inspect their workflow tasks and navigate to task forms in order to
work on the tasks and provide data input.
• Cockpit: A web application for process monitoring and operations that allows you to
search for process instances, inspect their state and repair broken instances.
• Admin: A web application that allows you to manage users, groups and authorizations.
To show how the MPMS can be realised with Camunda BPM, Figure 107 shows how modules of the
MPMS (see Figure 75 in Chapter 3) maps to modules of Camunda BPM. Green connections indicate
that the two modules correspond directly, in terms of functionality and scope. It can be seen that
200
Camunda BPM is a direct implementation of the WfMS reference architecture (see Figure Figure 72
in Chapter 3), because process definition tools, process engine, administration & monitoring tools,
tasklist and custome applications all directly map to modules of the Camunda BPM architecture.
ERP system
MES / QMS /
MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Automated
Human agent
agent control
interface
system
Figure 107: Mapping between modules of the MPMS and Camunda BPM.
Four modules of the MPMS architecture do not map to any modules in Camunda BPM. These four
modules correspond to the two new system functions identified in Table 13 of Chapter 3. The first
three modules are part of the definition tools subsystem and deliver the resource definition
functionality. The resource definition module is accompanied by task definition and location definition
modules, based on the definitions established in the data aspect design (see Section 3.3.3.4). The
agent allocation module is part of the process enactment service subsystem and delivers the resource
allocation function listed in Table 13 of Chapter 3.
201
The red connection indicates that the interface to automated agents control systems does not
currently exist, but Camunda BPM specifically caters for “custom applications” in such cases. The
realisation of such a custom application is further explored in Section 7.2.2. Furthermore, the task
definition, resource definition, location definition and agent allocation modules are currently not
supported by Camunda BPM, but are developed in Chapters 4 to 6 and realised as part of the HORSE
System, discussed in Section 7.2.2.
Given the primary context of small and medium manufacturing enterprises, it is first determined
which modules of the system can be situated in the cloud. Performance expectations for each module
of the MPMS is considered to determine which modules can be hosted in the cloud. For example,
modules used during design-time generally do not require guaranteed sub-second response times.
Hence, such modules can be hosted as cloud applications and be subjected to the normal performance
impact of distance and Internet traffic. To add some nuance to the discussion, two cloud-based
models and a non-cloud model are used as reference for software deployment (Shawish and Salama,
2014).
Rimal et al. (2011) advocates for scalability, performance, multi-tenancy, configurability, and fault-
tolerance as the primary considerations for cloud support of applications. Table 54 lists the
advantages and disadvantages inherent to each cloud-support model in relation to the five
considerations.
Table 54: Advantages and disadvantages of SaaS, PaaS, and on-premise models in relation to the
five considerations for cloud-support.
202
network quality, traffic, network quality,
and distance. traffic, and distance.
Additional tenants
Tenancy can easily be
added with additional Only within its local
Multi-tenancy extended to any agent
software installation environment.
with Internet access.
or expansion.
The five considerations listed in Table 54 are applied to determine which modules of the MPMS can
be hosted with the SaaS or PaaS cloud computing models. The results of the analysis are listed in
Table 55. Please note, all modules related to the MPMS, as shown in Figure 74, are considered in
this analysis to establish the line between cloud-based and on-premise deployment.
Table 55. Application of the five considerations for cloud-support for the modules of the MPMS.
203
Human agent On-premise Multiple, technology-heterogeneous realizations for
interface each local deployment requires no scalability or multi-
Auto agent control tenancy.
system The configuration is done during design-time.
The control of multiple, interacting agents require strict
performance guarantees in the millisecond domain and
near-zero fault tolerance.
Figure 108 shows the result of the five considerations as an overlay on the logical view of the MPMS
architecture. The modules at the global layer support process design, agent design, process
enactment, and monitoring. Process and agent design are interactive modules but do require any
guaranteed performance. A further advantage of the SaaS model is simplified versioning and upgrade
of the software since manufacturing is becoming more flexible (Chang et al., 2003; Mishra et al., 2014).
Process enactment and monitoring has a real-time character but without very strict timing
requirements. Consequently, it is possible to deploy all global layer modules and both the data stores
in the cloud. An important requirement for the cloud environment is a very high quality of service
(QoS) in terms of availability: unavailability of global functionality typically brings a process-oriented
manufacturing plant to a halt within minutes if not seconds.
SaaS
ERP system
SaaS PaaS
MES / QMS /
MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Automated
Human agent
interface
agent control On-premise
system
The modules at the local layer control the activities of agents—either individually or in teams—are
very much real-time cyber-physical systems. This means that part of their functionality has very strict
response-time requirements, possibly in the order of milliseconds. A good example is safety
management, which requires fast synchronization between sensors, local awareness functionality,
local execution functionality, and agents (humans and robots).
204
7.2.1.3 The MPMS as an IoT Application
With the process enactment services in the cloud and the agent control systems on-site, the MPMS
relies heavily on communication between the cloud and the Things that perform manufacturing
activities. This communication is facilitated by the Internet-of-Things. Significant disagreement exists
regarding the nature and scope of the IoT (Atzori et al., 2010), but Wortmann and Flüchter (2015)
offer a complete overview of the concept by bringing together computing, connectivity, and devices
in a single technology stack. The technology stack follows the concept of functional abstraction (Bass
et al., 2013), i.e., each layer builds on the functionality of the layer below. For example, the control
software of a thing/device makes use of the actuating and sensing components to exert control over
the hardware of the thing/device.
The technology stack draws attention to the division between the things or devices (including its
embedded control system) on the factory floor and software situated in the IoT cloud. The
connectivity layer facilitates communication between the IoT Cloud and one or more things/devices.
Functional abstraction and the division between the cloud and the device is applied to construct a
technology stack for the MPMS. The resulting technology stack, which is shown in Figure 109, serves
two purposes: (1) to describe how modern technologies contribute to realize the MPMS and (2) to
justify the designation of the MPMS as an IoT application.
On-cloud IoT
application
MPMS
Internet
Thing/ Human
device Sensor Robot Augmented
interface
software controller controller reality software
software
On-device
205
Starting from the bottom of Figure 109, to simplify the explanation of the assimilation of technologies,
the various things and devices are shown as simple icons. Human interfaces are represented with
displays and handheld devices. The sensors are represented with a camera and microphone while
robots are represented with a robotic arm and a vehicle. Lastly, augmented reality is represented with
wearable glasses and a sensor to track human movements. The displayed things or devices are only
representative since the actual set may differ in a factory. On the second layer from the bottom, the
various devices and things are controlled by their respective software systems. These software
systems are left purposefully abstract to signify the open nature of the MPMS. Many different
technologies can be utilized in conjunction with the MPMS. The software systems of the devices are
connected to the MPMS via the local area network of the factory.
Three work cell control systems, from competing vendors, are shown for thing/device communication
and management. This again demonstrates the openness and versatility of the MPMS in a
technologically heterogeneous environment. This layer is also the most significant deviation from the
IoT technology stack of Wortmann and Flüchter (2015). The thing/device communication and
management is not included in the Cloud grouping of the technology stack because of the
requirement for guaranteed, sub-second communication and synchronization between agents in a
work cell.
A singular block named Internet is shown to represent the connectivity between Local and Global
features. This implies all standard infrastructure and protocols. Communication may be directed via
an enterprise service bus to allow all subsystems to subscribe to it and publish messages.
At the top of Figure 109, the on-cloud functionality is presented in three layers. Camunda BPM can
run equally well on a Wildfly or Apache Tomcat application platform. The process management layer
contains the same three subsystems as shown in Figure 108. The more detailed modules of the MPMS
are omitted here in the interest of legibility. Lastly, the MPMS itself is shown at the top of the
technology stack, highlighting the MPMS as IoT application, with multiple layers of functionality
covering the complete technology stack of Wortmann and Flüchter (2015).
12
http://www.horse-project.eu/Media
206
The core role of the MPMS in the HORSE System has technological implications on the MPMS. Table
56 lists the technologies used for the implementation of the MPMS as part of the HORSE System,
but alternative technologies are undoubtedly possible.
The HORSE System has a layered architecture pattern, with a global orchestration layer and a local
control layer (Grefen et al., 2016). Figure 110 shows a model of the HORSE System. The upper layer
represents global control and the lower layer contains the technologies that are utilized by a human
or robot on the factory floor.
Figure 110: Software aspect of the HORSE System (Grefen et al., 2016).
Additionally, the HORSE System covers the design and execution lifecycle stages of manufacturing
activities. Both the global and local system layers are divided into design-time and run-time sub-
systems. Processes and agents are defined in the HORSE Design Global sub-system, while tasks and
physical constraints are defined in the HORSE Config Local subsystem. The definition information
generated during design-time is stored in the two data stores is then utilized during the execution of
manufacturing processes.
207
The subsystem labelled ‘HORSE Exec Global’ is responsible for the orchestration of activities during
process run-time. HORSE Exec Local includes the human interface and the control systems of
automated agents. This subsystem controls the steps performed by agents and sub-second
synchronization between agents. It is an abstract system, with instantiations based on different
technologies. In the HORSE Project, the HORSE Exec Local subsystem is realized using Robot Operating
System (ROS) and KUKA Sunrise technology. Thus, the control systems of automated agents may run
on different operating systems and even follow different control approaches. For example, a cutting-
edge KUKA robot and a computer numerical controlled machine can participate in the same process.
The MPMS and its modules presented throughout this thesis is synonymous with the entire global
layer of the HORSE System. As such, the design-time and run-time subsystems of the global layer are
elaborated further. It should be noted that the MPMS and HORSE System were designed under
completely different circumstances. The MPMS design is the product of an individual research, based
on existing scientific knowledge with limited extensions to satisfy domain-specific requirements.
Conversely, The HORSE System is a larger endeavour, designed by a team of contributors. The
contributors include multiple industry professionals and scientists from different disciplines, including
the author of this thesis. Although the author applied the same design principles and approach, the
HORSE System is the product of compromise, as the design team included a range of perspectives and
expertise. This compromise inevitably results in a system architecture that is slightly awkward to
explain, albeit still entirely valid. The awkwardness also extends to the mapping between the MPMS
and the HORSE System.
The HORSE Design Global subsystem corresponds directly to the Design Tools subsystem of the MPMS.
Figure 111 shows the mapping between the MPMS and the HORSE Design Global subsystem.
208
ERP system
MES / QMS /
MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Automated
Human agent
agent control
interface
system
Product Process /
Defs. Agent Data
Syntax Agent
Process Task Human Autom.
Violation Class
Ani- Identi- Agent Agent
Detec- Allo-
mation fication Design Design
tion cation
Task / Step /
Cell Defs.
The Location Definition module of the MPMS is not mapped to any part of the HORSE System in Figure
111. The equivalent module in the HORSE System is named Workcell Simulator, situated in the local
layer as shown in Figure 110. As for HORSE Design Global modules that are not present in the MPMS,
Table 57 provides reasons why these missing modules do not affect the realisation or evaluation of
the MPMS.
Table 57: Explanation of HORSE Design Global modules not included in the MPMS.
209
7.2.2.2 HORSE Exec Global
The HORSE Exec Global sub-system contains the modules involved in execution and monitoring of
manufacturing processes. These modules provide the functions used to enact a sequence of tasks,
assign agents to those tasks and provide the agents with necessary information. Exception handling
and performance tracking modules are also included. The Production Execution Monitoring module
supports real-time monitoring of manufacturing execution in terms of processes, orders, and agents
(human and automated). HORSE Exec Global also includes two Global Awareness modules. The Global
Safety Guard is a mechanism that can halt all process execution in case of emergency. Lastly, the Event
Processing module is a sophisticated piece of software that attempts to connect seemingly unrelated
events in the factory to detect problems before occurrence.
The HORSE Global Execution subsystem corresponds directly to the Process Enactment Service and
Administration & Monitoring Tools subsystems of the MPMS. Figure 112 shows the mapping between
the MPMS and the HORSE Design Global subsystem.
ERP system
MES / QMS /
MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Automated
Human agent
agent control
interface
system
Process /
Agent Data
Structur. Global
Next Task Agent Worklist Excep- Perfor- Event
Selection Selection Delivery tion mance Processing
Handling Tracking
Exec Global
Abstraction
Layer
210
As with the design-time subsystem, the mapping between HORSE Exec Global and the MPMS is not
entirely straight forward. However, the HORSE System covers all three run-time modules of the
MPMS, namely the process engine, agent allocation and administration & monitoring tools. As for
modules of the HORSE System not covered by the MPMS, Table 58 provides reasons why these missing
modules do not affect the realisation or evaluation of the MPMS.
Table 58: Explanation of HORSE Exec Global modules not included in the MPMS.
As the HORSE Exec Global subsystem is based on BPMS technology and uses BPMN2.0, it is proven for
level 4 processes (Wohed et al., 2006). The interface to the HORSE Exec Local subsystem enables the
process management system to also enact level 3 processes. The Global Execution subsystem sends
work items to a variety of humans, robots and automated guided vehicles, and receives responses
from those agents (e.g. task completed, or task failed).
Figure 113: The HORSE System positioned in the functional hierarchy of IEC62264:2013-1.
Figure 113 shows the run-time subsystems of the HORSE System in the architecture of computer
integrated manufacturing. The HORSE Exec Global subsystem occupies the position of the MPMS. The
HORSE Exec Local subsystem occupies the place of all human interfaces and automated agent control
systems. As such, the HORSE Exec Local subsystem is a realization of the internet-of-things, acting as
the connection between the MPMS and the devices. This realization is discussed in detail by Grefen
et al. (2018). As with the architecture presented in Figure 52, separate interfaces between
manufacturing operations management systems and other control systems are still possible, as shown
by the interface between the MES and PLC in Figure 113.
211
7.3 Evaluation
With the MPMS realised as part of the HORSE System, the last evaluation can be discussed. This
evaluation is about the realised MPMS and the overall theory for the exaptation of BPM knowledge
for smart manufacturing operations. The new developments of the MPMS are separately evaluated
in Chapters 4, 5 and 6, but the MPMS as a whole is evaluated in this section. Thus, the evaluation is
divided into three parts, corresponding to practical demonstration of process management,
verification of the MPMS design and, lastly, gauging the acceptance of the technology by factory
workers.
This case study will elaborate on the transformation in the context of the executable models of the
manufacturing processes. As a reminder, TRI manufactures telescopic sliders for industrial-grade
racks, cupboards and other containers. The manufacturing process is divided into three main
production phases preceded by a tool preparation phase. Figure 31 shows the complete
manufacturing process, designed according to the guidance provided in Chapter 4. The process is
broken into separate pools because it is asynchronous, i.e. there may be waiting time between
manufacturing phases.
13 https://youtu.be/JBodoko84jc
212
Figure 114: TRI manufacturing process, showing tool preparation and three phases of production.
Figure 114 shows four subprocesses (in BPMN2.0 terminology), depicted with a bold border to
indicate that they are further elaborated in separate process models. The interventions of the HORSE
Project are contained in those subprocesses, as the best opportunities to demonstrate smart
manufacturing technologies. The first of these subprocesses, single tool assembly, was already
discussed and demonstrated as part of the evaluation of dynamic agent allocation, in Chapter 6. The
second subprocess, place profiles in bin, is further elaborated in Figure 115.
213
Figure 115: Executable model of the 'place profiles in bin' subprocess.
214
The process shown in Figure 115 involves a human operator, an industrial robot from Universal
Robots, and an automated guided vehicle that can transport bins full of metal profiles. Both the
automated agents are controlled by an instantiation of the HORSE Exec Local subsystem based on the
Robot Operating System platform and the activities of all three agents are orchestrated by the MPMS.
The activities with bold borders call the reusable process model shown in Figure 99 of Chapter 6 to
find a suitable agent or coalition of agents and make the connection with the control system if an
automated agent is allocated. This scenario demonstrates complete vertical integration, across levels
2, 3 and 4 of the functional hierarchy.
The third subprocess also involves handling of metal profiles. The most significant difference of this
scenario compared to the previous is that one of the tasks can be allocated to a human or robot. The
grab, lift and hang single profile task can be performed by the loading robot or the human operator
stationed at the work cell. Unfortunately, the robot performs its duties relatively quickly compared to
the duties of the operator, resulting in unwavering allocation to the robot.
The last call activity shown in Figure 114 leads to a subprocess that is essentially the mirror image of
Figure 117. The two subprocesses involve the same activities and agents, in inverse order. Its process
model is omitted, in the interest of brevity and because it doesn’t contain any new knowledge.
Nevertheless, the presence of the MPMS in four important subprocesses gives good insight into the
status of production in the factory. All four these subprocesses were entirely manual before the
HORSE Project intervention, causing uncertainty about the progress of production orders. As
established in Chapter 1, uncertainty is detrimental to the flexibility so urgently needed by TRI.
215
Figure 117: Executable model of the P2 loading' subprocess.
216
7.3.1.2 Sand-casting foundry
The second practical case, as elaborated in Chapter 2, is used to demonstrate that the MPMS can be
used to design and enact cross-functional processes. This case is at a medium-sized foundry in Poland
and uses sand-casting to produce small batches of highly customizable metal parts for various
industries, including automotive, railway and aerospace. The company has more than a thousand
active part numbers at any time, emphasizing the need for manufacturing flexibility. Rapid design and
fabrication of moulds enables the company to quickly cycle between different production orders.
However, the finishing operations remain problematic. Casted products require substantial surface
treatment and refinement operations to satisfy customer requirements. While casting operations
have seen widespread automation, the finishing operations remain largely manual, with use of
traditional tools such as grinders and hammers. This problem is aggravated by the extensive product
customization. It is exceedingly difficult to develop a robotic solution that can perform surface
treatment and finishing operations on parts that change shape, size and layout every hour.
The HORSE System is used to model and enact the manufacturing process of the foundry, as shown in
Figure 118, populated by humans and a variety of automated systems. This cross-functional process
includes activities of several business functions at both level 3 and 4 of the functional hierarchy. Level
4 functions include Sales and Marketing (supported by an ERP system) and Engineering (supported by
a Product Lifecycle Management (PLM) system). Level 3 functions include production, inventory and
quality operations, supported by PLM, MES and QMS. Maintenance operations are absent from this
process model because the model is limited to the production phase of the business lifecycle.
Most of the activities shown in Figure 118 are decomposed on one or more levels. To demonstrate
integration to robotics, the ‘separation’ sub-process, as part of PA3: Finishing, is further elaborated
here. Separation is necessary because four to eight castings share a single mould and remain attached
to each other due to excess metal in the mould. A robot is deployed to remove the excess metal with
a disc cutter. The process model for this operation is shown in Figure 119 and makes use of teaching-
by-demonstration technology. After loading the production order, the operator moves the robot arm
through the necessary trajectory (see ‘Teach cutting plan to auto agent’ task in Figure 119). Once the
cutting plan is captured and a grape is placed on the table, the MPMS initiates cutting by sending the
instruction to the robot. The robot receives work items from the global layer (the process
management system) and responds with outcomes of the task (i.e. task completed, failed, paused).
The MPMS then moves on to the next activity, as dictated by the process model. A video of the
operational process is available online14 and a screenshot is shown in Figure 116. The MPMS is not
explicitly shown in the video, but as a core part of the HORSE System, the process can’t function
without it.
14
https://youtu.be/Oks28m0sP4Q
217
Figure 118: Executable model of the cross-functional process, including sales, marketing,
engineering and operations activities.
218
Figure 119: Executable model of separation process in the finishing production area.
219
This demonstration shows integration between levels 2, 3 and 4 of the functional hierarchy.
Additionally, cross-functional integration between distinct parts of the factory is also demonstrated.
Short videos showing the execution and integration of the HORSE System are available at
http://www.horse-project.eu/Media.
15 https://youtu.be/P6XhSHQJj_s
220
Figure 120: Executable model of the inspection and packaging process at APA.
221
7.3.2 MPMS verification
With the design complete and the MPMS realised, the system architecture can be confronted with
the requirements established in Chapter 2. The set of requirements are derived from scientific
literature on smart manufacturing and the practical cases presented in Chapter 2. Table 59 shows the
original ten system requirements and evidence for the satisfaction of those requirements.
Table 59: MPMS requirements from Chapter 2, as derived from scientific literature and practical
cases.
222
R09 The MPMS can assign Demonstrate Coating task assigned to SCF case
multiple actors to a single coalition of human and (Section 6.6.2)
activity. robot. APA case
(Section
7.3.1.3)
R10 The MPMS can respond to Demonstrate Reassignment of tasks APA case
changes in the based on stress level of (Section
manufacturing processes. operator. 7.3.1.3).
The MPMS and its modules have been extensively verified in appropriate practical scenarios. All ten
requirements defined in Chapter 2 are satisfied, with evidence provided in Table 59. It can thus be
concluded that the technology, as realised, is correct. However, the users of such technology should
also find it acceptable. The MPMS must still be assessed by users to determine whether it is an
appropriate solution to the problem defined in Chapter 1.
To be clear, the HORSE System as a whole is evaluated, because it is infeasible to distinguish the MPMS
from the rest of the HORSE System, from the perspective of the users. Typical users are concerned
with the solution to the problem, rather than the architecture or components of the solution.
Nevertheless, the MPMS is a core component of the HORSE System and together with the
“infrastructure” (middleware and platform) creates an integrated solution. Evaluation can be
attributed to parts of the system (which will be indicated if that is clear) but certainly also to the whole
HORSE System.
The Technology Acceptance Model (TAM) (Davis, 1989) is used as both survey and outline for the
interviews. The model includes twelve questions divided into two sections for usefulness and ease of
use. Importantly, the questions aim to determine whether the user prefers to use the new technology,
compared to the previous way of working. All twelve questions are measured on a Likert scale of one
to seven, ranging from extremely likely to extremely unlikely. Figure 121 shows the 7-point Likert scale
for the questions. The questionnaire is translated to Dutch to interview participants in their native
language. The form as used is included in Appendix M.
Figure 121: 7-point Likert scale for usefulness and ease of use.
Nineteen people were interviewed, immediately after a person interacted with the HORSE System.
The nineteen people can be broken into the following categories:
223
• 2 experienced tooling engineers.
• 2 intermediate tooling engineers (fully trained but not yet experienced).
• 13 inexperienced operators.
• 2 supervisors.
The 19 surveys and interviews generated significant data to be used for evaluation. Table 60 shows
the 12 statements posed to the interviewees and the average rating as reported by the interviewees.
The system, as named in the survey statements, refers to the HORSE System, i.e. the collection of
HORSE developments involved in the pilot case scenario. As an overview, the system rated favourably,
with only two statements garnering a slightly unfavourable rating.
Table 60: Questions asked during interviews with average ratings by interviewees.
Nr Statement Average
rating
1 Using the system in my job would enable me to accomplish tasks more quickly. 2,32
2 Using the system would improve my job performance. 2,26
3 Using the system in my job would increase my productivity. 2,37
4 Using the system would enhance my effectiveness on the job. 2,21
5 Using the system would make it easier to do my job. 1,79
6 I would find the system useful in my job. 2,16
7 Learning to operate the system would be easy for me. 1,42
8 I would find it easy to get the system to do what I want it to do. 3,53
9 My interaction with the system would be clear and understandable. 1,84
10 I would find the system to be flexible to interact with. 3,58
11 It would be easy for me to become skilful at using the system. 1,68
12 I would find the system easy to use. 1,79
With 4 representing a completely neutral point on the scale of 1 to 7, none of the questions had a
below average overall response. To give some more insight into the range of responses, Figure 122
shows the average ratings and standard deviations for all twelve questions.
224
1 2 3 4 5 6 7 8 9 10 11 12
Figure 122: Graph showing the response averages and standard deviations.
The participants were highly enthusiastic of the usefulness of the system. This optimism is often
attributed to the procedural nature of the process-centric approach. They acknowledged the value of
having a system that encourages disciplined process execution. This is even more important for
inexperienced operators, who can be trained faster to participate in complex processes. Apart from
increased discipline, some participants also appreciate the lessened mental burden. The augmented
reality presents the relevant information, as encoded in the process model, to perform a task and the
process automatically moves to the next task, thus making it easier for an operator to follow
instructions and perform the work.
A common realisation amongst participants was that they never noticed the mobile robot. The tooling
parts were simply available when needed and removed again once the participant finished. This
225
observation points to two positive outcomes. Firstly, the process is well-designed from a physical
perspective, because the two agents can operate near each other but not disturb each other.
Secondly, and more importantly, the MPMS can coordinate two agents well enough for the tooling
engineer (the evaluation participants in this case) to allow the mobile platform to work entirely on its
own.
The most common complaint by participants were that the system forces them to work a certain way.
Manufacturing processes that involve human participants tend to offer some flexibility to the
participants on the precise order of tasks. This is no longer possible when the process is controlled by
augmented reality and a process management system. This is complaint is reflected in the average
score of flexibility statement of the TAM, as shown with statement 10 in Table 60. The operators felt
restricted and constrained by the system, minimising their opportunity to pursue process
improvement. This is a matter of process design and task definition though. If more autonomy is
needed, fewer details can be specified on the task level. The MPMS and its process design capabilities
are highly flexible and can accommodate users who want more autonomy. Perhaps this can be used
as motivation for multiple variations of a process, based on the profile of a user. A more experienced
user can be given more informative guidance, rather than restrictive guidance. The experience
attribute identified in Section 5.4 can be used to enable allocation of process or task variations, based
on the specific operator.
The second most common negative observation, especially as perceived by the more experienced
participants, is related to deeper understanding about the process, by the operator. The experienced
operators remark that an executable process will make it less important for operators to consider why
the process is performed a certain way. They will simply perform the work, as instructed by the
system. This presents two possible problems: 1) when something goes wrong, the operators are less
likely to respond appropriately, and 2) the operators will offer less ideas for improvement, because
they are not engaged to consider deficiencies in the process. This sentiment is again reflected in the
questionnaire, as shown with statement 8 in Table 60. While this criticism is fair, it is again a matter
of the information presented to users. The practical part of the evaluation, with users performing the
process as guided by the HORSE System, only presented limited process-related information to the
users. The evaluation was technology-driven, to see how users interact with and accept the
technology. However, the information-display prowess of the MPMS were somewhat neglected in
favour of the augmented reality system. The MPMS is perfectly positioned to present rich process-
related information to the user, given that it also manages the upstream and downstream processes.
The user can be presented with status information about upcoming cases and also inform the user
about activities that will happen subsequent to the current task.
7.4 Findings
The HORSE System provides adequate evidence that the MPMS can be realised as a useable system
in conjunction with other technology to control the machines. More importantly, the HORSE System
shows that a single process management system can be used to design and enact business and
manufacturing operations processes.
The original problem statement defined in Chapter 1 was as follows: Current manufacturing process
management techniques and technologies are not well equipped for the flexibility needed in Industry
4.0. The MPMS, as a core part of the HORSE System, shows that BPM techniques and technologies
226
can instead be used to design and execute manufacturing processes populated by humans, robots
and new technologies, such as augmented reality and situational safety awareness. These processes
are also more flexible, because the tasks are defined independently of the agents that might execute
those tasks. This makes it possible to allocate different agents to tasks, based on the characteristics
of agents and the status of the process.
Beyond the goal of demonstrating the viability of process management in manufacturing operations,
the realized system yielded other benefits in the test cases. Apart from integration between levels 2,
3 and 4, what can be thought of as vertical integration, the system also enhances integration between
various instantiations of level 2, i.e. horizontal integration. The process management system of the
HORSE Project is connected to level 2 systems based on different technology, including ROS and KUKA
Sunrise. Coupled with direct interfaces to humans, the MPMS can enact cross-functional processes by
orchestrating the activities of any agent in an enterprise. More interestingly, it is easier to allocate
agents from one business unit to assist elsewhere. For example, if an automated vehicle fails to
transport items from the warehouse, the receiving operator can be directly informed of the problem
and instructed to fetch the items. Previously, the vehicle would be controlled by the warehouse
management system while the operator receives instructions from the MES.
Other advancements stem from the open and standardized nature of process management. By using
international standards and open-source software, the process management system is extendible and
adaptable. Companies can change the system to suit their needs or opt for a different system with the
same notation. Additionally, adopting an international standard notation brings substantial
embedded knowledge. BPMN enjoys extensive academic and commercial support and interest, which
will see it evolve and improve over time. This status is particularly beneficial for recruitment purposes.
The pool of professionals or consultants with BPMN knowledge and skill is larger than any proprietary
notation.
The most prominent shortcoming of the proposed unification is a lack of current support among
vendors of manufacturing information systems. Vendors of information systems understandably
prefer their own proprietary process management techniques and notations, they vie for competitive
advantage. Removing core functionality of existing information systems reduces the prospects where
a competitive advantage can be achieved. However, it is exceedingly likely that process management
in manufacturing will be consolidated in dedicated systems, as transpired in enterprise information
systems. The capabilities of industrial-grade, standalone process management systems will eventually
surpass that of manufacturing operations management systems, if this has not already occurred.
Even with the extensive capabilities of current and future process management systems, the proposed
unification of process management presents a typical trade-off between standardization and agility.
A unified system, based on international standards and open architecture, can orchestrate truly
heterogenous processes, yet remain simple enough to keep updated with changes to the enterprise.
However, a centralized system also forces compliance, limiting the options when responding to
unexpected events or when attempting to improve the current way of working. A single monolith
system serving a large enterprise, or even complete supply chain, may also become a bottleneck if
overloaded.
227
7.5 Chapter conclusion
Three relatively recent advancements enable the use of business process management technology for
manufacturing operations. Firstly, BPMN is standardized and well-formed, supporting both the
modelling and execution of complex processes. The richness of the notation is remarkably well-suited
for manufacturing operations, with a wide range of events and activity options. Secondly,
advancement in robotic technology allows for more flexible deployment of automation. As robots
continue to become smarter, the extent of instruction required by those robots will decline. A smarter
robot needs less control to perform tasks. Thirdly, the internet-of-things pledges a connected world.
By connecting the humans, robots, sensors and other equipment found in a factory to a central
orchestration system, the system can adapt to changing conditions and endeavour to ensure the most
appropriate resources are assigned to perform activities.
This chapter shows that a process management system can be used to facilitate integration across
levels 2, 3 and 4 of a manufacturing enterprise and that the control can extend down to individual
humans and robots. This capability is demonstrated with three real-world manufacturing cases. The
end-to-end manufacturing processes and selected subprocesses are modelled and enacted, with
activities performed by humans and robots.
228
Chapter 8
8. REFLECTION AND CONCLUSION
The manufacturing industry is experiencing unprecedented disruption. Fluctuating demand and mass
customization compel factory managers to look for new ways to improve manufacturing flexibility. A
manufacturing system must be able to rapidly adapt its operations to produce small volumes of highly
variable products. Fortunately, several emerging technologies are anticipated to deliver the flexibility
so eagerly awaited. More intelligent and versatile industrial robots can perform the larger variety of
actions necessary to produce more product variants. Handheld devices, augmented reality and
collaborative robotics enhance the already considerable proficiency of highly skilled factory workers.
The ubiquitous connectivity promised by the Internet-of-Things and cloud computing enables
improved insight into the state of the manufacturing system and the ability to quickly react to changes.
It is expected that mass customized products will be produced by smart robotics in dynamic processes
managed in the cloud (Zhang et al., 2014).
The new technologies, while promising, introduce a new set of problems to the factory. New
technologies invariably require new knowledge and skills. Incompatibilities with existing systems and
practices in the manufacturing system are also inevitable. Apart from incompatibilities with existing
systems, the new technologies are also not available as a single, integrated package. In fact, the
absence of out-of-the-box solutions that combine the different technologies is considered a primary
impediment on the path towards smart manufacturing (Kang et al., 2016).
Apart from the problems inherent to these technologies, the more pressing concern is the increasing
complexity of manufacturing. A manufacturing system with dynamically changing processes,
populated by versatile robots and augmented humans is incomparable to conventional facilities with
dedicated manufacturing lines. The research presented in this thesis is dedicated to the investigation
of processes in such complex manufacturing systems. This chapter, the last of the thesis, summarises
and concludes the research with the following four sections:
1. A summary of the research presented in this thesis, focussed on how the various
developments contribute towards achievement of the research objective.
2. A discussion on the scientific relevance of the research presented in this thesis, with
emphasis on the scholarly value of the artefacts.
3. A discussion on the societal relevance of the research, with emphasis on the practical value
of the artefacts.
4. Closing remarks and reflection on the research, including limitations and prospects.
229
• Smart manufacturing technologies are under-utilized, because the rigid process design and
management does not encourage rapid reconfiguration and reassignment of resources.
• The number of hardware and software systems continue to increase, based on different
control regimes from different vendors. These systems are difficult to integrate and utilise
together in the same process.
It is argued that current manufacturing process management techniques and technologies are not
well equipped for the flexibility needed in Industry 4.0. These techniques and technologies tend to
focus on localised optimisation and improvement (Cameron and Ingram, 2008; Moro, 2003), rather
than the broader, cross-functional improvement required for increased flexibility. This research takes
the broader perspective and proposes that the application of BPM techniques can be beneficial to
factories seeking increased flexibility. BPM holds several advantages in that it is technology agnostic
(Hepp et al., 2005) and a proven driver of integration (van der Aalst, 2013).
Applying BPM in manufacturing has seen some attention. Its integrative potential has been explored
(Prades et al., 2013; Gerber et al., 2014) and specialised notation extensions have been proposed (Zor
et al., 2011). However, these efforts are rather ad-hoc and isolated. This research takes a more
comprehensive approach by developing the manufacturing process management system (MPMS), an
information system that can be used to manage dynamic manufacturing processes.
ERP system
MES / QMS /
Chapter 4 MMS / WHMS
IF3 IF3
Definition tools
Process Task Process enactment service
Administration
MPMS
IF2 IF2
Chapter 6
Chapter 5 Human agent
Automated
agent control
interface
system
Figure 123: Software aspect of the MPMS architecture, showing the chapters dedicated to its
extensions.
230
The extensions indicated with chapter numbers in Figure 123 are not necessarily software
developments, but rather detailed conceptual investigations on the use of MPMS functionality for
manufacturing operations processes. The following three investigations are presented in Chapters 4
to 6:
This investigation yields a set of model fragments that can be combined to model manufacturing
operations processes. The fragments are depicted using the popular BPMN2.0 standard for modelling
business processes. The fragments are checked for suitability and completeness by modelling and
enacting the processes of all three practical cases described in Chapter 2. The results show strong
support for the use of business processes modelling for both representation and enactment of all
manufacturing processes, including processes that directly contribute value to the product.
231
The results show that the method sufficiently describes the characteristics of resources in terms of
their capability to perform manufacturing tasks. Although the method is time-consuming, it does
provide a remarkable view of the capabilities of resources to perform tasks. The method is also
tailorable, as shown in Section 5.6. The extensibility of the method improves its accessibility by
allowing a factory to only define the resource and activity attributes needed to enable resource
allocation.
As proof of concept, the algorithm is demonstrated in two of the three practical cases. The first case
shows preliminary indications that allocation of resources during process run-time can deliver
performance improvement. The second case demonstrates the capability of the algorithm to allocate
a coalition of multiple agents to a task.
Apart from the individual evaluations of the different artefacts, the MPMS as a whole and the theory
for the exaptation of BPM in smart manufacturing operations were also evaluated in Chapter 7. This
evaluation centres around three diverse, real manufacturing cases that shows that the MPMS can
indeed enable execution of processes populated by humans and industrial robots, supported by new
technologies such as autonomous guided vehicles, augmented reality and collaborative robots.
232
including collaborative robotics and augmented reality. Considering the use of BPM for such
processes, the following two research questions are asked:
1. How can manufacturing operations processes be designed and enacted using established
business process modelling notation?
2. How can resources (human operators and automated agents) be dynamically allocated to
manufacturing activities to improve the ability of the manufacturing system to respond to
changes?
Design science research does not attempt to explain observed phenomena. Instead, the purpose is to
provide knowledge that helps practitioners to perform design activities or solve problems. Thus, the
research questions are answered with packages of prescriptive knowledge named artefacts. The
following artefacts are developed as part of this research (artefacts 1 and 2 correspond to question
one, and artefacts 3 and 4 correspond to question two):
The theory for the exaptation of BPM for manufacturing operations processes is comprised of those
four artefacts. The scientific contribution by this research is, therefore, prescriptive knowledge on the
use of BPM to solve problems encountered in smart manufacturing operations. Scientific rigor is also
ensured with extensive evaluation. All four of the artefacts are individually evaluated with practical
demonstrations and interviews, and the theory as a whole is also evaluated with broad deployment
in an operational factory.
The theory contributes to the BPM scientific domain in two ways. Firstly, it extends the reach of
business process management into the material processes of manufacturing enterprises. This is
demonstrated with the design of executable manufacturing operations processes and the subsequent
enactment of those processes with a process management system based on BPM technology.
Secondly, it provides an extensible framework for the definition of resource and task attributes. This
framework is a product of extensive literature analysis, of both BPM and manufacturing, to be as
exhaustive as is reasonable.
233
2. Smart technologies, such as versatile robots and autonomous guided vehicles, are under-
utilized, because the rigid process design and management does not encourage rapid
reconfiguration and reassignment of resources.
3. The number of hardware and software systems continue to increase, based on different
control regimes from different vendors. These systems are difficult to integrate and utilise
together in the same process.
The artefacts presented in this thesis are exactly targeted at those three practical problems. Problem
1 is addressed in two parts, corresponding to the MPMS and design of processes. Chapter 3 shows
how a single process management system can drive integration in a manufacturing enterprise, by
managing cross-functional processes, regardless of the position in the enterprise. Chapter 4 shows
how established business process modelling notation can be used to design executable processes that
involve both information and material processing. Thus, a single information system can support the
design and enactment of all processes in a manufacturing enterprise.
Problem 2 is also addressed in two parts. First, Chapter 5 presents a method that guides a user to
define the characteristics of humans, robots and other resources. These definitions express the
capacity of the resources to perform tasks in the manufacturing processes. Second, Chapter 6 shows
how the MPMS can use the resource definitions to allocate resources to tasks, during process
execution. This capability can significantly increase the flexibility of a manufacturing system, by enable
dynamic reconfiguration of the resources that perform manufacturing activities. The process model
captures the activities that must be done, then the MPMS takes care of assigning resources to those
activities.
Problem 3 is addressed in Chapter 7 by showing how the MPMS can be used to orchestrate the
activities of humans and various automated agents such as robots and autonomous guided vehicles.
The MPMS, as a core component of the HORSE System, is conjoined with middleware and multiple
robot control systems, to deliver seamless integration across the entire functional hierarchy.
Processes are managed by the MPMS and the individual tasks in the process are allocated to coalitions
of agents, instructed by the MPMS and controlled by their control systems. This prowess positions the
HORSE System well as a reference architecture model of a modern manufacturing operations
management system.
The practical value of the research presented in this thesis is evident, but it is further enhanced by its
involvement with the HORSE Project. This enhancement is further discussed in two parts: 1) The
practical value of the HORSE System, and 2) The accessibility afforded by the option of deploying the
HORSE System, and by extension the MPMS, in the cloud.
The primary objective of the HORSE Project is to make advanced manufacturing technology more
accessible to small and medium enterprises and to solve their flexibility problems, by more
234
dynamically dealing with customized products and demand fluctuation. This objective is achieved by
developing the HORSE System, a modular, complex cyber-physical system that provides horizontal,
cross-functional manufacturing process management and vertical control of heterogenous work cells.
The system embodies the assimilation of traditional enterprise information systems (e.g., explicit
process management) and advanced manufacturing technology (e.g., human-robot collaboration and
the IoT). The HORSE System architecture is proposed as a reference architecture for a manufacturing
operations management system for Industry 4.0. Thus, the architecture model of the HORSE System
can be used as a template or framework to position and develop a commercial-grade manufacturing
operations management system for Industry 4.0.
The applicability of the HORSE System is directly demonstrated by implementing the technology in
three operational factories. Those three factories feature throughout this thesis and serves as
practical demonstration of the MPMS as part of the HORSE System. The HORSE Project is still ongoing,
and the HORSE System will be deployed at an additional seven factories across Europe. As with
previous deployments, the MPMS will continue to play a key part as the orchestrator of the various
technologies built into and controlled by the HORSE System.
Cross-functional, configurable manufacturing process management also opens new ways for smart
manufacturing by supporting flexible process definitions, dynamic allocation of tasks to human and
robotic workers, and real-time coupling of work cell events for manufacturing processes. Such process
management processes also hold promise beyond a single site or enterprise.
Cloud-based process management supports improved interoperability in manufacturing chains
and networks.
8.4.1 Limitations
The design science research approach ensures practical relevance by investigating the problems
encountered in real factories, but it also increases the risk of overlooked problems or missed
opportunities. This risk is mitigated by extensive reference to scientific literature, to extrapolate the
specific problems from the factories to more general problems. However, the manufacturing industry
is large and diverse. Completely unrelated problems may exist in other factories, which may not be
considered in this research. As compensation, the seven additional cases of the HORSE Project will
provide valuable insight into the applicability of BPM for diverse manufacturing processes and to
identify any shortcomings.
235
Regardless of the access afforded by the HORSE Project, the evaluation of the theory on the exaptation
of BPM for manufacturing remains limited. It is simply incredibly difficult and time-consuming to enact
true interventions in operational manufacturing systems. Tests can take several days to set up and
execute, during which the factory suffers undue disruption. It is also infuriatingly difficult to prove
causality in practical cases. There are numerous potential influences on a real-world manufacturing
process, making it difficult to isolate the intervention as the true cause for improvement.
The most prominent shortcoming of the MPMS is a lack of current support among vendors of
manufacturing information systems. Vendors of manufacturing information systems understandably
prefer their own proprietary process management techniques and notations, as they vie for
competitive advantage. Removing core functionality of existing information systems reduces the
prospects where a competitive advantage can be achieved. However, it is exceedingly likely that
process management in manufacturing will be consolidated in dedicated systems, as transpired in
enterprise information systems. The capabilities of industrial-grade, standalone process management
systems will eventually surpass that of manufacturing operations management systems, if this has not
already occurred.
8.4.2 Prospects
The research presented in this thesis provides a compelling case for the use of BPM in smart
manufacturing operations. The research relies on established modelling techniques and process
management technology. The modelling techniques and notations can certainly be enhanced to
improve its expressiveness for the manufacturing domain. For example, the representation and
execution support of material flow and buffers can be added to enhance the suitability of the process
model building blocks presented in Chapter 4. As for the process management technology, a
commercial-grade manufacturing process management system was not created. Instead, a prototype
was developed and implemented to demonstrate the feasibility of a system incorporating cloud
computing, the Internet-of-things, and smart devices. Further complications will undoubtedly arise on
the quest for a commercial-grade system, but, at least, the presented system architecture can serve
as a proven template for such a development.
As for specific improvements to the research, the MPMS gains good responsiveness for the
functionality to allocate resources to tasks during process run-time. However, resource allocation is
only one type of response to a change in the manufacturing process. Process exceptions, such as
emergency situations or equipment malfunctions, may require a different type of response. Although
it falls outside the scope of this research, the MPMS can certainly benefit from improved exception
handling functionality. Such functionality can be bolstered with complex event processing to identify
event patterns or links between seemingly unrelated events. Event processing is enjoying active
research and development (Theorin et al., 2015; Baumgraß et al., 2016), promising significant benefit
to the responsiveness of the MPMS. The responsiveness of the MPMS can also be enhanced by
improving its access to enterprise date. It was not the objective of this research to establish
integration to enterprise information systems, such as the ERP system of MES, but such integration
can further enhance flexibility. If customer orders and the production schedule can automatically be
fed into the MPMS, then the manufacturing system starts to resemble an autonomous system that
configures itself according to the demands placed on it.
236
The cloud-supported nature of the HORSE System, and by extension the MPMS, can improve
interoperability within manufacturing networks where a manufacturing process takes place across
multiple sites or even autonomous enterprises. Software modules that are used in a software-as-a-
service paradigm are typically of a standardized kind so that the same functionality can be used by
multiple parties. Applying functional standardization to the modules of the MPMS can improve
interoperability between multiple manufacturing enterprises that collaborate. Consequently, it may
be simpler to set up supply chains or supply networks with automated support for manufacturing
processes across enterprises.
These technological advances promise to deliver the flexibility needed to produce the personalised
and sophisticated products demanded by consumers. However, new technologies disrupt current
practices and introduce complexity into the manufacturing systems. Gaining benefit from the IoT,
cloud computing and collaborative robotics requires knowledge not typically held by manufacturing
personnel. This thesis provides such knowledge and packaged it into a useful information system
architecture. The provided knowledge can be used to model manufacturing processes, define the
capabilities of resources and realise a process management system that enacts the processes and
allocates resources to the activities in the processes.
237
BIBLIOGRAPHY
Aguilar-Savén, R.S., 2004. Business process modelling: Review and framework. International Journal
of Production Economics 90, 129–149. https://doi.org/10.1016/S0925-5273(03)00102-6
Ahuett-Garza, H., Kurfess, T., 2018. A brief discussion on the trends of habilitating technologies for
Industry 4.0 and Smart manufacturing. Manufacturing Letters 15, 60–63.
https://doi.org/10.1016/j.mfglet.2018.02.011
Alexakos, C., Georgoudakis, M., Kalogeras, A., Charatsis, K., Gialelis, J., Koubias, S., 2006. A model for
the extension of IEC 62264 down to the shop floor layer, in: IEEE International Workshop
on Factory Communication Systems. IEEE, Torino, Italy, pp. 243–246.
https://doi.org/10.1109/WFCS.2006.1704162
Altuger, G., Chassapis, C., 2010. Manual assembly line operator scheduling using hierarchical
preference aggregation, in: Proceedings - Winter Simulation Conference. Department of
Mechanical Engineering, Stevens Institute of Technology, Castle Point on Hudson,
Hoboken, NJ 07030, United States, pp. 1613–1623.
https://doi.org/10.1109/WSC.2010.5678907
Arias, M., Munoz-Gama, J., Sepúlveda, M., 2017. Towards a Taxonomy of Human Resource
Allocation Criteria, in: 15th International Conference on Business Process Management.
Barcelona, Spain, p. 9.
Arias, M., Rojas, E., Munoz-Gama, J., Sepúlveda, M., 2016. A Framework for Recommending
Resource Allocation Based on Process Mining, in: Reichert, M., Reijers, H.A. (Eds.),
Business Process Management Workshops, Lecture Notes in Business Information
Processing. Presented at the International Conference on Business Process Management,
Springer International Publishing, Innsbruck, Austria, pp. 458–470.
https://doi.org/10.1007/978-3-319-42887-1_37
Athawale, V.M., Chakraborty, S., 2011. A comparative study on the ranking performance of some
multi-criteria decision-making methods for industrial robot selection. International Journal
of Industrial Engineering Computations 2, 831–850.
https://doi.org/10.5267/j.ijiec.2011.05.002
Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things: A survey. Computer Networks 54,
2787–2805. https://doi.org/10.1016/j.comnet.2010.05.010
AVIO Consulting, 2013. A Comparison of Pegasystems PegaRULES Process Commander and Oracle
BPM Suite (White paper). AVIO Consulting, USA.
Babulak, E., 2009. Next Generation of Applied Internet Technologies in E-manufacturing, in: 11th
International Conference on Computer Modelling and Simulation. IEEE, Macau, China, pp.
386–390. https://doi.org/10.1109/UKSIM.2009.86
Bahadir, M.C., Satoglu, S.I., 2014. A novel robot arm selection methodology based on axiomatic
design principles. The International Journal of Advanced Manufacturing Technology 71,
2043–2057. https://doi.org/10.1007/s00170-014-5620-2
Bandyopadhyay, T., Steindl, R., Talbot, F., Kottege, N., Dungavell, R., Wood, B., Barker, J., Hoehn, K.,
Elfes, A., 2018. Magneto: A Versatile Multi-Limbed Inspection Robot, in: 2018 IEEE/RSJ
International Conference on Intelligent Robots and Systems (IROS). IEEE, Madrid, Spain,
pp. 2253–2260. https://doi.org/10.1109/IROS.2018.8593891
Banker, R.D., Bardhan, I.R., Chang, H., Lin, S., 2006. Plant Information Systems, Manufacturing
Capabilities, and Plant Performance. MIS Quarterly 30, 315–337.
https://doi.org/10.2307/25148733
Bass, L., Clements, P., Kazman, R., 2013. Software architecture in practice, 3rd ed, SEI series in
software engineering. Addison-Wesley, Upper Saddle River, NJ.
Bauer, A., Wollherr, D., Buss, M., 2008. Human-robot collaboration: A survey. International Journal
of Humanoid Robotics 05, 47–66. https://doi.org/10.1142/S0219843608001303
238
Baumgraß, A., Botezatu, M., Di Ciccio, C., Dijkman, R., Grefen, P., Hewelt, M., Mendling, J., Meyer,
A., Pourmirza, S., Völzer, H., 2016. Towards a Methodology for the Engineering of Event-
Driven Process Applications, in: Reichert, M., Reijers, H.A. (Eds.), Business Process
Management Workshops: BPM 2015, Lecture Notes in Business Information Processing
(LNBIP). Springer International Publishing, Innsbruck, Austria, pp. 501–514.
https://doi.org/10.1007/978-3-319-42887-1_40
Baumgraß, A., Dijkman, R., Grefen, P., Pourmirza, S., Völzer, H., Weske, M., 2015. A Software
Architecture for Transportation Planning and Monitoring in a Collaborative Network, in:
Camarinha-Matos, L.M., Bénaben, F., Picard, W. (Eds.), Risks and Resilience of
Collaborative Networks: 16th IFIP WG 5.5 Working Conference on Virtual Enterprises, IFIP
Advances in Information and Communication Technology. Springer International
Publishing, Cham, pp. 277–284.
Beer, J.M., Fisk, A.D., Rogers, W.A., 2014. Toward a Framework for Levels of Robot Autonomy in
Human-Robot Interaction. Journal of Human-Robot Interaction 3, 27.
https://doi.org/10.5898/JHRI.3.2.Beer
Berente, N., Vandenbosch, B., Aubert, B., 2009. Information flows and business process integration.
Business Process Management Journal 15, 119–141.
https://doi.org/10.1108/14637150910931505
Bessant, J., Caffyn, S., Gallagher, M., 2001. An evolutionary model of continuous improvement
behaviour. Technovation 21, 67–77. http://dx.doi.org/10.1016/S0166-4972(00)00023-7
Bessant, J., Caffyn, S., Gilbert, J., Harding, R., Webb, S., 1994. Rediscovering continuous
improvement. Technovation 14, 17–29. http://dx.doi.org/10.1016/0166-4972(94)90067-1
Bhangale, P.P., Agrawal, V.P., Saha, S.K., 2004. Attribute based specification, comparison and
selection of a robot. Mechanism and Machine Theory 39, 1345–1366.
https://doi.org/10.1016/j.mechmachtheory.2004.05.020
Botelho, S.C., Alami, R., 1999. M+: a scheme for multi-robot cooperation through negotiated task
allocation and achievement, in: Proceedings 1999 IEEE International Conference on
Robotics and Automation (Cat. No.99CH36288C). Presented at the International
Conference on Robotics and Automation, IEEE, Detroit, MI, USA, pp. 1234–1239.
https://doi.org/10.1109/ROBOT.1999.772530
Boulding, K.E., 1956. General Systems Theory - The Skeleton of Science. Management Science 2,
197–208. https://doi.org/10.1287/mnsc.2.3.197
Boyatzis, R.E., 1983. The competent manager: A model for effective performance. Long Range
Planning 16, 110. https://doi.org/10.1016/0024-6301(83)90170-X
Braglia, M., Carmignani, G., Zammori, F., 2006. A new value stream mapping approach for complex
production systems. International Journal of Production Research 44, 3929–3952.
https://doi.org/10.1080/00207540600690545
Brahe, S., 2007. BPM on Top of SOA: Experiences from the Financial Industry, in: Alonso, G., Dadam,
P., Rosemann, M. (Eds.), Business Process Management: 5th International Conference,
Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 96–
111.
Braun, R., Esswein, W., 2014. Classification of Domain-Specific BPMN Extensions, in: The Practice of
Enterprise Modeling, Lecture Notes in Business Information Processing. Springer, Berlin,
Heidelberg, pp. 42–57. https://doi.org/10.1007/978-3-662-45501-2_4
Breaz, R.E., Bologa, O., Racz, S.G., 2017. Selecting industrial robots for milling applications using AHP.
Procedia Computer Science 122, 346–353. https://doi.org/10.1016/j.procs.2017.11.379
Bruque-Cámara, S., Moyano-Fuentes, J., Maqueira-Marín, J.M., 2016. Supply chain integration
through community cloud: Effects on operational performance. Journal of Purchasing and
Supply Management 22, 141–153. https://doi.org/10.1016/j.pursup.2016.04.003
239
Bruyninckx, H., 2001. Open robot control software: the OROCOS project, in: Proceedings of the IEEE
International Conference on Robotics and Automation. IEEE, Seoul, South Korea, pp. 2523–
2528 vol.3. https://doi.org/10.1109/ROBOT.2001.933002
Cabanillas, C., García, J.M., Resinas, M., Ruiz, D., Mendling, J., Ruiz-Cortés, A., 2013. Priority-Based
Human Resource Allocation in Business Processes, in: ICSOC 2013. Presented at the 11th
International Conference Service-Oriented Computing, Springer Berlin Heidelberg, Berlin,
Heidelberg, pp. 374–388. https://doi.org/10.1007/978-3-642-45005-1_26
Cabanillas, C., Resinas, M., Ruiz-Cortés, A., 2012. RAL: A High-Level User-Oriented Resource
Assignment Language for Business Processes, in: Daniel, F., Barkaoui, K., Dustdar, S. (Eds.),
Business Process Management Workshops, Lecture Notes in Business Information
Processing. Presented at the International Conference on Business Process Management,
Springer Berlin Heidelberg, Clermont-Ferrand, France, pp. 50–61.
https://doi.org/10.1007/978-3-642-28108-2_5
Cadavid, J., Alférez, M., Gérard, S., Tessier, P., 2015. Conceiving the Model-driven Smart Factory, in:
Proceedings of the 2015 International Conference on Software and System Process, ICSSP
2015. ACM, New York, NY, USA, pp. 72–76. https://doi.org/10.1145/2785592.2785602
Cameron, I.T., Ingram, G.D., 2008. A survey of industrial process modelling across the product and
process lifecycle. Computers & Chemical Engineering 32, 420–438.
https://doi.org/10.1016/j.compchemeng.2007.02.015
Campion, M.A., Fink, A.A., Ruggeberg, B.J., Carr, L., Phillips, G.M., Odman, R.B., 2011. Doing
competencies well: Best practices in competency modeling. Personnel Psychology 64,
225–262. https://doi.org/10.1111/j.1744-6570.2010.01207.x
Camunda Services GmbH, n.d. Camunda BPM Architecture Overview. URL
https://docs.camunda.org/manual/7.11/introduction/architecture/ (accessed 9.18.16).
Carroll, J.B., 1993. Test Theory and the Behavioral Scaling of Test Performance, in: Test Theory for a
New Generation of Tests. Lawrence Erlbaum Associates, Inc., Hillsdale, N.J., pp. 297–322.
Carvalho, N., Chaim, O., Cazarini, E., Gerolamo, M., 2018. Manufacturing in the fourth industrial
revolution: A positive prospect in Sustainable Manufacturing. Procedia Manufacturing 21,
671–678. https://doi.org/10.1016/j.promfg.2018.02.170
Cattell, R.B., Horn, J.L., 1978. A Check on the Theory of Fluid and Crystallized Intelligence with
Description of New Subtest Designs. Journal of Educational Measurement 15, 139–164.
https://doi.org/10.1111/j.1745-3984.1978.tb00065.x
Centre for Trade Facilitation and Electronic Business, 2001. Codes for modes of transport, Second.
ed. United Nations, Geneva, Switzerland.
Ceroni, J.A., Nof, S.Y., 1999. Robotics Terminology, in: Nof, S.Y. (Ed.), Handbook of Industrial
Robotics. John Wiley & Sons, Inc., Hoboken, NJ, USA, pp. 1259–1317.
https://doi.org/10.1002/9780470172506.gloss
Chang, S.-C., Yang, C.-L., Cheng, H.-C., Sheu, C., 2003. Manufacturing flexibility and business strategy:
An empirical study of small and medium sized firms. International Journal of Production
Economics 83, 13–26. https://doi.org/10.1016/S0925-5273(02)00263-3
Chatterjee, P., Manikrao Athawale, V., Chakraborty, S., 2010. Selection of industrial robots using
compromise ranking and outranking methods. Robotics and Computer-Integrated
Manufacturing 26, 483–489. https://doi.org/10.1016/j.rcim.2010.03.007
Chen, D., 2005. Enterprise-control system integration - an international standard. International
Journal of Production Research 43, 4335–4357.
https://doi.org/10.1080/00207540500142399
Cheng-Leong, A., Pheng, K.L., Leng, G.R.K., 1999. IDEF*: A comprehensive modelling methodology
for the development of manufacturing enterprise systems. International Journal of
Production Research 37, 3839–3858. https://doi.org/10.1080/002075499189790
Chien, S., Barrett, A., Estlin, T., Rabideau, G., 2000. A comparison of coordinated planning methods
for cooperating rovers, in: Proceedings of the Fourth International Conference on
240
Autonomous Agents - AGENTS ’00. Presented at the the fourth international conference,
ACM Press, Barcelona, Spain, pp. 100–101. https://doi.org/10.1145/336595.337057
Chinosi, M., Trombetta, A., 2012. BPMN: An introduction to the standard. Computer Standards &
Interfaces 34, 124–134. http://dx.doi.org/10.1016/j.csi.2011.06.002
Chryssolouris, E.L.K.E., 2006. Manufacturing Systems: Theory and Practice, Second. ed, Mechanical
Engineering Series. Springer-Verlag, New York, USA.
Chung, P.W.H., Cheung, L., Stader, J., Jarvis, P., Moore, J., Macintosh, A., 2003. Knowledge-based
process management—an approach to handling adaptive workflow. Knowledge-Based
Systems 16, 149–160. https://doi.org/10.1016/S0950-7051(02)00080-1
Colombo, A.W., Schoop, R., Neubert, R., 2006. An agent-based intelligent control platform for
industrial holonic manufacturing systems. IEEE Transactions on Industrial Electronics 53,
322–337. https://doi.org/10.1109/TIE.2005.862210
Cottyn, J., Landeghem, H.V., Stockman, K., Derammelaere, S., 2011. A method to align a
manufacturing execution system with Lean objectives. International Journal of Production
Research 49, 4397–4413. https://doi.org/10.1080/00207543.2010.548409
Craggs, S., 2011. Comparing BPM from Pegasystems, IBM and TIBCO. Lustratus Research.
Crosby, P.B., 1979. Quality is free: the art of making quality certain. McGraw-Hill, New York.
Davidsson, P., Henesey, L., Ramstedt, L., Törnquist, J., Wernstedt, F., 2005. An analysis of agent-
based approaches to transport logistics. Transportation Research Part C: Emerging
Technologies 13, 255–271. https://doi.org/10.1016/j.trc.2005.07.002
Davis, F.D., 1989. Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information
Technology. MIS Quarterly 13, 319–340. https://doi.org/10.2307/249008
Davis, J., Edgar, T., Porter, J., Bernaden, J., Sarli, M., 2012. Smart manufacturing, manufacturing
intelligence and demand-dynamic performance. Computers & Chemical Engineering 47,
145–156. http://dx.doi.org/10.1016/j.compchemeng.2012.06.037
Decker, G., Barros, A., 2008. Interaction Modeling Using BPMN, in: Proceedings of the 2007
International Conference on Business Process Management, BPM’07. Springer-Verlag,
Berlin, Heidelberg, pp. 208–219.
Defense Acquisition University, 2011. Integrated Product Support Element Guidebook. Defense
Acquisition University, USA.
Dillmann, R., Friedrich, H., 1996. Programming by demonstration: A machine learning approach to
support skill acquisition for robots, in: Calmet, J., Campbell, J.A., Pfalzgraf, J. (Eds.),
Artificial Intelligence and Symbolic Mathematical Computation, Lecture Notes in Computer
Science. Presented at the International Conference on Artificial Intelligence and Symbolic
Mathematical Computing, Springer Berlin Heidelberg, Steyr, Austria, pp. 87–108.
https://doi.org/10.1007/3-540-61732-9_52
Dilts, D.M., Boyd, N.P., Whorms, H.H., 1991. The evolution of control architectures for automated
manufacturing systems. Journal of Manufacturing Systems 10, 79–93.
https://doi.org/10.1016/0278-6125(91)90049-8
DIN Deutsches Institut für Normung, 2016. Reference Architecture Model Industrie 4.0, First edition.
ed. DIN Deutsches Institut für Normung, Berlin, Germany.
Douaioui, K., Fri, M., Mabroukki, C., Semma, E.A., 2018. The interaction between industry 4.0 and
smart logistics: concepts and perspectives, in: 2018 International Colloquium on Logistics
and Supply Chain Management. IEEE, Tangier, Morocco, pp. 128–132.
https://doi.org/10.1109/LOGISTIQUA.2018.8428300
Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A., 2013. Fundamentals of Business Process
Management, First. ed. Springer Berlin Heidelberg, Berlin, Heidelberg.
ElMaraghy, H.A., 2005. Flexible and reconfigurable manufacturing systems paradigms. International
Journal of Flexible Manufacturing Systems 17, 261–276. https://doi.org/10.1007/s10696-
006-9028-7
241
Erasmus, J., Pretorius, J.-H.C., Wessels, A., 2015. An Integrated Process Framework for Engineering
Endeavours, in: IAMOT 2015 Conference Proceedings. Presented at the 24th Annual
IAMOT Conference, International Association for Management of Technology, Cape Town,
South Africa, pp. 255–272. https://doi.org/10.13140/RG.2.1.2410.5122
Erasmus, J., Vanderfeesten, I., Traganos, K., Grefen, P., 2018. The Case for Unified Process
Management in Smart Manufacturing, in: EDOC 2018. Presented at the 22nd International
Enterprise Distributed Object Computing Conference, IEEE, Stockholm, Sweden, pp. 218–
227. https://doi.org/10.1109/EDOC.2018.00035
Estruch, A., Heredia Álvaro, J.A., 2012. Event-Driven Manufacturing Process Management Approach,
in: Barros, A., Gal, A., Kindler, E. (Eds.), Business Process Management: 10th International
Conference Proceedings, Lecture Notes in Computer Science. Springer Berlin Heidelberg,
Berlin, Heidelberg, pp. 120–133.
EuRoC, 2018. EuRoC Winner announced at Automatica. URL http://www.euroc-
project.eu/index.php?id=168&no_cache=1&tx_ttnews%5Btt_news%5D=124&cHash=14d7
536dd29d574e2fb100a1e48a78e0 (accessed 6.26.19).
Fleischmann, A., Kannengiesser, U., Schmidt, W., Stary, C., 2013. Subject-Oriented Modeling and
Execution of Multi-agent Business Processes, in: 2013 IEEE/WIC/ACM International Joint
Conferences on Web Intelligence (WI) and Intelligent Agent Technologies (IAT). IEEE,
Atlanta, GA, USA, pp. 138–145. https://doi.org/10.1109/WI-IAT.2013.102
Fleischmann, A., Schmidt, W., Stary, C., 2015. Subject-Oriented Business Process Management, in:
vom Brocke, J., Rosemann, M. (Eds.), Handbook on Business Process Management 2:
Strategic Alignment, Governance, People and Culture, International Handbooks on
Information Systems. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 601–621.
https://doi.org/10.1007/978-3-642-45103-4_25
Fleishman, E.A., 1982. Systems for describing human tasks. American Psychologist 37, 821–834.
https://doi.org/10.1037/0003-066X.37.7.821
Fleishman, E.A., 1975. Toward a taxonomy of human performance. American Psychologist 30, 1127–
1149. https://doi.org/10.1037/0003-066X.30.12.1127
Fleishman, E.A., Mumford, M.D., 1991. Evaluating classifications of job behavior: A construct
validation of the ability requirement scales. Personnel Psychology 44, 523–575.
https://doi.org/10.1111/j.1744-6570.1991.tb02403.x
Fleishman, E.A., Reilly, M.E., 1995. Fleishman job analysis survey (F-JAS), First. ed. Management
Research Institute, Bethesda, MD.
Fleishman, E.A., Reilly, M.E., 1992. Handbook of human abilities: Definitions, measurements, and
job task requirements, Handbook of human abilities: Definitions, measurements, and job
task requirements. Consulting Psychologists Press, Palo Alto, CA.
Foster, I., Zhao, Y., Raicu, I., Lu, S., 2008. Cloud Computing and Grid Computing 360-Degree
Compared, in: 2008 Grid Computing Environments Workshop. Presented at the 2008 Grid
Computing Environments Workshop, IEEE, Austin, TX, USA, pp. 1–10.
https://doi.org/10.1109/GCE.2008.4738445
Franklin, S., Graesser, A., 1996. Is It an agent, or just a program?: A taxonomy for autonomous
agents, in: Müller, J.P., Wooldridge, M.J., Jennings, N.R. (Eds.), Intelligent Agents III: Agent
Theories, Architectures, and Languages:, Lecture Notes in Computer Science. Presented at
the ECAI’96 Workshop (ATAL), Springer Berlin Heidelberg, Budapest, Hungary, pp. 21–35.
Garcia, A., Sant’Anna, C., Chavez, C., da Silva, V.T., de Lucena, C.J.P., von Staa, A., 2004. Separation of
Concerns in Multi-agent Systems: An Empirical Study, in: Lucena, C., Garcia, A.,
Romanovsky, A., Castro, J., Alencar, P.S.C. (Eds.), Software Engineering for Multi-Agent
Systems II, Lecture Notes in Computer Science. Presented at the International Workshop
on Software Engineering for Large-Scale Multi-agent Systems, Springer, Portland, OR, USA,
pp. 49–72. https://doi.org/10.1007/978-3-540-24625-1_4
242
García-Domínguez, A., Marcos-Bárcena, M., Medina, I.V., 2012. A comparison of BPMN 2.0 with
other notations for manufacturing processes, in: AIP Conference Proceedings. Presented
at the The 4th Manufacturing Engineering Society International Conference, AIP
Publishing, Cadiz, Spain, pp. 593–600. https://doi.org/10.1063/1.4707613
Gerber, T., Theorin, A., Johnsson, C., 2014. Towards a Seamless Integration Between Process
Modeling Descriptions at Business and Production Levels: Work in Progress. J. Intell.
Manuf. 25, 1089–1099. https://doi.org/10.1007/s10845-013-0754-x
Gerhard, J.F., Rosen, D., Allen, J.K., Mistree, F., 2001. A Distributed Product Realization Environment
for Design and Manufacturing. Journal of Computing and Information Science in
Engineering 1, 235–244. https://doi.org/10.1115/1.1412230
Gerkey, B.P., Matarić, M.J., 2004a. A Formal Analysis and Taxonomy of Task Allocation in Multi-
Robot Systems. The International Journal of Robotics Research 23, 939–954.
https://doi.org/10.1177/0278364904045564
Gerkey, B.P., Matarić, M.J., 2004b. A Formal Analysis and Taxonomy of Task Allocation in Multi-
Robot Systems. The International Journal of Robotics Research 23, 939–954.
https://doi.org/10.1177/0278364904045564
Gerwin, D., 1987. An Agenda For Research on the Flexibility of Manufacturing Processes.
International Journal of Operations & Production Management 7, 38–49.
https://doi.org/10.1108/eb054784
Ghiani, G., Laporte, G., Musmanno, R., 2013. Introducing Logistics, in: Introduction to Logistics
Systems Management. John Wiley & Sons, Ltd, Chichester, UK, pp. 1–43.
https://doi.org/10.1002/9781118492185.ch1
Gilchrist, A., 2016. Industry 4.0: The Industrial Internet of Things, First. ed. Springer Science+Business
Media, New York, NY.
Gomar Jorge E., Haas Carl T., Morton David P., 2002. Assignment and Allocation Optimization of
Partially Multiskilled Workforce. Journal of Construction Engineering and Management
128, 103–109. https://doi.org/10.1061/(ASCE)0733-9364(2002)128:2(103)
Grauer, M., Karadgi, S., Metz, D., Schäfer, W., 2011. Online Monitoring and Control of Enterprise
Processes in Manufacturing Based on an Event-Driven Architecture, in: Muehlen, M., Su, J.
(Eds.), Business Process Management Workshops, Lecture Notes in Business Information
Processing. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 671–682.
Grefen, P., 2016. Business Information System Architecture, Fall 2016. ed. Eindhoven University of
Technology, Eindhoven, The Netherlands.
Grefen, P., 2015. Beyond e-business: Towards networked structures, First. ed. Routledge, Abingdon,
Oxon ; New York, NY.
Grefen, P., Eshuis, R., Mehandjiev, N., Kouvas, G., Weichhart, G., 2009. Internet-based support for
process-oriented instant virtual enterprises. IEEE Internet Computing 13, 65–73.
https://doi.org/10.1109/MIC.2009.96
Grefen, Paul, Mehandjiev, N., Kouvas, G., Weichhart, G., Eshuis, R., 2009. Dynamic business network
process management in instant virtual enterprises. Computers in Industry 60, 86–103.
https://doi.org/10.1016/j.compind.2008.06.006
Grefen, P., Vanderfeesten, I., Boultadakis, G., 2018. Developing a Cyber-Physical System for Hybrid
Manufacturing in an Internet-of-Things Context, in: González García, C., García-Díaz, V.,
García-Bustelo, B.C.P., Lovelle, J.M.C. (Eds.), Protocols and Applications for the Industrial
Internet of Things, Advances in Business Information Systems and Analytics. IGI Global.
https://doi.org/10.4018/978-1-5225-3805-9
Grefen, P., Vanderfeesten, I., Boultadakis, G., 2016. Supporting Hybrid Manufacturing: Bringing
Process and Human/Robot Control to the Cloud (Short Paper), in: Proceedings of the 5th
IEEE International Conference on Cloud Networking (Cloudnet). IEEE, Pisa, Italy, pp. 200–
203. https://doi.org/10.1109/CloudNet.2016.39
243
Gregor, S., Hevner, A.R., 2013. Positioning and Presenting Design Science Research for Maximum
Impact. MIS Q. 37, 337–356.
Grewal, C., 2008. An initiative to implement lean manufacturing using value stream mapping in a
small company. International Journal of Manufacturing Technology and Management 15,
404–417. https://doi.org/10.1504/IJMTM.2008.020176
Groover, M.P., 2016. Principles of modern manufacturing: SI version, 6th ed. John Wiley & Sons,
Singapore.
Groover, M.P., 2011. Fundamentals of modern manufacturing: materials, processes, and systems,
4th ed. J. Wiley & Sons, Hoboken, NJ.
Guilford, J.P., 1956. The structure of intellect. Psychological Bulletin 53, 267–293.
https://doi.org/10.1037/h0040755
Guinard, D., Trifa, V., 2009. Towards the Web of Things: Web Mashups for Embedded Devices, in:
Proceedings of the International World Wide Web Conference 2009. ACM, Madrid, Spain.
Haarmann, S., Podlesny, N.J., Hewelt, M., Meyer, A., Weske, M., 2015. Production case
management: A prototypical process engine to execute flexible business processes, in:
CEUR Workshop Proceedings. Innsbruck, Austria, pp. 110–114.
Haidt, J., 2006. The Happiness Hypothesis: Putting ancient wisdom and philosophy to the test of
modern science. Arrow Books, London.
Hankel, M., Rexroth, B., 2015. The Reference Architectural Model Industrie 4.0 (RAMI 4.0). German
Electrical and Electronic Manufacturers’ Association, Frankfurt am Main, Germany.
Hanson, J.E., Nandi, P., Kumaran, S., 2002. Conversation support for business process integration, in:
Proceedings of the Sixth International Enterprise Distributed Object Computing
Conference. IEEE, Lausanne, Switzerland, pp. 65–74.
https://doi.org/10.1109/EDOC.2002.1137697
Hausman, W.H., Montgomery, D.B., Roth, A.V., 2002. Why should marketing and manufacturing
work together?: Some exploratory empirical results. Journal of Operations Management
20, 241–257. https://doi.org/10.1016/S0272-6963(02)00010-4
Havur, G., Cabanillas, C., Mendling, J., Polleres, A., 2016. Resource Allocation with Dependencies in
Business Process Management Systems, in: La Rosa, M., Loos, P., Pastor, O. (Eds.), Business
Process Management Forum, Lecture Notes in Business Information Processing. Presented
at the International Conference on Business Process Management, Springer International
Publishing, Rio de Janeiro, Brazil, pp. 3–19. https://doi.org/10.1007/978-3-319-45468-9_1
Hayes, B., 2008. Cloud computing. Communications of the ACM 51, 9.
https://doi.org/10.1145/1364782.1364786
He, W., Sun, D., 2013. Scheduling flexible job shop problem subject to machine breakdown with
route changing and right-shift strategies. The International Journal of Advanced
Manufacturing Technology 66, 501–514. https://doi.org/10.1007/s00170-012-4344-4
Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D., 2005. Semantic business process
management: a vision towards using semantic Web services for business process
management, in: IEEE International Conference on E-Business Engineering. IEEE, Beijing,
China, pp. 535–540. https://doi.org/10.1109/ICEBE.2005.110
Herrera, M.E.B., 2015. Creating competitive advantage by institutionalizing corporate social
innovation. Journal of Business Research 68, 1468–1474.
https://doi.org/10.1016/j.jbusres.2015.01.036
Hevner, A.R., March, S.T., Park, J., Ram, S., 2004. Design Science in Information Systems Research.
MIS Quarterly 28, 75–105.
Heyer, C., 2010. Human-robot interaction and future industrial robotics applications, in: IEEE/RSJ
International Conference on Intelligent Robots and Systems. IEEE, Taipei, Taiwan, pp.
4749–4754. https://doi.org/10.1109/IROS.2010.5651294
Hildebrandt, T., Mukkamala, R.R., Slaats, T., 2012. Nested Dynamic Condition Response Graphs, in:
Arbab, F., Sirjani, M. (Eds.), Fundamentals of Software Engineering, Lecture Notes in
244
Computer Science. Springer Berlin Heidelberg, Tehran, Iran, pp. 343–350.
https://doi.org/10.1007/978-3-642-29320-7_23
Hofmann, E., Rüsch, M., 2017. Industry 4.0 and the current status as well as future prospects on
logistics. Computers in Industry 89, 23–34. https://doi.org/10.1016/j.compind.2017.04.002
Hollingsworth, D., 1995. The Workflow Reference Model, 1.1. ed. Workflow Management Coalition,
USA.
Homberg, B.S., Katzschmann, R.K., Dogar, M.R., Rus, D., 2015. Haptic identification of objects using a
modular soft robotic gripper, in: 2015 IEEE/RSJ International Conference on Intelligent
Robots and Systems (IROS). Presented at the 2015 IEEE/RSJ International Conference on
Intelligent Robots and Systems (IROS), pp. 1698–1705.
https://doi.org/10.1109/IROS.2015.7353596
Hommes, B.J., Reijswoud, V. van, 2000. Assessing the quality of business process modelling
techniques, in: Proceedings of the 33rd Annual Hawaii International Conference on System
Sciences. IEEE, HI, USA. https://doi.org/10.1109/HICSS.2000.926591
Howells, J., 2004. Innovation, consumption and services: encapsulation and the combinatorial role of
services. The Service Industries Journal 24, 19–36.
https://doi.org/10.1080/02642060412331301112
Huang, Z., Lu, X., Duan, H., 2012. Resource behavior measure and application in business process
management. Expert Systems with Applications 39, 6458–6468.
https://doi.org/10.1016/j.eswa.2011.12.061
Huang, Z., van der Aalst, W.M.P., Lu, X., Duan, H., 2011. Reinforcement learning based resource
allocation in business process management. Data & Knowledge Engineering 70, 127–145.
https://doi.org/10.1016/j.datak.2010.09.002
IEC, 2013. Enterprise-control system integration - Part 1: Models and terminology, 2nd ed. The
International Electrotechnical Commission (IEC), Geneva, Switzerland.
Illibauer, C., Ziebermayr, T., Geist, V., 2015. Towards Rigid Actor Assignment in Dynamic Workflows,
in: Felderer, M., Piazolo, F., Ortner, W., Brehm, L., Hof, H.-J. (Eds.), Innovations in
Enterprise Information Systems Management and Engineering, Lecture Notes in Business
Information Processing. Presented at the International Conference on Enterprise Resource
Planning Systems, Springer International Publishing, Munich, Germany, pp. 62–69.
https://doi.org/10.1007/978-3-319-32799-0_5
INCOSE, 2015. Systems engineering handbook: a guide for system life cycle processes and activities,
Fourth. ed. John Wiley & Sons, Inc., Hoboken, NJ.
INCOSE Concepts and Terms WG, 1998. INCOSE SE Terms Glossary, First. ed. International Council on
Systems Engineering, Seattle, WA.
International Electrotechnical Commission, 2001. Degrees of protection provided by enclosures (IP
code). International Electrotechnical Commission, Geneva, Switzerland.
International Organization for Standardization, 2015. Quality management systems - Fundamentals
and vocabulary, Fourth. ed. International Organization for Standardization, Switzerland.
Jalali, A., Wohed, P., Ouyang, C., Johannesson, P., 2013. Dynamic Weaving in Aspect Oriented
Business Process Management, in: On the Move to Meaningful Internet Systems: OTM
2013 Conferences, Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin,
Heidelberg, pp. 2–20. https://doi.org/10.1007/978-3-642-41030-7_2
Jarrar, Y.F., Al-Mudimigh, A., Zairi, M., 2000. ERP implementation critical success factors-the role and
impact of business process management, in: Proceedings of the IEEE International
Conference on Management of Innovation and Technology. IEEE, Singapore, pp. 122–127.
https://doi.org/10.1109/ICMIT.2000.917299
Jeschke, S., Brecher, C., Meisen, T., Özdemir, D., Eschert, T., 2017. Industrial Internet of Things and
Cyber Manufacturing Systems, in: Jeschke, S., Brecher, C., Song, H., Rawat, D.B. (Eds.),
Industrial Internet of Things: Cybermanufacturing Systems, Springer Series in Wireless
245
Technology. Springer International Publishing, Cham, pp. 3–19.
https://doi.org/10.1007/978-3-319-42559-7_1
Johnson, M., Bradshaw, J.M., Feltovich, P.J., Jonker, C.M., Van Riemsdijk, M.B., Sierhuis, M., 2014.
Coactive Design: Designing Support for Interdependence in Joint Activity. Journal of
Human-Robot Interaction 3, 43. https://doi.org/10.5898/JHRI.3.1.Johnson
Kabicher-Fuchs, S., Rinderle-Ma, S., 2012. Work Experience in PAIS – Concepts, Measurements and
Potentials, in: Ralyté, J., Franch, X., Brinkkemper, S., Wrycza, S. (Eds.), Advanced
Information Systems Engineering, Lecture Notes in Computer Science. Presented at the
International Conference on Advanced Information Systems Engineering, Springer Berlin
Heidelberg, Gdansk, Poland, pp. 678–694. https://doi.org/10.1007/978-3-642-31095-9_44
Kamara, J.M., Anumba, C.J., Evbuomwan, N.F.O., 2000. Process model for client requirements
processing in construction. Business Process Management Journal 6, 251–279.
https://doi.org/10.1108/14637150010325462
Kamble, S.S., Gunasekaran, A., Gawankar, S.A., 2018. Sustainable Industry 4.0 framework: A
systematic literature review identifying the current trends and future perspectives.
Process Safety and Environmental Protection 117, 408–425.
https://doi.org/10.1016/j.psep.2018.05.009
Kanfer, R., Ackerman, P.L., 1989. Motivation and cognitive abilities: An integrative/aptitude-
treatment interaction approach to skill acquisition. Journal of Applied Psychology 74, 657–
690. https://doi.org/10.1037/0021-9010.74.4.657
Kang, H.S., Lee, J.Y., Choi, S., Kim, H., Park, J.H., Son, J.Y., Kim, B.H., Noh, S.D., 2016. Smart
manufacturing: Past research, present findings, and future directions. International Journal
of Precision Engineering and Manufacturing-Green Technology 3, 111–128.
https://doi.org/10.1007/s40684-016-0015-5
Kannengiesser, U., Müller, H., 2013. Towards Agent-Based Smart Factories: A Subject-Oriented
Modeling Approach, in: 2013 IEEE/WIC/ACM International Joint Conferences on Web
Intelligence (WI) and Intelligent Agent Technologies (IAT). IEEE, Atlanta, GA, USA, pp. 83–
86. https://doi.org/10.1109/WI-IAT.2013.155
Kannengiesser, U., Neubauer, M., Heininger, R., 2015. Subject-Oriented BPM as the Glue for
Integrating Enterprise Processes in Smart Factories, in: Ciuciu, I., Panetto, H., Debruyne, C.,
Aubry, A., Bollen, P., Valencia-García, R., Mishra, A., Fensel, A., Ferri, F. (Eds.), On the Move
to Meaningful Internet Systems: OTM 2015 Workshops, Lecture Notes in Computer
Science. Springer International Publishing, Switzerland, pp. 77–86.
Kapoor, V., Tak, S.S., 2005. Fuzzy Application to the Analytic Hierarchy Process for Robot Selection.
Fuzzy Optimization and Decision Making 4, 209–234. https://doi.org/10.1007/s10700-005-
1890-3
Karande, P., Zavadskas, E.K., Chakraborty, S., 2016. A study on the ranking performance of some
MCDM methods for industrial robot selection problems. International Journal of Industrial
Engineering Computations 399–422. https://doi.org/10.5267/j.ijiec.2016.1.001
Katasonov, A., Kaykova, O., Khriyenko, O., Nikitin, S., Terziyan, V., 2008. Smart semantic middleware
for the internet of things, in: Proceedings of the Fifth International Conference on
Informatics in Control, Automation and Robotics. Madeira, Portugal.
Keyte, B., Locher, D., 2004. The Complete Lean Enterprise: Value Stream Mapping for Administrative
and Office Processes, 1st ed. Productivity Press, New York.
https://doi.org/10.1201/b16650
Khan, A., Turowski, K., 2016. A Perspective on Industry 4.0: From Challenges to Opportunities in
Production Systems:, in: Proceedings of the International Conference on Internet of Things
and Big Data. SCITEPRESS - Science and and Technology Publications, Rome, Italy, pp. 441–
448. https://doi.org/10.5220/0005929704410448
246
Khan, W.A., Raouf, A., Cheng, K., 2011. Augmented Reality for Manufacturing, in: Virtual
Manufacturing, Springer Series in Advanced Manufacturing. Springer London, London, pp.
1–56.
Khandekar, A.V., Chakraborty, S., 2015. Selection of industrial robot using axiomatic design
principles in fuzzy environment. Decision Science Letters 4, 181–192.
https://doi.org/10.5267/j.dsl.2014.12.004
Kim, C.-H., Weston, R.H., Hodgson, A., Lee, K.-H., 2003. The complementary use of IDEF and UML
modelling approaches. Computers in Industry 50, 35–56. https://doi.org/10.1016/S0166-
3615(02)00145-8
Ko, R.K.L., Lee, S.S.G., Lee, E.W., 2009. Business process management (BPM) standards: a survey.
Business Process Management Journal 15, 744–791.
https://doi.org/10.1108/14637150910987937
Kobayashi, T., Tamaki, M., Komoda, N., 2003. Business process integration as a solution to the
implementation of supply chain management systems. Information & Management 40,
769–780. https://doi.org/10.1016/S0378-7206(02)00102-7
Koltai, T., Tatay, V., 2013. Formulation of workforce skill constraints in assembly line balancing
models. Optimization and Engineering 14, 529–545. https://doi.org/10.1007/s11081-013-
9230-x
Koren, Y., Heisel, U., Jovane, F., Moriwaki, T., Pritschow, G., Ulsoy, G., Brussel, H.V., 1999.
Reconfigurable Manufacturing Systems. {CIRP} Annals - Manufacturing Technology 48,
527–540. http://dx.doi.org/10.1016/S0007-8506(07)63232-6
Koren, Y., Shpitalni, M., 2010. Design of reconfigurable manufacturing systems. Journal of
Manufacturing Systems 29, 130–141. http://dx.doi.org/10.1016/j.jmsy.2011.01.001
Korsah, G.A., Stentz, A., Dias, M.B., 2013. A comprehensive taxonomy for multi-robot task allocation.
The International Journal of Robotics Research 32, 1495–1512.
https://doi.org/10.1177/0278364913496484
Koschmider, A., Yingbo, L., Schuster, T., 2011. Role Assignment in Business Process Models, in:
Daniel, F., Barkaoui, K., Dustdar, S. (Eds.), Business Process Management Workshops,
Lecture Notes in Business Information Processing. Presented at the International
Conference on Business Process Management, Springer Berlin Heidelberg, Clermont-
Ferrand, France, pp. 37–49. https://doi.org/10.1007/978-3-642-28108-2_4
Kowalkiewicz, M., Lu, R., Bäuerle, S., Krümpelmann, M., Lippe, S., 2008. Weak Dependencies in
Business Process Models, in: Business Information Systems, Lecture Notes in Business
Information Processing. Presented at the 11th International Conference on Business
Information Systems, Springer Berlin Heidelberg, Innsbruck; Austria, pp. 177–188.
https://doi.org/10.1007/978-3-540-79396-0_16
Kroes, P., Light, A., Moore, S.A., Vermaas, P.E., 2009. Towards an Integrated Philosophical
Understanding, in: Philosophy and Design: From Engineering to Architecture. Springer,
Dordrecht, pp. 1–17.
Kruchten, P.B., 1995. The 4+1 View Model of architecture. IEEE Software 12, 42–50.
https://doi.org/10.1109/52.469759
Krumeich, J., Weis, B., Werth, D., Loos, P., 2014. Event-Driven Business Process Management: where
are we now?: A comprehensive synthesis and analysis of literature. Business Process
Management Journal 20, 615–633. https://doi.org/10.1108/BPMJ-07-2013-0092
Kulkarni, V., Reddy, S., 2003. Separation of concerns in model-driven development. IEEE Software
20, 64–69. https://doi.org/10.1109/MS.2003.1231154
Kumar, A., Dijkman, R., Song, M., 2013. Optimal Resource Assignment in Workflows for Maximizing
Cooperation, in: Daniel, F., Wang, J., Weber, B. (Eds.), Business Process Management,
Lecture Notes in Computer Science. Presented at the 11th International Conference on
Business Process Management, Springer Berlin Heidelberg, Beijing, China, pp. 235–250.
https://doi.org/10.1007/978-3-642-40176-3_20
247
Kumar, A., van der Aalst, W.M.P., Verbeek, E.M.W., 2002. Dynamic Work Distribution in Workflow
Management Systems: How to Balance Quality and Performance. Journal of Management
Information Systems 18, 157–193. https://doi.org/10.1080/07421222.2002.11045693
Kurbel, K.E., 2013. Enterprise Resource Planning and Supply Chain Management, First. ed, Progress
in IS. Springer Berlin Heidelberg, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-
31573-2
Kurtz, C.F., Snowden, D.J., 2003. The New Dynamics of Strategy: Sense-making in a Complex and
Complicated World. IBM Syst. J. 42, 462–483. https://doi.org/10.1147/sj.423.0462
Kusiak, A., 2018. Smart manufacturing. International Journal of Production Research 56, 508–517.
https://doi.org/10.1080/00207543.2017.1351644
Landers, R.G., Min, B.-K., Koren, Y., 2001. Reconfigurable Machine Tools. CIRP Annals -
Manufacturing Technology 50, 269–274. https://doi.org/10.1016/S0007-8506(07)62120-9
Langford, J.W., 2007. Logistics: principles and applications, 2nd ed, McGraw-Hill SOLE Press series.
SOLE Press/McGraw-Hill, New York.
Le-Anh, T., De Koster, M.B.M., 2006. A review of design and control of automated guided vehicle
systems. European Journal of Operational Research 171, 1–23.
https://doi.org/10.1016/j.ejor.2005.01.036
Lee, H.L., Whang, S., 2000. Information sharing in a supply chain. International Journal of
Manufacturing Technology and Management 1, 79–93.
https://doi.org/10.1504/IJMTM.2000.001329
Lee, J., 2015. Smart Factory Systems. Informatik-Spektrum 38, 230–235.
https://doi.org/10.1007/s00287-015-0891-z
Leitão, P., 2009. Agent-based distributed manufacturing control: A state-of-the-art survey.
Engineering Applications of Artificial Intelligence 22, 979–991.
http://dx.doi.org/10.1016/j.engappai.2008.09.005
Lemaire, T., Alami, R., Lacroix, S., 2004. A distributed tasks allocation scheme in multi-UAV context,
in: IEEE International Conference on Robotics and Automation, 2004. Proceedings. ICRA
’04. 2004. Presented at the IEEE International Conference on Robotics and Automation,
2004. Proceedings. ICRA ’04. 2004, IEEE, New Orleans, LA, USA, pp. 3622-3627 Vol.4.
https://doi.org/10.1109/ROBOT.2004.1308816
Lerman, K., Jones, C., Galstyan, A., Matarić, M.J., 2006. Analysis of Dynamic Task Allocation in Multi-
Robot Systems. The International Journal of Robotics Research 25, 225–241.
https://doi.org/10.1177/0278364906063426
Leymann, F., Roller, D., 2000. Production workflow: concepts and techniques. Prentice Hall, Upper
Saddle River, N.J.
Li, G., Hou, Y., Wu, A., 2017. Fourth Industrial Revolution: technological drivers, impacts and coping
methods. Chinese Geographical Science 27, 626–637. https://doi.org/10.1007/s11769-
017-0890-x
Li, Q., Wang, Z., Li, W., Li, J., Wang, C., Du, R., 2013. Applications integration in a hybrid cloud
computing environment: modelling and platform. Enterprise Information Systems 7, 237–
271. https://doi.org/10.1080/17517575.2012.677479
Lin, C.-M., Gen, M., 2008. Multi-criteria human resource allocation for solving multistage
combinatorial optimization problems using multiobjective hybrid genetic algorithm. Expert
Systems with Applications 34, 2480–2490. https://doi.org/10.1016/j.eswa.2007.04.016
Lindley, J.T., Topping, S., Lindley, L.T., 2008. The hidden financial costs of ERP software. Managerial
Finance 34, 78–90. https://doi.org/10.1108/03074350810841277
Lindsay, A., Downs, D., Lunn, K., 2003. Business processes - attempts to find a definition. Information
and Software Technology 45, 1015–1019. https://doi.org/10.1016/S0950-5849(03)00129-0
Liu, Y., Wang, J., Yang, Y., Sun, J., 2008. A semi-automatic approach for workflow staff assignment.
Computers in Industry 59, 463–476. https://doi.org/10.1016/j.compind.2007.12.002
248
Longo, F., Nicoletti, L., Padovano, A., 2017. Smart operators in industry 4.0: A human-centered
approach to enhance operators’ capabilities and competencies within the new smart
factory context. Computers & Industrial Engineering 113, 144–159.
https://doi.org/10.1016/j.cie.2017.09.016
Lu, Y., 2017. Industry 4.0: A survey on technologies, applications and open research issues. Journal
of Industrial Information Integration 6, 1–10. https://doi.org/10.1016/j.jii.2017.04.005
Lu, Y., Morris, K., Frechette, S., 2016. Current Standards Landscape for Smart Manufacturing Systems
(No. NIST IR 8107). National Institute of Standards and Technology, USA.
https://doi.org/10.6028/NIST.IR.8107
Luck, M., d’Inverno, M., 1995. A Formal Framework for Agency and Autonomy, in: Proceedings of
the First International Conference on Multiagent Systems. MIT Press, San Francisco, CA,
USA.
Lucke, D., Constantinescu, C., Westkämper, E., 2008. Smart Factory - A Step towards the Next
Generation of Manufacturing, in: Mitsuishi, M., Ueda, K., Kimura, F. (Eds.), Manufacturing
Systems and Technologies for the New Frontier: The 41st CIRP Conference on
Manufacturing Systems May 26–28, 2008, Tokyo, Japan. Springer London, London, pp.
115–118.
Luthra, S., Mangla, S.K., 2018. Evaluating challenges to Industry 4.0 initiatives for supply chain
sustainability in emerging economies. Process Safety and Environmental Protection 117,
168–179. https://doi.org/10.1016/j.psep.2018.04.018
MacKenzie, D.C., 2013. Collaborative Tasking Of Tightly Constrained Multi-Robot Missions 13.
Macris, A., Papadimitriou, E., Vassilacopoulos, G., 2008. An ontology-based competency model for
workflow activity assignment policies. Journal of Knowledge Management 12, 72–88.
https://doi.org/10.1108/13673270810913630
Malte, B., Florian, H., Andreas, E., Steven, N., 2011. Cross-Functional Integration of R&D, Marketing,
and Manufacturing in Radical and Incremental Product Innovations and Its Effects on
Project Effectiveness and Efficiency. Journal of Product Innovation Management 28, 251–
269. https://doi.org/10.1111/j.1540-5885.2011.00795.x
Mansar, S.L., Reijers, H.A., 2007. Best practices in business process redesign: use and impact.
Business Process Management Journal 13, 193–213.
https://doi.org/10.1108/14637150710740455
March, S.T., Smith, G.F., 1995. Design and natural science research on information technology.
Decision Support Systems 15, 251–266. https://doi.org/10.1016/0167-9236(94)00041-2
Mařík, V. a, McFarlane, D. b, 2005. Industrial adoption of agent-based technologies. IEEE Intelligent
Systems 20, 27–35. https://doi.org/10.1109/MIS.2005.11
Marvel, J.A., Falco, J., Marstio, I., 2015. Characterizing Task-Based Human–Robot Collaboration
Safety in Manufacturing. IEEE Transactions on Systems, Man, and Cybernetics: Systems 45,
260–275. https://doi.org/10.1109/TSMC.2014.2337275
Mavin, A., Wilkinson, P., 2010. Big EARS (The Return of “Easy Approach to Requirements
Engineering”), in: 18th IEEE International Requirements Engineering Conference. IEEE,
Sydney, New South Wales, pp. 277–282. https://doi.org/10.1109/RE.2010.39
Mavin, A., Wilkinson, P., Harwood, A., Novak, M., 2009. Easy Approach to Requirements Syntax
(EARS). Presented at the 17th IEEE International Requirements Engineering Conference,
IEEE, Atlanta, GA, USA, pp. 317–322. https://doi.org/10.1109/RE.2009.9
Medina-Mora, R., Winograd, T., Flores, R., Flores, F., 1992. The Action Workflow Approach to
Workflow Management Technology, in: Proceedings of the 1992 ACM Conference on
Computer-Supported Cooperative Work, CSCW ’92. ACM, New York, NY, USA, pp. 281–
288. https://doi.org/10.1145/143457.143530
Mehrabi, M.G., Ulsoy, A.G., Koren, Y., 2000. Reconfigurable manufacturing systems: Key to future
manufacturing. Journal of Intelligent Manufacturing 11, 403–419.
https://doi.org/10.1023/A:1008930403506
249
Mejía, G., Montoya, C., 2010. Applications of resource assignment and scheduling with Petri Nets
and heuristic search. Annals of Operations Research 181, 795–812.
https://doi.org/10.1007/s10479-010-0686-1
MESA, 1997. MES Functionalities and MRP to MES Data Flow Possibilities (White paper).
Manufacturing Enterprise Solutions Association, Chandler, AZ, USA.
Meyer, A., Herzberg, N., Puhlmann, F., Weske, M., 2014. Implementation Framework for Production
Case Management: Modeling and Execution, in: 18th International Enterprise Distributed
Object Computing Conference. IEEE, Ulm, Germany, pp. 190–199.
https://doi.org/10.1109/EDOC.2014.34
Mishra, R., Pundir, A.K., Ganapathy, L., 2014. Manufacturing Flexibility Research: A Review of
Literature and Agenda for Future Research. Global Journal of Flexible Systems
Management 15, 101–112. https://doi.org/10.1007/s40171-013-0057-2
Misra, G., Kumar, V., Agarwal, A., Agarwal, K., 2016. Internet of Things (IoT) - A Technological
Analysis and Survey on Vision, Concepts, Challenges, Innovation Directions, Technologies,
and Applications. American Journal of Electrical and Electronic Engineering 4, 23–32.
https://doi.org/10.12691/ajeee-4-1-4
Mittal, S., Khan, M.A., Romero, D., Wuest, T., 2017. Smart manufacturing: Characteristics,
technologies and enabling factors. Proceedings of the Institution of Mechanical Engineers,
Part B: Journal of Engineering Manufacture 0954405417736547.
https://doi.org/10.1177/0954405417736547
Modrák, V., Mandulák, J., 2009. Mapping Development of MES Functionalities, in: Proceedings of
the 6th International Conference on Informatics in Control, Automation and Robotics -
Signal Processing, Systems Modeling and Control. Milan, Italy, pp. 244–247.
Moeuf, A., Pellerin, R., Lamouri, S., Tamayo-Giraldo, S., Barbaray, R., 2018. The industrial
management of SMEs in the era of Industry 4.0. International Journal of Production
Research 56, 1118–1136. https://doi.org/10.1080/00207543.2017.1372647
Møller, C., 2005. ERP II: a conceptual framework for next‐generation enterprise systems? Journal of
Enterprise Information Management 18, 483–497.
https://doi.org/10.1108/17410390510609626
Monk, E.F., Wagner, B.J., 2013. Concepts in enterprise resource planning, Fourth. ed. Cengage
Learning, New York.
Monostori, L., 2014. Cyber-physical Production Systems: Roots, Expectations and R&D Challenges.
Procedia CIRP 17, 9–13. https://doi.org/10.1016/j.procir.2014.03.115
Moody, D., 2009. The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual
Notations in Software Engineering. IEEE Transactions on Software Engineering 35, 756–
779. https://doi.org/10.1109/TSE.2009.67
Moody, D.L., 2003. The Method Evaluation Model: A Theoretical Model for Validating Information
Systems Design Methods, in: ECIS 2003 Proceedings. Presented at the European
Conference on Information Systems, Association for Information Systems, Firenze, Italy.
Moreira, A., Rashid, A., Araujo, J., 2005. Multi-dimensional separation of concerns in requirements
engineering, in: Proceedings of the International Conference on Requirements
Engineering. Presented at the 13th IEEE International Conference on Requirements
Engineering, IEEE, Paris, France, pp. 285–296. https://doi.org/10.1109/RE.2005.46
Moro, L.F.L., 2003. Process technology in the petroleum refining industry—current situation and
future trends. Computers & Chemical Engineering 27, 1303–1305.
https://doi.org/10.1016/S0098-1354(03)00054-1
Mosteo, A.R., Montano, L., Lagoudakis, M.G., 2008. Multi-robot routing under limited
communication range, in: 2008 IEEE International Conference on Robotics and
Automation. Presented at the 2008 IEEE International Conference on Robotics and
Automation (ICRA), IEEE, Pasadena, CA, USA, pp. 1531–1536.
https://doi.org/10.1109/ROBOT.2008.4543419
250
Mrotzek, M., Ossimitz, G., 2008. Catastrophe archetypes - using system dynamics to build an
integrated systemic theory of catastrophes, in: 16th Interdisciplinary Information
Management Talks. Presented at the IDIMT 2008 - Managing the Unmanageable,
Jindrichuv Hradec, Czech Republic, pp. 3671–384.
NA 152-06-10 AA National Committee, 2003. DIN 8580:2003-09 Manufacturing processes - Terms
and definitions, 2003rd–09 ed. Beuth Verlag, Berlin, Germany.
Nagorny, K., Colombo, A.W., Schmidtmann, U., 2012. A service- and multi-agent-oriented
manufacturing automation architecture: An IEC 62264 level 2 compliant implementation.
Computers in Industry 63, 813–823. http://dx.doi.org/10.1016/j.compind.2012.08.003
Naumann, E., Jackson, Jr, D.W., 1999. One more time: How do you satisfy customers? Business
Horizons 42, 71–76. http://dx.doi.org/10.1016/S0007-6813(99)80024-X
Nerland, M., Karseth, B., 2015. The knowledge work of professional associations: approaches to
standardisation and forms of legitimisation. Journal of Education and Work 28, 1–23.
https://doi.org/10.1080/13639080.2013.802833
Neubauer, M., Stary, C. (Eds.), 2017. S-BPM in the Production Industry, First. ed. Springer
International Publishing, Cham, Switzerland.
Neubauer, M., Stary, C., Krenn, F., 2014. Subject-oriented process design across organizational
control layers, in: 2014 12th IEEE International Conference on Industrial Informatics
(INDIN). IEEE, Porto Alegre, Brazil, pp. 418–423.
https://doi.org/10.1109/INDIN.2014.6945549
Newman, S.T., Nassehi, A., Xu, X.W., Rosso, R.S.U., Wang, L., Yusof, Y., Ali, L., Liu, R., Zheng, L.Y.,
Kumar, S., Vichare, P., Dhokia, V., 2008. Strategic advantages of interoperability for global
manufacturing using CNC technology. Robotics and Computer-Integrated Manufacturing
24, 699–708. https://doi.org/10.1016/j.rcim.2008.03.002
Nof, S.Y. (Ed.), 1999. Handbook of Industrial Robotics, Second. ed. John Wiley & Sons, Inc., Hoboken,
NJ, USA. https://doi.org/10.1002/9780470172506
Nwankpa, J.K., 2015. ERP system usage and benefit: A model of antecedents and outcomes.
Computers in Human Behavior 45, 335–344. https://doi.org/10.1016/j.chb.2014.12.019
Oberhauser, R., Stigler, S., 2017. Microflows: Enabling agile business process modeling to
orchestrate semantically-annotated microservices, in: Proceedings of the 7th International
Symposium on Business Modeling and Software Design. Barcelona; Spain, pp. 19–28.
Oberweis, A., Schuster, T., 2010. A meta-model based approach to the description of resources and
skills, in: 16th Americas Conference on Information Systems 2010, AMCIS 2010. FZI
Forschungszentrum Informatik, Haid-und-Neustraße 10-14, 76131 Karlsruhe, Germany, pp.
3677–3688.
Object Management Group, 2014. Business Process Model and Notation (BPMN), 2.0.2. ed. Object
Management Group, Inc., USA.
Object Management Group, 2013. Information technology - OMG Business Process Model and
Notation, First. ed. ISO/IEC, Switzerland.
O’Leary-Kelly, S.W., Flores, B.E., 2002. The integration of manufacturing and marketing/sales
decisions: impact on organizational performance. Journal of Operations Management 20,
221–240. https://doi.org/10.1016/S0272-6963(02)00005-0
Olhager, J., 2003. Strategic positioning of the order penetration point. International Journal of
Production Economics 85, 319–329. https://doi.org/10.1016/S0925-5273(03)00119-1
Ouyang, C., Wynn, M.T., Fidge, C., Hofstede, A.H.M. ter, Kuhr, J.-C., 2010. Modelling complex
resource requirements in Business Process Management Systems, in: Rosemann, M.,
Green, P., Rohde, F. (Eds.), ACIS 2010 Proceedings. Presented at the 21st Australasian
Conference on Information Systems, ACIS, Queensland University of Technology, Brisbane.
Oztemel, E., Gursev, S., 2018. Literature review of Industry 4.0 and related technologies. Journal of
Intelligent Manufacturing. https://doi.org/10.1007/s10845-018-1433-8
251
Panetto, H., Molina, A., 2008. Enterprise integration and interoperability in manufacturing systems:
Trends and issues. Computers in Industry 59, 641–646.
https://doi.org/10.1016/j.compind.2007.12.010
Pauker, F., Mangler, J., Rinderle-Ma, S., Pollak, C., 2018. centurio.work - Modular Secure
Manufacturing Orchestration, in: Proceedings of the Dissertation Award, Demonstration,
and Industrial Track at BPM 2018. Presented at the 16th International Conference on
Business Process Management, CEUR-WS.org, Sydney, Australia.
Pereira, A.C., Romero, F., 2017. A review of the meanings and the implications of the Industry 4.0
concept. Procedia Manufacturing 13, 1206–1214.
https://doi.org/10.1016/j.promfg.2017.09.032
Pérez, M.P., Bedia, A.M.S., Fernández, M.C.L., 2016. A review of manufacturing flexibility:
systematising the concept. International Journal of Production Research 54, 3133–3148.
https://doi.org/10.1080/00207543.2016.1138151
Pesic, M., van der Aalst, W.M.P., 2006. A Declarative Approach for Flexible Business Processes
Management, in: Eder, J., Dustdar, S. (Eds.), Business Process Management Workshops,
Lecture Notes in Computer Science. Springer Berlin Heidelberg, Vienna, Austria, pp. 169–
180. https://doi.org/10.1007/11837862_18
Peterson, N.G., Borman, W.C., Mumford, M.D., 1999. An occupational information system for the
21st century: The development of O*NET., Washington. American Psychological
Association, Washington. https://doi.org/10.1037/10313-000
Pika, A., Leyer, M., Wynn, M.T., Fidge, C.J., Hofstede, A.H.M.T., van der Aalst, W.M.P., 2017. Mining
Resource Profiles from Event Logs. ACM Transactions on Management Information
Systems 8, 1:1–1:30. https://doi.org/10.1145/3041218
Piotrowski, N., Barylski, A., 2016. Multi-criteria Robot Selection Problem for an Automated Single-
Sided Lapping System, in: Awrejcewicz, J., Kaliński, K.J., Szewczyk, R., Kaliczyńska, M. (Eds.),
Mechatronics: Ideas, Challenges, Solutions and Applications, Advances in Intelligent
Systems and Computing. Springer International Publishing, pp. 1–13.
https://doi.org/10.1007/978-3-319-26886-6_1
Polderdijk, M., Vanderfeesten, I., Erasmus, J., Traganos, K., Bosch, T., van Rhijn, G., Bennet, D., 2017.
A Visualization of Human Physical Risks in Manufacturing Processes using BPMN, in:
Proceedings of the BPM 2017 Workshops, LNBIP. Presented at the 6th International
Workshop on Theory and Application of Visualizations and Human-centric Aspects in
Processes, Barcelona, Spain.
Pourmirza, S., Peters, S., Dijkman, R., Grefen, P., 2017. A systematic literature review on the
architecture of business process management systems. Information Systems 66, 43–58.
https://doi.org/10.1016/j.is.2017.01.007
Prades, L., Romero, F., Estruch, A., García-Dominguez, A., Serrano, J., 2013. Defining a Methodology
to Design and Implement Business Process Models in BPMN According to the Standard
ANSI/ISA-95 in a Manufacturing Enterprise. Procedia Engineering 63, 115–122.
https://doi.org/10.1016/j.proeng.2013.08.283
Prat, N., Comyn-Wattiau, I., Akoka, J., 2014. Artifact Evaluation in Information Systems Design-
Science Research – A Holistic View, in: Proceeding of the 19th Pacific Asia Conference on
Information Systems. Association for Information Systems, Chengdu, China.
Project Management Institute, 2013. A guide to the project management body of knowledge
(PMBOK guide), Fifth. ed. Project Management Institute, Inc, Newtown Square,
Pennsylvania.
Qin, J., Liu, Y., Grosvenor, R., 2016. A Categorical Framework of Manufacturing for Industry 4.0 and
Beyond. Procedia CIRP 52, 173–178. https://doi.org/10.1016/j.procir.2016.08.005
Qu, T., Lei, S.P., Wang, Z.Z., Nie, D.X., Chen, X., Huang, G.Q., 2016a. IoT-based real-time production
logistics synchronization system under smart cloud manufacturing. The International
252
Journal of Advanced Manufacturing Technology 84, 147–164.
https://doi.org/10.1007/s00170-015-7220-1
Qu, T., Lei, S.P., Wang, Z.Z., Nie, D.X., Chen, X., Huang, G.Q., 2016b. IoT-based real-time production
logistics synchronization system under smart cloud manufacturing. The International
Journal of Advanced Manufacturing Technology 84, 147–164.
https://doi.org/10.1007/s00170-015-7220-1
Ray, S., 2008. Introduction to materials handling. New Age International (P) Ltd., Publishers, New
Delhi.
Reichert, M., 2011. What BPM Technology Can Do for Healthcare Process Support, in: Peleg, M.,
Lavrač, N., Combi, C. (Eds.), Artificial Intelligence in Medicine: 13th Conference on Artificial
Intelligence in Medicine, Lecture Notes in Computer Science. Springer Berlin Heidelberg,
Berlin, Heidelberg, pp. 2–13.
Ren, S., Zhang, Y., Liu, Y., Sakao, T., Huisingh, D., Almeida, C.M.V.B., 2019. A comprehensive review
of big data analytics throughout product lifecycle to support sustainable smart
manufacturing: A framework, challenges and future research directions. Journal of Cleaner
Production 210, 1343–1365. https://doi.org/10.1016/j.jclepro.2018.11.025
Rimal, B.P., Jukan, A., Katsaros, D., Goeleven, Y., 2011. Architectural Requirements for Cloud
Computing Systems: An Enterprise Cloud Approach. Journal of Grid Computing 9, 3–26.
https://doi.org/10.1007/s10723-010-9171-y
Rosen, K.H., 2018. Generating Permutations and Combinations, in: Discrete Mathematics and Its
Applications. McGraw-Hill, New York, NY, p. 938.
Rus, D., Butler, Z., Kotay, K., Vona, M., 2002. Self-reconfiguring Robots. Commun. ACM 45, 39–45.
https://doi.org/10.1145/504729.504752
Russell, N., van der Aalst, W.M.P., Hofstede, A.H.M., Edmond, D., 2005. Workflow Resource
Patterns: Identification, Representation and Tool Support, in: Pastor, O., Falcão e Cunha, J.
(Eds.), Advanced Information Systems Engineering, Lecture Notes in Computer Science.
Presented at the 17th International Conference on Advanced Information Systems
Engineering, Springer Berlin Heidelberg, Porto, Portugal, pp. 216–232.
https://doi.org/10.1007/11431855_16
S. Wang, L. Gong, S. Yan, 2009. The Allocation Optimization of Project Human Resource Based on
Particle Swarm Optimization Algorithm, in: 2009 IITA International Conference on Services
Science, Management and Engineering. IEEE, Zhangjiajie, China, pp. 169–172.
https://doi.org/10.1109/SSME.2009.113
Sakamura, K., 2006. Challenges in the Age of Ubiquitous Computing: A Case Study of T-Engine, an
Open Development Platform for Embedded Systems, in: Proceedings of the 28th
International Conference on Software Engineering, ICSE ’06. Association for Computing
Machinery, New York, NY, USA, pp. 713–720. https://doi.org/10.1145/1134285.1134399
Sale, R.S., Mesak, H.I., Inman, R.A., 2017. A dynamic marketing-operations interface model of new
product updates. European Journal of Operational Research 257, 233–242.
https://doi.org/10.1016/j.ejor.2016.07.051
Salunke, S., Weerawardena, J., McColl-Kennedy, J.R., 2011. Towards a model of dynamic capabilities
in innovation-based competitive strategy: Insights from project-oriented service firms.
Industrial Marketing Management 40, 1251–1263.
https://doi.org/10.1016/j.indmarman.2011.10.009
Sarkis, J., Parsaei, H.R. (Eds.), 1999. Advanced manufacturing systems: strategic management and
implementation, First. ed, Automation and production systems. CRC Press, Amsterdam.
Sawhney, R., 2006. Interplay between uncertainty and flexibility across the value-chain: Towards a
transformation model of manufacturing flexibility. Journal of Operations Management 24,
476–493. https://doi.org/10.1016/j.jom.2005.11.008
Schild, K., Bussmann, S., 2007. Self-organization in Manufacturing Operations. Commun. ACM 50,
74–79. https://doi.org/10.1145/1323688.1323698
253
Schlichter, B.R., Kraemmergaard, P., 2010. A comprehensive literature review of the ERP research
field over a decade. Journal of Enterprise Information Management 23, 486–520.
https://doi.org/10.1108/17410391011061780
Seethamraju, R., 2015. Adoption of Software as a Service (SaaS) Enterprise Resource Planning (ERP)
Systems in Small and Medium Sized Enterprises (SMEs). Information Systems Frontiers 17,
475–492. https://doi.org/10.1007/s10796-014-9506-5
Semini, C., Barasuol, V., Boaventura, T., Frigerio, M., Focchi, M., Caldwell, D.G., Buchli, J., 2015.
Towards versatile legged robots through active impedance control. The International
Journal of Robotics Research 34, 1003–1020. https://doi.org/10.1177/0278364915578839
Senge, P.M., 2006. The fifth discipline: the art and practice of the learning organization, Revised and
updated. ed. Doubleday/Currency, New York.
Senkul, P., Toroslu, I.H., 2005. An architecture for workflow scheduling under resource allocation
constraints. Information Systems 30, 399–422. https://doi.org/10.1016/j.is.2004.03.003
Shawish, A., Salama, M., 2014. Cloud Computing: Paradigms and Technologies, in: Xhafa, F., Bessis,
N. (Eds.), Inter-Cooperative Collective Intelligence: Techniques and Applications, Studies in
Computational Intelligence. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 39–67.
https://doi.org/10.1007/978-3-642-35016-0_2
Shehory, O., Kraus, S., 1998. Methods for task allocation via agent coalition formation. Artificial
Intelligence 101, 165–200. https://doi.org/10.1016/S0004-3702(98)00045-9
Shen, M., Tzeng, G.-H., Liu, D.-R., 2003. Multi-criteria task assignment in workflow management
systems, in: Proceedings of the 36th Annual Hawaii International Conference on System
Sciences. IEEE, Big Island, HI, USA, p. 9. https://doi.org/10.1109/HICSS.2003.1174458
Shewfelt, R.L., 1999. What is quality? Postharvest Biology and Technology 15, 197–200.
http://dx.doi.org/10.1016/S0925-5214(98)00084-2
Snow, R.E., Lohman, D.F., 1984. Toward a theory of cognitive aptitude for learning from instruction.
Journal of Educational Psychology 76, 347–376. https://doi.org/10.1037/0022-
0663.76.3.347
Snowden, D., 2005. Multi-ontology sense making: a new simplicity in decision making. Journal of
Innovation in Health Informatics 13, 45–53. https://doi.org/10.14236/jhi.v13i1.578
Spearman, C., 1927. The abilities of man, The abilities of man. Macmillan, Oxford, England.
Stajkovic, A.D., Luthans, F., 1998. Self-efficacy and work-related performance: A meta-analysis.
Psychological Bulletin 124, 240–261. https://doi.org/10.1037/0033-2909.124.2.240
Stock, J.R., Lambert, D.M., 2001. Strategic logistics management, 4th ed, The McGraw-Hill/Irwin
series in marketing. McGraw-Hill/Irwin, Boston.
Suh, N.P., Cochran, D.S., Lima, P.C., 1998. Manufacturing System Design. CIRP Annals 47, 627–639.
https://doi.org/10.1016/S0007-8506(07)63245-4
Sutton, S.K., Davidson, R.J., 1997. Prefrontal Brain Asymmetry: A Biological Substrate of the
Behavioral Approach and Inhibition Systems. Psychological Science 8, 204–210.
https://doi.org/10.1111/j.1467-9280.1997.tb00413.x
Tainter, J.A., 2000. Problem Solving: Complexity, History, Sustainability. Population and Environment
22, 3–41. https://doi.org/10.1023/A:1006632214612
Takemura, T., 2008. Formal Semantics and Verification of BPMN Transaction and Compensation, in:
IEEE Asia-Pacific Services Computing Conference. IEEE, Yilan, Taiwan, pp. 284–290.
https://doi.org/10.1109/APSCC.2008.208
Tang, C.S., 2010. A review of marketing–operations interface models: From co-existence to
coordination and collaboration. International Journal of Production Economics 125, 22–40.
https://doi.org/10.1016/j.ijpe.2010.01.014
Tao, F., Qi, Q., 2018. New IT Driven Service-Oriented Smart Manufacturing: Framework and
Characteristics. IEEE Transactions on Systems, Man, and Cybernetics: Systems 1–11.
https://doi.org/10.1109/TSMC.2017.2723764
254
Tenhiälä, A., Helkiö, P., 2015. Performance effects of using an ERP system for manufacturing
planning and control under dynamic market requirements. Journal of Operations
Management 36, 147–164. https://doi.org/10.1016/j.jom.2014.05.001
Theorin, A., Bengtsson, K., Provost, J., Lieder, M., Johnsson, C., Lundholm, T., Lennartson, B., 2015.
An Event-Driven Manufacturing Information System Architecture, in: INCOM 2015.
Presented at the 15th IFAC Symposium on Information Control Problems in
Manufacturing, Ottawa, Canada, pp. 547–554.
Thoben, K.-D., Wiesner, S., Wuest, T., BIBA – Bremer Institut für Produktion und Logistik GmbH, the
University of Bremen, Faculty of Production Engineering, University of Bremen, Bremen,
Germany, Industrial and Management Systems Engineering, 2017. “Industrie 4.0” and
Smart Manufacturing – A Review of Research Issues and Application Examples.
International Journal of Automation Technology 11, 4–16.
https://doi.org/10.20965/ijat.2017.p0004
Thurstone, L.L., 1938. Primary mental abilities, Primary mental abilities. Chicago, University of
Chicago Press.
Todd, R., 1994. Manufacturing Processes Reference Guide, 4th ed. Industrial Press, Inc., USA.
Toma, I., Simperl, E., Hench, G., 2009. A joint roadmap for semantic technologies and the internet of
things, in: Proceedings of the Third STI Roadmapping Workshop. Crete, Greece.
Truijens, J., 1990. Informatie-infrastructuur: een instrument voor het management, First. ed. Kluwer
Bedrijfswetenschappen, Deventer.
Tsarouchi, P., Makris, S., Chryssolouris, G., 2016. Human–robot interaction review and challenges on
task planning and programming. International Journal of Computer Integrated
Manufacturing 29, 916–931. https://doi.org/10.1080/0951192X.2015.1130251
Ugarte, B.S. de, Artiba, A., Pellerin, R., 2009. Manufacturing execution system – a literature review.
Production Planning & Control 20, 525–539. https://doi.org/10.1080/09537280902938613
Unver, H.O., 2013. An ISA-95-based manufacturing intelligence system in support of lean initiatives.
The International Journal of Advanced Manufacturing Technology 65, 853–866.
https://doi.org/10.1007/s00170-012-4223-z
US Air Force, 1969. MIL-STD-499 System Engineering Management, First. ed. US Air Force,
Washington, DC.
van der Aalst, W., van Hee, K.M., 2004. Workflow management: models, methods and systems, First.
ed, Cooperative information systems. MIT Press, Cambridge, Mass.
van der Aalst, W.M.P., 2013. Business Process Management: A Comprehensive Survey. ISRN
Software Engineering 2013, 37.
van der Aalst, W.M.P., 1998. The application of Petri nets to workflow management. Journal of
Circuits, Systems and Computers 08, 21–66. https://doi.org/10.1142/S0218126698000043
van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M., 2003. Business Process Management: A
Survey, in: van der Aalst, W.M.P., Weske, M. (Eds.), Business Process Management:
International Conference, BPM 2003, Lecture Notes in Computer Science. Springer Berlin
Heidelberg, Berlin, Heidelberg, p. 12.
Van Gorp, P., Vanderfeesten, I., Dalinghaus, W., Mengerink, J., van der Sanden, B., Kubben, P., 2013.
Towards Generic MDE Support for Extracting Purpose-Specific Healthcare Models from
Annotated, Unstructured Texts, in: Weber, J., Perseil, I. (Eds.), Foundations of Health
Information Engineering and Systems: Second International Symposium, Lecture Notes in
Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 213–221.
Vanderfeesten, I., Erasmus, J., Grefen, P., 2016. The HORSE Project: IoT and Cloud Solutions for
Dynamic Manufacturing Processes, in: Lazovik, A., Schulte, S. (Eds.), ESOCC 2016
Workshops. Springer International Publishing, Vienna, Austria, pp. 303–304.
https://doi.org/10.1007/978-3-319-72125-5
Vanderfeesten, I., Erasmus, J., Traganos, K., Bouklis, P., Garbi, A., Boultadakis, G., Dijkman, R.,
Grefen, P., 2019. Developing process execution support for high tech manufacturing
255
processes, in: Empirical Studies on the Development of Executable Business Processes.
Springer International Publishing.
Vanderfeesten, I., Grefen, P., 2015. Advanced Dynamic Role Resolution in Business Processes, in:
Persson, A., Stirna, J. (Eds.), Advanced Information Systems Engineering Workshops,
Lecture Notes in Business Information Processing. Presented at the International
Conference on Advanced Information Systems Engineering, Springer International
Publishing, Stockholm, Sweden, pp. 87–93. https://doi.org/10.1007/978-3-319-19243-7_8
Verschuren, P., Doorewaard, H., 2010. Designing a research project, 2nd Revised. ed. Eleven
International Publishing, The Hague.
Vojdani, A.F., 2003. Tools for real-time business integration and collaboration. IEEE Transactions on
Power Systems 18, 555–562. https://doi.org/10.1109/TPWRS.2003.810700
von Ammon, R., 2009. Event-Driven Business Process Management, in: Liu, L., Özsu, M.T. (Eds.),
Encyclopedia of Database Systems. Springer US, Boston, MA, pp. 1068–1071.
Wade, M., Hulland, J., 2004. Review: The Resource-Based View and Information Systems Research:
Review, Extension, and Suggestions for Future Research. MIS Q. 28, 107–142.
https://doi.org/10.5555/2017212.2017218
Wang, S., Wan, J., Li, D., Zhang, C., 2016. Implementing Smart Factory of Industrie 4.0: An Outlook.
International Journal of Distributed Sensor Networks 12, 3159805.
https://doi.org/10.1155/2016/3159805
Wang, Y., Ma, H.-S., Yang, J.-H., Wang, K.-S., 2017. Industry 4.0: a way from mass customization to
mass personalization production. Advances in Manufacturing 5, 311–320.
https://doi.org/10.1007/s40436-017-0204-7
Weerdt, J.D., Schupp, A., Vanderloock, A., Baesens, B., 2013. Process Mining for the multi-faceted
analysis of business processes - A case study in a financial services organization.
Computers in Industry 64, 57–67. http://dx.doi.org/10.1016/j.compind.2012.09.010
Weng, S.-J., Cheng, B.-C., Kwong, S.T., Wang, L.-M., Chang, C.-Y., 2011. Simulation Optimization for
Emergency Department Resources Allocation, in: Proceedings of the Winter Simulation
Conference, WSC ’11. Winter Simulation Conference, Phoenix, Arizona, pp. 1231–1238.
Weyer, S., Schmitt, M., Ohmer, M., Gorecky, D., 2015. Towards Industry 4.0 - Standardization as the
crucial challenge for highly modular, multi-vendor production systems. IFAC-PapersOnLine
48, 579–584. https://doi.org/10.1016/j.ifacol.2015.06.143
Witsch, M., Vogel-Heuser, B., 2012. Towards a Formal Specification Framework for Manufacturing
Execution Systems. IEEE Transactions on Industrial Informatics 8, 311–320.
https://doi.org/10.1109/TII.2012.2186585
Wohed, P., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., Russell, N., 2006. On the
Suitability of BPMN for Business Process Modelling, in: Dustdar, S., Fiadeiro, J.L., Sheth,
A.P. (Eds.), Proceedings of the 4th International Conference on Business Process
Management, Lecture Notes in Computer Science. Presented at the International
Conference on Business Process Management, Springer Berlin Heidelberg, Vienna, Austria,
pp. 161–176. https://doi.org/10.1007/11841760_12
Wolstenholme, E.F., 2003. Towards the definition and use of a core set of archetypal structures in
system dynamics. System Dynamics Review 19, 7–26. https://doi.org/10.1002/sdr.259
Woodward, J., 1980. Industrial organization: theory and practice, 2d ed. ed. Oxford University Press,
Oxford ; New York.
Worker at Volkswagen Plant Killed in Robot Accident, 2015. . Associated Press.
Wortmann, F., Flüchter, K., 2015. Internet of Things: Technology and Value Added. Business &
Information Systems Engineering 57, 221–224. https://doi.org/10.1007/s12599-015-0383-
3
Xu, L.D., He, W., Li, S., 2014. Internet of Things in Industries: A Survey. IEEE Transactions on
Industrial Informatics 10, 2233–2243. https://doi.org/10.1109/TII.2014.2300753
256
Xu, L.D., Xu, E.L., Li, L., 2018. Industry 4.0: state of the art and future trends. International Journal of
Production Research 56, 2941–2962. https://doi.org/10.1080/00207543.2018.1444806
Yajun, L., Cecil, J., 2016. An Internet of Things (IoT)-based collaborative framework for advanced
manufacturing. International Journal of Advanced Manufacturing Technology 84, 1141–
1152. https://doi.org/10.1007/s00170-015-7772-0
Yao, X., Zhou, J., Lin, Y., Li, Y., Yu, H., Liu, Y., 2017. Smart manufacturing based on cyber-physical
systems and beyond. Journal of Intelligent Manufacturing.
https://doi.org/10.1007/s10845-017-1384-5
Žabjek, D., Kovačič, A., Štemberger, M.I., 2009. The influence of business process management and
some other CSFs on successful ERP implementation. Business Process Management
Journal 15, 588–608. https://doi.org/10.1108/14637150910975552
Zeithaml, V.A., 1988. Consumer Perceptions of Price, Quality, and Value: A Means-End Model and
Synthesis of Evidence. Journal of Marketing 52, 2–22. https://doi.org/10.2307/1251446
Zeng, D.D., Zhao, J.L., 2005. Effective Role Resolution in Workflow Management. INFORMS Journal
on Computing 17, 374–387. https://doi.org/10.1287/ijoc.1040.0067
Zhang, L., Luo, Y., Tao, F., Li, B.H., Ren, L., Zhang, X., Guo, H., Cheng, Y., Hu, A., Liu, Y., 2014. Cloud
manufacturing: a new manufacturing paradigm. Enterprise Information Systems 8, 167–
187. https://doi.org/10.1080/17517575.2012.683812
Zhong, R.Y., Xu, X., Klotz, E., Newman, S.T., 2017. Intelligent Manufacturing in the Context of
Industry 4.0: A Review. Engineering 3, 616–630.
https://doi.org/10.1016/J.ENG.2017.05.015
Zor, S., Görlach, K., Leymann, F., 2010. Using BPMN for Modeling Manufacturing Processes, in:
Proceedings of 43rd CIRP International Conference on Manufacturing Systems. pp. 515–
522.
Zor, S., Schumm, D., Leymann, F., 2011. A Proposal of BPMN Extensions for the Manufacturing
Domain, in: Proceedings of the 44th CIRP International Conference on Manufacturing
Systems.
Zur Muehlen, M., 2004. Organizational Management in Workflow Applications – Issues and
Perspectives. Information Technology and Management 5, 271–291.
https://doi.org/10.1023/B:ITEM.0000031582.55219.2b
257
APPENDIX A: TERMS AND ABBREVIATIONS
Table 61 provides definitions for terms that feature prominently in this thesis and Table 62 clarifies
abbreviations used.
Table 61: Definitions for terms that feature prominently in the thesis.
258
Table 62: Clarification of abbreviations used in this thesis.
Abbreviation Meaning
APA Automotive Parts Assembly (anonymised company name)
API Application programming interface
BPM Business process management
BPMN Business process model & notation
BPMS Business process management system
CMMN Case management model & notation
DBMS Database management system
DMN Decision model & notation
HEG HORSE Exec Global
HEL HORSE Exec Local
F/NF Functional / Non-functional
ICT Information and communication technology
IT Information technology
MPMS Manufacturing process management system
PF Process function
POJO Plain old Java object
REST Representational state transfer
SCF Sand-Casting Foundry (anonymised company name)
SF System function
TRI Thomas Regout International
259
APPENDIX B: TAXONOMY OF HUMAN ABILITIES
The full Taxonomy of Human Abilities (Fleishman, 1975) is copied here for convenience.
260
261
262
263
APPENDIX C: FLEISHMAN JOB APPLICATION
SURVEY
The full Fleishman Job Application Survey (F-JAS) is included here for convenience.
264
Instructions for Making Abilities Ratings
These questions are about job-related activities. An ability is an enduring talent that can
help a person do a job. You will be asked about a series of different abilities and how
they relate to your current job – that is the job you hold now.
For example:
You are then asked to answer two questions about that ability:
For example:
*If you rate the ability as Not Important to the performance of your job,
mark the one [ 1 ] then skip over question B and proceed to the next ability.
To help you understand what we mean by level, we provide you with examples of
job-related activities at different levels for each ability. For example:
1 2 3 4 5 6 7
Highest Level
Mark your answer by putting an X through the number that represents your answer.
Do not mark on the line between the numbers.
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Name four different Think of as many ideas as Name all the possible strategies
uses for a screwdriver possible for the name of a new company for a military battle
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Decide what to wear Determine the prime suspect Diagnose a disease using
based on the weather report based on crime scene evidence results of many different lab tests
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Remember the number on your bus to Recite the first names of the Recite the Gettysburg Address
to be sure you get back on the right one five people you just met after studying it for 15 minutes
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
22. Arm-Hand Steadiness The ability to keep your hand and arm
steady while moving your arm or while
holding your arm and hand in one
position.
Cut facets
Light a candle Thread a needle in a diamond
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
B. What level of SPEED OF LIMB MOVEMENT is needed to perform your current job?
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Sit up in an office chair Shovel snow for half an hour Do 100 sit-ups
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
B. What level of GROSS BODY COORDINATION is needed to perform your current job?
Get in and out of a truck Swim the length of a pool Perform a ballet dance
1 2 3 4 5 6 7
Highest Level
40. Gross Body Equilibrium The ability to keep or regain your body
balance or stay upright when in an
unstable position.
B. What level of GROSS BODY EQUILIBRIUM is needed to perform your current job?
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Detect differences in
Read a roadside billboard Focus a slide projector ships on the horizon
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Read street signs at dusk Take notes during Find your way through the
(just before sunset) a slide presentation woods on a moonless night
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Merge a car into traffic Operate a crane to move materials Throw a long pass to a
on a city street from a truck bed to the ground closely guarded teammate
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
50. Sound Localization The ability to tell the direction from which
a sound originated.
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
1 2 3 4 5 6 7
Highest Level
Table 63: Full list of robot attributes retrieved during the SLR.
292
This is the measure of displacement
of the end effector in response to Kapoor and Tak
Compliance force (or torque) applied to it. (2005) 5
Computational
Capacity 1
Computational
Complexity of
dynamic
equations 1
Configuration of
robot 1
The place (base, ceiling, wall) where
the robot arm is settled. The facility
layout, constraints, and obstacles are
Connection taken into account to choose the Bahadir and Satoglu
type connection type (2014) 1
Control of
Robotic Joints 2
Control
Technologies 1
Convenience of
use 1
Convertibility
(design for
functionality How easy to change robot for
changes) different functionalities Common sense 1
Coordinate
System 1
How much energy is used by the
Cost of energy robot Common sense 1
Cost of Feeder Cost of the feeder Common sense 1
Cost of Gripper
Mechanics Cost of the mechanics of the gripper Common sense 1
Cost of sensors Cost of sensors in the robot Common sense 1
Customization
product
Delivery 1
Defect
prevention
handling parts 1
A term used to describe a robot’s
freedom of motion in three-
dimensional space, specifically the
ability to move forward and
Degree of backward, up and down, and to the Bahadir and Satoglu
freedom left and to the right (2014) 8
Degree of protection denotes the
Degree of protection provided by an enclosure Khandekar and
protection against access to hazardous parts, Chakraborty (2015) 1
293
ingress of solid foreign objects and
water.
Delivery Time 1
Depreciation
Costs Depreciation cost over time. Common sense 2
Depreciation of
robot Depreciation over time. Common sense 1
The dexterity of industrial robots,
introduced here as C6, has many
definitions in the literature. Mainly, it
can be considered as the ability to
change position and orientation of
the end effector, between two
different configurations of the
Dexterity robotic structure Breaz et al. (2017) 2
dexterous
workspace 1
DH parameters 1
Dissemblability 1
How long/often is the robot
Downtime unavailable Common sense 2
Piotrowski and
Drive Systems Electric/Hydraulic Barylski (2016) 3
Efficiency 1
Electrical Drive
System 1
Environmental Impact that the robot has on its
Impact environment during operation. Common sense 2
Environmental
Performance 1
Exposure to
operator Unrest 1
External state
sensors 1
Favorable
Appearance and
Proper
Structure 1
Footprint is the amount of space Khandekar and
Footprint required for installing a robot. Chakraborty (2015) 1
Force and
Torque sensors 1
Force Output 1
Force-position
(compliance)
Control 1
Functionality 1
294
Geometrical
Dexterity 2
Gripper Control 2
Gripper
parameters
(Fantoni) 1
The value of handling coefficient can
be determined from various features,
like diameter (in mm), elevation (in
mm), basic rotation (in degree), roll
(in degree), pitch (in degree) and yaw
(in degree). The diameter, elevation
and basic rotation are related to the
work area to a robot arm, whereas,
roll, pitch and yaw are related to
Handling rotational angles of the robot wrist Karande et al.
Coefficient about the three principal axes. (2016) 3
Horizontal Reach of the robot of the horizontal
Reach axis. Common sense 1
Hydraulic drive
System 1
Implementation
easiness 1
Inconsistency
with
infrastructure 1
Input channels 1
Insurance Cost Cost for the insurance Common sense 1
Integrated with
a PC 1
Internal state
sensors 1
Joint
Orientations 1
Joint Sequence 1
L axis Max
Speed and
Range 1
Learning 1
Duration which the robot is expected
Life expectancy to maintain full performance. Common sense 1
Link cross
sections 1
Link length
Ratios 1
Link Masses and
inertia
properties 1
295
Load capacity is the maximum load
that a manipulator can carry without Athawale and
Load Capacity affecting its performance. Chakraborty (2011) 35
Maintainability
and Safety
Features 1
Maintainability/
regular
maintenance 4
Maintenance
Costs Cost for maintaining the robot Common sense 4
Manipulability
measure 1
Manipulator 1
Manipulator reach is the maximum
distance that can be covered by the
robotic manipulator so as to grasp
Manipulator objects for the given pick-n-place Athawale and
Reach operation. Chakraborty (2011) 9
Man-machine
interface 13
Material Of Material that the robot is covered
robot with. Common sense 1
Material used Material that the links are covered
for links with. Common sense 1
Maximum end
Effectors speed Same as Maximum Tip Speed Common sense 1
Maximum joint Speed of which a robot can position Khandekar and
speed its arm/actuator. Chakraborty (2015) 1
Maximum
speed end Maximum speed at which the robot
effector can move its end effector. Common Sense 1
Maximum tip speed is the speed at
Maximum Tip which a robot can move in an inertial Athawale and
Speed reference frame. Chakraborty (2011) 11
Means used for
rotary to linear
motion
conversion 1
Means used for
rotary to rotary
motion
conversion 1
Memory capacity of a robot is
measured in terms of number of
points or steps that it can store in its
Memory memory while traversing along a Athawale and
Capacity predefined path. Chakraborty (2011) 11
Motion 1
296
Motion
transformation
from actuator
to link 1
Mounting
Arrangement 1
Mounting position represents the
ability of a robot to fasten it securely
Mounting on a given surface during the working Khandekar and
Position cycle, Chakraborty (2015) 1
Natural
Frequency 1
Noise Delivery Noise output during operation. Common sense 1
Number of Axes Similar to degrees of freedom Common sense 3
Number of end Number of tips that the robot can
effectors use to manipulate something. Common sense 1
Number of in
and output
channels of the
controller 2
Number of The number of joints that the robot
joints has. Common sense 1
Number of The number of offset joints that the
offset joints robot has. Common sense 1
online and
offline
programming 1
Online Program
correction 1
Operation Costs Cost for running the robot Common sense 4
Duration that the robot can operate
Operation Time continuously. Common sense 1
Output
channels 1
Overall
Flexibility 1
Overall
Performance 1
Overload
capacity of the Maximum capacity that the robot can
robot lift. Common sense 1
Part Delivery
Position
Accuracy 1
Path Correction
Facilities 1
Path Measuring
Systems 2
297
How well a robot can come back to a
Position programmed location and Khandekar and
Repeatability orientation over and over. Chakraborty (2015) 1
Positioning
Accuracy 9
Power 1
Power
Consumption How much power does the robot use Common sense 2
Power Source Type of power delivery that the robot
Requirement needs. Common sense 1
Precision 1
Processor 2
Productivity 2
Program steps 1
while programming flexibility refers
Programming to a robot’s ability to accept different Chatterjee et al.
Flexibility programming codes. (2010) 19
Programming
Method 3
A term stating the durability which is
supported by enclosure of electrical
equipment towards environmental Bahadir and Satoglu
Protection class conditions (2014) 1
Purchase Cost Acquisition cost of the robot. Common sense 27
Quality Aspect 1
R axis Max
Speed and
Range 1
RAM 1
Range of Joint
Motions 1
Reach Reach in vertical, horizontal… Common sense 2
Reaction Speed 1
Recommended
Operating Recommended humidity around the
Humidity robot. Common sense 1
Such as reliability can be expressed
by Mean Time Between Failure
(MTBF) or Mean Time To Repair Bhangale et al.
Reliability (MTTR) (2004) 5
Repeatability is the measure of the
ability of a robot to return to the
same position and orientation over Athawale and
Repeatability and over again. Chakraborty (2011) 25
Repeatability
Error 4
298
Resolution 2
Rest Time 1
Risk 1
Robot arm
configuration 1
Robotic Arc
Welding
sensors 1
ROM 1
Runtime 1
S axis Max
Speed and
Range 1
Safety 3
Scheduling
Utilization 1
Sensing
Distribution 1
Sensing
Quantity 1
Sensing Range 1
Sensitivity 1
Sensors 1
Service 1
Simplicity 1
Simulation
Software 1
Singularities
present 1
Size of the
robot Size of the robot Common sense 4
Any slip sensors that the robot might
Slip Sensors have. Common sense 1
Space
Requirements 2
Speed 1
Spline
Interpolation 1
This is the measure of absence of
oscillations at termination of arm Kapoor and Tak
Stability movement. (2005) 5
Stroke 2
Supporting
Channel 2
299
Partner's
performance
T axis Max
Speed and
Range 1
Any tactile sensors that the robot
Tactile Sensors might have. Common sense 1
Teach-in play-
back
programming
technology 1
Technical
Features 2
Terrain Terrain over which the robot can
Traversability traverse. Common sense 1
Total Cost of
Layout 1
Training
Delivery Period Delivery time of the training Common sense 1
Travelling Time 1
Type of Type of actuators that the robot can
Actuators use. Common sense 2
Type of basic
robot
configurations 1
Type of Cables
used 1
Type of Control The type of control system that the
System robot has. Common sense 1
Type of end
effectors Type of end effectors used. Common sense 1
Type of flexible
drive system
used 1
Type of gear
train used 1
Type of gears
used for power
transmission 1
Type of grippers Which grippers that the robot can
supported use. Common sense 2
Type of Joints Type of joints that the robot has. Common sense 2
Type of
memory 1
Type of Robot 1
U axis Max
Speed and
Range 1
Usage of Robot 1
300
User Support 1
Athawale and
Velocity Is used as Maximum Tip Speed in 1 Chakraborty (2011) 20
Velocity Ratio 2
Vendor's Vendor’s service quality refers to the
Service level and variety of services offered Chatterjee et al.
(Contract) by a robot vendor. (2010) 14
Vendor's
training 1
Versions of
robot
Installations 1
Vertical reach Vertical reach of the robot Common sense 4
Vibration aspect 1
Warranty 2
Weight Of the
Robot 7
Working
Automation 1
Working
Environment 2
Working range
of joints 1
Workspace Workspace needed by the robot. Common sense 1
Maximum distance in which the end
Wrist reach effector of the robot arm reaches in Bahadir and Satoglu
distance the work envelop (2014) 1
301
APPENDIX E: EXCLUDED ROBOT ATTRIBUTES
This appendix lists the attributes excluded during the analysis documented in section 5.4.2.3 of
chapter 5. Five tables are presented for the five rules applied during the analysis.
Table 64: Eleven attributes Excluded because they are too abstract.
Attribute Description
Functionality
Motion
Online and offline
programming
Overall Performance
Programming Flexibility Programming flexibility refers to a robot’s ability to accept
different programming codes.
Quality Aspect
Risk
Safety Safety of the robot for the user.
Sensors Sensors
Technical Features General term for some technical features.
Usage of Robot The usage of the robot.
Table 65: 58 attributes Excluded because they are a subset of another attribute.
302
Attribute Description Subset of
Cost of sensors Cost of sensors in the robot Purchase Cost
Depreciation Cost of depreciation Operation Costs
Costs
Dexterous Dexterity
workspace
Dissemblability How easy to dissemble Adaptability
Downtime How long/often is the robot unavailable Reliability
Electrical Drive Drive System Drive Systems
System
Footprint Footprint is the amount of space required for installing Space Requirements
a robot.
Force and Sensors Tactile Sensors
Torque sensors
Geometrical Same as dexterity? Dexterity
Dexterity
Hydraulic drive Drive System Drive Systems
System
Input channels Controller Number of in and
output channels of
the controller
Insurance Cost Cost for the insurance Operation Costs
L axis Max Speed and Range of certain Axis Speed and Reach,
Speed and respectively.
Range
Link cross Degrees of Freedom
sections
Link length Reach
Ratios
Material used Material of the robot Material of Robot
for links
Maximum joint joint speed is defined as how quickly a robot can Maximum Tip Speed
speed position its arm/actuator.
Number of Sort of Same as degree of freedom Degrees of Freedom
Axes
Number of Joints Degrees of Freedom
joints
Number of Joints Number of Joints
offset joints
Output Controller Number of in and
channels output channels of
the controller
Overall Degrees of Freedom
Flexibility
Part Delivery Accuracy
Position
Accuracy
Path Accuracy
Correction
Facilities
303
Attribute Description Subset of
Position position repeatability is articulated as how well a robot Repeatability
Repeatability can come back to a programmed location and
orientation over and over again.
Positioning Probably same as accuracy Accuracy
Accuracy
Power Power needed Power Consumption
Programming Programming Method Programming
Method Flexibility
Purchase Cost Cost for buying the robot Operation Costs
R axis Max Speed and Range of certain Axis Speed and Reach,
Speed and respectively.
Range
Reaction Speed Velocity
Repeatability Same as Repeatability? Repeatability
Error
Robotic Arc Sensors External State
Welding Sensors
sensors
S axis Max Speed and Range of certain Axis Speed and Reach,
Speed and respectively.
Range
Size of the Size of the robot Space Requirements
robot
Speed Velocity Maximum Tip Speed
T axis Max Speed and Range of certain Axis Speed and Reach,
Speed and respectively.
Range
Total Cost of Cost Purchase Cost
Layout
Travelling Time Velocity
Type of Which grippers are supported at the robot type of End
grippers Effectors
supported
U axis Max Speed and Range of certain Axis Speed and Reach,
Speed and respectively.
Range
Velocity Is used as Maximum Tip Speed Maximum Tip Speed
Velocity Ratio Velocity
Vibration Accuracy
aspect
Working range Combination of Degrees of Freedom and Reach Degrees of Freedom
of joints
304
Table 66: Fifteen attributes excluded because they are a duplicate of another attribute.
Table 67: Nine attributes Excluded because they are a superset of other attributes.
305
rotational angles of the robot wrist about the three
principal axes.
Maintainability
Maintainability and
and Safety Maintainability
Safety
Features
Mechanism, usually consisting of a series of
segments, or links, jointed or sliding relative to one
another, for grasping and moving objects, usually in
Combination of
Manipulator several degrees of freedom. It is remotely
many attributes.
controlled by a human (manual manipulator) or a
computer (programmable manipulator). The term
refers mainly to the mechanical aspect of a robot.
Manipulator reach is the maximum distance that
Manipulator Horizontal and
can be covered by the robotic manipulator so as to
Reach Vertical Reach
grasp objects for the given pick-n-place operation.
Accuracy,
A general concept reflecting the robot’s accuracy,
Precision repeatability and
repeatability, and resolution.
resolution.
Number of actions that can be performed in a time Maximum tip speed,
Productivity
unit. traversability.
Ambient
Temperature and
Working
other
Environment
environmental
factors
Table 68: Thirteen attributes excluded because they describe a component, rather than an output
or capability.
Attribute
Cable layout
Configuration of robot
Control Technologies
Favorable Appearance and Proper Structure
Integrated with a PC
Link Masses and inertia properties
Online Program correction
Program steps
Robot arm configuration
Simulation Software
Teach-in play-back programming technology
Type of basic robot configurations
Type of gears used for power transmission
306
APPENDIX F: DEGREE OF PROTECTION
To describe the degree of protection of an agent, an IP code can be created in the format of IPxx. To
fill in the x’s, use the following tables.
307
APPENDIX G: LEVEL OF AUTONOMY
308
APPENDIX H: AGENT DEFINITION FORM
Dear participant,
Thank you in advance for participating in this evaluation. The objective of this research is to develop
a method to describe agents and tasks, to determine which agent can perform a manufacturing task.
Figure 124 shows an overview of the method, with three steps to describe tasks and agents,
respectively.
Task
Performed for each Performed for each Task-related
data table
task that requires run- attribute required to data tables
time allocation perform the task
T1: Identify T3: Determine
task(s) which T2: Describe the the required
require task value for each
allocation attribute
Start End
A1: Identify A3: Determine
A2: Describe the
agent(s) for the value of
agent
allocation each attribute
This form is used to capture the agent attributes and is therefore the output of step A3 of the method.
To evaluate the method, I ask that you fill in this form, describing an agent to the best of your ability.
Thereafter, please rate the method on usefulness, ease of use and intention to use. This evaluation is
based on the validated Method Evaluation Model (Moody, 2003).
If you have any comments regarding the attributes (e.g. unclear, missing) or the form itself (e.g.
difficult to use), please add those comments on page 8. I will use those comments to reflect on the
research and its outcomes. Lastly, if any information is confidential, please mark it as such and I will
ensure that it is never published in the public domain. In such a case, I guarantee that I will be the only
observer of that information.
Agent description
Please fill in the Table 69 to identify the agent under consideration. Next, go through all the attributes,
starting from page 2 and try to fill in those attributes of this agent. Lastly, fill in the three questions
on page 7. Comments regarding this form can be filled in on page 8.
309
Table 69: Agent identification information.
Agent name
Agent type
Agent description
Organisation
Completed by
Date of completion
Signature of person
who completed the
form
Agent attributes
An agent is defined as any entity (human or machine) that can act independently (Luck and d’Inverno,
1995). Independence in this case refers to whether the object is self-directed. A human operator
working under supervision is an agent, even under direct coaching. Similarly, a robot that executes
operations as received by its control system is an agent. However, a drilling machine operated by a
human operator is not an agent, but rather a tool.
Agents are described in terms of attributes to enable dynamic allocation to tasks during process run-
time. The following categories of attributes can be used to describe agents: authorization, tenancy,
ability, terrain traversability, functional and non-functional. All attributes do not have to be completed
for each agent, but bear in mind that an agent will only be considered for a task if it possesses all
attributes required for that task.
Authorization
List all authorizations that the agent has.
Tenancy
List all locations that the agent has access to.
Ability
State the level of all abilities that an agent possesses.
310
2 Written Cognitive The ability to read and understand information
Comprehensi Abilities and ideas presented in writing.
on
3 Oral Cognitive The ability to communicate information and
Expression Abilities ideas in speaking so others will understand.
4 Written Cognitive The ability to communicate information and
Expression Abilities ideas in writing so others will understand.
5 Fluency of Cognitive The ability to come up with a number of ideas
Ideas Abilities about a topic (the number of ideas is
important, not their quality, correctness, or
creativity).
6 Originality Cognitive The ability to come up with unusual or clever
Abilities ideas about a given topic or situation, or to
develop creative ways to solve a problem.
7 Problem Cognitive The ability to tell when something is wrong or
Sensitivity Abilities is likely to go wrong. It does not involve solving
the problem, only recognizing there is a
problem.
8 Deductive Cognitive The ability to apply general rules to specific
Reasoning Abilities problems to produce answers that make sense.
9 Inductive Cognitive The ability to combine pieces of information to
Reasoning Abilities form general rules or conclusions (includes
finding a relationship among seemingly
unrelated events).
10 Information Cognitive The ability to arrange things or actions in a
Ordering Abilities certain order or pattern according to a specific
rule or set of rules (e.g., patterns of numbers,
letters, words, pictures, mathematical
operations).
11 Category Cognitive The ability to generate or use different sets of
Flexibility Abilities rules for combining or grouping things in
different ways.
12 Mathematical Cognitive The ability to choose the right mathematical
Reasoning Abilities methods or formulas to solve a problem.
13 Number Cognitive The ability to add, subtract, multiply, or divide
Facility Abilities quickly and correctly.
14 Memorizatio Cognitive The ability to remember information such as
n Abilities words, numbers, pictures, and procedures.
15 Speed of Cognitive The ability to quickly make sense of, combine,
Closure Abilities and organize information into meaningful
patterns.
16 Flexibility of Cognitive The ability to identify or detect a known
Closure Abilities pattern (a figure, object, word, or sound) that
is hidden in other distracting material.
17 Perceptual Cognitive The ability to quickly and accurately compare
Speed Abilities similarities and differences among sets of
letters, numbers, objects, pictures, or patterns.
The things to be compared may be presented
at the same time or one after the other. This
311
ability also includes comparing a presented
object with a remembered object.
18 Spatial Cognitive The ability to know your location in relation to
Orientation Abilities the environment or to know where other
objects are in relation to you.
19 Visualization Cognitive The ability to imagine how something will look
Abilities after it is moved around or when its parts are
moved or rearranged.
20 Selective Cognitive The ability to concentrate on a task over a
Attention Abilities period of time without being distracted.
21 Time Sharing Cognitive The ability to shift back and forth between two
Abilities or more activities or sources of information
(such as speech, sounds, touch, or other
sources).
22 Arm-Hand Psychomotor The ability to keep your hand and arm steady
Steadiness Abilities while moving your arm or while holding your
arm and hand in one position.
23 Manual Psychomotor The ability to quickly move your hand, your
Dexterity Abilities hand together with your arm, or your two
hands to grasp, manipulate, or assemble
objects.
24 Finger Psychomotor The ability to make precisely coordinated
Dexterity Abilities movements of the fingers of one or both hands
to grasp, manipulate, or assemble very small
objects.
25 Control Psychomotor The ability to quickly and repeatedly adjust the
Precision Abilities controls of a machine or a vehicle to exact
positions.
26 Multilimb Psychomotor The ability to coordinate two or more limbs (for
Coordination Abilities example, two arms, two legs, or one leg and
one arm) while sitting, standing, or lying down.
It does not involve performing the activities
while the whole body is in motion.
27 Response Psychomotor The ability to choose quickly between two or
Orientation Abilities more movements in response to two or more
different signals (lights, sounds, pictures). It
includes the speed with which the correct
response is started with the hand, foot, or
other body part.
28 Rate Control Psychomotor The ability to time your movements or the
Abilities movement of a piece of equipment in
anticipation of changes in the speed and/or
direction of a moving object or scene.
29 Reaction Psychomotor The ability to quickly respond (with the hand,
Time Abilities finger, or foot) to a signal (sound, light, picture)
when it appears.
30 Wrist-Finger Psychomotor The ability to make fast, simple, repeated
Speed Abilities movements of the fingers, hands, and wrists.
312
31 Speed of Psychomotor The ability to quickly move the arms and legs.
Limb Abilities
Movement
32 Static Physical The ability to exert maximum muscle force to
Strength Abilities lift, push, pull, or carry objects.
33 Explosive Physical The ability to use short bursts of muscle force
Strength Abilities to propel oneself (as in jumping or sprinting),
or to throw an object.
34 Dynamic Physical The ability to exert muscle force repeatedly or
Strength Abilities continuously over time. This involves muscular
endurance and resistance to muscle fatigue.
35 Trunk Physical The ability to use your abdominal and lower
Strength Abilities back muscles to support part of the body
repeatedly or continuously over time without
'giving out' or fatiguing.
36 Stamina Physical The ability to exert yourself physically over long
Abilities periods of time without getting winded or out
of breath.
37 Extent Physical The ability to bend, stretch, twist, or reach with
Flexibility Abilities your body, arms, and/or legs.
38 Dynamic Physical The ability to quickly and repeatedly bend,
Flexibility Abilities stretch, twist, or reach out with your body,
arms, and/or legs.
39 Gross Body Physical The ability to coordinate the movement of your
Coordination Abilities arms, legs, and torso together when the whole
body is in motion.
40 Gross Body Physical The ability to keep or regain your body balance
Equilibrium Abilities or stay upright when in an unstable position.
41 Near Vision Sensory The ability to see details at close range (within
Abilities a few feet of the observer).
42 Far Vision Sensory The ability to see details at a distance.
Abilities
43 Visual Color Sensory The ability to match or detect differences
Discriminatio Abilities between colors, including shades of color and
n brightness.
44 Night Vision Sensory The ability to see under low light conditions.
Abilities
45 Peripheral Sensory The ability to see objects or movement of
Vision Abilities objects to one's side when the eyes are looking
ahead.
46 Depth Sensory The ability to judge which of several objects is
Perception Abilities closer or farther away from you, or to judge the
distance between you and an object.
47 Glare Sensory The ability to see objects in the presence of
Sensitivity Abilities glare or bright lighting.
48 Hearing Sensory The ability to detect or tell the differences
Sensitivity Abilities between sounds that vary in pitch and
loudness.
49 Auditory Sensory The ability to focus on a single source of sound
Attention Abilities in the presence of other distracting sounds.
313
50 Sound Sensory The ability to tell the direction from which a
Localization Abilities sound originated.
51 Speech Sensory The ability to identify and understand the
Recognition Abilities speech of another person.
52 Speech Sensory The ability to speak clearly so others can
Clarity Abilities understand you.
Terrain traversability
List all terrain types that the agent can traverse and how fast it can traverse that terrain.
Terrain Speed(m/s):
For example: smooth, rough, inclined.
Functional attributes
The following attributes do not fit into any of the previous categories, but are important indicators of
whether an agent can perform a task.
Attribute Value
Operation time minutes
Duration of continual operation without required rest.
Rest time minutes
Time required by the agent to reset between operations.
Type of end effectors
List of devices that the agent can use to interact with the material,
product or environment. For humans, this can be thought of as the
tools that the human has access to and can use.
Number of end effectors
The number of devices that the agent can simultaneously use to
interact with the material, product or environment.
Mounting position
Possibility to attach the agent to surfaces in different orientations.
(for example, ground, wall, ceiling and mobile platforms).
Degree of protection
Degree of protection denotes the protection provided by an
enclosure against access to hazardous parts, ingress of solid foreign
objects and water. (See Appendix F for the IP-Code)
Configuration duration (adaptability) minutes
Average duration to change the configuration of the agent to
perform different operations or at different locations.
Autonomy
The capability of an entity to create and control the execution of its
own plans and/or strategies. For instance, in mobile agents the
ability of the agent for determining the trajectory to reach a specific
location or pose. See Appendix G for the definitions and the
different levels of autonomy.
Degrees of freedom
314
A term used to describe a robot’s freedom of motion in three-
dimensional space. For humans, this is normally six, unless
something impedes movement.
Horizontal reach m
The distance from the resting or starting position that the agent can
reach into the horizontal plane.
Vertical reach m
The distance from the resting or starting position that the agent can
reach into the vertical plane.
Wrist reach distance m
The maximum distance in which the end effector of the agent can
reach in the work envelop.
Non-functional attributes
The following attributes describe characteristics of an agent other than its capability to perform
actions.
Attribute Value
Operation cost € per hour
Total cost of operating the agent.
Air pollution CO2 per hour
The effect of the agent on the environment.
Ambient temperature ºC - ºC
Range of temperature within which the agent functions as expected.
315
APPENDIX I: TASK DEFINITION FORM
Dear participant,
Thank you in advance for participating in this evaluation. The objective of this research is to develop
a method to describe agents and tasks, to determine which agent can perform a manufacturing task.
Figure 125 shows an overview of the method, with three steps to describe tasks and agents,
respectively.
Task
Performed for each Performed for each Task-related
data table
task that requires run- attribute required to data tables
time allocation perform the task
T1: Identify T3: Determine
task(s) which T2: Describe the the required
require task value for each
allocation attribute
Start End
A1: Identify A3: Determine
A2: Describe the
agent(s) for the value of
agent
allocation each attribute
This form is used to capture the task requirements and is therefore the output of step T3 of the
method. To evaluate the method, I ask that you fill in this form, describing a task to the best of your
ability. Thereafter, you are asked to rate the method on usefulness, ease of use and intention to use.
This evaluation is based on the validated Method Evaluation Model (Moody, 2003).
If you have any comments regarding the attributes (e.g. unclear, missing) or the form itself (e.g.
difficult to use), please add those comments on page 8. I will use those comments to reflect on the
research and its outcomes. Lastly, if any information is confidential, please mark it as such and I will
ensure that it is never published in the public domain. In such a case, I guarantee that I will be the only
observer of that information.
Task description
First, fill in Table 70 to identify the task under consideration. Next, go through all the attributes,
starting from page 2 and try to fill in those attributes required to perform the task. Lastly, fill in the
questions on page 8. Comments regarding this form can be filled in on page 9.
Task name
Task type
316
Task description
Process name
Organisation
Completed by
Date of completion
Signature of person
who completed the
form
Task requirements
In this research, a task is defined as any activity performed by an agent or a team of agents. When the
composition of the team must change, the task is ended, and a new task must begin. An agent is
defined as any entity (human or machine) that can act independently (Luck and d’Inverno, 1995).
Independence in this case refers to whether the object is self-directed. A human operator working
under supervision is an agent, even under direct coaching. Similarly, a robot that executes operations
as received by its control system is an agent. However, a drilling machine operated by a human
operator is not an agent, but rather a tool.
Tasks and agents are described in terms of attributes to enable dynamic allocation to tasks during
process run-time. The following categories of attributes can be used to describe task requirements:
authorization, tenancy, ability, terrain traversability, functional and non-functional. All attributes do
not have to be completed for each task, but bear in mind that an agent will only be considered for a
task if it possesses all attributes required for that task.
Authorization
List all authorizations that an agent must have, to perform the task.
Tenancy
List all locations that an agent must have access to, to perform the task.
Ability
State the level of abilities that an agent must posses to perform the task.
317
3 Oral Expression Cognitive The ability to communicate information and
Abilities ideas in speaking so others will understand.
4 Written Cognitive The ability to communicate information and
Expression Abilities ideas in writing so others will understand.
5 Fluency of Cognitive The ability to come up with a number of ideas
Ideas Abilities about a topic (the number of ideas is
important, not their quality, correctness, or
creativity).
6 Originality Cognitive The ability to come up with unusual or clever
Abilities ideas about a given topic or situation, or to
develop creative ways to solve a problem.
7 Problem Cognitive The ability to tell when something is wrong or
Sensitivity Abilities is likely to go wrong. It does not involve
solving the problem, only recognizing there is
a problem.
8 Deductive Cognitive The ability to apply general rules to specific
Reasoning Abilities problems to produce answers that make
sense.
9 Inductive Cognitive The ability to combine pieces of information
Reasoning Abilities to form general rules or conclusions (includes
finding a relationship among seemingly
unrelated events).
10 Information Cognitive The ability to arrange things or actions in a
Ordering Abilities certain order or pattern according to a
specific rule or set of rules (e.g., patterns of
numbers, letters, words, pictures,
mathematical operations).
11 Category Cognitive The ability to generate or use different sets of
Flexibility Abilities rules for combining or grouping things in
different ways.
12 Mathematical Cognitive The ability to choose the right mathematical
Reasoning Abilities methods or formulas to solve a problem.
13 Number Facility Cognitive The ability to add, subtract, multiply, or
Abilities divide quickly and correctly.
14 Memorization Cognitive The ability to remember information such as
Abilities words, numbers, pictures, and procedures.
15 Speed of Cognitive The ability to quickly make sense of, combine,
Closure Abilities and organize information into meaningful
patterns.
16 Flexibility of Cognitive The ability to identify or detect a known
Closure Abilities pattern (a figure, object, word, or sound) that
is hidden in other distracting material.
17 Perceptual Cognitive The ability to quickly and accurately compare
Speed Abilities similarities and differences among sets of
letters, numbers, objects, pictures, or
patterns. The things to be compared may be
presented at the same time or one after the
other. This ability also includes comparing a
presented object with a remembered object.
318
18 Spatial Cognitive The ability to know your location in relation
Orientation Abilities to the environment or to know where other
objects are in relation to you.
19 Visualization Cognitive The ability to imagine how something will
Abilities look after it is moved around or when its
parts are moved or rearranged.
20 Selective Cognitive The ability to concentrate on a task over a
Attention Abilities period of time without being distracted.
21 Time Sharing Cognitive The ability to shift back and forth between
Abilities two or more activities or sources of
information (such as speech, sounds, touch,
or other sources).
22 Arm-Hand Psychomotor The ability to keep your hand and arm steady
Steadiness Abilities while moving your arm or while holding your
arm and hand in one position.
23 Manual Psychomotor The ability to quickly move your hand, your
Dexterity Abilities hand together with your arm, or your two
hands to grasp, manipulate, or assemble
objects.
24 Finger Psychomotor The ability to make precisely coordinated
Dexterity Abilities movements of the fingers of one or both
hands to grasp, manipulate, or assemble very
small objects.
25 Control Psychomotor The ability to quickly and repeatedly adjust
Precision Abilities the controls of a machine or a vehicle to exact
positions.
26 Multilimb Psychomotor The ability to coordinate two or more limbs
Coordination Abilities (for example, two arms, two legs, or one leg
and one arm) while sitting, standing, or lying
down. It does not involve performing the
activities while the whole body is in motion.
27 Response Psychomotor The ability to choose quickly between two or
Orientation Abilities more movements in response to two or more
different signals (lights, sounds, pictures). It
includes the speed with which the correct
response is started with the hand, foot, or
other body part.
28 Rate Control Psychomotor The ability to time your movements or the
Abilities movement of a piece of equipment in
anticipation of changes in the speed and/or
direction of a moving object or scene.
29 Reaction Time Psychomotor The ability to quickly respond (with the hand,
Abilities finger, or foot) to a signal (sound, light,
picture) when it appears.
30 Wrist-Finger Psychomotor The ability to make fast, simple, repeated
Speed Abilities movements of the fingers, hands, and wrists.
31 Speed of Limb Psychomotor The ability to quickly move the arms and legs.
Movement Abilities
32 Static Strength Physical The ability to exert maximum muscle force to
Abilities lift, push, pull, or carry objects.
319
33 Explosive Physical The ability to use short bursts of muscle force
Strength Abilities to propel oneself (as in jumping or sprinting),
or to throw an object.
34 Dynamic Physical The ability to exert muscle force repeatedly
Strength Abilities or continuously over time. This involves
muscular endurance and resistance to muscle
fatigue.
35 Trunk Strength Physical The ability to use your abdominal and lower
Abilities back muscles to support part of the body
repeatedly or continuously over time without
'giving out' or fatiguing.
36 Stamina Physical The ability to exert yourself physically over
Abilities long periods of time without getting winded
or out of breath.
37 Extent Physical The ability to bend, stretch, twist, or reach
Flexibility Abilities with your body, arms, and/or legs.
38 Dynamic Physical The ability to quickly and repeatedly bend,
Flexibility Abilities stretch, twist, or reach out with your body,
arms, and/or legs.
39 Gross Body Physical The ability to coordinate the movement of
Coordination Abilities your arms, legs, and torso together when the
whole body is in motion.
40 Gross Body Physical The ability to keep or regain your body
Equilibrium Abilities balance or stay upright when in an unstable
position.
41 Near Vision Sensory The ability to see details at close range
Abilities (within a few feet of the observer).
42 Far Vision Sensory The ability to see details at a distance.
Abilities
43 Visual Colour Sensory The ability to match or detect differences
Discrimination Abilities between colours, including shades of colour
and brightness.
44 Night Vision Sensory The ability to see under low light conditions.
Abilities
45 Peripheral Sensory The ability to see objects or movement of
Vision Abilities objects to one's side when the eyes are
looking ahead.
46 Depth Sensory The ability to judge which of several objects is
Perception Abilities closer or farther away from you, or to judge
the distance between you and an object.
47 Glare Sensory The ability to see objects in the presence of
Sensitivity Abilities glare or bright lighting.
48 Hearing Sensory The ability to detect or tell the differences
Sensitivity Abilities between sounds that vary in pitch and
loudness.
49 Auditory Sensory The ability to focus on a single source of
Attention Abilities sound in the presence of other distracting
sounds.
50 Sound Sensory The ability to tell the direction from which a
Localization Abilities sound originated.
320
51 Speech Sensory The ability to identify and understand the
Recognition Abilities speech of another person.
52 Speech Clarity Sensory The ability to speak clearly so others can
Abilities understand you.
Terrain traversability
List all terrain types that an agent must be able to traverse to perform the task.
Terrain
Functional requirements
The following attributes do not fit into any of the previous categories, but are important indicators
of whether an agent can perform the task.
Attribute Value
Operation Time minutes
Duration of continual operation without required rest.
Rest Time minutes
Time required by between task instances to reset between
operations.
Type of end effectors
List of devices that the agent must use to perform the task. For
humans, this can be thought of as the tools that the human must
use.
Number of end effectors
The number of devices that the agent must simultaneously use to
perform the task.
Mounting position
Must the agent be attached to a specific surface to perform the task
(for example, ground, wall, ceiling and mobile platforms)?
Degree of protection
Degree of protection denotes the protection provided by an
enclosure against access to hazardous parts, ingress of solid foreign
objects and water. (See Appendix F for the IP-Code).
Configuration duration (adaptability) minutes
Average duration to change the configuration of the agent to
perform different operations or at different locations.
Autonomy
The capability of an entity to create and control the execution of its
own plans and/or strategies. For instance, in mobile agents the
ability of the agent for determining the trajectory to reach a specific
location or pose. See Appendix G for the definitions and the
different levels of autonomy.
Degrees of freedom
321
A term used to describe a robot’s freedom of motion in three-
dimensional space. For humans, this is normally six, unless
something impedes movement.
Horizontal reach m
The distance from the resting or starting position that the agent can
reach into the horizontal plane.
Vertical reach m
The distance from the resting or starting position that the agent can
reach into the vertical plane.
Wrist reach distance m
The maximum distance in which the end effector of the agent can
reach in the work envelop.
Non-functional attributes
The following attributes describe requirements of a task other than the actions to be performed.
Attribute Value
Operation cost € per hour
Total cost of operating the agent.
Air pollution CO2 per hour
The effect of the agent on the environment.
Ambient temperature ºC - ºC
Range of temperature within which the agent functions as expected.
Space requirements Length: m
How much space does the agent need to be able to function Width: m
correctly. Height: m
Recommended operating humidity %- %
Range of humidity within which the agent functions as expected.
322
APPENDIX J: RESULTS OF AGENT DEFINITION
FORMS COMPLETED BY PARTICIPANTS
This appendix lists the values determined by the five participants who completed the Agent Definition
form shown in Appendix H. The completed and signed forms are available from the author, on request.
323
Attribute Participant 1 Participant 2 Participant 3 Participant 4 Participant 5
Participant name Paulo Diogo Ribeiro Selma Kchir Ton Gerrits Harm ten Broek Michael van
Thiel
Agent name Yaskawa MH24 João Costa AGV Jan Gelderland Kuka LBR iiwa 7 Bart van Rooyen
industrial robot (anonymised) (anonymised) R800 (anonymised)
324
325
326
327
Number of end 1 1 3 2 1 2
effectors
Mounting position Ground Ground Ground Ground. Floor Ground
Ceiling
Wall
328
329
330
331
Completed by Rafael Arrais Selma Kchir Ton Gerrits Harm ten Broeke Michael van Thiel
Date of completion 27/06/2019 26/06/2019 13/06/2019 21/06/2019 21/06/2019
Authorization Safety sensors must None In case of No authorizations Forklift driver’s
be not be triggered confidential printed required. licence.
by an obstacle or information (like
intrusion, during financial
the coating information), the
operation. operator must be
screened to gain
access to the task
location.
Tenancy Product coating Production area, It depends on the Profile stacking work Intermediate
work cell. including printers, environment. For the cell. storage zone
finishers, high demonstration Profile staking work
capacity stackers purposes, the cell
and storage racks operator must have
(delivery station). access to the high
capacity stacker (O-
1-1-1-1).
Ability Oral 0 0 0 0 0
Comprehension
Written 3 2 3 3 3
Comprehension
Oral Expression 0 0 0 0 0
Written Expression 1 2 0 1 1
Fluency of Ideas 3 1 0 0 0
332
333
Originality 2 0 0 0 0
Problem Sensitivity 4 2 0 0 2
Deductive 2 2 0 0 3
Reasoning
Inductive 0 0 0 3 0
Reasoning
Information 0 2 1 2 2
Ordering
Category Flexibility 0 1 0 0 0
Mathematical 0 0 0 0 0
Reasoning
Number Facility 0 3 0 1 0
Memorization 3 2 0 2 1
Speed of Closure 5 2 0 0 0
Flexibility of 5 1 0 0 1
Closure
Perceptual Speed 5 2 0 3 1
Spatial Orientation 6 3 2 1 3
Visualization 4 0 2 0 0
Selective Attention 4 3 1 3 5
Time Sharing 0 3 2 0 0
Arm-Hand 6 2 3 3 1
Steadiness
Manual Dexterity 5 3 2 4 2
Finger Dexterity 0 0 0 0 0
Control Precision 3 3 0 4 2
Multilimb 0 0 2 0 0
Coordination
Response 0 2 2 0 4
Orientation
Rate Control 1 2 0 1 1
Reaction Time 1 4 1 6 6
Wrist-Finger Speed 0 2 1 4 3
Speed of Limb 3 2 1 3 2
Movement
Static Strength 3 2 5 1 3
Explosive Strength 0 1 0 0 0
Dynamic Strength 3 2 3 4 0
Trunk Strength 0 3 3 6 1
Stamina 4 3 1 3 1
Extent Flexibility 3 2 3 4 0
Dynamic Flexibility 0 3 3 5 0
Gross Body 5 3 2 2 1
Coordination
Gross Body 2 0 2 2 1
Equilibrium
Near Vision 5 2 1 2 1
Far Vision 0 4 1 0 2
Visual Color 5 0 0 0 0
Discrimination
Night Vision 0 0 0 0 0
Peripheral Vision 4 3 2 1 3
334
335
Depth Perception 4 3 0 2 2
Glare Sensitivity 3 2 0 3 3
Hearing Sensitivity 0 0 0 0 0
Auditory Attention 0 0 0 0 0
Sound Localization 0 0 0 0 0
Speech 0 0 0 0 0
Recognition
Speech Clarity 0 0 0 0 0
Terrain traversability Cardboard floor to Smooth Smooth No movement Smooth
protect the floor involved.
from excess paint.
The cardboard floor
can be slippery.
Functional Operation time 30 minutes 45 minutes 1 minutes 120 minutes 120 minutes
attributes
Air pollution N/A N/A Unknown CO2 per hour CO2 per hour
Ambient 35 ⁰C to 40 ⁰C 16 ⁰C to 27 ⁰C 16 ⁰C to 36 ⁰C 15 ⁰C to 35 ⁰C 15 ⁰C to 35 ⁰C
temperature
Space Unknown Length: 2.5 m Length: 1m Length: 2m Unimportant
requirements Width: 2.5 m Width: 2m Width: 2m
Height: 3 m Height: 2m Height: 2m
336
APPENDIX L: COMBINATION GENERATOR CODE
Combination generator Javaclass, as retrieved from Rosen (2018).
class CombinationGenerator {
private int[] a;
private int n; // Number of agents in the system
private int r; // Number of members in a coalition
private BigInteger numLeft;
private BigInteger total;
// Constructor
CombinationGenerator (int n, int r) {
if (r > n) {throw new IllegalArgumentException ();}
if (n < 1) {throw new IllegalArgumentException ();}
this.n = n;
this.r = r;
a = new int[r];
BigInteger nFact = getFactorial (n);
BigInteger rFact = getFactorial (r);
BigInteger nminusrFact = getFactorial (n - r);
total = nFact.divide (rFact.multiply (nminusrFact));
reset ();
}
// Reset
void reset () {
for (int i = 0; i < a.length; i++) {a[i] = i;}
numLeft = new BigInteger (total.toString ());
}
// Compute factorial
private static BigInteger getFactorial (int n) {
337
BigInteger fact = BigInteger.ONE;
for (int i = n; i > 1; i--) {fact = fact.multiply(new BigInteger (Integer.toString (i)));}
return fact;
}
338
APPENDIX M –TECHNOLOGY ACCEPTANCE MODEL
TRANSLATED TO DUTCH FOR INTERVIEWS
Het Technology Acceptance Model wordt gebruikt om gebruiksacceptatie van een systeem te
meten. Elke stelling wordt beoordeeld op een 7-punt likert schaal, van hoogs waarschijnlijk naar
hoogs onwaarschijnlijk (zie Figure 126).
Waargenomen bruikbaarheid
Verwatchte bruikbaarheid verwijst naar de mate waarin een persoon gelooft dat het gebruik van het
specifieke systeem zijn of haar werkprestaties zou verbeteren. De volgende zes vragen worden
gebruikt om de waargenomen bruikbaarheid te meten:
Waargenomen gebruiksgemak
Waargenomen gebruiksgemak verwijst naar de mate waarin een persoon gelooft dat het gebruik
van het betreffende systeem zou hem of haar geen moeiten kosten. De volgende zes vragen worden
gebruikt om het waargenomen gebruiksgemak te meten:
339
3 Mijn interactie met het HORSE-systeem
zou duidelijk en begrijpelijk zijn.
4 Ik zou vinden dat het HORSE-systeem
flexibel is om mee te werken.
5 Het zou gemakkelijk voor me zijn om
vaardig te worden in het gebruik van het
HORSE-systeem.
6 Ik zou het HORSE-systeem gemakkelijk
in gebruik vinden.
340