Automated Configuration of

Industrial Crane Applications - A

Software Product Line Approach

Eetu Suominen

School of Electrical Engineering

Thesis submitted for examination for the degree of Master of

Science in Technology.
Espoo 29.5.2023

Supervisor

Prof. Valeriy Vyatkin

Advisor

D.Sc. (Tech.) Imed Hammouda

Copyright © 2023 Eetu Suominen
 Aalto University, P.O. BOX 11000, 00076 AALTO
www.aalto.fi
Abstract of the master’s thesis

Author Eetu Suominen

Title Automated Configuration of Industrial Crane Applications - A Software
Product Line Approach
Degree programme Automation and Electrical Engineering
Major Control, Robotics and Autonomous Systems Code of major ELEC3025
Supervisor Prof. Valeriy Vyatkin
Advisor D.Sc. (Tech.) Imed Hammouda
Date 29.5.2023 Number of pages 77 Language English
Abstract
To be successful in large-scale and complex software development business, systematic
reuse of software is essential. This requires careful management of commonalities
and variabilities among software variants. However, in industrial automation, this
approach is not yet widespread, and non-systematic software reuse approaches, such
as clone-and-own, are more commonly used due to their simplicity and availability.
This thesis aims to implement a prototype of an easy-to-use configurator tool
that takes an industrial crane application specification as an input and automatically
configures a common control software platform to meet customer requirements. The
tool adheres to the concept of Software Product Line Engineering (SPLE) as a
mechanism for mass customization, providing benefits, such as reduced time to
market, improved software quality, and cost-effectiveness.
This study applied Design Science Research methodology as an iterative problem-
solving approach for finding solutions to the identified practical problems in crane
application development. The study consisted of four iterations, each consisting of
five phases of the regulative cycle. Qualitative data about solution requirements and
feedback were collected through focus group discussions and by analyzing software
artifacts.
The developed tool successfully addresses issues related to industrial crane applica-
tion development, such as time-consuming and laborious manual configuration tasks,
lack of harmonization between applications, and difficulties in efficiently utilizing
reusable software artifacts. As crane control software is becoming increasingly more
complex due to constant safety and productivity improvements, the tool acts as
an extendable platform that supports efficient reuse and variability management to
enhance software development.
Keywords Software Product Line, Software Reuse, Industrial Crane Application,
TIA Portal Openness, Design Science Research
 Aalto-yliopisto, PL 11000, 00076 AALTO
www.aalto.fi
Diplomityön tiivistelmä

Tekijä Eetu Suominen

Työn nimi Teollisuusnosturisovellusten automatisoitu konfigurointi -
Ohjelmistotuotelinjallinen lähestymistapa
Koulutusohjelma Automation and Electrical Engineering
Pääaine Control, Robotics and Autonomous Systems Pääaineen koodi ELEC3025
Työn valvoja Prof. Valeriy Vyatkin
Työn ohjaaja TkT Imed Hammouda
Päivämäärä 29.5.2023 Sivumäärä 77 Kieli Englanti
Tiivistelmä
Menestyäkseen laajamittaisessa ja monimutkaisessa ohjelmistokehitysliiketoiminnas-
sa ohjelmistojen järjestelmällinen uudelleenkäyttö on välttämätöntä. Tämä vaatii
huolellista ohjelmistoversioiden yhteisten ja vaihtelevien piirteiden hallintaa. Teolli-
suusautomaatiossa tämä lähestymistapa ei kuitenkaan ole vielä levinnyt laajalle, ja
ei-järjestelmällisiä ohjelmistojen uudelleenkäyttömenetelmiä, kuten kloonaa-ja-omaa,
käytetään yleisemmin niiden yksinkertaisuuden ja käytettävyyden vuoksi.
Tämän diplomityön tavoitteena on toteuttaa prototyyppi helppokäyttöisestä
konfigurointityökalusta, joka ottaa teollisuusnosturisovelluksen spesifikaation syöt-
teenä ja automaattisesti konfiguroi yhteisen ohjausohjelmistoalustan vastaamaan
asiakkaiden vaatimuksia. Työkalu noudattaa konseptia ohjelmistotuotelinjan ke-
hittämisestä mekanismina massaräätälöintiin, joka tarjoaa etuja, kuten lyhyempi
markkinoilletuontiaika, ohjelmistojen korkeampi laatu ja kustannustehokkuus.
Tässä tutkimuksessa sovellettiin suunnittelutieteellistä tutkimusmetodologiaa
iteratiivisena ongelmanratkaisutapana löytää ratkaisuja nosturien sovelluskehitykses-
sä havaittuihin käytännön ongelmiin. Tutkimus koostui neljästä iteraatiosta, joista
jokainen koostui viidestä sääntelevän syklin vaiheesta. Laadullista tietoa ratkaisun
vaatimuksista ja palautteesta kerättiin fokusryhmäkeskusteluilla ja analysoimalla
ohjelmistoartefakteja.
Kehitetty työkalu ratkaisee onnistuneesti teollisuusnosturisovellusten kehitykseen
liittyviä ongelmia, kuten aikaa vievät ja hankalat manuaaliset konfigurointitehtävät,
sovellusten välisen yhdenmukaisuuden puute, ja vaikeus hyödyntää tehokkaasti
uudelleenkäytettäviä ohjelmistoartefakteja. Koska nosturin ohjausohjelmisto on yhä
monimutkaisempi johtuen jatkuvasta turvallisuuden ja tuottavuuden parantamisesta,
työkalu toimii laajennettava alustana, joka tukee tehokasta uudelleenkäyttöä ja
vaihtelevuuden hallintaa tehostaen ohjelmistokehitystä.
Avainsanat Ohjelmistotuotelinja, Ohjelmistojen uudelleenkäyttö,
Teollisuusnosturisovellus, TIA Portal Openness, Suunnittelutieteellinen
tutkimus
 5

