61

1. An application engineer receives the newest version of the Crane Core platform
and the tool from a central repository.

2. The application engineer runs the tool and follows the instructions for inputting
the crane specification. Alternatively, the engineer can load a previous crane
specification and continue with that.

3. The application engineer selects which components of the platform should be

configured and starts the configuration process.

4. After the configuration process has finished, the tool generates a log file, which
can be investigated for in-depth information about the results.

5. If the automated configuration was executed successfully, it is recommended to

save the crane configuration data for future use.

6. If the application engineer is satisfied with the results, the platform can then be
extended manually with application specific software. Otherwise, if the results
were not satisfactory, the platform can then be configured manually or the tool
could be run with different parameters.

6.1.3 Implementation
The tool is implemented with C# using .NET Framework SDK 4.8. It uses Windows
Forms UI framework2 for building the desktop user interface. The tool utilizes
.NET-based TIA Portal Openness API for interacting with TIA Portal, and it
requires the use of .NET Framework SDK 4.8. The implementation tries to follow
SOLID principles [52] and general Object-Oriented Programming (OOP) guidelines
by structuring the program into well-defined reusable objects.
The tool utilizes many of the .NET-based APIs and libraries. The most essential
ones are LINQ to XML3 , Json.NET4 and AeroWizard5 . LINQ to XML allows, for
example, manipulating XML trees, which makes it possible to import modified func-
tion blocks to TIA Portal. Json.NET allows JSON serialization and deserialization
of any .NET objects, which is used for saving and loading crane configuration data.
Finally, AeroWizard is used for creating the stepwise wizard user interface.

6.1.4 Design
The architecture of Crane Configurator consists of three main layers: presentation
layer, service layer and data layer, which can be seen in Figure 27. The presentation
layer is responsible for the user interface and the logic in it. It interacts with the user
and communicates the information to the service layer. The service layer implements
all of the configuration tasks and the connection to TIA Portal. It contains three
2
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/?view=netdesktop-7.0
3
https://learn.microsoft.com/en-us/dotnet/standard/linq/linq-xml-overview
4
https://www.newtonsoft.com/json
5
https://github.com/dahall/AeroWizard
 62

subcomponents: hardware, machinery, and parameter configurators, which all have

their own role. Lastly, the data layer consists of different input data, such as stored
crane specifications, field device data, and data models used in the other two layers.

Figure 27: An overview of the Crane Configurator architecture.

6.1.5 User Interface

The user interface of the Crane Configurator consists of six different pages, four of
them are presented in Figure 28:
• Welcome page containing general information about the tool.
• General crane info page in which a project name and an application type can
be defined. It also allows the option to select and load a previously saved crane
configuration.
• Input files page containing text fields for file paths of different input files, such
as Crane Core software, field device library, parameters, and I/O tag Excel file.
• Hardware configuration page in which a user can configure field devices.
• Machinery configuration page in which a user can configure crane machineries
and devices included in them.
• Project generation options page allows to select what shall be configured. Some
options might be disabled based on earlier choices a user has made.
The user interface contains instructions that guide the user thorough the configu-
ration process. If all the required information is entered, the user can proceed to the
next page by clicking "Next". Previous pages can also be returned to by pressing the
arrow button in the top left corner.
 63

Figure 28: An overview of the Crane Configurator user interface. The figure shows
four of the six main views in the user interface: a) Welcome page b) General info
page c) Hardware configuration page d) Project generation options.

6.2 Answers to Research Questions

RQ1: What technical problems are faced in crane application develop-
ment?

A problem-driven investigation in which problems are identified in crane application

development, was an essential starting point for the work in order to set the scope
for the first iteration. Although SPLE is practiced to some degree in the company
using a common software platform (Crane Core), many technical challenges still
arise from the high level of variability, non-systematic software reuse approaches, and
the lack of appropriate tools and knowledge. Based on the focus group discussions
with the application engineers, it was identified that one of the most troublesome
aspects of the application development is the manual configuration of the PLC I/O
tags. It is a time-consuming and tedious process in which mistakes are easy to make.
I/O connections being the foundation between PLC hardware and software, it is
important that they are done clearly and correctly to avoid future problems in crane
application development.
 64

