46

Portal Openness point of view. To give flexibility in terms of configuring the field
devices, the tool would have an option to import field devices in all four ways.
The hardware configuration was separated into two different parts: general field
devices and devices which were directly connected to the machineries (e.g., bridge,
trolley, and hoist). This was to allow further configuration of machinery parameters
defined in PLC data blocks based on the configured field devices. The parameters
include, for example, Profinet I/O start addresses and device type identifiers for
motor controllers and position measurement devices. Load measurement devices also
have similar parameters but configuration support for them was left out as they are
only relevant for hoist machineries. Figure 21 shows the implemented tool used for
configuring devices connected to machineries. General field device configuration view,
shown in Figure 22, is similar but without the additional machinery specific view.

Figure 21: Machinery and device configuration views in Crane Configurator. The
views are from an updated version of the tool, which was developed in Iteration 3.

The machinery configuration would include creating new machinery software

template blocks and new instance calls for the blocks if the defined configuration
includes more machineries than there are already preconfigured in the Crane Core
platform. These blocks consist of machinery and application specific I/O blocks that
connect symbolic I/O tag names to correct variable addresses. Furthermore, data
blocks and program blocks that manage, for example, machinery inputs and outputs
are also created. All the created blocks are modular and only specific parts related
 47

to machinery numbers are modified. Some of the parameters would also be set in
PLC data blocks based on the defined configuration. Those parameters are mostly
related to the devices connected to the machineries and different smart features.

5.1.3 Design Validation

Design validation was mostly done by the author as the application engineers were
more interested in seeing the tool in action instead of being involved in the develop-
ment process. The application engineers were more experienced in developing PLC
software than traditional software, therefore, there was also no reason to validate
specific software design choices of the tool by them as they did not have much
knowledge in that area. Additionally, the application programming interface in
use, TIA Openness, was not well known among the engineers, which also strongly
impacted the decision for the chosen validation process. During this phase Wieringa’s
validation questions were considered.

Question 1 (Internal Validity): Would this design, implemented in this problem

context, satisfy the criteria identified in the problem investigation?

The features implemented in Iteration 1 would only partially satisfy the criteria
identified in the problem investigation phase as not all crane configuration tasks were
included in the design. The crane configuration process would still be time-consuming
and tedious even with the help of the tool. Moreover, the setup and usability of the
tool would not be at the level required by the application engineers. The implemented
features related to hardware and machinery configuration would save time and effort
in the configuration process, but it would not be clear how applicable they would be
in practice as the setup and usability were not at the required level. In addition, the
achieved harmonization between application projects would still be minimal as the
implementation did not include many configuration tasks that would vary in design
between the engineers.

Question 2 (Trade-offs): How would slightly different designs, implemented in this

context, satisfy the criteria?

Incorporation of additional automated configuration tasks would have satisfied the

criteria identified in the problem investigation phase, apart from the last criteria.
However, this was not possible as it was unclear at the time what these additional
configuration tasks would be and what tasks would be the most important ones. The
focus of Iteration 1 was to develop a working prototype so that it would then be
easier for the application engineers to devise the rest of the configuration tasks and
tool requirements. Therefore, it was decided to only include the already known basic
crane configuration tasks in the tool in Iteration 1.

Question 3 (External Validity): Would this design, implemented in slightly different

contexts, also satisfy the criteria?
 48

The configurator tool is highly coupled with Crane Core software platform. For this
reason, the automated configuration tasks would not work, for example, with other
types of software platforms without heavily modifying the back-end functionalities
of the tool. However, it would be possible to only utilize the user interface and crane
configuration data models in a different software platform as they are not dependent
on the platform. Furthermore, the crane configuration data models could be utilized
in storing and visualizing different crane application configurations, for example, in
product life cycle management.

