Automation of Intralogistic Processes through Flexibilisation

A Method for the Flexible Configuration and Evaluation of Systems of Systems

Marco Bonini

, Augusto Urru

, Sebastian Steinau

, Selcuk Ceylan

, Matthias Lutz

Jan Schuhmacher

, Kevin Andrews

, Harry Halfar

, Stefan Kunaschk

, Asadul Haque

, Vinu Nair

Matthias Rollenhagen

, Nayabrasul Shaik

, Manfred Reichert

, Norbert Bartneck

Christian Schlegel

, Vera Hummel

and Wolfgang Echelmeyer

ESB Logistikfabrik, Reutlingen University, Germany

Institute of Databases and Information Systems, Ulm University, Germany

Institute of Organisation and Logistics, Ulm University of Applied Sciences,Germany

Institute of Computer Science, Ulm University of Applied Sciences, Germany

ESB Logistik Lernfabrik, Reutlingen University, Germany

Keywords: Intralogistics, Automation, Flexibilisation, Modular Configuration, Human-Robot Interaction, Evaluation.

Abstract: The high system flexibility necessary for the full automation of complex and unstructured tasks leads to

increased technological complexity, thus to higher costs and lower performance. In this paper, after an

introduction to the different dimensions of flexibility, a method for flexible modular configuration and

evaluation of systems of systems is introduced. The method starts from process requirements and, considering

factors such as feasibility, development costs, market potential and effective impact on the current processes,

enables the evaluation of a flexible systems of systems equipped with the needed functionalities before its

actual development. This allows setting the focus on those aspects of flexibility that add market value to the

system, thus promoting the efficient development of systems addressed to interested customers in

intralogistics. An example of application of the method is given and discussed.

1 INTRODUCTION

The interconnectivity of systems promoted by the

fourth industrial revolution (industry 4.0), based

primarily on the real-time availability of digital

process information (such as position of goods

throughout a facility), paved the street for the

increasing adoption of service robots in the logistic

sector. According to projections for the 2017,

worldwide sales of robotic systems in intralogistic -

defined as the organization, control, execution and

optimization of the internal material and information

flows and the material handling in industry, trade and

public institutions (Arnold, 2006) - are estimated to

increase by 46% in respect to the previous year,

reaching the 37.000 units for a value of about US$ 1,2

billion (IFR, 2017). A large share of this positive

trend in sales is due to the growing use of AGVs

(automated Guided Vehicles) in manufacturing and

partially non-manufacturing environments

(Fraunhofer IPA, 2017), displaying a first and

obvious result of the interconnectivity of systems

provided by the concept of industry 4.0. However, the

total worldwide revenue of service robots for

professional use in logistics in 2016 (US$ 992

millions) amounts only to about 7,6% of the total

worldwide revenue of industrial robots in the same

year (US$ 13,1 billion) (IFR, 2017). The potential for

service robots in intralogistics application is still

huge. On the one hand, the growth of the logistic

sector, conveyed by the boom of the E-Commerce,

demands for automation of more than the transport

itself (AGV). On the other hand, advancements in

perception, decision-making and robot abilities make

it technically possible to automate handling and

manipulation processes for a large variety of items.

Despite these two converging factors, robotics

struggles to fulfil its potential in intralogistic

applications (Hägele, 2012), because the benefits of

using robotics for the automation of the material

handling in intralogistics not always justify the costs

of a robotic solution (Bonini, 2015). As a result, the

380

Bonini, M., Urru, A., Steinau, S., Ceylan, S., Lutz, M., Schuhmacher, J., Andrews, K., Halfar, H., Kunaschk, S., Haque, A., Nair, V., Rollenhagen, M., Shaik, N., Reichert, M., Bartneck, N.,

Schlegel, C., Hummel, V. and Echelmeyer, W.

Automation of Intralogistic Processes through Flexibilisation - A Method for the Flexible Conﬁguration and Evaluation of Systems of Systems.

DOI: 10.5220/0006878003800388

In Proceedings of the 15th International Conference on Informatics in Control, Automation and Robotics (ICINCO 2018) - Volume 2, pages 380-388