Parameter configuration and CRC issues are additional technical challenges that
the application engineers are facing. As variability in Crane Core is mostly realized
by parametrization, it is a major part of the platform configuration, and therefore
takes significant effort from the application engineers. CRC values, which are an
essential part of failsafe parameters, also bring their own challenges to the application
development. Although issues with CRC values can be quite situational, not planning
for them in advance can lead to significant work in the future.
Other essential and time-consuming configuration tasks, such as hardware and
machinery configuration, are also included in the application development process.
They are not as serious challenges as there are already valid approaches for managing
them that have been used in the past. During the discussion with the application en-
gineers, it was discovered that, for example, it is common to create project hardware
configuration from previous projects by applying the clone-and-own-approach. More-
over, configuring new machineries in Crane Core is not that common, as most of the
projects include three or four machineries, and the platform is already preconfigured
with four machineries. Although the clone-and-own technique does not fit into the
basis of SPLE, moving from an already validated and working approach to a new
practice could just cause more problems.
Another problem in crane application development is the lack of harmonization
among the development practices. During the analysis of different application projects,
it was noticed that individual application engineers working on different projects
have subjective design paradigms and individual programming practices, which
have been formed over time. As crane application specifications themselves vary
considerably, this makes maintenance and variability management increasingly more
difficult. As application projects diverge more and more from the common platform,
the development approach starts to transfer from SPLE to a more product-centric
development. As discussed in Section 2.3, solving issues then requires more effort as
they need to be addressed on a product-by-product basis [17].
An additional problem related to the development approaches is the difficulty in
sharing and utilizing reusable software artifacts. Although Crane Core manages to
capitalize on the commonalities and variabilities among crane applications, it does
not include many of the functionalities developed as part of the crane applications.
As a result, the application engineers must constantly communicate with each other
to find reusable artifacts and avoid reimplementing the same functionalities. All the
identified problems in crane application development are presented in Table 1 in
addition to the solutions implemented in Crane Configurator, which are covered in
the answer to the second research question.

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

configurator tool?

The crane application configuration and development processes include multiple

tasks, some of which are more complex or time-consuming than others. Therefore,
it was crucial to identify the tasks that would address the identified problems and
provide the most value to the application engineers when automated while also
 65

keeping the tool user-friendly. Based on the collected data, three main tasks of
the application configuration were identified: hardware, machinery, and parameter
configuration. Each of these components are further divided into subtasks for more
specific configuration tasks.
Hardware configuration includes creating new field devices, setting their param-
eters and configuring the network that connects them. Machinery configuration
consists of configuring the appropriate number of machinery objects in the PLC
project and linking the I/O tags to hardware interface variables. Lastly, the parame-
ter configuration involves setting PLC program parameters based on a given crane
specification and calculating CRC values.
All these configuration tasks were included in Crane Configurator as they solve
the identified problems covered in the answer to the first research question. The
tasks are presented as solutions in Table 1 along with the corresponding problems
and their impact in application development.

Table 1: The identified problems in crane application development and the solutions
to them in Crane Configurator.
Problem Impact Solution
Laborious I/O tag Automated linking of the I/O tags to
High
configuration hardware interface variables
Automated parameter configuration
Laborious parameter
High based on a crane specification and
configuration
parameter templates
Laborious hardware Automated configuration of field
Low
configuration devices and network connections
Laborious addition/removal Automated configuration of
Low
of machinery objects machineries
Lack of harmonization
Automated standard approaches to
among crane application Medium
many configuration tasks
development
Difficulty in efficiently Automated reuse of components such
utilizing reusable software Medium as machinery objects and common
artifacts predefined field devices
 66

7 Discussion
This chapter discusses the meaning and importance of the results of the study. First,
it addresses what has been confirmed and refuted, as well as what can be interpreted
based on the findings and the answers to the research questions. After that, the
chapter presents the contributions and the implications of this work, along with
its limitations. Finally, the validity threats of the research and their mitigation
strategies are discussed.
The research problem of the thesis was the lack of an automatic tool for configuring
varied crane applications in Konecranes Oyj. The problem was successfully resolved
by the development of a crane configurator tool, which allows for extending the
Software Product Line practices and better utilization of the Crane Core PLC
software platform in the company. Discussions with the application engineers and
the validation iteration confirmed that the tool is capable of reducing the workload
and time spent in the configuration process. It was also confirmed that the tool is
easy-to-use and can be extended with new features. From a technical standpoint, no
issues were found that would prevent the deployment and further development of
the tool.
Ideally, a crane configurator solution would produce a fully configured application
based on a given crane feature profile i.e., a product specification and the common
software platform. This form of process is described as a production line by Krueger
et al. [17], and it enables rapid production of variants for any of the products in a
product portfolio. In this kind of product factory, products are not manually created
but instantiated. However, this approach is not realistic for the entire crane product
family, as there will always be a demand for specialized custom crane solutions
that require some form of manual tailoring. Nevertheless, more automatic crane
application configuration could be achieved with further tool development in some of
the more standard solutions, which are mostly implemented by copying parts of the
software from earlier projects. With automatic generation of varying custom crane
applications, the benefits of SPLE discussed in Section 2.2.5 would be fully realized.

