16

Figure 1: Software reuse by utilizing shared functionalities contained in a library [7].

With increasing number of product variants arising from the need of local modifi-
cations at different customer sites, a simple software library is not effectively filling
its purpose anymore [9]. Individual variants inherently have their distinctive charac-
teristics, which need to be considered during maintenance and updates of the system.
Thus, leading to increased costs and decreased quality [7]. To control this additional
complexity of variability while still achieving the benefits of systematic software
reuse, Software Product Line Engineering (SPLE) was developed. Before covering
the concept of SPLE, first some essential terms are explained.

2.1.1 Common Software Platform

A common software platform or a software platform is also referred to as a core
asset set, which forms the foundation for a software product line [15]. It is a shared
structure consisting of software subsystems and interfaces, which enable efficient
development of variant products. It can include not only reusable software components
but architecture, domain models, test cases, and other artifacts of the development
process [14]. A successful platform supports software reuse by containing product
commonalities while also providing means for variability to allow innovation and
flexibility [16]. Software platforms that are used in this work include, for example,
Crane Core and .NET Framework.

2.1.2 Variation Point

Core asset sets are designed with in-built variation points [17]. They are representa-
tions of places of variability within the assets. These places change depending on the
individual product to meet the required needs. Variation points use variation mecha-
nisms to create diversity in the product line. These mechanisms can be, for example,
code macros, configuration properties, runtime conditionals, feature mappings and
 17

parameterization.

2.1.3 Variant
Pohl et al. [15] defines a variant as a representation of variability within artifacts
in which variability means the ability to change. A variant is a single choice in a
variation point. For example, in the context of a car, a variation point could be the
color of a car whereas variants could be then red (car) and green (car). A variant can
also be defined as a complete product or a system in a product line, which consists
of a set of artifacts [18]. Both definitions are used in this thesis depending on the
context.

2.2 Software Product Line Engineering (SPLE)

According to Pohl et al. [15], Software Product Line Engineering is a development
paradigm to systematically combine the use of a common software platform and
mass customization to meet the needs of customers in the development of software
applications. It is a way of cost-efficiently developing a product portfolio by capital-
izing on the similarities of the products while also recognizing their differences [17].
When a product family is considered as a single entity, rather than many individual
products, significant benefits are achieved in production and maintenance. In SPLE,
building a product consists of the following steps [14]:

• Taking reusable components from a common software platform

• Configuring the components through variation mechanisms

• Adding new components

• Assembling the collection of components according to feature profiles

SPLE consists of three essential iterative activities: core asset development,

product development, and management [14], which are illustrated in Figure 2. These
activities are a mix of technology and business practices, which together allow the
creation of tailored products according to the defined product-building approach.

2.2.1 Core Asset Development

Core asset development is often referred to as domain engineering or development for
reuse. It means proactively planning for software reuse, analyzing the domain as well
as maintaining and building reusable artifacts [7, 14]. As it does not result in any
specific product, it requires strategic thinking that goes beyond a single product. Most
importantly, core asset development requires identifying and managing common and
variable artifacts of the product family, which is referred to as variability management.
Common artifacts are included in all of the products, while variable artifacts are
specific to individual products. Both common and variable artifacts are mapped
 18

Figure 2: Essential activities of product line development [14].

to features desired by stakeholders. Kang et al. [19] defines features as distinct

user-visible aspects or characteristics of a system.
A feature model is a way of describing the relationships and dependencies of
features belonging to a specific domain [20]. Figure 3 depicts the variability of a
simple car using a feature diagram notation commonly used in feature modelling.
The figure shows that every car has a body, a transmission, and an engine. These are
mandatory features marked with filled circles. On the other hand, not every car has
a trailer, which is indicated in the diagram with an optional feature "Pulls Trailer"
(empty circle). The engine of a car can be powered with gasoline, electric, or both
(filled arc). In contrast, the car can be either automatic or manual but not both.
This is called an alternative relation denoted with an empty arc.

Figure 3: A feature model of a simple car [20].

Variability management guides to the construction of variability models, which

describe the commonalities and variabilities of the product line from variation points
[1]. Different types of variability models include, for example, feature models [19],
decision models [21], and Orthogonal Variability Models (OVM) [22]. A wide range
of frameworks and tools to support variability management have been proposed
and evaluated in many studies. For example, Rubin and Chechik [23] presented a
framework, which refactors cloned products into a SPLE representation through
 19