Preface
I would like to thank my advisor Imed Hammouda for all the support during the
thesis process. Without the many discussions and the invaluable feedback, the thesis
would not have reached its current shape. I could not have imagined a better advisor.
I would also like to thank Valeriy Vyatkin for supervising the thesis. I am also
grateful to my manager Otso Karhu for the opportunity to work on this topic at
Konecranes. Additionally, I would like to extend my thanks to my friends and fellow
students, Matias Mäki-Leppilampi and Sampo Vänninen for their proofreading and
the insightful conversations during lunches.
Finally, I would like to thank my dear family for supporting me in everything I
do. Without them, I would not be where I am today.

Otaniemi, 29.5.2023

Eetu Suominen
 6

Contents

Abstract 3

Abstract (in Finnish) 4

Preface 5

Contents 5

Abbreviations 9

Glossary 9

1 Introduction 11
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Goal of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Scope, Limitations and Delimitations . . . . . . . . . . . . . . . . . . 13
1.5 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Software Reuse and Variability Management 15

2.1 Software Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Common Software Platform . . . . . . . . . . . . . . . . . . . 16
2.1.2 Variation Point . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Software Product Line Engineering (SPLE) . . . . . . . . . . . . . . . 17
2.2.1 Core Asset Development . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Product Development . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.4 Means of Production . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.5 Benefits and Difficulties of SPLE . . . . . . . . . . . . . . . . 20
2.3 Product-centric Development . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Clone-and-Own . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Industrial Crane Control 26

3.1 Industrial Crane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Waste-to-Energy Cranes . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Steel Cranes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Crane Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Programmable Logic Controller . . . . . . . . . . . . . . . . . 27
3.2.2 PLC Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Next Generation Crane Control System (NGEN) . . . . . . . . . . . . 30
3.3.1 Machinery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
 7

3.4 Crane Automation System . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.1 Variabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Hardware Configuration . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 I/O Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Crane Application Development Process . . . . . . . . . . . . . . . . 34

4 Methodology 36
4.1 Design Science Research . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Research Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Regulative Cycle Framework . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.3 Design Validation . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Data Collection Methods . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.1 Focus Group Discussions . . . . . . . . . . . . . . . . . . . . . 40
4.4.2 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1 Totally Integrated Automation Portal . . . . . . . . . . . . . . 40
4.5.2 TIA Portal Openness . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.3 .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Iterations 43
5.1 Iteration 1: Piloting . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3 Design Validation . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Iteration 2: I/O Tag Configuration . . . . . . . . . . . . . . . . . . . 50
5.2.1 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3 Design Validation . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Iteration 3: Configuration Wizard . . . . . . . . . . . . . . . . . . . . 54
5.3.1 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . 54
5.3.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.3 Design Validation . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Iteration 4: Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.1 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . 58
 8