7.1 Revisiting Research Questions

7.1.1 RQ1
As an answer to the first research question, the study revealed that the I/O tag
configuration was one of the most time-consuming and challenging parts of the crane
application configuration process. Although it is already implemented in the tool,
that area could be further researched and extended to provide even better support
to application engineers.
Regarding the automated configuration of the PLC hardware, the study found
that it is not particularly beneficial for application engineers. Since the hardware
configuration generally does not require much manual configuration work, most
of the engineers prefer the clone-and-own technique when creating the hardware
configuration. The reasons for this coincide with the study conducted by Dubinsky
 67

et al. [6] in which it was shown that clone-and-own is a simple and quickly available
method for reuse. The configurator tool cannot compete with the clone-and-own
approach in these aspects in its current form. However, in cases where additional
device parametrization is required in the hardware configuration, the tool would be
more valuable.
Furthermore, the tool supports the use of a central repository for reusable field
devices as part of the hardware configuration, realizing many of the benefits of
systematic reuse discussed in Section 2.2.5, such as increased productivity and
reduced maintenance overhead. To encourage wider adoption of the tool among the
application engineers, it is important to promote these benefits and convince them
that the tool is effective and yields better results compared to previous methods.

7.1.2 RQ2
Regarding the answer to the second research question, it was seen that solving
the identified problems required the inclusion of multiple configuration tasks in
the tool. Although the wide coverage of automated configuration tasks assists the
application engineers effectively in multiple areas, it also comes with its own challenge
of maintaining the implemented functionalities during the rapid development cycles
of both Crane Core and TIA Portal. Streamlining the tool to only focus on the
most important configuration tasks, such as I/O tag configuration, would reduce the
maintenance workload. However, it would then lose the potential of becoming an
extensive product configurator as part of an automated production line. The question
then becomes whether it is worth pursuing the Software Product Line approach
further in hopes of large long-term benefits or settling with a simpler support tool.

7.2 Contributions and Implications

Variability management and software reuse have been researched in the field of
industrial automation, but practical approaches and tools are still largely missing
[53]. Especially holistic approaches regarding modularization and reuse of entire
interdisciplinary automation systems are lacking. As an exploratory study, this thesis
contributes to academic knowledge by presenting a tool-based approach to automated
configuration of a common PLC software platform, enabling better software reuse
and variability management in the field of industrial automation. Furthermore, the
thesis raises awareness of the importance of SPLE and how it can be efficiently
applied in the automation industry with the use of a common PLC software platform
and a product configurator tool. As a result, this study could be used as a basis for
future research on Software Product Line approaches in the industry.
The thesis also contributes to the science and engineering community as a
whole by introducing Design Science Research methodology as an approach for
systematic problem solving. The study demonstrates how to create a validated artifact
through iterative design, implementation and validation based on the regulative cycle
framework introduced by Wieringa [41]. Consequently, by demonstrating a successful
methodological approach, the thesis also encourages other researchers to apply DSR
 68

in their work and extend it.

Practitioners in the automation industry interested in expanding their knowledge
of SPLE and software reuse, as well as improving their development approaches
by applying generative programming, will also benefit from this thesis. Further-
more, the thesis provides valuable information about Siemens’ TIA Portal Openness
API to practitioners by demonstrating its feasibility and capabilities for generative
programming by highlighting its strengths and weaknesses. For these reasons, the
work inspires and assists practitioners in creating Openness applications and product
configurators to automate their engineering processes. Konecranes Oyj is the direct
beneficiary of this work, as it gains concrete value in terms of faster and cheaper
custom crane deliveries with the developed configurator tool. With a successful
deployment of the tool, similar product configurators could also be seen in other
businesses areas in the company.