ISBN: 978-989-758-321-6

need for efficient automation of some still manual

intralogistic processes remains largely unanswered.

On the one hand, potential users, seeking automation

of some currently manual intralogistic processes,

would rather buy technologies that are flexible, as the

capacity of flexible systems can be better exploited,

for a shorter investment payback period. On the other

hand, technology providers would rather design their

components to be flexible in order to be applicable in

different domains, products and processes, as some of

their fully mature technologies struggle to find their

way to market or do not total enough sales to justify

their development costs. However, the desired

flexibility comes together with an increased level of

complexity and therefore generally with (1) increased

costs and (2) decreased performance, two factors

potential users seeking automation of logistic

processes vigorously reject.

In order to solve this issue, research should

address two topics simultaneously. On the one hand

the costs of flexibility should be reduced by easing

the integration effort of existing software and

hardware technologies through a modular approach.

On the other hand, a method should be developed that

enables first the flexible configuration of a system of

systems (SoS from here onwards) through the

aforementioned technological modules and then its

evaluation before the actual development. This would

in turn prevent the development of systems no

investor wants to buy (high costs and low

performances), thus promoting the efficient

development of systems addressed to interested

customers in intralogistics.

After an introduction to flexibility and its

dimensions, this paper presents the aforementioned

method for flexible configuration and evaluation of a

SoS. The method is explained and an example of its

possible outcomes is given and discussed.

2 DIMENSIONS OF

FLEXIBILITY

In order to translate the general need for flexibility

into a more specific requirement of “what” should be

flexible and “to what extent”, we propose in this

section a novel taxonomy of flexibility. This is then

used in the second step of the proposed method

(translation into requirements), in order to focus the

type of flexibility required by potential customers.

Three dimensions of flexibility are identified:

process, system and technological flexibility.

2.1 Process Flexibility

The dimension of process flexibility concerns the

variety of processes, tasks and resources a SoS is

capable of coordinating and executing.

2.1.1 Resources Allocation

One of the challenges of contemporary process

management technology is the provisioning and

allocation of resources for process execution, hence

everything that is needed to execute a process,

including machines, knowledge, human workers or

robots. A resource, for instance a service robot, may

be allocated on a task according to static or dynamic

factors. Static factors refer to (1) whether a robot

possesses the necessary capabilities to handle a task

(e.g. an appropriate gripper or recognition system for

a product), (2) whether the terrain is suited for the

locomotion system of the robot and (3) whether the

robot possesses the necessary software for

performing the task. Dynamic factors of resource

allocation deal with resources not always being

readily available, as robots may be down for

maintenance or otherwise engaged. The efficient and

effective allocation of resources is paramount for

automated and semi-automated processes in the

intralogistics sector, where multiple processes run in

parallel, while still sharing the same resources.

Priorities of routine processes need to be set, as well

as extraordinary processes need to be integrated in the

decisional pipeline in order to be accomplished. To

consider all these aspects at run-time, a process

management technology must be able to handle the

various requirements flexibly, while prioritizing

resources according to specific constraints and

adapting to new circumstances (Reichert, 2012).

2.1.2 Workflow

Processes control many of the high-level functions

regarding intralogistics, such as decision-making;

their explicit representation as process models is

immensely beneficial, allowing for process optimiza-

tion thanks to thorough analysis and subsequent

removal of inefficiencies and inconsistencies. Ideally,

these process models are also compatible with a

process management system (PrMS), which becomes

then capable at run-time of: (1) coordinating the flow

of process information between all resources

involved, (2) supporting users when executing

processes by providing them with information and (3)

communicating decisions to super and subordinated

systems. Thanks to the modelling of processes and the

use of a PrMS, the workflow can be flexibly

Automation of Intralogistic Processes through Flexibilisation - A Method for the Flexible Conﬁguration and Evaluation of Systems of

Systems

381

managed: process models can easily be changed and

adapted to changing circumstances (Weber, 2008).

These changes can be reflected in the actual process

execution of future process instances or even in

currently running processes: this often becomes

