Concept Development of a User Interface
for Remote Tank Monitoring of IBC Tanks
Master’s thesis in Industrial Design Engineering
ANDREA HANSSON
TOM KRZNAR
DEPARTMENT OF INDUSTRIAL AND MATERIALS SCIENCE
DIVISION OF DESIGN AND HUMAN FACTORS
CHALMERS UNIVERSITY OF TECHNOLOGY
Gothenburg, Sweden 2021
www.chalmers.se

Master’s thesis 2021
Concept Development of a User Interface
for Remote Tank Monitoring of IBC Tanks
ANDREA HANSSON
TOM KRZNAR
Department of Industrial and Materials Science
Division of Design and Human Factors
Chalmers University of Technology
Gothenburg, Sweden 2021
Concept Development of a User Interface for Remote Tank Monitoring of IBC Tanks
ANDREA HANSSON
TOM KRZNAR
© ANDREA HANSSON & TOM KRZNAR, 2021.
Supervisors: Patricia Borghede, Emerson Automation Solutions
Examiner: Andreas Dagman, Department of Industrial and Materials Science
Master’s Thesis 2021
Department of Industrial and Materials Science
Division Design and Human Factors
Chalmers University of Technology
SE-412 96 Gothenburg
Telephone +46 31 772 1000
Cover: Visualisation of a conceptual remote IBC tank monitoring system.
Printed by Chalmers Digitaltryck
Gothenburg, Sweden 2021
iv
Concept Development of a User Interface for Remote Tank Monitoring of IBC Tanks
ANDREA HANSSON
TOM KRZNAR
Department of Industrial and Materials Science
Chalmers University of Technology
Abstract
The process industry is being shifted through emerging technological advancements
and digitization. This created an opportunity to develop a new remote tank mon-
itoring and inventory management system for mobile plastic tanks, also known as
IBC tanks. The main focus of this project was to identify and define user needs and
requirements for developing a remote monitoring system for mobile plastic tanks.
The user needs would be presented through the development of a theoretical frame-
work for developing a digital monitoring system and a conceptual solution focusing
on user experience and human factors.
The user needs were identified in the early stages of the project through interview
studies, a workshop, benchmarking and opportunity identification. When the user
needs and requirements were identified, they were analysed, redefined and mapped
out through the analysis methodology and systems theory. The concept genera-
tion resulted in a configuration of hardware and software working together to create
functionalities that filled the user needs. The hardware unit includes a set of elec-
tronic and user interface components that serves the purpose of feeding data to the
software while keeping the unit complexity low. The software concept was a user
interface design, built to facilitate remote tank monitoring, easy pairing, inventory
analysis, inventory management and inventory security.
A digital prototype was made in the delivery phase of the project which resulted in a
series of visualisations presenting the theoretical framework for developing a digital
remote tank monitoring system, which was identified in the development phase.
Keywords: Industrial design engineering, user experience, systems theory, digital
prototyping, remote tank monitoring, user research, UX/UI.
v

Acknowledgements
First and foremost, we are grateful to our supervisor Andreas Dagman for his guid-
ance. His encouragements, knowledge and past experience from the relevant field all
contributed to us being able to carry this project through until the end. We would
also like to express our gratitude towards the case company and our supervisor Pa-
tricia Borghede for for supporting our endeavour with guidance and organisation.
We would also like to thank Emerson and it’s employees who were involved in this
project and provided us with technical support. Finally, we would like to express
our gratitude towards all of our university colleagues who have often been a source
of vital advice and all of the participants who were part of our research. Without
you, it would have been impossible to complete our studies.
Tom Krznar and Andrea Hansson, Gothenburg, June 2021
vii