7.3 Limitations
Although the tool was validated to some degree by the author, the findings do not
fully support the practicality and maintainability of the tool in crane application
development. Some problems could possibly come to light only after full adaptation
of the tool among end-users. Nevertheless, even if the tool fails to effectively
support application engineers or becomes deprecated at some point, overall the study
has extensively contributed to the existing knowledge base and provided valuable
information to practitioners in the field of industrial automation as discussed in
Section 7.2.
An additional limitation of the study is the fact that the feasibility of using crane
feature models, which describe the relationships of the features, as part of the tool was
not assessed in the study. As variability modelling is an essential part of successful
SPLE, it is certainly something that could be further researched as a part of the
tool. For example, a similar kind of toolchain to the one that Papakonstantinou and
Sierla presented in their study [2], in which control software product line assets were
generated based on feature models, could provide additional value to the configurator
tool.
One major limitation of the developed configurator tool is its dependence on
Crane Core and TIA Portal automation software platforms. The tool is built around
both entities, and although the design considers the change sensitivity of the Crane
Core platform, it still requires that the common development rules of the platform
are followed and the applications are built in a predefined way. Waste-to-Energy
applications are generally built differently compared to other applications, and they do
not fully follow the defined configuration guidelines. This means that the configurator
tool offers less benefit when configuring WtE applications as, for example, the I/O
configuration of the tool does not follow the practices used in WtE applications.
Moreover, the dependence on TIA Portal through the use of TIA Portal Openness
API complicates the migration of the tool to support another automation platform.
Additionally, the frequent development cycles of both TIA Portal and TIA Portal
Openness cause the risk of increased maintenance efforts in the future.
 69

7.4 Validity Threats

This section defines validity threats of this study based on the definition by Runeson
and Höst [43].

Construct Validity: The author did not have experience in crane application
development and most of the knowledge was possessed by the application engineers
and not shared extensively within the company. Moreover, the application engineers
had limited knowledge of TIA Portal Openness and the concept of a product config-
urator in SPLE. For these reasons, there were some gaps of knowledge between the
author and the application engineers. This leads to the risk that some concepts and
terms might have been understood differently during the focus group discussions
with application engineers. To counter this threat, the discussed constructs are first
defined in the meetings to form a collective understanding among the participants.

Internal Validity: Since the focus group discussions consisted of multiple persons
and no previous contact was made with most of them, there is a risk that many of
them were cautious in their talks and did not properly express their opinions. This
suggests that the data collected during the discussions may have been incomplete,
or some valuable information may not have been captured. To mitigate this risk,
private discussions were held with some of the application engineers in which detailed
questions were asked in a more casual setting.
Because generally the focus groups only consisted of a handful of application
engineers, the gathered data might also have been inconsistent or biased based on the
individual experiences of the engineers. For example, the application engineers might
have different opinions on what they regard the most time-consuming or challenging
tasks in crane application development. This risk was tried to mitigate by selecting
a variety of different application engineers with diverse backgrounds and years of
experience as participants to the discussions. By cross verifying and gathering data
from multiple sources, known as triangulation [54], the findings are more reliable
while also widening the overall understanding of the data.
Furthermore, there is a possibility that some of the data collected from artifacts,
such as engineering documents and crane application projects, was incomplete or
inaccurate. Moreover, essential information might also have been missing from the
artifacts. This risk was countered by returning to the application engineers and
checking for accuracy with their experiences. This validation technique is called
member checking [55].

External Validity: This study was conducted only at one company with their
proprietary common software platform. Therefore, the evaluation of the configurator
tool is specific to that company and the findings from it are not generalizable in the
field of industrial automation. Moreover, the generalization within the company, for
example, to other crane types, is also limited due to the utilization of the particular
platform and technologies. However, the study acts as a representative case for
researchers and practitioners to encourage further research and development on
 70

Software Product Line approaches in the automation industry. For example, the
study can be replicated in other domains with similar technologies or expanded within
the company. Additionally, researchers and practitioners interested in software reuse,
SPLE, or generative programming could extract parts from this study and expand
on them in their own work.

Reliability: As the author had previous knowledge of the common software platform
(Crane Core), C# and TIA Portal Openness API, it was a substantial benefit regarding
the development work of the tool. Other researchers with strong technical backgrounds
could easily replicate this study given a similar context. Application and platform
engineers were actively consulted during the work to mitigate subjective design
choices and to effectively drive the development of the tool towards the goals of the
stakeholders. Along with the use of triangulation and member checking, the study was
designed well with clear research questions and well-defined methodology to increase
reliability and ensure that the results are consistent, accurate, and reproducible.
 71