necessary when there are long-running processes

active at a given time as well as frequently updated

regulations or possible process optimizations and

changes. In such cases, running process instances

must be updated flexibly at run-time to reflect the

changes, a capability only few modern PrMSs

provide (Künzle, 2011).

2.1.3 Tasks Execution

The software an autonomous robotic system consists

of can be separated into different abstraction levels,

among which the task abstraction level is one of the

most abstract ones (RobMoSys, 2018). Modelling a

task at symbolic abstraction level provides a

representation of how the system parts of a robot are

orchestrated to provide a service, such as the

transportation of an item (Lutz, 2014). At the same

time, the modelling of simple tasks (e.g. picking or

transportation) allows for flexible composition of

more complex tasks (e.g. picking and transportation,

hence commissioning). In a design phase, tasks as

building blocks are the foundation to offer and deliver

services to a super-ordinated system and provide the

link between processes and functionality. The

composability of those tasks is an important

prerequisite for the development of domain specific

tools e.g. enabling a human operator to flexibly use

an assisting robot, by adopting an existing task or by

modelling a new one. In a run-time phase, the flexible

execution of the tasks is a prerequisite for robust real-

world capable robotics systems working in open and

human-shared environments, where changes in the

environment and unforeseen events need to be

considered (Steck, 2011).

2.1.4 Human-Robot Interaction

Humans play always a fundamental role in

automation, either as supervisors of an automated

SoS or as active parts of the system itself, especially

for the execution of those sub-tasks, which are

particularly complicated to automate or for which

accountability is required. The human-robot

interaction belongs to the process flexibility because,

depending on the complexity of the task, on the

required performance, on the available resources and

even on the time of the day, different resources

(human or automation) might be allocated to different

sub-tasks to seek an overall better efficiency.

2.2 System Flexibility

The dimension of system flexibility concerns the

capability of a SoS of adapting itself or being adapted

to achieve different goals, identified in the

summarized sub-categories.

2.2.1 Applicability to Different Scenarios

The applicability of the system to different scenarios

measures the capability of the system to fulfill

requirements for a wider range of processes or

domains, so that it can be successfully installed “out

of the box” in different applications. Considering

requirements from different scenarios, key to a wider

applicability, generates however higher system

development costs, which can be justified only in case

of a real consequent increase in sales. In the

development phase the selection of scenarios to be

considered should be limited to those requirements,

which bring a positive balance between increased

development costs and potential increase in sales.

2.2.2 Adaptability after Installation

The adaptability measures the ability of a system to

respond to certain unexpected changes after its

installation without being completely reengineered.

This is a fundamental characteristic in the dynamically

changing environment of intralogistics, where specific

tasks can change over a relatively short period and

facility layouts need to be adaptable to the changing

business. A scarce system adaptability to new slightly

different requirements would prevent the possibility of

spreading investment costs over a long time period,

representing thus a barrier to the investment.

2.2.3 Integration with Installed Technologies

Integration with technologies pre-installed at the

customer’s site represent often the highest cost and

therefore the greatest barrier to the market. To tackle

this problem through integrational flexibility, a SoS

should consider a variety of common integration

requirements concerning material and information

flow. This is done by (1) organizing the suitable

interfaces to make the integration process as plug-

and-play as possible and by (2) designing the system

with a modular approach (see section 3), so that

technological modules can be plugged or unplugged

in favor of a smoother integration.

2.2.4 Scalability

The scalability measures the capability of an intra-

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

382

logistic system of increasing (or decreasing) its

maximum capacity in respect to the demanded

throughput, by adding (or subtracting) other instances

of the system itself or sub-modules of it (Wencai,

2012). Designing a system in order to be up scalable

(or down scalable) reduces the risk of investing in

automation technology, by extending its service life,

which would be otherwise short due to the constantly

changing nature of the logistic sector. This degree of

flexibility is particularly necessary for instance in the

ramp-up phase of a hub for distribution, or for third

part logistic providers, which continuously renege-

tiate the volume of their business.

2.2.5 Productivity

The concept of productivity is close to the one of

scalability in respect to the capability of an