5.1.4 Implementation
When it comes to importing field devices, it was quickly noticed that the best option
would be to import them from a global library. Library items are created in TIA
Portal project and then drag-and-dropped to a global library or a project library.
When importing devices from the Siemens’ hardware catalogue or GSD/GSDML
files, the device is created without any I/O modules. This was not the case with
library items. The I/O modules are necessary for the use of the device. This would
mean that the modules would have to be configured inside the tool, which would
become unmanageable with a considerable number of different I/O modules fitting
different devices. The tool would essentially have to become an alternative version
of TIA Portal’s hardware configuration view in order to manage that efficiently and
that would obviously lose the purpose of the tool.
With the AML files, the problem is not with the I/O modules as they will be
included when importing the hardware configuration. However, challenges come
in terms of the large extent of the import. For example, if the file includes a PLC
device, all software in the already configured PLC device is overwritten. Moreover,
after the AML file is imported, TIA Portal requires software compilation before it
can continue with other configuration tasks.
With global libraries, devices can be manually preconfigured with all the necessary
I/O modules. As most of the crane applications use similar devices, it would not
require much effort. This method also allows to have a central repository for the
preconfigured field devices, which in turn allows better reusability and increases
harmonization between the applications. Library devices can be imported from the
library, automatically configured with the specified parameters, and connected to
Profinet and I/O controller.
The problem of configuring field devices was the fact that all the devices had
different software structures in TIA Portal Openness. This made accessing the
parameter information challenging as there was no one solution to, for example,
set I/O address of the device. Device names, Profinet IP addresses, and network
connections were possible to configure by looping over different device structures
and modules to find correct access points. I/O address configuration had to be hard
coded for different devices. It was then decided to limit I/O address configuration to
only field devices which were directly connected to machineries. These devices were
motor controllers and position measurement devices. Load measurement devices
 49

were left out for the reasons discussed in Section 5.1.2.

The resulting hardware configuration, which the tool generated, can be seen in
Figure 22. The generated hardware configuration includes some example field devices
which could be in an actual crane application.

Figure 22: An overview of the programmatically generated hardware configuration.

a) A configurator user interface with a hardware configuration page. The interface
is from an updated version of the tool, which was developed in Iteration 3. b) TIA
Portal hardware configuration view with all of the generated field devices.

Machinery and parameter configuration tasks were more straightforward and

easier compared to hardware configuration. This was mostly because TIA Openness
allowed an easier access and control over software programs and data blocks compared
to hardware devices. There were also clear instructions in a platform configuration
manual on what blocks to add or modify when creating new machineries. Although
adding or removing machineries in core software is relatively fast to do manually,
automating this configuration task prevents any human errors as those are quite
likely in a process that includes many simple repetitive tasks.
In the software, the crane configuration tasks were separated into three clearly
defined components mentioned in the solution design section: hardware, machineries,
and parameters. Although there was some overlap in these components, for example,
some of the hardware parameters are also defined in PLC parameters and some of the
field devices (e.g., motor controllers and position measurement devices) are coupled
with certain machineries. Moreover, some of the parameters are directly connected
to the machineries and others are, for example, to power supply and general crane
information. The separation of these three components is clearer in the point of view
of TIA Portal and how the configuration tasks can be implemented with TIA Portal
Openness.

5.1.5 Evaluation
The evaluation of this iteration was conducted through a demonstration session of the
tool, which was attended by selected application and platform engineers. The idea
 50

was to demonstrate the features implemented in the iteration and to get feedback
from the attendees. In addition, some predefined questions were asked from the
application engineers about the development processes to get insight into their work
and software reuse approaches as well as to identify improvement areas. Overall,
the feedback on the tool was positive and constructive. However, there were some
uncertainties regarding the practicality and effectiveness of the tool. The session
was also helpful in understanding the role and challenges of application development
in different industries. Furthermore, some discussion and planning were conducted
about the direction of the tool so that it could effectively address the identified
challenges.
In the session, the following knowledge question was asked: "Which component
of the configuration process is the most time-consuming and tedious?". During the
discussion following the question, it was identified that I/O tag configuration is one
of the most time-consuming tasks for the application engineers. The feedback from
the session was directly transferred as an input to the start of Iteration 2.

5.2 Iteration 2: I/O Tag Configuration

Iteration 2 focused on the addition of I/O tag and parameter configuration. Based on
the discussion with the application engineers in the previous iteration it was found
that I/O tag configuration was one of the most time-consuming and repetitive tasks.
In the first iteration, only empty I/O blocks were created for new machinery objects.
However, in this iteration the goal was to configure the I/O blocks with correct I/O
tags, which are connected to the corresponding variable addresses in PLC hardware
interfaces.
During the discussion with the application engineers, it also became clear that
I/O tag configuration could be the main feature of the tool in which most of the
development effort is focused. A secondary goal for this iteration was the ability to set
PLC parameters from predefined parameter files. This need came from application
projects in which it is not possible to set parameters through the web user interface
of the crane. With automatic parameter configuration, the time to set correct
parameters in the PLC software decreases as most parameters are then loaded either
from templates or similar projects. Iteration 2 included much less planned work
compared to Iteration 1; therefore, the length of the iteration was only two weeks.