model comparison and merging. Yoshimura et al. [24] introduced an approach for
detecting variability in software products from change history. Furthermore, similar
tools have been proposed in industrial automation research. For example, Schlie et al.
[5] proposed a framework for comparing PLCopen1 projects in Extensible Markup
Language (XML) form and visualizing the produced results.
Besides managing and creating core assets through variability management, core
asset development involves defining product line scopes and production plans [14].
The product line scope encompasses all the products that construct the product
line, while the production plan outlines how these products are generated from the
core assets. These three outputs are then utilized in product development. In this
thesis, individuals involved in the core asset development are referred to as platform
engineers, while application engineers are responsible for the product development.

2.2.2 Product Development

In SPLE, product development is also referred to as application engineering or
development with reuse [1]. Developing applications using platforms means deriving
specific products for the needs of a customer from the product line using reusable
assets and exploiting product line variability [15]. Figure 4 illustrates this concept in
which products are derived from a common platform based on feature models. The
platform consists of both common and variable artifacts, which are used in deriving
the products. In addition of the three outputs of the core asset development (core
assets, product line scope, and production plan), product development depends on
the requirements of the individual products [14].

Figure 4: Feature models used as a method for deriving products from a common
platform [7].

1
https://www.plcopen.org
 20

2.2.3 Management
Management activity in SPLE is divided into technical and organizational manage-
ment [14]. Technical management oversees the activities of the core asset and the
product development teams by ensuring that these two units follow their intended
product line process tasks and collect data for progress tracking. Organizational
management ensures that the organizational structure supports SPLE activities and
that the organizational units receive enough resources.

2.2.4 Means of Production

The means of production in SPLE denotes a common mechanism that utilizes the
variation points in the core assets to generate configured versions of artifacts that
form a product in the product line [25]. The means of production can be manual
or automated. Although with large product lines and frequent changes, manual
production is impractical. SPLE tools can automate product generation by exercising
variation points, which are tied to a feature model. Examples of such application
generator and configurator tool are Gears [26] and pure::variants [27]. Application
generators have proven to be a successful method of achieving software reuse and
generally result in higher productivity than approaches like component-based reuse.
In automation industry, Papakonstantinou and Sierla [2] also presented a toolchain
for automatically generating PLCopen XML project files from feature models based
on Systems Modeling Language (SysML). These kinds of configurator tools that
apply product specification to the core assets are the essence of SPLE by allowing
rapid and cost-effective production of variants [17].
In configuration tools, when deriving a product from the product line based on
these variation points, different feature binding decisions are made using variation
mechanisms at different times, called binding times [13]. Based on these times,
bindings can be categorized into compile-time binding, load-time binding, and
runtime binding [28]. In compile-binding time, decisions are made about feature
inclusion before or during the compilation process [13]. This is done by using tools like
preprocessors or feature-oriented programming. Any code related to the nonincluded
features is then excluded from the final product, resulting in a smaller and more
optimized program.
Alternatively, load-time binding allows engineers to select desired features after
the program compilation until the program is started [13]. The feature selection
is made after deployment using configuration files or command-line parameters.
This approach provides more flexibility in feature selection compared to compile-
time binding. Finally, some techniques, such as reflection and context-oriented
programming, enable runtime binding in which decisions are made in runtime and
can change during the execution of the program.

2.2.5 Benefits and Difficulties of SPLE

With the use of automated production, product lines enable rapid production of
product variations, a concept known as mass-customization [29]. Fisher [29] provides
 21

a good example of this phenomenon by highlighting the case of National Bicycle in

Japan in 1991. The company increased its market share from 5 to 29% by transitioning
from mass-produced bikes to mass-customized ones. Rather than offering a limited
selection of pre-made models, the company was able to deliver fully customized bikes
to customers in two weeks. A responsive supply chain with a produce-to-order system
allowed supply to be matched with demand as it happened.
The process of utilizing the commonalities and managing variability in a prod-
uct family undeniably leads to remarkable efficiencies in the development process.
When software reuse is proactively planned, enabled, and enforced to allow mass
customization, improvements in the following areas are achieved [14, 13]:

• Quality. Accumulating error fixes and improvements from reuse to reuse.

• Productivity. Increase in productivity due to reusable assets and reduced

testing efforts. This effectively leads to overall reduced development costs.

• Reliability. Reuse of tested components increases the reliability of a system.

When components are used in multiple systems, possible errors are detected
more likely while also strengthening confidence in them.

• Time to market. Due to increased productivity with reusable assets, the

time from the conception of the product to its market availability is reduced.
This is visualized in Figure 5 in comparison with single systems development
in which effective reuse is not applied.

• Documentation. With reusable software components, the amount of docu-

mentation to be written is reduced.

• Maintenance. As quality and reliability are increased, fewer defects can be