intralogistic system of increasing (or decreasing) its

throughput in respect to the demand. The difference

is however, that for this sub-category, such degree of

flexibility is reached without adding (or subtracting)

other instances of the system itself, but just by

controlling the output of the installed system. The

flexibility reached through productivity adjustments

of existing equipment is therefore limited in respect

to the one that can be reach by up or downscaling the

whole system. Productivity adjustments are

particularly important in those systems subjected to

seasonal fluctuation, such as the online retailing

business in periods before e.g. Christmas or the by

now global phenomenon of Cyber Monday.

2.2.6 Variants and Configurability

The ultimate level of system flexibility is the total

modular configurability, where functionalities could

be added or subtracted to the system by simply

plugging and unplugging technological modules.

Such total configurability could probably work in a

software environment, but it is hard to achieve from a

hardware standpoint, without an exponential increase

of development costs. A halfway compromise

between total configurability and a fix design is the

creation of variants for a SoS: this means limiting the

spectrum of technological hardware and software

module that can flow into a system to a pre-defined

set of configurations, each of which can be optimized

for a specific set of functionalities. The design is

nevertheless flexible, as to the possibility of

integrating in a single SoS a set of different and

alternative technological modules, but unlike the total

configurability, the variant approach allows for

containment of development costs.

2.3 Technological Flexibility

The dimension of technical flexibility concerns the

intrinsic flexibility of technological modules

composing the SoS.

2.3.1 Heterogeneity of Handled Goods

Handling and transport are the two processes that set

the bases for intralogistics. On the lowest level, the

basic aspect of flexibility at play is therefore the

capability of a system to handle and transport

heterogeneous goods. Heterogeneity can be due to

mainly three factors: (1) physical, (2) informational

and (3) environmental factors. Example of (1)

physical factors of the items are dimensions, weight,

shape (fixed or variable), surface (smooth, porous or

damaged), and resistance (robust or fragile) (Bonini,

2012). Among the (2) informational factors the most

relevant are the position of labels, and the means of

the information (one- or two-dimensional barcodes,

handwritten label, RF-ID etc..). For the (3)

environmental conditions, heterogeneity is not an

intrinsic characteristic of the goods, but rather

depending on the way items are grouped or sorted.

Increasing the flexibility of technological modules

such as grippers, object recognition technologies and

kinematics would result in the possibility of handling

a wider range of heterogeneous items, thus favoring

the applicability of the SoS.

2.3.2 Technological Capabilities

Technological modules composing a SoS embed

functionalities, which are necessary to give the robot

the capabilities to accomplish a task. The flexible

composition of technological capabilities is

paramount for the creation of a SoS through modular

approach. Software models and model driven

software development provides the tools to explicate

those structures required to enable the flexible

composition of software components, allowing the

reuse of closed software components on model level.

Robotic business ecosystems (RobMoSys, 2018)

(SeRoNet, 2018) using those structures are currently

being promoted and implemented, in which

participants are able to exploit synergies and share

risks, by offering their own software components to

other participant, thereby gaining access to

components offered by others. The developer of a

robotic commissioning system, for example, can use

the building blocks (thereby the expertise) of a

robotics navigation expert and other building blocks

to compose the system. The SmartMDSD-Toolchain

(Stampfer, 2016) as an integrated development

Automation of Intralogistic Processes through Flexibilisation - A Method for the Flexible Conﬁguration and Evaluation of Systems of

Systems

383

environment makes those structures accessible to the

participants of the ecosystem. Models, as machine

readable representations for building blocks and their

encapsulated functionality, allow for the explication

of variation points within the building blocks. Those

variation points can be used to enable flexibility to

adapt the building blocks during system composition

and system operation.

3 METHOD

In this section a new method for flexible modular

configuration and evaluation of systems of systems is

introduced, which, starting from process

requirements and considering factors such as

feasibility, development costs, market potential and

effective impact on the current processes, enables the

evaluation of a flexible SoS equipped with the needed

functionalities before its actual development. The

presented method is made of five major steps and

takes in input requirements of potential users,