5.2.1 Problem Investigation

In this phase, the feedback from Iteration 1 was analyzed. No major problems or
improvements to existing features were gathered from the feedback. As already real-
ized during Iteration 1, configuring and creating new machinery blocks automatically
does not usually save much time as it is quite common to only have either three or
four machineries in industrial cranes. Because the core platform already has four
machinery instances preconfigured, it is then relatively fast to remove the excess
machinery instance manually from the software. But in some special cases with
more than four machineries, the automated machinery configuration could become
 51

a time-saving component. As already mentioned, the I/O tag configuration task

is much more time-consuming for the application engineers as it is always project
specific with hundreds of different tags that need to be connected to the right PLC
addresses.
Parameter configuration is also a major challenge for crane projects with no IPC
that would support the crane web user interface. Configuring the crane parameters
in the PLC software in multiple different data blocks is much more time-consuming
compared to using the web user interface as in most of the projects. The crane web
user interface supports setting the parameter values from files; therefore, similar
functionality would be of much benefit in cases where it is not possible to use the
web user interface. Finding specific parameters and setting their values is much
easier in the web user interface as it does not require knowledge of the PLC software
architecture.
Additionally, it was found that it would be useful to see detailed information about
the automated configuration process after it was done. This would help application
engineers to confirm that the tool had executed all the tasks that were planned and
that there are no mistakes in the finished configuration.

5.2.2 Solution Design

Based on the feedback gathered from Iteration 1, the I/O tag configuration part of
the tool would include importing the I/O tags from an Excel file to the TIA Portal
project and then connecting the tags to correct PLC variables in the right I/O blocks.
To know which tags need to be linked to which variables in PLC hardware interfaces,
a separate tag connection Excel file would be used to relay that information. Because
the tag names are different in every project, it would not be effective to hard code
all the connections.
The I/O symbolic tag names follow naming rules which can be used to create
naming patterns, which are then linked to specific PLC variables. As there are
slightly different practices on the naming depending on the people who are doing
the electrical designs for the cranes, it should also be possible to provide multiple
patterns corresponding to one PLC address. These patterns would be included in the
tag connection Excel file with their corresponding variable addresses. The tool would
need to go through all the imported tags and find the defined patterns. After all the
patterns are found, the corresponding tags would be added to the right I/O blocks
and linked to the variables defined in the Excel file. Figure 23 shows an overview of
the designed I/O configuration in the tool.
In parameter configuration, the tool would go through all the parameters in a folder
specified by the user and assign the values defined in the files to the corresponding
parameter PLC addresses. The tool would show all the parameters which were not
able to be set to help in troubleshooting and finalizing parameter values.

5.2.3 Design Validation

In this phase Wieringa’s validation questions were again considered. The third
question regarding external validity was discarded since the answer is the same as in
 52

Figure 23: An overview of the I/O configuration in Crane Configurator.

Iteration 1.

Question 1 (Internal Validity): Would this design, implemented in this problem

context, satisfy the criteria identified in the problem investigation?

The features related to I/O tag and parameter configuration in Iteration 2 would
satisfy the criteria identified in the Iteration 2 problem investigation. Although not
all criteria would be satisfied from the previous problem investigation in Iteration 1
as library feature configuration is not incorporated into the tool. This configuration
task was one of the predefined requirements for the tool. Because of time constraints
it was left out as it is not a major task that the application engineers would be
interested in.

Question 2 (Trade-offs): How would slightly different designs, implemented in this

context, satisfy the criteria?

I/O tag configuration without a separate tag connection Excel file would have also
satisfied the criteria. In that case the tags would have been more or less hard coded
meaning that there is less flexibility on the tag naming. The effectiveness of that
approach would highly depend on the types of application projects and their tag
naming. Additionally, parameter configuration with predefined parameter templates
would have also satisfied the criteria defined in the problem investigation phase.
However, this design would also be much less flexible in terms of changes as the
templates would need to be updated every time a new Crane Core version with
parameter changes is released. The chosen design gives more flexibility in terms of
the used parameter values as it does not have hard coded parameter templates, but
it also leaves some responsibility for the user to find suitable parameter sets. Since
flexibility and maintainability are important aspects of the tool in order for the tool
to bring value to the application engineers in the long term, these mentioned designs
were discarded.
 53