expected, which in turn leads to reduced maintenance effort and costs.

• Team size. A commonly known fact in software development is that even

though the size of a development team is doubled, productivity does not
double because of increased communication overhead. Reusing many compo-
nents allows smaller development teams, which leads to reduced costs, better
communication, and increased productivity.

In addition, the Software Engineering Institute has listed benefits of software

product lines, such as ability to rapidly customize a product, decreased product risk,
increased market agility, increased customer satisfaction, ability to maintain market
presence and to sustain growth [30].
The transition to software product line engineering is not straightforward. It
comes with its own technical and non-technical difficulties related to the adoption
and upkeep of the product lifecycle.

• Initial investments. Systematic software reuse requires large initial invest-

ments in infrastructure, training, and tools, which payoff only years later [13].
 22

Figure 5: Time to market with respect to the number of different systems with and
without Product Line Engineering [15].

In core asset development, there are costs in creating reusable assets. In con-
trast, application engineering generates expenses when retrieving the assets
and configuring them into individual products [31].

• Reusable assets. There are technical challenges for software reuse, such as
issues related to finding suitable reusable software, legacy components, and
difficulties involving adaptation of the assets [13].

• Knowledge harvest. Extracting and sharing knowledge of diverse technical

artifacts such as source codes, design models, and requirements are challenging
and time-consuming tasks [32]. Without a single easily accessible repository,
finding required information and abstracting system requirements into coherent
and consistent variability models are difficult tasks.

• Architects. Lack of good architects leads to challenges in developing and

maintaining a platform architecture that supports a software product line [32].
Architects need to know how to make the platform extensible and flexible while
considering the inherent variation in the product line.

• Organizational structure. The separation of the core asset team (platform

engineers) and the product team (application engineers) causes the product
team to be in a situation in which their choices are limited [32]. They must
accept the architecture that was not designed by themselves, which can be
challenging. There should be proper communication between the two teams to
alleviate this issue.

• Management support. Getting sustained management support and funding

are essential for successful SPLE [13]. Managers need to be aware of the initial
costs and convinced about the obtainable long-term savings.
 23

2.3 Product-centric Development

SPLE stands in contrast to product-centric development in which products are
developed individually, usually starting out from a cloned copy of a similar product
[17]. In product-centric development, little advantage is taken in terms of the
commonalities in the product portfolio. This kind of development approach is
associated with non-systematic software reuse. Whereas systematic reuse of assets in
SPLE is structured around organization-wide plans and processes, non-systematic
reuse depends on the knowledge and initiative of individuals. It involves little if any
planning and control by the management.
In product-centric development each product team focuses solely on their indi-
vidual products, and there is limited collaboration and sharing between the teams
[17]. To find defects from a product portfolio each of the N product teams should
communicate with the other N − 1 teams, which is illustrated in Figure 6. As the
number of products in the portfolio grows, the time complexity of managing defects
and implementing enhancements increases to the square of the number of products.
As a result, deadlines are missed, quality declines, and morale among employees
decreases. In a modest product line of 20 products, theoretically 400 interproject
communication efforts should be made.

Figure 6: Product-centric development and O(N 2 ) time complexity described and

illustrated in [17].

In contrast, SPLE involves modifying core assets to ensure that products are
created correctly using a product configurator [17]. Addressing the source of defects
in core assets rather than individual issues on a product-by-product basis, results in
an O(N ) operation compared to an O(N 2 ) operation. Therefore, SPLE approach,
visualized in Figure 7, is more scalable and effective for managing a large portfolio
of products.
 24

Figure 7: PLE factory and O(N ) time complexity described and illustrated in [17].

Due to the mentioned challenges in Section 2.2.5 and the interdisciplinary nature
of industrial automation, SPLE is not widely adopted in the field of industrial
automation [3]. Product-centric development is still more common in the field
because not all companies apply modular software concepts in their development
processes. Most common form of reuse is a non-systematic approach called clone-
and-own.

2.3.1 Clone-and-Own
Clone-and-own is a non-systematic and unplanned software reuse technique in which
software is copied and subsequently modified to address product requirements that
are similar but not identical [9]. The term clone refers to the copying of artifacts,
while own means to take ownership of the copy by modifying it. This technique
is illustrated in Figure 8. However, this non-systematic technique, without proper
central governance, eventually leads to significant number of variants of a system.
This phenomenon is known as software mitosis. Faust and Verhoef [9] describe it as an
uncontrolled natural emergence of variants caused by ungoverned local modifications.
Despite the availability of new techniques to manage this complexity of variability,
cloning is still widely used due to its perceived simplicity and availability, as shown in
a study conducted by Dubinsky et al. [6]. The approach provides a quickly available
mechanism to start from projects that are already verified, while still allowing to
modify them freely and independently. In the study, they found that practitioners
are lacking the awareness and knowledge of alternative software reuse methods.
Therefore, it is hard to convince them that other methods might yield better results.
Various tools and frameworks have been proposed to deal with cloned product
 25