technological modules implementing different

functionalities (see first level of flexibilisation in

section 2) and different system evaluation methods.

The output of this novel method is a virtually

configured SoS, with its documented evaluation.

Some steps of the method can be re-iterated, either

relaxing process requirements or re-arranging

Figure 1: method for flexible configuration of Sos.

technological modules, in order to find the

configuration providing the best system evaluation.

Each iteration yields a documented evaluation of the

configured system, hence providing not only a

decisional support tool for the design, but also a tool

for the tracking and documentation of these decisions.

This section is set to explain the five steps of the

method; in the next section an example is reported.

3.1 Collection of User Stories

User stories serve the purpose of collecting a critical

mass of potential user, which have the wish for

automation of the same (or similar) intralogistic

processes, but in potentially very different domains,

branches and applications. The potential users have in

common the need (or wish) for automation and the

lack of suitable (as in effective and efficient) systems

on the market.

3.2 Translation into Requirements

The translation of user stories into requirements is

fundamental to identify the needed functionalities,

with a particular focus on the type of needed

flexibility (process, system or technological – see

section 2). In the first iteration of the method,

requirements should be comprehensive of all possible

different application of the system under design,

because this would allow for a wider adoption after

the realization. As the next steps of the method are

implemented, considering a wide variety of

requirements, thus adding more functionalities to the

system, could result either impossible or inconvenient

(discovered during step 4 - system evaluation).

As the method progresses, or in following

iterations of the method, some of the requirement

might be sorted out, thus leaving behind some of the

potential users, which will reduce the critical mass,

needed for spreading the development costs.

3.3 System Configuration

Thanks to the collection of requirements and the

identification of necessary functionalities in the

previous step, the system can be virtually configured

with a modular approach drawing technological

modules from a pool of existing technologies, each

contributing to different system abilities. Example of

these technologies are the following macro

categories: object recognition, navigation, grasping,

transportation, booking (in connection with a

warehouse management system - WMS), decision-

making, mission planning, collision avoidance, robot

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

384

kinematics etc. Each of these macro-categories can be

divided into technological sub-modules that can

implement very different functionalities.

3.4 System Evaluation

In this step, the virtually configured system is

evaluated against general and application-specific

criteria. First (4.1) feasibility and (4.2) development

effort are evaluated according to general criteria. The

goal of the (4.1) feasibility evaluation is to assess

whether the integration of different technology

modules is possible and to give a numerical evidence

of technical boundaries of the new virtually

configured system. Once feasibility has been

positively assessed, the (4.2) development effort has

to be determined: here both the procurement costs

(hardware and software) and the integration costs

need to be considered, together with an estimated

effort for fine tuning in order to reach the target

performances of the system.

The next step of the analysis is the evaluation of

application-specific criteria. Here first and foremost

the (4.3) market potential needs to be estimated for

each application, domain and branch considered in

step 1 of the method (Urru, 2015). This assessment,

together with the estimated (4.2) development costs,

can give the system developer a first insight on the

potential of realization of the virtually configured

SoS. Another application-specific criterion to

evaluate is the performance of the system in the single

application calculated in comparison with the existing

process (manual or semi-automatic): this yields an

application-specific (4.4) assessment of the

advantages (savings, increased capacity, increased

ergonomics etc.) of the system with respect to the

current process (Urru, 2017). In case of negative

evaluation of any of the four criteria, the method

might loop back to previous. This can happen in any

of the following cases: if the system is (4.1) not

feasible, if the (4.2) development costs do not match

the (4.3) market potential or if the (4.4) advantages on

the current process are not satisfactory. In these cases

another configuration of the system could be

proposed (back to step 3 of the method – system

configuration), or a simplification (relaxation) of the

requirements for the system could occur (back to step

2 of the method – translation into requirements). In

this second case, as some of the functionalities are

sorted out and not implemented in the system,

potential user could be left behind and this needs to

be coherently considered in the estimation of the

market potential.

In case of positive result of the evaluation, after

one or more iteration of the method, the system

implementation (step 5) can begin.

4 METHOD APPLICATION