5.2.4 Implementation
There were not many architectural changes in the software between the first and
second iteration as the base foundation for the software was already established in
Iteration 1. The new features incorporated in Iteration 2 were mostly built on top of
the existing software structures. The I/O tag configuration was added as part of the
existing machinery configuration component. Although not all configured tags are
connected to the machineries, the implementation of I/O tag configuration is still
similar to other configuration tasks in the machinery configuration component. This
way it was possible to maintain the three main components constructed in Iteration
1.
A part of the I/O tag connections which the tool generated are presented in
Figure 24. As can be seen from the figure, the generated connections are quite
simple, but a whole crane application project can include hundreds of tags, which
need to be connected to the right PLC addresses. Even though it is not feasible to
programmatically connect all of the tags because of the variation in the applications
and tag naming, successfully connecting the main tags (50-100) already reduces the
workload of application engineers significantly.

Figure 24: Part of the programmatically generated I/O tag connections in a function
block written in FBD programming language. The input tags with I/O addresses on
top of them are connected to variables in a hardware interface.
 54

The extended parameter configuration feature was added as part of the existing
parameter configuration component. The implementation was quite straightforward
as the parameter files included PLC addresses for the parameter values that could be
directly used for setting the values in the right PLC data blocks. However, because
it first required finding the right data blocks and as TIA Openness does not provide
an easy method for that, the blocks needed to be found by recursive search through
all the PLC blocks. Moreover, some addresses that referred to parameters in arrays
needed to be slightly modified as those addresses did not directly work for setting
the parameter values.
Additionally, descriptive information about the configuration process and the
results were added for the tool in the form of a log file that is generated after the
process. The file contains detailed steps of the configuration phases and shows, for
example, what field devices and I/O tags were configured and which parameters
were not able to be set. The implementation phase included also small bug fixes and
improvements, which enhanced software readability and maintainability.

5.2.5 Evaluation
The evaluation was again conducted through a demonstration session of the tool. The
feedback from the application engineers was positive and they were satisfied with the
results, especially the I/O tag configuration part. It was confirmed that the presented
solution for configuring I/O tags would significantly reduce the effort required to
configure the tags. More information about crane application development was also
able to be gathered, for example, related to hardware configuration and general
development practices. The information helped in understanding the potential place
of the tool in application development and how it would be the most effective in
gaining value.
As most of the key features were included in the tool at the end of this iteration,
it was important to focus on User Experience (UX). Based on this, the following
knowledge question was asked: "How user-friendly and easy-to-use is the tool?". As
the user interface had become fairly crowded with the addition of new features, it
was suggested to transfer to a software wizard or a setup assistant approach in which
the user interface guides the user through a sequence of steps.

5.3 Iteration 3: Configuration Wizard

Iteration 3 added a stepwise wizard user interface to the tool while also improving
the parameter configuration component with the addition of CRC calculations. As
with the previous iteration, the length of Iteration 3 was also two weeks.

5.3.1 Problem Investigation

During the evaluation of Iteration 2, it became apparent that the user interface could
be improved to allow better usability. It contained lots of separate text fields and
buttons, which made it crowded and incoherent. It would be hard for application
engineers to know what fields are necessary and what are the consequences of them.
 55

It was suggested to transfer to a software wizard approach in which each of the

configuration data collection phases were in their own windows and the tool guides
through them sequentially.
Another focus in this iteration was the addition of CRC calculations. Because the
tool supported setting PLC parameter values from external files and from the crane
specification, it would also need to recalculate the CRC values as otherwise it would
result in errors. While this feature was necessary for valid parameter configuration, it
would also be useful for the application engineers when they are facing issues caused
by incorrect initial CRC values in PLC data blocks. Simply recalculating all the
CRC values for each of the parameter sets would fix these errors.

5.3.2 Solution Design

The new stepwise wizard UI was designed to streamline the process of inputting
crane configuration data. Even though there was no specific order in which the
configuration data needed to be filled, the new design would simplify the process
and make the UI look more professional. The new approach would also make it
easier to extend the tool with new configuration tasks in the future without changing
the whole user interface layout. Additionally, it would leave more room in the user
interface for operating instructions and notes for the user as the configuration data
collection is separated into individual windows. This was an important design change
in terms of better usability. As already discussed, it is essential that the tool is easy
to use and learn, otherwise, it would discourage application engineers from using the
tool and do the configuration manually as before.
The addition of CRC calculations was designed to be part of the parameter
configuration process. The complete process is visualized in Figure 25. CRC
calculations would require parameter PLC addresses from external files to get access
to the parameter values in the PLC. This would be a minor limitation as a successful
CRC configuration would be dependent on up-to-date parameter files. An important
aspect of the CRC and parameter configuration design was the detailed information
about the results in a log file. This would allow application engineers to check what
was configured and if there were any errors.