variants. Some propose to merge the variants into a single platform to eliminate all
clones [9], while others suggest maintaining variants [18] without trying to refactor
them. Faust and Verhoef [9] introduced a grow-and-prune technique in their study
to address software mitosis. The technique involves directed growth phases to
quickly address market needs, followed by pruning phases in which generic solutions
are created by identifying commonalities between the products. Grow-and-prune
technique balances between the high demands of customer specific software in the
short term and a more maintainable generic solution which saves in costs and efforts
in the long term.

Figure 8: Products are created by changing a copy of an existing similar product by

modifying (a’), removing (c) or adding (d) components [7].
 26

3 Industrial Crane Control

In this chapter, the core concepts and background of industrial cranes and their
control systems are discussed. The crane configurator tool that is developed as a part
of this thesis uses a common crane control system platform, making it essential to
understand the platform itself and the basic concepts used in the control of a modern
industrial crane. First, an overview of an industrial crane and its applications is
given. After that, the chapter introduces the basics of crane control, the underlying
automation system, and the software platform in which the tool operates.

3.1 Industrial Crane

An industrial crane, also called an overhead crane, is a heavy-duty machinery found
in industrial environments that is capable of lifting and moving extremely heavy or
bulky loads safely and precisely [33]. Industrial cranes use the overhead space of an
industrial facility for moving a load in a rectangular area side to side and backward
and forward. They consist of three main movement axis types that are realized by
three machinery units: a bridge, a trolley, and a hoist (Figure 9 and Figure 10). The
bridge of an industrial crane runs on two parallel rails seated in runway beams. The
trolley moves horizontally across the bridge beam connected to one or more girders.
The hoist manages the vertical movement of the end effector, such as C hook, and it
is mounted on the trolley. Crane movement is typically controlled by an operator
with a wired pendant or a radio controller, which guide the electric-powered travel
of the crane. Cranes are typically used to transfer materials to support activities
such as manufacturing, storing, loading, or unloading in a facility.
Industrial crane applications differ considerably in terms of mechanical, electrical,
and software features depending on the industry in which they are used. These
industries include, for example, general manufacturing, automotive, paper, Waste-
to-Energy (WtE), steel, and aviation. The different industries divide the cranes
into basic application types, but individual customers then often have additional
requirements based on the factory specific processes and business needs. Next, to
give a general understanding of a few crane applications, WtE and steel cranes are
briefly presented.

3.1.1 Waste-to-Energy Cranes

Waste-to-Energy (WtE) cranes (Figure 9) are used as a waste or ash processing
cranes in the process of converting waste into electricity or heat. The role of WtE
cranes is to manage the waste materials, which may include municipal solid waste,
industrial waste, or biomass. They are used to transport the waste from storage
bunkers to the incinerator feed hoppers or other processing equipment in which
the waste is burned or converted into fuel. Ash cranes move the by-product of the
process, ash, to trucks on the other side of the powerplant. WtE cranes are typically
equipped with a grabber or a claw-like tool that can pick up and move large volumes
 27

of material. The cranes are usually fully autonomous making the entire process safer,
more efficient and profitable.

Figure 9: 2-girder Waste-to-Energy crane [34].

3.1.2 Steel Cranes

Steel cranes (Figure 10) are sturdy and resilient cranes used in the harsh environments
of steelmaking processes for tasks such as scrap handling, casting, and forging. The
process includes many different types of cranes, such as charging cranes, ladle cranes,
and forging cranes. Charging cranes transport and discharge scrap metal to the
charging area of the blast furnace. They usually operate with two hoists and two
trolleys because the materials are unloaded by lifting the auxiliary hoist to tilt the
material container. Efficiency and reliability of the steel cranes are essential for
the safe production of high-quality steel in the extreme environments with strong
vibrations, direct flames, and elevated temperatures.

3.2 Crane Control

In a conventional industrial crane, all control devices are wired directly with the
system in a way that leads to a certain functionality of the crane [35]. This usually
leads to a substantial number of electrical wires, in turn, causing significant wiring
work and difficulties in troubleshooting and repairs. Most importantly the control
system could not be modified without needing to rewire the connections to the input
and output devices. To overcome these challenges, a Programmable Logic Controller
(PLC) is used to control the crane movements.