In this section, a simplified example of application of

the method is described: the first step is the collection

of user stories (step 1). In this simplified example, the

focus is set on the processes of commissioning and

replenishment (complementary and symmetric to

commissioning) of items in a warehouse. The first

user story comes from the pharmaceutical sector and

targets the process of product returns: these products

are checked for quality and expiration date upon

arrival and, overnight, replenished back into the

shelves of the warehouses. Since normally only

specific products with low turnover are returned, the

required performance is not high, but the process is

rather inconvenient (additional night shift with labor

involved), hence the wish for automation. The second

user story comes from the sector of internet retailing

and focusses on the process of commissioning in a

warehouse: the shape of the stored items can vary

from rigid cuboid, to flexible sack- or bag-shaped and

the weight can range from 0.1Kg to 20Kg. A high

performance is in this case critical to the success of

the automation, as the company seeks an increased

picking capacity. The third user story comes from the

food retailing sector and the process in question is the

replenishment of shelves for packaged food in a

supermarket. Since the replenishment needs to

happen during opening time of the shop, particularly

important is the safe interaction of the automation

with the customer. Items can vary from very fragile

glass bottles of wine, to fresh mozzarella bags and

weights can range from 0.05Kg to 5Kg.

The second step (step 2) of the method is the

translation of all user stories into comprehensive

requirements, inclusive of all collected scenarios.

This enables the identification of required

functionalities, such as an Optical Character

Recognition (OCR) reading module for the proof of

the expiration date in the pharmaceutical (first user

story) and food retailing sector (third user story).

Once the needed functionalities are listed, thanks

to the database of available technology modules, the

first virtual configuration of the system can start (step

3). A digression concerning the database of

technology modules is at this point necessary. In

order to keep the database up to date, explicit or

implicit collection of user stories from the point of

view of technology providers should be collected. For

Automation of Intralogistic Processes through Flexibilisation - A Method for the Flexible Conﬁguration and Evaluation of Systems of

Systems

385

the simplified example reported in this section, it is

assumed that the database can be filled with the

following technological modules provided by

different technology producers and developed for

other niche applications: (1) an OCR developed for

the postal sector to read hand-written addresses, (2) a

mobile platform equipped with navigation modules

and a manipulator for the feeding of small cylindrical

parts (0.01Kg to 5Kg) to a production line by means

of a two-finger gripper, (3) an object recognition

module for cuboid-shaped goods, (4) an object

recognition module for bags and sack-shaped goods,

(5) a barcode reading module connected to a WMS

and (6) a suction cup gripper suited for small non-

porous items up to 5Kg. If the configurator of the

system is experienced and well aware of the

technological state of the art, the configuration (step

3) happens together with a preliminary feasibility

study (step 4.1). The preliminary feasibility concerns

mainly hardware integration aspects, such as respect

of payloads, energy demands, and constructional

mechanical stress. This helps filtering out some

system configurations that are clearly not feasible,

such as mounting a gripper on a manipulator with a

payload lower than the gripper itself. In order to

remain inclusive of all functionalities needed by the

different users in the example, the mobile platform

equipped with the manipulator should be

strengthened to support items up to 20Kg, it should

be equipped with the OCR, the barcode-reading and

cuboid-shaped object recognition modules and the

whole system should be integrate with a WMS.

The proposed configuration, yielded after the first

iteration of the method, is then evaluated (step 4).

Assuming that (4.1) this configuration is technically

feasible and (4.2) that the development effort is

justified by (4.3) the potential market in the three

sectors, the (4.4) advantages of application of this

configuration are then evaluated in each sector. In this

step of the evaluation (step 4.4) the following

complications emerge: (1) the mobile platform,

strengthened to reach the 20Kg requirement of the

second user story, is not applicable in a supermarket

(third user story), both because of layout problems

and because of safety regulations; (2) the system does

not deliver improved overall performances in the

commissioning (second user story); (3) in order to

handle the variety of goods in the supermarket two

different interchangeable gripper are necessary (a two

finger-gripper and a suction cup gripper); (4) in the

pharmaceutical (only cuboid goods) and the internet