5.4.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.3 Design Validation . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Results 60
6.1 Crane Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Answers to Research Questions . . . . . . . . . . . . . . . . . . . . . 63

7 Discussion 66
7.1 Revisiting Research Questions . . . . . . . . . . . . . . . . . . . . . . 66
7.1.1 RQ1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1.2 RQ2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2 Contributions and Implications . . . . . . . . . . . . . . . . . . . . . 67
7.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.4 Validity Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8 Conclusions 71
8.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.2 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
 9

Abbreviations
AML Automation Markup Language
API Application Programming Interface
CBD Component Based Development
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DLL Dynamic Link Library
DSR Design Science Research
FBD Function Block Diagram
GSD General Station Description
GSDML General Station Description Markup Language
HMI Human-Machine Interface
I/O Input/Output
IEC International Electrotechnical Commission
IP Internet Protocol
IPC Industrial Personal Computer
LD Ladder Diagram
OOP Object-Oriented Programming
PLC Programmable Logic Controller
SCADA Supervisory Control And Data Acquisition
SFC Sequential Function Chart
SPL Software Product Line
SPLE Software Product Line Engineering
ST Structured Text
TIA Totally Integrated Automation
UI User Interface
UX User Experience
WtE Waste-to-Energy
XML Extensible Markup Language
 10

Glossary
Artifact
Item produced during a software development life cycle.

Asset
An artifact that has a particular value and is intended to be reused.

Common software platform

A set of assets forming a shared structure consisting of software subsystems
and interfaces, which enable efficient development of variant products. Crane
Core is an example of a common software platform.

Component
A clearly defined part of software that fulfills functionality within a software
system.

Crane application
Complete crane control software designed to meet customer requirements.

Crane Core
Proprietary PLC software platform that contains the essential functionalities
of crane control.

I/O tag
Symbolic name representing hardware input/output signal address used in a
PLC program.

Machinery
Crane Core software object that manages features related to one type of
movement axis of a crane, such as a hoist, a trolley, and a bridge.
1 Introduction
1.1 Motivation
To be successful, software development business requires certain aspects which include
reducing time to market, improving software quality, and being cost-effective [1].
Software Product Lines (SPLs), which are collections of similar software products,
aim to address these aspects by extensive and planned reuse of modular software
artifacts. Product lines offer many product options to customers while also reducing
development time and costs [2]. A key step in Software Product Line Engineering
(SPLE) is variability management in which commonalities and variabilities are
identified and managed among software variants and versions arising throughout the
development processes [1]. SPLE is often successfully applied in the field of software
engineering, however the approach is still not widespread in industrial automation,
where the importance of software has increased due to the achieved benefits in
flexibility and costs [3, 2].
The limited adaptation of SPLE is mostly due to the laborious identification
process of reusable software artifacts combined with the interdisciplinary nature of
industrial automation [3]. In the automation software industry, variants also arise
from modifications in other disciplines, such as electrical and mechanical engineering
(i.e., exchange of a sensor). Moreover, not all Programmable Logic Controller (PLC)
suppliers in the automation industry support the object-oriented extensions to
International Electrotechnical Commission (IEC) 61131-3 standard [4]. This can
cause variability management to be more difficult, as concepts such as inheritance
are not possible to implement.
Moreover, the automation industry commonly creates new software variants from
existing control software by copying and subsequently modifying [5]. This product-
centric development approach is referred to as clone-and-own. Despite its drawbacks,
it is a software reuse approach widely used and favored by many practitioners due
to its simplicity and availability [6]. However, in this kind of opportunistic and
unplanned software artifact reuse approach, tracking different types of variants is
difficult and usually proper documentation is not maintained. As a result, this causes
severe maintenance issues in the future [5]. This is because modifications inherently
cause the variants to diverge from their origin, increasing maintenance overhead as
changes must be propagated to all clones [7, 8].
This uncontrolled growth of variant systems, called software mitosis [9], will
eventually lead to a loss of overview [7]. Over time, the growth and compounding
of specific changes in these variant systems cause future changes to be even more
difficult and costly [9]. To achieve sustainable development, software variants must
be compared to extract commonalities and variabilities in them [7]. Maintenance
and software updates become easier when all the variants are formed from a common
software platform, which is then extended based on the captured variabilities. This
reduces maintenance effort as changes do not have to be merged with each individual
variant, only the shared codebase needs to be updated. However, depending on the
situation, this kind of approach might not always be possible or beneficial. Moreover,
 12