3.2.1 Programmable Logic Controller

Programmable Logic Controller (PLC) is a solid-state industrial control device used
for the automation of real-world processes by using a programmable memory to
store instructions and realize timing, counting, logic, and sequencing functions [35].
 28

Figure 10: 4-girder charging crane [34].

The stored instructions are mostly implemented in compliance with the IEC 61131-
3 standard [4], which includes programming language standards, such as Ladder
Diagram (LD), Function Block Diagram (FBD), Structured Text (ST) and Sequential
Function Chart (SFC). Field devices or external equipment such as input devices
e.g., switches and sensors and output devices e.g., motors are connected to the PLC
through Input/Output (I/O) modules.
During the operation of a PLC, its Central Processing Unit (CPU) completes
three cyclic tasks: (1) it reads the input signals from the field devices, (2) applies
the programmed behavior stored in the memory and (3) writes signals to output
devices, which then control a machine or a process [35]. This sequential process
is known as scanning. The PLC architecture, visualized in Figure 11, consists of
multiple subsystems, which implement this process [36]. The architecture results in
a flexible automation system used for controlling processes that vary in their nature
and complexity. To modify a control system, only the programmed instructions need
to be changed [35]. There is no need to rewire the connections to the input and
output devices. Unlike general purpose computers, PLCs are mechanically more
robust, resistant to vibration, and are designed to function in extreme temperatures
under dirty conditions. This allows PLCs to be used reliably for extended times in
industrial environments.

3.2.2 PLC Project

A PLC project, illustrated in Figure 12, consists of two main parts: hardware
configuration and executable program (software), which are both downloaded to
the PLC. Hardware configuration defines all the physical devices of the automation
system and network connections between them. Executable program is the software
 29

Figure 11: An overview of PLC architecture described in [36].

that the PLC runs cyclically as part of the scanning process. Hardware configuration
and executable program can still both be divided into their own standard and fail-safe
components.

Figure 12: An overview of a PLC project in TIA Portal.

The fail-safe components are used to implement functional safety systems in

compliance with the international functional safety standards [37], for example, IEC
61508 – Functional Safety of Electrical/Electronic/Programmable Electronic Safety-
related Systems [38]. Fail-safe PLCs, designed for functional safety use, are utilized
in applications which require increased level of reliability and safety. Fail-safe PLCs
 30

achieve these by redundant architecture and high level of self-diagnostic coverage. If

a fault or a failure is detected, a fail-safe PLC can place the system in a safe state or
cause a predictable safe shutdown.

3.3 Next Generation Crane Control System (NGEN)

As Industry 4.0 technologies are becoming essential in modern data-driven businesses,
cranes have transferred to more software-oriented systems from merely electrome-
chanical systems to cover the demand of new levels of safety, flexibility, and efficiency.
Thus, the control of a modern crane can be, for example, fully automated with
software. Additionally, intelligent software features, such as anti-sway control of
the hook which increase safety and productivity as well as remote real-time data
monitoring capabilities for predictive maintenance, are also typically included in the
modern systems. One example of a PLC software concept that allows these features
to be implemented in an industrial crane is Next Generation Crane Control System
(NGEN) developed by Konecranes Oyj.
NGEN is an architectural PLC software concept for industrial cranes implemented
in Siemens’ TIA Portal automation software. TIA Portal and other technologies
related to this work are discussed in Section 4.5. NGEN typically uses an Industrial
Personal Computer (IPC) as the controller device instead of a traditional hardware
PLC. The used IPC has a PLC software controller running independently from
the operating system enabling the same functionality as a hardware PLC but also
offering more flexibility and ability to run PC applications. NGEN consists of three
main parts: Crane Core, library features and application software. Crane Core
is a PLC software platform, which standardizes the essential crane functionalities
of crane control software in industrial crane applications making the maintenance
and documentation of the features easier. Crane Core platform is extended with
application specific software to cover individual customer requirements. Application
software uses well-defined interfaces to communicate with Crane Core.
Crane Core architecture contains software modules with clear interfaces and
predefined set of hardware and software features that can be used in any crane
application, for example, general manufacturing, WtE, hot metal and fully automatic
cranes. Crane Core consists of a standard core, a fail-safe core, and core interfaces.
Library features are reusable software artifacts but not applicable in all crane appli-
cations. They are implemented outside Crane Core architecture and use interfaces to
communicate with Crane Core similar to application software. NGEN PLC software
architecture is visualized in Figure 13.
Next, some of the most important concepts of Crane Core platform are explained.
They are essential for understanding the functionality of the developed configurator
tool.