8 Conclusions
8.1 Summary
This study examined the automatic configuration of a common PLC software plat-
form for creating industrial crane applications in the context of Software Product
Line Engineering. First, in Chapter 2, software reuse and variability management
approaches are discussed and compared. The chapter also described the benefits
of Software Product Line Engineering and how the concept can be realized in soft-
ware development. It also covered the reasons why non-systematic software reuse
approaches are still widely used despite their well-known drawbacks.
Chapter 3 presented an industrial crane, its control system and connection to
software development and variability management. It also discussed the common
software platform that contributed a major part of the tool development. The
methodology of the thesis was covered in Chapter 4. The chapter introduced Design
Science Research methodology, which provided a systematic approach for the tool
design, development, and evaluation. It also described the data collection methods
and technologies used throughout the study.
In Chapter 5, the development process of the tool is described during the four
iterations in the context of the regulative cycle framework. The chapter gave insight
into the development process by highlighting some of the challenges, technical details,
and results. Chapter 6 revisited the research questions of the thesis and presented
the results regarding the finished tool implementation. Finally, Chapter 7 showed
how the findings fit the existing knowledge, how they contributed and what were the
limitations of the study. It also covered threats to the validity of the research and
how they were mitigated.

8.2 Concluding Remarks

In this thesis, it was shown that it is possible to implement an easy-to-use tool that
automatically configures parts of a common PLC software platform for generating an
application instance based on a crane specification. The iterative development of the
tool was successful as the requirements specified by the stakeholders were fulfilled.
The tool successfully addresses issues related to crane application development, such
as time-consuming and tedious manual configuration tasks, lack of harmonization
between the applications, and difficulties in efficiently utilizing reusable software
artifacts.
It was shown that these problems were solved by incorporating deliberately chosen
configuration tasks into the tool that would otherwise require considerable effort to
execute manually. In addition, the utilization of a central software asset repository
allows efficient reuse of software artifacts through the configurator tool. The tool was
designed in a way that it would be easy to extend and maintain its functionalities
with reasonable effort in the future.
Overall, the tool designed and implemented in this thesis provides an efficient and
extendable mechanism for automating the generation of part of the industrial crane
 72

applications in Software Product Line Engineering environment. Furthermore, the

study created momentum in building harmonized solutions and sustainable software
ecosystems in the automation industry. With further development and widespread
adoption of the tool among the application engineers, benefits such as reduced time
to market, improved software quality, and cost-effectiveness are undisputed. As crane
control software is becoming increasingly more complex due to the constant safety
and productivity improvements, tools and approaches that support efficient reuse
and variability management are crucial for maintaining competitiveness in the future.
In the next section, some ideas for future development are presented.

8.3 Future Work

First and foremost, it is recommended to promote and deploy the tool for end-users
and conduct a feasibility study to evaluate its benefits. Collecting feedback from
users can help identify areas of improvement in terms of usability and performance.
Additionally, further investigation into application development could serve as a
basis for automating a larger portion of the development process. For instance, as
discussed in Section 7.3, adding crane feature models could help realize the mass
customization of crane applications.
Another promising area of improvement is the automatic generation of high-level
application functionalities using the configurator. To implement this feature, a
deep understanding of crane applications is required to extract reusable software
components from various projects. Creating a central repository of these reusable
components and developing a mechanism for assembling the components into a
common platform would further realize the benefits of systematic software reuse.
In addition, integrating Konecranes’ sales configurator tool, which calculates sales
prices for cranes based on customer requirements, into the crane configurator tool is
another interesting future research topic. It could enable more automatic generation
of crane applications as both tools manage similar crane specifications. Furthermore,
investigating a possible connection between the sales configurator and feature models
as part of Crane Configurator is also worth looking into.
Siemens supports the creation of TIA Portal add-ins, which are tools and scripts
integrated into the TIA Portal automation software. Developing an add-in from
the tool could improve its usability, availability, and distribution, as it would be
directly integrated into the platform used by the application engineers. Some of the
functionality of the tool could also be extracted into separate, smaller add-ins to
further increase ease of use. This topic is connected to the larger question discussed
in 7.1.2 of whether to further pursue the current Software Product Line approach of
the tool or simplify the tool into smaller support tools.
 73