eliminating clones and adopting a shared software platform increases coupling and
requires all systems to be retested in case the shared codebase is modified [6].
Overall, systematic software reuse and variability management are essential in terms
of competitiveness. With the increasing complexity of automation software systems
and the growing number of variants, managing variability becomes a challenging task
that requires considerable amount of time and effort.

1.2 Research Problem

In industrial automation, the development of custom industrial crane control software
is a complex and multifaceted process that involves multiple levels of decision-making,
resources, and stakeholders, which make proper Software Product Line Engineering
(SPLE) essential in the field. In a non-standardized crane, the control software is
developed based on the customer’s precise requirements, which consist of mechanical,
electrical, and software elements. As a mechatronic system, these mechanical and
electrical parts also strongly influence the control software requirements of the
crane. With high customer diversity of demand, this leads to multiple different
custom variants of crane control software configurations. These include, for example,
automatic cranes with specialized grabs in Waste-to-Energy (WtE) industry and
cranes with specialized safety features in hazardous mining and metals processing.
One approach to manage software variants using SPLE, is to have a common
control software platform that defines the commonalities among the crane applications
like mentioned previously. This allows application engineers to configure and extend
the platform to then build crane control systems on top of it, which are tailored to
the needs of individual customers. However, as safety and productivity are constantly
being improved with software based smart features in cranes, control software has also
become increasingly more complex and highly configurable. This causes the manual
configuration of the platform to be a laborious and costly task in a crane delivery.
The configuration and programming tasks made by crane application engineers also
introduce possible human errors to the control software, which lower the program
quality and could cause more work in the future.
In SPLE, it is not sufficient to only have well-defined software modules or platforms,
which are planned for reuse, but also processes and tools that support automatic
implementation of products from those artifacts are needed to effectively generate a
wide range of customizable products [10]. There is a need for these types of tools
and approaches that can utilize feature profiles of the software variants to automate
application configuration and development tasks, thus minimizing manual labor.
Before developing such a tool, it must be ensured that crane specifications, the
common software platform, and other assets can be effectively utilized to automate
such tasks in a way that is easily maintainable and extendable.

1.3 Goal of the Thesis

The goal of the thesis is to implement a prototype of an easy-to-use configurator tool
that takes a crane application specification as an input and automatically configures a
 13

common control software platform to appropriately generate an application instance.

This will be carried out by first identifying technical problems in custom industrial
crane application development and investigating what configuration tasks should
be included in the tool based on the identified problems. The tool will reduce
the overall engineering effort required to build crane applications tailored to the
needs of individual customers by capitalizing on the commonality among different
applications. This will shorten the amount of time needed to develop non-standardized
crane applications, which will reduce time to market and improve cost effectiveness
throughout a crane delivery process. To conclude, the thesis tries to answer the
following research questions:

• RQ1: What technical problems are faced in crane application development?

• RQ2: What configuration tasks should be included in a crane application

configurator tool?

To answer the research questions, discussions are held with crane application
engineers to identify the underlying variabilities and required configuration tasks while
also receiving insight into the current state of the application development processes.
Additionally, part of the identification process includes investigating the software of
the application variants as well as reading engineering and commissioning manuals.
The work will follow Design Science Research (DSR) methodology to identify and
understand the tool requirements prior to the development and evaluation of the
solution. The work will consist of multiple iterations in which a regulative cycle
framework is applied. The goal of each iteration is to improve the solution based
on the evaluation of the previous iteration. The regulative cycle in each iteration
consists of five phases: problem investigation, solution design, design validation,
implementation, and evaluation.

1.4 Scope, Limitations and Delimitations

This thesis focuses on the concepts of software reuse and variability management, and
how common and variable parts can be used in a tool-based automatic application
generation solution in crane control software domain. It does not address different
systematic feature and variability modelling approaches, which try to capture variant
characteristics, features, and configuration options. Although variability modelling
approaches are essential part of a successful SPLE workflow, they might cause
development processes to be less flexible and thus not bring as much concrete value
to the application engineers as automatic code configuration and generation tools.
Additionally, with substantial number of complex variants and no global knowledge
base of the variants, creating effective feature models would be a time-consuming task.
Moreover, maintaining this kind of database with feature mapping rules requires
considerable effort when new variants are constantly created. Therefore, it seems
more beneficial to first create a basic crane application configurator tool and assess
its usefulness before extending the tool with proper feature models.
 14