5.3.3 Design Validation

As in the previous iterations, Wieringa’s validation questions were considered. The
third question was not answered since the answer is the same as in Iteration 1.

Question 1 (Internal Validity): Would this design, implemented in this problem

context, satisfy the criteria identified in the problem investigation?

The new user interface and the addition of CRC calculations satisfy the criteria
discussed in Section 5.3.1. Although some elements of UI design can be subjective,
most of the design decisions in the new UI have clear measurable value in terms of
usability and clarity that address the identified issues.
 56

Figure 25: An overview of the parameter configuration process.

Question 2 (Trade-offs): How would slightly different designs, implemented in this

context, satisfy the criteria?

User interface in which different input fields related to different configuration tasks
are separated clearly into their own clear sections would have satisfied the criteria.
However, it would have required more effort and UX design to successfully achieve
that compared to a stepwise wizard approach.
CRC calculations could have been implemented independently from the parameter
files while still satisfying the criteria, but it would have required the use of some other
technology as it was not possible to access the right parameters without knowing the
PLC addresses in TIA Openness. By iterating through the parameter values in the
data block with some other approach, it could have been possible to then calculate
the CRC value. The CRC calculation also requires a parameter set identifier value,
which is not located in the same data block. Therefore, it was found easier to use
the parameter files to get the PLC addresses and the identifier value. The effort
to implement the CRC calculation feature without the parameter files would have
greatly exceeded the downside of having this dependency.
 57

5.3.4 Implementation
The transition from the old user interface to the new wizard approach was relatively
easy as the underlying structures in the code did not require changing. Besides moving
all the text fields and buttons to separate views, data content checks were added
when the user moves to the next window. Based on the inputted data, some of the
configuration options are also now disabled from the user. For example, if parameter
files are not given, it is not possible to enable parameter or CRC configuration options.
Part of the updated user interface can be seen in Figure 26 in contrast to the old
one. The whole user interface is presented in Section 6.1.5.

Figure 26: a) The old user interface used in the first and second iterations. b) The
updated user interface developed in Iteration 3.

Similarly to the parameter value configuration, CRC configuration uses parameter

PLC addresses from the parameter files to get access to the parameter value fields in
the data blocks. The CRC values are calculated based on the parameter values in
the parameter set. Depending on whether the user wants to update the CRC values
or just check them, the tool then either sets the calculated CRC value or compares
it to the existing value. Because there are differences between the data types and
formats used in the PLC software and tool software implemented in C#, some data
type conversions were required. For example, in the PLC software, CRC values are
in Word data type and presented in hexadecimal format while in the parameter
files the CRC values are in decimals. The implementation includes guard checks to
verify that the data in the parameter files is valid. Furthermore, if there were any
problematic cases or errors in the configuration, those would be presented in the log
file.
The CRC calculation algorithm was implemented based on a previous Java
implementation in the company and it was constructed as a separate library project
to allow better reusability. In addition, unit tests were implemented for the calculation
 58

to verify its functionality.

5.3.5 Evaluation
In the conducted demonstration session, the overall feedback was again positive.
Unfortunately, not as many application and platform engineers managed to attend
the session but the ones who did were actively participating in the discussion. Based
on the feedback and discussions, it was agreed that the new UI was an improvement
over the old one in terms of better UX design. Minor improvements to the UI were
suggested, but otherwise the session was more focused on describing and showing the
functionality of the tool. To give basis for a new iteration, the following knowledge
question was asked: "To what extent is the tool ready for deployment?"

5.4 Iteration 4: Validation

Iteration 4 focused on small bug fixes, polishing, and validation. It was the last
iteration; thus, the goal of it was to prepare and validate the tool for deployment.
Because not much software development was required anymore, it was also the
shortest iteration.

5.4.1 Problem Investigation