retailing sector (only non-porous items) the most

performing way to grasp items is through a suction

cup gripper. Considering this technological remarks,

provided by the evaluation step, the method can be re-

iterated in order to obtain a system configuration that

can be positively evaluated.

It is evident that the second user story (internet

retailing) poses challenging requirements, with high

impact on the negative result of the evaluation. Only

after acknowledging the lacks of the new configured

system, especially concerning performances, the

method loops back to its second step (step 2), where

requirements are analyzed again and alternately

relaxed, seeking synergies towards a partial

automation of a slightly modified process. In this

specific user story of internet retail, it would be for

instance possible, to divide the warehouse in four

areas according to item size and required picking

performance. The commissioning of small items

requiring high picking performance (fast movers)

could be achieved through standard technologies such

as the Autostore or the Amazon Kiva system; the

commissioning of large fast movers could be

automated with an automatic storage and retrieval

technology; the commissioning of large slow movers

(low picking performance required) could remain

manual. The last part of the warehouse, namely the

one dedicated to the commissioning of small (up to

5Kg) slow movers could be automated through a

small mobile platform, which could be suitable for the

automation of the other user stories as well.

The system is therefore re-configured (step 3) in

order to fulfill the new (relaxed) requirements. As the

necessary payload is reduced to 5Kg and

performances are not the highest priority for the

system, the existing mobile platform equipped with

the manipulator can be used, equipped with the OCR,

barcode-reading and cuboid-shaped object

recognition modules and with an interchangeable

gripper (two-finger and suction cup). An interface to

the central WMS completes the system configuration,

result of the second iteration of the method.

The relaxation of requirements has two different

and opposite effects highlighted by the evaluation of

the new configuration (step 4). On the one hand, the

development costs sunk, as the platform does not

need to be strengthened to reach the 20 Kg

requirement, but, on the other hand, the market

potential shrunk, as only approximately 25% of the

processes in the second user stories can be automated

with the proposed technology. If, considering the

significant reduction of development costs, the

market potential is still appealing, the system is

evaluated in each scenario for its efficiency (saving,

performances etc…). If this final part of the

evaluation is positively concluded, the obtained

results can be also used as a marketing tool to ease the

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

386

decision to invest. Once a commitment of some sort

has been stipulated with potential users (for instance

those providing the initial user stories) the

implementation of the system can begin.

5 DISCUSSION

The weakest link of the proposed method resides in

the fourth step: the system evaluation. This is not due

to the difficulty of the evaluation itself: in literature

several methods for assessment of (4.1) feasibility,

(4.2) development costs, (4.3) market potential and

(4.4) performance and economic advantages of

automation can be found, which could be applicable.

The evaluation is the weakest link of the method

because what is being evaluated is not an existing

SoS, but a virtual one, configured in step 3 (system

configuration) on the bases of the required

functionalities. The power of the evaluation resides in

its numerical and possibly objective aspect, but if the

system under evaluation is 100% virtual, one could

argue that this numerical quantification becomes

vain, invalidated by the too many necessary

assumptions. However, the configured SoS will

normally consist in great majority of an existing

platform (in the example, the mobile platform with

navigation modules and manipulator), which needs to

be modified by adding some other technological

modules. The existing technological platform will

account for a consistent percentage of the whole

system, so that the remaining share, upon which

assumptions need to be made for the evaluation, will

have a relatively minor impact in the uncertainty of

realization. Although this does not fully erase the risk

of evaluating a partially virtual system upon some

assumptions, this risk is mitigated by reducing the

impact of such assumptions, hence restoring the value

of a quantitative evaluation.

Future research will focus on the validation of the

proposed method through at least three different

applications, for different intralogistic processes.

6 CONCLUSION

After a brief introduction on robotics in intralogistics,

in this paper an alternative taxonomy of flexibility

was introduced together with a novel method for

flexible modular configuration of systems of systems.

The novelty of the method relies in the possibility of

evaluating the virtual systems of systems, equipped

with the needed functionalities, before its actual

development. This is accomplished first analyzing all

process requirements, then assessing factors such as