In addition, this thesis will only cover control software configuration in industrial
crane applications. It will not address other software systems (e.g., motor controller
software and web user interface) that can be included in crane applications. The
reason for this is that the other software systems are already mostly preconfigured
with no significant variability between the applications, while the control software
configuration remains the most time-consuming phase. Integration of other software
systems, such as a sales tool, to the configuration tool were also excluded from this
work. The configurator tool will be designed to support industrial cranes using Crane
Core software platform developed by Konecranes Oyj and implemented in Siemens’
Totally Integrated Automation (TIA) Portal automation software, meaning that
other crane types and automation software vendors are not considered in the scope
of this thesis.
The work is limited to the use of the Crane Core software platform as it is
the base software used in the delivered industrial cranes of the client of this work,
Konecranes Oyj. As a result, the developed configurator tool is also then limited by
the platform in terms of what should be configured in the software. The automation
software in which Crane Core is built also limits the choices of technology for the
automated configuration. The technologies chosen by the author, which are used
for configuring the software platform and building the tool, also have their own
technological limitations.

1.5 Structure of the Thesis

The rest of this thesis is organized into seven more chapters as follows. Chapter 2
introduces and compares reuse and variability management approaches in software
development. Chapter 3 discusses industrial crane control systems and the common
software platform used as part of the experimental part of this thesis. The method-
ology of the thesis is presented in Chapter 4. The work done during the different
iterations of the tool is described in Chapter 5. In Chapter 6, the results of the thesis
are presented, along with an overview of the finished implementation of the tool,
followed by a discussion in Chapter 7 and conclusions in Chapter 8.
 15

2 Software Reuse and Variability Management

In this chapter, background information and context of this study is discussed in
terms of software reuse and variability management. First, systematic software reuse
is explained and its connection to Software Product Line Engineering (SPLE) is
described. Then, the processes and the deployment of SPLE are discussed along with
its known benefits and difficulties. At the end of this chapter, an alternative approach
to SPLE is discussed called product-centric development. Finally, clone-and-own, a
commonly used non-systematic software reuse approach, is presented as it is generally
associated with product-centric development.

2.1 Software Reuse

Software engineering field is considered to originate from the 1968 NATO Software
Engineering Conference [11]. The conference focused on the software crisis, which is
described as the challenge of creating large and efficient software cost-effectively [12].
The crisis was due to the rapid increase in computing power and the complexity of
problems while not having adequate software development techniques to manage
them. The concept of software reuse was proposed for overcoming the crisis. Krueger
[12] describes software reuse as "the process of creating software systems from existing
software rather than building software systems from scratch". There are two types of
software reuse, systematic and non-systematic reuse, which are covered in Sections
2.2 and 2.3, respectively as parts of two software development paradigms. Systematic
software reuse can be regarded as among the most effective software engineering
approaches for achieving increased productivity, higher quality, and reduced costs
[13].
In the 1968 conference, software engineers acknowledged the fact that software
systems can share functionality even though they are designed for different use cases.
Implementing the same functionality multiple times is not efficient, thus it made more
sense to create it in the form of a library, which is a collection of software artifacts
designed for reuse [7]. Figure 1 illustrates this concept of utilizing shared functionality
contained within a library. In the figure, two similar systems utilize a common library
instead of creating duplicate components within the systems. This kind of approach
for achieving software reuse is called Component Based Development (CBD) [13].
Other approaches are, for example, Object-Oriented Programming (OOP), Domain
Engineering, and Software Ecosystems.
An extra layer of complexity is added to software maintenance and development
when variation is introduced [7]. This means that the two systems no longer share
identical functionality. In Figure 1, system P1 uses a software component a from
the library, but in P2 a variant of component a is implemented. These kinds of
similar but not identical systems are called product families or Software Product
Lines (SPL). Software Engineering Institute [14] defines a software product line as
"a set of software-intensive systems that share a common, managed set of features
satisfying the specific needs of a particular market segment and that are developed
from a common set of core assets in a prescribed way."