References
[1] R. Bashroush, M. Garba, R. Rabiser, I. Groher, and G. Botterweck, “Case tool
support for variability management in software product lines,” ACM Comput.
Surv., vol. 50, no. 1, 2017. [Online]. Available: https://doi.org/10.1145/3034827

[2] N. Papakonstantinou and S. Sierla, “Generating an object oriented iec 61131-3

software product line architecture from sysml,” in 2013 IEEE 18th Conference
on Emerging Technologies & Factory Automation (ETFA), 2013, pp. 1–8.
[Online]. Available: https://doi.org/10.1109/ETFA.2013.6648057

[3] J. Fischer, S. Bougouffa, A. Schlie, I. Schaefer, and B. Vogel-Heuser, “A

qualitative study of variability management of control software for industrial
automation systems,” in 2018 IEEE International Conference on Software
Maintenance and Evolution (ICSME), 2018, pp. 615–624. [Online]. Available:
https://doi.org/10.1109/ICSME.2018.00071

[4] “Programmable controllers - part 3: Programming languages,” International

Electrotechnical Commission, International Standard, 2013.

[5] A. Schlie, K. Rosiak, O. Urbaniak, I. Schaefer, and B. Vogel-Heuser,

“Analyzing variability in automation software with the variability analysis
toolkit,” in Proceedings of the 23rd International Systems and Software
Product Line Conference - Volume B, ser. SPLC ’19. New York, NY, USA:
Association for Computing Machinery, 2019, p. 191–198. [Online]. Available:
https://doi.org/10.1145/3307630.3342408

[6] Y. Dubinsky, J. Rubin, T. Berger, S. Duszynski, M. Becker, and K. Czarnecki,

“An exploratory study of cloning in industrial software product lines,” in 2013
17th European Conference on Software Maintenance and Reengineering, 2013,
pp. 25–34. [Online]. Available: https://doi.org/10.1109/CSMR.2013.13

[7] N. Lodewijks, “Clone-and-own: Analysis of an industrial automation

system,” Master’s thesis, University of Amsterdam, 2017. [Online]. Available:
https://scripties.uba.uva.nl/scriptie/645890

[8] S. Stanciulescu, S. Schulze, and A. Wasowski, “Forked and integrated variants

in an open-source firmware project,” in 2015 IEEE International Conference on
Software Maintenance and Evolution (ICSME), 2015, pp. 151–160. [Online].
Available: https://doi.org/10.1109/ICSM.2015.7332461

[9] D. Faust and C. Verhoef, “Software product line migration and deployment,”
Software: Practice and Experience, vol. 33, no. 10, pp. 933–955, 2003. [Online].
Available: https://doi.org/10.1002/spe.530

[10] T. Y. Sim, F. Li, and B. Vogel-Heuser, “Modules, version and

variability management in automation engineering of machine and plant
manufacturing,” in 2008 IEEE International Conference on Emerging
 74

Technologies and Factory Automation, 2008, pp. 46–49. [Online]. Available:

https://doi.org/10.1109/ETFA.2008.4638369

[11] P. Nauer and B. Randell, “Software engineering; report on a conference by the

nato science committee,” NATO Scientific Affairs Division, Brussels, Belgium,
Tech. Rep., 1968.

[12] C. W. Krueger, “Software reuse,” ACM Comput. Surv., vol. 24, no. 2, p.
131–183, 1992. [Online]. Available: https://doi.org/10.1145/130844.130856

[13] E. S. de Almeida, “Software reuse and product line engineering,” Handbook of

Software Engineering, pp. 321–348, 2019.

[14] L. Northrop, “Sei’s software product line tenets,” IEEE Software, vol. 19, no. 4,
pp. 32–40, 2002. [Online]. Available: https://doi.org/10.1109/MS.2002.1020285

[15] K. Pohl, G. Böckle, and F. J. v. d. Linden, Software Product Line Engineering:

Foundations, Principles and Techniques. Berlin, Heidelberg: Springer-Verlag,
2005.

[16] J. Klein, G. Chastek, S. Cohen, R. Kazman, and J. McGregor, “An early look
at defining variability requirements for system of systems platforms,” in 2012
Second IEEE International Workshop on Requirements Engineering for Systems,
Services, and Systems-of-Systems (RESS), 2012, pp. 30–33. [Online]. Available:
https://doi.org/10.1109/RES4.2012.6347693