Minor problems with the new user interface were identified along with general bugs
within the tool. Most importantly, the tool was missing proper final validation,
which is an essential process before deploying any kind of software artifact to ensure
its reliability and requirement compliance. Although some testing and validation
were done already in the previous iterations, it was important to verify that all
the functionalities work correctly together with the newest changes. Validation is a
process of checking that the artifact design satisfies its intended use, i.e., it meets
the user’s requirements. In short, Pham [51] defines a validation process as "ensuring
that the software is executing the task correctly".

5.4.2 Solution Design

The idea of the validation procedure was to mimic the process of configuring an
actual crane application to a customer, starting from an electrical documentation of
the crane and ending in an initial application configuration. Based on the provided
crane specification, the objective was to then use the tool to configure field devices,
machineries, and PLC parameters. Validation process was designed as an internal
validation to ensure that all of the requirement specifications are met. It was assumed
that these requirements were correctly understood during the iterations, hence, no
further external validation was needed. While exercising all of the features of tool,
monitoring would be done to verify that all of the goals are met without any gaps or
bugs. If any abnormalities were found, they would be then analyzed and fixed before
releasing the tool for application engineers.
 59

5.4.3 Design Validation

Wieringa’s validation questions were again considered.

Question 1 (Internal Validity): Would this design, implemented in this problem

context, satisfy the criteria identified in the problem investigation?

The designed validation procedure addresses the identified gap in the evaluation of
the software reliability and requirement compliance. In addition, the designed UI
improvements and bug fixes handle the minor problems identified in the problem
investigation.

Question 2 (Trade-offs): How would slightly different designs, implemented in this

context, satisfy the criteria?

Instead of testing the high-level functionalities using a real crane application specifi-
cation, for example, a combination of extensive white-box testing and error-handling
validation would have also satisfied the criteria.

Question 3 (External Validity): Would this design, implemented in slightly different

contexts, also satisfy the criteria?

A similar validation procedure would also be applicable in other types of software

applications that require validation to ensure that requirement specifications are met,
and the application fulfills its intended purpose.

5.4.4 Implementation
The implementation of the validation procedure followed accurately the designed
plan. The tool was first used for specifying the crane configuration based on the
customer requirements defined in the electrical documentation and I/O tag lists.
After that, the automatic crane application configuration was started, and the process
was monitored carefully for any bugs. When the configuration was finished, the
resulting log file was checked to verify that the process was successful. The iteration
also focused on some polishing of the user interface in addition to the bug fixes based
on the evaluation of the previous iteration.

5.4.5 Evaluation
The validation procedure was implemented successfully. The tool was able to
effectively configure Crane Core platform in terms of field devices, I/O tag connections
and PLC parameters. All the requirement specifications were met. The tool was
simple and easy-to-use, although some learning is required to understand the basic
functionalities. No major bugs were found during the procedure. However, some
minor UI related bugs were identified, which were documented so that they can be
fixed before the deployment of the tool.
 60

6 Results
This chapter presents the finished configurator tool, known as Crane Configurator,
and the answers to the research questions. First, a general overview of the tool is
given after which the implementation and design are discussed. Lastly, the user
interface is presented, followed by the answers to the research questions.

6.1 Crane Configurator

Crane Configurator is a software tool designed to automatically configure a common
control software platform known as Crane Core. The tool utilizes crane information,
such as field devices and machinery specifications provided by an application engineer,
to generate an initial crane application instance. Its objective is to reduce the initial
engineering effort required for creating custom crane applications. In a larger scope,
the tool is designed to be a part of the organizational SPLE workflow for creating
crane applications. It utilizes the known variation points and commonalities defined
in the platform for configuring crane applications.

6.1.1 Features
The main features of the configurator tool:

• Hardware configuration: The tool creates specified field devices and configures
their parameters and network connections.

• Addition/removal of machinery objects: Based on the specified number of

machineries, the tool adds or removes machinery objects in the platform and
configures them appropriately.

• I/O tag configuration: Given a list of crane specific I/O tags, the tool connects
the tags based on predefined rules to correct PLC variables in the platform
hardware interfaces.

• Parameter configuration: The tool is able to assign values to PLC parameters

in the platform based on the crane specification or given parameter files.

• CRC calculations and checks: Based on the failsafe parameter values, the tool
is able to recalculate CRC values associated to the parameter sets or check
their correctness.

• Save and load crane configurations: Successful configurations can be saved and
then later loaded to save time.

6.1.2 Workflow
The use of the tool can be described with the following general workflow: