Rational System-level Design Methodology for Autonomous Robotic Systems
Lars Dalgaard Ph.D. Thesis May 2011
The Danish Technological Institute
The Maersk-McKinney Moller Institute
Centre for Robot Technology
University of Southern Denmark
Odense, Denmark
Odense, Denmark
ii
iii
Abstract Robots have increasingly entered the public domain and our homes, making robot vacuum cleaners like the Roomba and robot lawn mowers an integrated part of our lives. Robot guides at museums, robot aids for the handicapped and robots for aiding in treatment of dementia are slowly entering the scene as are robots in industrial segments which were traditionally too cumbersome (or expensive) to automate – for example, in agriculture and animal production. The development challenges of this new generation of robots are therefore quite different from those of the previous generation. Where previously the developers were assured structured and known environments, repetitive tasks and safety by physical shielding, they now face demands of higher level of autonomy, unstructured or even unknown environments, complex tasks, physical human-robot interaction and, not least, low cost. At the same time demands of safety; ethical, legal and societal (ELS) compliance; stability; and robustness have become firm requirements which have to be guaranteed before the product can enter the market. To address these new challenges we can no longer apply the traditional robot-centric development approaches as they are unable properly to handle the strong coupling between the robots, the task, and the surrounding environment, which together form a unified system. We therefore need to equip the robotics designer with a new set of tools able to handle this challenge. This dissertation set out to accomplish just that by aiming for contributions that will rationally and methodically aid designers of autonomous robotic systems through the design process leading from the initial problem definition to the final solution, that is, a rational system-level design methodology for autonomous robotic systems (ARSs). Therefore this dissertation offers analyses of the challenges that need to be addressed, of what an ARS is, and of how it can be represented to facilitate an easier design process. This has resulted in several novel contributions among which are POEM, a system-level reference model able to represent all ARSs; an Emergence Hierarchy (EH), a hierarchical
iv system representation based on emergent properties; the sDSM, a modified Design Structure Matrix able to model the EH; and an ARS Design Tool facilitating the design of an ARS by representing and allowing changes to the system at several levels-of-abstraction. These tools together with a framework for solution concept generation and a methodology for assessing dependability and ELS compliance issues, shape the initial steps towards a rational system-level design methodology for autonomous robotic systems.
v
Acknowledgements Though the work in this dissertation is my own, many people have been involved in its creation both directly and indirectly, and these are the people I would like to express my thanks to. First of all, I want to express my gratitude to my supervisors John Hallam, Claus Risager, and Henrik Gordon Petersen for believing in this project as much as I have, and for supporting the process with guidance and insights I could not have been without. Especially John Hallam has been an exceptional support through the entire project duration, and though we both knew that this project was as much an adventure as a research project, he was always able to keep calm and provide the right pokes at the right time to ensure that I was on track. Thanks John; for everything. And Claus: thank you for taking a chance with me back in the day when we were only five at the Centre for Robot Technology – hopefully this dissertation lives up to your expectations. Second of all, a special thanks to the reviewers of the preliminary version of this thesis: your comments were most valuable and provided me with new insights that helped greatly improve the final result. A special thanks also to The Danish Agency for Science, Technology and Innovation for co-funding this PhD and for making it economically possible for me to spend 4 months visiting the Australian Centre for Field Robotic (ACFR) in Sydney, Australia, as part of my PhD programme. From ACFR I would like to express my thanks to Senior Lecturer David Rye for providing supervision during my visit, and to Research Director Hugh DurrantWhyte for facilitating my stay. An abundance of thanks to Line for supporting me in every way possible through all the years and for tolerating me in, especially, the past months. I owe you the world. Thanks also to all my colleagues at DTI and to all my friends at SDU, without whom I would never have made it through the past months. And a big heartfelt thanks to my family and all my friends who have always been supportive. What would I do without you.
vi A special thanks goes to Steffen Schakinger, Sting, Enigma, Enya, Joe Satriani, Martin Tallstrom, and Toto for providing most of the vital musical stimulus during the writing of this dissertation – I definitely could not have done this without your daily input.
vii
Abbreviations ACFR
Australian Centre for Field Robotics, Sydney, Australia
ADT
The ARS Design Tool
AIST
The National Institute of Advanced Industrial Science and Technology, Japan
ALV
Autonomous Land Vehicle
ARS
Autonomous Robotic System
CE
Conformit´e Europ´eenne [English: European Conformity]
CRT
Centre for Robot Technology at the Danish Technological Institute
DAG
Directed Acyclic Graph
DSM
Design Structure Matrix
DTI
Danish Technological Institute
EH
Emergence Hierarchy
ELS
Ethical, Legal, and Societal issues
FP
Framework Programmes for Research and Technological Development under the European Union
HCI
Human-Computer Interaction
IFR
International Federation of Robotics
MMMI
The Maersk McKinney-Moller Institute, University of Southern Denmark
pHRI
Physical Human-Robot Interaction
POEM
Perception-Orchestrator-Entity-Mobility system-level model
RTE
Robot, Task*, and Environment* or Requirements, Task, and Environment
SDU
University of Southern Denmark
SRA
Strategic Research Agenda for Robotics in Europe
viii
Contents Abstract
iii
Acknowledgements
v
Abbreviations
vii
Contents
ix
List of Figures
xv
List of Tables
xxiii
1 Introduction 1.1
1.2
1.3
1
Thesis Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
The Background . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2
The Epiphany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.3
The PhD setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Thesis Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2.1
Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.2
Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.3
System-level and Robotic Systems . . . . . . . . . . . . . . . . . . .
10
Organisation of this dissertation . . . . . . . . . . . . . . . . . . . . . . . .
13
2 System-level design challenges in robotics 2.1
19
Guaranteeing Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.1.1
ARS System Properties . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.1.1.1
25
Dependability . . . . . . . . . . . . . . . . . . . . . . . . . ix
x
CONTENTS 2.1.1.2
2.2
2.3
2.4
2.5 2.6
Ethical, Legal, and Societal Compliance . . . . . . . . . .
27
2.1.2
Physical Safety in Robotics . . . . . . . . . . . . . . . . . . . . . .
28
2.1.3
The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Robotic systems are Socio-technical systems . . . . . . . . . . . . . . . . .
31
2.2.1
What are socio-technical systems? . . . . . . . . . . . . . . . . . . .
32
2.2.2
Socio-technical Robotic Systems . . . . . . . . . . . . . . . . . . . .
34
2.2.3
Designing Socio-technical systems . . . . . . . . . . . . . . . . . . .
36
2.2.4
The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Robots are complex systems . . . . . . . . . . . . . . . . . . . . . . . . . .
40
2.3.1
Complexity perspectives . . . . . . . . . . . . . . . . . . . . . . . .
41
2.3.2
Components and Interactions . . . . . . . . . . . . . . . . . . . . .
42
2.3.3
The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
The Awareness Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
2.4.1
The Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.4.2
The Public
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
2.4.3
The Robotics Field . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.4.4
The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.5.1
The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Responding to the challenges . . . . . . . . . . . . . . . . . . . . . . . . . .
63
2.6.1
Challenge 4–5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.6.2
Challenge 1–3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
3 What is an Autonomous Robotic System? 3.1
3.2 3.3
The RTE-components
71
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
3.1.1
The Task* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
3.1.2
The Environment* . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
3.1.3
The Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
3.1.4
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
The ARS Continuum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
3.2.1
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
CONTENTS
xi
4 Aspects of System-level ARS design 4.1
4.2
4.3
The ARS design process . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.1.1
A generic product development process . . . . . . . . . . . . . . . .
92
4.1.2
A generic systems engineering development process . . . . . . . . .
94
4.1.3
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
The Problem
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.2.1
What is a problem? . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.2.2
To solve, resolve, or dissolve a problem . . . . . . . . . . . . . . . . 101
ARS Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.3.1
Overall system-level considerations . . . . . . . . . . . . . . . . . . 105
4.3.2
Task* -component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.3.2.1
4.3.3 4.3.4
4.5
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Robots-component . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.3.4.1
4.3.5
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Environment* -component . . . . . . . . . . . . . . . . . . . . . . . 109 4.3.3.1
4.4
89
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Design Considerations Reference Sheet . . . . . . . . . . . . . . . . 120
Decision Making in ARS Design . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.1
An overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.4.2
PAPRIKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.4.3
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
An ARS System-level Concept Generation Framework . . . . . . . . . . . . 127 4.5.1
ServiceBot: Background story and Problem specification . . . . . 128
4.5.2
Initial Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.5.3
ServiceBot: Initial Analyses . . . . . . . . . . . . . . . . . . . . . 132
4.5.4
Concept Generation
4.5.5
ServiceBot: Concept Generation
4.5.6
Concept Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.5.7
ServiceBot: Concept Assessment . . . . . . . . . . . . . . . . . . 148
. . . . . . . . . . . . . . . . . . . . . . . . . . 139 . . . . . . . . . . . . . . . . . . 140
4.6
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.7
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5 Related Works in System-level Design
157
xii
CONTENTS
6 Modelling an ARS
163
6.1
Definitions of System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.2
A Hierarchical System Representation . . . . . . . . . . . . . . . . . . . . . 167
6.3
6.4
6.2.1
A graphical representation . . . . . . . . . . . . . . . . . . . . . . . 168
6.2.2
A matrix representation: The sDSM . . . . . . . . . . . . . . . . . 170 6.2.2.1
The DSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2.2.2
The sDSM
. . . . . . . . . . . . . . . . . . . . . . . . . . 175
A dynamic ARS representation: The Emergence Hierarchy . . . . . . . . . 179 6.3.1
Emergent Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.2
The Emergence Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 184 6.3.2.1
Several Supersystems . . . . . . . . . . . . . . . . . . . . . 185
6.3.2.2
Levels and Scope . . . . . . . . . . . . . . . . . . . . . . . 186
6.3.2.3
A Directed Acyclic Graph (DAG) . . . . . . . . . . . . . . 188
6.3.2.4
The Emergence Hierarchy sDSM . . . . . . . . . . . . . . 188
POEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 6.4.1
The POEM subsystems and Interactions . . . . . . . . . . . . . . . 191 6.4.1.1
The Mobility subsystem . . . . . . . . . . . . . . . . . . . 191
6.4.1.2
The Orchestrator subsystem . . . . . . . . . . . . . . . . . 191
6.4.1.3
The Perception subsystem . . . . . . . . . . . . . . . . . . 192
6.4.1.4
The Entity subsystem . . . . . . . . . . . . . . . . . . . . 192
6.4.1.5
The POEM interactions . . . . . . . . . . . . . . . . . . . 193
6.4.2
The limited scope of POEM . . . . . . . . . . . . . . . . . . . . . . 195
6.4.3
Examples of applying POEM . . . . . . . . . . . . . . . . . . . . . 196 6.4.3.1
Example I: Autonomous Robot vs. Semi-Autonomous Robot196
6.4.3.2
Example II: The TransPot ARS . . . . . . . . . . . . . . . 197
6.4.3.3
Example III: A functional element model for land vehicle systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.4.3.4
Example IV: The Weazel Ball . . . . . . . . . . . . . . . . 203
6.4.3.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.5
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
CONTENTS
xiii
7 The ARS Design Tool
211
7.1
Set-projection and Set-expansion views . . . . . . . . . . . . . . . . . . . . 212
7.2
Manipulation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.3
7.4
7.5
7.2.1
Adding Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.2.2
Removing Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 223
An Example: The Weazel Ball . . . . . . . . . . . . . . . . . . . . . . . . . 224 7.3.1
The Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.3.2
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
A Prototype ARS Design Tool . . . . . . . . . . . . . . . . . . . . . . . . . 233 7.4.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
7.4.2
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
7.4.3
A Software Implementation . . . . . . . . . . . . . . . . . . . . . . 236
7.4.4
Applying the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
7.4.5
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8 The Genefke-POEM Tool
247
8.1
The Genefke-scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
8.2
The Genefke-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.3
The hybrid tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
8.4
ServiceBot: Complexity Assessment . . . . . . . . . . . . . . . . . . . . . 256 8.4.1
Defining Internal and External View . . . . . . . . . . . . . . . . . 256
8.4.2
Subsystem Components . . . . . . . . . . . . . . . . . . . . . . . . 256
8.4.3
The Genefke-Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 257 8.4.3.1
Perception Subsystem . . . . . . . . . . . . . . . . . . . . 258
8.4.3.2
Orchestrator Subsystem . . . . . . . . . . . . . . . . . . . 259
8.4.3.3
Mobility Subsystem . . . . . . . . . . . . . . . . . . . . . 260
8.4.3.4
Entity Subsystem . . . . . . . . . . . . . . . . . . . . . . . 260
8.4.4
Performing the analysis . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.4.5
Interpreting the results . . . . . . . . . . . . . . . . . . . . . . . . . 262
8.5
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
8.6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
xiv
CONTENTS
9 Conclusions
267
9.1
Summary of Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
9.2
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
A The Comic
273
B The Genefke-scale
283
C The ServiceBot pictures
287
D Prop. & Struct. of the Design Methodology
291
D.1 Properties of the Design Methodology . . . . . . . . . . . . . . . . . . . . . 292 D.1.1 Facilitate a rational design process . . . . . . . . . . . . . . . . . . 294 D.1.2 Facilitate iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 D.1.3 Offer the means to evaluate the fitness of a design . . . . . . . . . . 295 D.1.4 Facilitate collaborative design . . . . . . . . . . . . . . . . . . . . . 295 D.1.5 Facilitate the construction of prototypes and experimental setups . 296 D.1.6 Produce process deliverables . . . . . . . . . . . . . . . . . . . . . . 296 D.1.7 Facilitate different design tools . . . . . . . . . . . . . . . . . . . . . 297 D.1.8 Be easy to explain and use . . . . . . . . . . . . . . . . . . . . . . . 297 D.1.9 Allow for different levels of generalisation . . . . . . . . . . . . . . . 297 D.1.10 Allow for different levels of autonomy . . . . . . . . . . . . . . . . . 298 D.1.11 Produce design documentation . . . . . . . . . . . . . . . . . . . . . 298 D.2 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 D.3 The Structure of the Design Methodology . . . . . . . . . . . . . . . . . . 300 D.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 E Design Considerations Reference Sheet
303
F Decision support for Dependability and ELS analysis
305
List of Figures 1.1
The overall structure of the rational design methodology providing the means rationally to go from a problem to the solution through some design process.
8
1.2
The coupling between the system-level and the component-level. . . . . . .
11
2.1
The relation between the first three design challenges. . . . . . . . . . . . .
21
2.2
How the five design challenges appear in the hierarchy from system-level to component-level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3
The required system properties in an Autonomous Robotic System. . . . .
24
2.4
The robot-seal Paro developed by Takanori Shibata at the National Institute of Advanced Industrial Science and Technology (AIST), Japan. . . . . . . .
2.5
27
Socio-technical Robotic Systems found as the intersection of the realms of Socio-technical Systems and Mechatronics/Robotics. . . . . . . . . . . . . .
36
2.6
Some of the basic subsystems and component-groups often found in a robot. 44
2.7
The passing of current from a power supply to a motor shown at three different levels of component-detail. . . . . . . . . . . . . . . . . . . . . . .
2.8
The vision system and the velocity servo system represented as two separate systems using the component-groups of Figure 2.6 . . . . . . . . . . . . . .
2.9
45 46
The component-group interactions in a combined vision system and a velocity servo system modelled using the thirteen basic components of Figure 2.6
47
2.10 The component-group interactions that may be needed in order to realise our imaginary robot represented both using a digraph and as a binary adjacency matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.11 The component-level view of the TransPot system . . . . . . . . . . . . . .
50
2.12 The three fictitious robots from the fictitious robot company RoboCare. . .
55
2.13 Hiroshi Ishiguro together with his “Geminoid� . . . . . . . . . . . . . . . .
57
xv
xvi
LIST OF FIGURES 2.14 The information flow between Robotics, the media and the public. . . . . .
59
2.15 The extent (green) to which I will address the five design challenges in this thesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.16 Two ways of regarding a robotic system. Left: The traditional robot-centric view where the mobile robot constitutes the robotic system. Right: The systems-view where the robot is only part of the robotic system. . . . . . .
68
3.1
The ARS part of the design methodology. . . . . . . . . . . . . . . . . . .
71
3.2
The three types of Environment (* ) -component elements. . . . . . . . . . .
75
3.3
The system-centric continuum of robotic systems – a slight adaptation of Fig. 2 from [Hallam and Bruyninckx 2006] . . . . . . . . . . . . . . . . . .
3.4
79
The system-centric continuum of ARSs shown as a subset of the systemcentric continuum of robotic systems. A few examples of non-ARSs are also shown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5
80
Left: The 7 ARS Continuum segments. Right: their coupling to the RTEcomponents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
3.6
Six types of real-world ARSs . . . . . . . . . . . . . . . . . . . . . . . . . .
82
3.7
Seven different ARSs shown in the ARS continuum. . . . . . . . . . . . . .
85
3.8
The intended application domains of the tools, methods, models/representations developed in Chapter 3 shown with respect to the design life-cycle as will be presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
4.1
The Problem, the Solution and the Design Process of the design methodology. 89
4.2
The Problem and the Solution in the TransPot ARS. . . . . . . . . . . . .
91
4.3
The structure of the design methodology. . . . . . . . . . . . . . . . . . . .
92
4.4
The generic product development process as presented by Ulrich and Eppinger [2008, p23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5
The system life-cycle model of systems engineering as presented by Kossiakoff and Sweet [2003, p52]. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
94
The system engineering method top-level flow diagram from [Kossiakoff and Sweet 2003, p70]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7
93
96
The system engineering method over life-cycle from [Kossiakoff and Sweet 2003, p80]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
LIST OF FIGURES 4.8
xvii
A comparison of the product development model by Ulrich and Eppinger [2008] and the systems engineering method presented by Kossiakoff and Sweet [2003]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9
98
A somewhat simplified version of the Problem-components of the TransPot ARS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.10 Two TransPots with different tool designs. . . . . . . . . . . . . . . . . . . 107 4.11 The RoboMop robotic floor duster by RoboMop International AS. Picture from http://www.robomop.net/ . . . . . . . . . . . . . . . . . . . . . . . 111 4.12 Examples of robots where Industrial Design is a very important factor. . . 119 4.13 How the RTE1–RTE5 considerations relate to the RTE-representation. “Dependability and ELS” is shown using (D), socio-technical issues as (S), and complexity issues as (C). . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.14 The System-level Concept Generation Framework. . . . . . . . . . . . . . . 127 4.15 Two types of manned service vehicles currently used at the University of Suburbia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 4.16 The layout of the main campus of University of Suburbia. “Gray” denotes hall- and pathways, “orange” class rooms and offices, “light orange” large lecture halls, “white” outdoor areas, and “yellow ” outdoor pathways. The layout is based on parts of the Odense campus of University of Southern Denmark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.17 A pairwise ranking situation addressing Availability and Societal issues. . . 136 4.18 A pairwise ranking situation addressing Reliability and Societal issues. . . 136 4.19 Inspiration for the two concepts. . . . . . . . . . . . . . . . . . . . . . . . . 141 4.20 The intended application domains of the tools, methods, models/representations developed in Chapter 4 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 5.1
“The components involved in robot design and their interactions” – an adapted version of Figure 2.1 from Stoy et al. [2010, p28], showing how the Robots-component of the RTE-representation can be found. . . . . . . 160
6.1
The various interacting parts/subsystems contained within a system, separated by boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
xviii 6.2
LIST OF FIGURES The internal -view and external -view of a system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.3
A four-level hierarchy of systems and components represented using a tree structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.4
DSM taxonomy from [Browning 2001] . . . . . . . . . . . . . . . . . . . . . 170
6.5
An example system as both a DSM and a digraph. . . . . . . . . . . . . . 173
6.6
Partitioning a DSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.7
Constituents and Condensation of a system . . . . . . . . . . . . . . . . . 174
6.8
A two-level system hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.9
The possible partitions of a DSM and the legal partitions of a sDSM. . . . 176
6.10 An sDSM and a digraph representing the same two-level hierarchy system.
178
6.11 The coupling of interactions in different levels of the system hierarchy. . . . 178 6.12 A Emergence Hierarchy of systems and components represented using a DAG structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 6.13 An sDSM and a DAG representing the same four-level emergence hierarchy. 189 6.14 The system-level subsystems of an ARS comprising the Mobility, the Orchestrator, the Perception, and the Entity subsystems, along with the flow of information between them. I term this reference design POEM. . . . . . 191 6.15 The two inherent loops of POEM. . . . . . . . . . . . . . . . . . . . . . . . 195 6.16 Top: Illustrates how an ARS comprising an autonomous robot may relate to the four system-level subsystems. Bottom: Illustrates how an ARS comprising a semi-autonomous robot may relate to the four system-level subsystems. . . . . . . . . . . . . . . . . . . 197 6.17 The component-level view of the TransPot system superimposed with the four system-level subsystems. . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.18 The Mobility subsystem of the TransPot system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.19 The Orchestrator subsystem of the TransPot system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.20 The Perception subsystem of the TransPot system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 6.21 The Entity subsystem of the TransPot system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
LIST OF FIGURES
xix
6.22 A schematic of the relationship between different functional elements of an autonomous land vehicle system (ALV) [Durrant-Whyte 2005]. . . . . . . . 202 6.23 POEM superimposed on the ALV component model. . . . . . . . . . . . . 202 6.24 The Weazel Ball (http://www.weazelball.com/). . . . . . . . . . . . . . 204 6.25 POEM mapped to a simple model of the Weazel Ball. . . . . . . . . . . . . 205 6.26 The intended application domains of the tools, methods, models/representations developed in Chapter 6 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 7.1
Normal-, set-projection and set-expansion view of a level in the Emergence Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
7.2
The SP/SE impact on a lower level of the Emergence Hierarchy . . . . . . 214
7.3
The normal-view and the set-expansion view of Figure 7.1 represented using an sDSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
7.4
Introspective view of the lower level of Figure 7.3(b) . . . . . . . . . . . . . 216
7.5
Making manipulations to the Emergence Hierarchy from Figure 7.1 using set-projection and set-expansion views: C has been replaced by F and an interaction from F to D has been added. . . . . . . . . . . . . . . . . . . . 217
7.6
An example system represented as both an EH and as a sDSM. . . . . . . 219
7.7
An example system represented as both an expanded EH and as an expanded sDSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.8
The EH and sDSM after adding an interaction between A and B, and expanding level 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.9
The EH and sDSM after adding an interaction between 1 and 2, and performing an expansion of level 2. . . . . . . . . . . . . . . . . . . . . . . . . 221
7.10 The EH and sDSM after choosing an interaction between A 1 and B 2 and again expanding level 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 7.11 The initial setup for the analysis of the Weazel Ball . . . . . . . . . . . . . 224 7.12 Level 2 has been expanded . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 7.13 BallM, BallP, and Ball are now three separate subsystems. . . . . . . . . . 226 7.14 After adding ( BallP P 7→ Obst. O), contracting, and expanding level 2 . . 228
7.15 After adding ( BallP P 7→ Obst. O) and contracting level 2 . . . . . . . . . 228
xx
LIST OF FIGURES 7.16 After renaming Obst. E to Obst.E E and contracting level 2 . . . . . . . . 229 7.17 After removing ( BallP 7→ Obst.E) and expanding level 2 . . . . . . . . . . 229 7.18 After adding the remaining interactions from Table 7.3. . . . . . . . . . . . 230 7.19 The normal-views of the contracted sDSM and the sDSM from the initial setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.20 Introspective-view of level 2 of Figure 7.19(a) . . . . . . . . . . . . . . . . . 231 7.21 An alternative initial analysis setup showing also the sDSM with level 2 expanded. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 7.22 A screen-shot of the ARS Design Tool prototype implementation . . . . . . 237 7.23 An unfortunate situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 7.24 The expanded sDSM representing the thesis structure at some point in time. 243 7.25 The intended application domains of the tools, methods, models/representations developed in Chapter 7 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 8.1
The system complexity/development needs of various types of robots according to the Genefke-scale . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.2
An example screen shot of the Genefke-Tool. . . . . . . . . . . . . . . . . . 251
8.3
Two radar diagrams representing complexity analysis’s at two different points in a project’s life-cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
8.4
Identifying the 10 metric-subgroups. . . . . . . . . . . . . . . . . . . . . . . 254
8.5
Mapping POEM to the radar diagram. . . . . . . . . . . . . . . . . . . . . 255
8.6
The radar diagram of the 2 purposed ServiceBot concepts shown together using: Red : Concept I, Green: Concept II, Yellow : Internal/External knowhow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
8.7
The intended application domains of the tools, methods, models/representations developed in Chapter 8 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
LIST OF FIGURES 9.1
xxi
The intended application domains of all the tools, methods, and models/representations shown with respect to the ARS design life-cycle and the system-level and component-level. The areas addressed by this thesis (green) have been mapped to the software engineering model [Kossiakoff and Sweet 2003] – larger coverage of a phase indicates a larger contribution. . . 271
B.1 The Genefke-scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 B.2 The Lynex Lx 1000 remote controlled lawnmower, developed and sold by Lynex, ˚ Alsøvej 2, 8240 Risskov, Denmark, with a combustion engine of 22 HP and a total weight of 290 kg. . . . . . . . . . . . . . . . . . . . . . . . 285 C.1 The corridors and pathways at University of Suburbia . . . . . . . . . . . . 287 C.2 Junctions and turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 C.3 An elevator exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 C.4 Obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 C.5 “Broken” lines, colour differences in the floor, and distances to objects . . . 290 C.6 The structure of the ceiling above the corridors and pathways . . . . . . . 290 D.1 The design methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 D.2 The phases of the design methodology . . . . . . . . . . . . . . . . . . . . 300 E.1 Design Considerations Reference Sheet. . . . . . . . . . . . . . . . . . . . . 304 F.1 The sixteen Dependability and ELS criteria and their associated preference values before ranking has been conducted.
. . . . . . . . . . . . . . . . . 306
F.2 The sixteen Dependability and ELS criteria and their associated preference values after ranking has been conducted with respect to the ServiceBot (see Section 4.5.3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
xxii
LIST OF FIGURES
List of Tables 1.1
The six overall objectives of this thesis. . . . . . . . . . . . . . . . . . . . .
14
1.2
An indication of which chapters addresses which objectives. . . . . . . . . .
16
1.3
An overview of what are the various tools, methods, models/representations developed in this thesis and in which chapters they are presented. The following abbreviations are used: Tools (T), Methods (Me), and Models (Mo). 16
2.1
The number of European robotics projects past and present from 2000–2010 found on the EURON web-site 8th of August 2010. . . . . . . . . . . . . .
4.1
61
A Task analysis indicating which tasks could (C) be done by humans and robots respectively, and which should not (SN) be done by humans or robots, respectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.2
The ranked Dependability and ELS compliance criteria for the ServiceBot.
4.3
Concept I: Classification of the Environment* elements as Enabler (E), Dis-
137
abler (D), Commuter (C), or Irrelevant (I). Elements at the bottom below the double line are additions to the environment. . . . . . . . . . . . . . . 143 4.4
Concept I: A Task* analysis indicating which tasks the task-performing (Operators and Robots) are doing. Elements at the bottom below the double line are additions to the original task specification.
4.5
. . . . . . . . . . . . . 144
Concept II: Classification of the Environment* elements as Enabler (E), Disabler (D), Commuter (C), or Irrelevant (I). Elements at the bottom below the double line are additions to the environment. . . . . . . . . . . . . . . 146
4.6
Concept II: A Task* analysis indicating which tasks the task-performing (Operators and Robots) are doing. Elements at the bottom below the double line are additions to the original task specification. xxiii
. . . . . . . . . . . . . 147
xxiv 4.7
LIST OF TABLES The ServiceBot concept rankings. The following abbreviations are used: Moderately likely (ML), Positive (P), and Not likely (NL). . . . . . . . . . 149
6.1
An example of a subset of subsystems in an ARS at four different levels-ofabstraction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2
The motivation for including the five POEM interactions from Figure 6.14 and the reasons for not including the other seven possibilities (shown with gray background). The system names are abbreviated to their first letter for clarity. S designates the source of the interaction and D the destination. 194
7.1
Bottom-up approach: Resolving inconsistencies at Level 1 resulting from changes to level 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.2
Top-down approach: Level 1 and level 2 implications caused by adding interactions to level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
7.3
Interpretation and assessment of the nine potential sDSM inter-level interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
8.1
The initial list of POEM subsystem entities in the analysis made for ServiceBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.2
Metrics of the Perception Subsystem . . . . . . . . . . . . . . . . . . . . . 258
8.3
Metrics of the Orchestrator Subsystem . . . . . . . . . . . . . . . . . . . . 259
8.4
Metrics of the Mobility Subsystem
8.5
Metrics of the Entity Subsystem . . . . . . . . . . . . . . . . . . . . . . . . 260
8.6
The complexity analyses of the purposed ServiceBot concepts. . . . . . . . 261
9.1
The six overall objectives of this thesis. . . . . . . . . . . . . . . . . . . . . 267
. . . . . . . . . . . . . . . . . . . . . . 260
D.1 A comparison of the design methodology to other system-level design methods299
LIST OF TABLES
xxv
xxvi
LIST OF TABLES
Chapter 1 Introduction 1.1 1.1.1
Thesis Motivation The Background
As a newly graduated master in Computer Systems Engineering in 2001 I already had several years of practical experience behind me in the vast interdisciplinary field known as robotics. Naturally, the experiences had all been collected in the university setting of robotics but I had nevertheless built line-following autonomous mobile robots, controlled industry grade manipulator arms and from scratch managed to design, construct and control a 2D modular-robot as my thesis project. With this background I felt quite prepared for whatever future robotic challenges the world had in store for me. A couple of months before my graduation I had just accepted a job in a two-man company (I was the second person) called Manox, engaged in the design, construction and control of an autonomous mobile robot called TransPot. The task of the TransPot was repeatedly to transport 200 potted plants from a pot production facility to a designated bed in a large outdoor horticultural container field, offload the pots in a pattern on the ground and return to the production facility. A seemingly easy challenge, we thought, and ventured with open minds and a good portion of technical expertise into the unknown. As time went by it became more and more apparent to us how truly ambitious the project actually was. Constructing a mechanical mobile robot base, adding the necessary hardware and writing the necessary software enabling it to move around in the horticultural 1
2
CHAPTER 1. INTRODUCTION
field was actually not the greatest challenge. No, the greatest challenge was doing it so that all the requirements were obeyed at all times. This included the requirements stated initially by our customer (production rate measured in placed pots/hr, price, robot weight, etc.), but unfortunately also the requirements stated later by our customer (varying ground conditions of the soil, varying types of plants, an operational interface for his unskilled workers, etc.) and the legislative requirements (in particular safety) that we were not too familiar with. Our project had evolved from being a simple “textbook” mobile robot transporting potted plants, into a complex system comprising workers, operators, production planning, plant life-cycles, data mining, safety procedures – and of course a robot. Thanks to our engineering training – and a bit of luck – we actually managed to handle the challenges quite well. However, after three years of struggling we had to face the facts: Our TransPot was only able to place the pots perfectly on the ground about 80% of the time – mostly due to a bad mechanical design of the tool. On top of that the robot had only operational capacity for about 4 hours before recharging was needed, which was 4 hours too little. Had we actually managed to achieve 99% of the production requirements we would still have been faced with how to add extra energy capacity to the robot without increasing its weight; due to the risk of soil compacting we were already operating within margins. Potentially we would have been facing a total redesign of the mechanical and electronic parts which would have meant an economic disaster. We therefore decided to close the project and along with it the company. After Manox I went on to a position as research assistant in the Adaptronics group at the Maersk Mc-Kinney Moller Institute (MMMI), University of Southern Denmark (SDU) working on a large scale EU project called HYDRA: “Living” Building Blocks for Self-Designing Artefacts funded under the Fifth Framework Programme [CORDIS 2001]. Our objective was to develop a new type of self-reconfigurable modular robot exhibiting morphological properties, that is, a robot able to change its own shape. Our solution was the 1 kg ATRON modules which when interconnected were able to move relatively to each other thus changing the shape of the overall super-structure. In spite of several design flaws the modules (often) worked quite well and resulted in a world-wide media coverage and several scientific publications. Through the HYDRA project I experienced the research way of robot design and found
1.1. THESIS MOTIVATION
3
it quite far from the real-world targeted development process of Manox I previously encountered. Naturally, the ATRON modules and the TransPot were entirely different types of robots developed for entirely different purposes but also with an entirely different set of success-criteria: the success of the TransPot was directly linked to the performance of the entire system where the success of the ATRON was linked to the performance of the robot and to the amount of scientific commodities generated. This had of course resulted in a more robot-centric development process which in many ways was similar to what we had applied in the initial phases of the TransPot project. The experience I had gathered so far resulted in a two year position as a teacher at the Odense University College (OUC) where I taught robotics, automation and control to engineering students. This positioned me strategically between the commercial world and the research world. The commercial side was the obvious target of our students, and the research side the material by which we often taught them. Furthermore my position put me in contact with several national as well as international R&D robotics projects often with the participation of several universities and companies. In such projects the goal was commonly to develop some novel robotic solution dedicated to a particular domain, but quite frequently the end-results did not match the expectations. On paper the projects could well be a success but when it came to the actual robots that were supposedly developed, semi-working prototypes and non-integrated components were the typical end-products. This was indeed puzzling to me, but I began to see several patterns and distinct parallels to my previous experiences.
1.1.2
The Epiphany
Reflecting on my accumulated experiences it slowly became apparent to me that something was fundamentally wrong with the way we developed new robots: How was it that with the vast amounts of advanced robotic components commercially available and with robotics research at an extremely high level, that it apparently was so hard to construct new robots that actually worked according to the expectations? If iRobot could make and sell Roomba vacuum cleaner robots in copious amounts, why could we not make a simple mobile robot transporting potted plants in a nursery garden? The technology and knowledge is surely there, so where does it go wrong?
4
CHAPTER 1. INTRODUCTION
One observation I made was of the inherently different ways robots and robotics are perceived by universities and the rest of the world. The media often portrays state-of-the-art in robotics as close to T1000 Terminator-robots able to accommodate our every need (or kill us all) which gives the public a very wrong idea of what actually is possible robotics-wise. On the other hand the robotics researchers know that the actual state-of-the-art is nowhere close to the realisation of T1000 robots but that it is in several areas, nevertheless, still years ahead of what is found in real-world products. However, as robotics is greatly multidisciplinary even the researchers are forced to specialise in some sub-domain of robotics. Though all these sub-domains in the past decades have been the focus of intense research and have, at an ever growing pace, helped introduce increasingly more sophisticated and complex components to the market, it is nonetheless hard to apply these components to make new robotic systems that conform to real-world demands. Researchers therefore often apply their particular contribution to some laboratory test-platform to show the validity of their results which again can give the impression that the state-of-the-art of robotics is way ahead of the facts. It also dawned on me that an obvious problem in modern robotics development is the almost exclusive focus on developing the physical robot with very little attention to the larger system of which the robot is to become part – a view shared, among others, by the growing Human-Robot Interaction society which has recently (2009) resulted in the emergence of a new journal: International Journal of Social Robotics (e.g. [Salvini et al. ˇ 2010; Sabanovi´ c 2010]). This has, of course, been the traditional way as “robot” for many years has been synonymous with heavy-duty industrial manipulator arms or factory floor mobile robots. These robots were developed and produced in a wide range of shapes and sizes to satisfy as broad a range of applications as possible. The actual integration of these robots into a given production system was then performed by some automation specialist who would choose an appropriate robot and treat it as one component of many in the final system. Today this picture has changed. Robots have increasingly entered the public domain and our homes, making robot vacuum cleaners like the Roomba and robot lawn mowers an integrated part of our lives (e.g [Bill Gates 2007]). Robot guides at museums, robot aids for the handicapped and robots for aiding in treatment of dementia are slowly entering the
1.1. THESIS MOTIVATION
5
scene as are robots in industrial segments which were traditionally too cumbersome (or expensive) to automate – for example, in agriculture and animal production (e.g. [International Federation of Robotics (IFR) 2010]). The development challenges of this new generation of robots are therefore quite different from those of the previous generation. Where previously the developers were assured structured and known environments, repetitive tasks and safety by physical shielding, they now face demands of higher level of autonomy, unstructured or even unknown environments, complex tasks, direct human-robot interaction and, not least, low cost. At the same time demands of safety; ethical, legal and societal (ELS) compliance; stability; and robustness have become firm requirements which have to be guaranteed before the product can enter the market (e.g. [European Robotics Technology Platform (EUROP) 2009c]). Thinking that the development of robots that can conform to such demands can be done in the “old way” without much regard to their working environment and the task they have to fulfill, is naive at best. The task and environment become crucial elements in the complete system. A mobile robot moving among people may not be “safe” just because it has a Sick laser-scanner fitted to its chassis. Its mechanical construction, its control system and the structure of its surroundings may play equally important roles, which makes proper safety handling an inherent system property and not just a component that can be added to the robot at a later date (e.g. [Herrmann and Melhuish 2010]). “System integration” for such systems is therefore not something that can be done after the robot has been built – it must be done while (or even before) it is being built, as an integral part of its design process (e.g. [Sommerville 2003]).
1.1.3
The PhD setup
As rewarding as the position at OUC was, I did not feel that teaching was my true calling, so I started searching for a way to put my new found epiphany to more dedicated use. The direction I aimed for was a way to delve into some of the development problems of robotics I had observed and hopefully come up with ways to approach them more rationally and thereby help facilitate the design of future robotic systems. An opportunity presented itself: The Danish Agency for Science, Technology and Innovation (FI) has a programme called ErhvervsPhD which in English is translated to the
6
CHAPTER 1. INTRODUCTION
roughly accurate Industrial PhD. The idea is that a PhD project is started amongst a PhD candidate, a company and a university, where the candidate is employed by the company which in turn receives some economical reimbursement from the Agency. Both the company and the university must provide PhD supervision of the candidate and the latter is payed by the Agency for guaranteeing that the PhD programme undertaken by the candidate conforms to the Danish regulations. It was the ideal opportunity. I had previously discussed my ideas with Prof. John Hallam from MMMI and had actually already drafted a PhD proposal. From my prior engagements I knew Claus Risager, head of the Danish Technological Institute’s (DTI) Centre for Robot Technology (CRT), and I presented the proposal to him. DTI is more than 100 years old, self-owned and a non-profit institution specialised in developing, applying and disseminating research- and technologically-based knowledge for the Danish and International business sectors. This is done partly through participation in development projects in close collaboration with leading research and educational institutions both in Denmark and abroad, and through consultancy and standardisation services. Claus believed that a PhD-student in rational robotics design could provide CRT with significant commercial value as they were already participating in several robotics development projects, though only counting a staff of four, and knowledge in this area would be a great contribution. At the same time their many projects and inherent close links with both industry and academia, would offer an invaluable setup assuring that the PhD project would maintain a close tie with “the real world”. Claus, John and I quickly came to terms and agreed that I should apply for an Industrial PhD position at CRT, with Claus and John as company supervisor and main university supervisor respectively, and with Prof. Henrik Gordon Petersen (MMMI) as co-supervisor. Fortunately our application was approved and on February 1st, 2007, I started my new job as PhD-student at CRT. As part of the Danish three year PhD programme it is required for the student to do “environmental change” which usually implies a three to six months stay at a foreign university. I was fortunate to get in touch with Senior Lecturer David Rye at the Australian Centre for Field Robotics (ACFR) in Sydney, Australia, who accepted me as visiting PhD student for 4 months from August until the end of November, 2008.
1.2. THESIS OBJECTIVE
7
Furthermore I took a seven months leave of absence from my studies from autumn 2009 to spring 2010 where I worked as a “normal” consultant at CRT, engaged in writing project applications, and working on projects – fortunately directly related to some of my PhD work. This period contributed with much real-world input to my research.
1.2
Thesis Objective
From the brief outline of issues described in Section 1.1.2 it is evident that robotic system designers face difficult tasks in handling both a new set of requirement challenges and a complex and multi-disciplinary domain whilst dealing with potential discrepancies in how the customers/users and the developers perceive robotics. These challenges are of course not exclusive but do give an idea of the direction in which the new generation of robotics is moving and consequently afford an opportunity to smooth their impact by providing the robotic systems designers with better means to handle them. This PhD project set out to accomplish just that by aiming for contributions that will rationally and methodically aid the designer through the design process leading from the initial problem definition to the final solution, which led to a more formal definition of what we seek: a rational system-level design methodology – which also became the title of this dissertation. The overall structure of the design methodology we seek can be seen in Figure 1.1: Given a Problem represented as some Task needing resolution in some Environment under a set of Requirements, we wish to obtain a Solution (an Autonomous Robotic System (ARS)) comprising a set of Robots, a possibly altered Environment – by the introduction of, for example, a local positioning system – and, possibly, adaptation of the initial Task specification – a task may be solved in various ways depending, for instance, on the level of autonomy. We denote the altered Environment and the adapted Task as Environment* and Task* respectively.
8
CHAPTER 1. INTRODUCTION
Design Methodology Problem
Solution (ARS) Task*
Task Environment
Design Process
Requirements
Environment * Robots
Figure 1.1: The overall structure of the rational design methodology providing the means rationally to go from a problem to the solution through some design process.
Having established the overall structure, let us now identify the main objectives of this thesis by investigating the elements comprising its title: Rational System-level Design Methodology for Autonomous Robotic Systems.
1.2.1
Design Methodology
The multi-disciplinary nature of robotics makes it highly unlikely that one method alone will be able to provide the necessary structure to a robotic system design process, which led to an approach of not seeking a design method but a design methodology. By definition (from the free Merriam-Webster on-line dictionary) a methodology is “a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures”. A design methodology therefore helps dictate the overall structure of the design process by providing (domain) specific methods and tools, and by showing how to apply them. The need for such methods and tools is directly acknowledged by the European Robotics Technology Platform (EUROP) [2009c, p36]: “As enablers of a broad range of innovative applications, robotic technologies will often find their way into everyday devices. The development of engineering skills, methods, and tools is crucial in this respect.” One of the objectives of this dissertation is to provide the initial steps towards a design methodology suitable for designing autonomous robotic systems, that is, not a method dictating how robotic systems should be designed, but a setting providing the designer with means rationally to 1) analyse and understand the problems at hand, 2) assess what
1.2. THESIS OBJECTIVE
9
design methods and approaches are appropriate for addressing these problems, and 3) aid in handling domain specific aspects of the design process. The scope of this objective is rather large in its entirety and this dissertation would have to address in depth aspects of most natural science disciplines and even aspects of project management and social sciences, to cover it sufficiently. This breadth is probably a reason why it has not been attempted before, and as I am fairly realistic in nature, I do not believe it to be credible if I claimed I, in only three years, could devise a robotic systems design methodology that would sufficiently be able to cover all aspects. The goal is therefore to lay an initial foundation for future work in this area by contributing a design methodology that indicates feasible paths to the design of autonomous robotic systems.
1.2.2
Rational
Characterising a design methodology as being rational implies that the methods and tools that it comprises aid the designer in making the right design choices such that “each step taken can be shown to be the best way to get to a well defined goal.” [Parnas and Clements 1986]. That implies, among other things, that the process can be documented, reviewed and easily followed by others, and that transfer of knowledge from the design of one system to another becomes possible. However: The traditional methods of decision-making are based on the classical model of pure rationality, which assumes full and exact knowledge about the decision situation being considered. In design, assumptions about the exact knowledge are almost never true. At least to a large measure, the requirements are not comparable and therefore, the preference ordering among them is incomplete. The departure from “pure-rationality” based models to “bounded-rationality” based models [Simon 1996] is needed in design because of the fact that the designer has a limited information-processing capacity and the information is uncertain, vague, or imprecise. [Yassine 2004] Bounded rationality means that the choices made are as rational as they can be when the complete set of possible solutions is unknown [Simon 1996]. This allows for the experience and expertise of people to enter the design process and thus supports the notion that “good designs are made by good designers”. It also accounts for technological progress
10
CHAPTER 1. INTRODUCTION
made within relevant fields so that, for instance, newly invented sensors, new vision algorithms and new wheel constructions can enter the pool of eligible components. If you are not aware of the existence of such components, the design solutions will of course not contain them, but your design process will still be (bounded) rational. Though the rationality view employed in this dissertation is bounded, it does not imply that we cannot enlarge these boundaries by obtaining the right knowledge to further facilitate right choices. The “right� knowledge is, as a minimum, an understanding of what are the problems we are dealing with, as without it we would not know what knowledge we are, in fact, missing. One of the objectives of this dissertation is therefore to identify the right body-ofknowledge needed to make rational design decisions. This requires an analysis of the problem domain to obtain a better understanding of the system-level challenges that we are currently facing in robotics as this will provide a necessary framework for knowledge elaboration and help us identify where our knowledge is lacking. Another objective is to facilitate the use of this knowledge in a rational and structured way by providing a set of tools that will aid the designer in making the right design choices at the right time.
1.2.3
System-level and Robotic Systems
As addressed briefly in Section 1.1.2 the inclusion of the task and the environment in the design process seems imperative to produce a working system complying with the new requirements as it not only involves the physical robots but all aspects of where and how it has to operate. This argument can be further emphasised by an analogy from the car industry [Hallam and Dalgaard 2010]: When car designers set forth to design a new car they know that the end-result will be some type of car. It will more than likely have four wheels, some doors, a combustion (or hybrid) engine, brakes, windows, and so forth. They may not know exactly what the interior will be made of (leather or plastic) or what type of odometer visualisation they will end up applying (clock-handle or numerical), but based on the amount and type of constraints and requirements they will work towards a product that conforms to the specifications.
1.2. THESIS OBJECTIVE
11
Comparing this process to the approach often applied when designing robots today it does appear strikingly similar, there are however several fundamental differences: the car is designed to fit an already existing infrastructure (the Environment) comprising roads, traffic signals, zebra crossings, pedestrians, cyclists, parking spaces, bicycle paths and so forth, and to provide the driver with means to obey a vast set of traffic rules through its speeder, brake and wheel interfaces as she drives from one place to another (the Task). The car, the environment and the task therefore both complement and continuously interact with each other forming a complete system. This constrains the car designers’ choices in various ways: when viewed from the system-level the designers may, for instance, be constrained by safety regulations, aesthetics and braking-distance, but when viewed instead from the component-level the requirements may be on maximum current consumptions, colour of the interior or minimum clock-frequency of the central processor. As the current consumption naturally relates to the capacity and size of the car battery which in turn contributes to the overall weight of the car, this component-level constraint is indirectly coupled to the system-level constraint of braking-distance. If a car design were conducted by regarding constraints only from the component-level with no regard to the system-level it might never pass the large number of safety and performance tests required to reach the market. This inherent coupling between the component-level and the system-level can be visualised as in Figure 1.2.
System level
Component level
Figure 1.2: The coupling between the system-level and the component-level.
12
CHAPTER 1. INTRODUCTION Often when roboticists have to design a new robot they focus mostly on the component-
level aspects as research and development in robotics often is centred around components – we may call this type of design process a component-centric or robot-centric design process. A robot-centric approach is often sufficient when designing only parts of a system solution or if the system is “simple enough”, that is, has no or very little autonomy, does not operate in direct contact with people, and so on. However, when a complete robotic system has to be conceived capable of autonomous operation in the real-world complying with real-world complexities and constraints, chances are that the process of integrating these components will be guided solely by experience and ad-hoc approaches. Experience tells us that this practice unfortunately often leads to systems which do not obey their initial system requirements and in the worst cases results in a total project collapse – this, of course, depending on the complexity of the system. A reason for the ad-hoc integration practice is that we lack the means also to handle the design process from the system-level perspective. We simply do not fully understand how choices made at the component-level affect the system-level or how requirements from the system-level affect the choice of components – this is in full analogy with the car example above. In order to facilitate this, a first step is to shift the focus from the pure robot-centric to a more system-centric design process, which directly implies shifting also how we perceive robotics altogether, towards a more systems-oriented view. To accentuate the point of thinking in terms of systems and not only robots, the design methodology sought in this project is therefore targeted at designing robotic systems and thus not only the robots. To make it clear what sub-domain of robotic systems the design methodology will foremostly address, the term autonomous was added in front, which may indeed make it more ambiguous. In this dissertation I will therefore use the following definition to narrow the scope slightly: Definition 1. An Autonomous Robotic System (ARS) is a system that solves, resolves, or dissolves problems in some environment facilitated by one or more autonomous or semiautonomous robots. (Note: The reasons for using the terms “solves”, “resolves”, and “dissolves” will be fully explained in Section 4.2.)
1.3. ORGANISATION OF THIS DISSERTATION
13
To further narrow the scope of the design methodology, the focus is not on how to dimension and construct physical robots or components either, but on devising guidelines for handling the system-level problems of robotic system design along with the tools to support this.
To facilitate these thoughts, one three-fold objective of this dissertation is therefore 1) to establish a model for characterising an ARS in terms of its system-level components, as without such a model it is difficult to understand what we have to design, 2) to define a structured system view able to handle different levels-of-abstraction from the system-level to the component-level facilitating a handling of the complex system couplings, and 3) to define a unified system-level model of an ARS able to serve as the foundation for designing any ARS.
1.3
Organisation of this dissertation
In this section I will clarify how I have chosen to address the objectives presented in the last section. Let us first restate all the objectives one by one using a slightly different ordering:
14
CHAPTER 1. INTRODUCTION
1)
To analyse the system-level challenges
2)
To establish a system-level model for characterising an ARS in terms of its physical components
3)
To provide the initial steps of a design methodology suitable for designing autonomous robotic systems
4)
To define a structured system view able to handle different levelsof-abstraction from the system-level to the component-level facilitating a handling of the complex system couplings
5)
To define a unified system-level reference model of an ARS able to serve as the foundation for designing any ARS
6)
To provide a set of tools that will aid the designer in the design process Table 1.1: The six overall objectives of this thesis.
To address the six objectives, I have chosen to organise this dissertation in the following way: • Chapter 2 entitled System-level design challenges in robotics addresses five major challenges in robotics: 1) the need for guaranteeing compliance with real-world de-
mands of dependability and ethical, legal, and societal issues, 2) the fact that robotic systems are socio-technical systems, 3) the fact that robots are complex systems, which makes them inherently hard to design, 4) there is an awareness gap in robotics between the public and professional views of what is possible, and 5) the fact that robots are often developed in large collaborating teams comprising partners with varied backgrounds and with different skills, agendas, and perceptions of the problem at hand. • Chapter 3 entitled What is an Autonomous Robotic System? first presents what
an ARS is in terms of its three system-level components Robots, Task*, and En-
vironment*, effectively resulting in an RTE-representation. Then I introduce the ARS Continuum which can be used to characterise an ARS by ranking these three components in the order of how much they contribute to the overall success of the
1.3. ORGANISATION OF THIS DISSERTATION
15
system. • Chapter 4 entitled Aspects of System-level ARS design first outlines what an ARS de-
sign process may look like and comprise, then treats the input to the design process, the Problem, and then addresses three different ways of approaching it seen from an ARS perspective. This leads to a presentation of several system-level design considerations which consolidates into the Design Considerations Reference Sheet. Then an overview of decision making in ARS design is made which leads to the formulation of an Dependability and ELS assessment methodology followed by a system-level framework to facilitate the generation of ARS concepts based on the devised methods and tools: An ARS system-level concept generation framework. This is assessed using a test design case called ServiceBot.
• Chapter 5 entitled Related Works in System-level Design presents an overview of related works.
• Chapter 6 entitled Modelling an ARS presents a more elaborate ARS system model based on a hierarchical system view and emergent properties, and introduces a
distinct system-level reference model I call POEM (an acronym for PerceptionOrchestrator-Entity-Mobility) which aims to capture the essence of any conceivable ARS seen from the system-level. • Chapter 7 entitled The ARS Design Tool combines the hierarchical system view with POEM, and new techniques I denote set-projection and set-expansion, to form the
basis of an innovative ARS Design Tool that will help the designer of future ARSs better to handle the inherently complex interactions and dependencies present in both subsystems and components of ARSs. • Chapter 8 entitled The Genefke-POEM Tool presents a tool to support assessment of the complexity of an ARS solution with respect to the knowledge resources available to make it. The tool is assessed using the ServiceBot test case. • Chapter 9 entitled Conclusions presents the final conclusions of this dissertation and offers a brief discussion of future work.
The six objectives are therefore addressed in the chapters as shown in Table 1.2.
16
CHAPTER 1. INTRODUCTION
Objective
C2
1) address challenges
×
2) ARS model 3) steps of methodology 4) structured system view
C3 ×
C4
×
5) system-level reference model 6) tools
C6
C7
C8
×
×
× ×
Table 1.2: An indication of which chapters addresses which objectives.
An overview of what are the tools, methods, and models/representations and where they are presented in the thesis, is shown in Table 1.3.
Chapter
Tools, methods, and models
Chapter 3
• RTE-representation
Chapter 4
T
• ARS Continuum
• Three ARS design approaches
×
• Dependability and ELS assessment methodology
×
Chapter 7 Chapter 8
×
• Emergence Hierarchy • ARS Design Tool
• Genefke-POEM tool
×
×
• Concept Generation Framework • POEM
Mo ×
• Design Considerations Reference Sheet
Chapter 6
Me
×
× ×
×
Table 1.3: An overview of what are the various tools, methods, models/representations developed in this thesis and in which chapters they are presented. The following abbreviations are used: Tools (T), Methods (Me), and Models (Mo).
As can be gathered from the chapter structure and from the tools, methods, and models/representations that will be presented, it has been necessary to concentrate more on some aspects and less on others. One reason being that not much work have been done
1.3. ORGANISATION OF THIS DISSERTATION
17
previously in this area making the “obvious point-of-attack” non-existent and thus making it hard to identify – let alone cover – all areas in three years. Another reason being that though my scientific and technical background is broad I hold degrees in neither processnor design-engineering which means that some facets, though identified and treated, are not covered in-depth. This is, for instance, the case with project management aspects and socio-technical issues. Nevertheless, I believe the result presented in this thesis deals with an useful subset of ARS design issues and provides an important contribution to the ARS design problem.
18
CHAPTER 1. INTRODUCTION
Chapter 2 System-level design challenges in robotics As presented in the Introduction several challenges exist that in various ways affect our abilities to design and produce working robotics systems suitable for the real-world – these issues were consolidated into Objective 1 of Table 1.1 on page 14. In the next sections I will present five of these design challenges and discuss how they each influence the design process. In the last section I will then present a strategy for how I have chosen to respond to them and how they integrate with the rest of the work presented in this thesis. The five design challenges I have chosen to address are the following: 1. The need for guaranteeing compliance with real-world demands of dependability and ethical, legal, and societal issues. 2. The fact that robotic systems are socio-technical systems. 3. The fact that robots are complex systems, which makes them inherently hard to design. 4. There is an awareness gap in robotics between the public and professional views of what is possible. 5. The fact that robots are often developed in large collaborating teams comprising partners with varied backgrounds and with different skills, agendas, and perceptions of the problem at hand. 19
20
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS The motivation for focusing on these particular design challenges is that I believe they
constitute five pressing issues with respect to the design of robotic systems and, most importantly, all originate at the system-level – both factors are essential with respect to the focus of this thesis. Let me elaborate these points a bit further: (1) addresses important issues of guaranteeing compliance with dependability and ethical, legal, and societal issues, which are issues that we frequently encounter at DTI in our general work with robotics and in particular with welfare technology. They are also issues specifically raised by The Strategic Research Agenda for Robotics in Europe (SRA) [European Robotics Technology Platform (EUROP) 2009c] published by The European Robotics Technology Platform (EUROP) which states that “building an early awareness of the resulting ethical, legal, and societal issues will allow timely legislative action and societal interaction, which will in turn support the development of new markets”. These issues are therefore central to the future of robotics and as they all relate to the coupling between robots and society they need initial addressing from the system-level. (2) addresses robotic systems from a socio-technical perspective, which is closely linked with (1). The socio-technical view is often a minor factor in robotics design where, for instance, users may be involved in the design process, where human-robot interaction may be considered, or where the organisation where the robot is to be installed are part of decision making. These are indeed common practices in robotics but the socio-technical implications reach much deeper when our new robots are to become integrated parts of society – as observed in other areas deploying technology in social contexts (e.g. in the SOCIONICAL project1 or by Sommerville and Dewsbury [2007]). These issues therefore need to be addressed explicitly in the design process of robotic systems, which can only be achieved by addressing them foremost from the system-level. (3) explores the general and widely accepted notion of robots being complex systems, which is also closely linked with both (1) and (2). In designing socio-technical robotic systems guaranteeing compliance with dependability and ethical, legal, and societal issues, the complexity of the system is very high in terms of development needs and time, and with respect to a large number of components and interactions. Being able to handle these issues in a rational and sound way requires an understanding of what complexity is and how it can be managed in a design situation. This naturally spans the entire robotic system 1
“Complex socio-technical system in ambient intelligence” funded under the European Union’s Seventh
Framework Programme in ICT-2007.8.4: Science of complex systems for socially intelligent ICT.
21 design process from the system-level to the component-level, but as with the previous two challenges, it originates at the system-level. These first three design challenges can be directly inferred from the increasing set of new demands we face in robotics and their couplings can be visualised as shown in Figure 2.1.
Demands Higher level of autonomy Unstructured/unknown environments Direct human−robot interaction Complex tasks Low cost Robots integrated in our lives ...
1) Issues of dependability and ELS 3) Higher system complexity 2) Robotics as socio−technical systems
Figure 2.1: The relation between the first three design challenges.
The last two design challenges (4) and (5) are more sociological in nature as they address issues relating to different perspectives and viewpoints of robots and robotics which are indeed also important to consider when designing a robotic system. These challenges are, however, addressed more as open discussions based on personal experiences from participation in several national and international robotic projects aimed at designing robots. This places them slightly out of scope of the rest of the thesis but as they represent issues that directly affect robotics design I have chosen to include them. To illustrate more clearly at what levels in the hierarchy from system-level to componentlevel the five challenges are present, consider Figure 2.2. As can be observed all the challenges originate at the system-level, but both (1) and (2) actually impact the system all the way to the component-level but to a continuously lesser degree. This indicates that though they are predominantly system-level issues, subsystems and components further down the hierarchy may have a direct impact on them. Consider a spear (component) attached to a mobile robot – this may indeed have both ethical and societal consequences. Complexity (3) is an issue present at all levels though taking on different forms at the various levels. At the system-level we may consider complexity from the point of view of development time, at the component-level it may be manifested as large numbers of components and
22
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
interactions. The awareness gap (4) is a system-level issue as it addresses the system as a whole, while issues of design collaboration (5) exist at all levels: perhaps as a management
o−
3)
C
ci So
D 1)
2)
ep e
nd
ab
ilit y te a om ch nd 4) pl nic EL a S Aw ex ity l is su 5) are es C ne ol ss la g bo a ra p tio n
issue at the system-level and an engineering issue at the component-level.
System level
Component level
Figure 2.2: How the five design challenges appear in the hierarchy from system-level to component-level.
2.1
Guaranteeing Compliance
Many of the new generation of robots have to be applied in working environments that may be unstructured, unpredictable or unknown, like offices, hospitals, homes and fields, and perform complex tasks like blood-sampling, weeding, cleaning or nursing. This observation is also shared by the SRA [European Robotics Technology Platform (EUROP) 2009c]. The SRA outlines its robotic visions to 2020 and beyond, stating that the key priorities for European Robotics are in the newly emerging market sectors of domestic service, professional service, security, and space robotics, and that these sectors in particular have a strong need for complying with application requirements as the robots potentially have to interact directly with humans in difficult environments. This not only implies higher technical complexity but also means that issues like safety, reliability, security, and ELS compliance will have to be guaranteed as it will otherwise be close to impossible to obtain
2.1. GUARANTEEING COMPLIANCE
23
the necessary official licenses and permits allowing the systems to be deployed in the first place. These licenses and permits will therefore become a definite hurdle in future robotic systems, as they are in all other types of technical equipment we surround ourselves with. A car must comply with a large number of official rules and regulations before it can enter the consumer market, and so must a simple coffee machine. Why should it be any different for robotic systems? Making guarantees about a robotic system therefore means to produce assurance that it complies or meets with appropriate requirements. Some assurances will be needed to create the necessary product certifications allowing the product entry into the market (for example safety and security issues), while others will be needed to document that the system actually performs according to specification in order to satisfy the customer (for example maintainability and reliability issues). Yet others will be needed to document that the system complies with social as well as ethical norms of its working environment (for example “mental safety”2 ). From a robot-centric viewpoint it is tempting to focus primarily on the assurances concerning the functional specifications of the robots and on the assurances needed to move them into the commercial market. However, to obtain a robotic system that complies with all requirements it is necessary to acknowledge that this approach is insufficient as several of these issues are inherently coupled to the robotic system and thus not only to the physical robot. The reliability of the entire system, informally defined as “the probability, over a given period of time, that the system will correctly deliver services as expected by the user” [Sommerville 2010, p292], cannot, for instance, be fully guaranteed by only regarding the robot, as the potential non-deterministic nature of humans in the system or a sudden unanticipated change in the environment may severely affect it. Technological measures may indeed be used to raise reliability but so may training of operators and adaptation of the environment, which may ultimately prove to be both cheaper and better. Still, the problem of guaranteeing reliability remains, and can probably only be fully assessed once the entire system is operational. Besides reliability several other properties are inherently coupled to the system and 2
Mental Safety indicates that the robots must not induce fear or disgust in humans, or present them
with “unpleasant surprises” [Nonaka et al. 2004].
24
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
need also to be addressed properly in order to obtain robotic systems that actually perform as intended. In the following Section 2.1.1 I will present a list of the system properties I have identified as the most essential when reaching for this goal in ARSs. Safety is naturally among these and is the single most important property when interaction with people or animals is part of the system functionality; I have dedicated Section 2.1.2 to a more elaborate treatment of that subject.
2.1.1
ARS System Properties
In Figure 2.3 I present a collection of the inherent system properties I believe are the most essential when addressing compliance issues of ARSs. It has emerged as a hybrid between the Dependability properties addressed by [Sommerville 2010, p269,291–293], the Dependability and ELS properties addressed by [European Robotics Technology Platform (EUROP) 2006; Veruggio 2007; European Robotics Technology Platform (EUROP) 2009c,a,b; Veruggio and Operto 2009], the ideas of Mental Safety presented by [Nonaka et al. 2004], and personal experience. Discrepancies in the definitions offered by the two first exist, in particular regarding Dependability, which perhaps is due to their roots in two different disciplines. I have therefore attempted the best compromise in compiling a list that I believe captures a feasible set of properties.
Dependability
Reliability
Accuracy
Timeliness
Resilience
Safety
Precision
Security
Physical Safety
Repairability
Integrity
ELS
Maintainability
Availability
Mental Safety
Confidentiality
Ethical
Liability
Legal
Societal
Responsibility
Figure 2.3: The required system properties in an Autonomous Robotic System.
As shown in the figure, two main topics are addressed, Dependability and Ethical, Legal, and Societal compliance, which are further subdivided into nine categories, which are then associated with ten subcategories. This latter association is to express “relates-to” and does not imply, for instance, that the definition of Reliability can be deduced from Accuracy,
2.1. GUARANTEEING COMPLIANCE
25
Timeliness, Resilience, and Precision, just that they are interrelated. Each of the nineteen system properties is therefore an essential property in its own right. In the following I will provide brief definitions of each of these properties. As noted by [European Robotics Technology Platform (EUROP) 2009b], many of the areas are multidisciplinary research areas in their own right, and it is out of scope of this dissertation to treat the finer details. I kindly refer the reader to supplementary literature if an in-depth discussion is desired. 2.1.1.1
Dependability
The Dependability of an ARS is a term that expresses the trustworthiness of the ARS as a whole, that is, the degree of confidence a user, owner, maintainer, bystander, etc., can have that the ARS will operate as they expect, and that it will not fail in normal use. As Sommerville [2010, p291] points out, it is not meaningful to express dependability numerically. Instead terms such as “not dependable”, “very dependable”, and “ultradependable” can be used to reflect the degree of trust we have in a system. The dependability properties presented here apply to the context of the ARS seen from the system-level, but may equally well be used when addressing the properties at the component-level. Reliability is the probability, over a given period of time, that the ARS will correctly deliver useful services at any given time. Availability is the probability that the ARS will be up and running and able to deliver useful services at any given time. Safety is the judgement of how likely it is that the ARS will cause physical harm to or psychological unease in people or animals, or do damage to the environment. Security is a judgement of how likely it is that the ARS can resist accidental or deliberate intrusions. Maintainability is the ARS’s ability to accommodate system changes (for example, due to new requirements) in an economical way, and where there is a low probability that these changes will introduce new system errors.
26
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Repairability reflects how easy it is to fix a problem with the ARS once it has been discovered. It depends on being able to diagnose the problem, access the components that are faulty, and modify or replace these components. Timeliness reflects the ARS’s ability to deliver services on time. Resilience is the ARS’s ability to maintain or recover a stable state when subject to disturbance. Precision is the degree to which the ARS can perform the same service each time to the same level of quality. Also known as repeatability or reproducibility. Accuracy is the degree of quality with which the ARS can deliver a certain service. Physical Safety is the judgement of how likely it is that the ARS will cause physical harm to people, animals or property. Mental Safety is the judgement of how likely it is that the ARS will induce fear or disgust in people or animals, present them with “unpleasant surprises”, or otherwise violate ethical codes of conduct. Integrity is a judgement of the ARS’s ability to withstand intrusion compromising its functionality or data. Confidentiality is the degree of the ARS’s ability to handle data in a safe and secure manner. With respect to dependability in general the SRA makes the following projections [European Robotics Technology Platform (EUROP) 2009a, p12]: 2010: The extent of the fulfilment of dependability requirements is adjusted to the task. Since not all modifications to the process or the environment (in particular with respect to safety) are possible in the context of the task, only certain tasks are feasible. The reliability and availability of the system is often ensured and increased through human intervention. 2015: Dependability of robot system components is increased resulting in less human intervention and greater robustness. Human-robot interaction is safe without fences. Close human-robot collaboration becomes possible because of this development.
2.1. GUARANTEEING COMPLIANCE
27
2020+: Dependability aspects are thoroughly considered in the design phase of the robot system. The engineering of such system for a specific application is much easier as the individual components (i.e., robots and peripherals) have greater dependability. Self-diagnosis and control (structural or motion and parameter adjustment) result in graceful degradation of the system and thus extend the time to maintenance. An important factor to point out is that the SRA does not project close human-robot collaboration in robotics products before the year 2015 which gives a realistic picture of the current state-of-the-art in robotics with respect to dependability, and stresses the need for more focus in this area. I believe this projection to be fairly sound – of course given that the robots envisioned in the future systems are capable of causing physical harm if something goes wrong. Here it can be argued that, for instance, the not-so-dangerous robot-seal, Paro, developed by the National Institute of Advanced Industrial Science and Technology (AIST), Japan, is also a “domestic service robot�, but that is of course a matter of definition (Paro can been seen in interaction with an elderly woman in Figure 2.4).
Figure 2.4: The robot-seal Paro developed by Takanori Shibata at the National Institute of Advanced Industrial Science and Technology (AIST), Japan.
2.1.1.2
Ethical, Legal, and Societal Compliance
The Ethical, Legal, and Societal (ELS) compliance of an ARS is a combined term that addresses the normative as well as the legal compliance issues of the system as a whole. These terms can be somewhat more vague to assess as, contrary to most dependability properties, they are not directly quantifiable. They are, however, not less important, and are essential in bringing a robotic system to market.
28
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Ethical addresses the ethical issues introduced by the ARS. Legal addresses the legal issues introduced by the ARS. Liability addresses both the product and legal liability of the ARS. If the ARS is not operating according to specification or is involved in a situation which causes damage to people, animals or property, is the designer, the manufacturer, the distributor, the supplier, the retailer, the commissioner or the user liable? Responsibility addresses the overall legal responsibility of the ARS. Who is legally responsible for operating the ARS? Societal addresses the various impacts the ARS has on society, for instance, labour displacement, unemployment, job profiles, the amount of available jobs, or living standards.
2.1.2
Physical Safety in Robotics
As stated in the previous section Physical Safety as an ARS system property “is the judgement of how likely it is that the ARS will cause physical harm to people, animals or property.” In this section I will provide a short overview of what this implies in terms of modern day robotics and what exists in terms of standards to help facilitate this. Safety in robotics has been an issue ever since the introduction of the first manipulator arms in industry back in the early 1960s. The focus was then – and still is – naturally on physical safety where preventing the robot from doing physical harm to humans through collision was of foremost importance3 . The most common solution applied through the years has been to create separate workspaces for the robots and the humans, and prevent unintentional interaction through some form of physical shielding between them – for example by enclosing the robot in a cage. This setup is well-known as a work-cell. In the new generation of robotics we will experience direct physical interaction between humans and robots, which means that the separation of workspaces is no longer possible as 3
See, for instance, [Dhillon 1991] for a thorough treatment of the topic or [Dhillon 1996] for an impressive
reference list of published literature on robot reliability and safety from 1973 to 2001.
2.1. GUARANTEEING COMPLIANCE
29
they are now shared. This type of interaction is called physical Human-Robot Interaction (pHRI) on which Bicchi et al. [2008] state: “...one of the most revolutionary and challenging features of the next generation of robots will be physical Human-Robot Interaction (pHRI).” This statement refers not to safety issues alone but to the fact that safety has to be guaranteed while simultaneously guaranteeing compliance with other dependability factors as well. This is stressed as Bicchi et al. [2008] also point out that the holy grail of pHRI is intrinsic safety, explained as “...a robot that will be safe to humans no matter what failure, malfunctioning, or even misuse might happen.” – a parallel to the first part of Isaac Asimov’s First Law of Robotics is evident: “A robot may not injure a human being or, through inaction, allow a human being to come to harm.” This is basically another way of addressing the Dependability issues treated earlier. For robots in general this is of course not an easy goal to reach, but as we have seen in the past years in domestic robots – like robot vacuum cleaners – by keeping the size small, the weight low and the motor power at a minimum, it is possible. This is of course why these types of robots have been the first to enter the consumer market as they can easily be “proven” to comply with required safety requirements. When we move the focus to more “heavy-duty” robots where the weight might be expressed in kilograms with two or three figures, this task is no longer trivial, but is, regardless, a crucial point to be addressed before these robots can hope to enter the consumer market. A key problem is that “robotics” comprises so many different engineering disciplines with individual domain regulations – some with large sets, like electronics and mechanics, and others with very few (if any), like computer-vision and software engineering – but no single regulation encompasses all types of robots. This is, of course, because “robot” is very hard to define and can thus cover everything from washing machines and internet-bots, to manipulator arms, autonomously guided vehicles, exoskeletons and surgical assistant robots, depending on who you talk to. Therefore to submit a new robot to the market, common practice dictates that robots are classified and approved individually based on directives that apply to related categories. For instance, in the case of obtaining the Conformit´e Europ´eenne (CE) product marking in Europe, some 20 directives exist [European Commission, Enterprise and Industry 2010], where it is up to the producer to select the appropriate ones. In the case of a robot this could, for instance, be directives on General Product Safety (2001/95/EC) and Machinery (2006/42/EC), or on Low Voltage
30
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
(2006/95/EC) and Safety of toys (88/378/EEC). The producer then has to verify that the robot complies with these directives, has to identify whether an independent conformity assessment is required, has to test the product and produce a risk assessment, has to draw up the technical documentation and then place the “CE” stamp on the robot. This stamp now indicates that the producer declares that the robot meets the EU safety, health and environmental requirements, and it can therefore be sold on the European market. However, finding the right directives in the first place can be quite problematic. Some robot types do, nevertheless, have standards addressing their particular domain in relation to safety and pHRI. As Santis and Siciliano [2008] write, most of these (unfortunately only) relate to industrial robots and only to a very limited degree address how direct cooperation with humans may be accomplished. The international standard ISO 10218 rev. 2006 does to some extent cover this but as Santis and Siciliano state: “It must be pointed out, however, that the case when robots and people have to share the operational space is not clearly discussed. Actually, the standard poses human-robot segregation in the workplace as the way to obtain safety.” Furthermore the standard only specifies requirements and provides guidance for the assurance of safety in design and construction of the robot itself, not for an entire robot system. Work has been ongoing since and a new revised version of ISO 10218 is on its way. In December 2009, Rockwell Automation released a White Paper [Schuster and Winrich 2009] outlining the major advances that this new standard will address. Besides an updated version of the 2006-revision – now called ISO 10218-1 – a new Part 2 is added – ISO 10218-2 – which is scheduled for release sometime in 2011. The most prominent changes of the 2006 revision cover a more comprehensive set of requirements by addressing the integration and installation of a robot system or cell, and thus not only the robot itself. Among the many changes to be included in the updated standards are first-time safety requirements for four major new robotic technologies: cable-less teach pendants, human-robot collaboration, robot-to-robot synchronisation and vision-based safeguarding systems. However, these new standards still address only conventional industrial work-cell systems, for which only “human-robot collaboration” can be regarded as remotely interesting to future pHRI applications. According to Schuster and Winrich [2009], this standard treats “new software-based safety systems which [in a work-cell] can slow a robot to a safe speed or otherwise direct a robot’s motion to a safe position or a safe state, allowing people
2.2. ROBOTIC SYSTEMS ARE SOCIO-TECHNICAL SYSTEMS
31
to share the same workspace with far less risk.” This does unfortunately not offer much in the direction of standards for robotic systems operating under pHRI but, as Santis and Siciliano [2008] also point out, the ISO Technical Committee TC 184/SC 2 are currently working on a standardisation of “Personal Care Safety” (working group 7) and “Service Robots” (working group 8). These standards may prove very useful indeed but from their website4 it is, however, unclear when they will become available.
2.1.3
The Challenge
The nineteen essential system properties from Figure 2.3 form a set of issues to be considered when contemplating the design of a new robotic system. Depending on the task, the environment and the overall system requirements, not all of the properties may be equally important, and an assessment must be made to which are the most necessary and which may be redundant. In an ARS cleaning the floors of a pig-stable, Confidentiality may not be much of an issue and Accuracy may take precedence over Precision. In an ARS taking care of elderly people in their homes, Confidentiality may indeed be important and Precision may here take precedence over Accuracy. In both cases, however, Physical Safety will be on the top of the list as it will be in many future systems. For the assessment to have validity, the process must be both rational and traceable, meaning that evidence can be produced as to why the choices were made as they were. Later on when the ARS has been constructed, such an assessment will constitute a check list with which the product can be evaluated, bringing us one step closer to producing the necessary evidence of dependability and ELS compliance.
2.2
Robotic systems are Socio-technical systems
The field of robotics is, as mentioned before, inherently multi-disciplinary traditionally comprising areas such as mechanics, electronic hardware, sensors and actuators, navigational systems, communication networks, kinematic and dynamic modelling, control al4
http://www.iso.org/iso/standards development/technical committees/list of iso
technical committees/iso technical committee.htm?commid=54138 Accessed 2/5-2011.
32
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
gorithms, controller design, software engineering, task planning, production planning and Supervisory Control And Data Acquisition (SCADA) systems – and that is just to mention a few of them. Systems produced in such technical contexts where mechanical systems, computers, control systems, and electronic systems are tightly coupled are typically referred to as being mechatronic systems which is also how robotics is traditionally regarded. Each of the natural science areas have along with an increasing line of new fields such as metallurgy, tribology, sustainable energy, zoology, and biochemistry, during the past decades made countless contributions to the robotics and automation fields making the collective body-of-technical-knowledge immense, in turn greatly expanding the list of application possibilities. This has, along with a rising public interest in robotics, been a catalyst for demands of higher level of autonomy, operation in unstructured or even unknown environments, execution of complex tasks, and direct human-robot interaction, as we now want the robots to be an integral part of our daily lives providing both domestic as well as public services. When designing and applying robotic systems in these contexts it therefore requires focus not only on the technical aspects of robotic systems but also on the operational processes, the organisation in which they are deployed and – as covered in the previous section – requirements of guaranteed dependability and ELS compliance. In effect this indicates that robotic systems should be regarded not only as mechatronic systems but as socio-technical systems. Let us explore this a bit further.
2.2.1
What are socio-technical systems?
Originating in the context of labour studies by the Tavistock Institute in London at the end of the fifties, the definition of “socio-technical system” was initially concerned with the adaptation of humans to the organisational and technical framework of production [Ropohl 1999]. According to Ropohl the concept was established “. . . to stress the reciprocal interrelationship between humans and machines and to foster the program of shaping both the technical and the social conditions of work, in such a way that efficiency and humanity would not contradict each other any longer.” The homogeneity between organisation, humans and machines are therefore key in any socio-technical system. In this light Kline [1995, p60] offers a rather broad definition of socio-technical systems: “Socio-technical systems are complete systems of coupled social and technical parts which
2.2. ROBOTIC SYSTEMS ARE SOCIO-TECHNICAL SYSTEMS
33
humans erect and operate primarily to control our environment and perform tasks we cannot do without such systems�. Kline offers several examples of socio-technical systems that conform to this definition: Boeing, General Electric, air-craft transport, newspapers and TV networks, households, orchestras and bands, armies, Harrods, etc., so his definition spans any type of organisation where any number of people and technical parts interact – it is thus not restricted to any one domain or discipline in particular. However, through the decades the initial studies from Tavistock have found its way into a large number of individual disciplines each adapting and formulating their own socio-technical theories (see [Badham et al. 2001] and [Baxter and Sommerville 2011] for excellent reviews and discussions on the topic). These include the original studies into work and workplaces, but also large scale information systems, computer-supported cooperative work, cognitive systems engineering focusing on the relationships between human and organisational issues in control systems and health care, Total Quality Management, Business Process Re-engineering, human-machine interface design, user-centred design, and so on. As an example consider the following definition of socio-technical systems from Software Engineering offered by Sommerville [2010, p267]: Socio-technical systems include one or more technical systems5 but, crucially, also include people who understand the purpose of the system within the system itself. Socio-technical systems have defined operational processes and people (operators) are inherent parts of the system. They are governed by organisational policies and rules and may be affected by external constraints such as national laws and regulatory policies. Sommerville is naturally focussed on software and thus concentrates on how software systems integrate with the people (operators and users) of the receiving organisation and how the organisation itself relates to and incorporates the system. This follows from a long tradition in software development where involvement of users and organisations in the design and integration process has been a mantra for many years (see for instance [Mathiassen et al. 1998; Beck 2000] or equivalent software development literature). 5
[Sommerville 2010, p267] defines technical system as systems comprising hardware and software com-
ponents but no procedures and processes. Examples are televisions, mobile phones, and other equipment with embedded software.
34
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
2.2.2
Socio-technical Robotic Systems
The organisational and societal impacts of robots have been topics of science-fiction writing for more than a century, and have been a reality ever since the first Unimate robot was introduced into manufacturing at General Motors in 1960. “How should the organisation be adapted to facilitate the robot?” – and “will people lose their jobs?” have been among the persistent questions through the decades, so addressing socio-technical issues in robotics is not a new issue. However, traditional industrial production robots aside, many of the new robots slowly entering the consumer market are revolutionary not only in terms of technology, but also because no prior systems exist and some present applications that may not even have been anticipated. These factors makes it hard to predict what the sociotechnical impacts may be. Take, for instance, Paro. At DTI we sell Paros accompanied by a training programme for the caretakers in order for their organisations to prepare for its arrival not only technically but also mentally. The arrival of Paro at a care-centre often resembles the arrival of the Queen of Denmark with all inhabitants, caretakers, and administrators of the centre waiting outside in formation. It is clearly an event — not orchestrated by DTI but by the centre in anticipation of the robot and of what it will accomplish. Though we have good documentation of the results with Paro there are, of course, still sceptics of its abilities and others who regard the pomp and circumstance as extremely exaggerated. These sceptics also often raise questions of an ethical nature (see more in Section 2.4) and argue that it is deceptive to allow people with dementia to get emotionally attached to a robot. What makes Paro special is that the societal – and media – impact it has generated in Denmark was not to that degree expected by anyone. Not even by its designer Takanori Shibata with whom we frequently have meetings. So it is safe to say that Paro was not designed to have this impact in Denmark but may have been designed for the Japanese socio-technical context which in many ways is different from the Danish. But could we have anticipated the Danish impact? Maybe! Many of the variables were known to us before we began selling Paro but as we were moving into unknown territory many new variables emerged as we went along. Though DTI has specialists in both robotics and caretaking the full extent of the socio-technical context could not be charted beforehand as it comprises not only the inhabitants’ interactions with the robot but also interactions between inhabitants and the care-centre and between the care-centre and the robot. To
2.2. ROBOTIC SYSTEMS ARE SOCIO-TECHNICAL SYSTEMS
35
fully understand the latter interactions – which play an equally strong role in the system – would have required thorough studies in advance. Some were of course conducted but we mainly chose to see how it would work through learning-by-doing and adapt our training courses accordingly. This proved to be a feasible strategy and later resulted in the creation of a Welfare Technology Assessment methodology [Danish Technological Institute 2010] which is now widely used at DTI to assess the potential of new welfare technology products. The assessment is based on quality rankings of both the optimisation of the work force, the work environment, the quality of life, its function, the work processes and organisational relations, its interaction with the user, the economic aspects, and stability and support. These factors indeed address several socio-technical aspects. Though the integration of Paro has been a success, not all new technologies are integrated that easily. Some years back an autonomous mobile robot was as a test put into commission at the Odense University Hospital, Denmark, transporting products at the lower cellar levels. However, the test was not a success as the robot was bullied by the human workers who regarded it as arrogant and continuously obstructed its motion path. According to Tveden [2010] the robot was finally forced into a closet by the workers. The project was soon after terminated. I am sure that countless other examples can be found of failed new technology where the failure is not caused by bad or malfunctioning technology but in the way it integrates with the organisation and the people with it. This observation is akin to the one of Baxter and Sommerville [2011] who state: “the failure of large complex systems to meet their deadlines, costs, and stakeholder expectations are not, by and large, failures of technology. Rather, these projects fail because they do not recognise the social and organisational complexity of the environment in which the systems are deployed.” Paro, as well as many new welfare technology products, is a robot that was already constructed and then afterwards adapted to a (Danish) socio-technical context. The interesting question is, however, could it have been designed that way from the beginning? As stated before many new robots have no predecessors which makes it hard to anticipate how they will operate in concert with the receiving organisation and the people in it if these factors have not been considered when they were designed. The SRA [European Robotics Technology Platform (EUROP) 2009c] presents six future application scenarios for robotics: robotic workers, robotic co-workers, logistics robots, robots for surveillance & intervention, robots for exploration & inspection, and edutainment robots. Each sce-
36
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
nario finds applications in two or more of the following sectors: industrial, professional service, domestic service, security, and space. A total of 39 product visions within this frame are presented where most represent new areas, some are already in the research pipe-line but only few have systems actually in existence today. A vast majority of these 39 product visions (if not all) will be applied in contexts where it is more correct to refer to them as socio-technical systems rather than just mechatronic systems – in fact, the term socio-technical robotic systems seems an appropriate term to indicate their position as both socio-technical and as mechatronic systems as illustrated in Figure 2.5. The degree of “social inclusion” for a particular system will of course vary greatly depending on the context but I worry that even though we actually manage to produce a technically working robotic system with proper handling of its dependability and ELS compliance issues, we may still end up with a system the ultimately fails if we have not properly addressed the socio-technical aspects.
Figure 2.5: Socio-technical Robotic Systems found as the intersection of the realms of Socio-technical Systems and Mechatronics/Robotics.
2.2.3
Designing Socio-technical systems
As argued before it may be crucial to address the socio-technical issues of a robotic system from the time of its design in order to handle its proper integration and use in a socio-technical context. This is also stressed by Baxter and Sommerville [2011] who state: “Socio-technical considerations are not just a factor in the systems development process: social-technical factors have to be considered at all stages of the system life-cycle”. However, this is easier said than done as a general problem with handling socio-technical
2.2. ROBOTIC SYSTEMS ARE SOCIO-TECHNICAL SYSTEMS
37
systems is that that the complexity of such systems are extremely high6 as they comprise both inert, naturally-occurring systems, biological systems, human-made hardware systems, communication systems, value systems – and depend on interactions among them [Kline 1995, p61]. This astoundingly large complexity, Kline says, makes them not only hard to construct but also inherently difficult to analyse in their entirety meaning that we cannot construct adequate system representations for the entire system. When we as humans are faced with designing such complex systems we have no choice but to adhere to repeated design-build-test cycles founded in experience, observations, and data from a wide variety of cases7 . In fact, Kline [1995, p138] states, that because of this high level of complexity no serious studies exist of complete socio-technical systems as people usually split them into separate disciplines and treat the pieces independently. This, Kline says, is a huge problem as each discipline is discussed in separate communities that often lack adequate communication with each other. As established earlier Kline’s socio-technical view is rather broad but his observations are nevertheless largely shared by Baxter and Sommerville [2011] who advocate the need for a new dedicated discipline called “socio-technical systems engineering” to harmonise the analysis and design practices from the various areas and disciplines. One problem Baxter and Sommerville point out is that the individual methods, to some extent, reflect different national cultures and approaches to work and work organisations, which means that each method “...is tailored to a particular market, which partly explains why there have never been any significant or successful attempts to integrate approaches to create a more general, standardised method of socio-technical system design.” Other problems include inconsistent terminologies between the approaches, the use of different levels of abstraction, conflicting value systems, and lack of agreed success criteria, and methods 6
Kline [1995, p48] uses a simple complexity index derived from the multiplication of 1) the number of
independent variables needed to describe the state of the system, 2) the number of independent parameters needed to distinguish the system from other systems in the same class, and from 3) the number of control feedback loops both within the system and connecting the system to the surroundings. He uses this index as a rough measure to discuss and rank different types of systems from low to high complexity. His ranking is: Paradigmatic systems of Physics, Chemistry, and Simple Engineering Analyses; Systems of HumanDesigned Hardware; A Singe Human Being; Human Social Systems; Ecologies Containing Humans; and Socio-technical Systems as the most complex. His observation is that the largest contributor to rising complexity is the presence of human beings and other forms of life in the system. 7 Kline [1995, p63] refers to this process as “learning-by-doing”, “learning-by-using”, “trial-and-error”, “muddling through”, and “barefoot empiricism”.
38
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
that favour analysis over synthesis and thus are mostly used to critique existing system without providing suggestions of how they could be approved. Though apparently a very difficult task to handle socio-technical system analysis and design, I believe that using a “learning-by-doing” approach with the right set of guidelines, a good set of tools, and the right composition of people, will take us a good step in the right direction of designing socio-technical robotic systems. As Baxter and Sommerville point out an important aspect of socio-technical system design is to include the user in the process. This is already common practice in several areas of software development in particular in agile methods such as Extreme Programming (e.g. [Beck 2000]), Dynamic Systems Development Method (e.g. [DSDM Consortium 2008]), and Scrum (e.g. [Schwaber and Beedle 2001]). Furthermore the community of human-computer interaction (HCI) addresses issues of usability (e.g. [Nielsen 1993]), human/user centred system design and holistic design (e.g. [Gulliksen et al. 2003]). Both of these disciplines are already closely linked to robotics and both advocate a close interaction with the user in the design process. In relation to HCI, but in more direct relation to robotics, we find human-robot interaction (HRI). HRI addresses, among other things, the perception of humans, and the application of social psychology (e.g. [Young et al. 2009]) to construct cognitive maps that facilitate the generation of safe motion planning (e.g. [Breazeal et al. 2008]). This is used, for example, to construct games where a user and a robot can safely interact (e.g. [Hansen et al. 2010]8 ). User participation in the design process is therefore also an inherent aspect of HRI design ˇ and as Sabanovi´ c [2010] states in relation to the dynamics between technology and society: “This suggests the need for users to get involved in the early stages of the robot design process and for more reflexive practices of design, which take into account the ongoing interchanges between robotics and society”. The inclusion of the user in the design process is therefore essential, but when it comes to socio-technical robotic systems design it is not quite enough – we need a much wider inclusion of people. Some compliance issues addressed in the last section may not, for instance, be directly required by the user or customer but they may indeed be by legislation – for example the Danish laws of person-data security9 addressing what is legal with 8 9
Of which I am co-author. “Persondataloven” – https://www.retsinformation.dk/forms/r0710.aspx?id=828 Accessed 15/5-
2011.
2.2. ROBOTIC SYSTEMS ARE SOCIO-TECHNICAL SYSTEMS
39
respect to handling personal information acquired through digital means. This requires the inclusion of people with knowledge of the law in the design process. It could also be general codes of conduct where a robot’s behaviour may be acceptable in Denmark but not in another country. The user may not be aware of this and we thus need people with knowledge of code of conduct from these countries as part of the design process. Another example is Salvini et al. [2010] who address the need for “design-for-acceptability” arguing that the term acceptability normally is handled as being a “user-specific” or “user-centred” issue, and that this is not sufficient anymore: we need to address it from a much broader angle incorporating also bystander interactions and environment interaction. This may require the inclusion of sociologists in the design process. However, no matter what guidelines and tools are chosen it is important to keep at least one thing clearly in mind: “Sociotechnical theory has at its core the notion that the design and performance of new systems can be improved, and indeed can only work satisfactorily, if the ‘social’ and the ‘technical’ are brought together and treated as interdependent aspects of a work system” [Clegg 2000], that is “where neither the technical nor social subsystems are optimised at the expense of the other” [Badham et al. 2001, p1370].
2.2.4
The Challenge
Placing robotic systems in a socio-technical context results in an increase in system complexity as the hosting organisation, the people in the system, and the robots themselves become inherent parts of the system and intrinsically coupled. This high complexity makes such systems not only hard to analyse but also to design, which introduces a great challenge for robotics in general but, in particular, for the creation of new types of robotic systems with no prior reference systems. As social-technical factors have to be identified and considered at all stages of the system life-cycle – meaning in all stages from conception of the initial idea to decommissioning of the product – it requires the involvement of practitioners from many disciplines from not only the technological fields but also from sociological and business fields. This poses new challenges as issues of achieving a common understanding of what a “socio-technical system” actually is, agreeing on the level of abstraction to use, finding an appropriate
40
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
balance between the technical and social sides, defining evaluation criteria for the social aspects of the system, etc. are essentials to be addressed [Baxter and Sommerville 2011]. No coherent framework currently exists to handle all relevant aspects of socio-technical systems but several methods and guidelines can be found in various disciplines.
2.3
Robots are complex systems
In robotics we often10 hear a robot referred to as a complex system or comprising complex components but rarely is the term actually elaborated as it draws on some common implicit understanding of its meaning that we all share in the robotics community. In an ARS design situation, however, it is important to know more specifically what we mean by “complexity” as it gives us an indication of the development effort and tells us why it is so difficult to make robots that perform in the real world. This section will try to elucidate the term in the context of robotics. According to Oxford Dictionaries Online11 the word complex used as an adjective can mean “consisting of many different and connected parts” or “not easy to analyse or understand; complicated or intricate”. The former is very close to, at least, some definitions of system (see Section 6.1), while the latter refers to the ability of some observer to comprehend the matter in question. In combination the two are close to the definition offered by Jackson and Keys [1984] presented in [Kasser 2007, p17-16]12 where the difference between complex system and its antonym simple system is explained: A simple system will be perceived to consist of a small number of elements, and the interaction between these elements will be few, or at least regular. A complex system will, on the other hand, be seen as being composed of a large 10
Take, for instance, [Durrant-Whyte 2005] where references to “complex” or “complexity” are made
throughout the paper to characterise everything from dynamic models, feature map matching, outdoor navigation, target tracking, fusing and processing of information, to outdoor environment models. Another example is [Brooks 1986] where he uses the terms to characterise behaviours, the environment, and mobile robot control systems. 11 http://oxforddictionaries.com/ 12 Note the “p17-16” does not indicate a range of pages but is the actual page number used by Kasser. He has divided his book into chapters and this is thus page 16 of chapter 17.
2.3. ROBOTS ARE COMPLEX SYSTEMS
41
number of elements, and these will be highly interrelated. [Jackson and Keys 1984] Note here the use of the words perceived and seen, which promotes subjective assessment by the observer: The classification of a system as complex or simple will depend upon the observer of the system and upon the purpose he has for considering the system. If his purpose is to solve a problem which is perceived to exist in the system, then the type of problem he is tackling will be a crucial factor in determining the perspective taken. Often the same system may be seen as being simple or complex, depending upon the problem. [Jackson and Keys 1984] So what both Kasser and Jackson and Keys argue is that though the level of complexity is determined by the observer, the purpose for considering the system in the first place and the amount of (perceived) components and interactions in a system are also key factors. In the next sections I will first explore the issues of complexity perspectives and then explore ARS complexity relating to the more physical aspects of the system by considering its components and their interactions.
2.3.1
Complexity perspectives
The complexity perspective employed by a roboticist may indeed be different from that of a non-roboticist as the roboticist (even as a mere observer) is able to comprehend the quantity of elements and interactions necessary for the system to work13 and thus implicitly incorporates this knowledge into the assessment. A non-roboticist will most likely make his assessment based on what he can visually observe. From a roboticist’s point-of-view, observing an industrial manipulator continuously moving boxes from point A to point B would not be characterised as complex, as neither the robot nor the task are perceived as such, but if the same manipulator were to perform welding with on-line compensation for slack and deflection, the solution would now be regarded as more complex. However, a non-roboticist bystander would possibly consider both systems to be either very simple or very complex: the former if he has some knowledge of robotics but is unaware of the difference in complexity between a pick-and-place 13
At least on the technical level. See the discussion on socio-technical robotic systems in Section 2.2.
42
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
operation and a welding operation; the latter if he has no knowledge of robotics and regards such “technical wonders” with awe. From a roboticist’s point-of-view mobile robots, on the other hand, are generally perceived as somewhat complex regardless of the task they are performing. A system comprising a simple mobile robot performing a simple task on the surface of Mars, may indeed be quite a complex system. One reason is that we know how difficult it can be to make a mobile platform perform even the simplest tasks in a robust manner, but another is that in robotics we carry out our task in some physical environment, which we too characterise as having some level of complexity. On the other hand, as will be mentioned in Section 2.4, a small robot drawing pictures on a piece of paper may be perceived as complex by the non-roboticist but as simple by a roboticist. From these observations it should be clear that it is not trivial to construct a precise complexity metric for robotic systems that is able to quantify generic robotic system complexity, as it will always depend on some specific viewpoint and purpose. However, by stating the viewpoint and purpose explicitly it should be possible to obtain a metric that addresses complexity in robotic systems more formally, thus making it applicable when comparing different systems at the same level of abstraction. In the context of robotic system design such comparisons are essential as the measure of complexity of a certain system or sub-system would allow us to 1) assess the efforts needed to design and construct them and 2) point out to us which parts require more attention than others. That means that the complexity measure should be applicable from the viewpoint of the robotic systems designer and for the purpose of designing an ARS.
2.3.2
Components and Interactions
Though complexity is highly subjective, it does not change the fact that a robot or a robotic system comprises a large number of highly interrelated physical components and often is placed in a socio-technical context. As many roboticists have engineering backgrounds it should be obvious to the reader that we would not call something complex without good reason. Yes, the type of task and the type of environment do indeed play major roles, but as we are often inherently technically oriented, the physical components in the robotic system and their interplay, are of course major factors. This section I have therefore dedi-
2.3. ROBOTS ARE COMPLEX SYSTEMS
43
cated solely to addressing complexity as seen from the component level in order to illustrate from where this complexity originates. To keep the examples less cluttered I will for now ignore socio-technical components (like humans) but they are of course, as presented in Section 2.2, a major contributor to the overall system complexity. For starters let us look at a simple sketch, Figure 2.6, of some of the basic subsystems and components that are often found in a robot. From a certain level-of-abstraction a robot can be said to comprise a Software System, a Sensor/Actuator System, a Power System, an Electronics System and a Mechanics System, which, incidently, are also the titles of often separate R&D entities/departments/groups/teams in companies and universities. Let us imagine each of these groups is responsible for delivering different components of a robot, and that each of these components can be characterised as belonging to a certain component-group as illustrated by the thirteen headlines in the outermost ring of the figure. The headlines also define the level-of-abstraction applied which means, for instance, that CPU may comprise all electrical computer components including I/O ports, A/D and D/A converters, USB ports, etc. A different level-of-abstraction could of course have been employed where these were the parts of the Electronics System instead of CPU, but for simplicity I have chosen this representation. Now, in a given robot how do these components interact to form functioning systems? Imagine some battery powered mobile robot and robot-tool composed of components from the thirteen categories. An onboard vision system could, for instance, comprise components from Sensors (the camera), Drivers (necessary software drivers), Control (some vision algorithms), CPU (a computer platform), Chassis (mounting of components on the platform), Converters (for supplying the correct voltage to the camera and the computer), and Supply (the main battery power). An onboard velocity servo system may be composed of components from Actuators (the motor), Sensors (a velocity encoder), Drivers (motor and encoder drivers), Control (a velocity control algorithm), CPU (a computer platform, I/O, A/D, D/A channels), Signal Conditioning (conversion and balancing of the control signals), Chassis (mounting of the components on the platform), Supply (direct voltage to power the motor and the converters), and Converters (to supply the correct voltage to the computer).
44
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Sensors
Actuators
Drivers Supply S/A System Control Converters Software System
Power system
Communication
Robot Charger
Mechanics System Electronics System Network Chasis
Signal Conditioning
Tool CPU
Figure 2.6: Some of the basic subsystems and component-groups often found in a robot.
For the vision system and the velocity servo system to function, connections facilitating interaction between these components are needed. An interaction is essentially a flow of information between two components and can thus be anything from an abstract concept like “knowledge” to a very physical “stream of electrons”, depending on the level-of-abstraction applied. There is a natural difference in terminology as we regard a system from various levels. Looking at a laptop computer from the outside we see components like casing, keyboard, buttons and screen, where interaction with a user is conducted through “touch”, “light”, and “sound”. If we instead take it apart we see modems, CPU boards, loudspeakers, and hard-drives, where interactions internally are in the form of “data streams”, and “signals”. A further subdivision will reveal semi-conductors, resistors, and crystals with interactions comprising “voltage”, and “current”. And so on and so forth. As an interaction has a source component and a sink component we can depict it graphically as an arrow where the arrow tail indicates the component being the interaction source and the arrow head the component being the interaction sink. Also it is assumed that the conduit of the interaction is embedded within the components unless otherwise
2.3. ROBOTS ARE COMPLEX SYSTEMS
45
stated, thus emphasising that for our purposes interactions are always flows of information. If there is a need for explicitly showing the information conduits they can be separated from the components as illustrated in Figure 2.7. Here three identical ways of passing current from a power supply to a motor can be observed at an increasing level of component-detail. The interaction between the components is current in all cases.
(a)
Supply
(b)
Supply
(c)
Supply
Motor
Wire
Connector
Wire
Motor
Connector
Motor
Figure 2.7: The passing of current from a power supply to a motor shown at three different levels of component-detail.
With this notation the interactions and components constituting the vision system and the velocity servo system can be seen in Figure 2.8 represented as a digraph. It should be noted that the Chassis components have been left out for clarity.
46
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Vision System
Velocity Servo System
Supply
Supply Power
Power
Converters
Converters Regulated Power
Regulated Power
Sensors I/O Signals
Sensors
I/O Signals
Regulated Power
Power
Data
Regulated Power
CPU
Signal Conditioning Data Data
Control
I/O I/O
Data
Drivers
Data
I/O I/O
CPU
Link
Control Signals
Actuators
Data Data
Control Data Data
Drivers
Figure 2.8: The vision system and the velocity servo system represented as two separate systems using the component-groups of Figure 2.6
As these two systems co-exist in the same robot, utilising some of the same componentgroups, it makes sense to combine them to obtain a new merged digraph. This is done by applying the union of the component-groups of both systems as well as their interactions. The result can be seen in Figure 2.9(a), where it can be observed that seemingly duplicate interactions exist as they were present in both systems, for instance, the Data interaction running from Drivers to Control. In the graph they appear to be identical, but as the Data being transported in the two cases are not the same, this seems to advocate keeping both. However, as they both convey Data in some form, this suggests that they can be merged into one without loss of generality. This begs the question: What if the interactions had also had different labels, could they be merged? The answer is “yes� provided that the labels are merged into a new label indicating that several types of interactions take place, as could also be accomplished in the case of Data by choosing more precise names to be able to distinguish the two types. A more compact version of Figure 2.9(a) can be seen in Figure 2.9(b) where the interactions have been merged and the labels removed. In
2.3. ROBOTS ARE COMPLEX SYSTEMS
47
this form the digraph has become a simple graph and can be represented using a binary adjacency matrix as we shall see shortly.
Supply Power
Supply Power
Converters
Converters
Regulated Power
Regulated Power
Regulated Power
Sensors
Power
I/O Signals
I/O
Signal Conditioning Control Signals
Actuators
Sensors
I/O Signals
CPU
Data
Link
Regulated Power
I/O
I/O
Data
CPU I/O
Drivers Data
Data
Data
Data
Data
Data
Signal Conditioning
Drivers
Data
Control
Actuators
Control
(a) The merged systems preserving all interac-
(b) A more compact view where the in-
tions. The red interactions belong to the vision
teractions have been merged and the la-
system and the blue to the velocity servo system.
bels removed.
Figure 2.9: The component-group interactions in a combined vision system and a velocity servo system modelled using the thirteen basic components of Figure 2.6
It is quite evident from Figure 2.9 that even at the level-of-abstraction presented by our thirteen component-groups, the number of interactions grows fast as more systems are added. A more expanded case can be seen in Figure 2.10(a) where the possible interactions comprising our complete imaginary robot are shown. As with the previous figure, several interactions between two component-groups have been merged into one and the labels have been removed.
Communication
Control
Charger
Drivers
Converters
Supply
Actuators
Tool
Sensors
Chassis
Communication
CPU
Network
SignalConditioning
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Network
48
CPU
Network Chassis
Drivers
CPU SignalConditioning Chassis
Supply
Control
Tool Sensors
Charger
Converters
Actuators Converters
Sensors
Supply Charger
Tool
Signal Conditioning
Drivers Control
Actuators
Communication
× × × ×× × ××× × × × ××× ××××× × ×× ×××× ××× ×××× ×× × ××× × × × × × × ×
(a) The interactions represented using as a di-
(b) The interactions represented using an ad-
graph.
jacency matrix.
Figure 2.10: The component-group interactions that may be needed in order to realise our imaginary robot represented both using a digraph and as a binary adjacency matrix.
Even in this simple form the digraph is now quite cluttered with interactions and the reference to complex system inevitably springs to mind. Let us examine this a bit further. To gain a better understanding of what is happening in the digraph, we can represent it using a binary n × n-adjacency matrix, where n is the number of component-groups –
thirteen in our case – and where the row and column labels are identical, and ordered according to some chosen permutation of the component-groups. An “×” in a cell indicates that there is an interaction from the component-group in the row to the component-group in the column, hence representing the arrow in the digraph. The resulting adjacency matrix representation of our imaginary robot can be seen in Figure 2.10(b). By looking at a component-group’s row it is now quite evident in which interactions it represents the source, and by looking at its column those in which it is the sink. The number of sources and sinks related to a component-group is a measure of its coupling to the other component-groups. For instance, the Charger is quite independent of the other component-groups, having a low-coupling, while the CPU experiences several source and sink interactions, having a
high-coupling to the other component-groups. A high-coupling indicates a high system dependency, meaning that a change to a high-coupling component might potentially affect
2.3. ROBOTS ARE COMPLEX SYSTEMS
49
many other components, in particular those that it depends on and those that depend on it. A low-coupling on the other hand may 14 indicate a low system dependency which may imply that it can be changed with less impact to the overall system15 . These effects can be hard to determine exactly – especially at design time – and when they appear in great numbers, it is only natural to perceive the system as complex in accordance with Jackson and Keys [1984]. We have so far only looked at the robot-complexity from a certain level-of-abstraction – a level that was chosen by me to facilitate the construction of a simple example. Other levels-of-abstraction can of course be applied depending on what you regard as pertinent to what you want to observe or communicate. These abstraction processes are used to separate the pertinent from the non-pertinent are known as Cognitive Filters [Kasser 2007, p17-7] and are filters through which we view the world in different ways. In Figure 2.6 I employed two different cognitive filters when representing the two levels-of-abstraction and illustrated their coupling through open-ended arrows indicating “is-part-of”/“belongs-to” relationships, thus indicating how my two views correlate. The two levels therefore show the same system, just represented through different cognitive filters. The coupling of a component therefore directly depends on the level-of-abstraction in which it is viewed. If a new level is added to Figure 2.6 and the CPU is spilt into some full set of subcomponents, perhaps “computer platform”, “I/O”, “A/D-” and “D/A channels”, the interactions now coupled to CPU could be observed as interactions among these subcomponents and the subcomponents of other component-groups. This, however, will not change the observation that CPU has a high-coupling in the robot, but will help reveal in greater detail what causes it. The system is therefore still complex, but will have a different representation typically with more components and more interactions than in the higher level. It is not hard to imagine from Figure 2.10 that if a real-world mobile robot were to be constructed, the number of components and their interactions could grow huge. As an 14 15
This “may” will explained in Section 4.3.4 The terminology of “coupling” is similar to the one often found in Software Engineering accredited
to Stevens et al. [1974], where it is typically used together with the concept of cohesion, indicating how well-formed the components are. High-cohesion is often correlated with low-coupling and vice versa.
50
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
example, consider Figure 2.11 which shows a somewhat simplified component-level view – at some level-of-abstraction – of the TransPot system mentioned in the Introduction using a layered presentation to logically separate components belonging to the environment, the mechanical platform, the sensors and actuators, the electronic interfaces, the I/O, the software drivers, the processing, the communication and the external processing. Information/energy flow among the components are again shown using arrows where the tail is the source and the head the destination.
External Processing
Database
Job planning
RFID map
Path planning
Middleware
Communication
Wireless communication
Middleware
TransPot control
Motion control
Tool control
Processing
Motor control
Motor control
TrackFinder
Drivers
Driver
Driver
Driver
Driver
Driver
Driver
Drivers
Driver
Driver
Driver
I/O
Grabber
RS232
Counter
DAC
DAC
Counter
DO
Interfaces
Interface
Interface
Interface
Interface
Interface
Interface
Interfaces
Interface
Interface
Interface
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Sensors
Motors
Chassis
Troughs
Conveyors
Sensors and Actuators Mechanical Platform
Environment
Sun−screen
Light
DI
Wheels
Lines
RFID tags
Soil/Concrete Mypex
Obstacles
ADC
Dock
DI
Pots
Encoder
DC/DC
Batteries
Sensor
Conveyor
Operator
Charger
Figure 2.11: The component-level view of the TransPot system
From a design perspective, handling these components and their interactions was not an easy task, as even small changes would have great impact on the rest of the system. Especially, comprehending how the various components coupled to the task we were trying to solve was particularly hard. A seemingly small task change would turn out to affect both our environment (augmented with plastic lines and Radio-Frequency Identification (RFID) tags for navigation and absolute positioning) and the coordination between the tool and the motion of the robot. The high complexity and multi-disciplinary nature of the
2.4. THE AWARENESS GAP
51
system made it hard to comprehend and anticipate everything, which is a general problem often observed in robotics. The SRA [European Robotics Technology Platform (EUROP) 2009c] also acknowledges this and in one of its final conclusions states that: The greatest challenge in robotics is the integration of diverse technologies from a variety of fundamental domains into one coherent system. [European Robotics Technology Platform (EUROP) 2009c, p36]
2.3.3
The Challenge
The challenges with respect to complexity are two-fold: First, there is a need for a complexity measure that will allow us to assess the complexity of robotic systems from various levels of abstraction and from the viewpoint of the designer, whose natural purpose is designing such systems. Such a measure would be an asset as it would allow the designer to assess the efforts needed to design and construct a certain system but also allow her to assess which parts would require more design attention than others. Second, the component and interaction complexity of a robotic system are very high as they typically comprise a vast number of components and interaction of both technical and social nature. It is the job of the system designer to manage this complexity in the context of design in a sound and rational way which necessarily includes being able to handle different levels-of-abstraction simultaneously. Methods, tools, and guidelines for how this can be accomplished would be important assets in the design of future socio-technical robotic systems.
2.4
The Awareness Gap
An awareness gap exists between what the public believes is possible robotics-wise and the actual state of robotics. Often it can be observed that what the public considers simple is hard robotics-wise, and what is considered trivial in the robotics community may be perceived by the public to be very hard:
52
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS Public reasoning may be: “If you can construct a Roomba you should also be able
to construct mobile robots which autonomously can clean my whole house and others that can take care of patients in a hospital.” With reference to the former the European Robotics Technology Platform (EUROP) [2009a, p11] claims that not before the year 2020 will a robot actually be able to carry out the task of cleaning 100% on its own. However, observing the media coverage of robotics one would imagine that we were already able to do that now. On the other hand attending a robotics fair, for instance AUTOMATICA in Munich, the public can be observed to be deeply fascinated by small mobile robots drawing pictures on pieces of paper laid out on the ground. Technology-wise this has been possible for four decades using Turtle robots and the Logo programming language, but it nevertheless still manages to captivate an audience. At present this awareness gap can be regarded as a mere curiosity and be mostly accredited to different perspectives on complexity but as I will argue in the following it may have severe implications in future socio-technical robotic systems. Three factors are involved in creating and maintaining this gap: one is the media and they way it (in general) presents robotics, another is the public itself and the last is the robotics community.
2.4.1
The Media
As part of my PhD studies I had to participate in a business course held by FI and afterwards write a business report in topic covered at the course. I chose to write about Robots and Ethics [Dalgaard 2008], where I initially did a survey of the Danish media’s treatment of robotics based on headlines retrieved from the web-versions of three of the major Danish newspapers, Politiken (pol) (http://www.politiken.dk/), Jyllandsposten (jp) (http://www.jp.dk/) and Ekstra Bladet (eb) (http://www.eb.dk/). The following is an excerpt (translated): • “Robot as musical conductor ”, 15/5-2008 (jp) • “The bouncer is a robot”, 14/5-2008 (eb) • “Robots to assist the elderly”, 10/5-2008 (jp) • “The robots are coming! ”, 12/4-2008 (jp)
2.4. THE AWARENESS GAP
53
• “Monster-dog frightens millions”, 10/4-2008 (jp) • “Baby-robot is going to learn how to talk ”, 4/3-2008 (jp) • “Robot makes difficult surgery possible”, 29/2-2008 (jp) • “Robot feeds and herds at the same time”, 27/2-2008 (jp) • “Robot acquires porn-money for the tax-office”, 21/2-2008 (jp) • “Can you love your robot more than you love your neighbour? ”, 30/1-2008 (pol) • “Child-robots under the Christmas tree”, 11/12-2007 (eb) • “Microsoft’s santa-robot is perverted ”, 4/12-2007 (jp) • “Have sex with a robot”, 13/10-2007 (eb) • “Robot demanded 18 jobs”, 8/10-2007 (eb) • “Rullemarie16 got a baby-sister ”, 30/8-2007 (pol) • “Armed robots ready for Iraq”, 3/8-2007 (eb) • “Robots to help brain-damaged children”, 19/6-2007 (eb) A quick glance at the headlines reveals robots as being apparently engaged in a multitude of human job functions: as a conductor, bouncer, caretaker of elderly people, surgeon, soldier, explosives remover, farmer and sex-object. Besides these you find the more scary headlines such as “The robots are coming!”, ”Monster-dog frightens millions”, and “Robot demanded 18 jobs”. Taking a closer look at the stories behind the headlines, they are often not as “colourful” as they are made out to be. For instance, “Robot acquires porn-money for the tax-office” is about an internet search-bot the tax-office applies to monitor internet activity in order to catch owners of porn-sites who do not declare how much money they earn. Also the Microsoft santa-robot is a piece of software which during Christmas time was linked to Messenger so children could “chat” on-line with Santa Claus – apparently he was not too sober. 16
Rullemarie is a tele-operated robot used by Danish explosive experts for remote handling of (possible)
explosives.
54
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS Without going into too much detail about the articles, the point is that from the head-
lines alone it may appear as if robotics is constantly verging on the edge of ethics and therefore is something to be watchful and perhaps even scared about. If the articles had contained what they lead on, it would be easy to get the impression that robots actually already are engaged in job functions that we usually regard as requiring some form of intelligence and social awareness. The problem is here that the only reference many people have to robot intelligence is artificial intelligence (AI), which in the version of media and movies often is comparable to that of humans. Hence – the reasoning may be – the capabilities of robots must be almost human-like. This reasoning is as such sound enough, but the facts on which it is based obviously are not. Let us take a different example. In June 2010 a viral marketing campaign was launched by a Danish affiliated workers union, FOA, aimed at creating awareness of the work conducted by health-care workers in the public sector in order for them to gain fairer salaries. The campaign was not launched using FOA’s own name but was presented as a commercial from a company called RoboCare who, supposedly, had invented three humanoid-like autonomous robots able to take care of the sick, the elderly and children – see Figure 2.12. After a few days of nationwide speculation on the validity of the company and its products, FOA revealed themselves as the actual sender. FOA explained that the commercial was just meant to illustrate what might happen if we lose the human health-care workers, but otherwise stated that they were very much pro health-care-technology in general – as a matter of fact DTI have a quite close collaboration with FOA in this area. However, before FOA revealed themselves, several media (television, newspapers, internet blogs, etc.) had become dedicated to discussing these robots and their (alleged) application in caretaking. Some were outraged by the possible perspective that one day robots (in general) would take care of our elderly, the sick and our children, while others saw it as the early warnings that robots may indeed take over the world some day. Most, however, approached it more calmly, but were now assured that the capabilities of modern day robotics were at a level where such products were a reality. Few saw through the charade and called the bluff – these were mostly more technically oriented people. Mette Strømgaard Dalby17 was interviewed right after the campaign by Danish Radio’s P1 [Dalby 2010] about the possible impacts she saw the campaign having on robotics in 17
Mette Strømgaard Dalby is Head of Development, Kolding School of Design, Denmark.
2.4. THE AWARENESS GAP
55
future welfare and health-care scenarios. She expressed great concern about the “fearfactor” used in the campaign alienating people to robotics by suggesting that robots will take over the human role entirely instead of the factual intention of their just being a supplement. Dalby advocated a more qualified and positive debate.
R (a) RC Senior .
R (b) RC Health .
R (c) RC Play .
Figure 2.12: The three fictitious robots from the fictitious robot company RoboCare. All pictures are taken from the FOA website: http://www.rigtigemennesker.dk/#/se-kampagnen/annoncer/
.
2.4.2
The Public
In spite of these sensational headlines and campaigns, it seems that people are embracing robots in an increasing manner. The number of service robots in personal/domestic use was estimated at 4, 400, 000 units world-wide at the end of 2008 (4, 200, 000 were vacuuming or floor cleaning robots, 133, 000 were lawn mowing robots) with an expected addition of 4, 800, 000 units (4, 600, 000 being vacuuming or floor cleaning robots and 123, 000 lawn mowing robots) in the period 2009–2012 alone [International Federation of Robotics (IFR) 2010, p12]. However, the vacuuming, floor cleaning, and lawn mowing robots, which constitute a majority of these robots, are not deployed in direct pHRI during operation and are relatively small in weight and size. These factors make them both physically and mentally safe and, as the work they conduct does not present any apparent ethical problems, these robots easily become an integral part of a household. What these types of robots represent is therefore in strong contrast to how the media present robotics in general, but as the robots are becoming more advanced and engaged in direct pHRI this contrast grows smaller and may in the worst case prove damaging for future robotic systems. The FOA case is an example of where “damage control” was needed.
56
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
An awareness gap therefore exists between the public and robotics which is linked both to the facts about the technology itself but more importantly also to what the technology represents. In a socio-technical robotic system with direct pHRI the technology is not necessarily more sophisticated than that of a simple robot vacuum cleaner, but the sociotechnical context in which it is applied changes it from being “just” a piece of funny electronics into representing something that may inflict emotional consequences on its surroundings. When this happens – or when we think this may happen – we start thinking in terms of moral and ethical consequences. Peter C. Gøtzsche18 has a clear opinion on how to assess and discuss ethical problems [Gøtsche 2007]: “Ethical problems, just like scientific ones, can be subjected to a logical analysis.” To facilitate this Gøetzsche suggests the following sequential model of reasoning: 1. Recognition of the problem. 2. Assessment of the facts of the case (including scientific facts). 3. Consequential considerations (utilitarianism). (a) consequences for those involved in the case. (b) consequences if all did so in similar cases. 4. Deontological considerations (duties, regardless of consequences). 5. Distributive justice (e.g. just distribution of limited resources). 6. Ethical intuition (after having considered the above). It is beyond the scope of this dissertation to treat each of these, but one important point to be made is regarding “2. Assessment of the facts of the case (including scientific facts).” Gøetzsche argues that immediately after recognising the existence of a potentially ethical problem, the facts have to be assessed. As the previous discussions and the ones in the next section will show, the facts are unfortunately not always correctly presented to the public making a sound discussion very hard. 18
Peter C. Gøtzsche is a Danish medical researcher, and leader of the Nordic Cochrane Center at Rigshos-
pitalet in Copenhagen, Denmark
2.4. THE AWARENESS GAP
2.4.3
57
The Robotics Field
In robotics we like facts, but the increasing media focus and an increasing need for funding research through external channels has made it necessary for many of us to adapt to this new world and sell our “products” in more, let us say, popular ways. As an example consider Professor Hiroshi Ishiguro, director of the Intelligent Robotics Laboratory at Osaka University, Japan, who, among other things, has constructed a famous life-like copy of himself called the Geminoid shown in Figure 2.13.
Figure 2.13: Hiroshi Ishiguro together with his “Geminoid”
The Geminoid naturally received a great deal of attention in the media when it was first presented to the public. Wired featured a story by John Brownlee on Ishiguro and the Geminoid on the 26th of April 200719 containing the following excerpt:
Called the Geminoid, the robotic doppelganger looks like a creepy waxen mummy. . . its dead eyes cold appraising the succulence of the flesh of the children around it. It is part cyborg, part real doll, part Shigeru Miyamoto, part Dracula. It is horrible. It hates you. 19
http://www.wired.com/table of malcontents/2007/04/professor ishig/
58
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS On a promotional flyer for Phie Ambo’s documentary Mechanical Love [Ambo 2007],
in which Ishiguro and the Geminoid play significant roles, we read: “It [the Geminoid] is ready to take his place as expert, teacher, family father, and husband.” The fact is that the Geminoid was created as part of Ishiguro’s studies into interaction and tele-presence and is essentially a tele-operated robot with minor autonomous features like chest cavity movements to simulate breathing and a eyelid blinking frequency resembling that of humans. It was thus in no sense a cyborg, part Dracula or intended as a substitute for himself in all aspects of life as suggested by the flyer. Ishiguro has of course been interviewed by the media on several occasions, but was not heard actively protesting the media’s coverage. Why not? Well, Ishiguro briefly visited MMMI in the spring of 2008 and gave a short presentation on his project. His opening line was something like: “You all probably know my work from the media. Now I will tell you what it’s really about.” He then addressed the factual aspects of his research and furthermore added that the media had helped expose his research to everyone by turning it into good stories. He had not been hiding anything from the media, but they had found the story not in his facts but in what they perceived as facts. Humanoid robots have always been subject to much wonder and fear, as people have ascribed them with human abilities based on their appearance. This can be explained by Masahiro Mori’s hypothesis of the Uncanny Valley [MacDorman 2005], and the media’s focus on this is therefore quite understandable – it sells more papers or gets more viewers. The example of the Geminoid is just one among many, and is not in anyway meant as an attack on Ishiguro, his research or his handling of the media. However, it illustrates quite well an ongoing symptomatic trend where we, as roboticists, sometimes accept the media’s colourful stories as they provide great exposure of our research and promote the robotics awareness in general. Only when the stories do not suit our liking, we react. Is it then too late?
2.4.4
The Challenge
To facilitate the market entry of future socio-technical robotic systems we need to close the gap between the public and the robotics world. As illustrated in Figure 2.14 by the solid arrows, the media often work as a filter between robotics and the public, occasionally
2.4. THE AWARENESS GAP
59
twisting facts to produce good stories. The reactions from the public often go through the media again and possibly result in more questions to the robotics world which result in an attempt to provide more facts to the media, and so on and so forth.
Facts Facts
Robotics
Story
Media Questions
Public Reactions
Questions Figure 2.14: The information flow between Robotics, the media and the public.
The only way we can hope to close the gap is by accepting the need to take more control over the flow of information by: 1) Establishing a more direct dialogue with the public revealing the true facts of what we do and our actual agenda (shown as dashed arrows), and 2) be more conscious in our dealing with the media administering the facts for mutual benefit (shown in red).
Luckily these steps have already been taken in many robotics areas thus slowly revealing a sound dialogue with the public. At DTI, for instance, we have in the past four years published a weekly e-Newsletter presenting our own work and that of others in the robotics field. The newsletter has about 800 subscribers counting researchers, companies, media, and people from the general public. On several occasions the media has used one of DTI’s stories as background material for their own – often quoting it directly – which has resulted in the establishing of direct contact between the public and DTI (or other media and DTI). In these situations DTI can more easily control the information flow.
60
2.5
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Collaboration
As mentioned before, robotics is an inherently complex and multi-disciplinary field covering most areas of the natural sciences and even aspects of project management and social sciences. This complexity and breadth makes it difficult for any one person or institution to manage all technical aspects of a robot development process which is why the robotics community is often centred locally on specific sub-domains in robotics, making them specialist in, for instance, vision and control systems, but perhaps not in mechanical design and HCI; or in mechanical design and sensors, but not in software engineering and navigation. This local division of focus is quite understandable given the breadth of robotics, but an additional explanation may be found in the inherent difference in technical orientation found in the people. As Kossiakoff and Sweet [2003, p20] point out – referring to Systems Engineering in general – three fundamental types of technical people exist with entirely different intellectual objectives, interests, and attitudes: the scientist, the engineer, and the mathematician. The scientist is dedicated to understanding the nature and behaviour of the physical world, the mathematician is usually primarily concerned with deriving the logical consequences of a set of assumptions, which may be quite unrelated to the real world, and the engineer is mainly concerned with creating a useful product. Kossiakoff and Sweet state that most technical professionals typically can be modelled as some weighted combination of the three, with one being the absolutely most predominant, that is, they are specialised. The reason being that “most technical people resist becoming generalists for fear they will lose or fail to achieve positions of professional leadership and the accompanying recognition. This specialization of professionals inhibits technical communication between them; the language barrier is bad enough, but the differences in basic objectives and methods of thought are even more serious.” [Kossiakoff and Sweet 2003, p21]. Robotics is a discipline that requires specialists in all three forms to handle the “foot work” but indeed also generalists able to make sense of it all. Coordinating such a scenario is quite challenging and it begins the moment you place these people in the same room and ask them to work together. The following quote seems appropriate at this time: This is a wonderful orchestra. Every musician – male or female or any kind of -male – is an artist in her or his own right. It is only when we play together we might have a little problem. — Victor Borge while conducting the Dance of the Comedians
2.5. COLLABORATION
61
Though some universities and companies may be well equipped to handle most of the development process of a new robotics system themselves it is more often seen that it is done in larger collaborations between companies, universities and (to some extent) the endusers, forming consortia in the setting of large scale national or international R&D projects. Many of these projects receive some form of external funding as they, in the case of robotics, often are resource demanding and often contain an element of either research or innovation (or both), promoting local, national or international interests. In Europe, for instance, the Framework Programmes for Research and Technological Development (FP) currently at FP7 running from 2007–2013, partially fund a large portfolio of robotics related projects. The European Robotics Research Network (EURON) keeps a user-updated website20 on current and previous FP funded European robotics research projects: 2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
15
21
21
7
24
4
11
1
2
2
2
Table 2.1: The number of European robotics projects past and present from 2000–2010 found on the EURON web-site 8th of August 2010.
The list in Table 2.1 is not complete but does give some indication of the robotics projects activity in Europe. As most projects run for 2–4 years it would indicate that at least 50 projects are currently in the pipeline. The projects in Table 2.1 all receive funding from the FPs and thus the robotics projects receiving only national funding, or the robotics projects not receiving funding at all, are not included in the count. However, no matter the type of funding scheme, it is nevertheless quite common that different parties team up and form some collaboration agreement and organisational structure in which the project is to be carried out. Depending on the type of project and the organisational structure such setups offer several pitfalls that it is important to be aware of in order to be able to counteract them. Consider the following non-exhaustive list outlining what some of them may be: Communication: Partners may come from different work/educational backgrounds and thus (almost by definition) may experience communication problems as they do not 20
http://www.euron.org/resources/projects/index Accessed on the 8th of August 2010.
62
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS speak the same “language”. Also if partners are from different countries, cultural and language barriers may be issues.
Location: Partners are often not from the same physical location – they might even be from different countries. This may further increase an already existing communication barrier or create a new one. Agendas: Each partner has her/his own agenda for being part of the project. Some want new technology, some want to publish papers, some only want the generated knowledge, some want a finished product, some want only to use the final product, and some are just there to observe. Usually the agenda is also coupled to how much funding the partner receives versus how much self-financing has to be provided. Objectives: Due to communication problems and different agendas it may be hard to reach a common consensus on what exactly the main project objective is. From my personal experiences from both participation in projects and writing full and partial applications for both national as well as EU projects, this issue seems to be a recurring theme throughout the project life-cycle. Knowledge: What technical and managerial knowledge is required in order for the project to succeed and how is this knowledge reflected in the project partners. What happens if a partner decides to leave the project prematurely? - can the project continue? For a given robotics project involving collaboration between several partners, the described issues form a somewhat minimal set. Delving into project management and collaboration strategies I am sure that several other issues would surface. As further reading I suggest Fisher et al. [1999] on negotiation techniques or Kossiakoff and Sweet [2003] on project management in systems engineering.
2.5.1
The Challenge
The challenges of collaboration are known to all of us and we probably discovered them, that day in the first grade, when we were assigned to the same group as the guy we absolutely did not get along with and had to make a poster – it was tough but we had to make it, and usually we did. As was also the case in Section 2.4, communication is of the absolute essence when collaboration has to work, but with that said, it may not always be
2.6. RESPONDING TO THE CHALLENGES
63
enough – especially when different agendas are part of the equation. However, being aware of the individual partners’s roles in a project may improve collaboration significantly, and thus also the end-results of the project.
2.6
Responding to the challenges
In the previous five sections I have presented five challenges all originating in the systemlevel that I believe to be the most pressing with respect to the design of robotic systems: 1) we need to guarantee compliance with real-world demands of dependability and ELS compliance, 2) the fact that robotic systems are socio-technical systems and not just mechatronic systems, 3) the fact that robots are complex systems, which makes them inherently hard to design, 4) an awareness gap exists between the public and roboticists, and 5) robotic projects are often done in multi-disciplinary and international groups which may result in several problematic issues.
Individually each of the five challenges represents design issues that are separate research areas in their own right, and to cover them all to their full extent in this thesis would not be realistic given the time frame available. Therefore I have chosen to focus my efforts on the first three and also mainly address their system-level impacts — with the exception of complexity, which I shall treat on several levels. With reference to Figure 2.2 from the introduction to this chapter I can now provide a modified view illustrating this coverage. This is shown in Figure 2.15. The following discussions and results directly fulfill Objective 1 of Table 1.1 on page 14.
ilit y te a om ch nd 4) pl nic EL a S Aw ex ity l is su 5) are es C ne ol ss la g bo a ra p tio n
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
o−
3)
C
ci So
D 1)
2)
ep e
nd
ab
64
System level
Component level
Figure 2.15: The extent (green) to which I will address the five design challenges in this thesis.
2.6.1
Challenge 4–5
The awareness gap in robotics and the collaborative nature of robotics relate to the development process of robotic systems in several ways through the robotic system life-cycle. From finding partners and funding for a project, and establishing a good consensus of goals and objectives among these partners, to explaining to the public the motivation for the system and why it is dependable and complying with potential ELS issues. As stated in the introduction to this chapter, these challenges – though indeed very important – are out of scope with the main thread of this thesis and I have therefore chosen not to pursue them further.
2.6.2
Challenge 1–3
Challenge 1–3 are pursued in two ways: separately and as a unity. Let us consider the former first.
2.6. RESPONDING TO THE CHALLENGES
65
1) Dependability and ELS compliance As addressed in Section 2.1 a method is needed for conducting a system-level assessment of which dependability and ELS compliance criteria are the most relevant to a specific design problem. Such an assessment will provide valuable input to the designer and the design process as it will 1) provide insights that enables the designer to derive – or update – system specific design requirements, and 2) constitute a checklist that can be used to rank different system solutions with respect to their conformance to the criteria. The way I have chosen to respond to this issue is by utilising a Decision Support method that constructs a designer/user/stakeholder value ranking of the different criteria through a conjoint analysis. This method is covered in detail in Section 4.4 and shown in use in Section 4.5. The process is fully traceable and facilitates the ranking of different solutions with respect to how they conform to the criteria, which is a valuable tool throughout the design process. Other methods for obtaining the assessment have also been contemplated, for instance, the use of questionnaires, which is a commonly used tool (e.g. [Sommerville and Dewsbury 2007]), but the method described above is in many ways superior as it forces the ranker to perform pair-wise preference rankings of a large subset of all possible pairs of criteria. This process is most enlightening as the discussions leading to the individual choices helps elucidate and clarify the issues further. Using questionnaires furthermore requires a lot of post-processing as they do not on their own produce a ranking, which has to be manually calculated. This is done implicitly in the method I will present. 2) Socio-technical issues As stated in Section 2.2 a major challenge in designing socio-technical robotic systems is that socio-technical factors have to be identified and considered at all stages of the system life-cycle. This requires among other things: • The involvement of practitioners from many disciplines, not only from the technological fields but also from sociological and business fields.
• Achieving a common understanding of what a “socio-technical system” actually is • Agreeing on the level of abstraction to use
66
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS • Finding an appropriate balance between the technical and social sides • Defining evaluation criteria for social aspects of the system This list is not by far exhaustive and requires a more in-depth study of the field than
has been possible within the time frame of this thesis. That does not, however, make the issues less important. I believe that to start addressing these challenges in robotics we have first, as a community, to fully recognise that some robotic systems are, in fact, socio-technical systems. As mentioned previously some of the more “socially oriented” areas in robotics such as Human-Computer Interaction (HCI) and Human-Robot Interaction (HRI), seem to have actually captured parts of these aspects; an observation parallel to the one Baxter and Sommerville [2011] have made in the domain of large IT-systems. I participated in a workshop entitled “Beyond Gray Droids: Domestic Robot Design for the 21st Century” (DRD09) at the Human-Computer Interaction conference (HCI2009) with the paper [Dalgaard and Hallam 2009], and found among the participants a broad consensus on the direction in which robotics is currently moving and therefore also the importance of a more direct inclusion of the human-factor when designing robots; this consensus I had not previously found in the more “mechatronic oriented” areas of robotics from where also I originate. Bringing these “groups” closer together can, from my point of view, only lead to a more coherent common understanding in the robotics community of the challenges we face, which will be a great leap in the right direction of creating better robotic systems. In this thesis I will directly address socio-technical considerations in Section 4.3 where I present a framework of important considerations to make when generating conceptual robotic solution ideas. However, this is on a very low-detailed level and is only included to ensure that designers will be forced to at least acknowledge that the considerations are necessary. In Section 6.4 I will present a system-level reference model for robotic systems which is able to handle certain aspects of a socio-technical context as it provides the means to capture the notion of system on various levels of abstraction. 3) Complexity In Section 2.3 I presented two sub-challenges with respect to handling robotic system complexity in a design context:
2.6. RESPONDING TO THE CHALLENGES
67
1. The need for a complexity measure that will allows us to assess the complexity of robotic systems from various levels of abstraction and from the viewpoint of the designer whose natural purpose is designing such systems. 2. Methods, tools, and guidelines for handling the component and interaction complexity inherent to socio-technical robotic systems. The first is addressed explicitly in Section 8.1 where I will show how the Genefke-scale from Appendix B can be utilised to assess the complexity of an ARS as seen from the perspective of a designer. This is done by using a measure of “development need” rather than of complexity per se, but as will be argued, the tight correlation between the two makes it a feasible abstraction. With respect to the second, I will first address this in Chapter 6 where I present a hierarchical ARS systems view enabling the designer to represent components and their corresponding interactions. This is taken a step further in Chapter 7 where a design tool is presented that enables the designer to manipulate these components and interactions at various levels of abstraction, facilitating a more rational design process. Motivating a systems-view Let us now consider a combined impact of the three challenges: that we need a proper systems-view of robotic systems. The fact that robots are complex systems, that we need to issue system guarantees regarding dependability and ELS, and that robotics can be regarded as socio-technical systems, all relate to the notion of system and promote a use of the word to denote not only the physical robot but also its inherent couplings to the tasks it carries out and the components of the environment in which it operates. This coupling is necessary in order to address properly socio-technical issues as well as issues of dependability and ELS compliance, as all these are system factors depending on what the system does, where it does it, and how it does it. Establishing a systems-view of robotics able to capture this “trinity” is therefore imperative in order to guarantee both a sound design process and a feasible system solution. That means that the traditional way – the robot-centric way – of regarding a solution as being “a robot solving a required task” (as in Figure 2.16, Left) and hence letting the design process be guided by that fact, is insufficient in many cases as
68
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
it will not cover all aspects of a solution. For instance, the robot – in this case exemplified by a mobile robot – will conduct its task in an environment with which it interacts; it may operate in the vicinity of people with whom it may interact; the people may carry out tasks that facilitate the task of the robot; the people may interact with the environment and with each other; the robot may be partially operated by an operator with whom it interacts; and so forth. Obviously, the traditional approach will argue, these notions are an inherent part of “a robot solving a required task” – which may or may not be correct. If the traditional way of designing robotic systems does indeed take these factors into account then a robotic system has indeed been realised that solves the problem. If not, chances are that the system will not work as intended. In the systems way of thinking (as in Figure 2.16, Right) these factors are parts of the solution as they are explicitly part of the system itself. That means that if a robotic system is to solve a task in some environment, the consequential alterations to the environment caused by this (for example the moving of an object, the guidance of a museum visitor, etc.) are actually alterations to or adaptations of the robotic system itself. Though arguably the only difference between the two different points of view in Figure 2.16 lies in the interpretation of abstract boundaries, the systemsview offers a more holistic – or complete – view of the situation, which facilitates the design of correct solutions for the new generation of robotic applications and makes new design options in task or environment explicit.
Robotic System Robotic System Task
Task
Mobile Robot
Surroundings
Mobile Robot
Surroundings
Figure 2.16: Two ways of regarding a robotic system. Left: The traditional robot-centric view where the mobile robot constitutes the robotic system. Right: The systems-view where the robot is only part of the robotic system.
2.6. RESPONDING TO THE CHALLENGES
69
In this systems-view it is evident that for an ARS to be able to solve the required problem many different parts have to interact, coordinate, cooperate and adapt. It is therefore also evident that the physical robots are a central but not necessarily a dominating part of the puzzle as all the parts are necessary for the system to carry out its tasks. In this view relevant aspects of task and environment become inherent and necessary elements of the system itself, making it imperative to consider them all thoroughly when designing and realising a particular ARS. These observations are further supported by recent studˇ ies from the field of human-robot interaction: Sabanovi´ c [2010], for instance, argues that “a social robot, as a participant in interaction with people, becomes a part of a larger social and cultural system and needs to be studied as such”, and Salvini et al. [2010] argue for the inclusion of “acceptability” in the design process of service robots which they address by adopting the Human-Tech Ladder [Vincente 2004] as means to handle the people-technology system. The Human-Tech Ladder is a five level systems hierarchy comprising physical, psychological, team, organisational, and political levels, each with a corresponding list of hard and soft technologies. Each step on the ladder represents “a relatively distinct aspect of people, and thus, a qualitatively different way of thinking about them” [Vincente 2004, p53], coupled with technology at various levels of abstraction indicating “the relationships we need to build into the system to achieve good fits.” [Vincente 2004, p60]. Applying a proper systems-view when designing ARSs is therefore imperative to cope properly with the addressed challenges. This systems-view will be a focal point of this thesis from this point on and will first be elaborated in Chapter 3 where I present what an autonomous robotic system is, from this perspective. In Chapter 4 I will then show how these elaborations can help us design an ARS from the system-level. The need for a system-level model able more directly to capture subsystems, components, and interactions is then presented in Chapter 6, motivated first by an in-depth discussion of what a “system” actually is and how it can be represented.
70
CHAPTER 2. SYSTEM-LEVEL DESIGN CHALLENGES IN ROBOTICS
Chapter 3 What is an Autonomous Robotic System? Design Methodology Solution (ARS)
Problem
Task*
Task Environment
Design Process
Environment* Robots
Requirements
Figure 3.1: The ARS part of the design methodology.
In the previous chapter I argued that in order to address the first three challenges properly we need a systems-view of robotics able to express the unity of the physical robot, its tasks and its operating environment. This systems-view I call an Autonomous Robotic System (ARS), and it was first introduced briefly in the introduction on page 8 as the output of the design process as shown in Figure 3.1 – that is, it is some instantiation of an ARS we are aiming for when designing a new robotic system. The definition of ARS was also presented in the introduction which I will restate here for convenience: Definition 1. An Autonomous Robotic System (ARS) is a system that solves, resolves, or dissolves problems in some environment facilitated by one or more autonomous or semiautonomous robots. 71
72
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM? This definition addresses both the functionality – or behaviour – of the ARS as a system
that solves, resolves, or dissolves problems, but also the environmental context in which it does so, and the robots by which it is aided. The focus is therefore on the actual ARS instantiations as these are the systems that we have to bring into the real world. To facilitate this I will in this chapter address ARSs from their more physical representation comprising Robot, Task*, and Environment* components as shown in Figure 3.1, which I will henceforth refer to as the RTE -representation1 . Section 3.1 will first address each of the RTE-components in more detail, and in Section 3.2 I will explain how different ARSs can be classified in terms of these components. That is done through the presentation of a model I have termed the ARS Continuum.
3.1
The RTE-components
In the following sections I will present my definition of the three RTE-components and close with an evaluation of the validity of the representation.
3.1.1
The Task*
The RTE Task* -component represents one or more designated jobs, functions, or processes that the Robots- and Environment* -components facilitate. This means that they may be carried out by both robot-components and environment-components, either as separate activities or as collaborations. An ARS Task specification of moving an item from position A to position B can have several Task* -component solutions depending on the overall system configuration. Consider, for instance, the following five possible Task* -components in an ARS comprising one mobile robot and one human: 1. Mobile Robot picks up item at position A, drives to position B, and places the item. 2. Mobile Robot picks up item at position A, drives to position B, hands the item to Human, and Human places the item. 3. Mobile Robot picks up item at position A, throws it to Human at position B who places the item. 1
The asterisk denotes a possibly altered task and environment with respect to the initial design Problem
which is the overall function that the ARS has to perform in order to reach its goals (see Section 4.2)
3.1. THE RTE-COMPONENTS
73
4. Mobile Robot picks up item at position A, gives it to Human who runs to position B and places the item. 5. Mobile Robot at position C sends Human an SMS stating: “Pick up item at position A and place it at position B �. Human complies. Conversely, the overall system configuration depends also on the Task* -component, as some of the possibilities in the list are not realisable without some adaptation of both the mobile robot and the environment – for instance, the addition of a mechanical throwing arm, a GSM modem, a mobile phone, and lessons in how to catch flying objects. The Task* -component is therefore inherently coupled to both the robot- and the environmentcomponents. Note that the above list does not make any assumptions of how the tasks are actually carried out, but merely what has to be done. This can of course be specified at a higher level-of-detail to explicitly include, for instance, motion commands to a mobile robot or exact global coordinates. Which level-of-detail is chosen depends entirely on the situation and the ARS in question.
3.1.2
The Environment*
The RTE Environment* -component represents the potentially altered environment in which the system carries out its Task* -components, where the alterations represent changes made to facilitate the ARS solution by making it, for instance, cheaper, simpler, faster, or perhaps more dependable. The Environment* -component therefore constitutes the actual context in which an ARS operates. That means both the surroundings like a factory floor, a living room, a swimming-pool, a lawn, a Mars canyon, a hospital ward, or wherever the ARS is made to operate, and the objects in these surroundings. The elements of both the original Environment and the Environment* -component are therefore all physical in nature, and represent the subset of all physical components in the world (in some view) with which components of the ARS interact. That means that elements like humans, robots from other ARSs, trees, air, rain, grass, benches, tables, chairs, stones, etc. may be found as elements in an Environment* -component of an ARS autonomously cutting grass in a park.
74
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM? Consider the term “affordance” invented by Gibson [1979, p127]: “The affordances
of the environment are what it offers the animal, what it provides or furnishes, either for good or ill.” With a translation of this into an ARS context, we may rewrite it as: “The affordances of the Environment (* )
2
are what it offers the ARS, what it provides
or furnishes, either for good or ill.” As a rough classification of elements in the Environment (* ) -component we may thus regard each one as being either “good” or “ill” at any given point in time during the operation of the ARS. Instead of “good” or “ill” I will instead refer to the role of an element as being either an Enabler or a Disabler : Enablers: Elements facilitating the Task* -component. Disablers: Elements obstructing the Task* -component. Note that I have explicitly coupled the two roles to the Task* -component instead of to the perhaps more obvious Robots-component. The reason is that Environment (* ) elements affect not only the robots in the system but also other elements in the Environment (* ) component, like for instance, humans that also perform a task in the ARS. The Task* component is therefore the common denominator linking to ARS function rather than to ARS components. In the example with the ARS autonomously cutting grass the robot, the air, and the grass are the foremost Enablers while trees, benches, tables, chairs and stones constitute Disablers as they may be seen as obstacles to avoid or elements that may potentially damaging. Humans on the other hand may be perceived as either depending on their role. If the human is an system operator she is (more than likely) an Enabler while humans in the form of children playing on the grass are potential Disablers – which precise role they have at any given time is entirely dependent on where they are and what they do. If the operator suddenly blocks the path of the robot, she becomes a Disabler. If the robot on the other hand blocks the path of the operator it becomes a Disabler. If the children move a potential obstacle away from robot’s or operator’s path, they in turn function as Enablers. This ambiguity can be modelled by introducing the concept of Commuters, that is: Commuters: Elements sometimes functioning as Enablers and sometimes as Disablers. 2
I will use Environment (* ) to indicate a reference to both the Environment and the Environment*.
3.1. THE RTE-COMPONENTS
75
Commuters are therefore elements to pay special attention to as their roles may change over time. In the example above, humans were used to illustrate this concept, and in fact most Commuters are animate/living objects as they may behave in unexpected ways seen from the ARS’s perspective – this may again include the robots. However, other elements may also be Commuters. Take, for instance, an ARS where a mobile robot has to follow a static wall at some fixed distance. The wall is naturally an Enabler, but may very quickly turn into a Disabler if the robot collides with it. The Commuter role of the wall in this case is fairly obvious but Commuters which are predominantly Enablers but only occasionally turn out to be Disablers can be quite challenging to identify and thus hard to handle properly. Commuters which are predominantly Disablers and occasionally Enablers are on the other hand easy to handle, as we may choose to see them entirely as Disablers and disregard their Enabling role – naturally depending on the situation. We can thus divide all Environment (* ) -component elements into one of three major categories as illustrated in Figure 3.2: The ones that are always Enablers, the ones that are always disablers, and the ones that are Commuters. This categorisation, though very simple, facilitates a grouping and classification of Environment (* ) -component elements based on their role in the ARS, which in a design situation, will help the ARS designer obtain an overview of the system. This will be treated further in Chapter 4.
Enablers
Always Enablers
Disablers
Commuters
Always Disablers
Figure 3.2: The three types of Environment(*) -component elements.
The tight coupling of the Environment* -component to both the Task* - and Robotcomponent is quite evident as the classification of elements as either Enablers, Disablers, and Commuters directly depends on what tasks need to be solved and what robots are used.
76
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
Furthermore the choice of what elements to include in the Environment* -component in the first place depends also on the task and robots as they indirectly dictate the needed “level of inclusion”. It may, for instance, not be necessary to consider “birds” as part of the environment in an ARS operating underwater – unless, of course, it is an ARS conducting a rather unusual form of duck hunting.
3.1.3
The Robots
The RTE Robots-component represents the robots operating in the ARS. The definition of “robot” seems to be strongly related to the eye-of-the-beholder, and I will therefore spare the reader my feeble attempt at yet another definition, as I am sure the existing ones are all correct from their particular perspective. I will instead try to outline the boundaries for how I see a robot in an ARS context, which I am confident will cover a sufficiently large set of existing robot definitions. Plural As the word Robots indicate, several robots may indeed be part of an ARS. They may be operating either simultaneously or at different times; they may be identical or entirely different; or they may share the same workspace or not be anywhere near each other. Task-enabled From Definition 1 – and from the previous description of the Task - and Environment* components – it is evident that the ARS must somehow solve, resolve, or dissolve problems by conducting tasks in some environment. That implies that the ARS robots must be orchestratable in such a way that they will carry out their part. The orchestration may be in the form of off-line programmed tasks, on-line adaptive behaviour, commands via operator remote control, voice commands, tactile interfaces, or any other means of telling the robots “what to do”. So what types of robots are task-enabled? Well, of course the obvious industrial manipulators and a wide range of mobile robots, but also Paro (Figure 2.4 on page 27) and robot toy dinosaur Pleo3 perform tasks which qualify them as being task-enabled – on a 3
By
Innvo
Labs
Corporation
http://www.pleoworld.com/
based
in
Hong
Kong
and
Carson
City,
Nevada.
3.1. THE RTE-COMPONENTS
77
high-level they may be regarded as advanced “Sense and Act”-scenarios. So from a task point of view, most robots may indeed conform to this requirement.
Autonomy As stated in Definition 1 the ARS robots can be characterised as being either “autonomous” or “semi-autonomous”. From a semantic perspective there is an obvious difference between the two where the former refers to robots that are decoupled from any human intervention during operation, meaning that all decisions regarding what to do is the responsibility of the contained system called the “robot”. The latter, on the other hand, refers to robots where the decision making is partially conducted by the robot itself, but where humans retain some level-of-control and may intervene – by some means – during operation. In the real-world robots truly autonomous robots are rarely found, as robots generally are constructed to serve some human purpose and we therefore do not wish to relinquish all control. Exceptions do of course exist where it is imperative that the robots during certain operational periods in fact are truly autonomous, for instance, in space- or underwater robots. However, in these robots, humans still hold the ultimate control and can command a Mars robot to stop what it is doing (with minute long delays, of course) or command an underwater robot to return to base (when it has resurfaced to be able to receive the command, that is). The robots in an ARS will therefore typically be semi-autonomous in nature but may also just be advanced remote-controlled (RC) devices – even in some cases tethered4 . I will not make any judgement call on whether these types of devices always are or are not robots, but only state that socio-technical and dependability issues as well as ELS compliance may also be important in an ARS with a RC device. RCs may therefore be equally fit in the ARS context as any semi-autonomous robot, but the assessment will have to be made in each case.
3.1.4
Evaluation
The rationale behind the RTE-representation have been discussed both in the Introduction to this thesis and in Section 2.6, and I believe it to be a sound model both for comprehension and discussion of ARSs but also as a support framework in an ARS design process – 4
Think, for instance, of tele-operated robots or the first version of the Asimo robot.
78
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
these topics will further be explored in Chapter 4. The RTE-representation has so far been directly evaluated in the context of the EU project PV-Servitor 5 of which DTI is partner, where it has been used in the consortium to support discussions on the importance of taking a system-level approach to the design of robotic systems. Furthermore the RTE-representation and its rationale were part of a central subproject description – of which DTI was main author – in the application for “Resilient Reasoning Robotic Co-operating Systems” (R3-COP)6 . R3-COP received an EU review evaluation of 49 out of 60 possible points and was approved with a total budget of e18, 319, 660. One of the reviewer comments were: “The concept of developing generic reference architectures for autonomous robotic systems, improving design methodologies, and apply rigourous testing of those systems with measurable coverage according to relevant metrics is sound.” On the more critical side it can be argued that the RTE-representation is bound too closely to the technical aspects of an ARS and thus does not seem properly to capture the social aspects that I so strongly advocated the need for in Chapter 2. I must admit that this is in part true as it does not explicitly have a “social subsystem”. However, the model is not only technical as it incorporates all physical aspects of the ARS and thus also people in both the Task* and Environment* components. The social issues are addressed explicitly during the design process – as will be shown in Chapter 4 – and the RTE-representation therefore captures them on a more implicit level represented by the people present in the system and what roles they play.
3.2
The ARS Continuum
In order to understand what an ARS is it makes good sense to explain its context relative to robots and robotic systems in general. Seeking inspiration in the system-centric continuum of robotics [Hallam and Bruyninckx 2006] we can represent it as a triangle where the vertices are labelled with the RTE-components as shown in Figure 3.3. Any robotic system can now be found as a dot somewhere in the continuum based on how the RTE components are balanced to obtain a successful system, where I denote “success” as the particular robotic system’s ability to fulfill its intended purpose. Some systems will 5
The PV-Servitor project is partially funded by the FP7 SME programme. The project focusses on
using robot technology to autonomously clean Photo Voltaic (PV) solar panels, as dirt causes severe power-output loss. 6 R3-COP is an ARTEMIS Projects funded under the European Union’s Seventh Framework Programme and, for DTI’s part, by The Danish Agency for Science, Technology and Innovation. DTI is one of the participants, where we have to generate and contribute knowledge about a methodology-based development framework for autonomous systems. Some of this will be based on the work presented in this thesis.
3.2. THE ARS CONTINUUM
79
be more robot-oriented than others, meaning that the robot contributes the most to the overall success of the system, and will therefore be placed in the area closer to the robot vertex of the triangle. Others might be more task- or environment-oriented, indicating a larger success dependency on the task and environment respectively. Systems found very close to the robot vertex are
Robot
naturally not very coupled to either the task or the environment and therefore often represent generic platforms like the LEGO Mindstorm kits. They can of course be used to create robots that solve specific tasks Task
Environment
or operate in certain environments, but as a system the
Figure 3.3: The system-centric con-
kit is inherently centred on the robot in a non-task and
tinuum of robotic systems – a slight
non-environment way.
adaptation of Fig. 2 from [Hallam and Bruyninckx 2006]
Systems found along the edges of the triangle are lacking one of the components, or it at least has minor
significance. A robotic system with a minor environment component could, for example, be a robot able to physically manipulate and solve a Rubik’s cube. Here the task and the robot are inherently linked, but the environment is equivalent to a simple table or a robotic work cell – depending on the type of robot of course. A robotic system with minor task component could, for instance, be a toy submarine, where the coupling between the watery environment and the robot is essential for it to function, while the task may not be more than random motion. A robotic system with minor robot component could be a water wave generator. The generating element itself may be a simple plate moving back and forth, while the manner in which it moves and the environment’s response to this motion are tightly linked. The aforementioned types of robotic systems are not considered to be ARSs following the simple argument that not all RTE-components are sufficiently represented according to the RTE-component description given in Section 3.1. That means that some subset of Figure 3.3 where the RTE-components are sufficiently represented can be drawn and thus will represent the system-centric ARS Continuum where ARSs can be found. This is illustrated in Figure 3.4. The choice of a subset in the shape of a similar but scaled triangle with the same centroid as the the robotic systems continuum, was made to emphasise that only systems with one or more RTE-components missing would not be regarded as ARSs,
80
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
and that the three components carry equal weight.
Robot
To
Ro
bo
t
LEGO Mindstorm
er olv eS Cu b ik’s Ru b
ne
ari
m ub
yS
ARS Continuum
Water Wave Generator
Task
Environment
Figure 3.4: The system-centric continuum of ARSs shown as a subset of the system-centric continuum of robotic systems. A few examples of non-ARSs are also shown.
Any “proper” ARS can now be found somewhere in the continuum of Figure 3.4 based, of course, on what type of system it is. As was the case in Figure 3.3 some ARSs will be more robot-oriented than others, some more task-oriented than others, and some more environment-oriented than others. The point is here that just because we employ a RTE systems-view for ARSs it does not mean that the components carry equal weight in a given system – on the contrary. In fact an ARS can be characterised as some ratio, R:T:E, of the RTE-components relative to each other indicting how it is “oriented”. This effectively positions it relative to other ARSs and makes it possible to conduct direct comparisons. While it may not be desirable actually to compare the absolute ratios of two different ARSs, it is on the other hand interesting to compare them on a more fundamental level. This can be done by partitioning the ARS Continuum into well-defined and disjoint sets, where an ARS will belong to only one. In Figure 3.5 Left six such partitions have been constructed by the triangle’s medians, and one extra partition around the centroid, resulting in seven partitions. They are numbered from 1 to 7 and each represents a specific category of ARSs determined by their position in the continuum. Figure 3.5 Right shows a table indicating how the partitions are related to the RTE-components. A “++” indicates high orientation
3.2. THE ARS CONTINUUM
81
towards the particular component, “+” average orientation, and “−” that the orientation is low.
Robot
1 6
2
R
T
E
1
++
+
2
++
3
+
−
−
4
−
5
3
7
#
6
5
Task
7
4
+
−
++
+
++
−
++
+
+
++
+
+
− +
Environment
Figure 3.5: Left: The 7 ARS Continuum segments. Right: their coupling to the RTE-components.
It can be observed from Figure 3.5 that by using the medians as partition separators we are forced to rank the RTE-components of an ARS according to which orientation is more dominant, which is less dominant, and which is least dominant. Arguably we might want to represent an ARS with two equally dominant orientations and one least dominant orientation. Should this be necessary I suggest placing the dot on the median line between the two dominant orientations. The division into only six partitions was done to make it as simple as possible, and adding three extra to accommodate these situations seemed unnecessary. Partition 7 represents those ARSs where a balance exists between the three orientations such that it is hard to find one dominant orientation. These types of ARSs are not necessarily more complex, better, or more coherent than ARSs belonging to any of the other six partitions, but possibly they might be regarded as having a higher system-complexity as the couplings between the RTE-components may be larger in numbers and perhaps stronger. This, however, I have not verified with certainty.
82
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
To introduce how ARSs may fit in this partitioned ARS continuum let us look at a few examples.
(a) ARS Guide (REUTERS/Nicky
(b) ARS Live-Fire Training (2007-2010
Loh)
Marathon Robotics Pty Ltd)
(c) ARS
Handicap-aid
(AFP
(d) ARS Roomba
PHOTO/JIJI PRESS)
(e)
ARS
Acting
(YOSHIKAZU
(f) ARS Rescue (TOSHIFUMI KITA-
TSUNO/AFP/Getty Images)
MURA/AFP/Getty Images)
Figure 3.6: Six types of real-world ARSs
. Figure 3.6(a) shows the MSI produced robot named “Rich” demonstrating giving a tour walking down a garden trail in Linkou, Taipei County, Taiwan on October 18, 2008. From
3.2. THE ARS CONTINUUM
83
the context of this picture it is not entirely evident exactly how the ARS operates but as a guide-ARS the robot-component has a very strong impact on the success of the overall system. Its (presumed) foremost task of conveying information to people is closely linked to the robot itself and thus also plays a major part. The environment on the other hand plays a less dominant part – in my interpretation at least – though interactions with humans may occur and navigation depends on the surroundings. However, I chose to regard the link between the robot and the task as being a stronger success-factor and thus place this ARS in partition 1. Figure 3.6(b) shows the Rover system by Marathon Robotics which applies state-ofthe-art robotic technology to live-fire training. The segway-based mobile robots are autonomous and function as moving targets in an urban environment model. Here the robots and the environment both play crucial roles as it is the robots’ ability to navigate the surroundings that contributes most to the success of the system. The tasks – or scenarios – conducted by the system are to some extent pre-programmed and controlled centrally, which makes them slightly less important in this perspective. However, if the scenarios are not played out well, the users’ experience may not be positive and the overall perceived success of the system will be diminished. This suggests that the task is the most crucial part, but I still believe the robot and the environment to take precedence. I place this ARS in partition 2. Figure 3.6(c) shows Japan’s Health Minister Yoichi Masuzoe sitting with “My Spoon”, developed by Japan’s Secom, designed to help disabled people eat meals by using a joystick controllable by either the jaw, hands or feet. The robot itself is a simple RC manipulator arm which, of course, is quite important as it facilitates grabbing the food and moving it to the mouth. However, it is through the interplay between the human (part of the environment) and the robot that the purpose is fulfilled for the most part. I therefore place this ARS in partition 3. Figure 2.4 (page 27) shows the robot-seal Paro developed by the National Institute of Advanced Industrial Science and Technology (AIST), Japan, in close interaction with an elderly woman. Though the robot itself is important the success of the system lies more in its ability to react appropriately in its direct interaction with humans. That places this ARS in partition 4. Figure 3.6(d) shows a Roomba vacuum cleaner robot, developed by iRobot Corporation, cleaning a living room with both furniture, toys, and a child. The Roomba is capable of
84
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
autonomous cleaning motion largely based on random-walks (at least in the early versions). Naturally the robot itself plays a major role in this ARS, but as can be observed from the continuous development of the Roomba product range, completing the cleaning task in an efficient way (coverage) while navigating a semi-structured – but unknown – environment, seems to be the “selling point”. I therefore place this ARS in partition 5.
Figure 3.6(e) shows the humanoid robots Wakamaru, produced by Japan’s Mitsubishi Heavy Industry, taking part in a drama for the world’s first robot and human experimental theatre, at Osaka University, Japan, on November 25, 2008. Judging from my insufficient information I would say that though the robot is essential, the success of the system may depend even more on its ability to actually “act”, that is, the task it performs. The environment is of course also important but I will in this case not regard it as the prime catalyst of the system’s success. I place this ARS in partition 6.
Figure 3.6(f) shows Tokyo Fire Department’s rescue robot transferring a mock victim onto itself during an anti-terrorism exercise in Tokyo, on November 7, 2008. The coordination of both task, robot, and environment in this ARS requires extreme finesse as the failure of any one part may not just be a problem but in the extreme case, fatal. It is, for me, quite impossible to attribute the success of this ARS to any one of the three in particular, and it must therefore necessarily belong to partition 7.
The resulting ARS continuum can be seen in Figure 3.7.
3.2. THE ARS CONTINUUM
85
Robot
Guide
Live−fire
Rescue Handicap−aid
Acting
Roomba
Paro
Task
Environment
Figure 3.7: Seven different ARSs shown in the ARS continuum.
3.2.1
Evaluation
The ARS Continuum model is perhaps a little out of scope with the other contributions presented in this thesis as I have not found a direct use for it in the ARS design process. However, I believe that as an “as-is” tool it may be an asset in both disseminating and communicating the workings and rationale of the RTE-representation to a broader audience. As presented in Section 2.2.2, DTI has constructed the Welfare Technology Assessment methodology [Danish Technological Institute 2010] which is widely used to assess the potential of new welfare technology products. Perhaps the ARS Continuum could be an addition to this as I believe welfare technology products will often belong to partitions (3), (4), or (5). Other direct DTI robotics activities include socially interacting robots (e.g. [Hansen et al. 2010; Hansen 2011]), which may typically belong to partitions (5), (6), or (1); horticultural robotics, which may typically belong to partitions (2), (3), or (7), and so on. Perhaps a classification of all DTI’s robot activities could be classified using the ARS Continuum, and this way be more readily communicated in a more structured way. However, this will have to be assessed at a later date.
86
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
3.3
Conclusions
In this chapter I have presented what an ARS is in terms of its three system components Task*, Environment*, and Robots, and have shown that an ARS Continuum model can be constructed using these components. These accomplishments directly fulfill Objective 2 of Table 1.1 on page 14. The ARS Continuum can be used to characterise an ARS by ranking its three components in the order of how much they contribute to the overall success of the system, where “success” is the particular ARSs ability to fulfill its intended purpose. By partitioning the continuum into seven disjoint sets any ARS can be thought of as belonging to one set, thus effectively introducing seven categories of ARSs. Seven different real-life ARSs were used as examples of these categories.
To illustrated more clearly what are the intended application domains of various tools, methods, models/representations developed in this thesis – see Figure 1.3 on page 16 for an overview – with respect to the ARS design process and the system and component levels, I will at the end of each chapter present an illustration as shown in Figure 3.8. The design life-cycle model(s) visualised in the horizontal direction will be explained in Section 4.1, and the vertical model is the system/component model shown in Figure 1.2 divided into three partitions: 1) the system-level, 2) the intermediate levels, and 3) the component-level. Each tool, method, and model/representation now spans a certain part of the system/component levels and a certain part of the life-cycle representing its intended application domain. The application domain of the RTE-representation model and the ARS Continuum model presented in this chapter can thus be shown as in Figure 3.8. The reason for the relative short life-cycle span of the RTE-representation will become evident in the Chapter 3 where a more detailed system-level model, POEM, is introduced.
3.3. CONCLUSIONS
87
Planning
Concept Development
System−level Design
Concept Development
Needs Analysis
System level
Concept Exploration
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
RTE−representation
Advanced Development
Engineering Design
Post Development
Operation & Support
ARS Continuum
Intermediate levels Component level
Figure 3.8: The intended application domains of the tools, methods, models/representations developed in Chapter 3 shown with respect to the design life-cycle as will be presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2.
88
CHAPTER 3. WHAT IS AN AUTONOMOUS ROBOTIC SYSTEM?
Chapter 4 Aspects of System-level ARS design Design Methodology Problem
Solution (ARS) Task*
Task Environment
Design Process
Requirements
Environment* Robots
Figure 4.1: The Problem, the Solution and the Design Process of the design methodology.
In the previous chapter I presented what an ARS is in terms of the RTE-components and showed how ARSs can be categorised by means of the ARS Continuum spanned by these components. In this chapter I will discuss what it implies actually to design such an ARS, that is, what it means to transit from a Problem to a Solution – called the Design Process – as shown in Figure 4.1, thus creating a physical ARS instantiation. As the focus of this thesis is on the system-level aspects of ARS design I will not be offering a full solution to the design problem but instead provide methods and that will aid the designer in certain parts of the process – in particular those that directly originate at the systemlevel. This directly addresses Objective 3 of Table 1.1 on page 14. To illustrate the use of these methods and tools, I have constructed a design test scenario, ServiceBot, that I will use as a running example through this chapter and Chapter 8, that is, I will apply the addressed concepts, methods, and tools to the example immediately after they have 89
90
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
been presented. The results from the test case will be used as part of the evaluation of the approaches. To put things in perspective I will first in Section 4.1 give an overview of what a full design process of an ARS may contain. This serves two purposes: 1) to give the reader an idea of “the whole picture�, and 2) provide a contextual reference frame I can use to show exactly where the developed methods and tools I present in this thesis will apply in an actual ARS design situation. Section 4.2 then explains what a Problem comprises and presents three different ways of addressing it in an ARS design situation. Section 4.3 presents discussions on what ARS design considerations are important seen from the system-level perspective and from the perspective of the RTE-representation. In Section 4.4 I present a quick overview of decision-making as means to help the ARS design effort. Section 4.5 then presents an ARS system-level concept generation framework that serves primarily to illustrate how dependability and ELS issues, socio-technical issues, and complexity issues, can be directly incorporated into the ARS design process supported by direct utilisation of the RTE-representation. This section also introduces ServiceBot as means of evaluation. Section 4.6 offers an evaluation of the presented results and Section 4.7 a conclusion.
4.1
The ARS design process
To illustrate first how a full transition from a Problem to a Solution may manifest itself consider the TransPot system. Figure 4.2 shows the Problem and our Solution as it would appear in the view of Figure 4.1, though naturally simplified. The Problem comprises the Task of transporting pots, an Environment comprising soil, pots, people, greenhouses, trees, rain, plastic, and so forth, and a set of Requirements addressing both production requirements, operational time, dependability issues, and economy. The Solution comprises a single semi-autonomous mobile robot as the Robots-component, an Environment* -component with added plastic lines and RFID tags for navigation, a mechanical dock in the production facility, trained system operators, a computer controlled gate to the production facility, a large conveyor belt, and a few other things, and finally a Task* -component showing the overall job functions of the robot, the workers, and a machine moving pots to the conveyor belt.
4.1. THE ARS DESIGN PROCESS
Requirements
Design Process
* Transport 5000 pots/hr * 8 hours operation * Safe and robust * Cheap
Environment *
Robotic System
* Workers pot pots * Machine moves pots to conveyor * Robot gets pots from conveyor * Robot drives to bed # * Robot places pots in bed * Robot returns to conveyor
Robots
* Transport pots from production facility to beds and place them on the ground
Task*
Solution
Environment
Task
Problem
91
Figure 4.2: The Problem and the Solution in the TransPot ARS.
This representation, however, does not provide insights into the structure of the design process itself which included handling often changing customer requirements, tests and experiments, decisions, analyses, and so forth, which, in fact, are common issues in the life-cycle of most engineered systems. Initial work on these structural issues of the ARS design methodology is presented in Appendix D which is a revised version of the paper: Concerning a Rational System-level Design Methodology for Autonomous Robotic Systems [Dalgaard and Hallam 2009]. It presents the properties and structure of the design methodology necessary to facilitate the complete transition from a Problem to a Solution as shown in Figure 4.1; a process we can characterise as a step-wise materialisation of the final Solution [Kossiakoff and Sweet 2003, p122]. The resulting structure is for convenience shown also in Figure 4.3. It comprises several sequential phases – a pre-phase followed by Phase 1 –Phase N – facilitating and incremental process. Each phase may internally have several iterations and will in the end produce a set of deliverables comprising documentation, prototypes and possibly components.
92
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
Problem
Pre−phase
Phase 1
Phase 2
Phase N
Solution
Task
Task*
Environment
Environment *
Requirements
Robots
Deliverables
Deliverables
Deliverables
Figure 4.3: The structure of the design methodology.
Appendix D does not, however, address precisely what the function of each phase should be and what activities they may contain. To address this I will now briefly present two development models from domains relating to robotics – one from product development and one from systems engineering. I could also have chosen development models from, say, software development, where Extreme Programming [Beck 2000] and the Unified Software Development Process [Jacobsen et al. 1999] would have been good candidates. However, the purpose here is, as also stated in the introduction to this chapter: 1) to give only a general outline of what an ARS design process may contain, and 2) to provide a contextual reference frame for where the methods and tools I present later may apply in the ARS design process. When a complete process model for ARS design has to be designed at a later date these methods should of course not be ignored, but for now, the chosen methods will suffice.
4.1.1
A generic product development process
Consider first Figure 4.4 which shows a generic product development process comprising six distinct phases each comprising an iteration of Marketing-, Design-, Manufacturing-, and Other Functions-aspects [Ulrich and Eppinger 2008, p14]. These include: Phase 0 – Planning: Project approval; launch of development process; defining corporate strategy; assessment of technology; considerations of product platform and architecture; defining supply chain strategy; identifying production constraints, etc. The output is the project mission statement.
4.1. THE ARS DESIGN PROCESS
93
Phase 1 – Concept Development: Collection of customer needs; development of industrial design concepts; alternative product concepts are generated and evaluated; estimation of manufacturing costs; economic analysis, etc. Phase 2 – System-level Design: Definition of product architecture; decomposition of the product into subsystems and components; identification of service issues, etc. Phase 3 – Detail Design: Complete specification of geometry, materials, and tolerances; production costs are assessed, etc. Phase 4 – Testing and Refinement: construction and evaluation of multiple preproduction versions of the product; early prototypes are built; reliability tests are conducted; sales plans are developed, etc. Phase 5 – Production Ramp-Up: the product is produced and evaluated by customers; the product is launched.
Figure 4.4: The generic product development process as presented by Ulrich and Eppinger [2008, p23].
Though this structure seemingly maps well to the phases of Figure 4.3 it does not have the same emphasis on iterations and prototyping that is required in ARS design as it is a generic model for product development of simple systems. Ulrich and Eppinger [2008, p21] state that for complex systems the last three phases of Figure 4.4 are typically substituted with several parallel Design and Test sequences followed by an Integration and Test phase and lastly a Validation and Ramp-Up phase in order “to address a number of system-level issues. The concept development phase considers the architecture of the entire system, and multiple architectures may be considered as competing concepts for the overall system. During the system-level design phase the system is decomposed into subsystems and these further into many components. Teams are assigned to develop each component. Detail design of the components is a highly parallel process in which many development teams work at once, usually separately. Managing the network of interactions across components and subsystems is the task of system engineering specialists of many kinds.”
94
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
4.1.2
A generic systems engineering development process
Consider now the example from Systems Engineering, where Kossiakoff and Sweet [2003, p52] present a generic eight phase system development life-cycle model shown in Figure 4.5 which comprises three stages: the first two – Concept Development and Engineering Development – encompassing the development part of the life-cycle, and the third – Post Development – the post-development period. The Concept Development stage is the initial stage of the formulation and definition of a system concept perceived to best satisfy a valid need; the Engineering Development stage covers the translation of the system concept into a validated physical system design meeting the operational, cost, and schedule requirements; the Post Development stage includes the production, deployment, operation, and support of the system throughout its life-cycle [Kossiakoff and Sweet 2003, p54].
Concept Development
Needs Analysis
Concept Exploration
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Integration & Evaluation
Production
Operation & Support
Figure 4.5: The system life-cycle model of systems engineering as presented by Kossiakoff and Sweet [2003, p52].
The Concept Development stage comprises three phases: Needs Analysis: Defines the need for a new system; addresses whether or not available technology is likely to support the increased capability desired. Concept Exploration: Examines potential system concepts in answering the question: “What performance is required of the new system to meet the perceived need?” and “Is there at least one feasible approach to achieving such performance at an affordable cost?”. Concept Definition: Selects the preferred concept answering the question: “What are the key characteristics of a system concept that would achieve the most beneficial balance between capability, operational life, and cost?”. A number of alternative concepts must be considered and their relative performance, operational utility, development risk, and cost must be compared. The Engineering Development stage comprises three phases:
4.1. THE ARS DESIGN PROCESS
95
Advanced Development: Since the concept development stage is largely analytical and carried out with limited resources, significant unknowns are to be fully defined and resolved: the “unknown unknowns”; identification and reduction of development risk; devoted to designing and demonstrating the undeveloped parts of the system; systems engineering is central to the decision of what needs to be validated and how, and to the interpretation of the results; experimental models and simulations are often employed to validate component and subsystem design concepts at minimum cost; when the risks of using unproven technology are large, this phase is often contracted separately, with contracts for the remaining engineering phase contingent on its success. Engineering Design: Detailed engineering design of the system; usually punctuated by formal design reviews which provide an opportunity for the customer or user to obtain an early view of the product, monitor its cost and schedule, and provide valuable feedback to the system developer; issues of reliability, producibility, maintainability, and other “ilities” are of paramount importance; Integration & Evaluation: integration of the engineered components into a functioning whole and evaluating the system’s operation in a realistic environment; often requires the design and construction of complex facilities to closely simulate operational stimuli and constraints, and measure the system’s responses. The Post Development stage comprises two phases: Production: production of the system; no matter how effectively the system design has been engineered for production, problems inevitably arise during the production process; Operation & Support: provision of a logistic support system; training programs for operators and maintenance personnel; instrumentation required for training and maintenance is often a major component of the system to be delivered; minor and major upgrades during the life time of the system driven by evolution in the system mission, as well as by advances in technology that offer opportunities to improve operation, reliability, or economy.
96
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN The application of the systems engineering method “can be thought of as the system-
atic application of the scientific method to the engineering of complex systems. It can be considered as consisting of four basic activities applied successively as illustrated in Figure 4.6.” [Kossiakoff and Sweet 2003, p69]. These steps are: Requirement analysis, Functional definition, Physical definition, and Design validation, where the specifics vary depending on the type of system and the phase of its development. As can be observed several internal feedback loops exists in each phase indicating that each phase comprises several iterations which is consistent with the structure I proposed in Figure 4.3 – it can rightfully be argued that this structure can, in fact, be mapped to a spiral model [Boehm 1988].
From preceding phase Objectives
1. Requirements analysis Requirements
2. Functional definition Functions
3. Physical definition System model
4. Design validation
To next phase
Figure 4.6: The system engineering method top-level flow diagram from [Kossiakoff and Sweet 2003, p70].
To get a better overview of how Figure 4.5 couple with Figure 4.6, Kossiakoff and Sweet [2003, p80] offer the systems engineering life-cycle model shown in Figure 4.7.
4.1. THE ARS DESIGN PROCESS
97
Step
Phase
Needs Analysis
Concept Exploration
Concept Definition
Advanced Development
Engineering Design
Integration & Evaluation
Requirement Analysis
Analyze needs
Analyze operational reqmts
Analyze performance reqmts
Analyze functional reqmts
Analyze design reqmts
Analyze reqmts
Functional Definition
Define system functions
Define subsystem functions
Define component functions
Define subcomponent functions
Define part functions
Define functional tests
Physical Definition
Visualize subsystems, technology
Visualize components, architectures
Select components, architectures
Specify component construction
Specify subcomponent construction
Specify test equipment
Design Validation
Validate needs, feasibility
Validate performance reqmts
Simulate, validate system effectiveness
Test critical subsystems
Validate component construction
Test & evaluate system
Figure 4.7: The system engineering method over life-cycle from [Kossiakoff and Sweet 2003, p80].
In Figure 4.7 it is especially important to note that the analyses of requirements is an ongoing process all through the system life-cycle but with focus on different types of requirements depending on the current phase. This is particularly essential as “a basic characteristic of systems engineering is that everything is not necessarily what it seems, and that important assumptions must be verified before the are accepted as being valid.” [Kossiakoff and Sweet 2003, p71]. This viewpoint is shared by Kasser [2000] who notes that as the requirements may change during the development life cycle1 the goal of Systems Engineering – and thus also ARS design – seems to be to provide a system that: • Meets the customer’s requirements as stated when the project starts • Meets the customer’s requirements as they exist when the project is delivered • Is flexible enough to allow cost effective modifications as the customer’s requirements
continue to evolve during the operations and maintenance phase of the system life cycle.
As Kasser points out: “this is, of course, impossible with today’s technology”. However, he suggest that it is possible to come close and achieve a large degree of convergence between the requirements and the capability of the system by not identifying all the requirements at the start of a project. Instead we should identify: 1) the highest priority requirements - the show stoppers, and 2) the real requirements - as opposed to apparent requirements. 1
For instance due to changes in the project vision, in the economic situation, in the work force, etc.
98
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
This is essentially the same viewpoint as Kossiakoff and Sweet. Note that proper definition and handling of requirements is a discipline in its own right often referred to as Requirement Engineering. For further reading on the subject see, for example, [Nuseibeh and Easterbrook 2000; Sommerville 2003; Kossiakoff and Sweet 2003; Kasser 2003; Grady 2006; Hari et al. 2007].
4.1.3
Comparison
Both the generic product development method presented by Ulrich and Eppinger [2008] and the generic systems engineering method presented by Kossiakoff and Sweet [2003] adhere to the same overall structure of the development process – except for slight differences in terminology – which can be illustrated by comparing the two models as shown in Figure 4.8 where I have stretched the former to fit the structure of the latter. The major difference between them is that Ulrich and Eppinger’s method is dedicated to product development where Kossiakoff and Sweet’s method employs a broader systems view to cope with systems of larger development complexity which also explains its higher and inherent focus on iterative cycles. Furthermore Kossiakoff and Sweet’s method handles the product through all phases of its life cycle starting with needs analysis and ending with support and improvement, where Ulrich and Eppinger’s start slightly later with project approval and assessment of technology, and stops after the product has been launched.
Planning
System−level Design
Concept Development
Concept Development
Needs Analysis
Concept Exploration
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
Figure 4.8: A comparison of the product development model by Ulrich and Eppinger [2008] and the systems engineering method presented by Kossiakoff and Sweet [2003].
With respect to the ARS design process both structures may apply well depending on the type of ARS in question. If a simple system has to be developed – or if it is a straight forward adaptation of an existing system – the structure of Ulrich and Eppinger’s model may be quite suitable. If a more complex ARS has to be designed, Kossiakoff and
4.2. THE PROBLEM
99
Sweet’s structure may be more appropriate as it is slightly more elaborate and focuses on the entire life-cycle. However, as addressed in the introduction to this chapter, the purpose of presenting these development methods was not to present a final structure for ARS design, but more to elucidate what activities are required. NASA’s model [NASA 2007], for instance, follows a somewhat different structure, but the activities are to a large extent the same.
4.2 4.2.1
The Problem What is a problem?
Typically an ARS is realised to fulfill some desired function in response to a problem, and can therefore be characterised as having “goal-seeking behaviour”, also referred to as teleology [Hitchins 2007, p6]. The goal, of course, depends on perspective, and it can be argued that a system performing “something” always has a goal however intangible or unquantifiable it may be. The goals of an ARS may also be intangible or unquantifiable seen from a higher level perspective. Consider, for instance, the goals of “making people with dementia feel better” and “making the indoor climate healthier”. An ARS comprising Paro (Figure 2.4 on page 27) may serve the former while the an ARS comprising a Roomba (Figure 3.6(d) on page 82) aims at the latter. Perhaps neither robot was developed with exactly those goals in mind: perhaps Paro was developed as a cute robot providing some degree of interaction with people through motion and sound, and perhaps the Roomba was developed as a robot vacuuming floors able to collect XX grams of dirt per hour – but again, perhaps the higher level goals were what the developers were actually striving for. To avoid constraining the ARS design process unnecessarily the Problem of Figure 4.1 therefore aims at capturing all “levels of goals” relevant to an ARS context, no matter how tangible and quantifiable they are. Naturally, in order to make a (working) ARS instantiation complying with desired goals, subgoals and sub-subgoals may have to be established to properly assess the overall “success” of the system. This may indeed not be an easy task – it is, however, imperative that it can be done. To address this explicitly the Problem has been defined as comprising a Task -component, an Environment-component, and a Requirements-component. The Task is the function that the ARS has to perform in order to reach its goals, the Environment constitutes the
100
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
physical context where the system must operate (much like the Environment* -component of Section 3.1.2), and the Requirements may comprise functional – what it must be able to do – as well as non-functional – relating to performance and compliance issues (see Section 2.1) – requirements on both the system- and component-levels, and constraints that the system is subject to and must obey in order to reach its goals2 . This Problem representation seeks to ensure (perhaps by slight coercion) that the ARS goals addressed can be “converted” into a more quantifiable structure, explicitly addressing what has to be done, where it has to be done, and under what requirements it has to be done. As an example consider the Problem-components of the TransPot ARS shown in Figure 4.9.
* Transport pots from production facility to beds and place them on the ground
Requirements
Environment
Task
Problem
* Transport 5000 pots/hr * 8 hours operation * Safe and robust * Cheap
Figure 4.9: A somewhat simplified version of the Problem-components of the TransPot ARS.
The Problem-components specified here are naturally very much simplified, but are, nevertheless, not far from the what we aimed for when we first started the project. The gardeners’s overall goal was to obtain higher productivity and they had found that a feasible approach was to rationalise their internal transportation of pots under the shown (initial) Requirements. They decided to look for a technical substitute for their current human solution as internal transportation was cumbersome and was wearing out their workers, 2
The reason for not making a separate Constraints-component is that constraints can be reformulated
into formal requirements.
4.2. THE PROBLEM
101
and having heard of Manox they thought that a robot might be the feasible way to go. The overall goal and the Problem-components were therefore not initially linked to an ARS solution, but just to some technical solution. This, of course, raises a very fundamental and interesting question: being roboticists we naturally think in terms of using robots in our solutions, but is that actually always a good thing? If better non-robotic solutions to a given problem exist in other domains should we not consider these in our efforts? I wonder if anyone has made actual cost-benefit calculations on using sheep to cut grass instead of using robotic lawn-mowers3 . I am sure that under certain conditions the sheep will prove to be a superior choice. My point is that it is never bad to think out-of-the-box in terms of possible solutions even though they might seem ridiculous – why shoot sparrows with canons4 ?
4.2.2
To solve, resolve, or dissolve a problem
Definition 1 states that an ARS is “a system that solves, resolves, or dissolves problems”. These terms refer directly to Ackoff [1981, p171] who states that a problem can in general be either resolved, solved or dissolved. Let us briefly look at the differences between them: To resolve a problem is to select a means that yields an outcome that is “good enough”. Ackoff calls this the clinical approach as it relies heavily on past experiences and current trial and error for its inputs, is rooted deeply in common sense, and makes extensive use of subjective judgement. Research may be applied but is rarely used exclusively or allowed to play a decisive role. To solve a problem is to select a means that is believed to yield the best possible outcome, that optimises. Ackoff calls this the research approach as it is largely based on scientific methods, techniques, and tools. It makes extensive use of mathematical models and real or simulated experiments, and therefore relies heavily on observation and measurement, both of which it aspires to carry out as objectively as possible. To dissolve a problem is to change the nature of either the entity that has it or alter its environment in order to remove the problem – in other words: “move the goal posts” 3
However, in one of Husqvarna’s more recent (May 2011) robotic lawnmower product catalogues a
“functional specification” of a sheep was presented to facilitate easy comparison with its robotic counterparts. 4 A Danish proverb.
102
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
[Hitchins 2007, p17]. Ackoff refers to this as the design approach, as designers often try to change the characteristics of the system that contains the part with the problem, that is, they look for dissolutions in the containing whole rather than for the solutions in the contained parts. Adding all three methods to the explicit ARS definition is done to signal that various approaches may be applied when handling an ARS problem. To exemplify, consider the problem of “vacuuming dirty floors in my house”, and consider the Roomba solution to this problem. This ARS seems to attempt to resolve the problem instead of solving or dissolving it. The former would suggest that instead of an ARS based on a generic5 robot that preforms “well on average” a customised ARS for each particular household should be made, carefully optimised for the configuration of exactly those surroundings. The latter would suggest that we instead remove (or redefine) the problem, for instance, by sealing off the area so dirt cannot arrive in the first place – perhaps not the best solution, especially because it does not comprise robots. However, considering the background story of iRobot and the complexity of robotic systems, I am quite certain that they did, in fact, try to solve the problem; but if a problem to outsiders appears to have been resolved rather than solved, where does the argument falter? In the perception of the problem at hand: when customers buy a Roomba they want it to be a product that can vacuum their particular house which it is not, of course, specifically designed for. What iRobot’s original problem specification for the Roomba was – or still is – is, however, unknown. This renders the above assessment of how the Roomba addresses a problem wrong and illustrates that the use of the terms resolve, solve, and dissolve are only valid if the original problem specification is known. As another example consider the TransPot project: here we attempted to solve the gardener’s problem by making a customised solution: a mobile robot able to transport the pots from the production facility to designated beds in the container field, obeying the productivity requirements. The overall solution was thus based on science and engineering skills, but as the problem was broken down into smaller sub-problems we found that several of these needed to be resolved or dissolved. Many of the former we based on common sense rather than scientific facts like the construction of the HCI interface to the 5
Generic in the sense that it applies to a large number of households.
4.2. THE PROBLEM
103
system. It worked and served its purpose, but was perhaps a bit too engineer-like and would have benefitted from a more proper HCI design process. Many of the latter emerged as we went along with the project and were typically the result of an initial attempt to solve the problem in a more scientific way. For instance, to park the mobile robot aligned with the conveyor belt where it would receive the pots to be transported, we attempted several optimisations of its control parameters to prevent misalignment stemming from unintentional oscillations of the chassis, and did not succeed. Finally we found a way to dissolve the oscillation problem by mounting physical docking clamps on the ground facilitating a mechanical alignment of the robot – in RTE-representation terms we adapted the environment to facilitate a solution. Due to the autonomous nature of ARSs robots, several problems can also be addressed by ARSs in ways that help dissolve a problem. Consider, for instance, a warehouse where heavy items have to be moved around manually by workers. The problem would be that “workers are worn down by repeated lifts of heavy items�. To resolve this the warehouse could hire more people and reduce the weight of the items. To solve this, an exo-skeleton solution may be applied as it would provide the workers with extra strength and thus less wear. To dissolve this, a reconfiguration of the warehouse and the positions of its items could allow for a mobile robot to move the items around, thus effectively dissolving the problem as the workers were no longer required to lift the items. This, however, may introduce a new range of problems related to ELS compliance. So, to summarise: A problem addressable by an ARS may employ an overall approach of either resolving, solving, or dissolving the problem, which may lead to entirely different instantiations of ARSs. We can make a somewhat general characteristic of the nature of these ARS instantiations and relate them directly to the RTE-components: ARS Resolver approach: An ARS that resolves the given problem in the most intuitive way, often by mimicking the tools and processes by which humans alone would resolve it. These ARSs can therefore often be applied directly in the existing environment without the need for much customisation. ARS Solver approach: An ARS that solves the given problem considering both alterations to the processes and to the environment. This may require careful analysis
104
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN and possibly simulations to assess which approach is the optimal one, and may result in a robot performing a different task than first expected.
ARS Dissolver approach: An ARS that dissolves the given problem by altering the perspective of the original problem and perhaps end up redefining it to a simpler one. This may typically be done through (extensive) adaptation of the processes and the environment, and the robots will of course reflect that. Which overall approach to choose in a given situation depends on the context of the problem, the amount of funds available (dissolving a problem may, for instance, require several costly environmental changes), the time frame, dependability issues and ELS compliance, and so on. A guiding factor may be found in a closing remark by Ackoff [1981, p173] where he states: Improvements obtained by resolving problems tend to have shorter lives than those obtained by solving them. Solutions, however, tend to have shorter lives than dissolutions. Nevertheless, few if any problems are ever permanently resolved, solved, or dissolved. Every treatment of a problem generates new problems.
4.3
ARS Design Considerations
To design an ARS is to realise a system that through the use of robots solves, resolves, or dissolves some problem in some adapted environment by carrying out tasks. The result is therefore a system; a unity; a whole, which comprises numerous components that interact to obtain the desired functionality. Through the design process these components therefore have to be chosen, perhaps constructed, and then assembled in the right way in order to fulfill the overall goals of the system. As an aid to this process I will in this section address some of the considerations and decisions that the ARS designer will have to make as seen from the system-level perspective and from the RTE-perspective. It is, however, problematic to address the design of an ARS from the three RTE-components separately as they are but a system abstraction facilitating an easier way of regarding an ARS. Nevertheless, it is possible to explain design considerations relating to each component separately if we constantly keep in mind their interactions with the other components and the impact they will have on the overall system.
4.3. ARS DESIGN CONSIDERATIONS
105
This section first presents some overall system-level considerations and then systemlevel considerations with respect to each of the three RTE-components in turn. This latter part also addresses intra-RTE considerations and RTE considerations stemming directly from the Problem. After each presentation I will make a short summary of some of the considerations which at the end of this section are collected in a Design Considerations Reference Sheet which provides an overview of the issues discussed. This sheet can be found as Figure E.1 on page 304 and will be fully explained and applied directly as part of the ARS system-level concept generation framework presented in Section 4.5.
4.3.1
Overall system-level considerations
Several system-level design considerations relating to the overall setting of the ARS can be (and should be) made and evaluated once the identification and specification of a Problem have been made, and hereafter be continuously iterated and updated as new issues arise that affect previous evaluations. Below I have compiled a list of relevant considerations formulated as brief guideline questions that can be seen as a mini-summary of some of the issues I have previously covered: Dependability and ELS compliance, socio-technical issues, complexity, and the ARS type. In a full design context project management considerations will naturally be part of the overall system-level considerations, but as this is out of scope with the thesis I have chosen not to address any such issues: none mentioned, none forgotten. Note that the red letter followed by a number, in this and in the following lists and text, refer to entries in the Design Considerations Reference Sheet on page 304. (I4) Dependability and ELS compliance: What issues are relevant and should be considered? Which are not and should not? (I5) Socio-technical: What are the organisational, political, and legal policies of the environment? What people are present in the system during operation? What is the social context? Who are the users? – are they involved in the design process? How should operators be trained? (I6) Complexity: Can the Problem be simplified6 and still be within the scope of the requirements? 6
In accordance with the K-I-S-S principle (Keep It Simple Stupid).
106
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
(I7) ARS approach: What ARS approach are we aiming for: an ARS Resolver, an ARS Solver, or an ARS Dissolver? A thing to bear in mind is that though some of the questions seem straightforward and easy to answer, and others seem complex and hard to answer, the answers provided may severely affect the overall system design. In particular with respect to addressing I5, I recommend the direct involvement of sociologists or other like-minded people that can elaborate the questions and provide answers. In Section 4.5.2 I will provide a suggestion of how to handle I4 by utilising a Decision Support System.
4.3.2
Task* -component
In Section 3.1.1 it was explained that the Task* -component represents one or more designated jobs, functions, or processes that the Robots- and Environment* -components facilitate. This indicates that a tight coupling between these three components exists, and it is thus not possible to make final design decisions about any without careful consideration of how they couple. The starting point of this process is of course the Task -component – as it specifies the function that the ARS has to perform in order to reach its goals – and the system-level considerations presented in the previous section. What we are looking for is therefore some mapping between the Task -component and the (potential) task-performing elements in the system dictating who-does-what-and-when. Potential task-performing elements are typically robots, other machines, and people, but other elements of the final Environment* -component may also be catalysts in performing a job-function. Perhaps a system is made such that wind-, water-, or solar power is utilised to power certain system components. In these cases the wind, the water or the sun actually performs a task necessary for the connected components to function. Naturally it can not be controlled directly, but as wind-mills and water-mills have brakes and solar panels can be covered, the energy flow can, in fact, be controlled to a certain degree. When it comes to people, we all have some intuitive idea of what we are capable of when it comes to performing a function. Rules and regulations may dictate that we must not perform certain tasks for safety or health reasons, or that a certain function may only be performed a certain number of times, but in general we have a pretty good idea of our capabilities. Robots on the other hand may perform some of the same tasks as humans, but
4.3. ARS DESIGN CONSIDERATIONS
107
also tasks entirely different from humans, for instance operation in hazardous environments like nuclear reactors, or they may work for 24 hours continuously. What a robot is capable of depends, of course, entirely on the type of robot and how it is constructed, which makes it one of the task-performing elements that we can mold as we please – to a certain extent – where humans can only be directed. From analyses of the Problem-specification it is therefore important to determine what could be done by humans and what should not be done by humans (I1). The latter gives an indication of what the non-human taskperforming elements (at least) will have to handle, which may provide insights into what robots are needed, and what alterations to the environment are required. In the TransPot project it was quite clear from the beginning that we were going to make a mobile robot to transport potted plants, but it was, among many things, not clear how the pots should get on the robot: should the robot somehow collect them? Should they be placed on the robot by people or by some other mechanical device? To answer this question we had to consider carefully both different robot tool designs (see Figure 4.10) and also possible alterations to the Environment in terms of people and additional devices. As we were rationalising a production process it did not seem feasible to make people place the pots on the robot if it could somehow be done automatically. We therefore eventually settled on a large tool carrier able to carry about 250 pots where the pots could be loaded onto it by means of a new custom-built conveyor belt. However the choice was not easy to make.
(a) TransPot with conveyor belts
(b) TransPot with fork
Figure 4.10: Two TransPots with different tool designs.
Another example, was the production facility’s speed of producing pots. The Requirements stated (see Figure 4.9) that the system should be able to transport 5000 pots per hour and that is should operate for 8 hours straight to follow the work cycle of the human
108
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
workers. However, we considered the possibility of a smaller (and lighter) robot with an extended operational cycle beyond the 8 hours facilitated by adding a pot-buffer-station on the ground near the production facility where during the day we could temporarily offload the pots. When the humans went home from work we could then change the robot’s task to spend the evening transporting pots from the buffer-station into the container field. This idea was, however, discarded as the gardeners wanted the robot to work during normal human work hours. These considerations are not uncommon in production systems where processes have to be rationalised by the introduction of machines or robots. However, in Denmark at least, the introduction of robots in industry is rarely done at the expense of human workers, as we do not have many large companies where a production system can be entirely substituted by robots – as is for example the case with the car manufacturing industry in other countries. Instead robots are often used to aid the workers by performing tasks that the workers are not allowed to perform as they may present a health risk, for instance, welding in small confined spaces, painting with toxic paint, repetitive movements, heavy lifts, and so on. The same issues were present in the horticultural industry: it was impossible for gardeners to get a proper work force as the jobs involved heavy an repetitive work. However, no products on the market were available to help this situation, which created the market for the TransPot. In other businesses, like for instance in health-care services, a robot helping a handicapped person eat, like “My Spoon” in Figure 3.6(c), does in fact help perform a task that another human otherwise would have to do, but enables the handicapped to do it herself. In the consumer market, robots like the Roomba in Figure 3.6(d) also carry out a human task, but one that people often do not like. The essence of the above is that robots indeed perform tasks that humans are perfectly capable of doing, which means that often it is a feasible path to push as much of a Task as possible onto the Robots and other non-human task-performing elements, and relieve the humans as much as possible – again, naturally depending on the situation. One thing to watch carefully, however, is how the complexity of both the robots and the environment are affected by this choice. If a simple task can be conducted by a human without much effort but a robot needs additional tools and development time to perform the same task,
4.3. ARS DESIGN CONSIDERATIONS
109
the likely increase in its complexity and price may not be worth it seen from a system perspective. 4.3.2.1
Summary
As for the system-level considerations I also propose a short list of Task* -component considerations in the form of simple questions that may help the ARS designer focus on the right areas. Note that I have added direct references to dependability and ELS compliance, and socio-technical issues; though not discussed directly in the text they are inferred from the system-level context and need addressing in the design process. (T1) Dependability and ELS compliance: What tasks may directly influence dependability and ELS compliance issues? How should they be handled? (T2) Socio-technical: How should people be involved in task solving? What about bystanders? – are they affected by the task carried out by the system? (T3) Complexity: Can the system complexity be reduced by altering the tasks? (T4) Environment* : How can the environment contribute to the decomposition of tasks? What elements actually need tasks? (T5) Robots: What types of tasks can the robots carry out?
4.3.3
Environment* -component
As presented in Section 3.1.2 the Environment* -component represents the potentially altered environment in which the system carries out its Task* -component, where the alterations represent changes made to facilitate the ARS solution by making it, for instance, cheaper, simpler, faster, or perhaps more dependable. This, of course, requires a careful preliminary analysis of the Environment-component with respect to all relevant parameters (I2). Establishing exactly what these parameters are may not be an easy task, but needs to be conducted to get an overview of what components may later on be characterised as potential Disablers, Enablers, and Commuters, and which components can be disregarded as not being part of the final system. Before this has been done it is difficult to assess exactly how to adapt – or rather design – the environment to facilitate the system, or if it should
110
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
indeed be adapted. In terms of the Robot-component perhaps it is the robots that should be made to fit in the existing environment. To draw a parallel think of the design of a car [Hallam and Dalgaard 2010]: had the infrastructure and traffic rules not already existed – or had they been different – perhaps a car would be designed entirely differently. This is, for instance, the case with the Rapid Urban Flexible (RUF), a concept for a dual-mode transport system where vehicles are able to drive both on the roads but also on a monorail system [Jensen 1996]. Here both the infrastructure, the vehicle and how we transport ourselves are parts of the concept and the components thus have to be designed accordingly. In the ARS context the considerations of environment alterations are strongly coupled to the type of ARS design path is pursued (I7) as explained in Section 4.2.2. An ARS Resolver approach will typically only require minor changes to the environment and instead have the rest of the system adapt to the existing environment, where both an ARS Solver path or an ARS Dissolver path may require direct alterations to the environment. Consider here again the TransPot, where we had to create the necessary infrastructure to support, among other things, the mobile robot’s navigation system. After considering many different types of navigation technology we ended up choosing a cheap and simple solution: line following and localisation by means of RFID tags. We installed 3cm-wide white plastic lines (Enablers) in all pathways of the container field, painted white lines in the beds and attached RFID tags in front of every bed. Together with an inexpensive FireWire camera, a simple vision algorithm and a RFID tag-reader we now had an extremely robust navigation system. It was not pretty as the container field was cluttered with white plastic lines but it nevertheless proved a viable solution as 1) it was incredibly robust, 2) it was technologically simple, 3) it was weather- and tractor-proof, 4) it was flexible and easy to install, 5) it was visually clear where the robot would be operating (mental-safety), and not the least: it was cheap. Navigation could of course have been resolved without altering the environment in such a drastic way if we had used, for instance, a GPS system. However, for a number of reasons (price being one of them) a GPS-based solution was not feasible so we had to be pragmatic and make a choice. By choosing the environment solution we did, we actually implicitly addressed several dependability issues in one go: reliability, availability, maintainability, repairability, precision, accuracy, and mental-safety. Also the solution could be regarded as an indirect reduction of system complexity as other navigational solutions, for instance GPS, would
4.3. ARS DESIGN CONSIDERATIONS
111
have required a significantly higher amount of navigational programming and a more complex Task* -specification, and would not have provided the same dependability coverage which would then have to be addressed in other ways. Of course the introduction of lines and RFID tags slightly raised the environment-complexity, but the correlated reduction in robot-complexity and task-complexity was in this case much higher, which led to an overall reduction in system complexity. Reducing system complexity by utilising the existing environment components properly or by alteration of the environment in some appropriate way, is one of the most overlooked solutions in robotics. I have often seen robots equipped with a complex concert of sensor systems (for testing some complex algorithm, no Figure robotic
4.11: floor
International
duster AS.
The
RoboMop
doubt), solving problems where a slight alteration to ei-
by
RoboMop
ther the robot or the environment would have made the
Picture
http://www.robomop.net/
from
solution much simpler. Consider the RoboMop robotic floor duster shown in Figure 4.11 invented by Torbjørn
Aasen from Norway. It comprises a simple actuated ball that by the means of some internal mechanical construction rolls in one direction until it bumps into something and then naturally changes direction. It is then placed in a plastic frame under which an electro-static dust pad is placed, and a simple cleaning robot is made that dusts the room in random patterns. On the box in which it is shipped it reads: “Smart Navigation Technology: Senses walls and objects, automatically changing direction”. I believe this to be good Norwegian humour, and in direct reference to the (about ten times) more expensive cleaning robots like, for instance, the Roomba, which employs a somewhat more advanced navigation technology that in effect offers little more than the RoboMop’s. The Roomba’s random motion patterns are based on bump sensors and an optical distance measurement system, and the RoboMop utilises simple mechanics. Naturally, the Roomba and the RoboMop are two entirely different products, where the Roomba is much more versatile and able to collect more than just dust particles, but in fact the RoboMop works quite well for what it is designed for: dusting – and at a tenth of the price. So if the Problem to be addressed is dusting flat homogenous floors in houses, I believe the RoboMop to offer the lowest system complexity – and it works excellently on dust bunnies under the bed.
112
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
In designing the environment we generally want to facilitate the Task* -component by increasing the number of Enablers, and decreasing the number of Disablers and Commuters. Each added Disabler and Commuter – or transformed Enabler – potentially introduces new situations that will have to be considered thoroughly before any final decision is made. The introduction of lines and RFID tags in the TransPot example was a potential hazard for tractors and people, as the former could have torn them from the ground and the latter could trip and fall – this would, in effect, have compromised system dependability and have turned the lines into hidden Commuters. Luckily this was not the case as we managed to attach them firmly to the ground and they turned out to pose no problem at all. However, if the system had actually been operating for years, the soft ground material under the lines could potentially be washed partially away creating tripping situations. Perhaps not the most dangerous of hazards, but nevertheless a factor to consider. The moral is, here, that any alteration made to the environment considered to be an Enabler should initially be considered as a Disabler and then “proven” to be otherwise. If it turns out to be a Commuter – even a slow-changing one – countermeasures have to be taken, for instance, by engaging people in the environment to ensure maintenance such that tripping situations are prevented. If it turns out to be a Disabler, it probably was not such a good alteration in the first place. If the Environment-component is partially unknown when the ARS is designed – for instance the Martian surface or in previously unexplored caves – it may be difficult to assess the level of Enablers, Disablers, and Commuters, let alone to introduce environment alterations and to anticipate their effect. This presents a serious challenge for both the Robot-component and Task* -component, as these will have to be designed and constructed to accommodate this. Usually this will lead to a heightened level of complexity in these components, but this can be reduced again, by considering a lesser degree of autonomy in the robots, for instance by making them partially remote controlled.
4.3.3.1
Summary
As with the system-level and Task* considerations I also propose a short list of Environment* -component considerations in the form of simple questions that may help the ARS designer focus on the right areas. Note that I have again added direct references to
4.3. ARS DESIGN CONSIDERATIONS
113
dependability and ELS compliance, and socio-technical issues. (E1) Dependability and ELS compliance: With respect to the system dependability and ELS compliance criteria, which can be strengthened by making alterations to the environment? (E2) Socio-technical: Which people are present/needed in the environment? How can the operation of humans and animals in the system be facilitated by alterations to the environment? (E3) Complexity: Can the system complexity be reduced by making alterations to the environment? (E4) Task* : How can the tasks be facilitated by making alterations to the environment? (E5) Robots: How can the robots be facilitated by making alterations to the environment?
4.3.4
Robots-component
Designing the Robots-component is about establishing what types of robots are required in the ARS, how many are required, what their configuration should be, and how the robots should be acquired: perhaps existing robots can be applied directly, perhaps some exist but have to be adapted to suit the needs, or perhaps entirely new robots should be built from scratch. An ARS based on existing Robots These decisions may not be easy to make, but sometimes the answer may indeed be straightforward, for instance, when the ARS from the beginning is centred around an already existing robot. In these situations the design of the Robots-component is practically nonexistent, but may instead require an increased focus on the design of the Task* -component and the Environment* -component. In these situations the choice of robots often precede the definition of the Problem which is then specified to reflect the use of the chosen robot. For instance, in the case of applying Paro in an ARS context to help people with dementia (Problem), the majority of the system design process was focused on training personnel
114
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
(Environment* ) in how to use (Task* ) Paro together with people suffering from dementia (Environment* ). The Solution is here of a more dynamic character as experiences from practical use may reveal new issues that essentially change the Problem and thus reflect back on both the Task* -component and the Environment* -component. The robot, however, is not changed, but is perhaps just applied differently. An ARS based on new Robots In cases where the robots are not given beforehand, it is, again, important first to decide whether an ARS Solver, an ARS Resolver, or an ARS Dissolver design approach is the road to follow (I7). Based on this decision and based on Environment analyses (I2), it may be possible to select a suitable platform type. If, for instance, the Problem-specification and the environment calls for mobile robots, different means of locomotion have to be examined while considering both issues of static and dynamic stability, maneuverability, and the characteristics of ground contact points, in order to determine what type of platform actually is required (see [Siegwart and Nourbakhsh 2004, Chap.2] for a good review on locomotion techniques in mobile robots). Aspects of kinematics, controllability, and navigation – according to Siegwart and Nourbakhsh comprising perception, localisation, cognition, and motion control – of the platforms will also have to be assessed with respect to both the Task* -component and the Environment* -component, before a final decision can be made. And even then, everything may be subject to change. In the TransPot robot we initially chose differential drive control which implied a specific mechanical design with two actuated wheels and two unactuated castor wheels. However, we quickly discovered that the unactuated castor wheels, which turn 180◦ when the driving direction is reversed, would tear the ground plastic on which the pots were placed, effectively destroying the container field. Furthermore, we were using pneumatic tyres which meant that the wheels never had exactly the same diameter, making it almost impossible to obtain straight-line driving when using dead-reckoning, as we only used encoder feedback to determine their individual velocities. We therefore decided to construct a new mechanical platform based on Ackermann steering instead, which solved a lot of these problems. The point is, that the inherent complexity of an ARS makes it hard to foresee the consequences of all design choices, even the choices made quite early in the process such as the type of robots and their configuration – but we have to try. This illustrates the importance of using experimental setups to test partial solutions as the design process progresses. Without these
4.3. ARS DESIGN CONSIDERATIONS
115
tests to uncover problems in time and test the validity of potential solutions, it takes a lot of luck – or at least a lot of experience – to make a fully functioning ARS. Components When robots of a feasible type and configuration have been chosen it is time to see if existing products match the requirements or can be adjusted to match them. In making robots for an ARS, unfortunately neither case is likely. Yes, often generic experimental platforms are used over and over again in research for various types of projects, but once real-world requirements enter the scene even an existing platform that seems to be perfect may only comply 99%. The last percent may, for instance, be a requirement of 8 hour operational time and not 4 hours as the platform originally supports. As with the TransPot, such an obstacle is not easily resolved. If we double the battery capacity, we may double the weight and the size of it, making it impossible to integrate in the existing platform. And even if we could integrate it, the increased weight may affect the locomotion velocity and ultimately violate other performance requirements. It is therefore likely that the robots in an ARS have to be built “almost” from scratch. “Almost” in the sense that robots, like may other products, usually comprise some amount of commercially available components that can be integrated to form larger components, which again are integrated to form the actual robot. Designing a Robot-component can therefore often be regarded as the process of choosing the right components at the right time and assembling them in the right way. ...the right components Choosing the right components is a key aspect of making a robot, where “right” refers not only to obtaining a required robot-functionality but just as much to how the choice affects both the Task* -component and the Environment* -component. To make a rational component choice we, in theory, need to have sufficient knowledge of all possible components and the possible impacts of choosing one particular component over another – needless to say that we are not fully at that point yet, but efforts are made. EU projects like “Robot Standards and Reference architecture” (RoSta)7 , “Best Practice in Robotics” (BRICS)8 , and “Resilient Reasoning Robotic Co-operating Systems” (R3-COP) all address different aspects of robotics by investigating standards, reference architectures, frameworks, com7 8
RoSta was a Coordination Action funded under the European Union’s Sixth Framework Programme. BRICS is a Collaborative Project funded under the European Union’s Seventh Framework Programme.
116
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
ponent knowledge-bases, and component reusability, in order to facilitate more rational choices when designing robots. Hallam and Bruyninckx [2006] also argue the need for an ontology of robots as objects to facilitate, among other things, the choice of components, but acknowledge that such an ontology does not yet exist. Though some component ontologies have actually been developed – at least partially – in certain areas of robotics, they offer only a small piece of the big puzzle. Examples can, for instance, be found in ontologies for urban search and rescue robots [Schlenoff and Messina 2005], and for indoor office environments [Chella et al. 2002]. Therefore, to make component choices we often rely on our own past experiences, which often leads to a reuse of the camera, the computer platform, or the algorithms we used in past projects – because we know they work. This practice has the benefit of being charted space and it is therefore easy to make something work9 , but has also the downside that the choice may not be that rational – after all it was not really chosen, it was there – and may therefore prove not to be a good solution. In Section 4.4 I will address choice from the perspective of Decision Support Systems which may provide a feasible path for rational choice in ARS design. ...at the right time and assembling them in the right way As illustrated with the battery in the TransPot example, the time-of-choice of battery had a major impact on the overall system. Had we, instead of continuing through the project with the initial battery setup, actually made serious consideration of the impact that a later change would impose and actually chosen the right configuration earlier on, at least that problem would have been eliminated. But why did we not see this coming? If we compare this situation to the imaginary mobile robot example shown in Figure 2.10 on page 48 we can see that the Supply in this case is the interaction source of five other component-groups and the sink of two. It is therefore not even close to being the highestcoupled component in the system, which we might have considered to be an explanation, as it would then have a high system dependency. In Section 2.3.2 I wrote that a lowcoupling may result in a low system dependency, which silently implied that this is not always the case. The problem is that the system model presented in Figure 2.10, shows the system components and interactions as we perceive them in the operational system. This, of course, gives a good indication of which components to pay special attention to when 9
In a R&D project context, never underestimate the power of showing a demo of something that works.
4.3. ARS DESIGN CONSIDERATIONS
117
designing an ARS, as high system dependency often indicates a design critical component – a component whose design may have system wide impact. However, the model does not convey information on when components should be chosen. As the time-of-choice of the battery is crucial with respect to system requirements and the choice/construction of other components, for instance the chassis, it is in fact a design critical component and thus has a high system dependency in spite of its relatively low system coupling. We therefore need to be able to establish some ordering of components reflecting when certain components should be chosen such that these situations can be avoided. It is out of scope of this dissertation to treat these aspects further but perhaps the field of Configuration Design (see for example [Wielinga and Schreiber 1997; Brown 1998; Soininen et al. 1998]), or Assembly Planning (see for example [Swaminathan and Barber 1996]) may provide interesting insights. Also the Design Structure Matrix has proven valuable in ordering tasks in complex design problems (see for example [Eppinger et al. 1992; Huang and Kusiak 1998; Browning 2001; Yassine 2004]) and may aid in finding a future solution, as may the “Ontology-Based ELectronic Integration of CompleX Products and Value Chains” (OBELIX)10 which offers a more ontological approach (see for example [Pe˜ na et al. 2003]). Other factors Seen from the point of view of journalists, retailers, bystanders, and sometimes even project stakeholders like end-users, the “robots” will often be regarded as “the whole system” – or “the product” – without much regard to the changes made to the environment or the meticulously crafted tasks that the ARS as a whole, performs – seen from a robot-centric view point, that is. This is, in fact, not a problem (as long as the design of the robots is conducted using an ARS systems-view) but may result in design requirements specifically targeted at the robots and not the system as a whole. These requirements may have to be filtered and treated accordingly, as a naive wish for an fully autonomous four-wheeldrive mobile robot may not be the best choice in all solutions. With this in mind, if we for a moment regard the design of the Robots-component from a Product Development perspective, the design function can be defined as: The design function plays the lead role in defining the physical form of the product to best meet customer needs. In this context, the design function includes 10
OBELIX was an IST Project funded under the European Union’s Fifth Framework Programme.
118
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN engineering design (mechanical, electrical, software, etc.) and industrial design (aesthetics, ergonomics, user interfaces). [Ulrich and Eppinger 2008, p3]
First, an obvious emphasis is made here that it is what the customer needs not what she wants that counts. In most other design disciplines (for instance in Software Engineering and Systems Engineering) this is a well-known distinction, but as many modern-day robotics projects are made in academia, we are brought up thinking in terms of what we (i.e. the Professor) want, not as much in terms of needs. When designing an ARS this type of thinking may inhibit our judgement, and may cause us to make design decisions not founded in rational (system) reasoning, effectively reverting us back to a more robotcentric view-point. In the TransPot project we had discussed the possibility of using a fleet of smaller – and thus lighter – mobile robots, but as the gardeners saw “big robot = high capacity” we ended up going that way. Second, the definition addresses engineering design which essentially is what roboticists know how to do, but then also industrial design addressing issues of aesthetics, ergonomics, and user interfaces. These issues are often imperative in an ARS but in particular when direct pHRI has to be considered. In Figure 4.12 two robots are shown where Industrial Design principles have been applied in their development process. The RoBlood project shown in Figure 4.12(a) has as a close collaborating partner the Kolding School of Design, Denmark, who was in charge of the physical design of the robot [Wetton and Students 2007], and the Care-O-bot project in Figure 4.12(b) has made many thorough considerations regarding the appearance and user-interfaces of the robot [Parlitz et al. 2008; Reiser et al. 2009]. Without including Industrial Design principles in the design process of robots we may not be able to handle fully dependability issues such as mental-safety or compliance issues of ethical and societal character, let alone areas of aesthetics and ergonomics, which we as roboticists may simple “forget” as they are not part of our usual mind-set.
4.3. ARS DESIGN CONSIDERATIONS
(a)
The
blood
RoBlood
(b) The Care-O-bot 3 service robot by the Fraun-
sampling
hofer Institute for Manufacturing Engineering
robot
shown
by
PhD-student
Thiusius
here
119
and Automation (IPA) in Stuttgart, Department Robot Systems.
Rajeeth
Savarimuthu, MMMI, SDU. Figure 4.12: Examples of robots where Industrial Design is a very important factor.
4.3.4.1
Summary
As with the previous components I have again compiled a list of relevant considerations to make when designing the Robots-components, in the form of simple questions that may help the ARS designer focus on the right areas. Note that I have again added direct references to dependability and ELS compliance, and socio-technical issues. (R1) Dependability and ELS compliance: With respect to the system dependability and ELS compliance criteria which should be directly reflected in the robots? How do we address them? (R2) Socio-technical: How can the operation of humans and animals in the system be facilitated by the robots? How can the operation of the robots be facilitated by humans and animals in the system? (R3) Complexity: Can the system complexity be reduced by making a different choice and configuration of robots?
120
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
(R4) Task* : How should the robots be chosen and made to facilitate the task? What level of autonomy is required? (R5) Environment* : How does the environment support the chosen robots? What changes should we make to the robots in order to integrate them better in the environment?
4.3.5
Design Considerations Reference Sheet
The Design Considerations Reference Sheet shown in Figure E.1 on page 304 contains, as explained earlier, a summary of the considerations presented and discussed in the past subsections, and is only meant as an overview of the issues and not as a substitute for the presented discussions. However, it does provide a more structured view of couplings between the considerations which, hopefully, will help the ARS designer in her quest. The sheet will be applied directly in Section 4.5 as part of the ARS system-level concept generation framework. To illustrate the coupling between the different considerations, the sheet is presented in a matrix form where the rows indicate the source of the questions and the columns what the questions address. Vertically it is divided into three zones: Initial Analyses, the RTE-components, and System-level Assessment. Initial Analyses (I1–I7) comprise analyses of the Problem and of the overall system-level aspects. The results of the Problem analysis provide input directly to the RTE-components as explained in the last sections (illustrated here by arrows) and the results of the analysis of the system-level aspects are treated separately but indirectly provide input to the RTEcomponents. The considerations for each RTE-component (RTE1–RTE5) stem from the Problem analysis, from the individually elaborated system-level aspects, and from the other two RTE-components. These last interactions indicate the intrinsic coupling of the three RTEcomponents. The considerations for the RTE-components can also be visualised as in Figure 4.13. The System-level Assessment (A1–A5) is a general assessment of a given Solution or concept as will be explained further in Section 4.5.6.
4.4. DECISION MAKING IN ARS DESIGN
121
S D
C
R2
R1
R3
R
T5
R5 R4
T1 D
E5
T4
E*
T*
E1 D
E4 T2 S
E2 T3 C
E3
S
C
Figure 4.13: How the RTE1–RTE5 considerations relate to the RTE-representation. “Dependability and ELS” is shown using (D), socio-technical issues as (S), and complexity issues as (C).
4.4 4.4.1
Decision Making in ARS Design An overview
Designing an ARS involves making a lot of decisions: Which ARS approach should be chosen? What dependability and ELS compliance issues are the most relevant? What type of computer should be used? What navigation algorithm should be applied? What type of locomotion system do we need? – and so on. We often base our choices on either experience or on a mapping between a set of possibilities and the possible consequences of picking a specific possibility, that is, a weighing of the pros and cons. This latter process is particularly difficult when many parameters are in play. As exemplified in the previous sections a choice of a particular type of battery may, for instance, depend on parameters such as the total size and weight of the robot, the production requirements, the maximum velocity of the platform, the price, etc., which in effect, turns the choice of battery into a multi criteria decision problem. Addressing multi criteria decision problems is part of the
122
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
field of Decision Theory which in literature, according to Hazelrigg [1998], can be traced back at least 250 years and has spawned a multitude of new theories, methods, and tools like Multi Criteria Decision Analysis (e.g. [Belton and Stewart 2002]), Multi-Attribute Utility Theory (MAUT) (e.g. [Keeney and Raiffa 1976; Dyer 2005]), the Analytic Hierarchy Process (AHP) (e.g. [Saaty 1980; Saaty and Vargas 2001; Saaty 2008]), and so forth, where I have found references to the latter being applied directly in robotics to help selecting the most appropriate industrial manipulator for a particular application (e.g. [Goh 1997; Kapoor and Tak 2005]).
As part of DTI’s contribution to the R3-COP project I am conducting a survey of Decision Making and Decision Support Systems to establish their applicability in a framework for autonomous systems design. In that process I have focused on the application of decision theory to design problems and found an early example where MAUT was applied to construct a “methodology by which engineering design managers may consider technical aspects of a design concurrently with economic aspects of the manufacturing system in selecting among alternatives and directing the design effort.” [Thurston 1990]. This, and other efforts (e.g. [Mistree et al. 1990]), resulted in the late 1990s in the forming of a new community with an emerging perspective on design theory called Decision-Based Design (DBD) [Chen et al. 2006]. In his seminal paper Hazelrigg [1998] provides a framework for DBD in engineering (which is later expanded slightly by Wassenaar and Chen [2003]) and states: “In reductio ad absurdum, engineering design involves only two steps: (1) determine all possible design options and (2) choose the best one.” after which he comments that this is not as easy as it sounds as both steps are extremely difficult or impossible to perform for all but the most simple products. Hazelrigg gives four reasons for this: 1) the range of possible design options is virtually limitless, 2) it is not possible to know exactly how a particular design will perform until it is built and design is thus always a matter of decision making under conditions of uncertainty and risk, 3) in order to compare and rank order design options it is necessary to have a valid measure of value, which is not trivial to identify especially not one that is also valid under conditions of uncertainty and risk, and 4) the dimensionality of a typical design is so large that even given full knowledge of all options it may be computationally infeasible to search all possible options for the best one. In conclusion he states that “design can never be reduced to a prescriptive procedure exclusive of human input” and that “decision making cannot be done in the
4.4. DECISION MAKING IN ARS DESIGN
123
absence of human values”. This he sees in contrast to engineering design viewed as a problem solving discipline in the mathematical sense, where parameters can be obtained, calculations made, and a definite result produced. He states that we should move away from such approaches and focus on the value a particular design choice offers rather than on what physical performance measure is optimised. That is, “design is a decision that seeks to maximise value, where value is always expressed as a real scalar”. This value is “a measure of the win-lose outcome of a design, namely, How much money will I make if I choose this design? Sometimes additional outcome attributes must be included: safety, environmental concerns, company image, for example.” In these cases the value is a multi attribute function but still represented by a real scalar. The existence of this scalar can be illustrated in the following way: If a decision maker is asked to rank three design options according to preference, say A, B, and C, the result may be A B C where ‘ ’ denotes “is preferred to”. This ordering implies [Hazelrigg 1998] the existence of the real scalar u
such that uA > uB > uC – economists call such a scalar utility. Note that if the situation A B C A should arise it would require uA > uB > uC > uA which is not possible
as u is a real scalar. This dilemma is said to be intransitive and “a person who has such a preference order is called irrational” and “would not make a good design engineer” [Hazelrigg 1998]. Hazelrigg’s thoughts are largely shared by the DBD community (see, for instance, [Lewis et al. 2006a]) and provides a more system oriented view on design as it is value-driven rather than performance-driven. With respect to ARS design this may pose a problem as many design choices are made in a performance-driven context, but as a supplement I believe these approaches can provide important input – especially concerning the system-level issues (which I will address in Section 4.5.2). To get an overview of the principles behind a decision-making process let us look at its three key elements [Lewis et al. 2006b]: • identification of options or choices • development of expectations on the outcomes of each choice • formulation of a system of values for rating the outcomes to provide an effective ranking and thereby obtaining the preferred choice
124
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
Correspondingly, engineering design-making can be viewed as a process of modelling a decision scenario resulting in a mapping from the design option space to the performance attribute space. Subsequently, a utility function is constructed that reflects the designer’s preference while considering trade-offs among system attributes and the risk attitude toward uncertainty [Lewis et al. 2006b]. The resulting decision rule is therefore: “the preferred decision is the option whose expectation has the highest value” [Hazelrigg 1998].
4.4.2
PAPRIKA
As an example of using decision making in an ARS design I have chosen to use the Potentially All Pairwise RanKings of all possible Alternatives (PAPRIKA) approach [Hansen and Ombler 2008]. Here the decision-maker (or user, customer, designer, etc.) has to identify a set of criteria for the problem at hand each having a set of categories in some ordinal scale, that is, from low value to high value. These criteria form the value-model for a set of alternatives which each have to be ranked according to the criteria each with one value from the categories. To exemplify: If we have criteria A, B, and C each with the categories (0, 1, 2), where 0 is the lowest value and 2 the highest, one alternative, say α, may be assessed to have A = 0, B = 2, and C = 1 – which we can write as (0, 2, 1) – and alternative β may be assessed as having (1, 2, 1). The aim is now to rank the criteria by assigning a value/point to each of the categories thereby constructing a value-model (or point-system) where the overall utility for a particular alternative is calculated as the sum of the values of its categories. The alternatives can now be ranked and the preferred solution is the alternative with the highest utility. The decision-maker (or user, customer, designer, etc.) performs the ranking by conducting a pairwise ranking of potentially all undominated pairs of all possible alternatives. An “undominated pair” is a pair of alternatives where one is characterised by a higher ranked category for at least one criterion and a lower ranked category for at least one other criterion than the other alternative [Hansen and Ombler 2008]. Conversely, the alternatives in a “dominated pair” are inherently pairwise ranked due to one having a higher category for at least one criterion and none lower for the other criteria. As an example consider the undominated pair from the example above: (0, 1, 2) and (0, 2, 1). Here αA ∼ βA , βB αB ,
and αC βC , where ‘∼’ means “is equally preferred to” Thurston [2006]. An example of
4.4. DECISION MAKING IN ARS DESIGN
125
a dominated pair could be (0, 1, 2) and (0, 0, 2), where αA ∼ βA , αB βB , and αC ∼ βC .
The decision-maker now begins by pairwise ranking undominated pairs (by indicating
‘ ’, ‘∼’, or ‘≺’) defined on just two criteria at a time, were all the other criteria’s categories are pairwise identical. This is followed, if the decision-maker chooses to continue, by pairs with successively more criteria, until potentially all undominated pairs are ranked. The big contribution of PAPRIKA is that the set of undominated pairs – which is potentially very large – is “minimised by identifying and eliminating all pairs implicitly ranked as corollaries of the explicitly ranked pairs through the transitivity property of additive value models”. [Hansen and Ombler 2008]. Furthermore, PAPRIKA automatically assigns points to the categories depending on the rankings made by the decision-maker whereas, for instance, the Analytic Hierarchy Process (e.g. [Saaty 1980]), requires the decision-maker to do this manually by using a number between 1 and 9. So PAPRIKA works by forcing the decision-maker to consider a set of undominated pairs and for each of them make the assessment: “which one do I prefer?”. The strength of this approach is, in my opinion, that the decision-maker, through this process, becomes very much aware of what she actually prefers without having to consider all criteria at the same time. In fact, the process itself takes quite a lot of mental effort but once it has been completed the solution that PAPRIKA offers is not actually a big surprise – it actually makes sense and feels rational. This is also one of the key goals of DBD: “its [utility analysis] goal is not to predict or mimic the choices of human decision-makers, but to help humans make better decisions.” [Thurston 2006], that is, it is not a miracle tool telling us what we did not know, but an instrument to help us become conscious of what we already know. In the past months I have tested an online implementation of PAPRIKA called “1000minds”11 made by Paul Hansen and Franz Ombler who authored [Hansen and Ombler 2008], where I have used it to: 1) reach consensus on which four prototypes should be discarded out of seven possible in a project where DTI participates, and 2) obtain an overview of what members of the Danish Municipalities Entrepreneur Forum thought were the most important factors when choosing a robotic lawn mower. 11
http://www.1000minds.com/ US patent 7552104, New Zealand 526447 / 527785, Australia
c 2002-11 1000Minds Ltd. All rights reserved. 2004248503, Canada pending. Copyright
126
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
In the former case we were a group of 8 people, who all together, formulated the criteria and categories we wanted to rank the prototypes by, conducted the pairwise rankings of undominated pairs, and assessed the individual prototypes. The process was very rewarding and actually helped the group obtain a greater understanding of where we were heading in the project. In the latter case I used a systems approach formulating both the criteria and the categories from home and left the pairwise rankings to the participants – the 1000minds software is capable of sending emails with personal URLs to individual ranking pages. Not to focus too much on the technical specifications of robots but more on what overall system properties were desired, I had formulated a set of criteria and categories like “A: How often does an operator need to be present?” with the categories “1: All the time”, “2: Sometimes”, and “3: Never”, and “B: How often should you need to manually cut the grass after the robot has already been there?” with the categories “1: Always”, “2: Once in a while”, “3: It happens”, and “4: Never”. Being presented, for instance, with the pair (A1,B4) and (A3,B1), the users were forced to choose between the lesser of two evils – this, I am sure, created a lot of new thoughts. The responses to the process and my follow-up presentation were quite positive.
4.4.3
Perspectives
As mentioned earlier I believe that decision-making tools can be a great asset to the ARS design process in both component selection processes or in the more “lucid” system-level assessments. Quite a few of the questions presented in the Figure E.1 on page 304 could, for instance, be formulated into PAPRIKA format (or any other decision-making method) and be used to make rational decisions on the direction of the process. For instance, I7, relating to what ARS approach should be applied, it may be possible to see the three types as “alternatives” and formulate per-project criteria by which they should be ranked. With respect to I4, Dependability and ELS issues, I will in Section 4.5.2 present how PAPRIKA may be used to rank the importance of the individual criteria, make a choice of which to focus on and which to discard, and then use the remaining value-model to assess how well each concept or Solution complies.
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
4.5
127
A case study: An ARS System-level Concept Generation Framework
In this section I will present a case study of an ARS system-level concept generation framework, which, with reference to Section 4.1, can be seen as part of the “Concept Development” phase in product development [Ulrich and Eppinger 2008] or as part of the “Concept Exploration/Definition” phases in systems engineering [Kossiakoff and Sweet 2003]. The word “part” is chosen intentionally to signal that this framework does not replace either of them but should be seen as possible addition as it explicitly addresses ARS system-level issues. The reason for addressing this particular task in the first place, is that concept generation – that is, the generation of possible Solution suggestions or alternatives – is a system-level design activity and therefore must contain thoughts and decisions relating to both dependability and ELS issues, socio-technical issues, and complexity issues – all core elements in this thesis. The ARS system-level concept generation framework – henceforth referred to as the framework – therefore serves primarily to illustrate how these systemlevel issues can be incorporated directly into the ARS design process and how they might be assessed, but also how the RTE-representation itself can be used directly to facilitate this process.
Problem Task
Initial Analyses
Environment
Concept Generation
Concept Assessment
Final Concept
Requirements System−level Aspects
Figure 4.14: The System-level Concept Generation Framework.
Figure 4.14 gives an overview of the framework which comprises four phases: a Problem is first analysed together with the overall system-level aspects in the Initial Analyses phase. These results form in the Concept Generation phase the basis for the generation of a set of concepts that conform to the RTE-representation. In the Concept Assessment phase
128
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
these concepts are then assessed and ranked, and the final concept selected. However, the assessment may reveal that the concepts do not obey the original requirements which may lead to the generation of a new set of concepts or to a revision of one or more Problem aspects. The latter may also occur directly after the Initial Analyses if the requirements have not been fully specified, and the concept generation process can thus be seen as a way of obtaining a more concise specification. In the following sections I will address each activity sequentially interleaved by the ServiceBot where appropriate.
4.5.1
ServiceBot: Background story and Problem specification
As presented in the introduction to this chapter I have constructed a design test scenario called ServiceBot that I will use as a running example through the rest of the thesis, that is, I will apply the addressed concepts, methods, and tools to the example to validate them. This section presents the imaginary background story behind ServiceBot. The University of Suburbia is looking for ways to rationalise parts of their on-campus service system to free up personnel resources for other tasks. Today five manned service vehicles of the types shown in Figure 4.15 are used by service personnel between 8 o’clock and 16 o’clock on weekdays to distribute mail, paper, light bulbs, water, boxes, blankets, plants, and other kinds of goods to various locations on campus. These vehicles are battery powered, have a 1 m2 platform, are able to carry a load of 150 kg besides the driver, and can travel at a top speed of 4 m/s.
(a) Without load.
(b) With load.
Figure 4.15: Two types of manned service vehicles currently used at the University of Suburbia.
A common distribution operation involves a set of sequential tasks: 1) unplugging the
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
129
vehicle from the battery charging station at the head service office – henceforth denoted as home, 2) driving to a pick-up location, 3) loading the vehicle with goods, 4) driving to the designated destination, 5) delivering/placing the goods, 6) returning home, and 7) reconnecting the vehicle to the battery charger. All campus classrooms and offices are potential pick-up and placing locations and are distributed along the indoor and outdoor campus hall- and pathways which in total extend more than 3 km. A layout of the campus can be seen in Figure 4.16.
Figure 4.16: The layout of the main campus of University of Suburbia. “ Gray” denotes hall- and pathways, “ orange” class rooms and offices, “ light orange” large lecture halls, “ white” outdoor areas, and “ yellow” outdoor pathways. The layout is based on parts of the Odense campus of University of Southern Denmark.
It is the belief of the university administration that it should be possible to somehow rationalise this distribution task by using some form of robot technology, and, of course, want a solution that is economically feasible. The Problem specification of the ServiceBot is loosely specified by the administration and service workers of the University of Suburbia in the following way: An ARS is desired that is capable of transporting goods from home to various locations on the campus grounds where it must deliver them. The ARS must
130
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN be available every day between 8 o’clock and 16 o’clock. In this period several people (mostly students) are present in the corridors where the ARS must operate and the system must therefore be safe and not do any damage to either people, furniture, plants, or other objects in the environment. Unlike to many universities, the University of Suburbia has a good economy.
This can be reformulated into the following Problem: Task : • Transport goods from home through corridors to various locations on the campus grounds
• Deliver the goods at various locations • Return home.
Environment: • The environment comprises home, corridors, various pick-up and place locations, people (mostly students), furniture, plants, other objects.
Requirements: • Must be available every day between 8 o’clock and 16 o’clock. • Safe
4.5.2
Initial Analyses
The purpose of the Initial Analyses phase is to provide a foundation for Concept Generation, that is, it must provide information that can aid the ARS designer in conceiving ARS concept ideas that are within the boundaries of the system as a whole. As explained in Section 4.3.5 the Initial Analyses therefore comprises analyses of the Problem and of the overall system-level aspects which correspond to (I1–I7) of Figure E.1 on page 304 – the Design Considerations Reference Sheet – which I believe forms a minimal set of necessary considerations. A complete set of considerations would also include aspects of economy, project management, risk management, etc., as these also contribute to establishing the system boundaries for concept generation. However, as pointed out before, the focus of this case study is to provide an overview of the process, and to illustrate how system-level aspects can be directly incorporated in the process.
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
131
As promised in the last section I will now directly address how I4, Dependability and ELS issues, can be incorporated into the design process using a decision-making method. To do so I have devised a three step methodology – a Dependability and ELS assessment methodology – where the first step, Step 1, is context independent and prepares the system by setting up the decision model: Step 1: 1. Establish a complete set of dependability and ELS compliance criteria (see Section 2.1.1). 2. Formulate each criterion to facilitate a monotonically increasing or decreasing valuefunction (categories) (see [Krishnamurty 2006] for a discussion on this matter). 3. Choose an appropriate number of categories for each criterion and formulate them to represent appropriate ranges of monotonically increasing or decreasing values (see [Thurston 2006, p18] for a discussion of this non-trivial task). The second step, Step 2, is context dependent and should be applied to the context of the particular ARS in question. In this step ranking is performed and the criteria set reduced. Step 2: 1. Conduct ranking process with respect to the context in question. 2. Interpret the result to assess which criteria are relevant and which are not. Keep the relevant ones and discard the irrelevant ones. If in doubt whether to keep or discard a criteria, keep it. In the third step, Step 3, generated concepts or solutions are ranked and evaluated. Step 3: 1. Rank generated ARS concepts or ARS Solutions according to the remaining criteria. 2. Evaluate the results with respect to the requirements. With respect to the framework, Step 1 and Step 2 naturally belong in the Initial Analyses phase, whereas Step 3 belongs in the Concept Assessment phase. I will now illustrate the use of Step 1 and in the next section, where I present the initial analyses of the ServiceBot, address Step 2.
132
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
To illustrated the use of the methodology I have chosen PAPRIKA as my tool and have for Step 1 devised a decision model based on the dependability and ELS issues presented in Section 2.1.1, and entered them into the 1000minds online software. The result can be seen in Figure F.1 on page 306. The model comprises 16 criteria each having three categories. 16 is the maximum number of criteria allowed in 1000minds as the number of potential pairwise rankings obviously grows very large as the number of criteria increases12 . As the number of categories also affect this number, I chose to use only three for each criteria. Two things are important to notice here: First of all, as the categories all represent monotonically increasing functions, it implies the notion of an “ideal” ARS system in terms of dependability and ELS compliance, which is a system scoring the highest value in all criteria, that is, obtaining an overall utility of 100% produced as the sum of the point values. These values can be seen in the right side of the figure, all indicating 0%, 3.1%, and 6.3% for the three criteria respectively, as the model has not yet been ranked. Whether such an “ideal” ARS system, in fact, exists or can be constructed is another story but the notion of it seems feasible as it would be a system complying fully with all the addressed issues. Secondly, I address the ELS issues only through three simple criteria, which will probably not be sufficient in a complete real-life assessment. However, these issues could always be expanded into an complete analysis of their own, where the model is devised by specialists in these fields.
4.5.3
ServiceBot: Initial Analyses
The Initial Analyses of the ServiceBot involves addressing the Problem and overall systemlevel aspects corresponding to (I1–I7) of Figure E.1 on page 304. I will in the following address each of these separately.
I1: Task The Task was in the Problem specified as:
12
According to the 1000minds software, 16 criteria with three categories each, result in a total of
43, 046, 721 possible pairwise combinations.
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
133
• Transport goods from home through corridors to various locations on the campus grounds
• Deliver the goods at various locations • Return home.
We can expand this list slightly by subdividing each subtask further: 1. Locate goods 2. Obtain goods 3. Transfer goods to transport unit if required 4. Transport goods through corridors 5. Locate place-location 6. Transport goods to place-location 7. Deliver goods at place-location 8. Return through corridors to home These tasks now have to be assessed with respect to which could be done by humans and robots, and which should not be done by humans or robots. This will give a preliminary indication of where robots could be used in the system. The assessment is shown in Table 4.1.
Task 1 2 3 4 5 6 7 8
C humans
SN humans
× × ×
(×)
×
× × ×
× ×
SN robots
×
× ×
C robots
× (×)
× × ×
Table 4.1: A Task analysis indicating which tasks could (C) be done by humans and robots respectively, and which should not (SN) be done by humans or robots, respectively.
134
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
From these preliminary analysis it seems that all subtasks of the ARS could be done by both humans and robots. The only exceptions are (3) and (7) which, perhaps, should not be done by humans as they may require lifting and manipulation of potentially heavy objects. However, this will have to be discussed with the administration and service personnel, as it depends on what goods are to be handled. I2: Environment The Environment was in the Problem specified as: • The environment comprises home, corridors, various pick-up and place locations, people (mostly students), furniture, plants, other objects.
To assess which elements may be potential task-performers in the existing environment a more thorough analysis has to be conducted. In Appendix C several pictures are presented illustrating several aspects of the environment: Figure C.1 shows the corridors and pathways at University of Suburbia, Figure C.2 shows junctions and turns of the pathways and corridors, Figure C.3 shows an elevator exit used to access the perpendicular corridors, Figure C.4 shows a few potential obstacles, Figure C.5 shows “broken” lines, colour differences in the floor, and distances to objects, and Figure C.6 shows the structure of the ceiling above the corridors and pathways. In the photos are shown pathways comprising two parallel white lines on the ground, which are used to indicate where the vehicles manually operated by the service personnel were allowed to drive. Along the pathways are doors to lecture halls and offices, which are potential place-locations. Large glass doors are also seen, which lead to perpendicular corridors also containing lecture halls and offices. To access these perpendicular corridors – which are located at a lower level – the manually operated vehicles have to use an elevator. The corridors are all lit by fluorescent lights mounted on a metallic ceiling structure. Few windows are placed in the corridors making them appear slightly dim. Of these elements, only the existing service personnel and the elevators seem to be potential task-performers. I3: Requirements The Requirements was in the Problem specified as:
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
135
• Must be available every day between 8 o’clock and 16 o’clock. • Safe
Analysing these requirements reveals that safety and availability are dependability issues addressed directly by the university administration and are, in fact, the only explicitly stated requirements. I4: Dependability and ELS compliance Here we apply Step 2 of the methodology presented in Section 4.5.2 which stated: Step 2: 1. Conduct ranking process with respect to the context in question. 2. Interpret the result to assess which are criteria are relevant and which are not. Keep the relevant ones and discard the irrelevant ones. If in doubt whether to keep or discard a criteria, keep it. The initial ranking should be done by the problem stater (i.e. the university administration) supervised by the ARS designer – I will in this example impersonate both. The 1000minds software has a simulation module assessing how many pairwise rankings of undominated pairs are actually necessary, and in this case the system estimated from 90 to 292 when run 14 times. The reason for the imprecise prediction is that depending on the ranking of a particular pair (by indicating ‘ ’, ‘∼’, or ‘≺’), the system may automatically resolve several other pairs as corollaries – how many depends on the current and previous rankings. In total I had to rank 154 pairs which took me around 40 minutes which is, on average, one ranking per 15 seconds. This seems to be an acceptable amount of time to spend on the activity and even so if it is was doubled or tripled in a real-life situation. However, I only ranked criteria defined on just two criteria at a time. In the experience I have gained with the system, the rankings with more criteria does make the value-model more accurate, but the initial two-criteria rankings give a very good indication. As an example of a pair I was presented with, consider Figure 4.17. Here I had to decide between a dominance of either Availability or Societal issues. In this case I chose to favour 66–100% availability and neutral societal impact over 33–66% availability and positive societal impact. This because it was explicitly stated in the requirements that
136
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
availability was a key factor, and as the societal impact was only neutral in the worst case, the choice was easy.
Figure 4.17: A pairwise ranking situation addressing Availability and Societal issues.
Consider now instead Figure 4.18 where I had to decide between a dominance of either Reliability or Societal issues. Here I had to choose between 33–66% reliability and neutral societal impact over 66–100% reliability and negative societal impact. In this case I chose the first alternative as I believe that a system with negative societal impact, for instance, people getting fired directly because the ARS is installed, could potentially lead to a bad atmosphere and possibly create a situation where the robot is “forced into a closet”, as exemplified in Section 2.2.2.
Figure 4.18: A pairwise ranking situation addressing Reliability and Societal issues.
The resulting rankings of the criteria can be seen in Figure F.2 on page 307. One way of interpreting the results is that Physical safety is the most important criteria as its maximum point value is 11,6% followed by Societal impact with 10.7%, and so on. However, if the goal is to maximise utility for a certain solution the maximum point increase is obtained
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
137
by ensuring that there is no negative societal impact, as a transition to neutral provides 10,0% (this is indicated in the additional columns to the right where I have conducted a post-processing of the results from 1000minds). Using this reasoning, ensuring that the likelihood of the ARS causing physical harm is at least only moderately likely is ranked as second most important together with the availability being at least 33–66%. Interpreting the results based on their maximum point values does, however, make good sense and indicates the following priority of the criteria:
1
Physical Safety
2
Societal
3
Legal
4
Reliability
5
Availability
6
Resilience
7
Mental safety
8
Accuracy
9
Maintainability
10
Ethical
11
Precision
12
Security
13
Timeliness
14
Reparability
15
Confidentiality
16
Integrity
Table 4.2: The ranked Dependability and ELS compliance criteria for the ServiceBot.
As expected physical safety is at the top of the list but it is immediately followed by societal and legal impact, that is, two of the three ELS components. Being forced to consider dependability and ELS issues in a broader perspective but only pairwise at a time with other factors, produces, in my opinion, a more reliable result than considering all factors at the same time. In the QFD (e.g. [ReVelle et al. 1998]) design criteria rankings for a horticultural nursing robot we presented in [Sørensen et al. 2008, 2010], it was revealed – as
138
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
a surprise to us – that the users had ranked “Well-built Appearance” as being almost “not important” when assessed simultaneously with technical parameters. This was contrary to our general observations in robotics and we concluded that “the current QFD analysis should be modified in order to capture possible ‘unspoken’ customer needs.” I believe that using tools like PAPRIKA may help avoid such problems, and though the above example only illustrates my rankings, I did try to be realistic in my answers. At this point I am reluctant to remove any of the criteria from the list as I do not feel I have sufficient information – this decision should be made later on (if necessary) and together with the relevant partners (primarily university administration and service personnel). I5: Socio-technical issues Analysis of the socio-technical issues should in a real-life situation be conducted by people with the proper knowledge to do so (e.g. sociologists), but I will make an attempt for illustrative purposes. As the service department is an important part of the university’s infrastructure it is imperative that ARS system becomes an integrated part of it with respect to its job function but more importantly with respect to the human personnel. There has been rumours on campus that the rationalisation process the administration is undertaking is not only to help the service personnel but, in fact, over time to perform cutbacks in the workforce. This has produced an uneasiness in the service department as they fear that if the system is too effective they will loose their jobs. To avoid the personnel becoming “hostile” towards the system it is therefore stressed that the ARS should be regarded as an aid to the existing personnel; not as a substitute. The ARS sought is therefore not to be regarded as a Robotic Worker 13 but as a Robotic Co-worker 14 . The existing personnel should therefore receive intensive training in the workings and use of the system to feel confident that “they are still in control”. Furthermore they should be included as much in the development process as possible to gain a feel of “ownership” of the final solution. 13 14
“Robots performing tasks autonomously” [European Robotics Technology Platform (EUROP) 2009c]. “Robots working directly with and for humans” [European Robotics Technology Platform (EUROP)
2009c].
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
139
These considerations will ease the integration and acceptability of the system. I6: Complexity To facilitate the results of the above analyses it seems that a reduction in development complexity may be obtained by focusing solely on solutions with a lower degree of autonomy. If the existing service personnel are to be an inherent part of the ARS operation, full autonomy is not required. I7: ARS approach As funds and development time are not problems to the university administration all three approaches may still be valid at this point. Further clarification is needed. Summary The initial analyses has resulted in an expansion of the original Problem specification, now incorporating a more detailed Task component, a more detailed Environment component, and a Requirement component now containing additional dependability and ELS compliance issues, socio-technical parameters, and a direction for what level of autonomy should be used.
4.5.4
Concept Generation
Concept Generation is the process of generating a set of overall Solution candidates that conform to the RTE-representation and obey the system Requirements. Main considerations to keep in mind through this process can be found as (RTE1–RTE5) of Figure E.1 on page 304 – the Design Considerations Reference Sheet – where Figure 4.13 on page 121 illustrates the inherent coupling between the RTE components in this process. Each concept candidate must comprise: 1. a description of the concept and the principles behind it. 2. a list comprising environment components and any new elements added to it. This constitutes the Environment* -component.
140
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
3. a classification of the Environment* -component elements into Enablers, Disabler, Commuters, or Irrelevant. 4. a list comprising tasks and any revisions made to it. This constitutes the Task* component. 5. a description of how task division among the task-performing elements is intended. The process of generating the candidates can be done in a number of ways, and I will not impose any one method in particular. However, a brainstorming technique that I have been subjected to several times15 is the generation of several solution possibilities each belonging to a certain category spanned by one or more dimensions. Examples for ARS concept dimensions could be: • 1) One or several robots, 2) semi or full autonomy, and 3) with or without additions to
the Environment-component. This produces eight candidate categories representing
a broad range of possible solutions. • 1) Different ARS approaches. This produces three candidate categories and is more focused on the development process.
• 1) One or several robots, 2) with or without changes to the Environment-component,
and 3) with or without changes to the Task -component. This produces eight categories and is based only on the RTE-component; the first could be substituted for by, for instance, “semi or full autonomy” if this is more convenient.
4.5.5
ServiceBot: Concept Generation
To keep the ServiceBot case study at a reasonable level I have taken the liberty of making a few simplifications: 1) I will only consider the top-5 Dependability and ELS compliance criteria of Table 4.2 and disregard the rest, 2) the ServiceBot should only operate indoor and in the main corridor of the university, that is, the approximately 400 m long “gray” stretch shown in Figure 4.16 on page 129, 3) the brainstorming activity was reduced to discussions with a friend where we short-listed two possible concepts: the first is based on several small autonomous vehicles and the second is based on robots able to crawl along the ceilings of the corridors. Inspiration of the former comes from KIVA systems16 15 16
I am not sure if it is, in fact, a particular method or if it is just a common technique. http://www.kivasystems.com/
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
141
producing mobile robots for warehouse automation (Figure 4.19(a)), and of the latter from the project ACROBOTER17 [Stepan et al. 2009] (Figure 4.19(b)). In the following I will treat these two candidates.
(a) Kiva
A
robot able
to
port 1,300 kg.
from trans-
(b) Concept of the ACROBOTER platform (from [Stepan et al. 2009])
(from
http://www.kivasystems.com/solutions/picking/pick-from-pallets) Figure 4.19: Inspiration for the two concepts.
Concept I: Several mobile robots The concept applies several small mobile units each able to carry a substantial load – an example could be a robot similar to one of KIVA’s robots shown in Figure 4.19(a). Navigation is conducted by using an onboard vision system to follow the paths already used (R5) by the manually operated vehicles, and identification of place-locations is done using RFID tags in the floor or landmarks mounted on the doors readable by an onboard scanner (E4 and E5). Mobile robot technology is quite well known and is suitable for this task (R4). I have addressed T1, E1, and R1 (Dependability and ELS), in the following way: Physical Safety is ensured by 1) a slow driving velocity, and 2) a safety system that automatically slows the robots down to a halt when potential collisions are detected. As people particularly during busy hours (lunch time, for instance) take up most of the corridor space and often move in quick random patterns, it is advised not to operate the system in these periods as the risk of collision is too high. Carrying a load of 100 kg while 17
Supported by the European Union FP6 under grant no. IST-2006-045530.
142
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
moving, say, 1 m/s, can potentially cause severe damage to both people and goods upon impact. Societal impact is addressed as part of the socio-technical issues, and is directly a part of the Task* analysis in Table 4.4. Legal implications are addressed through the safety system as it is assessed that potential legal issues will primarily arise from damaged done by the robots. Reliability is addressed by applying a well-known technical concept (mobile robots) instead of venturing into new fields. Availability is addressed by applying a well-known technical concept and by careful training of the service personnel on how to operate the system.
Let us move on to the Environment* classification. Table 4.3 shows a list of elements in the Environment* where the original Environment elements are at the top, and below the double line, the additional elements. Each element is classified as either an Enabler (E), Disabler (D), Commuter (C), or as Irrelevant (I).
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
Element
E
Goods
×
The items transported
×
As we need them for navigation
Floor Lines Doors
D
C
I
×
143
Comment
As the robots drive on it ×
May be enablers if they are placelocations but disablers if they are opened and block the path of the robots
×
Pick-and-place locations
Should be enablers but if they are doors they may open and block the path of the robots
×
People Operators Ceiling
×
Overhead light
×
Bags RFID Landmarks
× ×
move other people out of the way Should facilitate the task
×
Sofas
Predominantly obstacles unless they
×
Not of importance
×
Location of the lines is done through a
Large obstacles vision system with its own light source Obstacles For localisation For localisation
Table 4.3: Concept I: Classification of the Environment* elements as Enabler (E), Disabler (D), Commuter (C), or Irrelevant (I). Elements at the bottom below the double line are additions to the environment.
As determined previously the only task-performing elements in the ARS are Operators (service personnel) and Robots. As the initial analyses conducted in Section 4.5.3 showed that all subtasks of the ARS could be done by both humans and robots the following task allocation is therefore within the system boundaries:
144
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
Task (1) Locate goods (2) Obtain goods
Operators ×
× ×
(3) Transfer goods to transport unit if required
×
(4) Transport goods through corridors
×
(5) Locate place-location
×
(6) Transport goods to place-location
×
(7) Deliver goods at place-location
×
(8) Return through corridors to home (9) Charge robot
Robots
×
Table 4.4: Concept I: A Task* analysis indicating which tasks the task-performing (Operators and Robots) are doing. Elements at the bottom below the double line are additions to the original task specification.
In Table 4.4 “(9) Charge robot” is the only alteration made to the Task and as can be observed I have delegated this task and (1) to the Operators to address T2, E2, R2, T4, and T5. With respect to Complexity issues, T3 has been covered by adding (9) above as an automatic docking and charging procedure has a higher development complexity than if an operator conducts it. E3 is addressed by adding simple RFID tags and/or landmarks to the system for easy and cheap localisation of place-locations instead of, for instance, complicated laser guided Simultaneous Localisation and Mapping (SLAM) techniques. R3 has not been considered as the exact configuration of robots has not been established. All main considerations (RTE1–RTE5) of the Design Considerations Reference Sheet have been made. Concept II: Ceiling crawling robots The concept applies several mobile units moving on the existing metal frames (R5) suspended from the ceiling in the university corridors as shown in Figure C.6(a). An example of such a robot is shown in Figure 4.19(b). The robots move by attaching themselves to two points in the frame by means of a hook-mechanism, releasing one, turning 90 degrees
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
145
around the other and reattaching the first in a new position. The robots load the goods by releasing a wire that grabs the goods and retracts it to be just under the robot body. Navigation is conducted by following a sequence of RFID tags mounted in all the connection points in the ceiling (E5). These RFID tags also indicate place-locations (E4). Though the motion technology is not fully developed yet, it is anticipated that this concept is suitable as a solution to the Problem (R4).
I have addressed T1, E1, and R1 (Dependability and ELS), in the following way:
Physical Safety is ensured by not moving at ground level which prevents collisions with humans and other obstacles on the ground. However, there is a potential hazard if the robot should loose its grip and fall to the ground, therefore the mechanical parts have to be designed very carefully to ensure that this does not happen. Societal impact is addressed as part of the socio-technical issues, and is directly a part of the Task* analysis in Table 4.6. Legal implications are addressed through the safety system as it is assessed that potential legal issues will primarily arise from damaged done by the robots. Reliability is potentially critical as this technology has not been fully tested yet. However, preliminary results are positive. Availability is addressed by careful training of the service personnel on how to operate the system.
Let us move on to the Environment* classification. Table 4.5 shows a list of elements in the Environment* where the original Environment elements are at the top, and below the double line, the additional elements. Each element is classified as either an Enabler (E), Disabler (D), Commuter (C), or as Irrelevant (I).
146
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
Element
E
Goods
×
Floor
D
C
I
Comment The items transported
×
Lines ×
Doors
×
Not present in the ceiling Not present in the ceiling May be enablers if they are placelocations but disablers if they are opened and block the path of the robots
×
Pick-and-place locations
Should be enablers but if they are doors they may open and block the path of the robots ×
People Operators Ceiling Sofas
× ×
Should facilitate the task As the robot moves on it
×
Overhead light
Not present in the ceiling
×
Not present in the ceiling May pose a problem as the robot has to move past them without damaging neither the robot or the lights
×
Bags RFID Ceiling connection points
× ×
Not present in the ceiling For localisation and navigation For motion
Table 4.5: Concept II: Classification of the Environment* elements as Enabler (E), Disabler (D), Commuter (C), or Irrelevant (I). Elements at the bottom below the double line are additions to the environment.
As determined previously the only task-performing elements in the ARS are Operators (service personnel) and Robots. As the initial analyses conducted in Section 4.5.3 showed that all subtasks of the ARS could be done by both humans and robots the following task allocation is therefore within the system boundaries:
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
Task
Operators
(1) Locate goods (2) Obtain goods
×
Robots × ×
(3) Transfer goods to transport unit if required
×
(4) Transport goods through corridors
×
(5) Locate place-location
×
(6) Transport goods to place-location
×
(7) Deliver goods at place-location
×
(8) Return through corridors to home (9) Charge robot
147
×
Table 4.6: Concept II: A Task* analysis indicating which tasks the task-performing (Operators and Robots) are doing. Elements at the bottom below the double line are additions to the original task specification.
In Table 4.4 “(9) Charge robot” is the only alteration made to the Task and as can be observed I have delegated this task and (1) to the Operators to address T2, E2, R2, T4, and T5. With respect to Complexity issues, T3 has been covered by adding (9) above as an automatic docking and charging procedure has a higher development complexity than if an operator conducts it. E3 is addressed by adding simple RFID tags to the system for easy and cheap navigation and localisation of place-locations. R3 has not been considered as the exact configuration of robots has not been established. All main considerations (RTE1–RTE5) of the Design Considerations Reference Sheet have been made.
4.5.6
Concept Assessment
Concept Assessment is the process of assessing the validity of the generated concepts seen from the perspective of both the Problem specification and the overall system-level considerations. This process may lead to the selection of a final concept, to a new concept generation phase if ideas need to be reworked, or to a revision of one or more of the Problem
148
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
aspects. Concept assessment should be carried out by the ARS designer together with the customer, project partners, investors, and other relevant project stakeholders, and together with specialists from the individual dependability and ELS fields. Main considerations to keep in mind through this process can be found as (A1–A5) of Figure E.1 on page 304 – the Design Considerations Reference Sheet: A1 is a general assessment of how well the concept addresses the Problem. A2 is assessed by conducting Step 3 of the Dependability and ELS compliance decision-making methodology presented in Section 4.5.2. A3 relates to socio-technical issues and have to be assessed by people with knowledge in this field, A4 relates to complexity assessment which can be conducted using the Genefke-POEM Tool which will be presented in Chapter 8, and A5 is a general reflection on the design approach taken. Based on the results of the five assessments a conclusion is made on how to proceed. The greatest challenges here lie in A2. Each of the concepts (and the final system) has to be ranked according to the Dependability and ELS compliance criteria which begs the question: how do we assess the physical safety level of a concept? – and all of the other criteria for that matter? There are no easy answers to these question as some require a lot of specialised domain knowledge. Physical safety, for instance, may require knowledge of error propagation, risk analyses, hardware failure, etc., and addressing Integrity aspects may require knowledge of secure software systems. Other criteria like Precision and Availability can only be properly assessed once the final system is operational – initial indicators can, of course, be obtained through simulations and testing of prototypes. It is entirely possible that separate and more thorough assessments of the individual criteria will have to be conducted to produce a more valuable result, but I contend that the preliminary list of criteria I have presented in Figure F.1 on page 306 provides a good first attempt and gives a “rough” picture sufficient for the initial analysis presented in this thesis.
4.5.7
ServiceBot: Concept Assessment
A1: General Assessment The general assessment of Concept I and Concept II is done with respect to the Problem. As both systems seem to offer a feasible solution to the Problem with respect to how they address the Task, Environment, and the Requirements, both are valid concepts.
4.5. AN ARS SYSTEM-LEVEL CONCEPT GENERATION FRAMEWORK
149
Let us take a closer look at the construction of the Environment* -components (Table 4.3 and Table 4.5, respectively). Of the original eleven Environment elements, both present two Commuters (Doors and Pick-and-place locations), Concept I three Disablers (people, sofas, and bags) but Concept II only one Disabler (the overhead lights). Avoiding static overhead lights seems to be easy compared to avoiding people, sofas, and bags in a crowded corridor, which makes Concept II look slightly more appealing. However, handling doors and pick-and-place locations using a mobile robot is not unfamiliar territory and can be solved, whereas doing the same using a ceiling crawler is a little less obvious. The conclusion of the general assessment is therefore, at this point, a tie. A2: Dependability and ELS compliance The top-5 Dependability and ELS compliance criteria of Table 4.2 are Physical Safety, Societal aspects, Legal aspects, Reliability issues, and Availability issues, and I (representing both the university administration, the service personnel, and other stakeholders) have
Concept
Physical Safety
Societal
Legal
Reliability
Availability
Rank
Score
made the assessments presented in Table 4.7.
Mobile robots
ML
P
NL
66–100%
66–100%
1
94.0%
Ceiling Crawler
ML
P
ML
33–66%
33-66%
2
72.6%
Table 4.7: The ServiceBot concept rankings. The following abbreviations are used: Moderately likely (ML), Positive (P), and Not likely (NL).
I estimated the risk of compromised physical safety of both concepts to be moderate, as it is unclear exactly how safe they can be made – in particular regarding Concept II. If the mechanical connections to the ceiling fail a potentially very dangerous situation can occur. So I estimate Concept I to be potentially much safer than Concept II but as there were only three categories to choose from I had to place them in the same category. I estimated the societal impact of both systems to be positive as the inclusion of the
150
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
service personnel in both the development and use of the system, (hopefully) makes them also happy to use it. Furthermore, robots in the public domain usually inspires curiosity which may have a positive impact on the other people in the environment. I estimated the likelihood of legal aspects becoming a problem to be significantly lower for Concept I than for Concept II. As Concept II is hanging from the ceiling it may potentially cause greater damage if it falls than if a mobile robot at slow speed accidentally knocks someone over. I estimated both the reliability and the availability of Concept I to be greater than that of Concept II as I have a hard time imagining how well the crawler will actually perform. These are, of course, all subjective assessments. The overall conclusion is hardly surprising: Concept I is the winner with 94.0% score over Concept II with only 72.6%18 .
A3: Socio-technical issues The socio-technical issues are in both concepts addressed by adding a new subtask and delegating this and another task to the system Operators. This is in accordance with the socio-technical issues addressed, and both concepts therefore comply equally well.
A4: Complexity Assessment The complexity assessment of the two concepts is conducted using the Genefke-POEM tool presented in Chapter 8, where the ServiceBot process is presented in detail in Section 8.4 on page 256. The results of the analyses are stated in the evaluation: “Concluding that Concept II is a ‘significantly more complex’ concept than Concept I is therefore not entirely misguided.”
A5: ARS approach The ARS approach has not yet been officially chosen but as both concepts make changes to the Environment and the Task components, both implicitly apply an ARS Solver approach. 18
I have normalised the score with respect to the first five criteria under consideration.
4.6. EVALUATION
151
Conclusion Based on the concept assessments, it is by the university administration and the service personnel decided to pursue only Concept I – Concept II had qualities, but as both the Dependability and ELS compliance assessment and the Complexity assessment were in favour of Concept I, the choice was easy to make. However, it is recommended to conduct a more detailed concept specification and another Concept Assessment before the final decision to use Concept I is made as concerns have been raised that the performance may not be high enough due to the seemingly very low velocities of the robots. This will have to be clarified further.
4.6
Evaluation
In this chapter I have presented the following four design methods which have all been applied in the running example ServiceBot: 1. The three ARS design approaches 2. The Design Considerations Reference sheet 3. The Dependability and ELS assessment methodology 4. The ARS system-level Concept Generation Framework Though the ServiceBot example was rather simple in nature it illustrated quite well how the methods could be integrated into a concept generation framework that through initial analyses, concept generation, and concept assessment was able to lead to the selection of a final solution concept. Let us explore this a bit further: The three ways of addressing a problem, (1), was not directly applied to the process as the constraints I had imposed on the problem did not require the initial identification of a fixed strategy. It was, however, concluded that the two solution concepts would both require an ARS Solver approach as they both addressed changes to the Task and Environment components without changing the overall Problem. The validity of the three ways of addressing a Problem is hard to assess as they have not really been applied. I believe that the rationale behind them is sound, but as I have not offered any in-depth discussion of what design implications a given choice may have,
152
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
their use may be limited. However, if a more direct coupling between a given approach and, say, economy or complexity, could be made it would give the ARS designer and other project stakeholders the means rationally to choose which way to go. The reason for why I have not directly addressed this is that such a coupling is not too apparent as, for instance, making alterations to the environment may not necessarily make the system more expensive or more complex. This concept therefore needs further development before I believe it to be a real asset in the design process. The Design Considerations Reference Sheet, (2), is a summary of the results and discussions presented in Section 4.3 and the overall system-level discussions presented in previous chapters. In the ARS system-level Concept Generation Framework it was applied as a “guiding-light” for the generation process, which seemed to work as intended: it forced me to consider system-level aspects as well as intra-RTE aspects through the entire concept generation process. In the places where I initially “cheated” by ignoring certain aspects I was later – after consulting the sheet – forced to revised my descriptions, explicitly stating what issues had been covered, and how they had been covered. I experienced this a positive addition to the process, and it proved that it is possible to provide simple guidelines to address complex problems. The validity of the method has only been demonstrated with respect to the ServiceBot case, where it proved to be an asset. This, however, does not fully validate the method as it will need external validation by people besides me in design contexts not constructed by me, to prove its worth. Before doing so, I believe it is necessary to elaborate, in particular, the guidelines for socio-technical validation as there are likely to be relevant issues that I am not aware of. A revision of the sheet by qualified personnel is therefore required before external tests can be conducted reliably. The Dependability and ELS assessment methodology, (3), was applied in the ServiceBot case as part of the ARS system-level Concept Generation Framework facilitated by the 1000minds software based on the PAPRIKA method. The methodology comprises three steps: the first is to construct a context independent value model, which I based on the set of dependability and ELS compliance criteria presented in Section 2.1. The second step is to conduct a ranking of the criteria and to potentially reduce the criteria set after careful interpretation of the results. In the ServiceBot case I performed this ranking by pretending
4.6. EVALUATION
153
to be the problem stater and chose, initially, not to reduce the set. Later on, however, I reduced the set to the top-5 ranked criteria as a simplification of the example. The third step is to rank the generated concepts (or final Solution) with respect to the criteria and evaluate the results. In the ServiceBot case I ranked the two generated concepts where one, Concept I, turned out potentially to address better the dependability and ELS compliance issues. The validity of the methodology has only been demonstrated with respect to the ServiceBot case. However, here it proved to work very well as the 1000minds software was able directly to support it and facilitate its actual use. This turned out to be a great asset in the process as it forced the user (me) to relate to all the dependability and ELS compliance issues through the pairwise ranking process. As expected this process helped elucidate quite a few issues and the end result – the ranking – was not a surprise. As discussed in Section 4.4.2 I have already used the 1000minds software in several real-life scenarios, where it has also performed very well. The methodologies I have used in these cases have been similar to the one presented here – just tailored to different applications – and I therefore have great confidence in the soundness of the presented approach. The idea of directly using decision-making tools and methods in ARS design may have, as discussed in Section 4.4.3, great potential and should be explored further. As an example of such explorative ideas is a new EU-project which is, at the moment, in its final negotiation phases with the EU FP7 administration. DTI is part of this project and I have contributed most of the textual material for a work package dealing with Design Support Systems in robotics design. I expect to bring the ideas and experiences from the Dependability and ELS assessment methodology directly into this work package as background knowledge when the project starts. The The ARS system-level Concept Generation Framework, (4), was developed as an illustration of how the methods of this chapter could be used in a structured context. The framework was iteratively applied to the ServiceBot case to show its validity, and proved to provide a simple and intuitive way of transiting from a Problem to a final concept through system-level thinking. The phases of the concept – Initial Analyses, Concept Generation, and Concept Assessment – were all sound, and largely based on ideas from [Kossiakoff and Sweet 2003] and [Ulrich and Eppinger 2008]. Though the ServiceBot case was simple and reduced in nature, I believe that the framework is scalable to real-world sized problems as the concepts and methods of this chapter all scale as well.
154
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
The validity of the framework has – like the other methods – only been demonstrated with respect to the ServiceBot case. However, here it proved its worth and served its purpose, and I do believe that it will do the same in a real-world scenario. These scenarios are unfortunately not easy to come by as they often exist only in student classes or in EU projects where the concept generation phase usually is quite small as the overall concepts of the system often is decided beforehand.
4.7
Conclusions
In this chapter I have presented several system-level aspects of ARS design. In Section 4.1 I first addressed what it implies to design an ARS, that is, what it means to transit from a Problem to a Solution, thus creating an ARS instantiation. Then in Section 4.2 I described what a Problem comprises. Here I argued that an ARS can be characterised as having “goal-seeking behaviour” as it will always have some purpose that is carried out through tasks. In the following section I presented the issue of “addressing problems”, where the terms to resolve, to solve, and to dissolve were discussed, leading to the explicit coupling to the RTE-components by defining three general types of goal-seeking ARS approaches: the ARS Resolver, the ARS Solver, and the ARS Dissolver – each addressing a Problem in a different way. In Section 4.3 I presented issues relating to the instantiation of an ARS, where considerations of both the system-level – in particular dependability and ELS compliance issues, socio-technical issues, and complexity aspects –, the Task* -component, the Environment* -component, and the Robots-component were addressed separately and in-depth. This led to the creation of the Design Considerations Reference Sheet which represents a summary of the design issues considered. Section 4.4 then discussed aspects of decision-making in the ARS design process, and Section 4.5 presented a case study called An ARS System-level Concept Generation Framework. Here I illustrated how the addressed design considerations coupled with a devised decision-making methodology specifically addressing Dependability and ELS compliance issues, could be used to generate and assess Solution concepts. Through this process a running example called ServiceBot was used to exemplify all aspects of the process. In last section I evaluated the developed methods and their use in ServiceBot case. These accomplishments directly fulfill Objective 3 of Table 1.1 on page 14.
4.7. CONCLUSIONS
155
To summarise, the four methods presented in this chapter, have the intended application domains shown in Figure 4.20. The three ARS design approaches are intended as system-level methods only existing in the concept development and partly in the engineering development stages. The same applies to the Design Considerations Reference Sheet and the Dependability and ELS Assessment Methodology which, however, do extend slightly further in the life-cycle as they also comprise assessments. The Concept Generation Framework is only present in the concept development stage, but extends somewhat into the intermediate levels and the component level, as it to some extent also addresses subsystems and components.
Planning
Concept Development
System−level Design
Concept Development
Needs Analysis
System level
Concept Exploration
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
ARS design approach Design Considerations Reference Sheet Dependability and ELS assessment methodology
Intermediate levels
Concept Generation Framework
Component level
Figure 4.20: The intended application domains of the tools, methods, models/representations developed in Chapter 4 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2.
156
CHAPTER 4. ASPECTS OF SYSTEM-LEVEL ARS DESIGN
Chapter 5 Related Works in System-level Design Doing “system-level design of systems” is not a new topic as it has been practiced for many years as an inherent part of many sciences and disciplines from Gastronomy to Architectural Design. Think, for instance, of complex systems like space shuttles, nuclear reactors, super tankers and the Large Hadron Collider which are all designed and realised according to specification, and (mostly1 ) work according to it. The design of such systems would not have been possible without careful system-level design considerations, and of course good science, engineering and management skills. In robotics, however, system-level design has mostly been done with respect to the robot being the whole “system” and only sometimes also with respect to its tasks and operating environment, which – as argued in this dissertation – are key when designing robotic systems that have to be integrated into the real world. Fortunately this is slowly beginning to change as more people recognise the need for a more rational approach to ˇ robotics design (e.g. [Sabanovi´ c 2010]), and thus also for design methods that are able to encompass more than just the robot. On several occasions during this PhD project I have attempted to convey this exact message (see for instance Appendix A) to both industry and academia, but often with quite different results. The former always seemed slightly more positive – perhaps because I always argued that the results of such an approach could lead to better products – while from academia I was often met with comments like: “We don’t need that. We are not interested in making working robotic systems, only in testing 1
With a few notable exceptions like Ariane5 and the Chernobyl disaster
157
158
CHAPTER 5. RELATED WORKS IN SYSTEM-LEVEL DESIGN
that the components resulting from our research work so we can publish papers and hire more PhD students.” Occasionally, however, I did received a sympathetic: “Good luck with that.”, as an acknowledgement of what I was trying to do and of the difficulty of the task. Academia is nevertheless on the right track, or at least moving in the right direction. I did an informal survey of the 2009–2010 EU projects found on the EURON web-site (see Section 2.5) where I tried subjectively to assess – by reading the overall mission statements and project web-sites – how many of them were dealing implicitly or explicitly with systemlevel issues beyond the robot itself. From my assessment I concluded that of the 21 projects started in 2009, about 7 of them deal with system-level issues (33%). Of the 15 projects started in 2010 the number is 7 (47%). Though a somewhat insufficient data set to draw major conclusions from, I still see this as an indication that projects dealing with broader system-perspectives are getting wider acceptance in the EU. Whether people are able to handle this challenge is a different matter, but the intentions are there. From the above it may not be a big surprise that not much previous work has actually been done in robotics relating to system-level design, which is further accentuated judging from the amount of academically published material on the subject. Of course companies like iRobot or Evolution Robotics would probably not have come as far as they have without system-level considerations but, as is often the case with companies and high-tech products, they keep their methods to themselves. A consequence hereof is that I have chosen instead to name this chapter Related Works and instead focus on making a brief literature overview of how disciplines and fields closely related to robotics – here in particular the sub-domain of ARSs’s – handle system-level thinking and how they handle the task and the environment aspects. Of related disciplines and fields I have found the following to be the most relevant: Software Engineering, Embedded Systems, Roboticsand Control Engineering, Systems Engineering, Product Development, and AI. Each of these disciplines have been chosen as they all offer some inherent system-level aspects and they can often be found in close contact with robotics. Software Engineering has a long history of broad systems-level thinking where userinterfaces, maintenance and economic considerations alongside the actual design of the software functionality often are key issues. Examples can easily be found by regarding, for example, the field of Object Oriented Analysis and Design (OOAD) [Mathiassen et al. 1998] and Extreme Programming [Beck 2000]. As has also been demonstrated several times
159 in this dissertation the works of, for instance, Ian Sommerville (eg. [Sommerville 2010]) have a lot to offer in this respect. However, I have found no references to complete robotic systems being developed solely using Software Engineering methodologies. In the design of digital electronics and Embedded Systems containing, for example, Field Programmable Gate Arrays (FPGA) and micro-controllers, various system-level design methods exist. An example is an UML-based design methodology for real-time and embedded systems presented in [de Jong 2002]. When designing real-time systems interacting with the real world, such approaches that take a broader system-level perspective are needed as several external components usually have to interact directly with the embedded system. In (traditional) Robotics- and Control Engineering, some broader system-level approaches exist but they are mostly concerned with designing kinematic configurations of modular robots to suit given application contexts, as is for example the case with the work of Farritor et al. [1996] on deriving configurations of a modular field robot using genetic algorithms or with the work of Paredis [1996] on the RMMS modular robot. Other approaches more focused on the mechatronic parts of systems can be found in, for example, [de Silva 2005] and [Coste et al. 1999]. Though all these approaches to some extent consider both the tasks and the environment, they are mainly guided by the design and physical assembly of the robots. No guidelines are proposed for integrating these systems into a realworld system context and such a process will therefore most likely rely on ad-hoc methods. Recently, however, in the field of self-reconfigurable modular robots Stoy et al. [2010] have presented a component model that is conceptually very similar to the RTE-representation of this dissertation as it addresses both the robot, the task, and the environment, and emphasises the need to consider all during a design process. Stoy et al.’s model is shown in Figure 5.1 with indication of how the Robots-component of the RTE-representation can be found. In [Dalgaard and Thomsen 2010] a system-level view is offered in an application where a new modular robot concept is coupled to the interior design of pig stables, and the pigs themselves. However, this system is not realised in real-life (not yet at least), and is therefore more of a conceptual solution. Within the field of Systems Engineering several systems-level methods do exist, for example [NASA 1995; International Council on Systems Engineering (INCOSE) 2000; Sys-
160
CHAPTER 5. RELATED WORKS IN SYSTEM-LEVEL DESIGN
Control
Mechanics
Robots
Electronics
Morphology
Task
Environment
Figure 5.1: “The components involved in robot design and their interactions” – an adapted version of Figure 2.1 from Stoy et al. [2010, p28], showing how the Robots-component of the RTE-representation can be found.
tems Management College 2001; Kossiakoff and Sweet 2003; Space & Missile Systems Center 2005; NASA 2007; Hitchins 2007; Kasser 2007; Friedenthal et al. 2008], but have, to the best of our knowledge, not yet been directly applied to the robotics field at least with results accessible to the public. However, as NASA has landed mobile robots on Mars I imagine that they have applied their own methodology in their development. The field of Product Development has traditionally much focus on the system-level as its development models treat all aspects from concept development to product maintenance [Ulrich and Eppinger 2008]. Some commonly used tools hereof, such as Quality Function Deployment (QFD) [ReVelle et al. 1998], have been applied to a few robotics systems, for example in the HortiBot project [Sørensen et al. 2006] and as part of the OmniRota project [Sørensen et al. 2008, 2010]2 funded by the Danish Government, Directorate for Food, Fisheries and Agri Business, where an actuated modular robot-wheel for plant nursing robots was developed. However, I have found no references to complete robotic systems being developed solely using Product Development methodologies. 2
I am co-author of these two papers.
161
Only relatively few disciplines within the robotics research community seem to have actually dealt with system-level oriented design approaches for designing complete autonomous robotic systems, and most of this work, though considering both the robots, the environment and the tasks, is based on the design and evolution of the robots’ controller architecture or the controller itself. This is the case for various disciplines within the AI field for example Good Old Fashioned AI and Robotics (GOFAIR), Insect AI, Situated Agents and Constraint Based Agents (CBA) (see for example [Celik and Mackworth 2004] for a discussion on the various disciplines). Another example is Embodied AI, where the interaction between intelligence and embodiment is essential, thus creating a link between the mechatronics, the task and the operating environment. An example can be found in [Pfeifer 1996]. Based on this brief outline of how disciplines and fields closely related to ARSs handle system-level thinking and aspects of task and environment, I do not believe that systemlevel design methods or methodologies have, so far, been applied in designing complete robotic systems. I therefore also firmly believe that the approach presented in this dissertation is indeed novel in nature.
162
CHAPTER 5. RELATED WORKS IN SYSTEM-LEVEL DESIGN
Chapter 6 Modelling an ARS This chapter is dedicated to establishing a suitable way of modelling an ARS that will make it easier to encompass all system-level aspects covered so far. In Chapter 3 the RTErepresentation was introduced as an ARS system-representation in its own right, but being a conceptual model it is not directly able to capture the separate system components and their complex couplings which is indeed required when we have to manage them in a design situation. We therefore need to establish a more detailed system-view which can be used as base for both modelling an ARS but also for manipulations of system components. In the previous chapters I have used the word system quite frequently, but have until now evaded explaining exactly what I mean by it. To establish a suitable foundation for a system-view, Section 6.1 will therefore first address this issue and show how a system can be modelled as a simple hierarchy – a system-hierarchy. Section 6.2 elaborates this and presents how this system-hierarchy can be graphically represented as both a tree and as a novel type of Design Structure Matrix (DSM) that I call a system-DSM – sDSM for short. To facilitate a more flexible design process Section 6.3 introduces the more dynamic Emergence Hierarchy based on the emergent properties of subsystems rather than on their functional properties, which is able simultaneously to represent a system at several levelsof-abstraction – this directly addresses Objective 4 of Table 1.1 on page 14. Lastly, in Section 6.4 I present a novel system-level reference model called POEM able to represent any ARS – directly addressing Objective 5. Several examples are offered to back this claim. Section 6.5 presents an evaluation of the results, and Section 6.6 offers a conclusion. 163
164
CHAPTER 6. MODELLING AN ARS
6.1
Definitions of System
Let us first take a closer look at the definition and the meaning of the term system. In spite of its common use in many languages and in such varied contexts as ecosystem, warning system, operating system, hexagonal crystal system, solar systems, school system, system-of-systems, cultural system, Computer Systems Engineering, and so on, a specific definition is somewhat elusive. Browsing through a few random dictionaries reveals the following: Source
Definition
WordWeb
• A group of independent but interrelated elements comprising a unified whole
• A complex of methods or rules governing behaviour Wiktionary
• A procedure or process for obtaining an objective
• From late Latin syst¯ema, from Ancient Greek συστ ηµα (syst¯ema, ”organised whole, body”)
• A whole composed of relationships among the members
WordWeb Online • A group of interacting, interrelated, or interdependent elements forming a complex whole
• A social, economic, or political organisational form Though in no way an exhaustive list, it is nevertheless quite representative, and does give an idea of what we of course suspected: it has to do with individual elements/members interacting to form some whole. Turning our attention once again to Systems Engineering as a natural source of further exploration we quickly discover more elaborate thoughts. Regarding a system from a Systems Engineering point of view implies regarding it as containing various complementary, interacting, cooperating, coordinating and adapting parts, each characterisable as being a system in its own right. From these interactions, cooperations, coordinations and adaptations among the parts (subsystems) a system’s properties emerge. That is, the properties that may not be identifiable from just looking at the separate functional properties of each part but rather come into existence as these particular parts interact in this particular way – the whole can therefore be seen as more than (or at least different from) just the sum of its parts. To capture these ideas Derek Hitchins offers the following definition of a system:
6.1. DEFINITIONS OF SYSTEM
165
A system is an open set of complementary interacting parts, with properties, capabilities and behaviours emerging, both from the parts and from their interactions, to synthesise a unified whole. [Hitchins 2007, p28]. Joseph Kasser has conducted a survey of various meanings and definitions of the word system [Kasser 2007, p17-2] and offers instead the following definition: A system is an abstraction from the real world of a set of objects, each at some level of decomposition, at some period of time, in an arbitrary boundary, crafted for a purpose. [Kasser 2007, p17-12]. These two definitions are in no way conflicting as they address different views of system, where Hitchins is more concerned with parts, properties, and emergence, and Kasser with the context and the representation. The systems-view they offer can be illustrated as in Figure 6.1, where dashed areas represent systems (and subsystems) bordered by boundaries and where arrows represent the interactions between these systems. Note that interactions only happen between systems at the same “level” – more on this later.
System
Surroundings Boundary
Figure 6.1: The various interacting parts/subsystems contained within a system, separated by boundaries.
With respect to boundaries, Kasser makes an explicit observation about his definition: “The word ‘arbitrary’ is used because the boundary may appear arbitrary to other entities until the purpose for drawing the boundary is understood”, and “The ‘boundary’ is
166
CHAPTER 6. MODELLING AN ARS
defined by the purpose for which it is drawn in the mind of the observer. . . ” [Kasser 2007, p17-12]. In other words, Kasser sees the boundaries as a subjective thing – created by applying cognitive filters (see Section 2.3.2) – and not as something predefined, and points out that “it is the act of drawing the system boundaries that creates the system” [Kasser 2007, p17-14]. Furthermore he does not see them as static either as he acknowledges that they may only be valid “at some period of time” as the area of interest represented by the system may change over time. Kasser’s view that a system is “an abstraction from the real world” is shared by Ropohl [1982] who states that “a system is by no means a real object. Actually it is more a model of reality.” Ropohl elaborates this by saying that a model has three typical characteristics which are also true for systems: (a) they are pictures – in the mathematical sense of a mapping – of reality, (b) they do not copy all the attributes of their original, but only those that seem to be relevant to the model builders and users, and (c) they are not absolutely valid, but only for definite persons during a definite time with regard to definite theoretical or practical operations. A system model of some part of reality is therefore not an absolute entity as it represents just one possible view-point: the one of the model builder. Another model builder may perceive reality differently and thus create an entirely different model, but the two models still represent the same part of reality and neither can therefore be said to be wrong. Hence, a system model can be interpreted and “the interpretation of the system model adds new information, which cannot be obtained from the model itself.” [Ropohl 1982]. Ropohl [1982] offers also a formal – mathematical – definition of a system as a combination of three different ways of regarding a system by different system schools: 1) as a functional concept, 2) as a structural concept, or 3) as a hierarchical concept. The Functional Concept regards the system as a black-box and deals with what-it-does rather than with what-it-is – it is thus a behavioural concept regarding the system from the “outside” – an external view. The Structural Concept is concerned with the “inside” of the system and views it as a whole composed of parts and relations and it is thus an internal view. The internal - and external -views can be illustrated as in Figure 6.2. The Hierarchical Concept views the system parts or elements as systems in their own right (subsystems), holding attributes and subfunctions of their own. The original system may therefore also be part
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
167
of a larger supersystem. Ropohl combines these three views System
into a formal specification of a system (S) represented as the following quadruple: INTERNAL VIEW
S = (α, ϕ, σ, π) where α is a set of attributes (inputs, outputs, states), ϕ a set of functions
Surroundings
EXTERNAL VIEW
that map between attributes, σ a set
Figure 6.2: The internal-view and external-view of a
of subsystems Sk0 , and π a set of re-
system.
lations (or a structure) upon the sub-
systems. This formally includes all three concepts, but to make the hierarchical concept more explicit Ropohl defines the subsystem Sk0 and the supersystem S + as: Sk0 = (αk0 , ϕ0k , σk0 , πk0 )
and
S + = (α+ , ϕ+ , σ + , π + )
The hierarchy (H) of systems can now be defined as the sequence: H = (..., S 00 , S 0 , S, S + , S ++ , ...)
(6.1)
Ropohol’s definition is, of course, a lot more “mathematical” than those of Hitchins and Kasser, but expresses the same set of ideas.
6.2
A Hierarchical System Representation
From Figure 6.1 and from Ropohl’s direct reference to a hierarchy in Equation 6.1 it is evident that a system may be represented as a hierarchy of its subsystems and their subsystems and so on, where the top-most level references the system as one whole entity. Each level of the hierarchy thus represents the entire system at some specific level-ofabstraction, which as discussed in the previous section, does not necessarily mean that it is complete, in the sense that we only represent the subsystems that are of interest to us. Moving down the hierarchy from some system at some level resembles “zooming in” on Figure 6.1 revealing a different scope of the system, and thus the original system’s
168
CHAPTER 6. MODELLING AN ARS
subsystems. “The scope of a system representation is the set of components within the boundary between the associated system and its environment.” [Ryan 2007], which means that as we zoom in the boundaries change and become narrower. This narrowing, says Ryan, therefore implies that a certain scope, S, is defined by both a spatial, S (x) , and a
temporal, S (τ ) , boundary. The spatial represents a revelation of new subsystems as we narrow our view, and the temporal indicates that the boundaries may be dynamic. Note, that “spatial is used in the broadest sense of the word to include conceptual and formal, as well as physical spaces, provided the system has a physical manifestation.” [Ryan 2007]. Ryan also introduces resolution, about which he states: “Resolution is defined as the finest distinction that can be observed between two alternative system configurations.” [Ryan 2007]. Resolution is thus a measure of the amount of information in a scope which, in our case, is related to the number of subsystems and interactions present at a certain scope. The higher the number, the higher the resolution. Resolution, R, is like scope also
defined by both a spatial, R(x) , and a temporal, R(τ ) , dimension. The temporal dimension
defines the duration of a moment in time, where longer moments represent coarser (lower) resolutions. To add to Ropohl’s definition we can now regard a system hierarchy as defined by 1) its levels, 2) its subsystems, 3) its subsystem interactions, 4) the scope of each subsystem, and 5) the resolution of each subsystem. Let us look at how we can represent it.
6.2.1
A graphical representation
A graphical way of representing a hierarchy is drawing it as a graph (tree) where the leaves are subsystems and the branches represent links between systems of neighbouring levels. An example of a four-level hierarchy can be seen in Figure 6.3, where subsystems are drawn as ellipses using dashed lines, and the links between the systems are drawn using open-arrows in the direction from sub-to-super system. Addressing the issue of scope it can be observed that as we move a level down the hierarchy each subsystem comprises several subsystems, indicating a different level of detail. If, for instance, the top-level represents a car, the next level down could comprise subsystems in the line of engine, doors, windows, wheels, and chassis, thus representing a more detailed view of what a “car” comprises. The resolution can be observed as how detailed this view is. If we in the car example, for instance, included also panels, fenders, and window wipers
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
169
as part of the same level, our resolution would have increased. This can, to some extent, be observed in Figure 6.3 as the number of subsystems on each level increases. However, as it does not represent a real system, we do not know what the subsystems actually represent and how they interact, and can thus not reach this conclusion solely based on the number of subsystems alone, hence the reservation.
Figure 6.3: A four-level hierarchy of systems and components represented using a tree structure.
Interactions among the subsystems have so far not been discussed, but they are naturally an inherent part of the hierarchy. Pimmler and Eppinger [1994] advocate the need for a general taxonomy of interactions and suggest four important types: 1) associations of physical space and alignment, 2) associations of energy exchange, 3) associations of information exchange, and 4) associations of materials exchange. Though these four – and possibly many others – are naturally relevant in an ARS context, I will to keep things simple continue with the definition I used in Section 2.3.2, and thus use interaction generically to denote all types of information exchange between two subsystems. These can be anything from an abstract concept like “knowledge” to a very physical “stream of electrons”, depending on the level-of-abstraction applied, and thus depending also on the level of the hierarchy we are regarding. Hence, my definition encompasses also the four suggestions by Pimmler and Eppinger, and extends it even a bit further. In the digraphs of Section 2.3.2 I used closed arrows to indicate interactions, where the arrow tail represented the interaction source and the arrow head the interaction sink. This convention I will use also for the systems hierarchy.
170
CHAPTER 6. MODELLING AN ARS
6.2.2
A matrix representation: The sDSM
6.2.2.1
The DSM
As shown in Figure 2.10 on page 48 it is also possible to represent systems and their interactions using an n × n-adjacency matrix, where n is the number of systems and where the
row and column labels are identical, and ordered according to some total ordering of the component-groups. An “×” in a cell indicates that there is an interaction from the system in the row to the system in the column, hence representing the arrow in the digraph. Let us expand this notation to include the entire hierarchy. First I will introduce the Design Structure Matrix 1 (DSM) which in its simplest form is a non-reflexive binary n × n-adjacency matrix. The DSM can thus be used to represent
digraphs, and if the edges are weighted the DSM cells will contain these weights and thus be a Numerical DSM (NDSM). A digraph can for example be used to represent components (as in our case), people (teams or organisations), activities or parameters, which makes a natural classification of DSMs into either static DSMs – the elements exist simultaneously – or time-based DSMs – the ordering of rows and columns indicate a flow through time – as shown in the taxonomy in Figure 6.4 taken from [Browning 2001].
Design Structure Matrices (DSMs)
Static
Components− based DSM
People−based DSM
Time−based
Activity−based DSM
Parameter− based DSM
Figure 6.4: DSM taxonomy from [Browning 2001]
Component-based DSMs are used for modelling system architectures based on components and/or subsystems and their relationships. This is the type I will be using to 1
Sometimes also known as Dependency Structure Method, Dependency Structure Matrix, Problem
Solving Matrix (PSM), Incidence Matrix, N-square Matrix or Design Precedence Matrix.
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
171
represent the system hierarchy. People-based DSMs are used for modelling organisation structures based on people and their interactions. Activity-based DSMs are used for modelling processes and activity networks based on activities and their information flow and other dependencies. Parameter-based DSMs are used for modelling low-level relationships between design decisions and parameters, systems of equations, subroutine parameter exchanges, etc. Most operations performed on a DSM are based on one basic concept: reordering the rows and columns of the matrix. As the labels of the rows and columns are ordered the same way, interchanging two rows and the corresponding two columns will reveal a new DSM matrix, but the information it represents will still be exactly the same. However, by reordering a DSM in certain ways it is possible to structure this information revealing new aspects and properties that were previously hard to identify. Different algorithms exist to facilitate a range of DSM analyses with different purpose. A clustering algorithm used on a people-based DSM may, for instance, have the goal of finding subsets of DSM elements (i.e. clusters or modules) that are mutually exclusive or minimally interacting [Yassine 2004]. In this case, blocks become analogous to team formations or independent modules of a system, and it may thus be desired to reorder the matrix such that these blocks are found along the diagonal of the DSM. A sequencing algorithm like, for instance, partitioning is the process of reordering the DSM rows and columns such that the new DSM arrangement does not contain any feedback marks, thus transforming the DSM into a lower triangular form [Yassine 2004] – this will shortly be covered in more detail. Other types of DSM manipulations exist such as tearing, banding, and eigenvalue analysis which are typically used with time-based DSMs (see for instance [Yassine 2004]), but it is beyond the scope of this dissertation to cover them all in detail. However, below I will give a short overview of some of the applications areas of DSMs, and most of the references used include a basic introduction to DSMs and their different manipulations, which may serve as a good foundation for further reading. The DSM having a simple and yet intuitive representation has been used extensively over the years in areas such as [Browning 2001]: building construction, semiconductor design, automotive industry, photography, aerospace, telecom, small-scale manufacturing,
172
CHAPTER 6. MODELLING AN ARS
factory equipment, and electronics industries, where the problems addressed have been various and of quite different nature. Consider for instance the following (small) set of examples from Systems Engineering and Product Development alone: interconnecting two systems using interpretive structural modelling (ISM) [Venkatesan 1979], analysis of design procedures [Gebala and Eppinger 1991], task organisation [Eppinger et al. 1992], integration analysis of product decompositions [Pimmler and Eppinger 1994], the creation of product variants [Huang and Kusiak 1998], capturing, structuring and computer implementation of product and process specific knowledge in systems for Rule-Based Engineering [Rask and Sunnersj¨o 1998], concurrent engineering in complex product development [Yassine and Braha 2003], complex product development [Yassine 2004], and developing modular architectures using genetic algorithms [Yu et al. 2007]. For more specific examples from other fields and disciplines, Browning [2001] has conducted a rather extensive survey. Also the web-site of DSMweb.org 2 offers many resources regarding DSMs and their use.
One of the pioneers in the field of DSMs was John Nelson Warfield who laid much of the groundwork for what was later to be called the Design Structure Matrix by Steward [1981] – Warfield simply referred to them as binary matrices [Warfield 1973, 1974, 1977]. Warfield made several observations that will help us use the DSM as a way of representing our system hierarchy, where one such observation was that of partitions. Consider the following example adapted from [Warfield 1973]:
Suppose first we have an example system comprising 7 subsystems, S = {1, 2, 3, 4, 5, 6, 7}.
We can represent it using a DSM as shown in Figure 6.5(a), but also as the digraph shown in Figure 6.5(b). Note, that in the DSM I mark illegal cells using grey.
2
http://129.187.108.94/dsmweb/en/dsm.html
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
173
2 3 4 5
×
××
(a) An example DSM.
7
7
6
××
×
6 7
5
3
×
1
4
2
1
5
× ×
2
6
3
1
4
(b) As a digraph.
Figure 6.5: An example system as both a DSM and a digraph.
If we now apply some reordering of the rows and columns to produce the DSM in Figure 6.6(a) we can observe that it can be partitioned into 16 blocks as shown in Figure 6.6(b). The partitions are formed by taking the smallest square submatrix possible that can be formed along the main diagonal, while allowing only empty cells to the right of each diagonal submatrix – the last eight partitions are constructed to meet the dimensions of the first four. To represent these partitions on the set S we can write S = {1, 3, 7; 5; 4, 2, 6},
where each term identified by the overbar is called a block of the partition. A DSM in this form is called block triangular.
If we now label these partitions as shown in Figure 6.6(c), we can see that the submatrices C1, C2, C3, and C4 all represent separate subsystems – let us denote them C1∗ , C2∗ , C3∗ , and C4∗ respectively – with only internal relations and the other submatrices C21, C31, C41, C32, C42, and C43 represent external relations between the first four subsystems.
1 3 7 5 4 2
×
1 3 7 5 4
×
×
×
×
(a) Reordered DSM
2
×
6
4
2
7
×× ×
× ×
6
5
3
1
6
2
×× ×
×
6
4
5
3
7
CHAPTER 6. MODELLING AN ARS
1
174
×
×
×
(b) Partitioned DSM
(c) Partition labels
Figure 6.6: Partitioning a DSM.
The subsystems C1∗ , C2∗ , C3∗ , and C4∗ Warfield calls the constituents of the system. To see why, consider Figure 6.7(a) where these four subsystems are mapped onto the digraph from Figure 6.5(b). Note that as the DSM is block triangular there can be only one-way connections between constituents, while two-way connections are still possible within a constituent. The partition thus enables us to think of the system as a set of four subsystems whose digraph can be seen in Figure 6.7(b). Warfield calls this digraph a condensation of the digraph in Figure 6.7(a) and has the DSM shown in Figure 6.7(c), which is also block triangular. The condensation is carried out simply by observing that if any relation is present in any cell of the external relations – as is the case with C31, C41, and C42 – we infer that an external relation must also exist between the corresponding
C1*
2
C4*
C2* 7
C3*
C1*
C1*
C2* 5
C2*
constituents.
3
C1* C2*
1
6
C4*
C4* C3*
C3*
C3* C4*
4
× ××
(a) The Constituents of
(b) The Condensation of
(c) The Condensation repre-
the system
the system
sented as a DSM
Figure 6.7: Constituents and Condensation of a system
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
175
Warfield notes that a system represented by a block triangular matrix is called a hierarchical system or hierarchy and if we partition the DSM in Figure 6.7(c) by taking the largest possible submatrices on the main diagonal which are empty and having no relations to the right, the DSM will look as in Figure 6.8(a). The partition on this set is now P = {C1∗ , C2∗ ; C3∗ , C4∗ }. The two blocks represent the levels of the hierarchy, which
C4*
C3*
C2*
C1*
means that this is a two-level hierarchy.
C1* C2* C3* C4*
× ××
(a) The Condensation DSM partitioned Figure 6.8: A two-level system hierarchy
6.2.2.2
The sDSM
Combining the definitions and observations of the previous example it is now possible to make a coherent DSM representation of a system hierarchy, which I have chosen to call a systems DSM or sDSM for short. If we use the concept of partitions presented before we can model all possible partitions of a DSM as exemplified in Figure 6.9(a) where a hierarchy with four levels is shown. Here n represents the current level as seen from a row and each partition has a “(<value>)” associated with it, where value indicates to which level the relations in this particular partition go. Therefore “(n-2)” in a partition in row 3 indicates that all relations from this partition go to level 1. The system hierarchy presented earlier in this section comprises two types of relations: 1) the interactions among subsystems on the same level, and 2) the couplings between
176
CHAPTER 6. MODELLING AN ARS
two neighbouring levels. Both can be represented by a block triangular DSM where the interactions can be found in the partitions formed around the diagonal – shown as “(n)” in the figure – and the couplings between the levels as the partitions below the diagonal, that is, in all the “(n-X)” partitions where X is a positive integer. That means that all partitions above the diagonal, thus with elements in “(n+X)” partitions, where X is again a positive integer, are illegal. However, Warfield’s hierarchy representation does not entirely represent the type of hierarchy we are looking for as it allows relations between levels that are not neighbouring. To disallow this, we need to constrain the level couplings to only the “(n-1)” partitions, resulting in a set of legal partitions for a sDSM as shown in Figure 6.9(b). The white partitions are legal, the gray are illegal.
Lvl
0
1
2
3
Lvl
0
1
2
3
0
(n)
(n+1)
(n+2)
(n+3)
0
(n)
(n+1)
(n+2)
(n+3)
1 (n−1)
(n)
(n+1)
(n+2)
1 (n−1)
(n)
(n+1)
(n+2)
2 (n−2)
(n−1)
(n)
(n+1)
2 (n−2)
(n−1)
(n)
(n+1)
3 (n−3)
(n−2)
(n−1)
(n)
3 (n−3)
(n−2)
(n−1)
(n)
(a) Possible partitions of a DSM
(b) Legal sDSM partitions
Figure 6.9: The possible partitions of a DSM and the legal partitions of a sDSM.
An example of a sDSM can be seen in Figure 6.10(a) (with its associated digraph representation in Figure 6.10(b)) where the system representations from Figure 6.6(b) and Figure 6.8(a) are coupled together to form a two-level hierarchy. As can be observed I have introduced a more elaborate notation which makes it easier to distinguish the three different types of relations existing simultaneously in a sDSM: I have chosen to utilise (◦) as a symbol to denote couplings between levels, that is, these will be found only in “(n-1)” partitions. Furthermore I now use (×) to represent only intra-level interactions, and have
6.2. A HIERARCHICAL SYSTEM REPRESENTATION
177
introduced (4) to represent inter -level interactions – these interactions are both found only in “(n)” partitions. This requires a bit of explanation:
A consequence of the condensation procedure is that some information from a lower level in the hierarchy will not be identifiable in the higher level directly above, such as, what interactions actually “result” in the higher level interaction. These are the inter level interactions, which are found in the off-diagonal partitions of the lower level, as they represent interactions between subsystems with different supersystems. For instance, the interaction
6
3
in the lower level couples to the interaction
C4
C1
in the higher
level, because the supersystem of “6” is “C4” and the supersystem of “3” is “C1”. If the interaction
6
1
were added, there would be no change at the higher level because
the necessary interaction already existed – this information change at a lower level would therefore be lost to us if we regarded only the higher level. To make these couplings between levels more apparent I have used the fact that all interactions present at the higher level can each be mapped to a distinct lower level partition (and vice versa), and framed both in a green box. In this case the higher level is a 4 × 4-matrix and the lower level therefore has
4×4 partitions. To illustrate this in terms of digraphs consider the situation in Figure 6.11.
Here some interaction I exists between two systems a and b both present at the same level of the hierarchy. System a is a subsystem of system A and b is a subsystem of system B. The existence of I guarantees the existence of at least one interaction, I 0 , between A and B, and the existence of at least one interaction I 00 between some subsystem of a and some subsystem of b.
6 C4
2 C4
4 C3
5 C2
7 C1
3 C1
1 C1
C4
C3
C2
CHAPTER 6. MODELLING AN ARS
C1
178
C1 C2 C3 C4 1 C1 3 C1 7 C1 5 C2
× ××
◦ ◦ ◦
4 C3 2 C4 6 C4
◦
◦
×
◦ ◦
×× ×
4 4
4
×
×
(a) An sDSM showing a system comprising two hi-
(b) The system shown as a digraph
erarchy levels. Figure 6.10: An sDSM and a digraph representing the same two-level hierarchy system.
I’ A
B
I
a
b
I’’
Figure 6.11: The coupling of interactions in different levels of the system hierarchy.
The interactions found in the partitions positioned on the diagonal, in contrast, represent intra-level interactions, as the two subsystems involved have the same supersystem. As an example consider the interaction
1
3
both with supersystem “C1”. If we trace
6.3. A DYNAMIC ARS REPRESENTATION: THE EMERGENCE HIERARCHY 179 this interaction to the higher level we will find only the illegal reflexive “C1”-cell, indicating again that information from the lower levels are not always apparent in the higher levels. The coupling between the levels does not need much explanation as this has been covered previously and the use of (◦) to represent them is just a visual aid to make the coupling clearer in the sDSM. However, an important observation has to be made on their ordering. In Figure 6.10(a) the subsystems of the lower level are ordered such that subsystems with the same supersystem are grouped together. These groups are then ordered according to the ordering of the supersystems, thus creating a nice “flow” of (◦)’s down the level. In fact, if we consider the “(n-1)” partitions as a sequence of bit-patterns – where a cell containing (◦) corresponds to a “1” and an empty cell to a “0” – we can represent the pattern belonging to “1 C1” as “1000”, the bit-pattern belonging to “5 C2” as “0100”, and so on. The sequence of the subsystems in Figure 6.10(a) can thus be regarded as being in numerically descending order, that is, a total ordering under the relation “≥”. As discussed before this ordering is most useful for viewing the correlation between two neighbouring levels, as it clearly reflects the inter-level and intra-level interactions. In my research I have not come across a DSM representation handling a hierarchical system representation as explicitly as my sDSM does, and I therefore believe it to be novel in nature. However, references to more implicit hierarchical representations can be found where parts of systems (or tasks) are treated in separate DSMs (see for instance [Browning 2001]). Also the ideas of Simon [1962] regarding the nearly decomposable matrix bear some resemblance as it addresses hierarchies and system interactions, but again not as elaborately as the sDSM.
6.3
A dynamic ARS representation: The Emergence Hierarchy
As presented in Chapter 3, an ARS is a system that solves, resolves or dissolves a problem by utilising some autonomous or semi-autonomous robots as part of the solution. Taking a system-level view of this system it becomes evident that in order for an ARS to handle the required problem many different parts have to interact, coordinate, cooperate and adapt.
180
CHAPTER 6. MODELLING AN ARS
As discussed previously it also becomes clear that the physical robots are a central but not necessarily a dominating part of the puzzle as they often have to operate in concert with humans (a socio-technical context), have to interact with objects and obstacles, and possibly have to adapt to changes in the environment. All these components and interactions are therefore inherent parts of the system. In the last section we established a hierarchical system representation which can represent a system based on an organisation of its subsystems into different levels-of-abstraction, but we did not discuss how this organisation comes about. In an ARS design situation we are realising a physical system through an iterative process which means that when we start the process only parts of the system are known to us – it is therefore quite difficult to construct a complete system model let alone represent it in a hierarchy. We therefore need to acknowledge that we will be constructing (most of) the model at the same time as we are realising the actual system. This way we will be able to use the model to gain insights into the actual system and hopefully structure the design choices we make accordingly. This notion is shared by Ropohl [1982] who states that when constructing a system model: . . . a certain pre-understanding of the reality to be modelled is indispensable. On the other hand, the process of modelling is expected to supply additional understanding, so that the model building procedure is quite similar to the “hermeneutic circle”3 , which occurs at the interpretation of historical and poetical texts. [Ropohl 1982] That means that seen in the ARS context a good ARS system model is founded in good knowledge of what an ARS may comprise – that is robots, tasks, environments, socio-technical issues, dependability, ELS compliance, and so on. It also means that as the model is created new knowledge will surface and contribute to a better understanding of the system and hence an even better model – and (hopefully) a better system. In the next sections I will motivate the adaptation of the system hierarchy from the last section to suit our needs better in a design situation. The new hierarchy will model subsystems based on their emergent properties rather than on their functionality and will have a slightly different structure. It is thus a dynamic system hierarchy, and I have chosen to call it an Emergence Hierarchy inspired by Hitchins: 3
Accredited to the German philosopher Martin Heidegger, 1929. Source: Wikipedia
6.3. A DYNAMIC ARS REPRESENTATION: THE EMERGENCE HIERARCHY 181 In systems, where a number of complementary systems come together and interact such that they form a coherent whole with emergent properties, then a level of hierarchy is established. Should that coherent whole interact with a number of complementary wholes, and should they then form a set with emergent properties, then a ‘higher’ level of hierarchy would be identified, and so on. [Hitchins 2007, p21]
6.3.1
Emergent Properties
From the above it seems apparent that we can facilitate the design process by making the process of constructing the system model easier – but how do we do that? I purpose that instead of looking at only the functional structures and properties of subsystems we allow also for a higher level-of-abstraction by regarding them in terms of their emergent properties. As Hitchins [2007, p28] wrote: “A system is an open set of complementary interacting parts, with properties, capabilities and behaviours emerging, both from the parts and from their interactions, to synthesise a unified whole.” Hitchins therefore tightly couples the notion of system to that of emergent properties which, in fact, is quite common. He explains this coupling in a historical perspective: His [Ren´e Descartes] name is enshrined in the term Cartesian Reductionism – the concept he espoused, of breaking down big things into smaller, and hence more understandable things. If it was possible to understand and explain the smaller parts, then the whole could also be explained by bringing together the various part-explanations. Cartesian Reductionism could [however] not explain why some wholes possess capabilities, have properties, and behave in ways that were not evident from examination of their parts in isolation4 . This observation was labelled ‘emergence’. . . [Hitchins 2007, p3,p7] These thoughts have survived through the years (see [Ryan 2007] for an excellent review) as can readily be seen from the following description provided by Sommerville [2010]: The complex relationships between components in a system mean that a system is more than simply the sum of its parts. It has properties that are properties 4
Examples of such “wholes” could be brains and ant colonies each composed of relatively simple parts
– neurons and ants respectively – where the parts in isolation do not account for the vast complexity of the whole.
182
CHAPTER 6. MODELLING AN ARS of the system as a whole. These ‘emergent properties’ [Checkland 1981] cannot be attributed to any specific part of the system. Rather, they emerge only once the system components have been integrated. Some of these properties, such as weight, can be derived directly from the comparable properties of subsystems. More often, however, they result from complex subsystem interrelationships. The system property cannot be calculated directly from the properties of the individual system components. [Sommerville 2010, p269]
Sommerville points out that there are two types of emergent properties: 1) functional emergent properties, and 2) non-functional emergent properties. The former refers to the case when the purpose of the system only emerges after its components are integrated, for example, an ARS is only an ARS once all its parts have been assembled. The latter refers to behaviours of the system in its operational environment. Dependability criteria like reliability, safety, and security are examples of such emergent properties, as they depend on both the properties of individual components and their interactions, but also on the system as a whole. Kasser [2007, p17-7] extends Sommerville’s list by stating that emergent properties can be either intentional and unintentional, and that there seem to be three types: Undesired, serendipitous, and desired. Undesired emergent properties refer to functionality performed by the system that is undesired, also known as “side-effects”5 . Serendipitous emergent properties refer to functionality that is beneficial and desired once discovered, but that were not part of the original specifications6 . Desired emergent properties refer to the purpose of the system that can only be achieved by the combination of the subsystems and components. Examples are the functionality performed by the system, system reliability, system weight, system safety, and system useability. Kasser’s desired emergent properties therefore encompass both the functional and the non-functional emergent properties presented by Sommerville. Seen in this light, designing and modelling an ARS is thus about synthesising the system parts – Kline [1995, p114] refers to this bottom-up perspective as applying a “reductionistic view” – such that the system as a whole displays the desired emergent behaviour of solving the intended Problem while minimising the effects of undesired emergent properties. 5 6
. . . by some (often jokingly) referred to as “features”. . . . also by some referred to as “features”.
6.3. A DYNAMIC ARS REPRESENTATION: THE EMERGENCE HIERARCHY 183 However, as noted before, synthesising parts does not necessarily give the full explanation of what the parts will eventually do when they are assembled and start interacting. We therefore need to regard also the system from a top-down perspective – Kline [1995, p114] refers to this as applying a “synoptic view”. To exemplify: instead of presuming early in the design process that a certain navigational algorithm has to be used in conjunction with some sensor setup it is – from a synoptic point of view – wiser to first establish (in detail) what behaviour the system actually needs to display and later strive to obtain this behaviour through subsystem and component choices; the reason being that component choices may have wide impact on the system’s emergence as they are at the bottom of the hierarchy, and therefore directly or indirectly influence several higher level subsystems. A premature component choice may therefore prove to be fatal at a later point in time. As obvious as this may sound, it is my experience that even in best-practice scenarios in robotics, component choices are nevertheless often made prematurely or on faulty grounds. It seems that both the bottom-up reductionistic view and the top-down synoptic view have their advantages, which leads Kline [1995] to the following conclusion: . . . neither the top-down synoptic view nor the bottom-up reductionistic view can, by itself, supply reasonable understanding of systems with hierarchical structure incorporating interfaces of mutual constraint and multiple levels of control7 . [Kline 1995, p121] The consequence of the above is that no complete view of a system can be obtained from either view-point. If we regard this with respect to Figure 6.2 on page 167 the topdown synoptic view is analogous to viewing the systems from the outside (external view) and thus having the focus on emergent behaviours of the systems, and the bottom-up reductionistic view is analogous to viewing the systems from the inside (internal view) focusing on how those emergent properties and behaviours are obtained – both views are 7
Kline summarises “interfaces of mutual constraint” in what he calls Polanyi’s Principle, Part A: “In
many hierarchical structured systems, adjacent levels mutually constrain, but do not determine, each other” [Kline 1995, p115], and “multiple levels of control” in what he refers to as Polanyi’s Principle, Part B : “In hierarchical structured systems, the levels of control (usually upper levels) ‘harness’ the lower levels and cause them to carry out behaviours that the lower levels, left to themselves, would not do.” [Kline 1995, p119]. Kline claims that such hierarchical systems are very common and “. . . nearly ubiquitous in biological systems, human-designed systems, in communications, and thus also in sociotechnical systems.” [Kline 1995, p119]. This is true also for robotics as will become apparent later on.
184
CHAPTER 6. MODELLING AN ARS
indeed essential. In a design situation we therefore need a way of modelling subsystems in terms of their emergent properties in order to achieve the desired emergence. As Hitchins puts it: . . . the key to achieving desired emergence is to identify the essential pattern of coupled processes in system design that would result in emergence, and to ensure in any subsequent creative activities that the links in the pattern are not disturbed or distorted [Hitchins 2007, p23]. What exactly emergent properties and emergent behaviour are can be interpreted – and has been interpreted – throughout literature, where explanations have ranged from divine intervention to “a difference between global and local structure” [Ryan 2007]. The reader is free to choose whatever definition pleases but to keep things “down to earth” I choose to regard them as “simple” properties and behaviours of a system, possibly explainable by our inability to model the system properly due to, perhaps, its nearly decomposable nature8 [Simon 1962]. A servo system, for instance, has in my terminology an emergent property of being a system which tracks an input control signal. A motor, an encoder and a power control unit could be wired and programmed to exhibit this emergent property, but if wired differently, they might not. In this case the components would have identical individual functionality but the emergent property would be lost9
6.3.2
The Emergence Hierarchy
As we saw in Section 6.2 it is possible to represent a system using a hierarchy with subsystems and interactions at several levels. This representation may be sufficient when we want to show and explain an existing system, but as stated in the introduction to this section we will actually be constructing the system model as part of the design process. How can we facilitate that and at the same time make it an asset to the design process itself? In the following sections I will address several issues that are important in this respect and at the end present both a graphical and a sDSM representation of the modified system hierarchy, the Emergence Hierarchy (EH). 8
A nearly decomposable system is a system where the interactions among the subsystems are weak,
but not negligible [Simon 1996, p197], that is, intra-component interactions are often stronger than intercomponent interactions. 9 Ryan [2007] refers to this type of emergent property as weak.
6.3. A DYNAMIC ARS REPRESENTATION: THE EMERGENCE HIERARCHY 185 6.3.2.1
Several Supersystems
The previous system hierarchy enforces â&#x20AC;&#x201C; by definition â&#x20AC;&#x201C; the systems view of subsystems being separate entities that interact, each again comprising separate subsystems that interact. What separates these independent subsystems is their boundary, and as established in Section 6.1, these boundaries are entirely determined by the system modeler though some cognitive filter. But what if the chosen cognitive filters are not appropriate? What if they are too big? What if they are too small? In a design situation dealing with emergent properties the boundary definitions play an important role, as they reflect how we perceive these properties, and a wrong definition may, in the worst case, require a redefinition of several subsystems both up and down the hierarchy in order to enforce the subsystem separation. To minimise the risk of such situations occurring I purpose to augment the hierarchical system model by allowing dynamic boundaries such that a subsystem may have several supersystems. Let me exemplify: Consider a subset of the potential subsystems of an ARS represented at four different levels-of-abstraction in a four-level hierarchy in Table 6.1.
Level 1
Subsystems The overall system model capturing the RTE-components, sociotechnical components, dependability issues, ELS compliance, etc.
2
Localisation system, safety system, motion system, energy system, environment system, organisational system, etc.
3
Servo system, mechanical base, computer system, control system, operator team, etc.
4
Electronics, mechanical components, software subroutines, operators, disablers, enablers, commuters, motors, sensors, batteries, GPSs, cameras, etc.
Table 6.1: An example of a subset of subsystems in an ARS at four different levels-of-abstraction.
Many of these subsystem names should be familiar to people working in robotics but as
186
CHAPTER 6. MODELLING AN ARS
with most disciplines, an exact consensus on what a particular name holds may be up for interpretation. My choice of level-of-abstraction for each level may also be discussed, but what is important to notice is that though I can argue that the subsystems on each level are separate (as I determine what emergent properties they must have), the subsystems on the next level down may contribute to the emergence of several of the higher level subsystems. Take, for instance, “motion system” on level 2: the name was chosen to indicate that its emergent behaviour is to handle the motion parts of the system, which, when we look at level 3, may perhaps be realised through some parts of both the “servo system”, the “mechanical base”, the “computer system”, and the “control system”. However, the emergent properties of the “safety system”, may also depend on both the “mechanical base”, the “computer system”, and the “control system”, but also on the “operator team”. Now, this would not be possible if I had followed the previous definition of system and the hierarchical structure of Figure 6.3, so one may argue that the reason for this coupling is due to a bad choice of boundaries – and perhaps subsystem names – as the explanation obviously is that though the “control system” may contribute to both it will in fact do so through entirely different parts. These parts, however, will only be apparent when we determine what level 4 subsystems it comprises. The dynamics resulting from this augmentation will provide the ARS designer with a more intuitive way of modelling the system as 1) common terminology used in robotics may be applied more readily, and 2) it will quickly become apparent if inconsistencies exist across levels. I will address these issues further in Chapter 7 where I present the ARS Design Tool which utilises these assumptions. 6.3.2.2
Levels and Scope
Each level of a system hierarchy represents the entire system using the emergent properties and behaviours produced by the subsystems and interactions found in that particular level. That means that no matter how we choose our cognitive filters and boundaries for the subsystems of a certain level we have to make sure that the entire system can be fully represented at that exact level-of-abstraction. One way of ensuring this – and at the same time maintain a coherent system representation – is to make sure that the scope of all subsystems and interactions present in a level are comparable. To illustrate this point, it may not make much sense to place a subsystem comprising only screws at the same level as an
6.3. A DYNAMIC ARS REPRESENTATION: THE EMERGENCE HIERARCHY 187 abstract “navigational system” as they represent entirely different spatial scopes. However, if a “navigational system” indeed needs to interact directly with a screw-subsystem, it may be advisable to make representations of the screw-subsystem at several levels throughout the hierarchy to maintain structural coherency. The task of determining how many levels are needed and at what level-of-abstraction they have to be to sufficiently represent a given system is not easy and may, in fact, not even be static. It is easy to imagine a hierarchy being dynamically expanded at the lower levels as the design process progresses (and more details are uncovered), but I do not see any problems in adding or removing intermediate levels either – as long as they make sense. From the example ARS hierarchy in Table 6.1 – and to support the systems view employed in this dissertation – it makes good sense, however, to make an initial separation between the more abstract and conceptual system levels, and the more implementation oriented levels. The former will ensure that subsystems of more abstract nature but still with clearly defined emergent properties, such as “safety system” or perhaps “red-ball-finder system”, can be specified without the need to worry about how they should actually be implemented. The latter on the other hand ensures that subsystems comprising actual components and component clusters/modules can be specified to the required level-of-abstraction. To support these notions I have divided the systems hierarchy into two segments: one of concepts, the concept-segment, and one of implementations, the implementation-segment, where the former is placed higher in the hierarchy than the latter. To make a clear levelof-abstraction distinction between the two segments I separate them by a difference in scope such that for all subsystems in the concept-segment the narrowest scope, SC,min ,
is always greater than the subsystems with the broadest scope in the implementationsegment, SI,max . That is: SC,min > SI,max
(6.2)
The segment position of a subsystem thus explicitly dictates its nature such that, for example, a “motor” placed in the concept-segment may be an abstract actuating element, where a “motor” placed in the implementation-segment represents some physical motor entity. With respect to Table 6.1 Level 1 and Level 2 would constitute the Conceptual Segment and Level 3 and Level 4 the Implementation Segment.
188
CHAPTER 6. MODELLING AN ARS
6.3.2.3
A Directed Acyclic Graph (DAG)
Modifying the graphical representation of the system hierarchy to reflect the modifications presented in this section is fairly straightforward. An example showing a four level Emergence Hierarchy can be seen in Figure 6.12, where subsystems belonging to the concept-segment are drawn as ellipses using dashed lines, and subsystems belonging to the implementation-segment are draw as solid-line boxes. The links between the systems are drawn using open-arrows in the direction from sub-to-super system. As subsystems now may have several supersystems the structure is no longer a digraph but is more properly
Implementation Segment
Concept Segment
known as a Directed Acyclic Graph – a DAG.
Figure 6.12: A Emergence Hierarchy of systems and components represented using a DAG structure.
6.3.2.4
The Emergence Hierarchy sDSM
The Emergence Hierarchy can be readily represented using an sDSM as the only modification is due to the possibility of several supersystems – in an sDSM this can be handled by just adding the extra supersystem couplings (◦) in the appropriate places. Figure 6.13 shows a four-level EH as both a sDSM and as a DAG.
sys2 sys3 sys4 sys5 sys6 sys7
◦ ◦ ◦
sys8
sys10 sys11
sys11
sys10
sys8
sys9
◦ ◦◦ ◦ ◦◦◦ ◦
sys7
sys6
◦
sys9
sys5
sys2
◦◦ ◦ ◦◦ ◦
sys4
sys1
sys3
sys0
189
sys1
ARS ARS
sys0
6.4. POEM
(a) An sDSM showing an EH comprising four
(b) The EH shown as a DAG
hierarchy levels. Figure 6.13: An sDSM and a DAG representing the same four-level emergence hierarchy.
6.4
POEM
The RTE-representation presented in Section 3.1 is an ARS system-view in its own right, but being a model that separately addresses the robots, the task, and the environment, it does not explicitly facilitate thinking in broader systems terms when we design an ARS as it advocates the robots as a separate – but coupled – system entity. To allow a more abstract or conceptual way of regarding ARSs it is important to have a model that still captures the essence of the ARS as presented in Chapter 3 but does not from the beginning constrain us to think in terms of “having to make a robot”. Such a model will be an asset in an ARS design situation as it will allow for a much wider span of design ideas – it will therefore also provide an important first step in devising the ARS Design Tool presented in Chapter 7. In terms of our Emergence Hierarchy such a model will naturally find its place at the top in the Concept-segment. If we number the EH levels such that the top-most level – comprising a sole system: the ARS – is System-level 0, the next level down System-level 1, the next level down System-level 2, and so on, we will find this model at System-level 1. The model must therefore comprise all subsystems and interactions at this level – hence-
190
CHAPTER 6. MODELLING AN ARS
forth denoted as system-level â&#x20AC;&#x201C; as it needs to conceptualise the general properties and behaviours of all ARSs. It is therefore imperative to conceive a subsystem set that is as complete as possible as it must be able to handle systems with any kind of architecture and functional model, which makes it necessary to find the basic building blocks which any ARS comprises, that is, we are looking for a reference model. Much previous work can be found in literature on architectures, functional models, and behaviour models for autonomous robots [Brooks 1986; Pirjinian 1997; Arkin and Balch 1997; Bonasso et al. 1997; Arras et al. 2003; Durrant-Whyte 2005], but these models all apply to other levels of abstraction than the one we are seeking, and often address the issues from a more robot-centric view-point. What we are looking for here is a reference model able to grasp the socio-technical aspects of ARSs as well as the purely technical aspects. However, the referenced literature has served as great inspiration, and as the aim is to provide a reference model able to handle all types of ARSs, it also means that these models must be allowed as part of an ARS â&#x20AC;&#x201C; an example of this will be given in Section 6.4.3.3. I have identified four essential system-level subsystems to meet the criteria presented above: a Mobility subsystem, an Orchestrator subsystem, a Perception subsystem and an Entity subsystem. Names are chosen to avoid overlap with existing architectures as far as possible while still being intuitively reasonable. The flow of information between these subsystems can be seen in Figure 6.14 where, again, an arrow tail indicates an information source and an arrow head the information sink. I use the acronym POEM to denote this system-level reference model. Please note that these four subsystems and their mutual interactions do not necessarily define a universal set of system-level subsystems but have, however, proven so far to be a sufficient set: I have not yet been able to conceive an ARS that cannot be described using them. I therefore do not claim POEM to be unique, as other representations may be equally good; nevertheless it is a novel contribution. The subsystems of POEM and their mutual interactions are described individually in the following subsections from Section 6.4.1.1 to Section 6.4.1.5, and Section 6.4.3 provides a few examples to illustrate its validity.
6.4. POEM
191
Autonomous Robotic System Entity subsystem Perception subsystem
Orchestrator subsystem
Mobility subsystem
Figure 6.14: The system-level subsystems of an ARS comprising the Mobility, the Orchestrator, the Perception, and the Entity subsystems, along with the flow of information between them. I term this reference design POEM.
6.4.1
The POEM subsystems and Interactions
6.4.1.1
The Mobility subsystem
Physical manifestations able to produce orchestrated motion and actions in some environment are required in an ARS. They can be anything orchestratable like robot platforms, actuated robot tools or humans, as long as they have the ability to produce controllable dynamic motion. I term this set of orchestratable and physical platforms the Mobility subsystem. 6.4.1.2
The Orchestrator subsystem
The Mobility subsystem of the ARS needs to move purposefully about in the environment in some structured, semi-structured or unstructured manner and carry out required actions. That implies that some Orchestrator subsystem, able to dictate and/or coordinate the required motions and actions, must be part of the ARS. Note that no decision is made as to the final physical location of this subsystem â&#x20AC;&#x201C; it may well be a human operator guiding a robot along on a leash (in which case both the human and the leash are part of
192
CHAPTER 6. MODELLING AN ARS
the subsystem) or a software component residing on a fully autonomous lawn mower – or both. The only assumption made is that the subsystem must exist and provide the means of orchestrating the motions and actions of the mobility subsystem. Other examples of components that may be found as part of an Orchestrator subsystem are rail tracks or walls. As individual components they may not necessarily be part of this subsystem but depending on their role in the ARS they may indeed be. If a rail track is used to guide the motion of an autonomous train that otherwise has no means of navigation, the rail tracks are regarded as part of the Orchestrator subsystem. If, on the other hand, the tracks are merely part of the ground structure they may at best be regarded as minor obstacles and thus part of another subsystem. Likewise with a wall. A wall may be a mere obstacle that should be avoided but if a wall-following guidance system is installed on a mobile robot the wall becomes an essential part of its motion – the wall guides the motion of the robot and is therefore part of the Orchestrator subsystem. 6.4.1.3
The Perception subsystem
In order for the Orchestrator subsystem to provide proper orchestration of the Mobility subsystem it needs information on its whereabouts, actions and status but also on the whereabouts, actions and status of other ARS entities – a Perception subsystem is therefore required. The function of this subsystem is therefore to obtain all relevant knowledge about all relevant entities in the ARS and to make it available in what ever form the Orchestrator may need it. In the final realisation of the ARS this may for instance include the location, attitude, velocity and acceleration of the physical platforms, and may also provide information on where obstacles, people, landmarks or other ARS entities of interest are located. Again, no assumptions on where this subsystem is physically located and how it is realised is made. It may well be an operator scouting the environment and shouting at the top of her lungs where all objects can be found or it may be the result of the interactions of a complex concert of electronic sensors. 6.4.1.4
The Entity subsystem
The Entity subsystem is the last subsystem of POEM. It contains static and dynamic entities that the Orchestrator subsystem is not directly responsible for orchestrating but
6.4. POEM
193
must manipulate or avoid through the Mobility subsystem. This may, for example, be the components that the ARS is responsible for transporting from location A to location B; humans obstructing the motion of the mobility system; or trees, walls, tables or other entities in the surroundings that are to be interacted with or avoided entirely. It may be argued that the Entity subsystem does not in itself conform to the definition of a system as being composed of interacting parts. It may indeed be the case that it in reality is a collection of static objects not (seemingly) influencing each other in any way but only interacting with other subsystems, essentially making them part of these subsystems. However, it may also consist of entities in complex interaction as for example pedestrians on a pavement who all move independently but continuously adapt to the position and gestures of other pedestrians – this indeed conforming to the definition of a system. A decision has therefore been made to accommodate both cases by keeping the notion “system” as there is a much higher probability of its entities actually interacting than not. In the extreme non-interacting case, the subsystem can simply be substituted by entity components without loss of generality. 6.4.1.5
The POEM interactions
The interactions/information flow among the POEM subsystems are based on the definitions of the subsystems but also guided by common robotics sense. Twelve interactions are possible among four subsystems but only five have been chosen. In Table 6.2 the motivation for the inclusion or exclusion of each interaction is given. Observing POEM as a whole and not just as individual subsystems and interactions, a few observations can be made: In Figure 6.15 one large loop involving all four subsystems (outer-loop) and one smaller (inner-loop) involving all but the Entity subsystem, can be observed. The latter can be seen as expressing how the motion of the Mobility subsystem is coordinated and executed, and the former as expressing the system impact of changes to the Entity subsystem caused by some influence of the Mobility subsystem. The exact interpretation of these couplings can, however, not be determined until lower level subsystems have been considered, because lower level subsystems and their interactions define the precise interpretation of the higher levels10 . However, I firmly believe that 10
“Only by looking at the next hierarchy up, it is possible to determine just what the current whole
systems emergent properties should be. . . ” [Hitchins 2007, p21]
194
CHAPTER 6. MODELLING AN ARS
S
D
Motivation
O
M
As O is responsible for orchestrating the motion of M.
M
O
As O orchestrates M and not vice versa, this interaction does not exist.
M
E
As M interacts with E in a physical way.
E
M
It may be argued through physics that this interaction should be present when the opposite is. However, I do not perceive the previous interaction as necessarily being on the level of force but more on the level of “picks-up”, “bumps-in-to” or “avoids”. If a more Newtonian interaction is required it is fully justified to add the interaction.
M
P
As P needs input from M to provide the necessary information to O.
P
M
As M only reacts to input from O, information directly from P does not make sense. However, it may be argued that this interaction is justified in systems where effectors act directly on sensor input, as in for example Braitenberg Vehicles [Braitenberg 1984], but in such cases I still see O as performing an orchestrating function, though possibly only being a wire on the component level.
E
P
As P needs input from E to provide the necessary information to O.
P
E
If P were to interact with E it would imply some form of orchestration of E for this information to serve a purpose. If E were to be orchestrated it would imply that it was actually M. As this is not the case the interaction does not exist.
P
O
As O needs information from P in order to orchestrate M.
O
P
If O were to provide information to P it would be processed by P and sent back to O. As this does not make sense the interaction does not exist.
O
E
As orchestration of E violates the definition of E, the interaction does not exist.
E
O
As O is only able to process information from P any information from E will have to go through P. The direct link would therefore not make sense.
Table 6.2: The motivation for including the five POEM interactions from Figure 6.14 and the reasons for not including the other seven possibilities (shown with gray background). The system names are abbreviated to their first letter for clarity. S designates the source of the interaction and D the destination.
6.4. POEM
195
this canonical abstract system model makes good sense in terms of how I perceive the behaviour of an ARS: a system performing a task through interaction with some environment.
Autonomous Robotic System Entity subsystem Perception subsystem
Orchestrator subsystem
Mobility subsystem
Figure 6.15: The two inherent loops of POEM.
6.4.2
The limited scope of POEM
POEM, is as addressed in the introduction to this section, a system-level model naturally placed at System-level 1 in the Emergence Hierarchy and is not meant directly to represent levels further down the hierarchy. But what about these levels â&#x20AC;&#x201C; how do we handle them? It is clear that in order to address subsystems and components at scopes smaller than POEM s, we may need additional models that are representative of these levels. This would greatly help the design effort as we could represent, for instance, subsystems and components often found in ARS systems like the examples presented in Table 6.1 on page 185. To address this issue I would suggest placing a more domain specific functional model at the lowest level of the concept-segment, for instance, the model presented in Figure 6.22 on page 202, if autonomous land vehicles are addressed; some other model if another type of system is addressed. On the highest level of the implementation-segment a more component oriented model, like the one presented in Figure 2.6 on page 44, could be used, and the two models tied together across the boundary. This would create an partial interface between
196
CHAPTER 6. MODELLING AN ARS
the two segments and provide a more domain specific hierarchy — “partial” because neither the domain specific model nor the component specific model may fully be able to handle aspects such as ELS compliance or socio-technical issues. This interface layer would then constitute a reference context for the design process as the conceptual-segment will be represented at the top by POEM and at the bottom by a domain specific model. A direct benefit of this approach is that subsystem names at the conceptual-level may, to some extent, be extracted directly as we may infer the coupling. This appears to be a fruitful further development of the POEM strategy that could be pursued in future work.
6.4.3
Examples of applying POEM
The aim for the POEM system-level view is for it to be able to contain all the components of any working ARS. That it in fact does so is obviously not straightforward to prove and it is therefore necessary to rely on evidence obtained from its practical usage. In this section a few initial “tests” of the POEM system-level view will be presented. 6.4.3.1
Example I: Autonomous Robot vs. Semi-Autonomous Robot
Consider an ARS where some autonomous robot is realised through the interactions of both the Mobility, Orchestrator and Perception subsystems. That indicates that the robot is in some way capable of self-orchestration based on local sensor input – this could for instance be a mobile robot comprising a controller based on the Subsumption architecture taking input from some range sensor mounted on the chassis. It could also be an autonomous vacuum cleaner implementing some coverage algorithm based on bump-sensor input. Consider now another autonomous robot realised in the same way except for the Orchestrator subsystem. Such a robot might still have some simple locally implemented command execution scheme but would largely rely on orchestration by, for instance, an external computer or a human operating a remote control (in which case “semi-autonomous robot” may be a more accurate definition). POEM dictates that the Orchestrator subsystem must be present in an ARS, in this example in a robot-external subsystem. The two examples can be visualised as in Figure 6.16, where the POEM subsystems are represented as sets projected onto the components. It can be observed that the POEM subsystems comprise the entire ARSs.
6.4. POEM
197
Autonomous Mobile Robot
Mobility
subsystem
Central Mission Controller
Orchestrator subsystem
Mobile Robot
Mobility
Orchestrator subsystem
Walls
Entity
Perception
subsystem
subsystem
Central Mission Controller
Semiâ&#x2C6;&#x2019;Autonomous
subsystem
ARS Operator
ARS Operator
Perception subsystem
Walls
Entity
subsystem
Figure 6.16: Top: Illustrates how an ARS comprising an autonomous robot may relate to the four system-level subsystems. Bottom: Illustrates how an ARS comprising a semi-autonomous robot may relate to the four system-level subsystems.
6.4.3.2
Example II: The TransPot ARS
The previous example relates POEM to some low-detailed component level in the Emergence Hierarchy and illustrates how different types of ARSs at that level may relate to it. Now, the example in Figure 6.17 shows the relation between POEM and the mediumdetailed component-level view of the TransPot system from Figure 2.11 page 50. It can immediately be seen that all components can be contained within at least one system-level subsystem indicating that POEM is sufficiently large to encompass the entire system. Let us take a closer look at the components contained within each subsystem. In Figure 6.18 the Mobility subsystem of the TransPot system is shown and Figure 6.19 shows the Orchestrator subsystem.
198
CHAPTER 6. MODELLING AN ARS
External Processing
Database
Job planning
RFID map
Path planning
Middleware
Communication
Wireless communication
Middleware
TransPot control
Mobility subsystem
Tool control
Motion control
Orchestrator
Processing
subsystem
Perception subsystem
Motor control
Motor control
TrackFinder
Drivers
Driver
Driver
Driver
Driver
Driver
I/O
Grabber
RS232
Counter
DAC
DI
Interfaces
Interface
Interface
Interface
Interface
Interface
Interface
Interfaces
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Sensors
Motors
Chassis
Troughs
Conveyors
Sensors and Actuators Sun−screen
Mechanical Platform
Lines
Light
Environment
Wheels
RFID tags
Soil/Concrete Mypex
Obstacles
Driver
Drivers
ADC
Driver
DI
Dock
Driver
Driver
DAC
Counter
DO
Interface
Interface
Interface
Encoder
DC/DC
Sensor
Batteries
Conveyor
Pots
Operator
Charger
Entity subsystem
Figure 6.17: The component-level view of the TransPot system superimposed with the four system-level subsystems.
External Processing
Database
Job planning
RFID map
Path planning
External Processing
Database
Job planning
RFID map
Path planning
Middleware
Communication
Middleware
Communication
Wireless communication
Wireless communication
Middleware
Middleware
TransPot control
TransPot control
Mobility subsystem
Tool control
Motion control
Orchestrator
Processing
Motor control
subsystem
Motor control
Motor control
TrackFinder
Drivers I/O Interfaces Sensors and Actuators Mechanical Platform
Environment
Tool control
Motion control
Processing
Driver
Driver
Driver
Driver
RS232
Counter
DAC
DI
Interface
Interface
Interface
Interface
Interface
Interface
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Chassis
Sun−screen
Light
Wheels
Lines
Motor control
TrackFinder
Driver
Grabber
RFID tags
Soil/Concrete Mypex
Obstacles
Driver
ADC
Dock
Drivers
Driver
DI
Driver
Counter
DO
Interfaces
Interface
Interface
Interface
Sensors
Motors
Troughs
Conveyors
Pots
Encoder
Drivers
Driver
DAC
I/O DC/DC
Sensor
Batteries
Interfaces Sensors and Actuators Mechanical Platform
Conveyor
Operator
Charger
Environment
Driver
Driver
Driver
Driver
Driver
Grabber
RS232
Counter
DAC
DI
Interface
Interface
Interface
Interface
Interface
Interface
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Chassis
Sun−screen
Light
Wheels
Lines
RFID tags
Soil/Concrete Mypex
Obstacles
Driver
ADC
Dock
Drivers
Driver
DI
Driver
Driver
DAC
Counter
DO
Interfaces
Interface
Interface
Interface
Sensors
Motors
Troughs
Conveyors
Pots
Encoder
DC/DC
Sensor
Conveyor
Batteries
Operator
Charger
Figure 6.18: The Mobility subsystem of
Figure 6.19: The Orchestrator subsystem of
the TransPot system
the TransPot system
The Mobility subsystem is the largest (in terms of number of components) of the four subsystems. It is responsible for providing the Orchestrator subsystem with something to
6.4. POEM
199
orchestrate and it therefore contains the parts that constitute the robot (the TransPot), its pot carrier tool, the conveyor belt in the production facility, the operator (who may be called to handle a recovery procedure after an emergency stop), the white lines on the ground, the RFID tags, (sun) light, the sun-screen and enough communication layers to enable orchestration. If the white lines, the sun light to illuminate them and the sun-screen to block-out fake lines together with the RFID tags had not been regarded as part of the Mobility subsystem, the TransPot would not be able to locomote to solve the required task. Instead it would only be able to conduct low-level motion commands – hence the inclusion of the components. Note that it is the tight coupling between the motion of the TransPot and the RFID tags IDs that justifies the inclusion of the RFID tags: the TransPot will only work as long as the encountered RFID tags IDs are correct – if the TransPot encounters a wrong RFID ID it will stop and call for assistance from an operator. The Orchestrator subsystem contains all parts that facilitate the orchestration of the Mobility subsystem. This includes the higher level planning components (Job- and Pathplanning), the communications layers, the various control layers ranging from “TransPot control” to low-level motor control, again the operator (as she is responsible for the application level orchestration), the white lines and the RFID tags. Four things in particular spring to mind: 1) why are the communication layers included? 2) why are all the control layers included? 3) why are the lines included? and 4) why are the RFID tags included? The communication layers shared with the Mobility subsystem enables the communication between the two. If only one of them had communication components, orchestration would not be possible and locomotion could not be achieved. The control layers are shared with the Mobility subsystem as they are, per definition, part of the orchestration. Had the TransPot been a platform where the low-level velocity control was distributed to an external source (maybe through a network connection), these components would not have been part of the Mobility subsystem. But as the TransPot is capable of some low-level control on its own they are indeed part of the Mobility subsystem. The lines are regarded as being part of the Orchestrator subsystem as they form orchestration by imposing a global constraint on the motion of some parts of the Mobility subsystem – namely the TransPot. The RFID tags are part of the Orchestration subsystem as they facilitate the generation of a sequence of RFID IDs (path planning) which functions as a target route for the TransPot. It may be argued that it is only the actual ID of the RFID tags that are part of
200
CHAPTER 6. MODELLING AN ARS
the Orchestrator subsystem as the physical RFID tag is a mere carrier of the information. Indeed this is correct, but as the level of detail of the TransPot system encompass only the notion “RFID tags” this is seen as including both the physical devices and their IDs. In Figure 6.20 the Perception subsystem of the TransPot system is shown and Figure 6.21 shows the Entity subsystem.
External Processing
Database
Job planning
RFID map
Path planning
External Processing
Database
Job planning
RFID map
Path planning
Middleware
Communication
Middleware
Communication
Wireless communication
Wireless communication
Middleware
Middleware
TransPot control
TransPot control
Tool control
Motion control
Tool control
Motion control
Processing
Processing
Perception subsystem
Motor control
Motor control
Motor control
TrackFinder
Drivers
Driver
Driver
Driver
Driver
I/O
Grabber
RS232
Counter
DAC
DI
Interfaces
Interface
Interface
Interface
Interface
Interface
Interface
Interfaces
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Sensors
Motors
Chassis
Troughs
Conveyors
Sensors and Actuators Mechanical Platform
Environment
Sun−screen
Light
Wheels
Lines
Motor control
TrackFinder
Driver
RFID tags
Soil/Concrete Mypex
Obstacles
Driver
ADC
Dock
Drivers
Driver
DI
Driver
Counter
DO
Interface
Interface
Interface
Pots
Encoder
Drivers
Driver
DAC
DC/DC
Sensor
Batteries
Driver
Driver
Driver
Driver
Driver
I/O
Grabber
RS232
Counter
DAC
DI
Interfaces
Interface
Interface
Interface
Interface
Interface
Interface
Interfaces
Camera
Tag reader
Encoder
Motor
Bumbers
Gyroscope
Sensors
Motors
Chassis
Troughs
Conveyors
Sensors and Actuators Mechanical Platform
Conveyor
Operator
Charger
Environment
Sun−screen
Light
Wheels
Lines
RFID tags
Soil/Concrete Mypex
Obstacles
Driver
Drivers
ADC
Driver
DI
Dock
Driver
Driver
DAC
Counter
DO
Interface
Interface
Interface
Pots
Encoder
DC/DC
Sensor
Conveyor
Batteries
Operator
Charger
Entity subsystem
Figure 6.20: The Perception subsystem of
Figure 6.21: The Entity subsystem of
the TransPot system
the TransPot system
The Perception subsystem is responsible for knowing the whereabouts, actions and status of the Mobility subsystem and the Entity subsystem. As this information is collected and processed on the TransPot itself by the “Motion control” and “Tool control” components they, together with drivers, I/O, interfaces and sensors, constitute most of the Perception subsystem. Another part is (again) the operator as she has the ability to obtain information about the system and pass it on to the Orchestrator subsystem – which may be in the form of herself – in order for it to take action. The Entity subsystem contains the entities that the Orchestrator subsystem is not directly responsible for orchestrating but that may interact with or be manipulated by the Mobility subsystem. In the TransPot system case the pots, the dock, obstacles, the ground, the RFID tags, the lines, the sun-light and the sun-screen are all parts of the Entity subsystem. Most curious may be the sun-light and the sun-screen. The sun-screen being mounted
6.4. POEM
201
on the physical platform and the sun-light being inherently intangible, are part of the Entity subsystem because their presence is needed in order for the vision system to be able to detect the lines on the ground. They are, however, not orchestratable in any way but are nevertheless important for the Mobility subsystem to function â&#x20AC;&#x201C; hence their inclusion.
Figure 6.17 illustrates, that POEM is sufficient in capturing the components of a whole ARS, that is, it is possible to track each component up the Emergence Hierarchy to one or more of the POEM subsystems through the (in this example undefined) intermediate levels. That also means that the manual projection of the POEM subsystems is not based solely on knowledge derived by observing the component level, but from intimate knowledge of how that particular ARS operates. In a design situation where a new ARS has to be devised it is important to capture this knowledge in the different levels of the Emergence Hierarchy as the design process progresses. This way the projection of the various levels onto lower levels can be carried out automatically based on the interactions and validated against the system specifications and checked for inconsistencies.
6.4.3.3
Example III: A functional element model for land vehicle systems
In [Durrant-Whyte 2005] a schematic of the relationships between the five key functional elements of an Autonomous Land Vehicle (ALV) system is presented. The schematic is reproduced in Figure 6.22.
202
CHAPTER 6. MODELLING AN ARS
Prior maps, goals, values
Planning
External Localisation Sensors
Internal Odeometric Sensors
Communication
Localisation
Navigation
External Environment Sensors
Mobility
Platform
Figure 6.22: A schematic of the relationship between different functional elements of an autonomous land vehicle system (ALV) [Durrant-Whyte 2005].
Applying POEM to the schematic in Figure 6.22 incorporating the descriptions of the elementsâ&#x20AC;&#x2122; functional properties the schematic in Figure 6.23 is produced.
Orchestrator subsystem Prior maps, goals, values
External Localisation Sensors
Internal Odeometric Sensors
Communication
Entity subsystem
Planning
Localisation
Navigation
External Environment Sensors
Perception subsystem
Mobility
Mobility subsystem
Platform
Figure 6.23: POEM superimposed on the ALV component model.
The Localisation element and the three sensor elements of the ALV are naturally part of the Perception subsystem as they contain the necessary information on the whereabouts of the mobility system.
6.4. POEM
203
The Planning, Navigation and Communication elements along with the “Prior maps, goals, values” are part of the Orchestrator subsystem as they are responsible for orchestrating and communication with the mobility subsystem. Also parts of the Mobility element are part of the Orchestrator subsystem as some of its lower-level control aspects may be regarded as actually having an orchestrating function. The Mobility element and the platform elements are part of the Mobility subsystem along with parts of the Communication element. The latter is included as communication in an ALV system is described as: “Communication provides the link between the vehicle and any remaining elements of the global system, including other vehicles and operators” [Durrant-Whyte 2005]. It has thus a broad definition which justifies its inclusion in the mobility subsystem. The ARS’s entity subsystem contains only the Communication element as no direct indication of other manipulatable entities or environments are directly part of the ALV model. This is, however, not surprising as the ALV model is a functional model of the elements of an ALV and does therefore not employ an explicit systems view encompassing all aspects of its containing robotic system. The only reason for including the Communication element is entirely due to its broad description as presented above which includes the notion “remaining elements in the global system” which may indeed include parts of the entity subsystem. As can be seen in Figure 6.23 the ALV model can be completely contained within the ARS system-level view. That means that the possibility exists for an ARS design process to result in an ARS utilising the ALV functional model. This does not in itself validate the system-level view but merely states that a necessary “path” between the two exists. If this had not been the case, the ARS system-level view would be faulty as the ALV model has indeed been employed in several real-world autonomous robotic systems. 6.4.3.4
Example IV: The Weazel Ball
As a last example let us focus on a simple real-world case. In Figure 4.11 on page 111 the RoboMop robotic floor duster was presented, and as I pointed out in the accompanying discussion, I believe it to be just as much a cleaning robot as a Roomba which, in turn, qualifies it to be a part of an ARS. As the element which offers “Smart Navigation Technology: Senses walls and objects, automatically changing direction” (printed on the shipping
204
CHAPTER 6. MODELLING AN ARS
box) is the mechanical ball, let us for the sake of simplicity disregard the plastic frame and the electro-static dust pad, and just concentrate on the ball alone. In the initial development phases of RoboMop the ball Torbjørn Aasen used was a commercially available product resembling (and perhaps, in fact, being) the Weazel Ball shown in Figure 6.24. The Weazel Ball has a toy weasel attached to it and when the ball moves randomly about the room it appears as if the weasel is trying to catch the ball – very amusing to watch and apparently a source of much frustration for cats and dogs. Does this ball in concert with its surroundings qualify as an ARS?
Figure 6.24: The Weazel Ball (http://www.weazelball.com/).
In a simple representation – at a fairly broad scope – we can regard the ARS system as comprising the Ball itself, the Floor on which it rolls, and the Obstacles in the surroundings, that is, walls, people, dogs, cats, furniture, and other kinds of material obstructing the motion path of the ball causing it to change direction. At this system scope we can argue that the only interactions present are the mutual interactions among the Ball and Obstacles (force), and among the Ball and the Floor (force). If we map POEM to this construct it yields the result shown in Figure 6.25.
6.4. POEM
205
Floor
Entity subsystem
Obstacles Orchestrator subsystem
Perception subsystem
Ball Mobility subsystem
Figure 6.25: POEM mapped to a simple model of the Weazel Ball.
The Ball is naturally part of the Mobility subsystem as the Ball is the moving object “navigating” the surroundings. However, it is also part of both the Perception and the Orchestrator subsystems as the force encountered upon physical contact with Obstacles is mechanically perceived and results – again mechanically – in an orchestration that leads to a change in motion. The Obstacles are part of the Orchestrator subsystems as it is, in part, the Obstacles that determine where the Ball should go next, implemented by the type of contact point and material of the Obstacles – colliding with a cat will most definitely result in a different orchestration than colliding with a solid wall. However, the Obstacles are also part of the Entity subsystem as they may also comprise objects that obstruct the motion of the Ball, for instance, a carpet which may slow the ball down or a piece of chewed chewinggum which may completely prevent motion. I do not consider these types of Obstacles as orchestrators as the goal of the ARS is to “produce fun” through motion of the ball – an idle ball does not live up to this goal. The Floor could be considered part of the Entity subsystem as were the Obstacles, but I have chosen only to regard the floor as a provider of orchestration, thus only being part of the Orchestrator subsystem. This orchestration is provided through the contact interface between the Ball and the Floor which continuously provides slight motion changes. Naturally they are not as abrupt as when collision occurs with an Obstacle, but it nevertheless has an impact.
206
CHAPTER 6. MODELLING AN ARS
It can be observed from the above discussion that the Weazel Ball can be completely contained within the POEM system-level reference model, which may seem surprising given its simplicity. However, the ball’s construction, where clever mechanical design makes it implement both Mobility, Perception, and Orchestration, qualifies it as an “advanced” robot if judged in terms of its performance – and that is accomplished even without an onboard computer. As argued in this dissertation focusing also on the design of the system rather than just on the functionality of a robot it may indeed be possible to conceive and realise systems that are both cheap, robust, safe, and reliable, and at the same time able to perform complex tasks. The RoboMop is an excellent example of such a system. As part of presenting the ARS Design Tool in the next chapter, I will use the Weazel Ball as a case study to illustrate some of the mechanisms of the tool. This is done in Section 7.3. 6.4.3.5
Conclusion
These simple examples are only meant to illustrate the versatility of the model and hopefully convince the reader that the ARS system-level subsystem model is sound. As stated earlier, I do not claim that POEM defines a universal set of system-level subsystems but believe it to be sufficient for the purpose of this dissertation and useful in the wider context of robot system design. However, as POEM in its current form is, in fact, able to capture the essence of all the presented models, it represents a more general and more generic model.
6.5
Evaluation
In the past chapters I have shown how parts of the ARS system-level design process can be facilitated using the RTE-representation for various purposes. In the introduction to this chapter I then argued that as it is a conceptual model it is not directly able to capture the separate system components and their complex couplings which motivated – and led – to the concepts of Emergence Hierarchy and POEM. Though I have demonstrated that POEM is a solid model for representing various types of ARSs from different levels of abstraction, and that the Emergence Hierarchy seems to be a sound way of hierarchically
6.5. EVALUATION
207
representing systems, there is, however, a rather large knowledge “dark-spot”: how do we make the transition from the RTE-representation to an Emergence Hierarchy with POEM at the top? – or asked in terms of the design life-cycle: how do we make the jump from the Concept Development stage to the Engineering Development stage? There is unfortunately no easy answer to this question. Though the RTE-representation is a conceptual model representing the physical world in terms of robots and their environment, the direct mapping of physical components from RTE to the Emergence Hierarchy can only be done at the implementation-segment, that is, leaving POEM at the top and a lot of components at the bottom. How do we connect the dots? This implies defining an appropriate number of levels, identifying subsystems at these levels, and naming them properly to avoid too much confusion. As was suggested in Section 6.4.2, it may perhaps be possible to utilise domain specific intermediate models to generate an interface layer between the concept-segment and the implementation-segment. This would give us POEM at the top, components at the bottom, and an intermediate layer somewhere between them. This would provide a good starting point for populating the Emergence Hierarchy but still does not address how we handle the in-betweens; though it is possible to use only a three-level Emergence Hierarchy I very much doubt that it will be of much use in a design process: system names could, for instance, be derived as some combination of the names of its own subsystems or super-systems, but this may eventually lead to extremely long and cluttered names.
To start addressing this problem in a broader perspective I believe that both a syntactic and a sematic analysis is needed of as many different robotic system models as possible – perhaps projects like “Robot Standards and Reference architecture” (RoSta)11 , “Best Practice in Robotics” (BRICS)12 , and “Resilient Reasoning Robotic Co-operating Systems” (R3-COP)13 may provide valuable insights. The results may then be used to elucidate how many levels-of-abstraction typically are used to describe a robotic system, what names are commonly used, and what the individual subsystems and components actually do. From this point it may be possible to construct a methodology for populating 11
RoSta was a Coordination Action funded under the European Union’s Sixth Framework Programme. BRICS is a Collaborative Project funded under the European Union’s Seventh Framework Programme. 13 R3-COP is an ARTEMIS Projects funded under the European Union’s Seventh Framework Programme 12
and, for DTI’s part, by The Danish Agency for Science, Technology and Innovation.
208
CHAPTER 6. MODELLING AN ARS
the Emergence Hierarchy in a rational way addressing levels, subsystems, emergence, and names. This, however, will not be pursued further in this thesis but constitutes an important task for future work. With respect to validation of the Emergence Hierarchy, the sDSM representation, and POEM, the first two have not been validated in any external context and thus only through the results presented in this thesis. POEM has on the other hand been evaluated externally as part of the Genefke-POEM tool presented in Chapter 8 applied in the context of the EU project PV-Servitor (see section 8.5). Also, a preliminary version of POEM was conceived while I was visiting the Australian Centre for Field Robotics, Sydney, where I gave a presentation of it in plenum followed by general discussion and evaluation. The responses were quite positive.
6.6
Conclusion
In this chapter I first presented a discussion of what a system is and showed how it can readily be modelled as a hierarchy – a system-hierarchy. I then elaborated this by presenting how this system-hierarchy can be graphically represented as both a tree and as a novel type of DSM that I call a sDSM. To facilitate a more flexible design process, I introduced a more dynamic hierarchy representation called an Emergence Hierarchy (EH) which is based on the emergent properties of subsystems rather than on their functional properties, which is able simultaneously to represent a system at several levels-of-abstraction. Then I presented a novel system-level reference model called POEM, which I claim is able to represent any ARS. I backed this claim by presenting four example cases where it was showed that POEM was indeed able to model these system. This, however, does not prove that it can, in fact, represent any ARS, but I have so far unable to find counterexamples. Then I presented an evaluation of the Emergence Hierarchy and POEM where I elucidated a large knowledge “dark-spot” that makes the transition from a RTE-representation to an Emergence Hierarchy representation very difficult. The accomplishments presented above directly fulfill Objective 4 and Objective 5 of Table 1.1 on page 14. To summarise, the two models presented in this chapter, have the intended application
6.6. CONCLUSION
209
domains shown in Figure 6.26. As POEM is a system-level reference model it belongs in the system-level part of the system/component hierarchy, and is intended to be used primarily from the concept development stage to the end of the engineering design phase – POEM is not likely to provide much contribution to other parts of the life-cycle. The Emergence Hierarchy is applicable only in the first two phases of the engineering development stage as it provides no means of assessing the validity of final physical solution – it is only a model. As discussed in this chapter, the intent of the Emergence Hierarchy is to provide the means to model a system from the system-level to the component-level, and its domain therefore spans all levels of the system/component view.
Planning
Concept Development
System−level Design
Concept Development
Needs Analysis
System level
Concept Exploration
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
POEM
Intermediate levels Component level Emergence Hierarchy
Figure 6.26: The intended application domains of the tools, methods, models/representations developed in Chapter 6 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2.
210
CHAPTER 6. MODELLING AN ARS
Chapter 7 The ARS Design Tool In the previous chapter I presented a specific benefit of the system-oriented view by showing how the concepts of the Emergence Hierarchy (EH) can be utilised to represent simultaneously all levels of abstraction of a robotic system from the system-level to the componentlevel. In this chapter I will combine the EH with the system-level reference model I denoted POEM, and new techniques I denote set-projection and set-expansion, to form the basis of an innovative ARS Design Tool – ADT for short – that will help the designer of future ARSs better to handle the inherently complex interactions and dependencies present in both subsystems and components of ARSs. More specifically the ADT will aid the designer in three major areas: 1) comprehending and managing rationally the local and system-wide consequences of subsystem and component choices/changes, 2) maintaining a consistent system representation at all times, and 3) incrementally creating a representation of the ARS in question as the design process progresses. These three challenges have been chosen as the initial focus as I believe that a tool able to facilitate these tasks will be a valuable asset to an ARS designer. At the same time it provides together with the previous results, a further contribution towards rationalising the ARS design process. In Section 7.1 I will first present the techniques of set-projection and set-expansion, and show how they can be used to derive some simple – yet effective – ways of manipulating an EH. After this I will in Section 7.2 present some further aspects of manipulating the EH which in Section 7.3 leads to a simple example where I introduce POEM as part of the EH. Section 7.4 then presents the functional requirements of the ADT, a prototype software 211
212
CHAPTER 7. THE ARS DESIGN TOOL
implementation of it and provides suggestions of how it should be applied to meet the required goals for the tool. The section ends with a discussion on how to further evaluate the tool. Section 7.5 summarises the results in a conclusion. These will directly address Objective 6 of Table 1.1 on page 14.
7.1
Set-projection and Set-expansion views
Employing the concepts of sets in conjunction with the EH, it becomes possible to define manipulations of the EH that will provide the backbone of how to apply the ADT, as will be presented in the next section. First, I will introduce the terms normal view, setprojection view and set-expansion view to denote three different ways of regarding (parts of) the EH. Figure 7.1 illustrates these views.
E1
E2
E1
E1
E3
E3
A
B
E2
D
C
Normal view
E3
A
B
E2
D
C
A
B
D
C
Set−projection view
B
C
Set−expansion view
C
Figure 7.1: Normal-, set-projection and set-expansion view of a level in the Emergence Hierarchy
Figure 7.1 shows three equivalent views of two neighbouring levels of an EH representing a simple system. In the first, the normal view, the representations of the two layers are identical to the one employed in Figure 6.12, except for the use of dashed lines to represent the couplings between the levels. In the second, the set-projection view (SP), sets are superimposed on the lower-level subsystems to indicate which higher-level subsystem they are part of – this was the view
7.1. SET-PROJECTION AND SET-EXPANSION VIEWS
213
used previously in both Figure 6.16, Figure 6.17, and Figure 6.23 of Section 6.4.3. The individual is-part-of relationship lines are now redundant and are replaced by a single one from the lower-level set to the higher-level subsystem indicating that the system is condensed as in Figure 6.7(b) on page 174. For clarity the higher-level representation has also been altered to reflect the appearance of the sets in the lower-level. In the setprojection view it is particularly easy to see which lower-level subsystems are part of several higher-level subsystems.
In the third, the set-expansion view (SE), the overlapping sets of the lower-level are now expanded into disjoint subsets each containing a portion of the EH. This is done by duplicating the subsystems that appear in more than one subset and “pulling” the sets apart, thus expanding the hierarchy at that (lower) level so that it resembles a normal system hierarchy, that is, no subsystem has more than one supersystem. As can be seen in Figure 7.1, the interactions within each separate subset are maintained while interactions crossing the subset boundaries are shown as dashed lines, to indicate that an inter-level interaction exists. Note that duplicate subsystems represent the single original shared subsystem – they are not copies but references.
The impact that performing the SP and SE operations on a level has on the level immediately below, can be seen in Figure 7.2 where a third level has been added to the previously used EH for illustrative purposes. As can be observed, the SP view does not affect this level, but the SE indeed does. The consequence of expanding a level is the that lower level subsystems will now have additional is-part-of relations corresponding to the increased number of higher level subsystems.
214
CHAPTER 7. THE ARS DESIGN TOOL
Normal view
A
B
Set−projection view
D
A
C
P
B
Q
Set−expansion view
D
C
P
A
D
B
C
B
C
Q C
R
S
R
S P
R
Q
S
Figure 7.2: The SP/SE impact on a lower level of the Emergence Hierarchy
More formally we can state that a subsystem, A, expands into a set of new subsystems Ae , comprising two-tuple elements Ax ≡ (A, x), where x is a supersystem of A. We denote S as the set of all subsystems found one level above the level of A. Using set-builder notation we can state Ae as: Ae = {Ax | Ax ≡ (A, x) and A ⊆ x and x ∈ S} We can furthermore state that an existing interaction
A
B
(7.1)
– or put less graphically:
A 7→ B – therefore expands into the following new set of interactions I 0 : I 0 = {(Ax 7→ By ) | Ax ∈ Ae and By ∈ B e }
(7.2)
where Ae and B e denote the sets of expanded subsystems of systems A and B respectively as given by Equation 7.1. It can thus be observed that if x = y it is an intra-level interaction and if x 6= y it is an inter -level interaction.
In the set-expansion view it is particularly easy to see which lower-level subsystem
emergences are necessary to obtain a certain higher-level system emergence. It is also easy to see exactly which lower-level subsystem interactions cause the higher-level subsystem interactions as these must stem from the inter-level interactions.
7.1. SET-PROJECTION AND SET-EXPANSION VIEWS
215
The process of expanding a level has an inverse operation: contracting. Contracting a level means moving from SE to SP to normal-view, and is accomplished by 1) merging subsystems with the same name (i.e. removing references), while 2) maintaining intra-level interactions and converting inter-level interactions into a set of new interactions, I. This operation can be formally stated as in Equation 7.3:
I = {(P 7→ Q) | P, Q ∈ {A, B}; P = Px ; Q = Qy where (Px 7→ Qy ) ∈ I 0 }
(7.3)
It is possible directly to represent the normal-view and the SE-view of Figure 7.1 using an sDSM as shown in Figure 7.3. As discussed in Section 6.3.2.4, note how Figure 7.3(a) handles systems with numerous supersystems by allowing them to have multiple (◦)’s. Also note how the SE-view in Figure 7.3(b) have off-diagonal partitions with several inter-level interactions – all analogous to the graphical representation – and uses a convention of post-
E2 E3 A B C D
◦ ×× ◦× ◦ ×× ◦ ◦◦ × ◦◦◦ ◦ (a) Normal view
E E1 E2 E3 A E1 B E1 C E1 B E2 C E2 D E2 C E3
◦ ×× ◦× ◦ × ◦ × ◦ ◦ ◦ 4 ◦ ◦ ◦
D E2
C E3
B E2
C E2
C E1
B E1
E3
A E1
E2
E
E E1
E1
D
B
C
A
E3
E2
E1
E
fixing names of expanded subsystem with an underscore and the name of its supersystem.
444
(b) Set-expansion view
Figure 7.3: The normal-view and the set-expansion view of Figure 7.1 represented using an sDSM.
In Section 6.2.2.2 I explained how a sequence of subsystems ordered as, for instance, the lower level in Figure 7.3(b), has a total ordering under the relation “≥”. A different way of ordering these subsystems – that I call introspective-ordering – can be seen in Figure 7.4.
E E1 E2 E3 A E1 B E1 B E2 C E1 C E2 C E3 D E2
◦ ×× ◦× ◦ ◦ × ◦ ◦ 4 ◦ ◦ ◦ ◦
C E3
D E2
C E1
C E2
B E2
B E1
A E1
E3
E2
E
CHAPTER 7. THE ARS DESIGN TOOL
E1
216
×4 4 4
Figure 7.4: Introspective view of the lower level of Figure 7.3(b)
The subsystems are clustered together in totally ordered groups where all members have the same original subsystem. The groups are then ordered to reflect the same subsystem ordering as in the normal-view. The result is a view where it is easy to observe how the normal-view interactions are realised in the expanded view, as the introspective-ordering produces n×n partitions reflecting the n×n cells of the normal-view – observe also how an illegal reflexive cell is mapped to a partition with only illegal cells. As the name suggests this introspective-view reveals information only relating to the current level, and can be used to observe how (and if) the original interactions are sustained during manipulations of the EH. As an example of how SP and SE can be utilised to make changes to subsystems and interactions of an EH consider the interaction
E1
E2
in Figure 7.1. In the SE view it
is clear that it must be a result of the inter-level interactions
A
D
and
A
C
in the
lower-level. If, for any reason, we now decide to change the nature of the subsystem C that is part of E2 to another subsystem with different emergence, say, F, the inter-level interaction
A
C
can now be removed – or at least re-evaluated. We will also have to
evaluate if the previous lower level subsystem of C, that is, the subsystem S as seen in Figure 7.2, is to remain as lower level subsystem of F – for simplicity we will say that it does. Let us also add a new interaction
F
D
for the sake of the example.
We can now obtain SP by contracting the level thus merging the disjoint sets by collapsing identical subsystems while maintaining intra-level interactions and converting interlevel interactions into new intra-level interactions. We observe that the intra-level interac-
7.1. SET-PROJECTION AND SET-EXPANSION VIEWS
217
tions on the higher-level have been maintained and if the emergence of E2 is still preserved we have maintained consistency in the hierarchy. The manipulation is illustrated stepwise in Figure 7.5.
E1
E2
E1
E3
E2
E3
A
D
C
A
D
A
D
F
B
Setâ&#x2C6;&#x2019;expansion view
E2
E3
F B
E1
B
F
C
B
Setâ&#x2C6;&#x2019;projection view
C
Normal view
C
Figure 7.5: Making manipulations to the Emergence Hierarchy from Figure 7.1 using set-projection and set-expansion views: C has been replaced by F and an interaction from F to D has been added.
Had we also decided to change subsystem D to something else we would potentially have to remove the inter-level interaction A
C
A
D
. This act and the previous removal of
now renders the hierarchy inconsistent as the interaction
E1
E2
still exists â&#x20AC;&#x201C; this
violates the emergent properties. This conflict has to be resolved by either: 1) removing E1
E2
or by 2) adding one or more inter-level interactions between subsystems of the
expanded E1 and the expanded E2. Which action to take depends entirely on the context. An important observation to make from the above example is that it is possible to carry out consistent manipulations of the hierarchy considering only two neighbouring levels at a time. As illustrated in Figure 7.2 these manipulations will, of course, have impacts on both higher and lower levels, however, these can be resolved if we in the next step move one level down or up and then repeat the SP/SE operations. This pairwise level-view of the hierarchy facilitates observing the entire system at a preferred level-of-abstraction while conducting analysis or design operations using only the terminology required at that particular level. Decisions can thus be made at, for instance, a high level while temporarily disregarding
218
CHAPTER 7. THE ARS DESIGN TOOL
the consequences to the lower-levels. These consequences will, of course, sooner or later have to be dealt with, but I believe that the offered flexibility will prove to be an asset in an analysis or design process. A thing to keep in mind when making manipulations of the EH using SP/SE operations is that they do not themselves provide automatic answers for how to maintain a consistent hierarchy but do provide a way of identifying conflicts and give an indication of what options are available for resolving them. Let us elaborate some of these issues a bit more.
7.2
Manipulation issues
As the example in the previous section illustrated, making manipulations to an EH using SP/SE is about adding, removing, or changing subsystems and interactions at various levels. The major challenge lies not so much in making these manipulations, as in ensuring that the emergent properties are preserved across all levels, that is, to maintain a consistent hierarchy at all times. As adding and removing subsystems are fairly trivial activities per se – the challenge being defining what their emergent properties should be – I will in the following focus solely on the handling of 1) adding interactions and 2) removing interactions, and show how consequential inconsistencies stemming from these manipulations can be resolved.
7.2.1
Adding Interactions
Let us assume that we are in the progress of designing some system – perhaps an ARS – and we have obtained the three-level EH and sDSM in Figure 7.6. We have only specified what the subsystems are on the three levels and have not yet decided on the interactions we need in order to obtain the desired emergent properties. If we now expand the lowest level (level 2) we will obtain the representations shown in Figure 7.7.
E 1 2 A B C (a) As an EH
◦ ◦
C
B
A
2
1
219 E
7.2. MANIPULATION ISSUES
◦ ◦◦ ◦
(b) As a sDSM
E 1 2 A 1
◦ ◦
B 1 B 2 C 2
◦ ◦
C 2
B 2
B 1
A 1
2
1
E
Figure 7.6: An example system represented as both an EH and as a sDSM.
◦ ◦
(a) As an EH with level 2 ex-
(b) As a sDSM with level 2 ex-
panded
panded
Figure 7.7: An example system represented as both an expanded EH and as an expanded sDSM.
To start obtaining our desired emergent properties we need to add interactions to our system, and in this case we have only two options: to add an interaction at level 1; or to add an interaction at level 2. No matter which choice we make, we have to determine what the impacts on the rest of the system will be, that is, how our particular choice affects other interactions in the system and how these, in turn, will affect other emergent properties. However, due to the hierarchical nature of the interactions in the EH – as shown in Figure 6.11 on page 178 – it is possible to focus only on the impacts relating to two neighbouring levels, as the effects will propagate both up and down the hierarchy. By moving through the EH in steps of one level at a time, pairwise handling of levels will
220
CHAPTER 7. THE ARS DESIGN TOOL
therefore ensure that the impacts can be properly detected and handled. Let us first observe what will happen in level 1 if we add an interaction between two level 2 subsystems. Let us choose to add the relation
A
to the system in Figure 7.6.
B
Performing an expansion of level 2 yields the result shown in Figure 7.8. Note that the expanded subsystem names in the EH representation have been post-fixed with the name
E 1 2 A 1
◦ ◦
B 1 B 2 C 2
(a)
◦ ◦
C 2
B 2
B 1
A 1
2
1
E
of their supersystem shown in curly brackets.
×4
◦ ◦
(b)
Figure 7.8: The EH and sDSM after adding an interaction between A and B, and expanding level 2.
As can be seen the addition of intra-level interaction
A1
B1
A
B
has resulted in two new inferred interactions: an
and an inter-level interaction e
A1
B2
. This makes good
e
sense as according to Equation 7.1 we have A = {A 1} and B = {B 1, B 2} and the
interaction by Equation 7.2 therefore expands into the following new set of interactions: I 0 = {(A 1 7→ B 1), (A 1 7→ B 2)} where the first is an intra-level interaction and the
second an inter-level interaction.
The implications on level 1 can only be related to the inter-level interaction as these relate to interactions between the supersystems. This is marked using red boxes – as opposed to green boxes – indicating that there is an inconsistency between the two levels. If we try to resolve this inconsistency at level 1 instead of level 2 we are applying a bottom-up approach as we seek a solution at a higher level, thus going upwards. Using this approach we see that the interaction
1
2
is needed to make it consistent. Note that it may seem
obvious to resolve the conflict by just removing this will not directly have the desired effect.
A1
B2
, but as will be presented shortly
7.2. MANIPULATION ISSUES
221
If we map out the set of all possible level 1 and level 2 implications caused by adding interactions to level 2 they will appear as in Table 7.1. As can be seen, no matter what relation we add there is always only one way of resolving it at the higher level.
Lvl 2 Interaction
Lvl 2 Intra-level
Lvl 2 Inter-level
Lvl 1 Resolution
A
B
A1
B1
A1
B2
1
2
B
A
B1
A1
B2
A1
2
1
B
C
B2
C2
B1
C2
1
2
C
B
C2
B2
C2
B1
2
1
A
C
None
A1
C2
1
2
C
A
None
C2
A1
2
1
Table 7.1: Bottom-up approach: Resolving inconsistencies at Level 1 resulting from changes to level 2.
Now let us instead observe what will happen in level 2 if we add an interaction between two level 1 subsystems, that is, we will now apply a top-down approach, thus attempting to resolve inconsistencies at level 2. Let us choose to add the relation
1
2
to the system
E 1 2 A 1 B 1 B 2 C 2
(a)
C 2
B 2
B 1
A 1
2
1
E
in Figure 7.6. Performing an expansion on level 2 yields the result shown in Figure 7.9.
◦ × ◦ ◦ ◦ ◦ ◦
(b)
Figure 7.9: The EH and sDSM after adding an interaction between 1 and 2, and performing an expansion of level 2.
As can be seen the addition of
1
2
has not actually resulted in much – except for
the partitioning of level 2. This is, of course, because no matter what inter-level interac-
222
CHAPTER 7. THE ARS DESIGN TOOL
tion we enter into the level 2 partition corresponding to
1
2
, it will indeed resolve the
inconsistency (shown again in red). Depending on which of the three possible inter-level interactions we choose –
A1
B2
,
A1
C2
, or
B1
C2
– a level 2 resolution can be
directly inferred. However, this level 2 resolution may then result in an additional inferred intra-level interaction which can be seen by inspecting Table 7.1. If, for instance, we choose A1
B2
to resolve the conflict, a contraction of level 2 yields an new
A
B
interaction
ARS 1 2 A 1 B 1 B 2 C 2
(a)
C 2
B 2
B 1
A 1
2
1
ARS
following Equation 7.3. If we again expand level 2 we get the result shown in Figure 7.10.
◦ × ◦ ×4 ◦ ◦ ◦ ◦ (b)
Figure 7.10: The EH and sDSM after choosing an interaction between A 1 and B 2 and again expanding level 2.
If we map out the set of all possible level 1 and level 2 implications caused by adding interactions to level 1 they will appear as in Table 7.2. As can be seen, the resolution of the inconsistency now depends on the choice we make. Lvl 1 Interaction 1
2
2
1
Lvl 2 Inter-level
Lvl 2 Intra-level
A1
B2
A1
A1
C2
B1
C2
B2
B2
A1
B1
C2
A1
C2
A1
B1
A
B
A
C
C2
B
C
A1
B
A
C
A
C
B
None
None C2
Lvl 2 Resolution
B2
Table 7.2: Top-down approach: Level 1 and level 2 implications caused by adding interactions to level 1
7.2. MANIPULATION ISSUES
223
An important observation following the above examples is that the bottom-up approach can be characterised as imposing changes on higher levels of the hierarchy based on lower level decisions, whereas the top-down approach can be characterised as facilitating choices – however, when these choices have been made a propagation step is necessary to ensure consistency. These notions will be essential for formulating the ADT in Section 7.4.
7.2.2
Removing Interactions
Removing an interaction in normal-view is always a trivial matter – at least seen from a manipulation point of view. However, sometimes it may be desired also to remove interlevel interactions when in SE view. If, for instance, the interaction
A1
B2
in Figure 7.8
was undesired it cannot simply be removed as the following return to normal-view still would have
A
B
– a subsequent expansion would therefore simply restore the interaction.
A solution is to rename either A 1 or B 2 to, say, D 1 or D 2 respectively and then remove the interaction. “Renaming” is, however, a semantic operation, and does not account for the changes this may have on the system. If, for instance, a renamed subsystem has several supersystems, the procedure is called splitting as it effectively splits a subsystem into two separate pieces each with their own emergent properties and with their own supersystem. Here it is important to point out that each “piece” of the original subsystem must maintain the scope of the original subsystem. If this were not the case the pieces would instead belong to a different level of the hierarchy indicating a wrong EH structure. Though the scope must be maintained, the resolution at that particular level may, however, very well have increased after the operation. Before splitting a subsystem several important issues therefore have to be addressed: 1) what are the new emergent properties of the split subsystems and do they make sense with respect to the other subsystems at the same level, 2) the source and sink interactions of the old subsystem should be evaluated to assess how they relate to the new subsystems – perhaps some should be removed or their interpretations redefined, 3) which lower level subsystems do the new subsystems have – the same as the original or are they, in fact, different. Splitting a subsystem is therefore quite a powerful tool as its use may impact the EH in many ways across several levels. It should therefore not be used uncritically and seen as an easy way out of problems, but rather as the means to obtain a better understanding
224
CHAPTER 7. THE ARS DESIGN TOOL
of the problem and thus a more rational approach to resolving it.
7.3
An Example: The Weazel Ball
To illustrate the use of some of the presented manipulation issues I will provide an example by analysing the Weazel Ball presented in Section 6.4.3.4. The emphasis is here on analysis as the ball has already been made, and it is therefore not a design situation, but the example will, however, prove insightful as it will provide input to Section 7.4 where I will formulate the ADT strategy. As the Weazel Ball was presented as an example of the versatility of POEM we will use POEM as the basis for our analyses and thus place it at the systemlevel – level 1 – of the EH. The purpose of the analysis is therefore to examine how the various POEM subsystems can be mapped down the hierarchy, thus essentially validating the argumentation of POEM ’s ability to contain the Weazel Ball.
7.3.1
The Analysis
ARS P O E M Floor Obst. Ball
(a)
Ball
Obst.
Floor
M
E
P
O
ARS
From Figure 6.25 it is now possible to construct the EH and sDSM shown in Figure 7.11.
◦ × × ◦ ◦× ◦× × ◦ ◦◦ ◦◦ ◦ (b)
Figure 7.11: The initial setup for the analysis of the Weazel Ball
As can be observed from Figure 7.11 the validation procedure I will apply is to conduct the analysis without the interactions between the Ball, the Obstacles, and the Floor, and instead show at the end that these interactions are indeed present in some sufficient representation – note that this is not the same as deriving the full set of subsystem interactions
7.3. AN EXAMPLE: THE WEAZEL BALL
225
that may exist in a Weazel Ball; it is only a subset. The reason for doing the analysis this way is to keep things relatively simple and instead focus on illustrating the manipulations. To get started let us expand level 2 to get an idea of how the Weazel Ball may be
ARS P O E M Ball P Floor O Obst. O Ball O Obst. E Ball M
Ball M
Obst. E
Obst. O
Ball O
Floor O
M
Ball P
E
P
O
ARS
mapped to POEM. This can be seen in Figure 7.12.
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ ◦
(a)
(b) Figure 7.12: Level 2 has been expanded
As POEM comprises five inherent interactions, the expanded level 2 also comprises five partitions – all marked as inconsistent. Since we are using POEM as overall reference model for this system it is not possible for us to make changes to level 1 as this will violate the definition of POEM. We can therefore only make changes to level 2 to resolve conflicts, which means that we will have to employ a top-down approach. A thing that strikes the eye when regarding Figure 7.12 is the fact that the one-cell partition of (Ball M 7→ Ball P) is grey, thus indicating that it is an illegal cell. This
is, however, not strange as “Ball” is present in both (i.e. they both represent the same “Ball”) and as the sDSM is non-reflexive the cell is unavailable. However, it is not possible to satisfy POEM ’s (M 7→ P) interaction unless we can somehow make it available. To do so, we need to split Ball M and Ball P into two separate subsystems: one handling the
Mobility part of the Ball and one handling the Perception part. For simplicity I call the new subsystems BallM and BallP respectively. The result can be seen in Figure 7.13. Note that the remaining grey cells occupying red partitions have also become available as “Ball” is now separated in three distinct subsystems – Ball O is the last part.
ARS P O E M BallP P Floor O Obst. O Ball O Obst. E BallM M
(a)
BallM M
Obst. E
Ball O
Obst. O
Floor O
BallP P
M
E
O
P
CHAPTER 7. THE ARS DESIGN TOOL
ARS
226
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ ◦ (b)
Figure 7.13: BallM, BallP, and Ball are now three separate subsystems.
Three of the five level 2 partitions contain only one cell which implies that these particular inter-level interactions have to be inserted to abide by the constraints of POEM, but two of them contain more than one cell, implying that we have a choice as to which interactions to add. However, we need to be sure which of the total nine potential interactions represent interactions that actually make sense in the system. If an interaction does not make sense, it will, in the case of a one-cell partitions, mean that the Weazel Ball cannot be validated with respect to POEM, and the argumentation I presented in Section 6.4.3.4 will thus not be valid. This will, of course, also be the case for partitions with more than one cell, but the odds are here more in our favour. In Table 7.3 I have made a quick assessment of all nine potential inter-level interactions.
7.3. AN EXAMPLE: THE WEAZEL BALL
# Interaction 1 2 3 4 5 6 7 8 9
227
Assessment
(BallP P 7→ Floor O)
This interaction does not exist and should therefore not
(BallP P 7→ Obst. O)
Collision with obstacles.
be included.
(BallP P 7→ Ball O)
The ball’s mechanical link transferring momentum from
(Floor O 7→ BallM M)
The floor’s effect on the ball’s motion.
(Ball O 7→ BallM M)
A mechanical coupling inside the ball.
(BallM M 7→ BallP P)
A mechanical coupling inside the ball.
a collision to a new direction of motion.
(Obst. O 7→ BallM M)
The obstacle’s effect on the ball’s motion.
(Obst. E 7→ BallP P)
The indirect detection of the loss of momentum.
(BallM M 7→ Obst. E)
The ball’s collision with motion obstructing obstacles.
Table 7.3: Interpretation and assessment of the nine potential sDSM inter-level interactions
As can be seen only Interaction 1 is not valid (shown in grey) which means that we can, in part, conclude that my previous argumentation is valid. The reason being that 1) Interaction 1 is part of a partition with more than one cell, and 2) if we split all expanded level 2 subsystems into separate subsystems – thus converting the EH to a normal system hierarchy – we know that we can add all required interactions without causing undesired inferred interactions. However, to make the final conclusion we still need to make sure that the Weazel Ball interactions are indeed present in some sufficient representation. This point will be made clear later on.
To continue exploring our example, let us start by adding, for example, (BallP P 7→
Obst. O), and then perform a contraction of level 2 followed by an expansion. Figure 7.14 shows the resulting system.
ARS P O E M BallP P Floor O Obst. O Ball O Obst. E BallM M
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ ◦
(a)
4
BallM M
Obst. E
Ball O
Obst. O
Floor O
BallP P
M
E
O
P
CHAPTER 7. THE ARS DESIGN TOOL
ARS
228
4
(b)
Figure 7.14: After adding (BallP P 7→ Obst. O), contracting, and expanding level 2
It can be observed that the addition of (BallP P 7→ Obst. O) has also resulted in the
addition of the inferred interaction (BallP P 7→ Obst. E), which, in turn, has resulted
in a new inconsistency between the two levels. As was the argument before, we cannot make changes to level 1 without violating POEM which means that we need to remove the inferred relation in level 2 to resolve the inconsistency. To illustrate more clearly why the inferred interaction was added consider Figure 7.15 which shows the contracted sDSM after the addition of (BallP P 7→ Obst. O). Expanding this level will naturally result in
ARS P O E M BallP Floor Obst. Ball BallM
(a)
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦◦ ◦ ◦
BallM
Ball
Obst.
Floor
BallP
M
E
P
O
ARS
Figure 7.14.
×
(b)
Figure 7.15: After adding (BallP P 7→ Obst. O) and contracting level 2
We now address the problem of removing (BallP P 7→ Obst. E), by splitting Obst. – re-
member that Ball has already been split – thus renaming Obst. E to Obst.E E. Contracting
7.3. AN EXAMPLE: THE WEAZEL BALL
229
ARS P O E M BallP Floor Obst. Ball Obst.E BallM
(a)
Obst.E
BallM
Ball
Floor
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ ◦
Obst.
BallP
M
E
P
O
ARS
the sDSM we now obtain the system shown in Figure 7.16.
× ×
(b)
Figure 7.16: After renaming Obst. E to Obst.E E and contracting level 2
The splitting procedure has resulted in the new interaction (BallP 7→ Obst.E) which
can be readily removed – this can, of course, also be done in SE view. Expanding level 2
ARS P O E M BallP P Floor O Obst. O Ball O Obst.E E BallM M
(a)
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ ◦
BallM M
Ball O
Obst.E E
Obst. O
Floor O
BallP P
M
E
O
P
ARS
after this operation reveals Figure 7.17.
4
(b)
Figure 7.17: After removing (BallP 7→ Obst.E) and expanding level 2
As all subsystems in level 2 have been split we have now obtained an ordinary system hierarchy – easily observed as the only illegal cells in level 2 are on the diagonal – where the remaining interactions from Table 7.3 can be easily added. This results in the consistent system seen in Figure 7.18.
ARS P O E M BallP P Floor O Obst. O Ball O Obst.E E BallM M
◦ × × ◦ ◦× ◦× × ◦ ◦ ◦ ◦ ◦ 4 ◦4
(a)
44
BallM M
Obst.E E
Ball O
Obst. O
Floor O
BallP P
M
E
O
P
CHAPTER 7. THE ARS DESIGN TOOL
ARS
230
4 4 4 4
(b)
Figure 7.18: After adding the remaining interactions from Table 7.3.
If we contract level 2 we now obtain the normal-view of the Weazel Ball ARS – this can be seen in Figure 7.19(a). For easy comparison with the initial setup I have shown it
ARS P O E M BallP Floor Obst. Ball Obst.E BallM
◦ × × ◦ ◦× ◦× × ×× ◦ × ◦ × ◦ × ◦ ◦ × × ◦×
(a) The normal-view of the sDSM
ARS P O E M Floor Obst. Ball
Ball
Obst.
Floor
M
E
O
P
ARS
BallM
Obst.E
Obst.
Ball
BallP
Floor
M
E
O
P
ARS
again, for convenience, in Figure 7.19(b).
◦ × × ◦ ◦× ◦× × ◦ ◦◦ ◦◦ ◦
(b) The initial setup sDSM
Figure 7.19: The normal-views of the contracted sDSM and the sDSM from the initial setup.
As was earlier concluded in part, it seems that POEM is indeed able to model the Weazel Ball ARS as anticipated. However, we still need to assert that the Weazel Ball interactions are present in some sufficient representation in order to be fully convinced – to do this, the introspective-view presented in Section 7.1 is most useful. Figure 7.20 represents this view of level 2 and as can be observed, the new interactions are located in the partitions
7.3. AN EXAMPLE: THE WEAZEL BALL
231
related to the interactions (Floor 7→ Ball), (Obstacle 7→ Ball), and (Ball 7→ Obstacle), which constitute the relations shown in Figure 6.25 on page 205. Furthermore it can be seen that the reflexive interaction (Ball 7→ Ball) seems to exist, but this is a consequence
of the split Ball subsystems which now, naturally, interact. We can therefore conclude the analysis by stating that it has been validated that POEM is, in fact, able to model the
ARS P O E M Floor Obst. Obst.E BallP Ball BallM
BallM
Ball
BallP
Obst.E
Obst.
Floor
M
E
O
P
ARS
Weazel Ball ARS.
◦ × × ◦ ◦× ◦× × × ◦ × ◦ × ◦ × × ◦ × ◦ ×× ◦
Figure 7.20: Introspective-view of level 2 of Figure 7.19(a)
7.3.2
Discussion
The most apparent differences between the sDSMs in Figure 7.19 are that 1) all the subsystems with more than one supersystem have been split, thus creating a normal system hierarchy instead of an EH, and 2) that interactions have been added to level 2 to make the hierarchy consistent. Naturally, the new names of the split subsystems should have been matched to their actual emergent properties, but as this was an example of manipulating the sDSM for analysis purposes, I did not prioritise this as their interpretations can be implicitly found in Table 7.3 and from the discussion in Section 6.4.3.4. Of course this step is crucial in a “real” analysis situation as only by explicitly stating what emergent properties a split subsystem should have, is it possible to assess whether the issues of “comparable
232
CHAPTER 7. THE ARS DESIGN TOOL
scope” and the requirements to supersystem emergent properties, are satisfied.
As was presented earlier in Section 7.2, the use of the top-down approach facilitates choices. The choices we had to make in this example related mostly to the interpretations of interactions and (a little less) to the interpretation of emergent properties. The analysis of potential interactions shown in Table 7.3 on page 227 represents a small set of what should have been considered had we carried out the analysis actually to model the Weazel Ball and not just validate its coupling to POEM. Consider Figure 7.21(a) showing what Figure 7.11(b) would have looked like had we also incorporated the Weazel Ball interactions as shown in Figure 6.25. If we expand level 2 of this sDSM we obtain the result shown in Figure 7.21(b), which should be compared to the much simpler sDSM in Figure 7.12(b) on which we based the assessment of our potential interactions. In this new situation several inter-level and intra-level interactions already exist, and each of them – even the ones in conflict with level 1 – should be analysed separately to assess if they are necessary or not. So, the choices we have to make using the top-down approach are not necessarily easy but, by using POEM, the EH representation and the derived SP/SE manipulations, it is possible to assess somewhat more easily exactly what should be analysed and thus how to
ARS P O E M Floor Obst. Ball
ARS
◦ × × ◦ ◦× ◦× × × ◦ × ◦◦ ◦◦ ◦ ×
(a) An alternative initial sDSM
P O E M Ball P Floor O Obst. O Ball O Obst. E Ball M
Ball M
Obst. E
Ball O
Obst. O
Floor O
Ball P
M
E
O
P
ARS
Ball
Obst.
Floor
M
E
O
P
ARS
structure the process slightly more.
◦ × × ◦ ◦× ◦× × 4 4 ◦ 4 × 4 ◦ 4 × 4 ◦ × 4 ◦ 4 4 ◦ 4 4 4 ◦
(b) The sDSM with Level 2 expanded
Figure 7.21: An alternative initial analysis setup showing also the sDSM with level 2 expanded.
7.4. A PROTOTYPE ARS DESIGN TOOL
7.4
233
A Prototype ARS Design Tool
Based on the the observations made in the last sections and in the previous chapter I present in this section a prototype ARS Design Tool able to aid the ARS designer in maintaining a more rational design process. First, I will present the overall motivation for the tool, then the functionality required to provide the necessary design aid. Then I will present a software implementation of a subset of these requirements, and present a strategy for applying the tool. I conclude with an evaluation of the tool.
7.4.1
Motivation
A key requirement of an ARS designer is the ability to comprehend and manage the complexity of the ARS in a rational way through all parts of the design process, where comprehension is a natural prerequisite for managing. Comprehending the ARS complexity is about understanding the essential parts and subparts of an ARS, and understanding how they may interact to obtain the required emergent properties of the system as a whole. This is indeed not easy as it requires a deep understanding of not only the technical possibilities but also of the more socio-technical aspects present in the system. Furthermore, it requires an understanding of the system at various levels-of-abstraction, that is, from both the more abstract notions of interacting systems to the physical component level where these abstractions are consolidated in realworld entities. Managing the ARS complexity is about handling all the parts, subparts, and their interactions in such a way that the required emergent properties are obtained. This involves the specification and realisation of subsystems (at appropriate levels and scopes) and interactions in both a model of the ARS in question but also in the real-world realisation of the system â&#x20AC;&#x201C; the actual ARS. Managing is also about handling inconsistencies in the system representation that may arise due to wrong specifications, requirement changes, a change of components, or simple misunderstandings. Furthermore, it is about handling all the above during an incremental and iterative design process where both experimental setups and prototypes are part. This implies that it is not possible to produce a complete system model from the beginning of the design process as the physical system itself will emerge as the process progresses, meaning that the system model will also emerge as the
234
CHAPTER 7. THE ARS DESIGN TOOL
process progresses. To facilitate these requirements, an ARS Design Tool is therefore needed able to aid the ARS designer in three major areas: 1) comprehending and managing rationally the local and system-wide consequences of subsystem and component choices/changes, 2) maintaining a consistent system representation at all times, and 3) incrementally creating a representation of the ARS in question as the design process progresses.
7.4.2
Functionality
From here a natural course of action is, of course, to determine how the various methods, tools, and models presented in this dissertation can help us. Let us first revisit some of the key points relating to the EH and POEM we have established so far: The system complexity issue that was the main focus of the previous chapter was how simultaneously to model the subsystems and interactions of an ARS at various levelsof-abstraction, which was realised through the development of the Emergence Hierarchy representation and the POEM system-level reference model – these two form a natural basis for addressing (1) above. In this chapter I have presented several ways of manipulating the Emergence Hierarchy to maintain a consistent system model at all levels, which constitute a natural basis for addressing (2). Furthermore, in the previous section I addressed several issues of top-down and bottom-up approaches to the design process, which can be used more or less directly to address (3). The ADT we are aiming for will most naturally be software-based which means that we can start thinking in terms of functional requirements of a software tool able to address the above issues. Let us first sum up some of the functional aspects linked to the EH and POEM : • POEM is a system-level reference model capturing the essence of all ARSs at a high level of abstraction.
• An EH with properly defined levels with subsystems of comparable scope has the ability simultaneously to represent a system at various levels-of-abstraction.
7.4. A PROTOTYPE ARS DESIGN TOOL
235
• Both a bottom-up (reductionistic) approach and a top-down (synoptic) approach are needed to manage the complex interactions of an EH. When manipulating the
EH the bottom-up approach imposes changes on the higher levels and the top-down approach facilitates choice. • Set-projection, set-expansion, and introspective views of an EH, expanding and con-
tracting levels of an EH, adding and removing interactions, and adding, removing and splitting subsystems constitute the (initial) set of EH manipulation tools.
These points together with the experiences from Section 7.3 have resulted in the following list of preliminary requirements for the functionality of the ADT: Foundation: Basing the tool on an underlying EH implementation will facilitate much of the required functionality. POEM : As one of the claims of this dissertation is that a system-level view is needed in order properly to handle the design of an ARS, the ADT should comply with this by introducing POEM at the system-level of the EH as exemplified in Section 7.3. This will guarantee that consistency checks and error resolution throughout the hierarchy ultimately will be done with reference to POEM, and will therefore always comply with its definition. A consequence of this is, as was shown in the Weazel Ball example, that a top-down approach needs to be the predominant way of resolving inconsistencies as POEM is immutable. Levels: The tool must facilitate easy insertion and removal of levels. Insertion should be possible also in between two existing levels. A strategy for handling the couplings between levels must, in either case, be automatically resolved, or at least suggested to the user. Subsystems: The tools must facilitate easy adding, removing, and splitting of subsystems. The user should in all cases – prior to the operation – be made aware of the possible consequences of the operation, for instance, what subsystems and interactions will be affected, and how they will be affected. A subsystem should be represented by its name and by a description of its emergent properties – this includes attributes such as weight, colour, size, etc., where these make sense, of course. The description should be easily editable and retrievable at will.
236
CHAPTER 7. THE ARS DESIGN TOOL
Interactions: The tool must facilitate easy adding and removing of interactions. Again, the user should appropriately be made aware of the possible consequences of the operation. As mentioned in Section 6.2 a numerical DSM allows for numbered entries in the cells instead of just a binary notation. Implementing this should be considered as means to handle several types of interactions instead of just one as presented in this dissertation. Graphics: To offer as much flexibility as possible the tool should graphically facilitate both the DAG representation and the sDSM representation, where the latter should be able to display both set-expansion and introspective views of any level. It should be possible to interact directly with the graphical representations to obtain information or perform manipulations of the EH. Design Patterns: A possibility not previously discussed in this dissertation is the use of “design patterns” in the design process. It could easily be imagined that certain common representations of certain clusters of subsystems and interactions could be reused in other designs. A database of these patterns would be an asset to the ARS designer. Inconsistencies: When inconsistencies exist, the user should be made aware of this and of options for resolving them. Based on user input the tool should then resolve the inconsistencies automatically. DSM analyses: As the “(n)” partitions of the sDSM are normal DSMs, several of the DSM analytical operations briefly described in Section 6.2.2.1, should be implemented as standard tools to obtain further insights of the design process. This could, for instance, be a sequencing tool that could help the ARS designer establish the order in which components should be chosen.
7.4.3
A Software Implementation
As a prototype ADT I have implemented a minimal subset of the functional requirements presented in Section 7.4.2. The EH representation and the presented manipulations have been implemented in the Python programming language, and run as a server providing a socket command interface for clients thus allowing them easy access to perform EH
7.4. A PROTOTYPE ARS DESIGN TOOL
237
operations. I have then made a graphical user interface (GUI) in the Java programming language, using the Prefuse1 visualisation tool kit to make an interactive DAG version of the EH. An interactive sDSM representation was programmed using standard Java Swing-components. A screen-shot of the ADT-GUI can be seen in Figure 7.22.
Figure 7.22: A screen-shot of the ARS Design Tool prototype implementation
The implementation offers only the basic functionality with hardly any automated features, as my focus was not on creating a fully functional tool, but rather on providing a development platform I could use in my research. Its main feature is, as can be seen in the figure, the sDSM and its ability to detect and mark both consistencies and inconsistencies between levels â&#x20AC;&#x201C; these are the green and red boxes. As the attentive reader will have noticed by now, I have used the tool extensively to produce both the EH DAGs and the sDSMs presented throughout this dissertation, where the latter have been generated by a script producing a higher resolution sDSM using the vector based PGF/TikZ graphic systems for TeX2 . However, though the tool is only able to facilitate simple operations on the DAG and sDSM like adding, removing, and renaming of subsystems, and adding and 1 2
http://prefuse.org/ http://sourceforge.net/projects/pgf/
238
CHAPTER 7. THE ARS DESIGN TOOL
removing of interactions, it does provide a simple and intuitive interface that can be used for conducting simple examples, as was demonstrated in the Weazel Ball example. As can be observed in Figure 7.22 the DAG visualisation leaves a lot to be desired, as it is hard to see the individual interactions – the graph edges are too cluttered – which does not make it suitable for representing levels with too many subsystems and interactions. However, visually representing a graph such that all nodes and edges can be clearly seen and understood, is not a trivial problem to solve – see, for instance, [Buchheim et al. 2002] for a review of some of the techniques. In my implementation I have used Prefuse’s layout system with a few modifications to constrain the drawn extent of interactions to the level where they belong which, of course, may result in a rather messy look – a better visual EH DAG representation should thus be a priority in a future implementation of the ADT. To improve the situation slightly I did, however, make a colour coding of subsystems, such that hovering over a subsystem, its supersystems will turn blue, its lower level subsystems green, and subsystems being the source or the sink of an interaction will turn orange or yellow respectively. This does provide an easy visual way of identifying exactly which other subsystems are coupled to a particular subsystem – information not as easily identifiable in the sDSM representation.
7.4.4
Applying the tool
Applying the ADT can be done in several ways depending on what the goal is. As was illustrated in Section 7.3 it is possible to use the tool to conduct analyses of how a higher level representation couples to lower level representations by utilising a mainly top-down approach. It is also possible to move the other way, that is, to derive higher level models from lower level representations. This could be done by applying a bottom-up approach to continuously resolve inconsistencies by adapting the higher levels instead of the lower levels. However, the main focus of this chapter is on using the ADT as an ARS design tool, so I will dedicate the remainder of this section to addressing this issue. As the top-down approach facilitates choice, it is natural to start an ARS design process from the higher-levels of the EH, that is, in the concept-segment, and design as much sideways (i.e. constructing the subsystems) and downwards (i.e. constructing the levels)
7.4. A PROTOTYPE ARS DESIGN TOOL
239
as possible. Each step sideways or downwards will result in top-down consistency check going downwards, thus making it possible to iteratively “zigzag” down the hierarchy and ensuring a fully consistent hierarchy once the component-level has been reached. When making a new design choice at some level only consistency with the level immediately above is required – as this now serves as reference – and the focus of the design effort can therefore be more localised. It also implies that the system-wide consequences of a design choice can be identified, analysed and compared to other possible choices before actually making the choice in the real-world. A natural consequence of applying a strict top-down approach, as just described, is that the EH will always converge towards a standard system hierarchy at all levels, which, in fact, is also the end-goal – at least at the component level. Were it not so, it would not be possible to actually realise the system, as subsystems with more than one supersystem is a mere abstraction. To illustrate parts of this process consider again Figure 7.22 where some system is represented. The system-level – level 1 – is here not POEM but just an example model comprising the subsystems E1, E2, and E3. As can be seen, level 2 has been expanded revealing that the EH is consistent at least to level 2. “At least” in the sense that it is not feasible to expand level 3 at the same time as level 2 to determine if the EH is in fact consistent to level 3, as this would result in a very large – and unmanageable – number of expanded subsystems in level 3. Therefore to determine if the EH is consistent to level 3, level 2 must first be contracted and then level 3 expanded. However, it is possible to expand level 4 to get an idea of how consistency looks further down the hierarchy, and as can be seen in the figure, some work will have to be done here. It may, however, not be worth spending too much effort on making lower levels consistent, as this consistency may be broken once the two individually consistent parts of the hierarchy “meet”, but the design process may make this strategy necessary especially if lower-level components are chosen early in the process. When lower-level components and interactions are chosen without a fully consistent hierarchy above, the top-down approach may then become a bottleneck as it will impose several constraints on the lower levels that we are currently manipulating. This may not be desirable and a bottom-up approach may be attempted. However, the lowest level where all the levels above are consistent, will always serve as the new reference, and this boundary should be handled with care: it is like laying train tracks from opposite sides and realising at the end that they do not fit each other, as exemplified
240
CHAPTER 7. THE ARS DESIGN TOOL
in Figure 7.233 .
Figure 7.23: An unfortunate situation.
7.4.5
Evaluation
Evaluating the tool in an ARS design context is unfortunately not straightforward as it requires a setting where 1) a system has to be developed from scratch, and where 2) it is possible to follow the entire process from conceptual development to final physical realisation of the ARS. As robotics projects usually span 2â&#x20AC;&#x201C;5 years in length and start at various points during a year, it has not been possible for me to conduct such evaluations during the course of this PhD project â&#x20AC;&#x201C; and even if it had been possible, proper evaluation would still require evaluations from several design teams working on the same problem, some with the ADT and others without. Another problem is the required domain knowledge. As stated previously it is imperative to have sufficient knowledge of what is to be designed and this knowledge is therefore also needed to use the ADT properly. Using the ADT without the proper background is like using a hammer to cut bread: the job might get done, but it is not pretty, not what you really wanted and indeed not very rational. It takes good ARS designers to make good ARSs, and though the tool offers a way to aid this process it is by itself just a tool. As discussed earlier it may indeed be powerful in the right hands and a disaster in 3
From http://bitsandpieces1.blogspot.com/2007 04 01 archive.html
7.4. A PROTOTYPE ARS DESIGN TOOL
241
the wrong ones. This also makes evaluation difficult, because who can actually evaluate it? To facilitate the evaluation process I therefore propose to initially use the tool on small scale problems with domains that are sufficiently narrow – as explained in the first chapters of this thesis the domain of an ARS is very broad and coming to terms with socio-technical ideas, dependability criteria, ELS compliance, and so forth, may in itself be quite a task. “Small scale problems” do therefore not necessarily have to be of robotics character, but could be any problem where a hierarchical (system) representation is possible, thus removing POEM from the system-level an evaluating only the functionality of the tool and the way it is used. An example of such a narrow scoped problem is structuring and writing this dissertation. I initially used the tool as means to organise my thoughts and consolidate them into parts, chapters, and sections. The goal I was aiming for was to obtain a natural flow in the text so a potential reader would: 1) enjoy the story while 2) not feeling lost (the former will not be addressed further). As addressed in Section D.1.1, Parnas and Clements [1986] believe in faking the rational process by producing the documentation that would have been produced had the process indeed been rational. The same can be said about my PhD (process) and this dissertation (documentation). Though my three year PhD process in many ways has been rational it has nevertheless also been both frustrating, unstructured and at times highly chaotic. An undeniable indicator is the amounts of notes, doodles, finished papers, unfinished papers, and presentation material I have managed to produce through the period, and though not in actual random order, still somewhat fragmented and incoherent. So in writing this dissertation it was of course important to rework all this material to be able to present a final document that actually seemed like the process had run in an orderly and rational fashion. Not to obscure the fact that it had in fact not been entirely rational but because good communication is about conveying a message to the receiver in an understandable way. In hindsight I could perhaps have tackled some issues of my PhD differently and more rationally, but as this is research, chances are that I would still end up with some level of chaos. So to address the problem of “the reader not feeling lost” whilst reading a document,
242
CHAPTER 7. THE ARS DESIGN TOOL
an important factor is to maintain a text that is as structured as possible. By “structure” I refer to where each piece of text in the document is placed relative to its dependencies to other parts of the text. If text piece A contains important information needed to understand piece B, it will often make most sense to place A before B. If you reverse the order, you would either risk losing the reader or constantly have to write “I will cover this in the next part called A”. A natural way of facilitating this situation was to include the ADT in the structuring process. When commencing the dissertation writing process I agreed with my supervisor on an initial structure comprising three parts Systems, Process, and Applications. Each part should naturally have an introduction and a conclusion, and so should each chapter. The tricky question was, what was the natural order of the parts and chapters? Using the ADT I could easily represent the document’s inherent hierarchical structure by placing Parts at the top level, then Chapters, and at the lower levels work with more loose terms like “NeedForSystemLevel” or “RoboCentricVsSys”4 . I initially applied a bottom-up process by first creating a manifold of loose terms and then assigning the obvious textual dependencies between them while continuously monitoring the resulting sDSM. Through this process I was able to track and handle several issues: • If a dependency was on the right side of the diagonal of a DSM, it would indicate that no forward references for that particular text piece were needed as the material had already been covered. However, its distance from the diagonal would indicate “how long ago” it was and could suggest that a summary might be advantageous. • If the dependencies were on the left side of the diagonal of the sDSM, forward refer-
ence were indeed needed. Again, its distance from the diagonal would indicate how far ahead the text would be. This would, for example, apply to the introduction where references were almost exclusively forward, and were handled by giving brief overviews. If a forward reference was needed between text belonging to the same “parent” a repositioning could be considered.
Considering the hierarchy top-down it was possible to see, for instance, what interchapter dependencies were required to fulfill the lower level structure. This would give 4
Using the notion of emergent properties, we can argue that meaning emerges from text due to the
interactions of its subcomponents, i.e. sentences and words, and a dissertation is thus a system in its own right.
7.4. A PROTOTYPE ARS DESIGN TOOL
243
indications of whether the structure was sound, where text needed to be split into more chapters or perhaps merged, and where it was important to remember forward references in the chapter introduction. An example of how the sDSM looked at some point during the writing process can be seen in Figure 7.24 – note that not all dependencies have been
Thesis Introdution RoboticDesign Systems Process Applications Conclusions Appendix RTEIntro Introdution RTE RoboticDesign NewChallenges RoboticDesign WhatAreWeDealingWith? RoboticDesign HowIsItUsuallyDone? RoboticDesign ProdProcOrg RoboticDesign RoboCentricVsSys Systems WhatIsSys? Systems HierarchyOfSys Systems NeedForSystemLevel Systems POEM Systems POEMverify Systems TransPotProcess Process OmniRotaProcess Process Rationality Process TaskHandling Process EnvHandling Process RobHandling Process Safety Process Ethics Process Criteria Process Structure Process DevModel Process Comparison Process CommentOnConsortia Process RequirementHandling Process GeneralDSM Applications ProjectExpand Applications sDSM Applications sDSMDesignTool Applications sDSMThesisExample Applications sDSMModWallExample Applications GenefkePOEMExample Applications OmniRotaQFD Applications Conclusion Conclusions Comic Appendix GenefkeScale Appendix GenefkeTool Appendix
◦ ◦ ◦ ◦ ◦ ◦ ◦
GenefkeTool Appendix
Comic Appendix
GenefkeScale Appendix
OmniRotaQFD Applications
Conclusion Conclusions
GenefkePOEMExample Applications
sDSMModWallExample Applications
sDSMDesignTool Applications
sDSMThesisExample Applications
ProjectExpand Applications
sDSM Applications
GeneralDSM Applications
CommentOnConsortia Process
RequirementHandling Process
Structure Process
Comparison Process
DevModel Process
Criteria Process
RobHandling Process
Ethics Process
Safety Process
EnvHandling Process
TaskHandling Process
Rationality Process
TransPotProcess Process
OmniRotaProcess Process
POEM Systems
POEMverify Systems
NeedForSystemLevel Systems
HierarchyOfSys Systems
WhatIsSys? Systems
RoboCentricVsSys Systems
ProdProcOrg RoboticDesign
HowIsItUsuallyDone? RoboticDesign
WhatAreWeDealingWith? RoboticDesign
NewChallenges RoboticDesign
RTE RoboticDesign
RTEIntro Introdution
Appendix
Conclusions
Applications
Process
Systems
RoboticDesign
Introdution
Thesis
added at this point.
×× × ×
◦
◦ ◦ ◦ ◦ ◦
4
◦ ◦ ◦ ◦ ◦ ◦
×
× ×
4
4
× ×
◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦
×
×
×
4
×
4
44
×
×
× 4
◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦
×
◦
◦ ◦ ◦
4
4
× ×
××
4 4
×
Figure 7.24: The expanded sDSM representing the thesis structure at some point in time.
Through simple re-ordering of the DSMs of the sDSM I was able to maintain a (fairly)
244
CHAPTER 7. THE ARS DESIGN TOOL
coherent document structure, but as the structure turned out to change several times as the text grew larger, the ADT software implementation I had made revealed itself as not being flexible enough to “keep up” with the changes – and an unfortunate software bug made the EH DAG crash at the most inconvenient times. Therefore, when I felt quite confident of the final structure I stopped using the ADT. Not using the ADT all the way to the end is of course not the ideal way of evaluating the use of the ADT, but as this was a one-person project where only I had to keep track of the structure, the tool actually served its purpose. Had it instead been a large scale project with multiple partners, it would have been important to keep updating and revising the EH all the way to the end, but in this case I had to evaluate if it would be time well spent – and I decided it was not. As the example shows, it is possible to apply the ADT to much simpler problems than ARS design, and I believe this to be a feasible initial path to further evaluate and tune the tool. The ADT’s ability as an analysis tool should also be explored further as it may well be applicable in many other areas than robotics.
7.5
Conclusion
In this chapter I have presented the techniques of set-projection and set-expansion as means to manipulate the EH. These techniques were consolidated in the expansion and the contraction methods facilitating a more detailed view of the individual EH. This led to a discussion on several EH manipulation issues, and an example of using these together with the EH and POEM to conduct a simple system analysis, was presented. This led to the final section where a prototype ARS Design Tool was presented. To summarise, the ARS Design Tool presented in this chapter, has the intended application domain shown in Figure 7.25. The tool is applicable only in the first two phases of the engineering development stage as it provides no means of assessing the validity of final physical solution. As discussed in this chapter, the intent of the ARS Design Tool is to provide the means to handle all subsystems and their interactions from the system-level to the component-level, and its domain therefore spans all levels of the system/component view.
7.5. CONCLUSION
245
Planning
Concept Development
Systemâ&#x2C6;&#x2019;level Design
Concept Development
Needs Analysis
Concept Exploration
Detail Design
Integrate and Test
Validation and Rampâ&#x2C6;&#x2019;Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
System level
Intermediate levels Component level ARS Design Tool
Figure 7.25: The intended application domains of the tools, methods, models/representations developed in Chapter 7 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2.
246
CHAPTER 7. THE ARS DESIGN TOOL
Chapter 8 The Genefke-POEM Tool This chapter presents a tool to support assessment of the complexity of a (potential) ARS solution with respect to the knowledge resources available to make it. The tool is largely based on the Genefke-Tool devised by my colleague at DTI, Kurt Bo Genefke, which is a tool to be utilised in a development context, perhaps with multiple partners, to identify early in the process the knowledge “dark-spots” that may prevent a particular solution from ever being realised, but also continuously to track the impact of new knowledge generated during a project. To apply this in an ARS context I have used the POEM system-level reference model as a tool to identify metrics by which the complexity of a solution can be measured. I call this hybrid tool the Genefke-POEM Tool. In the following I will first in Section 8.1 present the Genefke-scale and the rationale behind it, and in Section 8.2 give a quick overview of the Genefke-Tool and then explain how I have combined it with POEM to make a hybrid tool for ARS system complexity analysis in Section 8.3. Section 8.4 then presents the tool applied to two ServiceBot concept suggestions. The chapter closes with an evaluation in Section 8.5 and a conclusion in Section 8.6.
8.1
The Genefke-scale
The Genefke-scale (see Appendix B on page 283 for a detailed description), was developed at DTI – perhaps through the same observations as Kasser and Jackson and Keys – as the means to assess the development needs of an industrial robotic system (often manipulator 247
248
CHAPTER 8. THE GENEFKE-POEM TOOL
based) through a complexity measure based on both the process (the task) it carries out, the robots in the system, the controllable external components, the number of external sensors, and the amount of reference systems in existence. The complexity measure itself is an ordinal scale ranging from 1 to 5 indicating rising development needs as a function of rising complexity â&#x20AC;&#x201C; the function being monotonically increasing. Part of the rationale behind the Genefke-scale is that often as the complexity of a task rises in an industrial manipulator system, so does the complexity of the robot and thus the number of existing reference system decline which ultimately leads to higher development needs and time. Though simple in nature, the Genefke-scale has proven to be a useful tool when reaching consensus on the complexity of, for instance, a new development project; this consensus being possible because the perspective and purpose are clear to all parties.
In terms of designing ARSs the ideas behind the Genefke-scale can be readily utilised. However, the derivation of ARS categories equivalent to the Genefke-categories is not too obvious. Factors like the required level of robot autonomy, the number of robots in the system, the level of human-robot interaction, the level of robot-robot interaction, the task division between human and robots, the structure of the environment, etc. would all play a natural part in how we would assess the complexity level and thus how we would construct our categories. There is, however, no obvious mapping from these factors to a complexity metric as, for instance, an ARS comprising many robots is not necessarily more complex than one with few: compare an ARS for household cleaning comprising 20 Roombas to the Mars Pathfinder project or the Mars Exploration Rovers. Nor just because there is a highlevel of human-robot interaction in the system is it extremely complex: take, for example, Paro from Figure 2.4 on page 27. Nevertheless, at DTI we often refer to various types of robotic solutions as being a Category 1 through Category 5 even for robotic systems of non-industrial nature. Examples of such a use of the Genefke-scale can be seen in Figure 8.1 where several types of robots are shown mapped on the category scale from 1â&#x20AC;&#x201C;5.
8.1. THE GENEFKE-SCALE
249
R2D2
Asimo
5 Geminoid
Robotic Blood Sampling
4 Paro
Exoâ&#x2C6;&#x2019;sceleton
Binâ&#x2C6;&#x2019;picking Robot
3
Roomba
2
Robot Manipulator
Windmill
Washing machine
1
Figure 8.1: The system complexity/development needs of various types of robots according to the Genefkescale
This mapping is possible as we here, instead of focusing on the complexity of the system, rather focus on the perceived development needs of the system which are somewhat easier to grasp in terms of experience, availability of technology and knowledge, etc. The hypothesis being that an increase in development needs means an increase in system complexity regardless of the existence of explicit complexity metrics. This hypothesis seems to hold not only for traditional robotics but also in the realm of modern day robotics. It is, for instance, realistic to assume that the development of an ARS for household cleaning comprising 20 Roombas takes far less time than developing a Mars Exploration Rover, thus indicating that the Mars Exploration Rover is of a higher complexity. It is also realistic to assume that the development needs of Paro are less than those of, for instance, the Geminoid (see Figure 2.13 on page 57) developed by Hiroshi Ishiguro, indicating that the latter is more complex in spite of it being less engaged in human-robot interaction. Part of the reason why the hypothesis holds is that most ARS would fall in Category 3 through Category 5 in the original Genfke-scale meaning that, generally speaking, the development
250
CHAPTER 8. THE GENEFKE-POEM TOOL
time is measured in years rather than in months or weeks. This in turn means that there is a coarser grained variance in the development time of different ARSs making the estimates less sensitive to small scale (day or week) fluctuations.
8.2
The Genefke-Tool
The Genefke-Tool is a tool designed to facilitate project success by identifying dark-spots in the project’s know-how throughout a robotics project’s life-cycle, which Genefke regards as being from the initial phases of the project to about a year after the system is first made operational.
To identify missing know-how, Genefke applies his Genefke-Scale presented in Appendix B to assess the complexity of the required know-how for different parts of the project, the project know-how, and match this against the know-how actually present in the project among the participating partners, the Internal know-how, and the know-how present outside the project boundaries, the External know-how. For a standard industrial manipulator project, Genefke has identified 12 unique metrics by which each of these know-how criteria should be evaluated, and by entering these into a dedicated Excel sheet, a measure of the project’s missing know-how with respect to each metric can be established.
8.2. THE GENEFKE-TOOL
251
Figure 8.2: An example screen shot of the Genefke-Tool.
Figure 8.2 shows an example of the use of the Genefke-Tool. The 12 metrics can be seen on the left-hand side, and by entering the estimated complexity levels for both the project- (P), internal- (I), and external (E) know-how, the spreadsheet calculates the missing know-how in each case by “P − I” or “P − max(I, E)” (depending on the viewpoint)
and sums them to obtain some measure of the overall missing know-how in the project with respect to the solution in question. The tool assumes a linear complexity scale, meaning that moving from a “1” to a “2”, requires just as much extra know-how as moving from a “4” to a “5”. This is of course rarely (never?) true and the scale is in reality more likely to be exponential in nature. Nevertheless, the Genefke-scale makes it possible to compare complexities relatively in terms of “is-greater-than” or “is-less-than”, which on a system-level gives a hint on what development direction may be feasible. Besides the numerical output of the tool, Genefke applies also a visual representation of the complexity analysis by plotting a polygon map of the metrics for each know-how criteria, in a polar plot – a so-called radar diagram. Each map is constructed by plotting the complexity value for each metric along radial lines originating from the centre where the centre represents a “0” in complexity and the circumference a “5” in complexity.
252
CHAPTER 8. THE GENEFKE-POEM TOOL
This visualisation type facilitates an easy overview on the complexity of the whole system solution.
Figure 8.3: Two radar diagrams representing complexity analysis’s at two different points in a project’s life-cycle.
In Figure 8.3 two example radar diagrams from some project are shown at two different instances in time: the project start and when the system is made operational. Observe how the project complexity (yellow) decreases at several points as time progresses and how the internal know-how (green) grows. This indicates that internal knowledge has been obtained through the project – possibly also transferred from external (blue) side – and that the project complexity therefore decreases: when we know how to do something it often does not seem so complex. This illustrates the point that the Genefke-Tool is intended as a dynamic tool to be continuously updated through a project.
8.3
The hybrid tool
As stated in the beginning of this chapter, the hybrid tool is made as a combination of the Genefke-Tool and the POEM system-level reference model in order to facilitate systemlevel complexity analysis of autonomous robotic systems. This is done by discarding the
8.3. THE HYBRID TOOL
253
12 metrics that Genefke suggested and instead using POEM as a base for choosing system dependant metrics. The metrics are therefore project dependant, as opposed to the Genefke-Tool which employs the same set of metrics in the analysis of a wide range of industrial robotic solutions. However, the original metrics may also be applicable when analysing an ARS, but it may not always be obvious how to rank, for instance, “5. Material suitability for the process”. Also “9. Software in plant” may not make much sense when we are trying to capture a higher level of abstraction. So how do we choose the metrics based on POEM ?
As presented in Section 6.4 the four system-level subsystems of POEM each have a distinct definition which provides an excellent context for choosing four primary distinct metric-groups, each addressing their separate part of the system. As the five information paths among the four POEM subsystems convey information on how these subsystems mutually interact, it is natural to expand each of the four primary metric-groups by regarding where the information it handles originates from (source) and to where it provides it (sink). For instance, the metrics relating to the Perception subsystem must be chosen (and evaluated) with respect to the Entity and Mobility subsystems as these subsystems are the information sources, but also with respect to the Orchestrator subsystem which is the information sink. The result is that 10 metric-subgroups – each belonging to one of the four primary metric-groups – constitute the framework for defining the actual metrics. This framework is illustrated in Figure 8.4, where the numbers 1 through 10 each refer to a specific metric-subgroup with “red” indicating a source point and “blue” a sink.
254
CHAPTER 8. THE GENEFKE-POEM TOOL
P
1
E
10
2 9
3
4
8 7
O
5
6
M
Figure 8.4: Identifying the 10 metric-subgroups.
Choosing the actual metrics for a particular problem is now a matter of careful analysis of what information is actually important. One of the strengths of using POEM is that by choosing an appropriate set of metrics it will be possible to conduct complexity analysis of a wide range of possible solutions without making changes to them. Though this offers an obvious way of comparing analyses it may also be quite deceptive: making an analysis of two different solution scenarios with the same set of metrics without critical sense may cause important differences between the solutions to be missed. To minimise this risk, I suggest to choose a fairly high level-of-abstraction where possible, and a fairly low level-ofabstraction where needed. For instance, if we know that safety is an issue (which it often is), choosing a metric of “hazard-handling” over “collision-avoidance” may be preferred as the former may cover the latter. Analyses performed later in a project where more specific system decisions have been made, may cause the former to be substituted by the latter, but making such a choice prematurely may constrain the analysis and hinder direct comparisons between several solutions. Likewise, if we know that “stones” are an important part of the system, there is no need to conceal this fact by hiding them in some abstract metric – this will only make the results of the analysis less transparent. A feasible point-of-attack may therefore be first to identify the subsystems and components that are believed to be part of the Entity subsystem. The reason being that this subsystem contains all relevant elements from the environment, the objects to manipu-
8.3. THE HYBRID TOOL
255
late, and the obstacles to handle or avoid. In other words, this is possibly the subsystem comprising most tangible elements. Also the other system-level subsystems directly or indirectly interact with this subsystem and thus depend on its structure. Furthermore, the Entity subsystem is the subsystem with the lowest initial coupling to the solution, which makes it a good starting point. From here the subsystems and components of the Perception, the Mobility, and the Orchestrator subsystems may be defined. Now the metrics can be chosen for each of the identified subsystems with a firm basis in the problem at hand and within the context of the subsystemâ&#x20AC;&#x2122;s sources and sinks. The numbers of metrics and their level-of-detail have to be chosen to cover sufficiently the area in question such that the analysis will be as reliable as possible. This process is, of course, requires good knowledge of the problem domain and will often, to a large extent, be subjective. Evaluation of the results should therefore always be peer-reviewed and reiterated as necessary â&#x20AC;&#x201C; new things always pop up. To make a visual representation of the analysis we can, as with the Genefke-Tool, use the radar diagrams. By constraining the metrics belonging to a particular metric-group to a 90 degree slot of the radar diagram, it is possible to structure the result so that an easier identification of problems is possible. The segmentation used is shown in Figure 8.5.
Figure 8.5: Mapping POEM to the radar diagram.
256
8.4
CHAPTER 8. THE GENEFKE-POEM TOOL
ServiceBot: Complexity Assessment
In Section 4.5.7 I presented the results of a complexity assessment conducted on Concept I and Concept II of the ServiceBot case, by using the Genefke-POEM tool. This section explains how these results were obtained.
8.4.1
Defining Internal and External View
The Genefke-tool requires a complexity weighting of each metric with respect to Internal and External know-how. Luckily the University of Suburbia has a robotics department with quite skilled people in all aspects of robotics, and they have agreed to design and develop the final ServiceBot â&#x20AC;&#x201C; this department constitutes the Internal know-how reference. As the university is part of an excellent and international robotics network (called SuburbiaBotics Forum) they often collaborate with both industrial and academic parts from all over the world â&#x20AC;&#x201C; these partners constitute the External know-how reference. However, not to distinguish too much between the two I have chosen to use the same metrics for both.
8.4.2
Subsystem Components
The initial compiled list of possible subsystem and component candidates for the four system-level subsystems of POEM are presented below in short-form and is based on the previous results from the ServiceBot test case. It is emphasised that the list is not complete and is only meant as a reference point for choosing the initial metrics. As more analyses are conducted the list will converge towards the final system components. However, it at this point it gives an impression of how the process is started.
8.4. SERVICEBOT : COMPLEXITY ASSESSMENT
Subsystem
entities
Entity
Goods, Floor, Lines, Doors, Pick-and-place locations, Opera-
257
tors, People, Sofas, Overhead light, Bags, RFID-tags, Landmarks, Ceiling connection points. . . Orchestrator
Robot controllers, Operators,. . .
Mobility
Mobility Agents, Operators,. . .
Perception
Sensors, data handling, operator perception,. . .
Table 8.1: The initial list of POEM subsystem entities in the analysis made for ServiceBot.
8.4.3
The Genefke-Metrics
In the next sections I will present the final list of metrics used for the analysis. Each section presents a metric-group where each metric is grouped under some metric-subgroup â&#x20AC;&#x201C; colour coded and post-fixed in accordance with the numbering in Figure 8.4 â&#x20AC;&#x201C; with a short explanation of what it encompasses.
No formal methodology has been applied in choosing the particular metrics, but the analyses of the RTE-components and overall system-level aspects presented throughout the ServiceBot case study in Section 4.5, coupled with my knowledge of robotics and robotics research, has provided a lot of insight.
258 8.4.3.1
CHAPTER 8. THE GENEFKE-POEM TOOL Perception Subsystem
Entity 1 Pick-and-place localisa-
Location of Pick-and-place locations.
tion Obstacle Localisation
Location of all relevant types of obstacles in the system. This may include both bags, people, overhead lights, other robots, etc.
Goods Localisation
Location of the goods to be transported.
Operator Observations
The system operatorâ&#x20AC;&#x2122;s observations that is needed as input to the system.
Mobility 2 Mobility Localisation
Localisation of all Mobility elements (robots, operators, people, etc.) within the system.
Dynamic State Measure-
Measurements of all relevant (Mobility) dynamic states
ments
within the system - i.e. angles, velocities, attitudes, etc.
Orchestrator 3 Data Conversion
Conversion of all relevant data to formats required for further processing by both the Perception subsystem and by the Orchestrator subsystem.
Data Transmission
Transmission of data to the Orchestrator subsystem. This could be wires, Wi-Fi connections, speech, inductive, etc.
Sensor Fusion
Various sensor data will need fusion in order to obtain the required functionality.
Map Construction
Map of pick-and-place locations and locations of guidance system (lines, RFID-tags)
Situation Awareness
Assessing the situation correctly to handle all foreseen and unforeseen events is required â&#x20AC;&#x201C; especially to guarantee safe operation. Table 8.2: Metrics of the Perception Subsystem
8.4. SERVICEBOT : COMPLEXITY ASSESSMENT 8.4.3.2
259
Orchestrator Subsystem
Perception 4 Data Reception
The reception handling of data from the Perception subsystem.
Mobility 5 Mobility
Locomotion
The planning of motion for mobile units (robots) on either
Planning
the floor or the ceiling.
Mobility Pick-and-place
The planning of the pick-and-place operations. This will
Planning
naturally be the basis for the Locomotion Planning.
Mobility Operator Plan-
The planning of the human operatorâ&#x20AC;&#x2122;s tasks in the system.
ning
This may be conducted in part by the operator herself (brain) and by computer.
Orchestration Transmis-
All tasks required in handling and transmission of the
sion
orchestration, to the Mobility subsystem. This may be as complex as a data-marshalling, protocol assembly, and Wi-Fi transmission system, or as simple as a wire.
Hazard Handling
The handling of hazardous situations.
This could be
avoiding obstacles or avoiding that a ceiling crawler falls down. Table 8.3: Metrics of the Orchestrator Subsystem
260 8.4.3.3
CHAPTER 8. THE GENEFKE-POEM TOOL Mobility Subsystem
Orchestrator 6 Orchestration Handling
Handling of the data received from the Orchestration subsystem.
Operator Direction
The physical execution of tasks by an operator.
Perception 7 Mechanical Motion Sys-
The complete mechanical motion system (the mechani-
tem
cal and motion parts of the robots) which the Perception subsystem monitors.
Load/offload Goods Sys-
The complete mechanical motion system (the mechanical
tem
and motion parts of the load/offload system) which the Perception subsystem monitors.
Entity 8 Locomotion Execution
The system responsible for carrying out the locomotion on either the ground or the ceiling.
Table 8.4: Metrics of the Mobility Subsystem
8.4.3.4
Entity Subsystem
Mobility 9 N/A Perception 10 N/A Table 8.5: Metrics of the Entity Subsystem
8.4.4
Performing the analysis
Each metric is now ranked by a Genefke-scale number from 1 to 5 with respect to each of the two concepts. The number represents the complexity of handling the particular metric,
8.4. SERVICEBOT : COMPLEXITY ASSESSMENT
261
that is, the anticipated level of development needed to realise that particular metric in the particular solution scenario. The Internal and External know-how is also ranked with respect to each metric. This is done by making a qualified guess on the collected know-how in the robotics department of University of Suburbia and of the “state-of-the-art” know-how in the SuburbiaBotics Forum – coincidentally these two values are equal as explained earlier. To aid readability numbers shown in red indicate knowledge dark-spots, that is, where the value of a concept metric exceeds the value of the know-how. Table 8.6: The complexity analyses of the purposed ServiceBot concepts.
Int.
Ext.
I
II
Pick-and-place localisation
3
3
1
2
Obstacle Localisation
3
3
3
1
Goods Localisation
3
3
2
4
Operator Observations
3
3
1
1
Mobility Localisation
4
4
3
3
Dynamic State Measurements
4
4
3
4
Data Conversion
3
3
2
2
Data Transmission
3
3
2
2
Sensor Fusion
4
4
4
4
Map Construction
3
3
2
4
Situation Awareness
3
3
4
4
3
3
2
2
4
4
3.5
4.5
Perception Subsystem Entity 1
Mobility 2
Orchestrator 3
Orchestrator Subsystem Perception 4 Data Reception Mobility 5 Mobility Locomotion Planning
Continued on next page
262
CHAPTER 8. THE GENEFKE-POEM TOOL Table 8.6 – continued from previous page Int.
Ext.
I
II
Mobility P–and–P Planning
4
4
3.5
4.5
Mobility Operator Planning
4
4
2
2
Orchestration Transmission
4
4
3
3
Hazard Handling
3
3
3
4.5
Orchestration Handling
3
3
2.5
2.5
Operator Direction
3
3
1
1
Mechanical Motion System
3.5
3.5
3.5
4.5
Load/offload Goods System
3.5
3.5
3.5
4.5
4
4
3.5
4.5
1.0
8.0
Mobility Subsystem Orchestrator 6
Perception 7
Entity 8 Locomotion Execution Entity Subsystem Mobility 9 N/A Perception 10 N/A Missing Knowhow
8.4.5
Interpreting the results
From the values in Table 8.6 it can be observed that the missing know-how is calculated as being 1.0 for Concept I, and 8.0 for Concept II. To explain these values consider Figure 8.6 showing all the metric values of both Concept I (red), Concept II (green), and the internal/external know-how (yellow) in one radar diagram.
8.4. SERVICEBOT : COMPLEXITY ASSESSMENT
263
Figure 8.6: The radar diagram of the 2 purposed ServiceBot concepts shown together using: Red: Concept I, Green: Concept II, Yellow: Internal/External know-how.
264
CHAPTER 8. THE GENEFKE-POEM TOOL
What is immediately clear is that Concept II has several metrics (nine, in fact) where the value is estimated to exceed the current know-how in the project (also marked in red in Table 8.6). This indicates that significant amounts of knowledge will have to be generated in order to realise the concept. These metrics are mainly found in the Mobility and Orchestrator subsystems which is a consequence of a presumably quite complex mechanical structure, unclear concepts of how its motion planning should be conducted, and how pick-and-place operations should actually be done. Only in one metric have I assessed Concept II to require less efforts than Concept I: Obstacle Localisation. As the Concept II has only one identified Disabler, the overhead lights, (see Section 4.5.7) these should be quite easy to locate compared to people, bags, sofas, etc. which are Disablers of Concept I. Though the missing know-how of “1.0” and “8.0” seem like arbitrary values, they do constitute a good comparative indicator between the concepts. As “0” indicates that all know-how is available to realise the project, “1” could be interpreted as some new know-how is required – “8” then represents a significant need for additional know-how. Concluding that Concept II is a “significantly more complex” concept than Concept I is therefore not entirely misguided.
8.5
Evaluation
The conclusions reached in the ServiceBot test case are hardly surprising. I guess that most readers with some knowledge of robotics had already reached the same conclusion without even reading this section. So why is the Genefke-POEM tool useful? Because it provides the user and other project stakeholders with a structured/rational setting for handling a particular problem, as is similarly provided by the RTE-representation, the methods and tools of the Concept Generation Framework, the POEM model, and the ARS Design Tool, in their respective areas. This setting makes it possible to identify and discuss not only what the “dark-spots” are, but also where they are, how they affect other parts of the system, and how severe they are. In the ServiceBot example it was through the process of identifying the metrics that it became clear, that though the mechanical complexity was somewhat self-evident, its specific effects on the Orchestrator and Perception subsystems were not. These were elucidate through the process. As each metric was assessed it also became evident how severe the missing knowledge was, which provides the user and project
8.6. CONCLUSION
265
stakeholders (the ARS designer in our case ) with specific knowledge of where particular design or development efforts should be made. So, yes, in the ServiceBot case it may have been obvious from the beginning that Concept II was much more complex than Concept I, but through the process of using the Genefke-POEM tool it could be determined exactly how this complexity was manifested in the system. This, I believe, represents a valuable contribution to the ARS design effort. Though the ServiceBot example was quite simple, I have previously applied the GenefkePOEM tool in a slightly more elaborate real-world context in the EU project PV-Servitor of which DTI is partner. The PV-Servitor project, partially funded by the FP7 SME programme, is about using robot technology to autonomously clean Photo Voltaic (PV) solar panels, and in this context I successfully used the Genefke-POEM tool to analyse the complexity of six different solution scenarios. These results were disseminated in the project consortium and in an externally (EU) reviewed project deliverable – both with positive results. However, I have not used the tool beyond the preliminary design phases and thus have no experience with incorporating it into the full life-cycle of a design process as illustrated in Figure 8.3 on page 252. Experiences from extensive use of the original Genefke-tool at DTI, however, indicates that this should not pose any particular difficulties – but it will have to be assessed.
8.6
Conclusion
This chapter presented a hybrid tool called the Genefke-POEM -tool to support assessment of the complexity of a (potential) ARS solution with respect to the knowledge resources available to make it. The tool is based on the Genefke-tool developed by my colleague at DTI, Kurt Bo Genefke, and utilises the POEM system-level reference model to identify metrics by which the complexity of a solution can be measured. To illustrate the use of the tool I presented an analysis of two concepts from the ServiceBot running example and afterwards I provided a discussion on the tool’s general validity as well as how I have applied it in real-world contexts so far. To summarise, the Genefke-POEM Tool presented in this chapter, has the intended application domain shown in Figure 8.7. The tool is applicable from the concept devel-
266
CHAPTER 8. THE GENEFKE-POEM TOOL
opment phases (as illustrated with the ServiceBot example) to the end of the life-cycle, spanning the system-level, the intermediate levels, and parts of the component level.
Planning
Concept Development
System−level Design
Concept Development
Needs Analysis
Concept Exploration
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
System level
Intermediate levels Genefke−POEM Tool
Component level
Figure 8.7: The intended application domains of the tools, methods, models/representations developed in Chapter 8 shown with respect to the design life-cycle as presented in Figure 4.8 and the system-level and component-level overview shown in Figure 1.2.
Chapter 9 Conclusions 9.1
Summary of Achievements
This dissertation proposes the initial steps towards a rational system-level design methodology for autonomous robotic system, and has through the last eight chapters established the necessary foundation for doing so. In the introduction to this dissertation six main objectives were listed as being key to addressing this challenge. They were:
1)
To analyse the system-level challenges
2)
To establish a system-level model for characterising an ARS in terms of its physical components
3)
To provide the initial steps of a design methodology suitable for designing autonomous robotic systems
4)
To define a structured system view able to handle different levelsof-abstraction from the system-level to the component-level facilitating a handling of the complex system couplings
5)
To define a unified system-level reference model of an ARS able to serve as the foundation for designing any ARS
6)
To provide a set of tools that will aid the designer in the design process Table 9.1: The six overall objectives of this thesis.
267
268
CHAPTER 9. CONCLUSIONS
If we combine the contributions from the chapters the following list of contributions emerge: 1. To analyse the system-level challenges (Chapter 2) • The required system properties for dependability issues and ELS compliance were established, and the need for a method to conduct a system-level assess-
ment of which dependability and ELS compliance criteria are the most relevant to a specific design problem was motivated. • The conclusion that the new generation of robotic systems are socio-technical
systems and must be treated as such in the design process, was made. It was argued that properly to address socio-technical issues in ARS design we need to include people from different backgrounds than just the technical in the design process.
• The need for a complexity measure that will allow the ARS designer to assess the complexity of robotic systems from various levels of abstraction was establish
and also the need for methods, tools, and guidelines for handling the component and interaction complexity inherent to socio-technical robotic systems, was motivated. • The need for using a broad systems-view in the ARS design process to address the challenges, was strengthened.
2. To establish a system-level model for characterising an ARS in terms of its physical components (Chapter 3) • The RTE-representation was introduced able to represent the physical entities of the Task* -, Environment* -, and Robots-components of an ARS.
• The ARS Continuum was introduced as a model to characterise an ARS by ranking its three components in the order of how much they contribute to the overall success of the system. 3. To provide the initial steps of a design methodology suitable for designing autonomous robotic systems (Chapter 4) • I have addressed what it implies to design an ARS, that is, what it means to transit from a Problem to a Solution, thus creating an ARS instantiation.
9.1. SUMMARY OF ACHIEVEMENTS
269
• The ARS Resolver, the ARS Solver, and the ARS Dissolver as a classification of the three ways an ARS can address a Problem, were presented.
• A discussion of important system-level ARS design considerations leading to
the creation of the Design Considerations Reference Sheet which represents a summary of the design considerations.
• An ARS System-level Concept Generation Framework which illustrates how ad-
dressed design considerations coupled with a devised decision-making methodology specifically addressing Dependability and ELS compliance issues, can be used to generate and assess Solution concepts.
4. To define a structured system view able to handle different levels-of-abstraction from the system-level to the component-level facilitating a handling of the complex system couplings (Chapter 6) • The definition of the sDSM (system Design Structure Matrix), a novel type of DSM which effectively can represent a system-hierarchy at all levels simultaneously. • The definition of the Emergence Hierarchy – a dynamic hierarchy representation
based on the emergent properties of subsystems rather than on their functional properties. The Emergence Hierarchy is able simultaneously to represent a system at several levels-of-abstraction.
5. To define a unified system-level reference model of an ARS able to serve as the foundation for designing any ARS (Chapter 6) • The definition of POEM – a novel system-level reference model which I claim is able to represent any ARS.
6. To provide a set of tools that will aid the designer in the design process (Chapter 7 and Chapter 8) • The ARS Design Tool – a tool facilitating both ARS design and analysis based on POEM and the manipulations of the Emergence Hierarchy.
• The elaboration of the Genefke-scale’s ability to represent development-need as a complexity measure.
270
CHAPTER 9. CONCLUSIONS • The Genefke-POEM – supports the assessment of the complexity of a (potential) ARS solution with respect to the knowledge resources available to make it.
As can be observed all objectives have been covered: I have identified a necessary bodyof-knowledge comprising, not only the main contributions listed, but also the knowledge generated in the discussions and suggestions presented throughout the dissertation. Furthermore, I have established a model for characterising an ARS in terms of its physical components, provided a set of necessary system-level design considerations, provided a suggestion for the overall structure of the design methodology, presented methods for generating concepts, and a methodology for the evaluation of Dependency and ELS compliance issues. To represent an ARS properly in a design context I first devised a system-view based on emergent properties able to handle different levels-of-abstraction from the system-level to the component-level facilitating a handling of complex system couplings. I then devised a unified system-level model able to encompass all ARSs – that is the claim until proven otherwise – and showed how it in combination with the system representation could form an ARS design tool able to aid the ARS designer in her task. Furthermore I showed how the system-level model can be used together with the Genefke-tool to provide a hybrid tool for ARS complexity analyses.
To see these results from a slightly different perspective, Figure 9.1 presents the intended application domains of all the core tools, methods, and models/representations with respect to the ARS design life-cycle and the system-level and component-level. Furthermore I have illustrated the contributions of this thesis as the coverage (green) of the software engineering model [Kossiakoff and Sweet 2003], where larger coverage indicates larger contribution.
9.2. FUTURE WORK
271
Concept Development
Planning
System−level Design
Concept Development
Needs Analysis
System level
Concept Exploration RTE−representation ARS design approach
Detail Design
Integrate and Test
Validation and Ramp−Up
Integration & Evaluation
Production
Engineering Development
Concept Definition
Advanced Development
Engineering Design
Post Development
Operation & Support
ARS Continuum
POEM
Design Considerations Reference Sheet Dependability and ELS assessment methodology
Intermediate levels
Concept Generation Framework Genefke−POEM Tool
Component level Emergence Hierarchy ARS Design Tool
Figure 9.1: The intended application domains of all the tools, methods, and models/representations shown with respect to the ARS design life-cycle and the system-level and component-level. The areas addressed by this thesis (green) have been mapped to the software engineering model [Kossiakoff and Sweet 2003] – larger coverage of a phase indicates a larger contribution.
As can be observed, the contributions mostly, of course, address the system-level aspects of the design process where in particular the Concept Exploration and the Concept Definition stages have been the main focus. That leaves a rather large portion of the design process unaddressed, both in terms of development stages but also in terms of the component-level. Nevertheless, these contributions together form the initial steps towards a rational system-level design methodology, which was the overall goal of this PhD project.
9.2
Future Work
As the work presented in this dissertation is a first contribution to a field that slowly – but surely – gains wider acceptance in both academia and the industry, there is obviously room for future improvements in many areas. One of the larger “holes” I have left wide open is the actual real-world testing of the design methodology as only few of the methods, tools, and models have actually been tested in real-life scenarios. To facilitate this, appropriate test scenarios should be chosen and the methodology applied one step at a time to properly assess what works and what does not. It has been suggested to me to conduct initial tests of the methodology using “simple” methods like XP or SCRUM, which I believe to be a feasible initial approach. This way the phases of the methodology could be easily populated and the results would provide valuable input to the next iteration.
272
CHAPTER 9. CONCLUSIONS
Another â&#x20AC;&#x153;holeâ&#x20AC;? is the unresolved transition from the RTE-representation to an Emergence Hierarchy with POEM at the system-level. As addressed in Section 6.5 an initial approach to addressing this problem in a broader perspective could be to conduct both a syntactic and a sematic analysis of as many different robotic system models as possible, and from these results try to elucidate how many levels-of-abstraction typically are used to describe a robotic system, what names are commonly used, and what the individual subsystems and components actually do. Another area of interest for future research is the exploration of how to choose the right components at the right time, as briefly addressed in Section 4.3.4. Further investigations of the suggested readings would serve as a sensible starting point. In order for the ARS Design Tool to be a real asset in an ARS design situation, a more structured (and stabile) version should be implemented, and as discussed earlier, the use of subsystem design patterns may prove to be a most interesting research topic. Also the investigation of what existing DSM tools could be feasible to incorporate in the tool, and what new sDSM tools could be developed to service the design or analysis process, would be interesting areas.
Appendix A The Comic This appendix contains a small comic I made in conjunction with the AUTOMATICA 2008 robotics-fair in Munich. The idea was to test a different kind of dissemination activity contrasting the usual scientific papers and lecturing activities, by using the comic as the medium. The objective of the storyline was to give the reader a rather humorous overview of some of the problems and pitfalls that may exist in the development process of a robotic system. It was printed in 400 copies and placed at the booth we had at the â&#x20AC;?Service Robots Areaâ&#x20AC;? where also Fraunhofer IPA, BlueBotics and several other institutions/companies were represented. During the 5 day fair I managed to hand out close to 200 copies and had several fruitful discussions about robotics design with the visitors. A surprisingly high number of readers with their own experiences in robotic design came to me and expressed great interest in my project and acknowledged the problems I was attempting to tackle.
273
Thanks to: My colleagues and Mette at RoboCluster
PhotoShop magic: Line Birgitte Borgersen
Story and drawings: Lars Dalgaard
lars.dalgaard@teknologisk.dk
by Lars Dalgaard Danish Technological Institute June 2008
How Mobile Robotic Systems are Realised…
Lars Dalgaard
DISCLAIMER: This comic is a work of fiction and any resemblance to events or actual persons, living or dead, is not entirely unintentional and 42% coincidental.
Lars Dalgaard is an Industrial PhD student at the Danish Technological Institute, Institute Centre for Robot Technology, Technology writing his thesis entitled: “A System-level Design Methodology for Autonomous Robotic Systems”. He holds a masters degree in Computer Systems Engineering from the University of Southern Denmark, 2001, and has since graduation co-owned a mobile robot company, worked as a university research assistant, taught automation to engineering students and supervised several bachelor and master thesis projects. This work is his first attempt as a comic artist.
Enjoy!
This comic is made to illustrate some of the pitfalls existing in the way that robotic systems are realised today. It is intended not only as a food-for-thought but also as an eye-opener.
Too often ad-hoc approaches are used to tackle the integration of the various system components. In the worst cases this results in systems that do not perform as intended.
A robotic system comprises not only physical robots but also the tasks they are required to perform and the environment in which they operate. It is a very complex entity which is less than trivial to conceive, design and realise.
Introduction
274 APPENDIX A. THE COMIC
Electrician
SensorEngineer
PLC-Guy
ITEngineer
Gardener
FC-Official
RobotResearcher
Machinist
The People of our Story
The FC-Officials called the local Machinist to enquire about the possibilities of having a robot custom-built.
”We should get a mobile robot to mow our fields”, one of the FC-Officials thought. Unfortunately no fully automatic industrial solutions existed.
The football club, FC, was having economic problems and had no way of paying for a new truck and a new gardener.
Once upon a time a small football club had to say goodbye to their faithful Gardener and his football field mowing-truck – they were both retiring.
275
The Machinist started constructing the platform and before long it was finished: a nice frame with wheels, gears, motors and a grass-cutter underneath.
He called the PLC-Guy and the Sensor-Engineer who were very impressed by the result. “But how do we power the robot?”, asked the PLC-Guy. “We use a battery”, the SensorEngineer replied – “no question about that!”.
The PLC-Guy quickly called the Machinist and said he would be able solve the control problem together with the Sensor-Engineer. The Machinist was sure that the FC-Officials would be very happy.
The Machinist knew of two very common principles of steering for a vehicle: carsteering and tanksteering. He pondered which to choose and settled for tanksteering.
But the PLC-Guy was a bit unsure of how to constrain the robot to move just within the field…
…so he called his friend the Sensor-Engineer who suggested using a GPS system to always tell the robot where it was, thus making it aware if it was violating any boundaries.
The Machinist made a few calculations regarding the production cost and production time and called the FC-Officials who happily accepted the offer. Thus the project began…
The Machinist called his friend the PLC-Guy and asked him if he had any idea of what PLC system to use and how to program the robot’s movements. The PLCGuy thought he knew exactly how.
276 APPENDIX A. THE COMIC
After installing the gyroscope the robot worked much better (except for some difficulties in calibrating the gyroscope due to an annoying temperature drift).
The Sensor-Engineer called a Robot-Researcher at the university who said that it would not be a problem to devise a new algorithm provided that additional sensor input was obtained. “We can use a gyroscope”, said the Sensor-Engineer and it was decided to buy one.
Full of anticipation the group brought the robot to the football club and placed it on the grass…
…but to their disappointment it did not work very well: several spots of grass were left uncut. They discovered that it was because the robot did not turn as expected. But why was that??
Changing the tyres helped but it was unfortunately not enough. “Maybe we can solve the problem by using smarter software”, the SensorEngineer suggested.
They discovered the culprit: the soft grass made the wheels spin creating an error on the positional encoders. “We may be able to solve the problem by using wider tyres”, the Machinist thought.
The PLC-Guy made a simple PLC-program that enabled the robot to cover an area completely, as required by the FC-Officials. They tested it outside the Machinist’s workshop and it worked like a charm.
After mounting the battery, the PLC system and the GPS, the robot platform was ready.
277
The FC-Officials now had yet another problem: they thought the robot was mowing the grass too slowly. At the current driving speed it would take too long to finish the job.
The Machinist, the Sensor-Engineer and the PLC-Guy were thrilled that they had found a solution. The FC-Officials on the other hand were not too happy – the price of the safety system was very very high.
The Machinist knew a little about safety systems and thought that that was what they needed. He called his Electrician who immediately suggested using a couple of safety laser scanners.
“Doesn’t that just make the robot dangerous?”, the FCOfficials argued.
The PLC-Guy knew it was a software issue but didn’t know what to do. So he called the Robot-Researcher who suggested two different solutions based on softer turning curves.
The PLC-Guy implemented the new steering algorithm and it worked perfectly. The Machinist, however, thought that had he used the car-steering principle instead they might have solved the problem more easily – but he kept that to himself.
“Well, we can just increase the robot’s velocity”, the PLC-Guy said. “That should solve the problem…”.
However, the FC-Officials were not entirely satisfied: when the robot made its two 90 degree turns, one wheel dug a small hole in the grass because it was turning around its own axis. In case of rain, puddles would therefore form around the circumference of the football field.
278 APPENDIX A. THE COMIC
“What if we place it in the shed where the robot is kept while its offline?”, the Machinist proposed. This seemed convenient, they all agreed, since the shed was easily locatable using the GPS system. So it was done.
However, the FCOfficials were still not entirely satisfied: the robot was only able to mow a very few fields before it ran out of power. Since recharging required human help, the situation was not good!
After establishing the charging station a big problem was discovered: since the shed was located close to some big trees, the GPS system would lose contact with some of the satellites causing a location error. This error was severe.
“What if we create a charging station where the robot automatically can go when it needs to be recharged?”, the PLCGuy suggested. The others thought it was a great idea! But where should such a station be placed?
The group implemented the safety system and increased the robot’s velocity to meet the needs of the FCOfficials – and it worked! Now the robot would stop if something got in its way, before causing any harm.
“Why don’t you just size up the battery? – that should take care of things”, the Electrician suggested.
The FC-Officials were not happy with that solution: “The weight of the bigger battery will make the robot too heavy and it will compact the soil. This will damage the grass and leave puddles after a shower!”, they protested. (Besides there was no space for a bigger battery.)
The FC-Officials were not really satisfied about the progress of the project so far: the price had gone up and the deadline had already been missed by two months! But they thought it was too late to pull out so they complied…
279
“Not yet”, the FC-Officials objected. “Where is the PC software that makes it possible for us to control the robot from our club house?”, they asked. “We cannot use the robot without that.”
After a couple of weeks of writing new software and integrating new sensors, the robot was finally able to find the charger all by itself. The group cheered because now they thought the system was finally finished.
“No problem”, the Robot-Researcher said, “I’ll devise an algorithm for you based on the various sensor information you have”. And so he started. After some time he finally had exactly what was needed.
“Hmmm…”, the Sensor-Engineer thought, “we might be able to solve this problem by adding some more sensors on the robot, to provide a stable position reading even without all the GPS satellites.” He knew exactly what sensors to buy but he did not know how to combine all the different sensor readings into navigational information for the robot. Once again he called the Robot-Researcher and asked for his help.
“But how do we communicate wirelessly between the PC and the PLC?”, the IT-Engineer asked the PLC-Guy. “No problem,” the PLC-Guy said, “we just have to add a wireless extension board to the PLC and then it will work.”
…and before long, the IT-Engineer had made a software specification for the PC software. The FC-Officials were very happy about it and said that that was exactly what they wanted.
The IT-Engineer went to the football club to get as much information from the FC-Officials as possible, so as to make a good software specification. The FCOfficials were very happy to answer all the IT-Engineer’s questions…
The Robot-Researcher knew of an IT-Engineer who could possibly help them out. He called her up and presented the case. “No problem,” the IT-Engineer said, “I’ll get right on it!”
280 APPENDIX A. THE COMIC
Did the robot system actually work as intended? Well, the football club realised that one too many chunks of grass were left uncut after the robot had been there, so they hired the old pensioned Gardener for a couple of hours a week to do “manual corrections”. But they accepted that as part of having a custom-built robot system. After all that’s what to expect! Or is it…?
EPILOG:
Though happy that the robot system was working (but not looking exactly as they had hoped) the FC-Officials were not too happy about the final bill – or the delays that had occurred – but what could they have done?
The robot system was finally finished and it worked pretty well. Of course, there were a lot of small issues and inconveniences but after all everybody was happy that it worked as well as it did.
The IT-Engineer was now ready to start programming the PC software, and within a couple of weeks she was done. She couldn’t help wondering why the robot itself was controlled by a PLC platform and not by a PC platform running Java, which she thought would have made everything easier but she kept her thoughts to herself.
Its Centre for Robot Technology is engaged in three main areas: 1) Robots for grasping and handling, 2) socially-intelligent robots and 3) robots for agriculture. Currently it is involved in more than 20 R&D projects within the field of robotics and possesses broad expertises in all relevant technological and management areas.
Danish Technological Institute is an independent, not-for-profit institution approved by the Danish authorities to provide technological services to business and the community. The Institute adopts an interdisciplinary approach to innovation and to the task of improving the ability of small and medium-sized companies to exploit new technologies and management tools.
For more information on this work please visit:
This production represents the ongoing process of a PhD project that aims at devising a rational design methodology for mobile robotic systems facilitating all aspects of such a design process. The project is a collaboration between the Danish Technological Institute and The University of Southern Denmark.
As the story shows, the design and realisation of a robotic system requires competences from a broad range of technical as well as management areas. The task of creating a robotic system that functions as required, on time and on budget is therefore a highly demanding undertaking which unfortunately only too few people master.
So What Can Be Done?
281
282
APPENDIX A. THE COMIC
Appendix B
The Genefke-scale
At DTI my colleague, Kurt Bo Genefke, has established what we refer to as the Genefkescale based on many years of practical experience in integrating industrial robots in manufacturing. The Genefke-scale is a categorisation of industrial robotic solutions based on their complexity versus their corresponding development needs where the development needs increase as the complexity rises. The complexity axis is discrete and represents the complexity in an ordinal integer scale from 1 through 5 indicating an increasing complexity – we thus denote all solutions within a certain complexity range, N , as ”Category N solutions”. The scale is shown in Figure B.1. It should be noted that the figure seems to indicate a linear relationship between complexity and development needs which is of course not the case – it is probably of a more exponential nature. For instance, the difference in development needs between a Category 1 and Category 2 solution is very much smaller than the difference between a Category 4 and Category 5. 283
284
APPENDIX B. THE GENEFKE-SCALE
Figure B.1: The Genefke-scale.
To get a better understanding of what types of solutions belong to a certain category, headlines have been assigned to each of them and below are short descriptions of what they cover. Category 1: Simple Standard Solutions Comprises off-the-shelf solutions with single robots performing trivial tasks, for instance, palletting or simple pick-and-place operations. The process is very simple. A huge number of reference systems exist in the production industry today. Category 2: Adjusted Standard Solutions Comprises off-the-shelf solutions adapted to specific tasks where multiple robots may work at the same time but with no overlapping work-spaces. No or few external axis’s. This category comprises simple assembly line manipulators and some types of welding robots. The robots are known as ”process robots”. Many reference systems exist in the production industry. Category 3: Special Solutions Solutions that require acquisition of new knowledge through practical projects to solve the technical challenges. Simple external sensor input may be available and several robots may work together with overlapping work-spaces. The process is now an inherent part of the total solution. Furthermore external axis may also be controlled. No identical reference systems exist but parts may exist in other solutions.
285 Category 4: Applied Research Solutions so complex, that robot-suppliers have to seek support from specialised knowledge centres to succeed with initial projects. This category is often partly financed by development funding. The process is now very complicated and relies on multiple external sensor inputs and may involve several external axis. No identical reference system exists but parts of it may exist in other solutions. No identical reference systems exist but parts may or may not exist in other solutions. Category 5: Research Research projects, that only have industrial interest on a very long time scale. The solutions are unlike anything previously seen comprising cooperative robots, mobile robots, new types of sensors, new types of environments, and so forth. No reference system exists. As can be seen from the above list, Genefke measures complexity as a composition of both the the process (the task), the robots, the controllable external components, the amount of external sensors, and the amount of needed new R&D. Though directed at industrial (mainly manipulator) systems, the metric makes
Figure B.2: The Lynex Lx 1000 re-
good sense in other robotics domains as well, as the
mote controlled lawnmower, developed and sold by Lynex, ˚ Alsøvej 2, 8240 Ris-
more complex the task is it is likely that the robot and the external world become equally more complex.
skov, Denmark, with a combustion engine of 22 HP and a total weight of
Counterexamples may be found of this statement, but 290 kg. as a general and simple measure of robotic system complexity, it does make good sense and is quite suitable for broad communication. In fact, at DTI we apply it broadly both when discussing new development projects, when addressing the application and introduction of welfare-robots like Paro (see Figure 2.4 on page 27) and when participating in already existing projects like the Casmobot-project1 where a semi-autonomous lawn-mowing robot is produced from a remote controlled robot – the Lynex seen in Figure B.2 – retrofitted with a GPS system and a Nintendo Wii remote (this was classified as a Category 3). The robotic R&D projects we participate in at DTI are typically found in Category 3-4 meaning that they are essentially system-solutions in the broad sense and often requiring 1
http://www.fieldrobot.dk/index.php/casmobot
286
APPENDIX B. THE GENEFKE-SCALE
collaborations with universities to conduct the necessary research and companies as either end-users and/or the supplier of technical components. The goals of these projects are often to create knowledge that allow for similar systems to be obtained in the future but now instead as Category 2-3 which indicates an overall reduction in system complexity.
Appendix C The ServiceBot pictures
(a)
(b)
(c)
(d)
Figure C.1: The corridors and pathways at University of Suburbia
.
287
288
APPENDIX C. THE SERVICEBOT PICTURES
(a)
(b)
(c)
(d)
(e)
(f) Figure C.2: Junctions and turns
.
289
(a) Figure C.3: An elevator exit
.
(a)
(b) Figure C.4: Obstacles
.
290
APPENDIX C. THE SERVICEBOT PICTURES
(a)
(b)
(c)
(d)
Figure C.5: “Broken” lines, colour differences in the floor, and distances to objects
.
(a) Figure C.6: The structure of the ceiling above the corridors and pathways
.
Appendix D The Properties and Structure of the Design Methodology
Design Methodology Problem
Solution (ARS) Task*
Task Environment
Design Process
Environment * Robots
Requirements
Figure D.1: The design methodology.
In Section 4.1 of Chapter 4 I presented what it implies to fully design an ARS, that is, what it means to transit from a Problem to a Solution. In this Appendix, I will present a slightly revised version of the paper [Dalgaard and Hallam 2009] which dealt with the properties and structure of the design methodology necessary to facilitate this complete transition as shown in Figure D.1. Section D.1 will establish 11 necessary properties of the methodology which in Section D.2 is compared to a selection of known methods to establish what the structure of the methodology should be. This final structure is then presented in Section D.3. 291
292
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
D.1
Properties of the Design Methodology
In order to ensure that the design methodology will provide the necessary means to handle effectively a design process that results in sufficient system designs, the process structure must be well established. Seeking inspiration in Software Engineering, we find that Mathiassen and Stage [1992] argue that “the basic characteristics of a design solution are described in terms of their degree of complexity and their degree of uncertainty”, where the degree of complexity is the amount of relevant information available in a given situation and the degree of uncertainty is the availability and reliability of this information. The design process is thus about balancing these parameters by choosing a mode of operation, which can be either analytical or experimental, and the means of expression, which can be either specifications or prototypes. Mathiassen and Stage [1992] summarise their results in what they call “The Principle of Limited Reduction”: Relying on an analytical mode of operation to reduce the complexity introduces new sources of uncertainty requiring experimental countermeasures. Correspondingly, relying on an experimental mode of operation to reduce uncertainty introduces new sources of complexity requiring analytical countermeasures. [Mathiassen and Stage 1992] In short, they argue that a successful design process of a complex (software) system has to comprise both analytical and experimental modes of operation and both specifications and prototypes as means of expression. At the same time these characteristics lay the ground work for comparing and combining different approaches. The design process of robotic systems bears close resemblance to that of a designing a software system, since both need a constant focus on the system-level whilst developing the sub-systems. At the same time both utilise concepts of experiments, prototypes, specifications and analytical methods, and both are constrained by system and sub-system requirements. Software is also often developed in teams and requires expertise from different domains, just like robotic systems, and both have a strong need for concise and useable documentation, and for careful planning. Differences between the two domains also exist. One major difference is the cost of materials in the physical construction of the prototypes or the final product. While a
D.1. PROPERTIES OF THE DESIGN METHODOLOGY
293
software framework can be easily implemented and tested, the mechanical and electronic parts of a robot may take months to construct even after a design has been made. This puts a natural economical constraint on robotic design also supported by the fact that an extra prototype may severely increase the project budget â&#x20AC;&#x201C; this is normally not the case for software design. The implication is that a more stringent and rational approach is needed when dealing with robotics design than for software design. In the following sections, 11 necessary properties for the design methodology are proposed. These necessary properties have emerged as a result of discussions from the previous chapters and thus both directly and indirectly address several of these aspects. The list should be regarded as preliminary as new properties may be found that may prove to be equally necessary, however, I believe this selection to form a sufficient initial set. The properties are as follows: 1. Facilitate a rational design process 2. Facilitate iterations 3. Offer the means to evaluate the fitness of a design 4. Facilitate collaborative design 5. Facilitate the construction of prototypes and experimental setups 6. Produce process deliverables 7. Facilitate different design tools 8. Be easy to explain and use 9. Allow for different levels of generalisation 10. Allow for different levels of autonomy 11. Produce design documentation
294
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
D.1.1
Facilitate a rational design process
Characterising a design process as rational implies that every step taken is always on the optimal path to the goal [Parnas and Clements 1986]. Such processes only exist in theory since it would imply that they were ideal in every way and that the designer had access to all required knowledge and information at any desired point in time. Unfortunately this is rarely the case â&#x20AC;&#x201C; see also the discussion of bounded rationality in Section 1.2.2. However, since the initial problem and the goal of the process are known in our case, it is possible to construct a measure of progress and thereby the means to detect if the design choices made are bringing the design closer to the goal. This essentially allows us to fake a rational design process, as described by Parnas and Clements [1986], by following the ideal process as closely as possible and producing the documentation we would have produced had it indeed been rational. The main reason for doing so is to help the designer structure the design process by facilitating a standard procedure of what-to-do-next. On one hand this greatly reduces the number of ad-hoc design decisions thus resulting in a sounder design process and a better product. On the other hand, the process is much easier to review making the transfer of people, ideas and technology from one project to another easier.
D.1.2
Facilitate iterations
A strictly sequential development model consists of a set of disjoint phases where the completion of one phase is required before a new phase can commence. A functioning system will not exist before the completion of the final phase. Designing robotic systems cannot only follow such a model for two reasons: first, the system level impact of even a rational choice made at the final design stage is not fully predictable, let alone resolvable, at earlier stages; second, developing component prototypes and conducting experiments are integral parts of a robotic system design process since this is often the only way to gather the necessary information needed to make rational decisions, due to the (usually) high complexity and the interdisciplinary requirements of robotic systems. The solution is therefore to introduce iterations and increments1 into the design process 1
An increment is a system part integrated as it is completed. An incremental process is thus continu-
ously converging towards the goal as the increments are completed.
D.1. PROPERTIES OF THE DESIGN METHODOLOGY
295
to ensure that new information gathered when, for example, testing a prototype can be used iteratively in further analysis leading to new and better prototypes and eventually to the final system. Such a combination of an incremental and iterative process is often denoted an iterative development model and is widely used in software engineering as for instance in the spiral model [Boehm 1988], and in the Unified Software Development Process (UP) [Jacobsen et al. 1999].
D.1.3
Offer the means to evaluate the fitness of a design
A way of evaluating the fitness of a given system design is imperative. Such a measure will enable a continuous tracking of the overall design progress thereby facilitating that the design process can be kept as rational as possible â&#x20AC;&#x201C; a shrinking fitness could for instance indicate a wrong design path. Naturally precautions against falling into local optima must be taken. Also, a fitness measure will help to determine when finally to terminate the design process: for example, when an (optimal) design solution set has been found or when the solution set is exhausted, indicating that none is likely to be found.
D.1.4
Facilitate collaborative design
Often several partners have to collaborate in the design and construction of a robotic system due to its inherently interdisciplinary nature. Often these partners have different lines of expertise and often work in entirely different fields. This creates, besides the obvious communication challenges, several differences in opinion. On the more problematic side it may also create several different (hidden) agendas if the partners represent different institutions or companies. The design methodology should thus contain the means to establish what competencies are needed to carry out a particular project and evaluate the (potential) partners with respect to those requirements and with respect to their â&#x20AC;&#x153;politicalâ&#x20AC;? interests. Also the coordination of who-does-what in the project should take these issues into consideration.
296
D.1.5
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
Facilitate the construction of prototypes and experimental setups
Prototypes or demo constructions have a tendency to create undesired branches in a project process. That is, the work put into constructing a “demo” may well prove to be lost if non-reusable “hacks” are applied instead of the planned realisations. Often these situations occur due to sudden demands from external sources not directly participating in the project. To be able to handle such situations the design methodology must incorporate the means to determine what type of demo construction is feasible at any given point during the process such that it can become a (new) natural and rational stage in the ongoing process. Experimental setups are often necessary when making a robotic system, especially when it comes to the design of the physical robot(s). An experiment can clarify whether a certain choice is feasible or at all possible, and will therefore supply critical information to the design process. The design methodology must therefore directly facilitate the use of experimental setups.
D.1.6
Produce process deliverables
It is imperative to produce sufficient deliverables at the end of each design increment, containing at least the process documentation, the design documentation and possibly any constructed prototypes. The process documentation is a set of documents representing the project status after each increment. It contains status information on the various subtasks and creates the basis for a revision of the project schedule. Have planned tasks been completed? Have ordered components arrived on time? Have we run out of money? Have new people joined the project? – are some common issues to be addressed. The design documentation is a set of design documents continuously maturing during the design process. They represent how the current state of the design solution set has been reached in a rational way, hence, as if it had been produced in a single sequential process from the beginning. That means that iterations on subtasks, wrong decisions, errors and the likes, are removed from the documents and replaced by their ideal (rational) solution as soon as possible [Parnas and Clements 1986]. This results in a set of design documents that can be used as clear communication among the different project members and may serve
D.1. PROPERTIES OF THE DESIGN METHODOLOGY
297
well as progress reports during the course of the project. It may also ease the integration of late-arriving project participants, minimising the effects of Brooks’s law [Brooks 1982]. On the same account the documentation may also facilitate easy transfer of people, ideas and technology from one project to another, since (all) accumulated knowledge is well documented. The prototype(s) will at the end of an increment represent a subset of the final solution and may be able to produce a “demonstration”. It is not given that the prototype delivered after completing increment n+1 is a continuation of the prototype delivered at increment n – that depends entirely on the contents of the increments.
D.1.7
Facilitate different design tools
The design methodology should be agnostic with regard to the design tools employed during the design process. A certain category of robotic systems may for example require a particular form of analysis and thus require the use of a specific tool or method. These should be easily applicable to the design methodology provided that they interface to it correctly. In consequence, the design methodology must provide such interfaces at all steps where external design tools may be applied.
D.1.8
Be easy to explain and use
For a robotic systems designer to choose the design methodology as a tool when designing and realising a robotic system, it should be clear and coherent in structure and be easy to adapt to the specific needs of the system in question. The structure of the methodology, its tools and the project specific tools will constitute the actual design method, and it is important that the individual design tasks can be readily communicated to and understood by the people actually carrying them out. If not, chances are that standard ad-hoc design methods will be used instead. This may result in unfortunate designs leading to systems that in the worse case do not obey the required performance criteria.
D.1.9
Allow for different levels of generalisation
The design methodology should support the development of robotic systems with various levels of generalisation. That means that designs could include systems containing generic
298
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
robot platforms, for instance tool-carriers, as well as highly dedicated robot platforms depending on the project’s objective.
D.1.10
Allow for different levels of autonomy
The design methodology should support solutions employing different levels of autonomy: e.g., out of two equally fit design solutions, one might contain a remote controlled robot and one a fully autonomous robot. The reason for including this criterion is to emphasise that a robotic system does not necessarily have to be fully autonomous to comply with economic demands or efficiency requirements.
D.1.11
Produce design documentation
Since the process is rational, the design documents delivered at the end of the design process reflect a rational design process, meaning a recipe showing how to progress from the initial analysis to the final design in a single pass, thus masquerading as a strictly sequential process. This is useful for documenting the final results of the rational process phases and may serve well as deliverables to external (financial) partners, project managers, students, and others interested in the project.
D.2
Comparison
As presented in Section 5 not much work has been done previously in rational system-level design methodologies or methods for robotic systems. However, many contributions exist in the related fields of Software Engineering and Systems Engineering. Both have for many years contributed to theory and practice on methods and methodologies and thus form a natural basis of comparison to our proposal. Eight methods have been chosen for comparison: The Unified Process (UP) [Jacobsen et al. 1999], the Waterfall model (WM) [Benington 1983], the Spiral model (SM) [Boehm 1988], Extreme Programming (XP) [Beck 2000], NASA’s- [NASA 2007], DoD’s- [Systems Management College 2001], INCOSE’s- [International Council on Systems Engineering (INCOSE) 2000] and SMC’s [Space & Missile Systems Center 2005] Systems Engineering
D.2. COMPARISON
299
methodologies. In Table D.1 each method is evaluated with respect to the required properties presented in Section D.1, and are marked with an “×” if the method supports the
Fitness Collaboration Prototypes Deliverables Design Tools Easy to use Generalisation Autonomy Documentation
× × × × ×
DoD
INCOSE
SMC
×
×
×
×
×
×
×
× ×
NASA
×
XP
Iterations
×
SM
Rationality
WM
Property
UP
property.
× × × × × ×
×
×
×
×
×
× × × × × ×
× × ×
×
×
×
×
×
×
×
×
× × × ×
× × × ×
× × × ×
× × × ×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
×
Table D.1: A comparison of the design methodology to other system-level design methods
The comparison reveals that within Software Engineering, the Unified Process (UP) and Extreme programming seem to be the methods fulfilling the necessary properties best. The Waterfall model falls through and the Spiral Model is more of a reference model than a fixed model – it can therefore be adapted to the required needs. Within Systems Engineering, the identified test methodologies are actually all full development models that all deal with the necessary properties in more or less the same way. However, their application scope being very broad and primarily dedicated to highperformance military equipment, potentially makes them cumbersome to apply in our context.
300
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
The conclusion is, that methods and methodologies exist in both Software Engineering and Systems Engineering that may be used and adapted – at least partially – to the design of autonomous robotic systems. That implies that several concepts, methods and ideas from the test cases may help populate the tool box of a final design methodology – this, however, will not be treated further in this dissertation.
D.3
The Structure of the Design Methodology
In order to be a useful tool for the robotic system designer the design methodology must provide a homogeneous and rational context setting in which both the design process and the actual design can be represented. That means that the various components of the methodology need to have clear interfaces to neighbouring components in order to guarantee an unambiguous, yet adaptable, methodology. A natural choice is to divide the process into phases representing the sequential flow of the incremental process. Each phase may internally have several iterations and will in the end produce a set of deliverables comprising documentation, prototypes and possibly components. This overall structure is sketched in Fig. D.2.
Problem
Pre−phase
Phase 1
Phase 2
Phase N
Solution
Task
Task*
Environment
Environment *
Requirements
Robots
Deliverables
Deliverables
Deliverables
Figure D.2: The phases of the design methodology
An initial phase, pre-phase, is needed to process the information from the Problemspecification and make preliminary analysis needed throughout the design process – for example a stakeholder analysis, analysis of the competencies needed for realising the project, analyses of the Environment-component, Task -component, and Requirements. In particular the Requirements need careful handling and the domain of Requirement Engineering
D.3. THE STRUCTURE OF THE DESIGN METHODOLOGY
301
(often seen as a part of Systems Engineering) offer a wide range of methods and tools for this task (see for instance [Nuseibeh and Easterbrook 2000; Sommerville 2003; Kossiakoff and Sweet 2003; Grady 2006]). The information gathered from the pre-phase will also help set up the management structure of the project, that is, the choice of project consortium, the description and assignment of work-packages, the construction of a project time-line, and so forth. The subsequent phases, Phase 1 –Phase N, will each comprise the disciplines needed to carry out the design process for the system in question. Several standard tools and methods from Product Development, Systems Engineering and Software Engineering can easily be used to handle the more general process specific tasks such as customer requirements, test and experiment planning, and project management, alongside the more domain specific tasks like simulations tools, CAD applications and rapid prototyping equipment. Also a per-system customisation will often be required in order to accommodate, for instance, project specific requirements. If, for instance, an ARS based on mobile robots is to be realised such that it can carry out tasks on Mars, knowledge regarding, for example, the design and construction of high-end fault-tolerant electronic systems and components is crucial. Tools to support this should be directly applicable in the design methodology. What characterises the development of a robotic system is that at some point the different system components have to be chosen, constructed and/or deployed. For the system it implies choosing a robotic configuration – for instance one big mobile robot or ten smaller mobile robots – and a task and environment representation. For the robots it implies choosing among a vast set of computers, algorithms, sensors, actuators, wheels, materials and so on. Such choices are neither easy nor obvious and depend to a large extent on the level of experience and expertise of the people involved, but also on a sound design process. The methodology should therefore rationally guide the choice of these components and be able to establish the component- and system wide impacts of these choices. For example, what power system should be chosen and what effects does that choice have on the mechanical design of the robot? On the safety of the system? On the system price? The choice of battery for some robotic system might, for instance, impact the overall system weight and power availability, which in turn might affect the overall operational time, choice of power converters, and safety system design, which again may
302
APPENDIX D. PROP. & STRUCT. OF THE DESIGN METHODOLOGY
affect the maximum locomotion velocity and thus ultimately the production capacity. The choice of battery may therefore have large system wide impacts for a certain robotic system while for a different environment and task setting the consequences may be minor.
D.4
Conclusion
In this chapter I first presented 11 necessary properties of the design methodology which was then compared to eight commonly known methods from literature to determine how they complied with them. The conclusion was, that methods and methodologies exist in both Software Engineering and Systems Engineering that may potentially be used and adapted â&#x20AC;&#x201C; at least partially â&#x20AC;&#x201C; to the design of autonomous robotic systems. However, exactly which elements and how they should be applied was not addressed, as this is out of scope of this dissertation. The overall structure of the design methodology was then presented as phases placed in a sequential flow facilitating the incremental process. Each phase may internally have several iterations and will in the end produce a set of deliverables comprising documentation, prototypes and possibly components.
Appendix E Design Considerations Reference Sheet The Design Considerations Reference Sheet described in Section 4.3.5 on page 120 can be found on the next page.
303
304
APPENDIX E. DESIGN CONSIDERATIONS REFERENCE SHEET
Figure E.1: Design Considerations Reference Sheet.
Appendix F Decision support for Dependability and ELS analysis The following pages contain output from the Dependability and ELS analysis process described in Section 4.5.2 on page 130.
305
306APPENDIX F. DECISION SUPPORT FOR DEPENDABILITY AND ELS ANALYSIS
Figure F.1: The sixteen Dependability and ELS criteria and their associated preference values before ranking has been conducted.
307
Figure F.2: The sixteen Dependability and ELS criteria and their associated preference values after ranking has been conducted with respect to the ServiceBot (see Section 4.5.3).
308APPENDIX F. DECISION SUPPORT FOR DEPENDABILITY AND ELS ANALYSIS
References Ackoff, R. L. (1981). Creating the corporate future: Plan or be planned for. John Wiley & Sons, Inc. 101, 104 Ambo, P. (2007). Mechanical Love. Documentary produced by SF Film Productions ApS. 58 Arkin, R. C. and Balch, T. R. (1997). AuRA: principles and practice in review. Journal of Experimental and Theoretical Artificial Intelligence, 9(2-3):175–189. 190 Arras, K., Philippsen, R., Tomatis, N., de Battista, M., Schilt, M., and Siegwart, R. (2003). A Navigation Framework for Multiple Mobile Robots and its Application at the Expo.02 Exhibition. In ICRA’03. International Conference on Robotics and Automation, 2003. Proceedings., volume 2, pages 1992–1999. 190 Badham, R. J., Clegg, C. W., and Wall, T. D. (2001). International Encyclopedia of Ergonomics and Human Factors, chapter Socio-technical Theory, pages 1370–1373. Taylor & Francis, London. Published in the Taylor & Francis e-Library. 33, 39 Baxter, G. and Sommerville, I. (2011). Socio-technical systems: From design methods to systems engineering. Interacting with computers, 23(1):4–17. 33, 35, 36, 37, 40, 66 Beck, K. (2000). Extreme Programming Explained: Embrace Change. Pearson Education, Inc., publishing as Addison Wesley Longman. 33, 38, 92, 158, 298 Belton, V. and Stewart, T. J. (2002). Multiple Criteria Decision Analysis – An Integrated Approach. Kluwer Academic Publishers, first edition. 122 Benington, H. D. (1983). Production of Large Computer Programs. IEEE Annals of the History of Computing (IEEE Educational Activities Department), 5(4):350–361. 298 309
310
REFERENCES
Bicchi, A., Peshkin, M. A., and Colgate, J. E. (2008). Springer Handbook of Robotics, volume G of Engineering, chapter 57. Safety for Physical Human-Robot Interaction, pages 1335–1348. Springer Berlin Heidelberg. 29 Bill Gates (2007). A Robot in Every Home. Scientific American, January:58–65. 4 Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. Computer, 21(5):61–72. 96, 295, 298 Bonasso, R., Firby, R., Gat, E., Kortenkamp, D., Miller, D., and Slack, M. (1997). Experiences with an Architecture for Intelligent, Reactive Agents. Journal of Experimental and Theoretical AI, 9(2):237–256. 190 Braitenberg, V. (1984). Vehicles: Experiments in Synthetic Psychology. MIT Press, Bradford Books, Cambridge, MA. 194 Breazeal, C., Takanishi, A., and Kobayashi, T. (2008). Springer Handbook of Robotics, volume G of Engineering, chapter 58. Social Robots that Interact with People, pages 1349–1369. Springer Berlin Heidelberg. 38 Brooks, F. R. (1982). The Mythical Man-Month: Essays on Software Engineering. AddisonWesley Publishing Company. 297 Brooks, R. A. (1986). A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 2(1):14–23. 40, 190 Brown, D. C. (1998). Defining configuring. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12:301–305. 117 Browning, T. R. (2001). Applying the Design Structure Matrix to System Decomposition and Integration Problems: A Review and New Directions. IEEE Transactions on Engineering Management, 48(3):292–306. xviii, 117, 170, 171, 172, 179 Buchheim, C., J¨ unger, M., and Leipert, S. (2002). Improving Walker’s Algorithm to Run in Linear Time. In Goodrich, M. and Kobourov, S., editors, Graph Drawing, volume 2528 of Lecture Notes in Computer Science, pages 347–364. Springer Berlin / Heidelberg. 238
REFERENCES
311
Celik, P. M.-O. and Mackworth, A. K. (2004). Situated Robot Design with Prioritized Constraints. In Proceedings of the International Conference on Intelligent Robots and Systems (IROS) 2004, Sendai, Japan. 161 Checkland, P. (1981). Systems Thinking, Systems Practice. John Wiley & Sons, Inc., Chichester, UK. 182 Chella, A., Cossentino, M., Pirrone, R., and Ruisi, A. (2002). Modeling Ontologies for Robotic Environments. In Proceedings of the 14th international conference on Software Engineering and Knowledge Engineering (SEKE 2002), pages 77–80, Ischia, Italy. 116 Chen, W., Lewis, K. E., and Schmidt, L. C. (2006). The Open Workshop on Decision-Based Design. In Lewis, K. E., Chen, W., and Schmidt, L. C., editors, Decision Making in Engineering Design, chapter 2, pages 5–11. ASME Press. 122 Clegg, C. W. (2000). Sociotechnical principles for system design. Applied Ergonomics, 31(5):463–477. 39 CORDIS (2001). HYDRA : ”Living” Building Blocks for Self-Designing Artefacts. [Online; accessed 25-May-2010]. 2 Coste, P., Hessel, F., Marrec, P. L., Sugar, Z., Romdhani, M., Suescun, R., Zergainoh, N., and Jerraya, A. A. (1999). Multilanguage Design of Heterogeneous Systems. In Proceedings of the Seventh International Workshop on Hardware/Software Codesign, 1999. (CODES ’99), pages 54–58. 159 Dalby, M. S. (2010).
Robotterne Kommer (Eng.: The Robots Are Coming).
Ra-
dio Programme on Danish Radio’s P1, 10th of June 2010, at 09:09 o’clock. http://www.dr.dk/P1/P1Formiddag/Udsendelser/2010/06/09084444.htm. Interviewed by Poul Friis. 54 Dalgaard, L. (2008). Robotter og Etik - Erhvervsrapport. Technical report, Danish Technological Institute, Centre for Robot Technology. 52 Dalgaard, L. and Hallam, J. (2009). Concerning a Rational System-level Design Methodology for Autonomous Robotic Systems. In Proceedings of the 23rd BCS Conference on Human-Computer Interaction (HCI2009), volume 3, Cambridge, UK. ACM Press.
312
REFERENCES Presented at workshop ”Beyond Gray Droids: Domestic Robot Design for the 21st Century” (DRD09). 66, 91, 291
Dalgaard, L. and Thomsen, B. S. (2010). ModWall - a Morphological Boundary Concept for Pig Stable Design Based on Modular Robotics. In Proceedings of the joint 41st International Symposium on Robotics and 6th German Conference on Robotics (ISRRobotik-2010), pages 1129–1136. 159 Danish Technological Institute, C. f. R. T. (2010). Welfare Technology Assessment. Technical report, Danish Technological Institute, Centre for Robot Technology. 35, 85 de Jong, G. (2002). A UML-Based Design Methodology for Real-Time and Embedded Systems. In Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02), pages 776–779. 159 de Silva, C. W. (2005). Mechatronics: An Integrated Approach. CRC Press. 159 Dhillon, B. S. (1991). Robot Reliability and Safety. Springer-Verlag. 28 Dhillon, B. S. (1996). Engineering Design: A Modern Approach. Richard D. Irwin, Inc. Company. 28 DSDM Consortium (2008). DSDM Atern: The Handbook. DSDM Consortium, DSDM Consortium, Invicta Business Centre, Monument Way, Orbital Park, Ashford, Kent TN24 0HB, UK. Available online at: http://www.dsdm.org/atern-handbook/flash.html. 38 Durrant-Whyte, H. (2005). Autonomous land vehicles. Proceedings of the Institution of Mechanical Engineers, Part I: Journal of Systems and Control Engineering, 219(1):77– 98. xix, 40, 190, 201, 202, 203 Dyer, J. (2005). Multiple Criteria Decision Analysis: State of the art surveys, volume 78 of International Series in Operations Research & Management Science, chapter Maut – Multiattribute Utility Theory, pages 265–292. Springer. Can be found online at SDU. 122
REFERENCES
313
Eppinger, S. D., Whitney, D. E., and Gebala, D. A. (1992). Organizing Tasks in Complex Design Projects: Development of Tools to Represent Design Procedures. In Proceedings of NSF Design and Manufacturing Systems Conference, pages 301–309, Atlanta, GA. 117, 172 European Commission, Enterprise and Industry (2010). CE: CE marking makes Europe’s market yours! Leaflet. 29 European Robotics Technology Platform (EUROP) (2006). Strategic Research Agenda. Technical report, European Robotics Technology Platform (EUROP). 24 European Robotics Technology Platform (EUROP) (2009a). Appendix to: Robotic Visions to 2020 and Beyond - The Strategic Research Agenda for Robotics in Europe, 07/2009, Application Requirements. Technical report, European Robotics Technology Platform (EUROP). 24, 26, 52 European Robotics Technology Platform (EUROP) (2009b). Appendix to: Robotic Visions to 2020 and Beyond - The Strategic Research Agenda for Robotics in Europe, 07/2009, Glossary of Ethical, Legal and Societal Issues of Robotics. Technical report, European Robotics Technology Platform (EUROP). 24, 25 European Robotics Technology Platform (EUROP) (2009c). Robotic Visions to 2020 and Beyond - The Strategic Research Agenda for Robotics in Europe, 07/2009. Technical report, European Robotics Technology Platform (EUROP). 5, 8, 20, 22, 24, 35, 51, 138 Farritor, S., Dubowsky, S., Rutman, N., and Cole, J. (1996). A Systems-Level Modular Design Approach to Field Robotics. In Proceedings of the 1996 IEEE International Conference on Robotics and Automation, volume 4, pages 2890–2895, Minneapolis, MN, USA. 159 Fisher, R., Ury, W., and Patton, B. (1999). Getting to Yes: Negotiating an Agreement Without Giving In. Random House Business Books, second edition. 62 Friedenthal, S., Moore, A., and Steiner, R. (2008). A Practical Guide to SysML: The Systems Modelling Language. Morgan Kaufmann OMG Press, first edition. 160
314
REFERENCES
Gebala, D. A. and Eppinger, S. D. (1991). Methods for Analyzing Design Procedures. In Proceedings of ASME 3rd International Conference on Design Theory and Methodology, pages 227–233. 172 Gibson, J. J. (1979). The Ecologial Approach to Visual Perception. Houghton Mifflin Company, Boston, first edition. 74 Goh, C.-H. (1997). Analytic Hierarchy Process for Robot Selection. Journal of Manufacturing Systems, 16(5):381–386. 122 Gøtsche, P. C. (2007).
Rational Diagnosis and Treatment: Evidence-based Clinical
Decision-making, chapter 7: Medicine and the Humanities, pages 149–177. John Wiley & Sons, Ltd, fourth edition. 56 Grady, J. O. (2006). Systems Requirements Analysis. Academic Press. 98, 301 Gulliksen, J., G¨oransson, B., Boivie, I., Blomkvist, S., Persson, J., and Cajander, A. (2003). Key principles for user-centred systems design. Behaviour & Information Technology, 22(6):397–409. 38 Hallam, J. and Bruyninckx, H. (2006). An Ontology of Robotics Science. In Christensen, H. I., editor, European Robotics Symposium 2006, volume 22 of Springer Tracts in Advanced Robotics (STAR), pages 1–14. Springer-Verlag Berlin Heidelberg. xvi, 78, 79, 116 Hallam, J. and Dalgaard, L. (2010). Discussion session between John Hallam and Lars Dalgaard on parallels of car design an robotics design. 10, 110 Hansen, P. and Ombler, F. (2008). A New Method for Scoring Additive Multi-attribute Value Models Using Pairwise Rankings of Alternatives. Journal of Multi-Criteria Decision Analysis, 15(3-4):87–107. 124, 125 Hansen, S. T. (2011). Robot Games for Elderly – A Case-Based Approach. PhD thesis, Danish Technological Institute, Centre for Robot Technology and Aalborg University. 85 Hansen, S. T., Svenstrup, M., and Dalgaard, L. (2010). An Adaptive Robot Game. In Proceedings of the joint 41st International Symposium on Robotics and 6th German Conference on Robotics (ISR-Robotik-2010), pages 76–83. 38, 85
REFERENCES
315
Hari, A., Kasser, J. E., and Weiss, M. P. (2007). How lessons learned from using QFD led to the evolution of a process for creating quality requirements for complex systems. Systems Engineering, 10(1):45–63. 98 Hazelrigg, G. A. (1998). A Framework for Decision-Based Engineering Design. Journal of Mechanical Design, 120:653–658. Print. 122, 123, 124 Herrmann, G. and Melhuish, C. (2010). Towards Safety in Human Robot Interaction. International Journal of Social Robotics, 2(3):217–219. 5 Hitchins, D. K. (2007). Systems Engineering: A 21st Century Systems Methodology. Wiley Series in Systems Engineering and Management. John Wiley & Sons, Ltd. 99, 102, 160, 165, 181, 184, 193 Huang, C.-C. and Kusiak, A. (1998). Modularity in Design of Products and Systems. IEEE Transactions on Systems, Man, and Cybernetics, 28(1):66–77. 117, 172 International Council on Systems Engineering (INCOSE) (2000). Systems Engineering Handbook: A ”How to” Guide For All Engineers. International Council on Systems Engineering (INCOSE), second edition. 159, 298 International Federation of Robotics (IFR) (2009/2010). World Robotics - Service Robots 2009. Technical report, IFR Statistical Department. 5, 55 Jackson, M. C. and Keys, P. (1984). Towards a System of Systems Methodologies. The Journal of the Operational Research Society, 35(6):473–486. 40, 41, 49 Jacobsen, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process. Addison-Wesley. 92, 295, 298 Jensen, P. R. (1996). The RUF concept, a dual-mode car- and APM-System. In In proceedings of the 5th International Conference on Automated People Movers (APM 96), pages 641–650, Paris. 110 Kapoor, V. and Tak, S. S. (2005). Fuzzy Application to the Analytic Hierarchy Process for Robot Selection. Fuzzy Optimization and Decision Making, 4(3):209–234. 122
316
REFERENCES
Kasser, J. E. (2000). Case Study.
A Web Based Asynchronous Virtual Conference – A
INCOSE – Mid-Atlantic Regional Conference, Reston, VA.
http://www.therightrequirement.com/pubs/2000/webconf.pdf Accessed 13/52011. 97 Kasser, J. E. (2003). Object-oriented requirements engineering and management. In Proceedings of the Systems Engineering/Test and Evaluation Conference (SETE 2003). 98 Kasser, J. E. (2007). A Framework for Understanding Systems Engineering. The Rights Requirement Ltd., Bedfordshire, England, first edition. 40, 49, 160, 165, 166, 182 Keeney, R. K. and Raiffa, H. (1976). Decisions with Multiple Objectives: Preferences and Value Tradeoffs. John Wiley & Sons. 122 Kline, S. J. (1995). Conceptual Foundations for Multidisciplinary Thinking. Stanford University Press. 32, 37, 182, 183 Kossiakoff, A. I. and Sweet, W. N. (2003). Systems Engineering Principles and Practices. Wiley Series in Systems Engineering and Management. Wiley-Interscience, John Wiley & Sons, Inc., first edition. xvi, xvii, xxi, 60, 62, 91, 94, 96, 97, 98, 127, 153, 160, 270, 271, 301 Krishnamurty, S. (2006). Normative Decision Analysis in Engineering Design. In Lewis, K. E., Chen, W., and Schmidt, L. C., editors, Decision Making in Engineering Design, chapter 4, pages 21–33. ASME Press. 131 Lewis, K. E., Chen, W., and Schmidt, L. C., editors (2006a). Decision Making in Engineering Design. ASME Press. 123 Lewis, K. E., Chen, W., and Schmidt, L. C. (2006b). Decision Theory in Engineering Design – Introduction to Section 2. In Lewis, K. E., Chen, W., and Schmidt, L. C., editors, Decision Making in Engineering Design, page 13. ASME Press. 123, 124 MacDorman, K. F. (2005). Androids as an Experimental Apparatus: Why Is There an Uncanny Valley and Can We Exploit It? In Proceedings of the CogSci-2005 Workshop “Towards Social Mechanisms of Android Science”, pages 108–118, Stresa, Italy. 58
REFERENCES
317
Mathiassen, L., Munk-Madsen, A., Nielsen, P. A., and Stage, J. (1998). Objekt Orienteret Analyse og Design. Marko, Aalborg, Denmark. 33, 158 Mathiassen, L. and Stage, J. (1992). Information, Technology and People, volume 6, chapter The Principle of Limited Reduction in Software Design. 292 Mistree, F., Smith, W. F., Bras, B. A., Allen, J. K., and Muster, D. (1990). Decision-Based Design: A Contemporary Paradigm for Ship Design. Transactions of the Society of Naval Architects and Marine Engineers, 98:565–597. 122 NASA (1995). NASA Systems Engineering Handbook. Technical report, NASA. 159 NASA (2007). NASA Systems Engineering Handbook. Technical report, NASA. 99, 160, 298 Nielsen, J. (1993). Usability Engineering. Academic Press, San Diego, CA, USA. 38 Nonaka, S., Inoue, K., Arai, T., and Mae, Y. (2004). Evaluation of Human Sense of Security for Coexisting Robots using Virtual Reality. 1st report: Evaluation of Pick and Place Motion of Humanoid Robots. In Proceedings of the 2004 IEEE International Conference on Robotics and Automation (ICRA 2004), volume 3, pages 2770–2775, New Orleans, USA. 23, 24 Nuseibeh, B. and Easterbrook, S. (2000). Requirements Engineering: A Roadmap. In Finkelstein, A., editor, The Future of Software Engineering, volume Special Volume published in conjunction with ICSE 2000. ACM and IEEE Computer Society Press. 98, 301 Paredis, C. J. J. (1996). An Agent-Based Approach to the Design of Rapidly Deployable Fault Tolerant Manipulators. PhD thesis, Department of Electrical and Computer Engineering, Carnegie Mellon University, USA. 159 Parlitz, C., H¨agele, M., Klein, P., Seifert, J., and Dautenhahn, K. (2008). Care-O-bot 3 – Rationale for human-robot interaction design. In Proceedings of the 39th International Symposium on Robotics (ISR 2008), pages 275–280, Seoul, Korea. 118 Parnas, D. L. and Clements, P. C. (1986). A Rational Design Process: How and Why to Fake It. IEEE Transactions on Software Engineering, SE-12(2):251–257. 9, 241, 294, 296
318
REFERENCES
Pe˜ na, N., Garcia, E., and L´azaro, J. M. (2003). Configuration Ontology & Multi-product Configuration Tool (I). Deliverable LAB MCT WP06 10 01 of EU project: OntologyBased ELectronic Integration of CompleX Products and Value Chains (OBELIX) funded under FP5., LABEIN. 117 Pfeifer, R. (1996). Building Fungus Eaters: Design Principles of Autonomous Agents. In Maes, Mataric, Meyer, Pollack, and Wilson, editors, Proceedings of the Fourth International Conference on Simulation of Adaptive Behavior. 161 Pimmler, T. U. and Eppinger, S. D. (1994). Integration Analysis of Product Decompositions. In Proceedings of 6th ASME International Conference on Design Theory and Methodology, Minneapolis, MN. 169, 172 Pirjinian, P. (1997). An Overview of System Architecture for Action Selection in Mobile Robotics. 190 Rask, I. and Sunnersj¨o, S. (1998). Changing the Ways We Work, chapter Design Strcture Matrices for the Planning of Rule-Based Engineering Systems, pages 349–359. Advances in Design and Manufacturing. IOS Press, Amsterdam, Netherlands. 172 Reiser, U., Connette, C., Fischer, J., Kubacki, J., Bubeck, A., Weisshardt, F., Jacobs, T., Parlitz, C., H¨agele, M., and Verl, A. (2009). Care-O-bot 3 - Creating a product vision for service robot applications by integrating design and technology. In Proceedings of IEEE/RSJ International Conference on Intelligent Robots and Systems 2009 (IROS 2009), pages 1992–1998, St. Louis, Missouri, USA. 118 ReVelle, J. B., Moran, J. W., and Cox, C. A. (1998). The QFD Handbook. John Wiley & Sons, Inc. 137, 160 Ropohl, G. (1982). Some Methodological Aspects of Modelling Sociotechnical Systems. Progress in Cybernetics and Systems Research, 10:525–536. 166, 180 Ropohl, G. (1999). Philosophy of Socio-technical Systems. Society for Philosophy and Technology (EJournal), 4(3). 32 Ryan, A. J. (2007). Emergence is Coupled to Scope, Not Level. Wiley Periodicals: Complexity, 13(2):67–77. 168, 181, 184
REFERENCES
319
Saaty, T. L. (1980). The Analytical Hierarchy Process. McGraw-Hill, New York. 122, 125 Saaty, T. L. (2008). Decision making with the analytic hierarchy process. International Journal of Services Sciences, 1(1):83–98. 122 Saaty, T. L. and Vargas, L. G. (2001). Models, methods, concepts & applications of the analytic hierarchy process. International series in operations research & management science. Kluwer Academic Publishers. 122 Salvini, P., Laschi, C., and Dario, P. (2010). Design for Acceptability: Improving Robots’ Coexistence in Human Society. International Journal of Social Robotics, 2(4):451–460. 4, 39, 69 Santis, A. D. and Siciliano, B. (2008). Safety Issues for Human-Robot Cooperation in Manufacturing Systems. In Tools and Perspectives in Virtual Manufacturing, Napoli, Italy. 30, 31 Schlenoff, C. and Messina, E. (2005). A Robot Ontology for Urban Search and Resuce. In Proceedings of the 2005 CIKM Conference: Workshop on Research in Knowledge Representation for Autonomous Systems, Bremen, Germany. 116 Schuster, G. and Winrich, M. (2009). International Safety Standards Keep Pace with Advances in Robotic Technology and Applications. Technical report, Rockwell Automation; Power, Control and Information Solutions Headquarters. Whitepaper. 30 Schwaber, K. and Beedle, M. (2001). Agile software development with Scrum. Prentice Hall, New Jersey. 38 Siegwart, R. and Nourbakhsh, I. R. (2004). Introduction to Autonomous Mobile Robots. Intelligent Robotics and Autonomous Agents. A Bradford Book, The MIT Press, Cambridge, Massachusetts, first edition. 114 Simon, H. A. (1962). The Architecture of Complexity. Proceedings of the American Philosophical Society, 6(106):467–482. 179, 184 Simon, H. A. (1996). The Sciences of the Artificial. The MIT Press, Cambridge, Massachusetts, third edition. 9, 184
320
REFERENCES
Soininen, T., Tiihonen, J., M¨annist¨o, T., and Sulonen, R. (1998). Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12:357–372. 117 Sommerville, I. (2003). An Integrated Approach to Dependability Requirements Engineering. In Proceedings of the 11th Safety-Critical Systems Symposium. 5, 98, 301 Sommerville, I. (2010). Software Engineering. Pearson, ninth edition. 23, 24, 25, 33, 159, 181, 182 Sommerville, I. and Dewsbury, G. (2007). Dependable domestic systems design: A sociotechnical approach. Interacting with computers, 19(4):438–456. 20, 65 Sørensen, C. A. G., Jørgensen, R. N., Pedersen, J. M., Bertelsen, K. K., Dalgaard, L., and Nørremark, M. (2008). User-centered and conceptual technical guidelines of a plant nursing robot. Presentation at the 2008 American Society of Agricultural and Biological Engineers (ASABE) Annual Meeting. 137, 160 Sørensen, C. A. G., Jørgensen, R. N., Pedersen, J. M., Bertelsen, K. K., Dalgaard, L., and Nørremark, M. (2010). User-centered and conceptual technical guidelines of a plant nursing robot. Biosystems Engineering, 105(1):119–129. 137, 160 Sørensen, C. A. G., Jørgensen, R. N., Pedersen, J. M., and Nørremark, M. (2006). HortiBot: Application of Quality Function Deployment (QFD) Method for Horticultural Robotic Tool Carrier Design Planning. Presentation at the 2006 American Society of Agricultural and Biological Engineers (ASABE) Annual Meeting. 160 Space & Missile Systems Center, U. A. F. (2005). SMC Systems Engineering Primer & Handbook. Concetps, Processes, and Techniques. Space & Missile Systems Center, U.S. Air Force, third edition. 160, 298 Stepan, G., Toth, A., Kovacs, L. L., Bolmsj¨o, G., Nikloeris, G., Surdilovic, D., Gasteratos, A., Kyriakoulis, N., Chrysostomou, D., Kouskouridas, R., Canou, J., Smith, T., Harwin, W., Loureiro, R., Lopez, R., and Moreno, M. (2009). ACROBOTER: a ceiling based crawling, hoisting and swinging service robot platform. In Proceedings of the 23rd BCS Conference on Human-Computer Interaction (HCI2009), volume 3,
REFERENCES
321
Cambridge, UK. ACM Press. Presented at workshop ”Beyond Gray Droids: Domestic Robot Design for the 21st Century” (DRD09). 141 Stevens, W. P., Myers, G. J., and Constantine, L. L. (1974). Structured Design. IBM Systems Journal, 13(2):115–139. 49 Steward, D. V. (1981). The Design Structure System: A Method for Managing the Design of Complex Systems. IEEE Transactions on Engineering Management, 28(3):71–74. 172 Stoy, K., Brandt, D., and Christensen, D. J. (2010). Self-Reconfigurable Robots – An Introduction. Intelligent Robotics and Autonomous Agents. The MIT Press, first edition. xvii, 159, 160 Swaminathan, A. and Barber, K. S. (1996). An Experience-Based Assembly Sequence Planner for Mechanical Assemblies. IEEE Transactions on Robotics and Automation, 12(2):252–267. 117 Systems Management College, D. o. D. (2001). Systems Engineering Fundamentals. Defense Acquisition University Press, Fort Belvoir, Virginia 22060-5565. Supplementary text. 159, 298 Thurston, D. L. (1990). Multiattribute utility analysis in design management. IEEE Transactions on Engineering Management, 37(4):296–301. 122 Thurston, D. L. (2006). Utility Function Fundamentals. In Lewis, K. E., Chen, W., and Schmidt, L. C., editors, Decision Making in Engineering Design, chapter 3, pages 15–19. ASME Press. 124, 125, 131 Tveden, K. (2010). Sygehusrobotter venter i kulissen. Ugeskrift for læger, 172(9):678–679. 35 Ulrich, K. T. and Eppinger, S. D. (2008). Product Design and Development. McGraw-Hill, fourth edition. xvi, xvii, 92, 93, 98, 118, 127, 153, 160 Venkatesan, M. (1979). An Alternate Approach to Transivite Coupling in ISM. IEEE Transactions on Systems, Man, and Cybernetics, SMC-9(3):125–130. 172
322
REFERENCES
Veruggio, G. (2007). EURON Roboethics Roadmap. Technical Report 1.2, European Robotics Research Network (EURON). 24 Veruggio, G. and Operto, F. (2009). Ethical, Legal and Societal Issues in the European Strategic Research Agenda of the Coordination Action for Robotics in Europe (CARE). Presentation at the ”Full Day Workshop on RoboEthics” at the 2009 IEEE International Conference on Robotics and Automation (ICRA2009). 24 Vincente, K. (2004). The Human Factor: Revolutionizing the Way People Live with Technology. Routledge. 69 ˇ Sabanovi´ c, S. (2010). Robots in Society, Society in Robots – Mutual Shaping of Society and Technology as a Framework for Social Robot Design. International Journal of Social Robotics, 2(4):439–450. 4, 38, 69, 157 Warfield, J. N. (1973). Binary Matrices in System Modeling. IEEE Transactions on Systems, Man, and Cybernetics, SMC-3(5):441–449. 172 Warfield, J. N. (1974). Toward Interpretation of Complex Structural Models. IEEE Transactions on Systems, Man, and Cybernetics, SMC-4(5):405–417. 172 Warfield, J. N. (1977). Crossing Theory and Hierarchy Mapping. IEEE Transactions on Systems, Man, and Cybernetics, SMC-7(7):505–523. 172 Wassenaar, H. J. and Chen, W. (2003). An Approach to Decision-Based Design With Discrete Choice Analysis for Demand Modeling.
Journal of Mechanical Design,
125(3):490–497. 122 Wetton, B. and Students (2007). ROBOTS: BLOOD – a methodology. Designskolen Kolding, Aagade 10, 6000 Kolding, Denmark. 118 Wielinga, B. and Schreiber, G. (1997). Configuration-design problem solving. IEEE Expert, 12(2):49–56. 117 Yassine, A. and Braha, D. (2003). Complex Concurrent Engineering and the Design Structure Matrix Method. Concurrent Engineering, 11(3):165–176. 172
REFERENCES
323
Yassine, A. A. (2004). An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method. Guaderni di Management, 9. 9, 117, 171, 172 Young, J. E., Hawkins, R., Sharlin, E., and Igarashi, T. (2009). Toward Acceptable Domestic Robots: Applying Insights from Social Psychology. International Journal of Social Robotics, 1(1):95â&#x20AC;&#x201C;108. 38 Yu, T.-L., Yassine, A. A., and Goldberg, D. E. (2007). An Information Theoretic Method for Developing Modular Architectures using Genetic Algorithms. Research in Engineering Design, 18(2):91â&#x20AC;&#x201C;109. 172