[17] C. Krueger and P. Clements, “Systems and software product line engineering,”
Encyclopedia of Software Engineering, vol. 2, pp. 1–14, 2013.

[18] J. Rubin, K. Czarnecki, and M. Chechik, “Managing cloned variants: a framework

and experience,” in Proceedings of the 17th International Software Product Line
Conference, 2013, pp. 101–110.

[19] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, “Feature-oriented

domain analysis (foda) feasibility study,” Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, PA, Tech. Rep. CMU/SEI-90-TR-021,
1990. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?
AssetID=11231

[20] S. Apel and C. Kästner, “An overview of feature-oriented software development.”

J. Object Technol., vol. 8, no. 5, pp. 49–84, 2009.

[21] K. Schmid, R. Rabiser, and P. Grünbacher, “A comparison of decision modeling

approaches in product lines,” in Proceedings of the 5th Workshop on Variability
Modeling of Software-Intensive Systems, ser. VaMoS ’11. New York, NY, USA:
Association for Computing Machinery, 2011, p. 119–126. [Online]. Available:
https://doi.org/10.1145/1944892.1944907
 75

[22] J. Lee and S. Hwang, “Variability change management using the

orthogonal variability model-based traceability,” Wirel. Pers. Commun.,
vol. 89, no. 3, p. 729–745, aug 2016. [Online]. Available: https:
//doi.org/10.1007/s11277-016-3195-y
[23] J. Rubin and M. Chechik, “Combining related products into product lines,” in
Fundamental Approaches to Software Engineering, J. de Lara and A. Zisman,
Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, pp. 285–300.
[24] K. Yoshimura, F. Narisawa, K. Hashimoto, and T. Kikuno, “Fave: Factor
analysis based approach for detecting product line variability from change
history,” in Proceedings of the 2008 International Working Conference
on Mining Software Repositories, ser. MSR ’08. New York, NY, USA:
Association for Computing Machinery, 2008, p. 11–18. [Online]. Available:
https://doi.org/10.1145/1370750.1370753
[25] S. Thibault and C. Consel, “A framework for application generator design,”
ACM SIGSOFT Software Engineering Notes, vol. 22, no. 3, pp. 131–135, 1997.
[26] C. W. Krueger, “Biglever software gears and the 3-tiered spl methodology,”
in Companion to the 22nd ACM SIGPLAN Conference on Object-Oriented
Programming Systems and Applications Companion, ser. OOPSLA ’07. New
York, NY, USA: Association for Computing Machinery, 2007, p. 844–845.
[Online]. Available: https://doi.org/10.1145/1297846.1297918
[27] D. Beuche, “Modeling and building software product lines with pure::variants,”
in 2008 12th International Software Product Line Conference, 2008, pp. 358–358.
[Online]. Available: https://doi.org/10.1109/SPLC.2008.53
[28] S. Apel, D. Batory, C. Kästner, and G. Saake, Feature-oriented software product
lines. Springer, 2016.
[29] M. L. Fisher et al., “What is the right supply chain for your product?” Harvard
business review, vol. 75, pp. 105–117, 1997.
[30] R. Ferguson, “Decisions for sustaining a software product line,” Carnegie
Mellon University, Software Engineering Institute’s Insights (blog), Oct 2018,
online; accessed: 31-March-2023. [Online]. Available: https://insights.sei.cmu.
edu/blog/decisions-for-sustaining-a-software-product-line/
[31] G. Bockle, P. Clements, J. D. McGregor, D. Muthig, and K. Schmid, “Calcu-
lating roi for software product lines,” IEEE software, vol. 21, no. 3, pp. 23–31,
2004.
[32] L. Chen and M. A. Babar, “Variability management in software product lines:
an investigation of contemporary industrial challenges,” in Software Product
Lines: Going Beyond: 14th International Conference, SPLC 2010, Jeju Island,
South Korea, September 13-17, 2010. Proceedings 14. Springer, 2010, pp.
166–180.
 76

[33] C. M. A. of America, “Overhead cranes,” 2023, online; accessed 17-March-2023.

[Online]. Available: https://www.mhi.org/fundamentals/cranes

[34] Konecranes Oyj, “Material bank,” 2023, unpublished internal company database.