feasibility, development costs, market potential and

effective impact on the current processes. Thanks to

the evaluation before realization, the development

effort is focussed on those aspects of flexibility that

add market value to the system, thus promoting the

efficient development of systems addressed to

interested customers in intralogistics. An example of

the method application was given and the main

outcomes discussed.

ACKNOWLEDGEMENTS

Supported by „EFRE Program Baden-Württemberg

2014-2020“, Project: ZAFH Intralogistik.

REFERENCES

Arnold, D., 2006. Intralogistik – Potentiale, Perspektiven,

Prognosen, Springer. Berlin.

Bonini, M. Tishchenko, K., Kirchheim, A., Echelmeyer,

W., 2012. Application of Cognitive Robotics within

Logistics, Proceedings of the Austrian Robotic

Workshop.

Bonini, M., Prenesti, D., Urru, A., Echelmeyer, E., 2015.

Towards the full automation of distribution centers,

Proceedings of IEEE 4th International Conference on

Advanced Logistics and Transport (ICALT), pp.47-52.

Fraunhofer IPA, 2017. RockEU2, Market and supplier

study on European robotics, service robotics,

Deliverable 1.7.

Hägele, M., 2012. Market Study on European Service

Robotics, EURobotics, The European Robotics

Coordination Action, Fraunhofer IPA.

IFR, 2017. World Robotics 2017 - Industrial Robots and

Service Robots, International Federation of Robotics.

Künzle, V., Reichert, M., 2011. PHILharmonicFlows:

towards a framework for objectaware process

management, Journal of Software: Evolution and

Process.

Lutz, M., Stampfer, D., Lotz, A., Schlegel, C., 2014.

Service Robot Control Architectures for Flexible and

Robust Real-World Task Execution: Best Practices and

Patterns, Workshop Roboter-Kontrollarchitekturen,

Informatik, Springer LNI der GI. Stuttgart.

Reichert, M., Weber, B., 2012. Enabling flexibility in

process-aware information systems: challenges,

methods, technologies, Springer. Berlin.

RobMoSys, 2018 - RobMoSys: Composable Models and

Software for Robotic Systems, https://robmosys.eu/.

SeRoNet, 2018 - Plattform zur arbeitsteiligen Entwicklung

von Serviceroboter-Lösungen http://seronet-projekt.de.

Stampfer, D., Lotz, A., Lutz, M., Schlegel, C., 2016. The

SmartMDSD Toolchain: An Integrated MDSD

Automation of Intralogistic Processes through Flexibilisation - A Method for the Flexible Conﬁguration and Evaluation of Systems of

Systems

387

Workflow and Integrated Development Environment

(IDE) for Robotics Software, Special Issue on Domain-

Specific Languages and Models in Robotics, Journal of

Software Engineering for Robotics, JOSER.

Steck, A., Schlegel, C., 2011. Managing execution variants

in task coordination by exploiting design-time models

at run-time. Proceedings of IEEE/RSJ Int. Conf. on

Robotics and Intelligent Systems (IROS).

Urru, A., Bonini, M., Burbach, T., Höng, E., Stein, P.,

Echelmeyer, W., 2015, Autonomous unloading of heavy

deformable goods: market opportunities, proceedings

of IEEE International Conference on Service

Operations Logistics and Informatics (SOLI).

Urru, A., Bonini, M. and Echelmeyer, W., 2017, The STIC

analysis A decision support tool for technology related

investments in logistics, proceedings of IEEE

International Conference on Service Operations

Logistics and Informatics (SOLI).

Weber, B., Reichert, M., Rinderle-Ma, S., 2008. Change

patterns and change support features–enhancing

flexibility in process-aware information systems, Data

& knowledge engineering, Volume 66, Issue 3, pp. 438-

466, Elsevier.

Wencai, W., Yoram, K., 2012. Scalability planning for

reconfigurable manufacturing systems, Journal of

Manufacturing Systems, Volume 31, Issue 2, pp. 83-91.

ICINCO 2018 - 15th International Conference on Informatics in Control, Automation and Robotics

388