Contents
List of Figures xi
List of Tables xiii
List of Abbreviations xv
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Outline of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Theoretical framework 5
2.1 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Systems thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 User Experience Framework . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Human factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Visual perception . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Stakeholder management . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Methodology 15
3.1 Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 KJ-analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Identifying opportunities . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 Interview study . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.5 Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Defining product requirements . . . . . . . . . . . . . . . . . . 19
3.2.2 Systems mapping . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Develop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Concept generation . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Deliver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 User interface prototyping . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Result 25
ix
Contents
4.1 Discovery phase results . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Interview studies . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 Workshop findings . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3 Stakeholder mapping . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.4 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.5 Opportunity Identification . . . . . . . . . . . . . . . . . . . . 30
4.2 Definition phase results . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Defining product requirements . . . . . . . . . . . . . . . . . . 30
4.2.2 System mapping results . . . . . . . . . . . . . . . . . . . . . 31
4.2.2.1 Product system map . . . . . . . . . . . . . . . . . . 31
4.2.2.2 Software interface tree diagram . . . . . . . . . . . . 33
4.3 Development phase results . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2 Network and connectivity . . . . . . . . . . . . . . . . . . . . 37
4.3.3 Pairing and configuration . . . . . . . . . . . . . . . . . . . . 39
4.4 Deliver phase results . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.1 Hardware digital prototype . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Mobile user interface . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.3 Desktop user interface . . . . . . . . . . . . . . . . . . . . . . 45
4.4.4 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Discussion 51
5.1 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6 Conclusion 55
Bibliography 57
A Appendix 1 I
B Appendix 2 IX
C Appendix 3 XIII
D Appendix 4 XV
E Appendix 5 XXXI
F Appendix 6 XXXV
x
List of Figures
1.1 An empty IBC tank. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The infrastructure of the remote tank monitoring business sector. . . 2
2.1 The Double Diamond design process and a timeline of the project. . . 6
2.2 The five stage design thinking model. . . . . . . . . . . . . . . . . . . 7
2.3 The UX honeycomb model. . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 The Rubin’s vase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 The gestalt laws. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 The stakeholder classification model according to Mitchell et al. (1997) 12
3.1 Systems mapping process. . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Interrelationship functionality in systems mapping. . . . . . . . . . . 21
4.1 User evaluation of analytic screen. . . . . . . . . . . . . . . . . . . . . 26
4.2 A part of the workshop data analysis result. . . . . . . . . . . . . . . 27
4.3 Mapping of the stakeholders for the product. . . . . . . . . . . . . . . 28
4.4 The products included in benchmarking. . . . . . . . . . . . . . . . . 29
4.5 General product systems map . . . . . . . . . . . . . . . . . . . . . . 32
4.6 A section from the software interface diagram . . . . . . . . . . . . . 33
4.7 The three parts of concept generation results. . . . . . . . . . . . . . 34
4.8 Hardware dimension limitations. . . . . . . . . . . . . . . . . . . . . . 34
4.9 Hardware shape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10 Battery level indicator LED concept . . . . . . . . . . . . . . . . . . 35
4.11 Status light concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Hardware unit mounting to tank. . . . . . . . . . . . . . . . . . . . . 36
4.13 Inter IBC connectivity concept. . . . . . . . . . . . . . . . . . . . . . 38
4.14 Pairing requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.15 Digital prototype of hardware and software. . . . . . . . . . . . . . . 40
4.16 The hardware unit and mounting disk. . . . . . . . . . . . . . . . . . 41
4.17 Mounting and removal of hardware. . . . . . . . . . . . . . . . . . . . 41
4.18 Hardware user interface control panel description. . . . . . . . . . . . 42
4.19 Navigation in the mobile application. . . . . . . . . . . . . . . . . . . 42
4.20 Mobile application interface. . . . . . . . . . . . . . . . . . . . . . . . 43
4.21 IBC current status indicator box. . . . . . . . . . . . . . . . . . . . . 44
4.22 Desktop user interface layout. . . . . . . . . . . . . . . . . . . . . . . 45
4.23 Desktop user interface sections. . . . . . . . . . . . . . . . . . . . . . 46
4.24 Quick data display function. . . . . . . . . . . . . . . . . . . . . . . . 48
xi
List of Figures
4.25 Selection tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.26 A usability testing result example from one user. . . . . . . . . . . . . 49
B.1 Part 1 of appendix 2: Function diagram of the Navigation section of
the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
B.2 Part 2 of appendix 2: Function diagram of the Analyse section of the
user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X
B.3 Part 3 of appendix 2: Function diagram of the Manage section of the
user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
B.4 Part 4 of appendix 2: Function diagram of the configure section of
the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
D.1 Analysis of interview 1 part 1. . . . . . . . . . . . . . . . . . . . . . . XXIV
D.2 Analysis of interview 1 part 2. . . . . . . . . . . . . . . . . . . . . . . XXV
D.3 Analysis of interview 1 part 3. . . . . . . . . . . . . . . . . . . . . . . XXVI
D.4 Analysis of interview 2 part 1. . . . . . . . . . . . . . . . . . . . . . . XXVII
D.5 Analysis of interview 2 part 2. . . . . . . . . . . . . . . . . . . . . . . XXVIII
D.6 Analysis of interview 2 part 3. . . . . . . . . . . . . . . . . . . . . . . XXIX
E.1 User testing results part 1 of 2. . . . . . . . . . . . . . . . . . . . . . XXXII
E.2 User testing results part 2 of 2. . . . . . . . . . . . . . . . . . . . . . XXXIII
F.1 Workshop results part 1 of 3. . . . . . . . . . . . . . . . . . . . . . . XXXVI
F.2 Workshop results part 2 of 3. . . . . . . . . . . . . . . . . . . . . . . XXXVII
F.3 Workshop results part 3 of 3. . . . . . . . . . . . . . . . . . . . . . . XXXVIII
xii
List of Tables
4.1 Twelve of the highest rated needs and requirements. . . . . . . . . . . 31
4.2 An overview table of desktop user interface functions and features. . . 47
A.1 Description of color meanings in the requirements table. . . . . . . . I
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
A.2 Requirements table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVI
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXII
D.1 Table of statements and interpretations from the case company inter-
views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII
xiii
List of Tables
xiv
List of Abbreviations
Throughout the report, terms are used which are common in the RTM (remote
tank monitoring) and UX (user experience) industries, some of which have several
definitions. This list describes individual meanings of the words which are in relation
to the context of this report.
IBC Intermediate bulk container
RTM Remote tank monitoring
ROAC Radar on a chip
GNSS Global navigation satellite systems
UX User experience
UI User interface
HW Hardware
GPS Global positioning system
API Application Programming Interface
KPI Key performance indicator
RFID Radio Frequency Identification
QR Quick response
BLE Bluetooth low energy
LED light-emitting diode
ERP Enterprise resource planning
3D Three dimensional
SW Software
IM Inventory management
xv
0. List of Abbreviations
xvi
1
Introduction
Intermittent bulk containers, usually called IBC tanks (see Figure 1.1), are mobile
plastic tanks that usually contain 1000 litres and are used to store liquids and solids
in a wide variety of industries. The IBC tanks are used for collecting rain water,
storing chemicals in the process industry and vegetable oils in the food processing
industries, to mention a few use cases. The number of tanks used by a company can
vary from a few to thousands. Radar technology is traditionally used to monitor
levels in stationary tanks, but as radars become smaller and cheaper, the opportunity
to connect them to cloud solutions has evolved. This enables tank monitoring also
on mobile tanks. This thesis will research the customer and user needs around
remote tank monitoring systems for IBC tanks and will be presented in a conceptual
solution.
Figure 1.1: An empty IBC tank.
1.1 Background
More than 20 million intermediate bulk containers (IBC tanks, see Figure 1.1) are
manufactured each year. They are made of plastic with a cage, usually made of
metal, and sit on a pallet. IBC tanks are usually stackable and usually hold 1000
1
1. Introduction
litres, but other volumes do occur. They are used for storing and shipping liquids
and solids within a wide variety of industries, such as chemical, pharmaceutical,
food and beverage, and water and wastewater industries.
Remote tank monitoring can be performed by a variety of technologies such as weight
or ultrasonic, where the common denominator is that they measure the level of the
content in a tank and communicate it to a remote user who utilizes the information.
With the introduction of Radar on a chip (ROAC), radar units can be made smaller,
cheaper and simpler compared to radar devices used for level monitoring on larger
tanks. This opens up possibilities to utilize radar technology also on smaller tanks,
such as IBC tanks. Fagerberg (2020) divides the infrastructure of remote tank
monitoring in four parts: tank segment, localisation segment, network segment and
backoffice segment (see Figure 1.2).
Figure 1.2: The infrastructure of the remote tank monitoring business sector.
Fagerberg (2020) sees logistics management as an application for remote tank mon-
itoring systems. This includes level monitoring, location tracking, security tracking,
regulatory compliance and health and safety monitoring. optimizing transportation
routes when IBC tanks are being re-distributed or refilled is another application.
Some other possible applications of remote tank monitoring on IBC tanks have been
identified to be measuring during filling to ensure recipes, tracking of inventory
during storage, tracking and status checking of IBC tanks during transportation
and non intrusive inventory checks (Fagerberg, 2020).
2
1. Introduction
1.2 Aim
This project aims to identify and define user needs and requirements for developing a
remote monitoring system for mobile plastic tanks. The user needs shall be presented
in a conceptual solution focusing on user experience and human factors.
The aim will be reached by answering of the following research questions:
1. Who are the stakeholders for this project, in which industries do they work
and what are their needs from remotely monitored IBC tanks?
2. What would a theoretical framework for developing a digital monitoring system
based on human factors and user experience look like?
3. How could a conceptual solution based on the identified theoretical framework
be visualised?
1.3 Limitations
This project is limited to conceptual development of the system that is required
to preform remote tank monitoring in IBC tanks. The digital software concepts
will not be developed to the point of functional interactivity, but will be limited
to their visual appearance. The project will not regard the aspects of economics or
monetisation of the system. No technical aspects of radar systems, sensor technology,
or software development will be addressed.
1.4 Outline of the report
The content of the report is structured in the following chapters:
2. Theory This chapter presents the theory on which this project rests
on. The theory includes the design process used, systems
thinking, user experience framework and human factors.
3. Methodology In this chapter the methodology used is presented. The
methodology chapter is divided into four chronological phases
named discover, define, develop and deliver, where each
phase has a specific goal to fulfil.
4. Result Chapter four presents the results that came from the method-
ology used, and is divided into the same four phases which
are also present in the methodology chapter.
5. Discussion This chapter presents a discussion of the process and result
that has come of this project.
6. Conclusion In this chapter, conclusions are drawn and any presumed
further work is presented.
3
1. Introduction
4
2
Theoretical framework
This chapter addresses the theoretical aspects of this project and defines the scientific
base it rests upon. The design process of the project is described in detail to show
the workflow of the project. Systems thinking is described to show the way all
aspects of the project was structured to be comprehensive. User experience and
human factors is described to establish the science on how users and their needs are
evaluated in the project.
2.1 Design process
The Double diamond design process (see Figure 2.1) was chosen as a design process
for this project. The double diamond process is a framework consistent of two
diamonds where the process in each diamond starts with divergent thinking and
moves forward to convergent thinking (The Design Council, 2015a,b). The four
stages of the process are called Discover, Develop, Define and Deliver.
In the first divergent discovery phase design research takes place, and moves over
to the convergent definition phase as the results from discovery are transferred into
creativity processes and idea generation (The Design Council, 2015a). As the def-
inition phase ends The Design Council (2015a) means that the problem definition
should be clear. In the next convergent phase of development ideas are reviewed
and analysed and the process converges into the delivery phase with prototyping
and selection of concept (The Design Council, 2015a).
The process will be iterative as the arrows in Figure 2.1 shows. As new insights will
be reached, and the knowledge of the problem grows, the process might have to be
restarted (The Design Council, 2015b).
5
2. Theoretical framework
Figure 2.1: The Double Diamond design process and a timeline of the project.
The reasoning behind the choice of the double diamond process was that it would
wold work well with the available time and resources. In the selected research and
development process, only one of the two diamond segments can take a flexible
amount of time for it’s execution. As the second diamond is iterative, and the
duration can be shortened or lengthened depending on time and resources available.
This gives a useful degree of flexibility.
As the first diamonds served as a research foundation, the second represented the
presentation of a conceptual solution which was based on the gathered research in
the first diamond. Priority was placed on having a higher quality of user studies in
comparison to concept development. That meant that if this process was utilised,
the research part would have enough time in order to achieve the expected results,
and the conceptual solution would reach the quality level which was based on the
time that remained.
The Five Stage Design Thinking Model (see figure 2.2) by Plattner et al. (2012) was
also considered useful. It had the same phases As The Double Diamond process,
but the testing phase is its own phase and the discover phase is called emphatise.
In the Double Diamond process, testing is done in the delivery phase. This process
was not chosen, because it does not allow enough flexibility, and included iterations
that were not planned. Although iteration is proven to produce quality results, it
would take too much time.
6
2. Theoretical framework
Figure 2.2: The five stage design thinking model.
2.2 Systems thinking
Systems thinking is a subcategory of systems theory, that has existed for many
decades and is an interdisciplinary study of systems Checkland (1999). The term
could be described as organised thinking. There are many definitions of what sys-
tems thinking, but the definition of Arnold and Wade (2015) illustrates the reasoning
and benefits of using it. Their definition is that systems thinking is the ability to
think abstractly in order to:
• Incorporate multiple perspectives.
• work within a space where the boundary or scope of problem or system may
be undefined.
• Understand diverse operational contexts of the system.
• Identify interrelationships and dependencies.
• Understand complex system behaviour.
• Reliably predict the impact of change to the system.
This definition illustrates systems thinking as a skill set for depth understanding
of complex behaviours and how they can impact an ultimate outcome. A famous
quote could be used set an example to how systems thinking could be viewed from
an untrained perspective:
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the
problem and 5 minutes thinking about solutions.”
-Albert Einstein
This quote illustrates the importance and superiority of examination and prepa-
ration in comparison to action. The application of systems thinking is becoming
increasingly more common (Basadur et al., 2000). There are many reasons for that,
but the most obvious one is that world itself is becoming increasingly more com-
plex. Problems which never existed to this point in history are arising exponentially
making the standard ways of approaching them obsolete. This created a need for
7
2. Theoretical framework
searching for new problem solving approaches which systems thinking often finds a
way to.
2.3 User Experience Framework
Rosenzweig (2015) describes User Experience (UX) trough usability. A system is
usable when it provides an useful service to an individual and that human centred
design puts technology into useful tools. That gives individuals the potential to
reach their goals trough good UX.
Figure 2.3: The UX honeycomb model.
The UX honeycomb (see Figure 2.3) was created by Peter Morville with the purpose
of explaining user experience (Knight, 2019). Each piece in the honeycomb repre-
sents a part of the user experience, and the keywords for this are useful, usable,
desireable, findable, accessible, credible and valuable. These concepts are described
by Knight (2019) as:
Useful: The product must solve a problem or fill a need for the user, or
it quickly will be redundant. You must know the user and their
behaviour to stay relevant to them.
Usable: It is important that a product is easy to learn how to use as well as
it should be easy to use. This is key to retain customers.
Desirable The emotional connection to a brand or product often have impact
on the user experience, and a product should contain elements that
evoke these emotions.
8
2. Theoretical framework
Findable: The user must be able to find what they need to fulfil the purpose
of use.
Accessible: A product should be usable by everyone, despite any physical or
cognitive impairments.
Credible: The user must be able to believe what the product tells them.
Valuable: The product must deliver value to the satisfaction of all stakehold-
ers, from user to business.
User experience can be integrated to the design process by using the UX framework
(Watanabe and Shirasaka, 2021). The UX framework is used by keeping track of
stakeholders requirements and turning them into system requirements. User expe-
rience design is a principle that involves multiple disciplines of design. According
to Knight (2019) these disciplines are user research, content strategy, information
architecture, interaction design, visual design and usability evaluation. The purpose
of involving each discipline is described by Knight (2019) as:
User research User research should be preformed to understand
the needs and behaviours of potential users to make
an interpretation on the effect a design has on
them.
Content strategy This aims to make sure that the contents of the
product are meaningful an engaging to the user.
Information architecture This is a discipline that aims to help the user un-
derstand where they are, where they have been and
what to expect next when they navigate trough the
information shown to them. This is achieved by
making the relation of content understandable, or-
ganising them in a logical and meaningful way to
the user.
Interaction design Interaction design is a field that strives to design
interfaces that are meaningful and engaging to the
user. This is done by trying to understand how
the user interacts with technology and then design
interfaces that are intuitive, mitigates errors and
gives feedback on the users action.
Visual design Visual design enhances the user experience and
builds trust in the brand by using visual elements
to present a message.
Usability evaluation This is used to measure the experience of the users
interaction with a product interface. Methods
are used to measure intuitiveness, error frequency,
learnability and subjective satisfaction.
9
2. Theoretical framework
2.4 Human factors
Ergonomics is seen as the knowledge of the human abilities, limitations and charac-
teristics that affects the design of artefacts, systems or environments, to make these
effective, safe and comfortable for humans to use (Hollnagel, 1997). Human factors,
also called Cognitive ergonomics, are the mental aspects of ergonomics and regards
how these designs affects the mind, and how the mind affect designs (Hollnagel,
1997). Cognitive ergonomics can also be referred to as human factors engineering.
Human performance is recognised as a contributor to major accidents, specifically
in the oil and gas industries. It has been concluded that human and organisational
factors such as the design of equipment interfaces and work environment have con-
tribute to loss of human reliability leading up to accidents (McLeod, 2015).
2.4.1 Visual perception
The perceptual organisation of visual elements is an important factor in the design
of visual displays (Proctor and Proctor, 2012). The concept of prägnanz stems
from gestalt psychology, first mentioned by Köhler (1920) and later refined from
the experiments by Wertheimer (1923). They suggest objects perceived will be
organised the simplest way possible. A display that is viewed will be perceived as a
background with figures and either the darker or lighter of the elements will be seen
as background.
Figure 2.4: The Rubin’s vase.
This was first described by Rubin (1915), now known as The Rubin’s Vase (see
Figure 2.4). This shows how symmetrical patterns will be perceived as a figure and
a figure that completely surrounds another figure, will be perceived as a background.
Grouping of elements (see Figure 2.5) is another important factor in how objects are
perceived, and according to Proctor and Proctor (2012), the most recognised ones
are:
Proximity Objects close to eachother tend to be grouped together.
Similarity Objects of similar shape or color tent to be grouped together.
Continuity Figures tend to be organized in continuous paths.
10
2. Theoretical framework
Closure Elements that make up a closed figure usually get grouped
together.
Common region Objects that are collected within a border tend to be grouped
together.
Connectedness Objects that are connected with a line tend to be groped
together and separated from other connected groups.
Figure 2.5: The gestalt laws.
The principals of proximity, similarity, continuity and closure (see Figure 2.5) were
introduced by Wertheimer (1923) and the principals of common region and connect-
edness were presented by Rock and Palmer (1990). Palmer (1992) demonstrated
that when several common regions are are conflicting, the smallest one dominates
the grouping. When regions are nested and consistent, they are perceived hierarchi-
cal.
2.5 Stakeholder management
The stakeholder classification model presented by Mitchell et al. (1997) is a venn
diagram (see Figure 2.6) where the level of stakeholder power, legitimacy and ur-
gency defines the attributes of a stakeholder. Stakeholder power indicates to what
degree a stakeholder has the coercive, utilitarian or normative means to get their
will trough (Mitchell et al., 1997). Power should be seen as transitional, as it can
be gain or lost.
The definition of legitimacy by Mitchell et al. (1997) is somewhat vague but implies
that most scholars defines it as a normative trait. It could be found in moral claims,
something at risk or other constructs and is seen as a larger cause or a social greater
good(Mitchell et al., 1997). To have urgency as a stakholder, Mitchell et al. (1997)
means that there must be both a critical time factor and a great importance or
11
2. Theoretical framework
critical aspect for the stakeholder. Mitchell et al. (1997) states possible critical
factors can be related to aspects of ownership, sentiment, expectation and exposure.
Figure 2.6: The stakeholder classification model according to Mitchell et al. (1997)
When these attributes are put into the model, each field in the diagram creates a
classification that have different attributes, needs and claims. These classifications
are describes by Mitchell et al. (1997) as follows:
1. Dormant stakeholder: These stakholders have power over a com-
pany, but no reason to use it.
2. Discretionary stakeholder: There is legitimacy to the claim of a discre-
tionary stakeholder, but no power or urgency
to influence a company.
3. Demanding stakeholder: By not having power or legitimacy to their
claim, demanding stakeholders mostly search
for attention.
4. Dominant stakeholder: With the combination of power and legiti-
macy, dominant stakeholders can influence a
company and act on their claims.
5. Dangerous stakeholder: By having power and urgency a stakeholder
can be coercive and force their illegitimate
claims.
6. Dependent stakeholder: By lacking power, these stakeholders are de-
pendent on the advocacy or governance of
other, sometimes dominant, stakeholders to
voice their claims.
7. Definitive stakeholder: By having all attributes, the dominant stake-
holder will enjoy the priority and attention by
managers.
12
2. Theoretical framework
8. Non-stakeholder: Someone claiming to be a stakeholder without having
any attributes are not a stakeholder.
Salience is the level of attention of which managers give attention to a stakeholder
claim. Mitchell et al. (1997) means that the level of salience depends on the number
of attributes a stakeholder has, with more attributes giving higher salience. Classes
1-3 have low salience, and are seen as latent stakeholders (Mitchell et al., 1997),
implying that they are dormant. Class 4-6 are seen as moderatly salient, expectant
stakeholders, as they expect something from the situation they are stakeholders in
Mitchell et al. (1997). Class 7 is the definitive stakeholder that has all attributes
and therefor is a highly salient.
13
2. Theoretical framework
14
3
Methodology
The methodology chapter presents a set of design methods chosen based on their
focus on innovation, user experience and human factors engineering. The method-
ology is divided into the four phases of the double diamond process (see Figure 2.1).
The discover phase researches the market and users, the define phase methods define
which findings should be taken forward, the develop phase generates and iterates
the ideas and in the deliver phase the ideas are prototyped, tested and refined.
3.1 Discover
The discover phase aims to establish the context of the project. It includes method-
ology for studying the market, competitors, and users, in order to collect information
that can reveal user needs.
3.1.1 KJ-analysis
KJ-analysis is a method for picking out user needs that are identified during the
discover phase. Statements made by stakeholders are grouped by similarity, and
deviant statements are placed on their own (Shun and Kosuke, 2010). When all
results from the discover phase is reviewed all the identified needs are categorised
and can be labelled appropriately.
KJ-analysis was used to sort and categorize statements from all user study activities
related to the discover phase.
3.1.2 Benchmarking
Benchmarking is meant to study competitive solutions, solutions to similar problems
and solutions to other problems that can be used to solve the problem of the current
project (Ulrich and Eppinger, 2012). Using benchmarking will aim to research how
competitive companies places themselves on the market, to possibly identify key
features for a RTM solution, and to identify gaps in the market.
Benchmarking was preformed on the hardware of four competitive products that fill
the need of level monitoring on IBC-tanks. Two software applications that work with
the measurement device of corresponding company were also analysed. The needs
15
3. Methodology
from the requirements table were used as a guideline for finding relevant information,
but some new possible needs were found and entered with the requirements.
Of the four competitive solutions, the ones from Endress & Hauser and Vega were
established on the market. The ones from Packwise and Nanolike were on the market
for testing with customers. From the two established solutions the technical data
sheets were studied to find the functionalities, while the testing solutions did not
share that data publicly, and only information from their websites could be analysed.
The software was analysed by finding screenshots from the companies websites and
demo software, which were compiled into collages where different functions were
highlighted. The results were put into its own part of the requirements table, see
Appendix 1.
3.1.3 Identifying opportunities
Ulrich and Eppinger (2012) describes the practice of doing market research in order
to find successful innovations that can be imitated to fulfil a different need, or refined
to address the same need in a different context. This could be done by researching
patents, looking trough media and marketing of companies in interesting business
areas. The aim of doing research for identifying opportunities is to find solutions to
sub-functions that emerge during the discovery phase.
3.1.4 Interview study
According to Kvale (2007), the quality of an interview study rests on the craftman-
ship of the researcher. Interview studies can be methodological or not, and this
creates an openness where the decision of following a lead or the interview guide
has to be made in the moment (Kvale, 2007). An interview study can according to
Kvale (2007) be divided into the following seven steps:
1. Thematizing The purpose and theme of the study needs to be formulated.
This represents the why and what of the study.
2. Designing The study needs to be planned and designed whit the aim
of finding the intended knowledge. Moral implications of the
study shall be taken into account.
3. Intervewing The interviews should be conducted based on an interview
guide, and the researcher needs to have a reflective approach
to the knowledge that is sought after.
4. Transcribing The interview material needs to be prepared for analysis by
transcribing the interview from speech to text.
5. Analyzing The method of analysis needs to be chosen bases on the pur-
pose and topic of the study and the nature of the interview
material.
16
3. Methodology
6. Verfying The validity, consistency and possibility to generalise the results
needs to be established in order to confirm that the study inves-
tigates what it supposed to.
7. Reporting The method and findings of the study needs to be presented so
that it lives up to scientific standards and takes ethical aspects
into consideration.
When creating a interview guide Kvale (2007) means that it is beneficial to write
two interview guides; one with the researchers questions, to specify what knowledge
is sought after, and the interviewers questions, that aims to collect rich and varied
answers. Kvale (2007) suggests the following types of questions can be useful an
interview study:
Introductory questions When the subject gets to open an interview by de-
scribing a situation from their own perspective, spon-
taneous and personal experiences can be uncovered.
Follow-up questions By being curious, persistent and critical as an in-
terviewer, the subject may elaborate their answers.
This can be done by direct questions, agreeing, or
leaving silence to invite for more elaboration.
Probing questions Probing is a method encouraging the subject to tell
more without specifying what dimensions of the an-
swer is looked for.
Specifying questions These types of questions are used to find precise
statements where the answers are of a general kind.
Direct questions In the later part of an interview, when the subject
has shown what is relevant to them, direct questions
can be asked to get specific answers on specific topics.
Indirect questions To get a general view of attitudes of others or them-
selves, indirect questions can be asked, but needs to
be followed up by questions that allows the answers
to be properly interpreted.
Structuring questions In order to break off long answers or steer the inter-
view, structuring questions can be asked to lead the
interview in the desired direction.
Interpreting questions By rephrasing answers, clarification from the subject
can leave new information to the interviewer.
Silence By leaving silence in the interview, the subject is
given the opportunity to reflect and break the silence
with new information.
The interview guide (see Appendix C) was constructed to include as many types of
questions as possible. Introductory questions were asked to establish the context
17
3. Methodology
of the industry and professional role of the interviewee. Probing and follow-up
questions were spontaneously used to search for more information. Direct questions
were used when there was an opportunity to get the interviewees opinion on a matter.
Three sets of images of the prototype was used as a mediating object with the aim
of starting a conversation on the user needs of their industry and to get feedback on
the visual information presented in the prototype.
The case company had previously contacted possible users to learn about their
industries, needs and restrictions in terms of tank monitoring on mobile tanks. There
were five individuals interviewed, who were engineers and managed the instruments
and technology upgrades in their facilities. The interview guide used had open
questions that searched for similar knowledge to what was needed in the primary
phase of user studies, so the material was deemed relevant to analyse for finding
user needs.
Relevant statements from the interviews were analysed with KJ-analysis. State-
ments were sorted in to categories such as business model, connectivity, safety, mea-
surement data, hardware and software. When the analysis was done, the statements
were translated to needs and put into the requirements table (See Appendix A).
The interview guide were used for the second round of interviews, two individuals
were interviewed. One worked the paint industry and one worked the food and
beverage industry. Both worked in managerial roles. Statements from the interviews
were noted and the relevant ones were written besides the image of the prototype
it referred to. The feedback from the interviewees was subjectively analysed and
put into the UX-honeycomb (see Section 2.3) to get a better overview of the user
experience. The result was used as feedback for iterations in the prototyping process.
3.1.5 Workshop
A workshop is a knowledge sharing method where participants gather to explore a
specific topic in a creative way. The purpose is to utilise the higher idea generation
potential of a group, in comparison to that of an individual (Wikberg Nilsson et al.,
2015).
A workshop was held in early stages of the discovery phase to expand existing
knowledge base. The workshop included 12 participants and 1 facilitator. The par-
ticipants were 11 engineers working with product and business development within
the organisation of the case company and one industrial design engineering student.
The area of exploration was large, and the aim was to get a better understanding
about the vision of the case company, their existing knowledge and technological
possibilities.
The workshop was held digitally through the communication platform Teams and
digital whiteboard Mural. The workshop design was approached in a structured
manner, including the following activities:
18
3. Methodology
Introduction Facilitators and participants introduced themselves
and their professional backgrounds.
Context presentation A presentation about the context and aims of the work-
shop was presented to the participants in order to es-
tablish and clarify the expectations.
Warm up exercise A warm up exercise was held for the participants to
get acquainted to Mural.
Ideation exercise 1 The first ideation exercise focused on a broad vision
of business opportunities. This activity was executed
in groups of four, so that the participants were able
communicate but still not affect the diversity of ideas
from other groups during 20 minutes.
Ideation exercise 2 The second ideation exercise was a session where tech-
nical functionalities were explored. The exercise was
done individually, in silence, by all participant, during
20 minutes.
Voting session The voting session included examining and rating of
the ideas. The voting results was used as conversation
starter for the discussion activity.
Discussion The results from voting were discussed and details were
further explained.
The result was analyse with KJ-analysis and put into the reqirements table.
3.2 Define
According to The Design Council (2015a) the define phase is where elaboration and
filtering of data which was gathered in the discovery phase takes place. The define
phase also aims to set a context to develop and delivery phases. In the context of this
project it meant the definition of which data sets should be kept and which should
be discarded. This was done through the use of defining product requirements and
systems mapping.
3.2.1 Defining product requirements
The needs of users are usually expressed in the language of the user and are difficult
to quantify (Ulrich and Eppinger, 2012). To make the user needs manageable they
need to be translated into specifications, that shows what a solution need to do in a
precise way (Ulrich and Eppinger, 2012). The requirement should not express how
user needs are fulfilled, but rather what the solution needs to do in order to fulfil
them.
According to Ulrich and Eppinger (2012), a list of metrics should be prepared from
the identified user needs. The needs can be ranked based on the importance to
19
3. Methodology
the user. Benchmarking of competitive products can be done based on these met-
rics. When all information is compiled, it is be converted to ideally and marginally
acceptable target values (Ulrich and Eppinger, 2012). The specification need to
be evaluated during the development process and is finalised as technical and cost
related details are specified
The needs found in the analysis of interviews and the workshop were used to bench-
mark competitive solutions. In order to decide the relative importance of each need,
they were graded from 1-3, and the needs seen as a requirements were marked with
a "R". A mean was calculated and.the needs that received a mean from 2,5 to 3
were chosen along with the requirements to be included in further prototyping.
3.2.2 Systems mapping
Systems mapping is an organisational tool which is based on systems theory and
systems thinking (Lee et al., 2017). It is a holistic approach for examining complex,
real-world systems. Systems mapping is useful when the amount of information in
a system becomes too large to comprehend. A systems map becomes a visual aid
and gives a holistic view of the system. System mapping was utilised in the define
phase, in order to organize the technological parameters for the solution.
According to Lee et al. (2017) the fundamental principles of systems mapping are
interconnection, adaptation and environment, that focus should not be directed to-
wards individual components, but to the dynamic interrelationships between them.
Interesting patterns and behaviourscan emerge from the interrelationships that oth-
erwise could be missed. The process of creating a systems map is presented in figure
3.1. It shows the conversion process of an unorganised set of components into an
organised system map. The process is done in the following four steps:
1. Compilation of all system components.
2. Sorting of components into categories based on similarities.
3. Defining which systems category the components fit into by creating cat-
egory bounding boxes
4. Establishing interconnections between components with directional ar-
rows
20
3. Methodology
Figure 3.1: Systems mapping process.
The top row of Figure 3.2 represents a systems map scenario where a component is
removed from a system that has defined interrelationships. The bottom row showd
a system that do not have interconnections established. This suggests that mapping
is more accurate when interrelationships are defined.
Figure 3.2: Interrelationship functionality in systems mapping.
3.3 Develop
In the develop phase the most promising ideas from the first diamond are selected,
developed further and tested in an iterative process (see Figure 2.1) (The Design
Council, 2015a). According to Kurt et al. (2017), creativity plays an increasingly
crucial role for innovation in an organisation or a development project. Therefore,
the primary development phase focus was concept generation.
3.3.1 Concept generation
Concept generation is a way of boosting confidence of a product development project,
through the exploration of the full solution space (Ulrich and Eppinger, 2012). Ac-
cording to Ulrich and Eppinger (2012) This is done in the five following steps, that
are designed to reduce the likelihood of having to make drastic changes in later
stages of development.
21
3. Methodology
1. Problem clarification: The problem was broken down into subproblems
and the focus was put on the most critical sub-
problems.
2. Search externally: This was done through discussions with experts
in the technological field, case company engi-
neers and benchmarking information.
3. Search internally: This step exploits the potential of personal in-
put to the concept generation, by suspending
personal judgement, generating many ideas, and
welcome ideas that seem infeasible.
4. Explore systematically: Systematical exploration was used by visualis-
ing data in diagrams based on systems thinking
theory.
5. Reflect on the solutions: The process and result was reflected upon, in
order to identify any strengths or weaknesses
that could be used for improvement.
3.4 Deliver
In the deliver phase concepts are prototyped, tested and evaluated in an iterative
process (The Design Council, 2015b). This was done through user interface proto-
typing and usability testing which were chosen based on the results from the develop
phase.
3.4.1 User interface prototyping
The method that was chosen for user interface prototyping has five steps that are
suggested to be preformed in a sequence, but can also be adjusted to the context of
a project and still provide good results (Shneiderman et al., 2016). The five steps
are:
1. The first step defines use scenarios and conceptualises data flow diagrams of
the user interface. The diagrams can be tested with users.
2. The second step contains the visualisation of data flow diagrams and identifi-
cation of primary components and their interrelationships.
3. In the third step, interface standards are created, such as navigation and
structure of visual elements.
4. A digital prototype is created in the fourth step containing visualisations of
the interface.
5. In the fifth step the results are evaluated based on cognitive ergonomics and
usability.
22
3. Methodology
3.4.2 Usability testing
Usability testing is a method to evaluate prototypes to find the ease of use and
learnability of real users (Haiyan and Baozhu, 2011). The participants preform
tasks based on scenarios, short storylines that describe a user preforming a task in
a specific use context. This allows the participants to immerse themselves in the
circumstances and express their thoughts, needs and suggestions.
Usability testing was preformed as a final activity of the first iteration of ideation.
It aimed to identify the traits of the prototype according to usability theory aspects:
Useful, usable, desirable, findable, accessible, credible and valuable aspects (Knight,
2019). The participants of the usability testing were industrial design engineering
students. They were chosen based on their ability to evaluate the design features of
the prototype. The participants were presented with basic knowledge of the industry,
common problems and potentials to become familiar with context of the prototype.
Digital visualisations were used to present the conceptual product in the form of
CAD renderings of the hardware and slideshows of the software. The following use
scenarios were created to test some of the functionalities of the prototype:
• Mount the hardware, switch it on and locate the battery level.
• Pair and configure a new device.
• Use the mobile interface to create a fill request.
• Identity the purpose of the four different dashboards in the desktop interface.
The user testing sessions were documented by filming and the participants com-
municated their thoughts and ideas verbally and trough sketching. The data was
transcribed and analysed trough KJ-analysis, where statements were color coded
and categorised. The statements determined most relevant were emphasised and
brought into the next iteration phase.
23
3. Methodology
24
4
Result
In this chapter results from executing the methodology are presented. This chapter
is ordered in the double diamond development process phases and starts with the
result from the discover phase, continues with define and develop phases, and ends
with the the deliver phase.
4.1 Discovery phase results
This section includes results which are based on the discovery phase section of the
method chapter. These scope of results which are presented includes interview
studies, workshop, benchmarking, KJ analysis and opportunity identification.
4.1.1 Interview studies
The study of interview material from the case company revealed statements that
were extracted and sorted with KJ-analysis. The statements were interpreted into
needs and put into the requirements table (see Appendix 1). The collection of
statements and interpretations can be seen in Appendix 3. The statements revealed
different contexts where IBC tanks are used, and which issues that comes with them.
One example is that when an IBC tank is placed under ground, being used in an
oil separating system, it can be fully submerged in groundwater. That creates a
demand for solutions that works regardless of the groundwater levels, which was
interpreted to the need of a wtaerproof solution.
The second interview study resulted in a collection of statements and a subjective
judgement based on these put into the UX-honeycomb (see Figure 4.1). The pro-
totype was used as a mediating object during the interviews and it showed two
use scenarios in the mobile app and one in the desktop app. The reactions from
the interviewees were generally welcoming, but the desktop prototype management
function was the one which sparked the most reaction and reflection. One of the
interviewees stated that they would like to see the interfaces of the prototype both
in the control room and in the production floor to improve the production planning
and flow. The full result of the second interview study is found in Appendix 4.
25
4. Result
Figure 4.1: User evaluation of analytic screen.
4.1.2 Workshop findings
Findings from the workshop resulted in many forms of information. The information
included short pieces of text written by participants, sketches and images which were
browsed online and pasted the digital whiteboard. The workshop was recorded, so
statements could also be extracted afterwards. The statements from the workshop
were translated, analysed with KJ-analysis and categorized. The results of the
workshop were translated in to needs where applicable, and put into the requirements
table, see Appendix A.
In figure 4.2 a section of the KJ-analysis process is shown. For the full figure, see
Appendix F. The analysis was done in three steps. First, raw data was collected
from the workshop exercises. In the second step, the data was sorted and organised
into categories. In the third step, a map was created to find overlapping segments of
categories. Overlapping segments are shown in Figure 4.2, as bounding boxes with
titles in pink, and statements in yellow .
26
4. Result
Figure 4.2: A part of the workshop data analysis result.
The workshop data analysis resulted in a list of needs and requirements. These
needs was placed in categories related to the product, technical aspects, visionary
ideas, economical aspects, durability, security and user experience. The result can
be summarised as:
• A general desire to prioritise software before hardware in the business model.
• Subscription based service should be the main revenue.
• The solution should be capable of interaction with other products;
• Integration of AI and machine learning to the software, such as forecasts and
trends.
• Data visualisation of inventory history.
• Real time GPS tracking.
• A security system that is triggered by the hardware components.
27
4. Result
• A long battery life or a method of energy harvesting to charge the battery
• Robust hardware housing which is capable of withstanding all environments.
4.1.3 Stakeholder mapping
A stakeholder map was made in order to keep track of the stakeholders that were
identified during the discovery phase (see Figure 4.3).
Figure 4.3: Mapping of the stakeholders for the product.
Company leaders were deemed dormant stakeholders as they have power over prod-
uct lines of the company, but have no reason to use it as long as work run smooth.
Environmental NGO’s were categorized as discretionary stakeholders since they usu-
ally have legitimate but moral claims, but no real power to force their agenda. They
will need to cooperate with a dominant stakeholder with power and urgency, such
as a legislator, to affect the company. Operator users may have legitimate claims
regarding a product, but have no channels to directly affect the company. Neigh-
bours of industrial facilities are seen as demanding stakeholders, as they are directly
affected by the industry, and would like to draw attention to their opinions.
The division management of the company is seen as a dominant stakeholder along
with the legislators, since they have power to influence and act on their claims.
Competitor companies are categorized as dangerous stakeholders, as they have power
and urgency to keep their place in the market. Users in management or engineering
is seen as dependent stakeholders, as they can have legitimate claims that they want
to attention to, but have no own power to change. The engineers and developers
working with the project are seen as definitive stakeholders as they hold the power,
knowledge and possibility to affect the product. The stakeholders of category 4-7
28
4. Result
are the ones with highest salience, and need attention to their claims, while category
1-3 need to be kept an eye on, to notice any shift in placement.
4.1.4 Benchmarking
Benchmarking was preformed on the hardware of four competitive products that
fills the need of level monitoring on IBC-tanks, see Figure 4.4. The products chosen
for benchmarking were from Endress & Hauser the Micropilot FER30, from Vega
the Vegaplus Air 23 and from Packwise the Smart Cap. These measurement devices
operate with radar measurements, have GPS and temperature sensors. The fourth
solution, from Nanolike have the same functionalities but measure level trough a
strain gauge.
Figure 4.4: The products included in benchmarking.
The most prominent result of the benchmark was that energy supply is something
that differs widely between the solutions. The established ones are more sophisti-
cated, and when used as some user would, their battery would last as short as three
to six moths. On the other hand, the solutions that were still in testing had less
measuring possibilities, but had a lifespan of up to six years.
The software benchmark resulted in listings of functions and visual aspects of the
different software and color schemes. The same information were available in both
software, but presented with different detail. The color schemes were both based in
grey, with the company color as a highlight and red, green, yellow indicating tank
level.
29
4. Result
4.1.5 Opportunity Identification
To find solutions to some of the software functions discovered in benchmarking,
software that had similar functionality were researched in order to find key elements
that made them usable.
Task management software
Many functions of these online tools could be integrated into a potential inven-
tory management solution for IBC tanks. These are functions of task organisation
connected to task status, priority level, assignee and due date.
Flight radar
Flight Radar is a website that features real time visualisation of air planes on a
global map. The visualisation of moving objects attached with specific information
is a relevant feature for a the interface that shows tank movements.
Navigation software
Notably Google Maps and Studio NAND’s Peak Spotting software. These products
show real time visualisations on maps, using data in connection with AI algorithms
to predict traffic congestion and give the user suggestions to avoid getting stuck in
traffic. The combination of real time GPS tracking being visualised on a map with
AI assisted suggestions is a function that might be useful in managing logistics in
the software concept.
Financial Data visualisation
The financial industry has a history of storing and presenting large amounts of data.
Users can navigate and find information with the help of search functions and screens
based on parameters such as key figures, stock price changes, geographical areas and
indexes. The data can be presented in different ways depending on what the user
find interesting to analyse previous events and future possibilities.
4.2 Definition phase results
Definition phase of this project resulted in a defined selection of product require-
ments and its system map. These results represented the point of convergence of
discovery phase findings and the middle point of the double diamond design pro-
cess. Therefore, the results which were achieved here served as a foundation for the
development and delivery phase execution.
4.2.1 Defining product requirements
The needs found in the analysis of interviews and workshop were used to benchmark
competitive solutions. The results of these activities were combined into a table of
requirements with 107 individual requirements (see Table 4.1). The full requirements
list can be found in Appendix A.
30
4. Result
Table 4.1: Twelve of the highest rated needs and requirements.
No Need A T Avg E&H Vegaplus Packwise Nanolike
Micropi- air 23
lot FWR
30
12 Measure level R R R Yes Yes Yes Yes
32 Wireless connec- R R R Yes Yes Yes Yes
tion
35 Wide connectiv- R R R Yes Yes Yes
ity area
106 Battery powered R R R Yes, D 2 x LS Probably Yes
17500
11 Measure temper- 3 3 3 Yes Yes (A) Yes (A) Yes (A)
ature (Ambien- (A&P)
t/Process)
13 Location tracking 3 3 3 Yes Yes Yes Yes
15 Measure tank tilt 3 3 3 Yes No Yes No
60 Simple mounting 3 3 3 Thread, Adheisive, Tape/carrieYr es
ceiling, ceiling, plate
wall, belt
IBC
61 Simple removal 3 3 3 Yes No Yes
62 Not hinder stack- 3 3 3 Yes Yes Yes Yes
ing tanks
63 Re-attachable 3 3 3 Yes Depends Yes Yes
64 Plug and play 3 3 3 No Yes Yes Yes
4.2.2 System mapping results
When sufficient data regarding the technical possibilities and user needs was gath-
ered, a final iteration of systems mapping was carried out. The result came in the
form of diagrams that represent the suggested configuration of components. The di-
agrams that were produced was a system map of the entire product and a software
user interface tree diagram.
4.2.2.1 Product system map
The systems map is presented in figure 4.5. It presents a broad view of the different
sections and components that are included in the product, and how users interact
with the hardware through the software.
The product systems map resulted in a configuration of components that are cate-
gorized and interconnected. The categories included in the product system map are:
User interface, hardware components and external infrastructure. The descriptions
of the main categories of the product system map are listed below:
The user interface category of components is situated between the user and
the hardware segment of the product system. As the user interface communicates
31
4. Result
between the user and the hardware it can be identified that it should be prioritised
in further development.
The user interface category of the system map has two sub categories: Hardware user
interface and software user interface. They are shown in figure 4.5 as circles. The
hardware user interface communicates the power switch, battery level and device
status directly, without digital device. The software user interface relies on the use
of devices as computers and mobile devices to communicate the capabilities. The
software user interface also relies on external infrastructure components.
The hardware category of the product system map represents all physical compo-
nents that were defined in the requirements list. Three components are overlapping
with the hardware user interface subcategory, that implies that these are hardware
components that have user interface purposes.
The external infrastructure category of the systems map serves the purposes
to operate the GPS and Bluetooth components of the hardware and connect the
hardware category with the software category.
Figure 4.5: General product systems map
32
4. Result
4.2.2.2 Software interface tree diagram
A tree diagram of the software user interface was made to guide the user inter-
face design. The diagram shows the software user interface functionalities and their
interconnections. The diagram was created based on systems thinking, which em-
phasises the utility of data visualisation when the amount of data becomes too large
to comprehend. A part of the diagram is presented in figure 4.6, and contains one
of four sections of the user interface requirements. The full diagram can be seen in
Appendix ??.
Figure 4.6: A section from the software interface diagram
4.3 Development phase results
In this section of the report the develop phase results are presented. The result from
the concept generation is presented in three parts; hardware, network/connectivity
and pairing/configuration/user interface (see Figure 4.7). Their contents are briefly
explained below:
• Hardware: The first part includes concept generation of the hardware unit. It
includes concept generations related to physical hardware design and hardware
user interface design.
33
4. Result
• Network and connectivity: The second part includes concept ideas related
to connectivity components, networking concepts and integration of connec-
tivity of hardware and software.
• Pairing, configuration and user interface: The third part presents results
related to concept development of hardware/software pairing, it’s configuration
process and user interface.
Figure 4.7: The three parts of concept generation results.
4.3.1 Hardware
Although a detail design of the hardware was deemed unnecessary, but the hardware
dimensions, shape and design language needed to be defined to create a context for
the development of other segments.
Hardware dimensions
Based on information of the battery technology, existing competitors and the shape
of IBC tanks, the dimensions of the hardware was approximated (see Figure 4.8).
The total height could be up to 8 cm, as it could otherwise interfere with stacking and
transportation. The diameter should be around 15 cm. If smaller, some electronics,
like the choise of battery might be limited. If larger, it could be difficult to fit the
available flat surface on IBC tanks. Being too large could also make it difficult to
mount and dismount.
Figure 4.8: Hardware dimension limitations.
34
4. Result
Hardware shape and design language
The hardware was conceptualised to be cylindrical, as this type of a shape would
enable development of uncomplicated rotational mounting mechanisms, good grip
and an simplistic appearance (see Figure 4.9). The design language and product
identity was studied during hardware concept development. This could make the
product be more recognisable and desirable to use. The design language and identity
could be incorporated as hardware shape, logotype placement, packaging and colour
selection.
Figure 4.9: Hardware shape.
Hardware user interface
The ardware user interface design was important as it is connection to the user
experience and software. The ideation process of the user interface design resulted
in the following concepts:
• Battery replacement: Battery replacement hatch placed accessibly on the
exterior of the hardware.
• Battery level indicator: A battery indication concept is presented in Figure
4.10. It shows the LED light configuration for different battery levels. The
indicator should be visible on the hardware unit and should have the option
to be turned turned off to save battery.
Figure 4.10: Battery level indicator LED concept
35
4. Result
• Status indicator: A status light concept is presented in Figure 4.11. It
indicates a pending management request, assists the configuration process,
monitoring status, makes it possible to locate a specific hardware unit. The
status is shown by either color or a flashing sequence.
Figure 4.11: Status light concept
• Hardware mounting: The mounting process is tied to the configuration of
the device and should be effortless. The solution was a disk that is glued onto
the IBC tank permanently (see Figure 4.12). The mounting disks should be
included in the product to create flexibility of mounting the hardware unit on
different tanks. This could be solved with a plastic material and a shape that
is easy to produce. The mounting disks can not interfere with the radar signal
from the hardware device. This could be solved by removing material from
the central part of the mounting disc, see Figure 4.9.
Figure 4.12: Hardware unit mounting to tank.
• QR code location: One of the pairing possibilities for a new unit with an
IBC tank could be through scanning a QR code. The code should be placed
36
4. Result
in a location that is easy to find and accessible when tanks are stacked.
4.3.2 Network and connectivity
A connectivity concept was to be developed to make the hardware wireless. It
included a combination of connection types to suit different use cases. The con-
nectivity technology chosen was second generation cellular connection (2G), global
positioning system (GPS) and Bluetooth low energy (BLE).
2G is based on General Packet Radio Service (GPRS) mobile data standard which
includes 2G and 3G cellular communication network’s on a global scale. The reason
for 2G being chosen for mobile data transfer was the low power consumption, large
area-coverage and transmission volume capacity(Perrucci et al., 2009). Due to it’s
lower operation frequency in comparison with some of the more modern connectiv-
ity generations such as 4G or 5G, it uses significantly less power (Mahmoud and
Mohamad, 2016). It is a global network standard with a high coverage, which is
important due to a need for a good connection globally. 2G also has a transmission
volume capacity that is higher than required.
Another connectivity technology which was chosen to be integrated into the concept
solution was GPS. It would enable Geo-location, geographical fence (Geo-fence) and
related security functionalities. This could be used for higher efficiency in inventory
management, with real-time information on inventory locations, and theft protection
that notifies of unusual movements.
Bluetooth low energy (BLE) was identified to have potential the hardware unit.
The Bluetooth connection would serve the purpose of hardware inter-connectivity,
that fulfills the need of tanks being are able to talk to each other. This user need
originated from the users desire for a greater battery optimisation of the RTM
hardware unit. This technology can also be used to optimize the battery life.
Usability scenario of the connectivity concept
The use of GPS, 2G and Bluethooth in the hardware unit would enable a many
functionalities. In order to visually show the capabilities of the concept, a virtual
monitoring scheme was created (see figure 4.13). It shows a possible situation where
IBC tanks are be scattered in various locations and layouts in a warehouse. This
situation was conceptualised in order to describe the technical capability of the
connectivity concept.
The use cases shown in figure 4.13 includes a set of different IBC tank layouts which
could occur in a real-life scenario. The layouts are marked with numbers from 1 to
5 and each represents circumstances of storing IBC tanks. The scenarios are:
1. Lone IBC tank located outside. Good GPS and 2G signal, but out of inter-
connection range. Result is good monitoring and location, but bad power and
data usage efficiency.
2. Groups of several IBC tanks located outside within interconnection range of
37
4. Result
one another. This type of IBC placement enables optimal working efficiency.
3. Small group of IBC tanks outside located out of range of other groups. Mon-
itoring works at medium efficiency.
4. Two IBC groups located indoors with no GPS or 2G connection. They are
in interconnection range of one IBC with 2G and GPS connection. If as-
sumed interconnection range is equal to or greater than property boundary
distance to Geo-fence distance this can be concidered safe. This means that
if interconnection is established, the IBC must be located within the radius of
interconnection.
5. A single IBC group located indoors with no external connection, only inter-
connected with one another.
Figure 4.13: Inter IBC connectivity concept.
38
4. Result
Impact of connectivity further in the product development process
The Connectivity concept serves as a backbone to the concept, and if altered, it also
affects the rest of the product, which can be seen in product system map (Figure
4.5). Therefore the conceptualisation of this segment was done beefor software and
hardware design. This also affects the external and internal infrastructure of the
hardware. As the conceptual solution includes 2G, GPS and bluetooth, all external
infrastructure have to be considered, such as GPS accuracy and reach, 2G coverage
and Bluetooth range.
4.3.3 Pairing and configuration
This subsection contains results of pairing hardware with software and the onfig-
uration process. This stage was carried out after the hardware and connectivity
concepts were generated. This meant that in addition to fulfilling the user needs,
this result reflect the limitations and features that were conceptualised in the hard-
ware and connectivity concepts.
Pairing
The pairing concept was designed to be effortless. The process was designed in four
steps that would complete basic configuration of the hardware. To do the config-
uration, a mobile device, hardware unit and IBC tank is needed (see Figure 4.14).
The process is:
1. Attach the hardware unit to the tank.
2. Log into app on smartphone.
3. Select "add new monitoring device".
4. Scan QR-code on hardware unit.
After successful pairing, there are two options. The first is to use the basic configu-
ration and the second is to specify more parameters for other measurement options.
The basic configuration enables vertical level measurement, location, temperature,
and default hardware unit name, which is the serial number.
Figure 4.14: Pairing requirements.
Configuration
Further configuration would be possible through both mobile and desktop software.
The configuration options include the following settings:
39
4. Result
Specify content Select content type or a create new content.
IBC type Specifying the tank is necessary to receive the most
accurate volume data.
Transmission interval Select transmission intervals to choose in which time
frame the hardware should be active.
Geofence The category includes settings as selecting existing ge-
ofence, draw new geofence, geofence settings, geofence
security, transmission settings for a specific geofence,
security alarms and notifications settings.
Security Security settings includes interval settings for theft no-
tifications, notification upon movement and movement
outside a geofence and upon temperature interval de-
flection.
Radar settings Radar settings includes measuring frequency of passive
or intensive.
Thermometer The thermometer settings include temperature inter-
vals for content requirements and notification for irreg-
ular temperatures.
4.4 Deliver phase results
The deliver phase resulted in a conceptual prototype and an user experience eval-
uation. The prototype was was developed in the segments hardware and software.
The hardware segment includes digital visualisations of the prototype and the soft-
ware includes a mobile and desktop user interface prototype. The prototypes are
illustrated in Figure 4.15.
Figure 4.15: Digital prototype of hardware and software.
40
4. Result
4.4.1 Hardware digital prototype
The primary aim for the hardware prototype was to facilitate usability testing, to
receive feedback of how users would perceive the concept. The digital prototyping of
the interface resulted in a series of CAD renderings, that shows the functionalities,
see Figures 4.16, 4.17 and 4.18. Figure 4.16 shows the hardware unit prior to being
mounted on a tank, paired with the software and configured by the user. It shows
the two main components that are the hardware unit and the mounting disk that
holds the hardware on the tank.
Figure 4.16: The hardware unit and mounting disk.
The mounting process of the hardware unit and the disk is visualised in figure
4.17. The function was designed as a rotational locking mechanism that holds the
hardware unit in place. The mounting disk should be considered disposable, as has
a permanent, glue-based fixture to the IBC tank. That means the hardware unit can
be detached and moved to other IBC tanks, while the mounting platform cannot be
removed. The mounting disk has potential to be produced at a low cost, and would
be a low part of the product price.
Figure 4.17: Mounting and removal of hardware.
The hardware user interface is visualised in figure 4.18. It is located on a sloped
surface on the edge of the cylindrical casing, to be visually accessible from multiple
angles. The specific components of the hardware interface are numbered from 1-5
and serve the following purposes:
1. Battery level indicator switch.
2. Battery level indicator.
3. QR code.
4. Power switch.
5. Status indication light.
41
4. Result
Figure 4.18: Hardware user interface control panel description.
4.4.2 Mobile user interface
The mobile user interface was designed primarily for pairing IBC tanks with the
hardware units, but would also have simplified functions from the desktop user
interface. The functions included a simplified analysis tool, inventory navigation,
hardware configuration and management functions. The mobile user interface is
shown in figures 4.19 and 4.20.
Figure 4.19 shows the basic navigation features of the mobile application. This
feature is always accessible to keep track of orientation and progress. Navigation
function includes a menu with a main menu, located at the bottom, buttons for
settings, search and profile located in top of the interface.
Figure 4.19: Navigation in the mobile application.
The main app functions that are presented in Figure 4.20 are log in page, navigation,
analyse, manage and connect.
42
4. Result
Figure 4.20: Mobile application interface.
Log in
The application is accessed through a login page. The option of logging in is nec-
essary based for data security. Companies or different individual users could have
different types of access to data depending on the settings configured by the admin-
istrative user.
Navigate
The landing page of the application is navigate. The user is presented an overview
of all active hardware units on a map. The user can navigate through the inventory
and find an individual or a collection of tanks. The inventory can be navigated in
the following ways:
43
4. Result
Map Navigating through inventory in the map can be useful when many
IBC tanks are spread across different locations.
Text search The search bar is permanently located on the top of the user
interface. A search can be performed by content type, name,
serial number or location. This can be useful in situations when
any of the information is known prior to searching.
Filter input If the search needs to be narrowes, search filters of content type,
filling level, battery level or location can be used
List By scrolling through a list to find a tank could be useful when the
number of tanks is small.
Analyse
The analyse function has basic capabilities of showing current tank status and his-
torical data. The current tank status can be monitored through an indicator box
that was designed to present the most important information about the tank in a
compact space. An example of a status box is shown in Figure 4.21.
Figure 4.21: IBC current status indicator box.
The historical data shown in the analyse section is previous locations, fill level history
, temperature history, battery status and management request history. Unlike in the
desktop version, the mobile user interface is only analyse one IBC tank at a time or
all IBC tanks simultaneously.
Manage
The management function was designed to connect maintenance with management.
Management can request maintenance to be resolved. If a task cannot be executed
44
4. Result
at that specific point in time, it could be rescheduled and the tank status status
would change.
Connect
The connect function serves the purpose of pairing hardware with software. The
process of pairing uses the QR-code scanner or serial number input and has optional
configuration steps to optimise the battery life, security and data output.
4.4.3 Desktop user interface
The desktop user interface was designed to function along the mobile app, and has
similar usability and functionality. The visual identity and navigation principles
were designed to match the mobile application, as this would enhance the user ex-
perience when switching platforms. The main difference between the mobile and
desktop interface is their purpose. The focus of mobile application is to pair new
devices and execute management requests, and the desktop application focus analy-
sis and management. The desktop interface was designed to facilitate analytic tasks
and management operations, benefiting from the larger screen.
Desktop user interface layout
A presentation of the desktop prototype is shown in figure 4.22. The main layout
functions are a navigation bar in the bottom, a selection tool, and a profile icon for
preferences and logging in and out. There is also a search bar, content titles and
spaces.
Figure 4.22: Desktop user interface layout.
45
4. Result
Desktop application sections
The desktop applications has four main sections and several subsections that contain
different functions. The main sections are shown in Figure 4.23. The purposes of
the sections are
Navigate: Locate tanks.
Analyze: Analyze data received from hardware units.
Manage: Send management requests, such as scheduling maintenance, relo-
cation or refills.
Configure Configure the technical specifications of the hardware unit.
Figure 4.23: Desktop user interface sections.
In Figure 4.23 the landing pages of the different sections are shown. The individual
functions of each specific section are specified in Table 4.2. It describes functions
that global to the applications and unique functions in the different sections. A
location description of individual functions is listed to help locating them.
46
4. Result
Table 4.2: An overview table of desktop user interface functions and features.
In order enhance the experience of browsing, a navigation feature for quick data
display was designed. This purpose of this feature is to show highlights of general
information about individual IBC tanks before they are selected for further analysis,
management or configuration. The information is shown in a popup box when
clicking or hovering over a tank object in the map (see Figure 4.24). To the left
of Figure 4.24, the hovering function is shown, and on the right clicking clicking
fuction.
47
4. Result
Figure 4.24: Quick data display function.
A function that was thought to have potential to increase the functionality of the
application was the selection tool (see Figure 4.25). The tool is present globally in
the application, located on the left side of the screen. It is hidden until a selection is
made to not occupy unnecessary space while not in use. It’s principle function was
inspired by the add to cart function that is common in online shopping websites.
Bulk selections are possible and selections can be diverted to specific sections of the
application (see the top of Figure 4.25).
Figure 4.25: Selection tool.
4.4.4 Usability testing
Usability testing resulted in a collection of statements. It was compiled to show the
findings, their level of relevance and categorisation. The result was used mostly to
reiterate the develop and delivery phase and for stating future development oppor-
tunities.
A part of the usability testing result is shown in figure 4.26. The full results can be
48
4. Result
found in Appendix E. In the upper section of the Figure, a row of sticky notes is
arranged to show from which scenario the data originate from. The titles connect
to the statements by colour. for example; all blue sticky notes originate from the
hardware usability scenario. In the figure it is also possible to see the level of
relevance of each statement by looking at their sizes.
Figure 4.26: A usability testing result example from one user.
49
4. Result
50
5
Discussion
The result of the user studies played an important role in this project. By engaging
both engineers from the case company and potential users, a wide variety of state-
ments could be collected. The first part of the interview study was made on already
collected material, and there is a possibility that opportunities were missed. Regard-
less of the limitation, a lot of information came out of the analysis, and contributed
to the result. The second round of interviews were done with two participants, which
gave a limited amount of information. The participants were highly invested in the
process industry and both had long backgrounds in different companies, which gave
high quality to the statements they made. The result would have been more solid
if more participants had been found both rounds of interviews.
The workshop resulted in a large amount of data, with a focus on possible technical
solutions, which provided context to the hardware possibilities. There is also a
possibility that hidden user needs emerged from the engineers knowing the users
from previous project. While the workshop was successful, the process could have
been improved by dividing more time to actual execution of the activity to have
more possibilities for discussing the findings with participants. The benchmarking
was made on four similar solutions from four different companies. This gave a
context to what the state of technology is for the product segment, but did not
reveal any differentiating possibilities. The opportunity identification served as a
good base for designing functions, but could have been extended even more to get
a wider input of information.
The definition, or narrowing down of the identified user needs could have been
more comprehensive. The methodology suggests that the project team rates the
relative importance of needs. The project team consisted of only two individuals,
so the results may have been biased. If the requirements list should be used in
future development, the rating should be remade, with at least five people who are
knowledgeable of the industry.
A conceptual framework emerged from the concept generation. The conceptual
framework quality could be improved through the re-iteration of the user require-
ment prioritisation and rating in the definition phase, as well as with more time
dedicated towards the development. A re-iterated user requirements list would mean
that the base of the conceptual framework would have less bias. With more time
available for development, more concept generation iterations could be conducted
which could have resulted in more ideas.
51
5. Discussion
The prototype only shows a part of the solution. Due to resource and time limita-
tions, only the essential capabilities were presented. A a future opportunity could be
visualising the functions that were not included in the prototype. This could benefit
the presentation quality of the conceptual framework and user requirements. In
addition, the number of iterations in the digital prototyping were few. That meant
that the result from usability testing did not have the opportunity to translate into
changes on the prototype. In potential future development, this could be solved
with more time dedicated towards digital prototype development.
This project aimed to identify and define user needs and requirements for developing
a remote monitoring system for mobile plastic tanks and present them as a concep-
tual solution, focusing on user experience and human factors. By doing this, a set
of research questions would be answered. The question of who the stakeholders are,
in which industries they work and what their needs are was answered by the user
studies, that found most of the stakeholders in the process industry or within the
case company. The needs of user stakeholders were found to focus on ease of use
and visual representation of information from their production.
The answer to the question of what a theoretical framework would look like was
found to be that a systems thinking approach is useful when developing a hard-
ware/software combination, in order to comprehend all connections that need to be
established. The human factors aspects that were found relevant focused on the
visual representations of objects, in form of the gestalt laws. The question of how
the solution could be visualised is answered by the results. The feedback that was
generated from the usability testing and second round of interviews showed that the
visual representation of the concept lived up to what the users would expect.
5.1 Ethical considerations
Assuming the concept that was developed would be implemented in reality, it would
cause some ethical dilemmas that should not be overlooked. As the concept places
itself into the category of automation and digitisation, the topics of workforce being
replaced by robots, increased workforce control, increased necessary screen time
of employees, increased reliance of digital devices and other health considerations
should be reflected upon.
If the system would be implemented, it would likely lead to a reduction in workforce,
as processes as inventory monitoring done manually would be automated. Tasks as
inventory management that previously required several workers would be conducted
by a single worker. Eventually, artificial intelligence could learn repetitive human
input sequences and automatise them, making human labour redundant. This raises
the question if it is ethical to replace human labour with automated processes, leav-
ing unskilled labourers out of work, and subsequently making it harder for people
of low socioeconomic status to find jobs. Since the concept allows for worker being
tracked through GPS data and historical timestamps in the system, it would cre-
ate added stress or feeling of oppression to the workers who are working with the
IBC-tanks. A negative possibility of this would be that workers could become too
52
5. Discussion
controlled by management, leading to bad work environment with health effects on
the workers
Another concern would be the increased reliance on digital devices, as screen time
has negative effects on humans, both physically and mentally. Digital presence in
the workplace directly improves the physical strain on the workforce, an therefore,
it is difficult to tell if digitisation is doing more harm than doing good. The final
concern of implementing concept would be the increased radiation in the immediate
vicinity of the hardware units, as it would be emitting microwaves, Bluetooth low
energy transmission, cellular transmissions and GPS. That could possibly effect the
health of workers spending prolonged time around the system.
5.2 Sustainability
The implementation of the concept could have environmental effects. Some of these
effects might be positive and some negative. The positive ones could be that digi-
tising and automatising tank monitoring and management would lead to materials
being used more efficiently. Material stockpiles would be smaller, less tank content
would be have to be discarded or recycled due to them being expired.
The negative environmental impacts of a system like this are expected to be minimal
relative to the benefits, but they do need to be considered as ecology is one of the
most prevailing necessities of our time as a civilisation. The biggest negative envi-
ronmental impact which this system would bring is through the hardware. Due to
the hardware being technologically complex, it’s construction, recycling or disposal
would leave a footprint in the environment. This footprint would mainly represent
the carbon dioxide emissions which were used when producing and transporting
it. The chemical footprint of the battery and the disposal footprint of components
which cannot be recycled, mainly polymers and electronics, need to be considered.
This could be done by taking a circular approach when choosing components and
designing the business model.
53
5. Discussion
54
6
Conclusion
Radar technology has become smaller and cheaper, which has enabled the develop-
ment of level measurement radars for the variety of mobile plastic tanks commonly
known as IBC tanks. This project followed the double diamond process to develop
a conceptual remote tank monitoring system for IBC tanks. Information about the
market and end user was gathered trough interviews, benchmarking and a workshop
in the divergent Discover phase. The most valuable insights of this phase came from
the benchmarking, where a weakness in the competitor solutions power supply was
discovered.
The information gathered was analysed and transformed into a needs and require-
ments list in the convergent Define phase. The needs were rated, where the most
important needs, and all requirements were displayed in a systems map. The most
important needs and requirement regarded the connectivity, that needs to cover large
areas and have several sources, such as Bluetooth and cellular connection. The sys-
tems map showed the three segments needed for the concept; hardware, software,
their respective user interfaces and external infrastructure.
In the divergent Develop phase, the user needs were conceptualized into a remote
tank monitoring system, based on the systems map. The concept was visualized
in a hardware unit, a mobile interface for simple tasks and a desktop interface for
managing and analysis. The prototypes were evaluated trough usability testing in
the final, convergent, Delivery phase, trough usability testing and interviews. The
usability testing revealed some minor design flaws, such as unrecognizable symbols,
but showed that the prototypes otherwise were easy to understand. The interviews
were conducted with managers of engineering background in the process industry,
who saw great benefit to their processes in some of the features that showed tank
levels and statuses.
The final concept resulted in a comprehensive solution that presents both hardware
and software in a understandable way that is exiting for the end user and highlights
features that would put this concept in the front of its competitors.
For further work, the following activities are recommended:
• The interviews in the Deliver phase was conducted with two individuals, and
need to be extended with more participants from different industry to get a
more comprehensive and reliable result.
55
6. Conclusion
• The rating process of the needs and requirements list was done with focus on
the context of the project, which probably have given led to a bias towards
user experience friendly features. The needs and requirements list should be
re-iterated and the rating should include a broad spectrum of competencies.
• The power supply was found out to be a weakness for this kind of remote tank
monitoring. It now relies in batteries, but more research is needed to improve
the possibilities of a more durable power supply.
• No physical prototype was made of the hardware. In order to ensure that
all technology fits in the housing and that the user interface is functional, a
physical prototype needs to be developed and tested.
56
Bibliography
Arnold, R. D. and Wade, J. P. (2015). A definition of systems thinking: A systems
approach. Procedia computer science, 44:669–678.
Basadur, M., Pringle, P., Speranzini, G., and Bacot, M. (2000). Collaborative
problem solving through creativity in problem definition: Expanding the pie.
Creativity and Innovation Management, 9(1):54–76.
Checkland, P. (1999). Systems thinking. Rethinking management information sys-
tems, pages 45–56.
Fagerberg, J. (2020). The Global Remote Tank Monitoring Market. Berg Insight,
Gothenburg. Retrieved from: http://www.berginsight.com.
Haiyan, W. and Baozhu, Y. (2011). A definition of systems thinking: A systems
approach. volume 1, pages 395–398. IEEE Xplore Digital Library.
Hollnagel, E. (1997). Cognitive ergonomics: it’s all in the mind. Ergonomics,
40(10):1170–1182.
Knight, W. (2019). UX for Developers: How to Integrate User-Centered Design
Principles Into Your Day-to-Day Development Work. Apress.
Kurt, O. E., Ucler, C., and Vayvay, O. (2017). From ideation towards innovation:
pillars of front-end in new product development. PressAcademia Procedia, 5(1):71–
79.
Kvale, S. (2007). Doing Interviews. SAGE Publications, Ltd, London.
Köhler, W. (1920). Die physischen gestalten in ruhe und im stationären zustand -
gestaltprobleme und anfänge einer gestalttheorie (Übersichtsreferat). Published
in Jahresbericht über die gesamte Physiologie (1922) pp. 512ff. Berlin, Julius
Springer.
Lee, J. D., Wickens, C. D., Yili, L., and Linda Ng, B. (2017). An introduction to
human factors engineering (3rd edition). CreateSpace, Charleston.
Mahmoud, M. S. and Mohamad, A. A. (2016). A study of efficient power con-
sumption wireless communication techniques/modules for internet of things (iot)
applications.
McLeod, R. W. (2015). Designing for Human Reliability : Human Factors Engi-
57
Bibliography
neering in the Oil, Gas, and Process Industries. Elsevier Science & Technology,
Oxford.
Mitchell, R. K., Agle, B. R., and Wood, D. J. (1997). Toward a theory of stakeholder
identification and salience: Defining the principle of who and what really counts.
Academy of management review, 22(4):853–886.
Palmer, S. E. (1992). Common region: A new principle of perceptual grouping.
Cognitive Psychology, 24:436–447.
Perrucci, G. P., Fitzek, F. H., Sasso, G., Kellerer, W., and Widmer, J. (2009). On
the impact of 2g and 3g network usage for mobile phones’ battery life. In 2009
European Wireless Conference, pages 255–259. IEEE.
Plattner, H., Meinel, C., and Leifer, L. (2012). Design thinking research. Springer.
Proctor, R. W. and Proctor, J. D. (2012). Sensation and perception. In Salvendy,
G., editor, Handbook of Human Factors and Ergonomics, pages 59–89. John Wiley
& Sons.
Rock, I. and Palmer, S. (1990). The legacy of gestalt psychology. Scientific Ameri-
can, 236:84–90.
Rosenzweig, E. (2015). Successful User Experience Strategies and Roadmap. Elsevier,
Waltham.
Rubin, E. (1915). Synsoplevede figurer. studier i psykologisk analyse. første del.
Copenhagen and Christiania: Gyldendalske Boghandel, Nordisk Forlag.
Shneiderman, B., Plaisant, C., Cohen, M. S., Jacobs, S., Elmqvist, N., and Di-
akopoulos, N. (2016). Designing the user interface: strategies for effective human-
computer interaction. Pearson.
Shun, T. and Kosuke, I. (2010). A use of subjective clustering to support affinity
diagram results in customer needs analysis. Concurrent Engineering: Research
and Applications, 18(2):101–109.
The Design Council (2015a). Innovation by de-
sign. Design Council, London. Retrieved from:
https://www.designcouncil.org.uk/sites/default/files/asset/document/innovation-
by-design.pdf.
The Design Council (2015b). TWhat is the framework for innova-
tion? Design Council’s evolved Double Diamond. Retrieved from:
https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-
design-councils-evolved-double-diamond.
Ulrich, K. T. and Eppinger, S. D. (2012). Product Design and Development.
McGraw-Hill.
Watanabe, K. and Shirasaka, S. (2021). Designing a framework for sustainable
content communication considering ux on the content lifecycle for non-professional
personnel. Review of Integrative Business and Economics Research, 10(1):69–90.
58
Bibliography
Wertheimer, M. (1923). Untersuchungen zur lehre von der gestalt. ii. Psychologische
Forschung, 4:301–350.
Wikberg Nilsson, Å., Ericson, Å., and Törlind, P. (2015). Design - Process och
Metod. Studentlitteratur, Lund.
59
Bibliography
60
A
Appendix 1
Appendix 1 contains the table of requirements (see Table A.2). The colors used in
some cells are explained in Table A.1 Number 12, 32, 35 and 106 were identified to
be requirements, the rest were considered needs..
Table A.1: Description of color meanings in the requirements table.
Green Need discovered from interview study
Yellow Need discovered from workshop
Red Need discovered from benchmarking
Blue Need discovered from other sources
I
A. Appendix 1
II
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
2 Business model
3 No fuss business model so that engineers 3 1 2
doesn’t need to fight purchasers
4 System for selling subscribtions 3 1 2 Seems so
5 Business model for customers to be dis- 1 1 1
tributors of hardware
6 Marketplace for raw materials 2 3 2.5
7 Marketing
8 Clear marketing, visibility to customers 2 1 1.5
needed
9 Safety can be higher withn alarms. Qual- 2 3 2.5
ity can be higher with monitoring
10 Sensory measurments
11 Temperature (Ambient/Process) 3 3 3 Yes, -20- Yes (A) Yes (A) Yes (A)
60°C (A&P)
12 Level R R R Yes, 0-15m Yes Yes Yes, strain
gauge
13 Location 3 3 3 Yes, +/- Yes Yes Yes
20m
14 Vibration 3 2 2.5 No No Yes No
15 tilt 3 3 3 Yes, 0-180° No Yes No
16 Device position on IBC 3 3 3 Yes
17 Device status 2 3 2.5 Yes
A. Appendix 1
III
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
18 Alarms
19 Dangerous trends 3 3 3 Yes
20 Leakage 3 3 3
21 Near empty 3 3 3
22 Overfilling 1 1 1 Yes Yes
23 Low battery 3 3 3 Yes, light Yes
24 Tilt 2 3 2.5 Yes
25 Strange movement (time/location) 2 3 2.5 Unit not Theft pro-
safe for tection
transport
26 Temperature 3 3 3 Yes Yes Yes
27 Low stock 3 3 3
28 Clean antenna 1 1 1
29 Connectivity
30 Connectivity options 1 1 1 Mobile data, e-sim,
radio radio, NB-
IoT,LRWAN
31 Enabling customer to use their own com- 2 1 1.5 Yes
munication infrastructure
32 Wireless option R R R Yes Yes Yes Yes
33 Option for no cloud 2 1 1.5 No No
34 Option for wire data transfer 2 1 1.5 No No No
35 Connectivity area needs to be large R R R Yes, mobile Yes Yes
data/radio
A. Appendix 1
IV
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
36 Safety
37 Applicable for safety standards in diferent 1 1 1 Yes
industries
38 Data for safety should apply with regula- 1 1 1 Yes
tory entities (and neighbours)
39 ATEX rating (is crucial for flammables) 1 1 1 No No Yes
40 Turn off radar where it is not allowed to 2 3 2.5 Patent
measure (geofence) ?
41 Geofencing 3 3 3
42 Maintnance
43 Easy, preferrable automatic calibration 2 3 2.5 Yes
44 Data for optimizing maintnance schehule 3 3 3 No Repairs
45 Minimizing labour
46 System for automatic rounds on lube oil 2 3 2.5
47 Radar measuring would decrease the need 3 3 3
of moving IBCs while counting inventory
48 Less calibration and less messes 3 ? 3
qq System for automation on simple pro- 1 1 1
49 cesses
50 Hardware
51 Handheld system 2 ? 2 No No No No
52 Need some IP classification for water- 3 ? 3 IP66, IP68, IP69
proofing NEMA
4X/6P
A. Appendix 1
V
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
53 Measuring on emulsified oil/water mix 1 1 1
54 Needs to work with splashing and foaming 1 1 1
products
55 Needs to work on grease separating sys- 3 2 2.5
tems
56 Needs to work with steaming products 1 1 1
57 Universal system for all viscosities 1 3 2
58 GPS dormant while not in move 3 3 3
59 Reusable 3 3 3
60 Simple mounting 3 3 3 Thread, Adheisive, Tape/carrier Yes
ceiling/wall, ceiling, belt plate
IBC
61 Simple removal 3 3 3 Yes No, Sin- Yes
gle use
adhiesive
62 Not hinder stacking IBCs 3 3 3 Yes Yes Yes Yes
63 Re-attatchable 3 3 3 Yes Depends Yes Yes
64 Plug and play 3 3 3 No Yes Yes Yes
65 Visual localisation of radar unit 2 3 2.5
66 Automatic calibration 3 3 3 Yes
67 Save battery trough optimized data send- 3 3 3 Kind of
ing
68 RFID/NFC 2 3 2.5 some NFC
function
A. Appendix 1
VI
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
69 Battery indication 2 3 2.5 When low
70 Scanner 1 ? 1
71 Option for threaded mounting 2 ? 2 Yes No (But No No
have other
solutions
72 High accuracy 3 3 3 +/- 10 mm +/- 5mm 100 l
73 Process temperature 2 2 2 -20 - +60 °c -20 - +60 °c
74 Systems data exchange
75 Forklift/logistics 3 3 3
76 Work orders for production 1 3 2 Supports Yes
tickets
77 Automatic work orders for maintenance 3 3 3
78 Automatic connection to first responders 2 3 2.5
to minimize the effects of accidents
79 Connected to recipe system and business 2 2 2
system
80 Level data available to both subscriber 1 2 1.5
and supplier
81 Out data compatible with different sys- 3 2 2.5 No No
tems
82 Connection with tank emptying compa- 2 1 1.5
nies for oil sepatators
83 Connect with current backoffice 2 1 1.5 Yes
84 Custom mesurement intervals 3 3 3 ?, 1min-8h <{}5 s
A. Appendix 1
VII
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
85 Custom transmission intervals 3 3 3 15 min - 24h 15 min - 24
h (when or-
dering)
86 Radars can "talk" to eachother 2 3 2.5
87 Connect specific IBC to specific radar 2 3 2.5
88 FTD standard data excahnge 3 3 3 Yes
89 Data visuals
90 Options for different measurment units 3 3 3
91 Visual of volume left 3 3 3
92 Needs to make differens between many dif- 3 3 3
ferent contents (200+)
93 Bird wiew on IBCs (with content could be 2 3 2.5
sufficient in some cases)
94 Accuracy in both length and litres 3 3 3
95 Fast/live updates for quicker fills 1 2 1.5
96 Radar battery health 2 3 2.5
97 3D visual of tank fleet 2 2 2
98 Forecast on stock/levels 3 3 3 Yes
99 Cellular connection strength 2 3 2.5
100 Agumented reality options 1 3 2
101 All radar units on a map 3 3 3
102 Tank free capacity and fill level 3 3 3 Yes
103 Update frequency 2 3 2.5
104 BBF-date monitoring 1 3 2 Yes
A. Appendix 1
VIII
Table A.2: Requirements table.
Need R1 R2 Avg E&H Vegaplus air Packwise Nanolike
Micropilot 23
FWR 30
105 Battery
106 Battery R R R D, change- 2 x LS 17500 Probably Yes
able
107 Energy harvesting 3 1 2 No No
108 Wireless charging 3 1 2 No No
109 Long life 3 3 3 ∼140 days/- 6/18mo on 6 years
max usage max usage
110 Simple battery change 3 3 3 Yes No
111 System, general
112 Open API 1 1 1
113 Built in web server 1 1 1
114 Compatible with non RTR radars 2 1 1.5
115 Automatic software updates 3 3 3 Yes
116 Relevant info for user depending on role 2 3 2.5
117 Desktop, mobile and tablet 3 3 3 Yes Seems so
118 Automatic configuration 3 3 3
119 App store 2 3 2.5
120 Key-chain for unit passwords 1 1 1 Yes
B
Appendix 2
Appendix 2 contains the software user interface tree diagram which was only par-
tially shown in the definition phase part of the results chapter. It is presented in four
parts. Part 1 (figure B.1)contains UI features related to Navigation section, part 2
(figure B.2) presents the Analyse section features, part 3 (figure B.3) the manage-
ment user interface section, and part 4 (figure B.4) the configuration section.
Figure B.1: Part 1 of appendix 2: Function diagram of the Navigation section of
the user interface
IX
B. Appendix 2
Figure B.2: Part 2 of appendix 2: Function diagram of the Analyse section of the
user interface
X
B. Appendix 2
Figure B.3: Part 3 of appendix 2: Function diagram of the Manage section of the
user interface
Figure B.4: Part 4 of appendix 2: Function diagram of the configure section of
the user interface
XI
B. Appendix 2
XII
C
Appendix 3
In Appendix 3 the interview guide, the collected statements and analysis is pre-
sented.
Introduction of us
• Who we are
• What we study
• Thesis project about tracking IBC tanks
• We collect information on how industries are using IBCs in order to develop
an user interface
• Anonymity and masking of companies
• Consent of study and recording
Introduction of them
• Name and position
• Time in industry
• Are they aware of IBC use in their organization?
• Choose questions based on that
• If there are IBCs but no knowledge – Ask for connections in the end of interview
Introduction on their industry and plant
• What are they producing?
• In what quantity, absolute and in relation to competition
• Do they operate in shifts?
• What real dangers are there if anything goes wrong?
• Do you have any examples?
• Are there moving restrictions for goods on your plant?
XIII
C. Appendix 3
Introduction on their system
• How do you track tanks/levels (of any kind) today?
• What is your opinion on your system?
• Can a layman use them, or what is the learning time? Do you need to be an
engineer?
• Is this a universal system or specifically design for your application?
Questions on IBCs
• How many do you have at one point?
• How many are full/empty?
• Do you use all content in one run, or need to change them without being fully
empty?
• How do you store them? Are they stacked?
• How do you know whats in the middle?
• How do you keep different contents apart?
• Can you think of a production line where you use content from an IBC?
• How is it indicated that content in the tank is running low?
• Can you describe the flow of the new tank from the moment of notification of
low levels until the tank is changed?
• What happens to the empty tank? Is there waste?
• If an operator or driver took the wrong tank with the wrong content, is there
any way of noticing that?
• What would the consequences be?
XIV
D
Appendix 4
In appendix 4 statements and analysis of the interview studies are presented.
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
Business model
Have no direct opinion on Engineer not interested in No fuss business model
how they would be bought business model for purchase so that engineers doesn’t
(radar) of RTM product need to fight purchasers
The general comment was Customers see IBCs as dis-
that IBC/barrels were not posable packaging of raw ma-
something they or customers terial
would be super interested in
today.
Raw materials Are often or- IBCs are usually sold many
dered at Bulk at the same time
However, the company rents Some industries sell their raw System for selling sub-
out 15-30 cubic tanks to a material on subscription scriptions
number of customers, which
today typically includes a
radar
This is then connected in Uses GSM for radar connec-
some way to a GSM module tivity
that allows someone at Com-
pany A to have access to the
level to ensure that the cus-
tomer has enough in the tank.
Thus, Company A (alt cus- Plans logistics with radar Measurement data need
tomer) has level measure- data to be able to get in to
ment of the customer’s tank business system
which is then read by Com-
pany A to plan shipment of
product
XV
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
There is potential if they Company would like to own Some customer would
could be owned by Company their system and retail it to like to sell their own sys-
A altogether, which would their customer tem
also promote that the solu-
tion could be sold to more
customers
Has any system on any tank, Company have subscription
which measures the tanks raw material with GSM con-
and sends data via GSM to nected level meter
the supplier who will
On their tanks with nitro-
gen, they have some con-
nected system that the sup-
plier has. They think they
bought a package that there
is always nitrogen, and then
the customer has their level
meter on the tank.
Security
Imposes requirements on, Safety requirements on pack-
for example, packaging, la- aging for hazardous materi-
belling, where to place them als. Can not be placed any-
on the transport where during transportation
Leakage, etc., is super impor- No leaking is crucial Leaking detection
tant from the packaging.
Specially certified packaging Not every container is in- Leaking detection for en-
is used, but at the same time spected tire fleet
not every single container is
checked.
But they seem to know that Unaware of leakage detecting Clear marketing, visibil-
there are sensors today to de- technology ity to customers needed
tect
despite safe packaging, they Approved packaging do Leaking detection is not
sometimes leak sometimes leak useless
Temperature requirements There are requirements for Temperature sensor
exist for certain products/- temperature measurement on
transport methods some raw materials and some
transportation methods
XVI
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
Some tanks also have GPS GPS is used to make sure GPS tracking and alarms
transmitters to prevent them tanks does not get stolen or
from disappearing (however, misplaced
there are no legal require-
ments)
There are no direct auto- Currently no automatic Automatic connection
matic alarms in case of ac- alarms for hazardous ma- to first responders could
cidents today, but there are terials being involved in minimize the effects of
routines and protocols for accidents. There are pro- accidents
how they should be handled tocols on how to handle
when the call arrives accidents
sensors were connected to a There are sensors connected
global alarm system for cer- to alarms for some hazardous
tain types of hazardous prod- materials that alert if some-
ucts that alert you if you no- thing is off
tice something
General benefits from this are Safety can be higher with
mainly safety, possibly qual- alarms. Quality can be
ity and Customer can see higher with monitoring
safety benefits from contin-
uous monitoring. Can see
monitoring quality as a pos-
sible use
the biggest challenge is that ATEX rated security systems ATEX rating is crucial
everything should be Atex needed for flammables in pro- for flammables
rated (solvent is flammable, duction, but maybe not in
both zone 1 and zone 2, storage.
mostly 1 however) are needed
in production (not necessar-
ily outside thereby)
Looking for temperature/vi- ATEX rated security system Vibration sensors
bration sensors with ATEX for monitoring vibration and
– want info. Want to keep temperature. Monitors some
track of their mixing ma- machines with high frequency
chines with relatively high
frequency
However, they receive the Customer can see level of Level data available to
level value in their System c chemical that they subscribe both subscriber and sup-
if the supplier’s system does to, and can alert supplier if plier
not alarm and they deliver they do not refill
XVII
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
(Cyber security) Doesn’t Do not need to bother about Security standards differ
seem super critical. Often cyber security
the supplier seems to have
their own sensor that they
read, they have no connec-
tion to their sensor/System c
(4-20 mA)
Typically think they are not Facility typically not security Not all of facility needs
rated, but could be there at classed, but maybe receiving security classing
unloading areas logistics area
Do not have an ex- Facility not classified for haz- Neighbors mind security
classification, but all ard, but raw materials are. to a higher degree than
products they have after Neighbours do mind, facility
all. Their neighbours are
said to have demands for this
Required to have over filling Some system need over filling Over filling protection is
protection protection required on oil separation
systems
Applications IBC
Gets some raw materials on IBCs are used for raw mate-
IBC, but not much. Mainly rials and internal logistics
from other Company A sites
Filling raw materials at IBC Deliver product in IBCs
However, do not see that cus- Do not see their customer
tomers would typically have needing monitoring of the
to measure the level of these product they sell
as their goods are often used
in larger quantities even if
they are shipped on IBC
They have recipes designed IBCs are a standardised
based on that size, you usu- packaging
ally use an IBC and/or a bar-
rel
Has between 100-200 differ- 100-200 different contents in Needs to make difference
ent raw materials for these IBCs on site between many different
smaller vessels contents
They also fill their finished Deliver product in IBCs
product on IBC tanks
Those who end up in the IBC Only sell in IBCs for pre-
go directly to the customer orders
against an order
XVIII
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
It is emptied by lifting by The IBC is carried by a fork- Forklifts need to see in-
forklift where you open the lift in production. The crane formation.
crane (so it really has to be is opened manually
mobile)
Taking things into IBC’s, like Buying additives to raw ma-
additives terial in IBCs
Connectivity
Today, there is an external 2rd party management of Owning the communica-
party that handles wireless wireless communication is tion system is optimal
communication, which is not not optimal
considered optimal
Generally likes wireless Wireless is good Prefers wireless systems
Company B has some prefer- Wireless is regulated. Cloud Non wireless, cloud free
ences around wireless, ban on is banned solution is essential
cloud services, etc.
If they can be from a "stan- Would like to be able to Need option for wired
dalone" device, they should transfer data from mobile data transfer
be okay, like they go to the unit to computer to avoid
iPad and then emptied manu- wireless transmission
ally via type USB stick to the
computer and into the system
Range needs to be >50m Needs to be able to connect Connectivity area needs
over large areas to be large
forks connected with System Their forklifts use a system Needs to apply with fork-
A digitally for logistics orders lift logistics systems
Does not need to be wire- Do not require wireless. Vi- Uses red as a visual warn-
less, today goes to a System sual, red box for warnings ing color.
B system with a red box that
warns etc.
Use situations
A typical place was some Measures on grease separa- Needs to work on grease
grease/water separation tank tors before sent for cleaning separating systems
before water was shipped for
cleaning (environmental re-
quirements).
some radars on steam forma- Use radars on liquids that Needs to work with
tion steam steaming products
Most often they are carried Measures volumes with a Less calibration and less
out today on a scale. Do not scale that has to be cali- messes
like the scale so much due to brated. Create mess and fails
calibrated. Dirty and they go sometimes
wrong
XIX
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
They have also used volume Can use volume pump for low Universal system for all
via pump (DP flow, 400/l per viscosity products viscosities
minute), but they are neg-
atively affected by a pump
cavorting with high viscosity
products
as I said, would be willing to Could use a hand held sys- Handheld system. Con-
measure the emptying of an tem for measuring the emp- nected to recipe system
IBC into the production tank tying of a tank to production. and business system
with a handheld radar unit Could be connected to stock-
which in turn is connected /recipe system
to the computer system with
stock/prescription
Sees the possibility of a hand- Likes to see volume left. Visual of volume left
held device that you can use Could be use for making
to record how many liters you batches in process
have left. Perhaps used for
betting in the process
Has a project at G within Eu- Could use sensors to decrease Connection to system for
rope that is run via City A manual rounds rounds do minimize man-
where you "remove work that ual labor
does not create value" type
manual rounds. Should bring
in many sensors to solve this,
typically "wireless" sensors.
There are also deposit tanks Uses IBCs as deposit for
for lab samples etc. on un- throw away liquids
loading
Also has an application with Do have manual processes System for automation
salt + water mixture that is that could be more automa- on simple processes
more or less working. Today tized
not automated, but deemed
"simple" and one could use
"simple radar"
XX
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
The new wireless they are Uses different systems for dif- Out data compatible
looking at (mainly pres- ferent raw materials with different systems
sure/temp) will enter the
System c for process data.
Lubeoil, on the other hand,
is a little more into whether
they are going into the
AMS and not in the control
system.
Got tanks for the sewer sys- Use IBCs for oil separating in Alarms on dangerous
tem. Tanks are buried and in the sewage system. Only had trends
basements. Have alarms on catastrophe alarms
them today, but then they’re
too late
Could also detect leaks if they Could use trending data to Trends to detect leakage
can trend detect leakage
Depending on the position it Sensor may be under water Need some IP classifica-
sits, it may end up underwa- for prolonged times tion for waterproofing
ter (groundwater may end up
above tank level), today’s sit-
ting on a pipe to remove the
electronics
Raw materials/products
their paint is like liquid met- Their product needs heating Temperature sensors
als (very thick) – heat is to be less viscous
needed to keep them afloat
Probably they don’t splash so some products do not splash Needs to work with
much (high viscosity) and no due to viscosity, and do not splashing and foaming
foam foam products
Inventory
The only check will therefore Checks inventory 1-2 timed a
be 1-2 times per year that you year
inventory
Carry out rounding to check Rounding for lube oil
lube oil
Think they’re manually keep- Manual tracking of some raw
ing track of additives materials
For lube oil, you manually Manual tracking of some raw System for automatic
check in sieve glass. materials trough measuring rounds on lube oil
in glass
XXI
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
Inventories three times/year Counts inventory 3 times a Radar measuring would
with scale. Taking an after- year trough weighing decrease the need of mov-
noon. ing IBCs while counting
inventory
Have visual system on the Use a visual system for track-
IBC’s to see approximately ing inventory in IBCs
how much they are
Practicalities
The accuracy they seek is at Accuracy in liters Accuracy in L
a litre level
They do not go super fast Filling is slow Fast/live updates for
when they fill, take maybe 2- quicker fills
15 minutes.
Typically not stacked. Do typically not stack IBCs Bird view on IBCs with
Empty stacks. unless empty content could be suffi-
cient in some cases
A few centimetres. So you Centimeter accuracy. Need Accuracy in cm. Alarm
don’t go "dry" to not run dry when nearing empty
Maintenance
Do not have an automated Have no automation on their Automatic work orders
system for this. However, maintenance for maintenance
they wish for
Perform maintenance of all Checks level meters yearly by Easy, preferable auto-
meters once a year by man- dipping method matic calibration
ual "dipping"
Sucks oil layer every 6 Do not receive alarms from Continuous level measur-
months, therefore they oil separators trough sched- ing could optimize main-
have also not received any uled maintenance tenance schedule
warnings/alarms
Every two weeks, they Regularly confirms that their Minimize extra work
measure in samples of the oil separators work by con- on testing waste water
wastewater trolling waste water trough leakage monitor-
ing on oil separation
Visuals
Would like an external dis- Likes to be able to have dis- Forklift system applica-
play in the truck (type iPad), plays in forklifts tion
such displays have in produc-
tion today
XXII
D. Appendix 4
Table D.1: Table of statements and interpretations from the case company inter-
views.
Statement Interpretation Need
At least in System c, but if Getting work orders to other Connection to the system
they could show up in the system would be nice that create work orders
maintenance system to trig- for logistics and produc-
ger a work order, they’d be tion
partying.
Sees interest in its 4 oil Likes to see trends to manage Trend data to see if levels
separators (Company C and emptying of tanks go up too fast. Data in
Company D), 70mm warning, mm
150mm alarm. Would like to
see earlier and see if they go
"fast" up
Wishes need
See interest in seeing wa- Emulsion between oil and wa- Measuring on emulsified
ter/oil measurement, but ter makes it difficult to see oil/water mix
they become an emulsion level of oil
XXIII
D. Appendix 4
Interview 1
Figure D.1: Analysis of interview 1 part 1.
XXIV
D. Appendix 4
Figure D.2: Analysis of interview 1 part 2.
XXV
D. Appendix 4
Figure D.3: Analysis of interview 1 part 3.
XXVI
D. Appendix 4
Interview 2
Figure D.4: Analysis of interview 2 part 1.
XXVII
D. Appendix 4
Figure D.5: Analysis of interview 2 part 2.
XXVIII
D. Appendix 4
Figure D.6: Analysis of interview 2 part 3.
XXIX
D. Appendix 4
XXX
E
Appendix 5
In appendix 4, the rest of the user testing results can be found, which were not
presented in the results chapter of the report due to insufficient space. The first of
two parts of results is presented in figure E.1 and the second in figure E.2. The figure
include separating lines which run horizontally across the sticky note configuration
in order to maintain from which participant the sticky notes have originated from.
The utility in this was to confirm that overlapping findings were not coming from
the same source subject.
XXXI
E. Appendix 5
Figure E.1: User testing results part 1 of 2.
XXXII
E. Appendix 5
Figure E.2: User testing results part 2 of 2.
XXXIII
E. Appendix 5
XXXIV
F
Appendix 6
Appendix 6 contains the full workshop data result which was sorted by the KJ-
analysis method. It is presented in figures F.1, F.2 and F.3.
XXXV
F. Appendix 6
Figure F.1: Workshop results part 1 of 3.
XXXVI
F. Appendix 6
Figure F.2: Workshop results part 2 of 3.
XXXVII
F. Appendix 6
Figure F.3: Workshop results part 3 of 3.
XXXVIII
DEPARTMENT OF INDUSTRIAL AND MATERIALS SCIENCE
CHALMERS UNIVERSITY OF TECHNOLOGY
Gothenburg, Sweden
www.chalmers.se