[35] H. S. Bedi and K. Arora, “Monitoring and controlling of industrial crane using
programmable logic controllers,” Indonesian Journal of Electrical Engineering
and Informatics (IJEEI), vol. 3, no. 2, pp. 115–118, 2015.

[36] W. Bolton, Programmable Logic Controllers 4th Edition. Oxford: Elsevier

Newnes, 2006.

[37] F. F. Reijnen, T. R. Erens, J. M. van de Mortel-Fronczak, and J. E. Rooda,

“Supervisory control synthesis for safety plcs,” IFAC-PapersOnLine, vol. 53,
no. 4, pp. 151–158, 2020, 15th IFAC Workshop on Discrete Event Systems
WODES 2020 — Rio de Janeiro, Brazil, 11-13 November 2020. [Online].
Available: https://doi.org/10.1016/j.ifacol.2021.04.015

[38] “Functional safety of electrical, electronic and programmable electronic (e/e/pe)

safety-related systems,” International Electrotechnical Commission, Interna-
tional Standard, 2010.

[39] Konecranes Oyj, “Software architecture document crane core,” 2023, unpublished
internal company document.

[40] ——, “Feature description document crane core,” 2023, unpublished internal
company document.

[41] R. Wieringa, “Design science as nested problem solving,” in Proceedings

of the 4th International Conference on Design Science Research in
Information Systems and Technology, ser. DESRIST ’09. New York, NY,
USA: Association for Computing Machinery, 2009. [Online]. Available:
https://doi.org/10.1145/1555619.1555630

[42] A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design science in information

systems research,” Management Information Systems Quarterly, vol. 28, no. 1,
p. 6, 2008.

[43] P. Runeson and M. Höst, “Guidelines for conducting and reporting case study
research in software engineering,” Empirical Software Engineering, vol. 14, pp.
131–164, 2009.

[44] K. R. Larsen, R. Lukyanenko, R. M. Mueller, V. C. Storey, D. VanderMeer,

J. Parsons, and D. S. Hovorka, “Validity in design science research,” in Designing
for Digital Transformation. Co-Creating Services with Citizens and Industry:
15th International Conference on Design Science Research in Information Sys-
tems and Technology, DESRIST 2020, Kristiansand, Norway, December 2–4,
2020, Proceedings 15. Springer, 2020, pp. 272–282.
 77

[45] R. L. Baskerville, M. Kaul, and V. C. Storey, “Genres of inquiry in design-science

research,” Mis Quarterly, vol. 39, no. 3, pp. 541–564, 2015.

[46] Siemens, “Tia portal openness: Introduction and demo ap-

plication,” 2023, online; accessed 17-March-2023. [Online].
Available: https://support.industry.siemens.com/cs/document/108716692/
tia-portal-openness-introduction-and-demo-application?dti=0&lc=en-FI

[47] ——, “Simatic tia portal openness: Api for automation of engi-
neering workflows,” 2023, online; accessed 6-April-2023. [Online].
Available: https://support.industry.siemens.com/cs/document/109815199/
simatic-tia-portal-openness-api-for-automation-of-engineering-workflows?dti=
0&lc=en-GB

[48] Microsoft, “Overview of .net framework,” 2023, online; accessed 25-May-2023.

[Online]. Available: https://learn.microsoft.com/en-us/dotnet/framework/
get-started/overview

[49] A. Hejlsberg, M. Torgersen, S. Wiltamuth, and P. Golde, The C# programming

language. Pearson Education, 2008.

[50] M. Raudaskoski, “Generative programming in industrial crane applications,”

Master’s thesis, Tampere University, 2021. [Online]. Available: https:
//urn.fi/URN:NBN:fi:tuni-202102112053

[51] H. Pham, Software reliability. Springer Science & Business Media, 2000.

[52] R. C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure

and Design. Prentice Hall, 2018.

[53] C. R. Maga and N. Jazdi, “Interdisciplinary modularization in product

line engineering: A case study,” in Proceedings of 2012 IEEE International
Conference on Automation, Quality and Testing, Robotics, 2012, pp. 179–184.
[Online]. Available: https://doi.org/10.1109/AQTR.2012.6237699

[54] U. Flick, “Triangulation in qualitative research,” A companion to qualitative

research, vol. 3, pp. 178–183, 2004.

[55] A. Candela, “Exploring the function of member checking,” The Qualitative

Report, 03 2019. [Online]. Available: https://doi.org/10.46743/2160-3715/2019.
3726