Visualization of Vehicle Usage Based on Position Data for Root-Cause Analysis

(1)

Master Programme in Human-Computer Interaction

Department of Informatics and Media

Examensarbete

Visualization of Vehicle Usage

Based on Position Data for Root-Cause Analysis

A Case study at Scania CV AB

by

Ramadhan Kurniawan Sagala

2018-05-28

Uppsala Universitet

(2)

Uppsala Universitet

Master Programme in Human-Computer Interaction

Examensarbete

Visualization of Vehicle Usage

Based on Position Data for Root-Cause Analysis

A Case study at Scania CV AB

by

Ramadhan Kurniawan Sagala

2018-05-28

Handledare: Lina Eklund Examinator: Annika Waern

(3)

Abstract

Root cause analysis (RCA) is a process in Scania carried out to understand the root cause of vehicle breakdowns. It is commonly done by studying vehicle warranty claims and failure reports, identifying patterns that are correlated to the breakdowns, and then analyzing the root cause based on those findings. Vehicle usage is believed to be one of the factors that may contribute towards the breakdowns, but the data on vehicle usage is not commonly utilized in RCA.

This thesis investigates a way to help RCA process by introducing a dataset of vehicle usage based on position data gathered in project FUMA (Fleet telematics big data analytics for vehicle Usage Modeling and Analysis). A user-centered design process of a visualization tool which presents FUMA data for people working in RCA process was carried out. Inter- views were conducted to gain insights about the RCA process and generate design ideas.

PACT framework was used to organize the ideas, and Use Cases were developed to project a conceptual scenario. A low fidelity prototype was developed as design artifact for the visualization, and a formative test was done to validate the design and gather feedback for future prototyping iterations.

In each design phase, more insights about how visualization of vehicle usage should be used in RCA were obtained. Based on this study, the prototype design showed a promis- ing start in visualizing vehicle usage for RCA purpose. Improvement on data presentation, however, still needs to be addressed to reach the level of practicality required in RCA.

Sammanfattning

Root cause analysis (RCA) är en process på Scania som används för att förstå rotorsaken till fordons behov av reparation. Oftast studeras fordonets försäkringsrapporter och felrap- porter, för att identifiera och analysera mönster som motsvarar de olika behoven för reparation. Fordonsanvändningen tros vara en av de faktorer som bidrar till reparationsbehoven, men data angående detta används sällan i RCA.

Denna rapport undersöker hur RCA-processen kan dra nytta av positionsdata som sam- lats in i projekt FUMA (Fleet telematics big data analytics for vehicle Usage Modeling and Analysis). En användarcentrerad designmetodik har använts för att ta fram ett visualiser- ingsverktyg som presenterar FUMA-data för personer som deltar i RCA-processen. Inter- vjuer har genomförts för att samla insikter om RCA-processen och för att generera desig- nidéer. PACT-ramverket användes sedan för att organisera idéerna, och användningssitua- tioner togs fram för att skapa ett konceptuellt scenario. En low-fidelity prototyp togs fraför personer som deltar i RCA-processenm som en designartefakt för visualiseringen och ett utvecklande test genomfördes för att validera designen och samla in feedback för framtida iterationer av prototyping.

Under varje design-fas, samlades mer insikter om hur visualiseringen av fordonsanvänd- ning skulle kunna användas för RCA in. Baserat på detta, visade design-prototypen en lo- vande start för visualisering av fordonsanvändning i RCA. Förbättringar på hur data presen- teras måste dock genomföras, så att rätt genomförbarhet för RCA uppnås.

(4)

Acknowledgments

I would like to express my heartfelt gratitude to all the parties that have supported me in throughout this thesis. Many thanks to my supervisors in Scania: Sarah Hantosi Albertsson and Gustav Rånby, and also Sara Sylvan for all the help and guidance. I would like to thank my reviewer in Uppsala University, Lina Eklund, for all the feedback and counsel. I also thank my examiner, Annika Waern, for her comments and suggestions that have helped me improve this thesis. I would like to thank Scania and all the employees who had participated in this study. Last but not least, I would also like to thank Swedish Institute Study Scholar- ship for supporting me during the whole master program.

Finally, I dedicate this thesis work to my beloved wife Aidilla Pradini.

(5)

List of Figures

2.1 Example of dot distribution map . . . 6

2.2 Example of choropleth map . . . 6

2.3 Example of graduated symbol map . . . 7

2.4 Example of cartogram . . . 7

2.5 "A New Chart of History" by Robert Priestley (1765) . . . 8

2.6 Interactive visualization process . . . 9

3.1 Overview of the thesis process. . . 11

4.1 Root cause analysis problem definition. . . 18

4.2 Data used in root cause analysis. . . 19

4.3 Overview of root cause analysis process. . . 24

4.4 Use case diagram of the visualization tool. . . 26

5.1 Paper and pen prototypes. . . 31

5.2 Prototype starting page. . . 32

5.3 Prototype: data input wizard (top: empty, bottom: populated). . . 33

5.4 Prototype: data populated on the map. . . 34

5.5 Prototype: compare vehicles by population. . . 35

5.6 Prototype: compare individual vehicles. . . 36

5.7 Prototype v2: changes on labeling. . . 39

5.8 Prototype v2: data loaded on the map. . . 39

5.9 Prototype v2: compare population. . . 40

(8)

List of Tables

2.1 Graphical techniques for thematic maps . . . 5

3.1 Comparing four types of usability testing[Rubin2008] . . . . 13

4.1 Insights about FUMA data . . . 16

4.2 Insights on RCA problem definition . . . 17

4.3 Insights about data used in RCA . . . 20

4.4 Insights about common types of root causes . . . 20

4.5 Insights about Field Quality Engineers . . . 22

4.6 Insights about Field Quality Analysts . . . 22

4.7 Overview profile of field quality engineer and analyst. . . 23

4.8 Insights about RCA workflow . . . 24

4.9 Insights leading to UC-01 . . . 25

4.12 Insights leading to UC-04, UC-05, and UC-06 . . . 28

(9)

1 Introduction

1.1 Background

The study of human-computer interaction (HCI) started as an effort to incorporate cognitive science and human factors engineering into computer science study, in order to improve usability of computers [7]. Over the years, HCI has expanded and become an interdisciplinary study that lies in the intersection of computer science, behavioral science, design, visualization, and many other fields of study. This thesis work is an example of how two important areas of HCI, user-centered design and data visualization, can help users generate important insights from a big amount of data, through a case study carried out at Scania, a major manufacturer of commercial vehicles.

Like all machines, vehicles will face failures at some point in their lifetime. Some types of failures are commonly known failures which can be easily analyzed and fixed. However, there are some failures that happen beyond expectation. To make sure that these kinds of problem do not appear in the future, there is a need to understand the root cause of the failure. Scania addresses this issue by having a formal Root Cause Analysis (RCA) process.

Currently, RCA is commonly based upon finding patterns through the compilation of vehicle warranty claims and failure reports. This process is effective to single out internal factor, i.e. changes in the vehicle structure that may cause the breakdown. However it is believed that external factors such as vehicle usage play a part in causing vehicle failure in some cases. Therefore, any data that could explain this factor could give an extra insight to help the RCA process.

Enter FUMA, short from Fleet telematics big data analytics for vehicle Usage Modeling and Analysis. Scania has a massive number of vehicles sending in position data continuously as part of Scania Connected Services[17]. This position data is the most important part of the telematics data used by FUMA project to develop models of vehicle usage, as the name suggested. This study explores how the information gathered from geospatial data in FUMA project could be visualized so that it could be easily understood by people involved in RCA.

This visualization is expected to provide insight about the external or operational factor that may contribute to a vehicle breakdown, and hopefully would be useful as an additional di- mension to the RCA process.

The data must be presented in a manner that is relevant to the RCA process and easily understandable by the engineers working on RCA. In order to achieve this, Two things need

(10)

1.2. Motivation

to be understood: the structure of FUMA data and the way-of-working of Scania’s RCA process. A visualization based on FUMA data then needs to be designed according to the needs of RCA process. Then, a visualization tool that assists root cause analysis process needs to be proposed.

1.2 Motivation

The main motivation of this study is to create an added value within a company based on big data initiatives it already has. Scania has already managed to collect a vast amount of position data from its vehicles and done extensive research to build models and analytics on this data.

It is reasonable that the next step should be making the data useful for critical processes in the company. One of the processes is the root cause analysis, which has been chosen as a case study for this thesis.

1.3 Aim

The aim of this study is to propose a design of a visualization tool which presents data from Scania’s FUMA project in a way that is useful for Scania engineers and analysts during root cause analysis process.

1.4 Research questions

1. How can visualization of vehicle usage based on position data help in root cause analysis process?

2. How can we design a visualization tool which presents FUMA data for people working in RCA process in a user-centered approach?

1.5 Delimitations

• This study is conducted at Scania. Therefore the data used in this work is owned by and specific to Scania, and the target users are assumed to be exclusively Scania employees.

• The work is limited to the data provided by FUMA project.

• This thesis work is an exploratory study. The work does not present a solid case where FUMA data actually helps RCA process.

• The proposed design of the visualization tool is a low fidelity prototype.

• The prototype will be used to validate ideas of whether the data would be useful or not.

Hence, animation and more sophisticated visualization techniques will not be included.

(11)

2 Theory

This chapter presents brief explanations about theories that are relevant to the thesis. The chapter is organized into two sections, where each section discusses one topic within human- computer interaction (HCI) field which has helped in methodology and/or prototype devel- opments. The first section, about user-centered system design, is related to the methodology of the thesis. The second section is about data and information visualization, which contains theories that were useful during prototype development.

2.1 User-Centered System Design

As mentioned in previous section, this thesis work makes use of a design process in an effort to gradually answer the research question in each design phase. The design process in question is of a visualization tool which presents FUMA data (vehicle usage data based on position data) for people working in root cause analysis process. Since the thesis’ research question has a lot to do with understanding the users’ needs, workflow, and behavior, a user-centered design approach was chosen. This section explains the theoretical background behind user-centered system design.

Norman [15] argued that human-centered system design is a design approach that becomes more and more relevant over time because the complexity of modern products keeps getting higher and higher, which means it is easy to cause errors, frustration, or confusion to the users. By putting human needs, capabilities, and behavior as first priority, and then accommodate those things in the design process, we can alleviate the frustration that people get from dealing with high-complexity designs. This is the goal and motivation of human- centered or user-centered system design.

User-centered system design is a design process where users and their needs become the focus in each design phase. The process is usually iterative and includes the following activities [20].

1. Understanding the context of use (how can the users use the designed system?) 2. Identifying user requirements

3. Producing design solutions according to the requirements

(12)

2.2. Data and Information Visualization

4. User-centered evaluations of the design solutions—this step can provide feedback to any of the previous steps

Gulliksen et al. [13] listed 12 principles of user-centered systems design:

1. User focus: the goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should guide the development from the early phase

2. Active user involvement: representative users should actively participate throughout the entire development process and the entire system life cycle

3. Evolutionary systems development: the systems development should be iterative and incremental

4. Simple design representations: the design must be represented in a way that is easy to be understood by users and stakeholders

5. Prototyping: prototypes should be used early and continuously to visualize and eval- uate the design in cooperation with the end users

6. Evaluate use in context: baselined usability goals and criteria should control the devel- opment

7. Explicit and conscious design activities: the development process should contain ded- icated design activities

8. A professional attitude: the development process should be performed by effective multidisciplinary teams

9. Usability champion: usability experts should be involved early and continuously 10. Holistic design: all aspects that influence the future use situation should be developed

in parallel

11. Processes customization: the user-centered systems design process must be specified, adapted and/or implemented locally in each organization

12. User-centered attitude: should always be established

2.2 Data and Information Visualization

An important part of this thesis work is the design and development of a prototype of a visualization tool, which is why it is essential to discuss the basics of data and information visualization. Why a visualization tool? Because FUMA data is a huge dataset, and it would be impossible for the users to identify useful information in FUMA data if they were presented with the raw data.

A brief theory of data visualization

The aim of visualization is to make it easier to interpret a large amount of data so that we could gain a meaningful insight that would be hard to do just by observing raw data. Card et al. [6] define information visualization as “the use of computer supported, interactive, visual representations of abstract data to amplify cognition”. To break it down further, the process of data visualization could be explained into four stages[21]:

1. collection and storage of data,

2. transforming data for simpler manipulation,

(13)

Table 2.1: Graphical techniques for thematic maps Type of thematic map Graphical representation

of data Purpose

Dot distribution map Using dots to indicate the presence of variables

Showing spatial distribution

Choropleth map

Using a set of colors for different regions, where each color represents a different value

Showing data values that are aggregated by geo- graphical area

Graduated symbol map

Using the size of visual variables or markers to represent magnitude of the value

Showing data values on their corresponding geo- graphical area

Cartogram

Distortions of area or distance in proportion to the value

Showing spatial-

geographic patterns

3. mapping selected data into visual representation, 4. processing by human perception and cognitive system.

For the purposes of this thesis, the following subsections will focus on visualization of geospatial data, visualization of temporal data, and interactive visualization. The reason is because any information extracted from FUMA data is basically derived from vehicle position, which is a geospatial data, and timestamp, which is a temporal data. This data will then be presented in an interactive visualization tool.

Visualization of geospatial data

The source of FUMA data is from position information sent periodically by Scania’s vehicles.

Therefore, it is reasonable to include some kind of geospatial visualization in the visualization tool. There are many techniques that can be used to visualize geospatial data. Some of them are explained in this subsection, and the theory behind them became a consideration when selecting a visualization format for the prototype.

Geospatial data is most commonly visualized as a map. There are three important things to consider when designing a map visualization [14]: map projection, scale, and symbolization. Map projection refers to mathematical transformations that project the three- dimensional surface of the globe onto a two-dimensional surface. Scale is the ratio between the distance on the map and the real distance. Symbolization is the visual encoding that represents information as graphical elements on the map.

Maps that show spatial distribution of specific phenomena are called thematic maps. The- matic maps can be created using various graphical techniques, such as dot distribution map, choropleth map, graduated symbol map, and cartogram [14]. Table 2.1 show the comparison between these graphical techniques. Figures 2.1 [10], 2.2 [9], 2.3 [12], and 2.4 [8] show examples of dot distribution map, choropleth map, graduated symbol map, and cartogram respectively.

Visualization of temporal data

FUMA data has undergone rigorous post-processing and various analytical methods which resulted in various features that can explain vehicle usage, such as distance between stops, stop duration, and time difference between stops. These features are temporal data which

(14)

Lake Michigan Wisconsin

Acres of Harvested Wheat in Illinois

Iowa

Missouri

Kelly Ziegenfuss University of Illinois Produced December 9, 2014

Source of Data: USDA 2012 Projection: Illinois Albers Equal Area Standard Parallels: 39° N and 41 N°

Kentucky Indiana

Representative Densities:

Acres of Harvested Wheat

Box size is 100 square miles One dot represents 1,000 acres of harvested wheat Dot placement is random using county level data

10 acres/square mile 70 acres/square mile 130 acres/square mile

220 135 (km)

(mi) 0

0

Figure 2.1: Example of dot distribution map

Figure 2.2: Example of choropleth map

(15)

Figure 2.3: Example of graduated symbol map

Figure 2.4: Example of cartogram

can be very useful to analyze patterns. For this purpose, it is necessary to understand the basics of temporal data visualization.

Time is usually perceived as something linear. Historical time is typically visualized in the form of timeline, representing chronological order of relevant historical events. One of the early temporal visualizations created by a French scientist in the eighteenth century, depicted the time across horizontal axis moving from left to right, according to European writing standard [14].

Later in 1769, a British scientist named Joseph Priestley (1733-1844) published "A New Chart of History", a visualization of world historical event over time in a more structured way, with colors also introduced to the visualization (See Figure 2.5). Priestley’s graphical system are still relevant to today’s modern temporal visualization. It comprises the following main graphical elements [14]:

• Timescale: Uniform timescale with arithmetic representation

• Time indicators: Temporal division using vertical lines with time indicator label on each line.

• Thematic sections: Thematic sections are separated by lines.

• Line indicators: Line lengths are in proportionate ratio with the duration

(16)

• Line differentiators: Levels of uncertainty in the data are graphically depicted by the quality of lines (from solid to dotted lines)

• Color code: Used to marked a non-contiguous value.

Figure 2.5: "A New Chart of History" by Robert Priestley (1765)

Temporal data can be visualized in many ways. The following list describes some of the most common visualization techniques for temporal data [3].

1. Line graph: Time is used as the independent variable plotted on one axis, while the data values are plotted on the other axis in the form of points connected by lines. This is the simplest way to plot temporal data.

2. Stacked area chart: Similar to line graph, but multiple variables (data values) are placed on top of each other as colored areas, in order to show a cumulative total and components of that total.

3. Bar charts: Time is used as the independent variable plotted on one axis, while the data values are plotted on the other axis in the form of vertical or horizontal bars whose length represents the magnitude of the values. Grouped or stacked bar charts can also be created to show multiple variables.

4. Gantt chart: This type of chart is typically used to show a timeline of tasks in a project, where time is plotted on one axis while the name of tasks are on the other axis. The duration of each task is typically plotted in the form of bars.

5. Stream graph: Similar to stacked area chart but the areas are plotted around a central horizontal axis. Stream graphs are good to compare multiple time series or when the amount of data is big.

6. Heat map: Heat maps can be used when there are two time frames and only one variable to plot. Each time frame is plotted on one axis, while the magnitude of the variable (data values) is color coded in the plot.

7. Polar area diagram: In a polar area diagram, a time series is plotted in a cyclical manner.

This is good to visualize a cyclic temporal phenomena.

(17)

Interactive visualization

The proposed visualization tool is meant to be interactive. The main reason is the size of the FUMA data. The dataset is so big that the users would need to be able to view the data in different scales, which means interaction is necessary.

Visualizing data in in computerized environment means that the size of the medium to observe the visualization will be limited by the computer display (e.g. screen). Luckily, most of modern computers have enough computing power to generate a virtually large size, and interaction becomes an integral part to enable observation of such large visualization through the small display medium.

The information seeking mantra: "Overview first, zoom and filter, then details on demand" [19] is widely regarded as a common approach in building interactive visualization.

It promotes the the way of presenting data in different scales from large (overview) to the smaller ones, the ability to move between them (zoom), the ability to modify the scale (filter), and the ability to show the additional details that is hidden otherwise (details on demand).

Figure 2.6: Interactive visualization process

Figure 2.6 shows basic model of interactive visualization process involving two way communication between user and the system [22]. According to this model, the data is transformed into (static or dynamic) image based on the selected visualization technique.

Zudilove-Seinstra et al. identified four different types of user interaction which could produce different visual representation in an interactive visualization [22]:

1. The user may adjust visualization parameters/attributes. The user could choose how the final image should be rendered by adjusting the shape, color, texture, transparency, etc.

2. The user may interact with the visualized objects and scenes. This involves object manipulation such as selecting, rotating, scaling, moving, etc.

3. The user may extract features from the original dataset. This involves technique such as clip- ping (cutting away selected parts, usually in 3D visualization) and probing (displaying localized visualization and measurements).

4. The user may modify the data to be visualized. The data may be modified to investigate the projection of the result.

(18)

3 Methods

The main purpose of this study was to explore the possibilities of using position data to explore the concept of vehicle usage in Scania. Visualization of vehicle usage could be used for many things, and one of them could be to help finding root cause of vehicle break down.

This requires understanding on how the root cause analysis process is done and how the position data could help improving the process. The novelty of this project made the requirements rather unspecified. This study was thus performed in an exploratory manner.

Design-oriented research was selected as the general method due to the exploratory nature of the project, and the importance of a design artifact throughout the process[11].

The first step was to gain understanding about the data to be visualized, what it could explain, and what area it could give insight to, and other necessary information to plan the project. After the initial study, interview sessions were planned to understand the Root Cause Analysis (RCA) process, how it is done, and how the position data could give insights to improve the process. The data gathered from the interviews were analyzed using thematic analysis method. The result was then used as the base for constructing requirements in the form of PACT analysis and Use Cases. Lastly, these requirements were then translated into a prototype design, and a formative test was conducted to validate the prototype against the existing requirements. Figure 3.1 described the overview of methodologies used in this thesis project.

3.1 Understanding FUMA Data

An information gathering was conducted in the early phase of the project. The aim was to gain a better understanding about the FUMA project in general, and the data it produced in particular. As a design oriented research, this thesis project was trying to visualize the data in a way that could give meaningful insights. As part of FUMA project, This thesis work will only use the data generated in FUMA project as the sole source of information presented in the visualization tool. Therefore, it was reasonable to start with studying the data and find the potential usage of it.

Access to the data in FUMA project were given in the beginning of this project, and the the process of understanding FUMA was started by manually exploring the data and studying the current state of the project. This study was also complimented with an interview session with one of the FUMA project member. A data analyst was selected as a participant, and the

(19)

3.1. Understanding FUMA Data

Figure 3.1: Overview of the thesis process.

(20)

3.2. Interviews

aim was to get a better understanding about FUMA, which otherwise could not be explained just by going through available data and documentation.

3.2 Interviews

There are many ways of gathering requirements in a user-centered design process. Contex- tual inquiry is usually chosen in many design processes as it enables the designer to inquire the participants during the observation of the inquired activity, thus gain a better understanding of the user thought process and issues[5]. However, the root cause analysis (RCA) process is an ad-hoc activity by nature and contains sensitive, often classified information which makes it difficult to do contextual inquiry. Therefore, traditional interviews were chosen as an alternative to gather information in a more flexible way.

The aim of the interview sessions was to get a better understanding regarding the RCA and the possible way of using FUMA data to help the process. The user group targeted in this study was mainly the staff responsible in RCA process, which are Field Quality engineers and analysts in Scania R&D. The participants were selected using snowball sampling. In total, three employees participated in the interview, one field quality analyst, and two field quality engineers. The statistical analysis of the interview data would then not be of interest due to the low number of participants.

In regards to the qualitative nature of this research, The interview was designed as a semi- structured interview, with several open-ended questions that were prepared beforehand (see Appendix 1). The interviews were conducted in the building where the participants work.

The interview sessions were recorded and transcribed for analysis; each session lasted for around 30 minutes on average.

Thematic analysis was used to analyze the result of the interview. This method is widely used in qualitative research, and focuses on examining themes within data[1]. This is in line with the interview’s aim which is to understand the process behind the Root Cause Analysis and how the FUMA data could help in the process. Thematic analysis was done on the transcript of the interviews, and the themes were built to understand RCA process and gather requirements needed for the visualization tool design. The themes are explained as following:

• Understanding root cause analysis process – Problem definition in Root Cause Analysis – Data used in Root Cause Analysis

– Common types of root cause

• Gathering requirements for visualization tool design – PACT analysis

– Use Cases

3.3 PACT analysis

PACT (People, Activity, Context, Technology) is a user-centered design framework for designing an interactive tool. PACT framework essentially scopes the design situation by understanding the four aspects: people (P) who will use the product, activities (A) that the people want to undertake, the contexts (C) in which those activities take place, and the technology (T) that enables the desired interactivity [4].

Benyon et al (2014) acknowledge the PACT as a useful framework for thinking about a design situation in relation to an interactive system. A PACT analysis would be useful for both the analysis and design activities; understanding the current situations, seeing where possible improvements can be made and envisioning future situations [4]. By using PACT

(21)

3.4. Use Cases

Exploratory/Formative Test

Assessment/Summative Test

Validation/Verification Test

Comparison Test

Objective

Examine the effectiveness of preliminary design concepts

Evaluating lower level aspect and operation

Define an appropriate usability standard for future products

Compare multiple designs

When early stage early and/or midway late stage any stage

Interaction between

moderator and participant Extensive interaction Less interaction Little to no interaction none Type of result

Qualitative Quantitative Quantitative

Quantitative or qualitative

Table 3.1: Comparing four types of usability testing[16]

we could develop clear and concrete scenarios of how the target users would be interacting with the visualization tool.

In this study, each element of the PACT were identified from the thematic analysis result from the interview. Information extracted in the thematic analysis were selected and grouped into each element of People, Activity, Context and Technology.

3.4 Use Cases

A use case is described by a set of actions that is designed to be performed by the user to achieve a certain goal in the system. This concept is originally introduced in software engineering. The focus is to describe specifically on the interaction between the user and the system, with the context more emphasized on the user’s perspective [18].

3.5 Prototyping

After the qualitative data were gathered and analyzed, the result were used to design a prototype. A prototype is a tool that can be used to both explore and evaluate the design[18].

In general, prototypes could be categorized into low fidelity prototype (e.g. paper-and-pen, cardboard, sketches) and high fidelity prototype (e.g. interactive software).

A low fidelity prototype offers simplicity and can be produced cheaply and quickly, making it very useful in the early stage of the design process[18]. Its low fidelity makes it focus more on the underlying ideas of the design such as content, form, structure, and navigation.

High fidelity prototypes on the other hand, resemble the final product to a great extent. With a greater detail, it is suitable to communicate the ideas to stakeholder, or to test out technical aspects of the design. However, high fidelity prototypes take more time and effort to produce and more importantly, it may distract the discussion from the design essence (main concept of the design) to the superficial (such as fonts, colors, etc.) [18]. Due to the exploratory nature of this study coupled with the research limitation, low fidelity prototype was then considered as a suitable design artifact.

3.6 Usability Testing

After a prototype was designed, a usability testing for the prototype was planned to verify the discovered needs or identify new ones. There are four main types of usability testing[16]:

Exploratory/Formative Test, Assessment/Summative Test, Validation/Verification Test, and Comparison Test. Each of them is used for different purposes as described in Table 3.1.

Due to the exploratory nature of this study, a formative test was selected as the main approach for the usability testing. One participant was selected from the early interview session (see section 3.2). The participant was already familiar with the aim and the concept of

(22)

3.7. Ethical Consideration

this study, and the expectation build from this could be used to validate the design ideas. The test session lasted for 30 minutes. The participant was asked to do a set of tasks using think- aloud method, where each action and impression was described in a clear voice articulation.

The tasks were designed based on the use case. The details of the test scenario can be seen in Appendix 2. The test session were recorded, both voice and the interaction on the screen, and the recording was transcribed for further analysis.

3.7 Ethical Consideration

Information regarding the participants involved in this study is treated with confidentiality.

The participants were recruited on voluntary basis. The conversations were recorded with permission, and the anonymity is strictly kept in any written material and deliverable.

(23)

4 Data Gathering and Analysis

This chapter presents the results and methods of data gathering conducted in this thesis. The results of this initial investigation are crucial to understand FUMA data and RCA process.

The first section of this chapter discusses how the data is gathered, including details about the interview participants. The next two section summarizes all information gathered regarding the FUMA data and root cause analysis (RCA) process, based on interview results.

The last section is about the analysis conducted on the data, as a means to generate design requirements.

4.1 Data Source

Understanding FUMA Data

As part of FUMA project, this thesis work was given access to some datasets and documen- tations used in the project. The datasets were mostly in the form of large text files. Each dataset was extracted from the raw position data by using various algorithms according to the project pipeline. Understanding FUMA data was started by exploring these datasets as well as the documentation of how the datasets were extracted.

Aside from that, an interview session with a FUMA team member was also conducted to gain a better overview about the FUMA project and the vehicle usage. A data analyst, who has been involved in FUMA for around 2 years, was selected as the participant. Data analyst is responsible in setting up algorithm for analysis in FUMA, among other things. The interview session lasted for around 50 minutes.

Interviews

Root cause analysis (RCA) process is one of the responsibilities of the Field Quality Depart- ment in Scania R&D. RCA is an ad-hoc process by nature, which only conducted when the causes of the vehicle failure is more complicated. To understand more about the RCA process, interviews were conducted in the Field Quality department. The participants were selected among the field quality engineers who are responsible to initiate RCA, and also field quality analysts, who sometimes involved in RCA cases. Here are brief background about the users participated in the interview sessions:

(24)

4.2. Understanding FUMA Data

Table 4.1: Insights about FUMA data

Person Quotes Insights

FUMA Analyst "Just position information, timestamp, and vehicle ID... and Open Street Map.

But the actual, I’d say that the actual feature is an aggregation of that, so yeah."

The information extracted in FUMA project are based on the vehicle’s ID, position and timestamp.

"it goes from position to stops. From stops to labeling, like clustered stops with hub information. And then ex- tracting the vehicle sequences, like movements where you could add this hub feature"

In FUMA, vehicle stops are analyzed form position data, and all the vehicle usage modeling in FUMA are explored by analyzing the vehicle stops data.

"FUMA is about just using position data";

"...just looking at the data without combining them is a limit I think we are willing to have. Because we can join in anything we want from our other data on top of the vehicle position."

The vehicle usage aspects in FUMA are explored by mining information form position data only, i.e. aspects that can only be explored by learning patterns of vehicle position.

• Engineer1. The first participant was a Field Quality Engineer. He has been working in this role for more than 8 years, and currently responsible for components related to truck gearbox. The duration of the interview session was about 44 minutes.

• Engineer2. Another Field Quality Engineer, this participant has been working in this role for more than 6 years. He used to be responsible for components in truck chassis, such as steering, suspension, oil cylinder, etc. The duration of the interview session was about 31 minutes.

• Analyst1. Field Quality Analyst is responsible in data cleaning and preparation, and also creating various Business Intelligent reports. This participant has been working in this role for more than 9 years. The duration of the interview session was about 48 minutes.

4.2 Understanding FUMA Data

The first step in building a data visualization is to understand the data, its properties and limitations. FUMA project as the cornerstone for this study, utilizes telematics data gathered from Scania vehicles, specifically the position data. The position data, in its raw format, consists of only three elements:

• Vehicle ID - indicating the identity of the vehicle

• Coordinate (latitude-longitude) - indicating the position of the vehicle where the data is sent

• Timestamp - indicating the time when the data is sent

This data is sent continuously on a regular interval, ranging from one minute between mes- sages up to four hours, based on the vehicle subscription. This produces a huge amount of data, and the general aim of FUMA project is to extract meaningful information.

Using various analytical methods, these huge amount of raw position data are refined for further analysis. In the first step, vehicle stops are calculated based on the position data.

(25)

4.3. Understanding Root Cause Analysis Process

Table 4.2: Insights on RCA problem definition

Engineer1 " ...what part is only these trucks which are having this gearbox and this engine together that has this problem"

The problem in RCA usually ap- proached by finding a certain features or configuration that only applies for the failing vehicles

Engineer2 "...if this is a single case or if we should act on that and then start some deeper investigation, some work to avoid failures like that in the future"

Not every failure will be investigated using RCA process; it only happen on non ordinary failures (e.g. more critical, more comlpicated)

Analyst1 ". . . most of them, the trucks, they never fail";

" if you’re trying to do some sort of naïve classification problem, then the first guess of the classification is that nothing would fail"

The failures investigated in RCA often happen in a tiny percentage of the population.

"There is prioritization board"

"First it’s safety. And then I think it’s also based on cost... And then it’s also frequency."

There are some guidelines on decid- ing which vehicle failure will be fol- lowed up with a RCA process. Safety, cost-effectiveness, and the frequency are some of the factors considered in the guidelines.

Then the vehicle movements are calculated based on the sequence of the stops. And finally the various aspects of vehicle usage are analyzed using various machine learning algorithms based on the previous data.

In this study, three of the most basic features were selected to explain vehicle usage:

1. Distance between stops, 2. stop duration,

3. time difference between stops.

These three, however, does not reflect the limitation of the number of insights that can be extracted using FUMA data. They are merely the representation of the vehicle usage features measured in numerical values, which would be the base form of data used in the visualization tool.

4.3 Understanding Root Cause Analysis Process

Interviews were conducted in Field Quality department in Scania R&D. The participants were selected among the Field Quality Engineers and Analysts who have a lot of experience in doing root cause analysis (see 4.1). Using thematic analysis, the result of the interview were transcribed and coded based on the predefined themes to answers questions around root cause analysis.

Problem definition in Root Cause Analysis

Root Cause Analysis process could be regarded as a process to identify a group of similar vehicles and investigate why certain failures happen to only a number of vehicles within the group (see Figure 4.1). However, the implementation is often not as simple. In many cases, the failure only happens to a very small percentage of the population, so small that a naive

(26)

Figure 4.1: Root cause analysis problem definition.

(27)

classification would indicate that nothing is failing. But there are kinds of failures that need to be investigated at any cost, e.g. something related to safety. That is why a much more detailed analysis is needed in various areas of the complex vehicle structure.

Table 4.2 describes some quotes from the interview participants that lead to the insights about RCA problem definition explained in this sub-section.

Data used in RCA

Figure 4.2: Data used in root cause analysis.

RCA process is often carried out based on various aspects of the vehicles, and conse- quently uses various kinds of data. In the interviews, the participants mentioned the data commonly used in RCA. According to the source (where the data comes from), the data can be organized into 3 groups (see Figure 4.2):

• Workshops and distributors. Workshops and distributors of Scania all around the world regularly send reports regarding sales and maintenance of all vehicles. Warranty claims will have the most comprehensive report regarding vehicle failures. If the problem occurs outside the warranty period, failure reports, workshop history information, and spare part sales report will be used to investigate the problem.

• Internal Data. RCA process also uses internal data, such as truck specification doc- ument, design blueprint, and also previous cases that might be similar to the current problem.

(28)

Table 4.3: Insights about data used in RCA

Engineer1 "one major thing is often: warranty claims"; "Failure reports is another way"

Field quality engineer mainly use warranty claims and failure reports as the main source of information in RCA Engineer2 "we can go to the system and see how

many parts, that specific part were sold as spare part";

"if you had previous failure report with the same part number or if you have FQ items that’s already connected to that"

Another data sources that often used to provide additional information are spare part sales and similar cases in the past.

Analyst1 "we look into WHI as well because then we could have a longer history";

"other sources of course CHIN, chassis information... (something like) the specification of the trucks"

Field Quality Analysts also used Work- shop History Information (WHI) for older vehicles, though it is only useful for the vehicles who do the maintenance in Scania authorized workshops.

Truck specification is also used to help the analysis process.

Table 4.4: Insights about common types of root causes

Engineer1 "it’s often supplier changes, or some kind of change at the product"

"changes in the design"

"there’s production related issues...

These kinds of mistake are common also"

"it (the hardest case) is supplier related... some changes in the supplier and the sourcing then it can be hard to find."

"maybe it’s software bug here that we need to fix"

The most common, and often the most complicated, type of root cause is the deviation in the component quality from the suppliers. Other root causes that often happened are the changes in the design, production issue, material deviation, and software bug.

Engineer2 "The easiest one to find usually is production deviation... this will happen earlier"

"if it’s material deviation, or design, then it’s a bit tricky"

Analyst1 "when you have early failure, usually due to that the supplier have not given the right quality of the parts"

• Field observation. Sometimes, there are information that can only be explained by observing the problem directly. In this case, an engineer from Scania R&D to do a test drive and collect the log.

Table 4.3 describes some quotes from the interview participants that lead to the insights about common source of data explained in this sub-section.

(29)

4.4. Design Requirements

Common types of root cause

During the interviews, the participants also talked about the RCA process they had encoun- tered in the past. These root causes could be classified as following:

• Software bug. This indicates the problem was caused by a software problem in various parts of the vehicle, including control unit.

• Design variation. This means that the problem happened because of the changes in component design.

• Production deviation. This means that the problem was caused by the change in production process.

• Material deviation. This indicates that the problem was caused by changes in the material used in vehicles’ components.

• Supplier deviation. This means the problem was caused by bad quality parts delivered by the supplier.

Table 4.4 describes some quotes from the interview participants that lead to the insights about the common type of root causes explained in this sub-section.

4.4 Design Requirements

PACT Analysis People

The user of the visualization tool proposed in this study would be Scania employees who are involved in RCA process. RCA process is a quite complicated process and requires a deep knowledge gained through years of experience. So most of the users would be senior level employees with more than six years experience working with vehicle engineering or similar role. With that level of expertise, it is expected that the user will have good proficiency in statistical analysis. Scania has a highly computerized environment, and this means that the target user will be proficient in using IT tools.

Field quality engineers are the ones primarily responsible in initiating and implementing RCA. In cases where RCA is rather difficult or more complicated, Field Quality Analysts will be assigned to help the engineers narrowing down the area where they should investigate into. There are also other users that may assigned to RCA in a similar way (e.g. designers, purchasers), but they have specific area of expertises that makes the vehicle usage not necessarily relevant to those areas.

In Field Quality departments, the engineers and the analysts would be the ones involved in RCA process. Table 4.7 provides a brief summary about these two roles in terms of their traits, goals, and pain points that are relevant in the RCA process.

Field Quality Engineers Field quality (FQ) engineers are the main initiator of the root cause analysis process. They receive warranty claims and failure reports from all around the world on a daily basis. Typically an FQ engineer is responsible for one specific component of the vehicles (e.g. gearbox, suspension, chassis). The reports that come into their inbox have been filtered based on the component they are specialized in.

Having a deep technical knowledge about vehicle component has been the most important trait of an FQ engineer. They usually have an engineering education as a background, and have been working in this position for more than 5 years. They realize that even the highest quality product will fail from time to time, and it is their job to make sure that the failure will not happen again. “You can’t have a system that never fails. It’s too expensive”, said one of the FQ engineer highlighting their role in this company.

(30)

Table 4.5: Insights about Field Quality Engineers

Engineer1 " it would be easier to see if there’s something loose or if you have some collision between two parts, and then you can check the drawing and check what’s actually assembled."

Each field quality engineer has their own special truck components that they are responsible for. They have deep knowledge about their specialized components, how it is designed and assembled, and also where does the parts come from.

Engineer2 "(the reports) ends up in my inbox, coded to the special parts of the truck I have"

Table 4.6: Insights about Field Quality Analysts

Analyst1 “I was working with data: data cleaning, prepping. and also analyst creating reports, standardized BI report and also ad-hoc analysis when it comes to more difficult problems. . . for example, root cause analysis”;

"I’m not that interested into technical details on trucks, but also I think it’s impossible to know every little details"

Field Quality Analysts mainly deals with the higher layer of information in field quality department. Their main role is to produced reports and analysis for business intelligence. This expertise, however, often needed in RCA.

Even though they lack the technical expertise for RCA, they could give useful insights in the process to help narrowing down the root cause of the vehicle failure.

Field Quality Analysts Field quality (FQ) analysts are responsible for creating business intelligence report as well as data cleaning and preparation. During RCA process, FQ analysts are often deployed to help narrowing down the root causes using the higher level data that they possess. They typically have broad knowledge of various processes in Scania. “It’s really helpful to know about where you can find information and what processes are there in Scania,” said one of the FQ analyst, highlighting their capability to know where to find many kinds of information.

FQ analysts do not necessarily have a good knowledge in technical area of the vehicle components. But they usually have a good proficiency in high level statistics and numerical analysis. Their broad knowledge usually came from their long experience of work in various areas in Scania.

Activity

The visualization tool proposed in this study is expected to be used during the RCA process.

The RCA itself is basically ad-hoc natured, and it would mean that this tool will be used intensively only during the process.

Prior to the interview sessions, the participants did not necessarily familiar with the idea of using FUMA data in RCA process. This exploratory nature means that the activity aspect for the visualization tool might not be explicitly mentioned during the interview. As such, the activity aspect in this analysis was inferred from the insights gathered in the RCA problem definition (Section 4.3 Table 4.2).

In general, the goal of the visualization tool proposed in this study is to compare the vehicle usage between normal vehicle(s) and failing vehicle(s). This is aligned with the general

(31)

Table 4.7: Overview profile of field quality engineer and analyst.

goal of RCA process itself, which is to find the differences between the vehicles with failures and without. To achieve this, several activities were identified for the visualization tool:

• Select the vehicles to be compared To be able to compare the vehicles with and without failures, the users need to be able to select the vehicles they want to compare, and fetch the vehicle usage data for those vehicles.

• Select the vehicle usage feature to be compared Vehicle usage is a wide concept that includes a number of features. The users of this tool needs to be able to select which feature they want to compare between the selected vehicles.

• Adjust the comparison parameter Following Shneiderman’s information-seeking mantra: "Overview first, zoom and filter, details on demand"[19], the visualization tool should provide the users ways to adjust the information they want to be presented with.

Context

Scania vehicles are valuable assets to the customers. Any failure could affect their business negatively, and in turn would impact Scania’s reputation. This often makes root cause analysis process face a lot of pressure to deliver results in a limited amount of time. The visualization tool proposed in this study will be used during this kind of situation. More specifically, the tool will be used by the engineers and/or analysts in Field Quality Department to help them narrow down the root causes in RCA process.

Root cause analysis is a long process involving various experts within Scania. Figure 4.3 gives an overview of root cause analysis workflow. In general, it could be explained in five steps as follows:

(32)

Table 4.8: Insights about RCA workflow

Engineer1 " I create a failure report, then I create an item ... And then it needs to be accepted by R&D, where they have project management. And the PM (project manager) has to accept this FQ item and I have to convince him, with help of statistics e.g. how many claims are there, how many problems, how many failure reports do I have, how many basic warranty claims do we have, how many other in- dications, how many phone calls do I have from distributers and customers saying “this is really bad”. And then I have to organize pre-FQ meeting.

I have to present it to the PM, and if he agrees... then he accepts this item. And then he assign an assign- ment leader. project manager can take resources from R&D e.g. designers, testing engineer. the aim is to solve this FQ item. then we usually have the root cause analysis meeting. That’s like a milestone to understand the root cause. Then after you understand the root cause, then we can look at the solution. design solution."

Root cause analysis is done on certain vehicle failures that needs to be investigated further. Management approval is needed to start RCA. Understanding the root cause may require help from various expertise across Scania.

Figure 4.3: Overview of root cause analysis process.

(33)

Table 4.9: Insights leading to UC-01

FUMA Analyst "Just position information, timestamp, and vehicle ID... and Open Street Map.

But the actual, I’d say that the actual feature is an aggregation of that, so yeah."

"current data can’t tell me if something broke down. It can’t tell me anything about the driver. It can’t tell me anything other than.. It can’t tell me anything about the weather."

The data used in FUMA can give no explanation about the vehicle breakdown. Therefore, the user involved in RCA must specifically insert this information to the system.

0. The workshops and distributors all around the world continuously send warranty claims and failure reports to Scania. These documents will be filtered and sent to the inbox of related FQ engineers, based on their specialized components

1. When there is enough evidence indicating that a failure must be investigated thor- oughly, an FQ engineer will compile this report as a Field Quality Item, and present it to his/her manager.

2. The manager will sit in a pre-FQ meeting with the engineer to discuss about the FQ item. If the manager is convinced, a project leader will be picked to oversee the root cause analysis (RCA).

3. The project leader will create a specification of failure, which will be distributed among the project members. The team is arranged by gathering various expertise within Scania that could help investigate the problem.

4. Each team member will investigate the problem, finding any aspects from various data source within their expertise that may correlate to the failure. All team members will present their findings in the RCA meeting, and discuss to reach a conclusion of what the actual root cause is.

Technology

The engineers and analysts in RCA use standard desktop computer with modern web browser for their everyday work. A web based application would be a good choice for the visualization tool, not only because of its compatibility with various modern web browsers, but also offers plenty of choices for interactive visualization framework.

Use Cases

After analyzing previous results, a concrete scenario in the form of use cases was devised as a base to design the visualization tool. Six use cases has been identified during this phase, encompassing all the main functionality of the prototype. The overview of all the use cases can bee seen in Figure 4.4, and will be described further in the subsection below.

UC-01: Insert Dataset One of the activities identified in the PACT analysis is for the user to select the vehicles they want to compare. Each user in RCA will have their own way of selecting the sample of vehicles to be compared. As such, this tool should give the user freedom to do so.

However, this activity should also consider the limitation of the FUMA data, the main data source used to visualize the vehicle usage. By understanding FUMA data, it is known

(34)

Figure 4.4: Use case diagram of the visualization tool.

that this data cannot give information about which vehicles have experienced the failure and what time the failure on the vehicles happened (see Table 4.9. Therefore, the user needs to provide this information to the system.

The scenario for this use case is described as the following:

1. User selects a menu to insert dataset

2. The system displays a wizard, with an empty table for the dataset. Each row consists of Vehicle ID (String, unique, mandatory) and Time of breakdown (Date/time, optional) 3. User can insert manually to the table, or

4. User can import the data from text file (e.g. CSV) (see specification on point 2)

5. User selects the insert button to complete the wizard, and the system will load necessary data from FUMA environment

UC-02: Populate vehicles on the map From the result of the interviews, the users expressed their interest in some vehicle usage features that might be able to give them insights during RCA process e.g. the market(country) where the trucks operate, climate condition, road condition, and fuel condition where the trucks operate. (see Table 4.10

Looking back to the insights found in Table 4.1 in Section 4.2, it is acknowledged that the current state of FUMA data could not explicitly give answer to these features. However, there is one similarity among all these features: all of them are related to the location where the

(35)

Analyst1 "what we as analyst hand over to our customer is that we see big difference between the warmer market and the cooler market. you should probably try to investigate how that could happen."

"I’ve also been interested in road condition"

"In some market you’re provided with different fuel quality"

Some vehicle usage information that has not been explored yet in RCA process so far including the road conditions, climate conditions, and other aspects related to the location where the vehicle is operating (e.g. fuel quality).

While external informations (e.g. road data, climate data) are needed, vehicle geolocation data is nonetheless the key to explain these kind of usages.

Engineer1 "what are the road conditions, climate conditions"

Engineer1 "how are the vehicle, how are they driven, how are they operated and so on";

"how often they brake";

"how often the ABS system has been working on a brake";

"how big is the fuel consumption";

"Is it operating a very high gears often";

"if it’s idling a lot"

These are some of the vehicle usage aspects that the engineer interested in, but difficult to obtain. Currently, vehicle usage modeling in FUMA is not built with RCA problems in mind, and thus, has no direct answer to these features. However, FUMA has calculated some features regarding vehicle stops, and it is possible to use these features to extract the usage information needed in RCA.

Analyst1 "I wanted to know how long have they been driving, was it a start-up problem that the engine was cold for example...

And there’s no data (about it)"

vehicles are operating. This location (position) data is something that could be well explained by FUMA data. Therefore, visualization of this data could serve as the initial feature of the visualization tool. Geo-spatial map was selected as the visualization technique for this data.

A map could give a good context about the position information, especially on a global level like Scania trucks. And more importantly, a map is a generic visualization technique that could be extended to accommodate future features that may be explored using position data.

1. After the dataset is inserted, the system should populate the vehicles on the map.

2. The location should be based on average position of the vehicles in the dataset.

3. The user should be able to differentiate between normal vehicles and repaired vehicles (vehicles with time of breakdown)

UC-03: List vehicle features Table 4.11 reveals insights about the other features regarding vehicle usage that the user in RCA were interested into. These desired features have similarities, where all of them could be explained as occurrences of certain usage feature over time.

From the insights found in Table 4.1 in Section 4.2, it is known that vehicle usage features in FUMA project mainly analyzed from the sequence of vehicle stops over time. Although the

(36)

Table 4.12: Insights leading to UC-04, UC-05, and UC-06

Engineer1 "If it happens after the warranty period then there is not really such a good way to go"

"...if it’s a problem that only occurs once a week or sometimes"

These are some of the vehicle usage aspects that the engineer interested in, but difficult to obtain. Currently, vehicle usage modeling in FUMA is not built with RCA problems in mind, and thus, has no direct answer to these features. However, FUMA has calculated some features regarding vehicle stops, and it is possible to use these features to extract the usage information needed in RCA.

Engineer2 "from all the control units, we can see a lot of data like speed, gear changes, we can see a lot of data from that."

"you can get it a very aggregated level

"

The information regarding vehicle usage could also be obtained by access- ing the vehicle control unit log, but the the condition might be in a very aggregated level (months or even year interval), and the aggregation level is different from one vehicle to another.

FUMA data on the other hand, extracted from telematics data collected in much higher frequency, and thus could potentially provide a more valuable information regarding vehicle usage

Analyst1 "I always wanted to know what happened right before the break down"

"why did break down now, not last week"

"one factor that all of these (broken trucks) have been exposed to and not the others"

It is believed that the vehicle usage contributed to failure is something that accumulated over time, not just something that happen instanta- neously. Therefore, this "accumula- tion" is something that the visualization tool needs to present to the user.

desired features identified in Table 4.11 can not be explained using the current FUMA data, there are several usage features in FUMA that have similarities with the desired features. In this use case, the user should be able to see the list of these features, and select any of them to compare the vehicle usage within that feature.

UC-04: Compare vehicles populations The user should be able to see the data regarding vehicle usage based on the feature selected in the previous use case (UC-03). The features listed on UC-03 are mainly based on temporal data. The main goal of this visualization tool is to show the difference between normal vehicles and vehicles with failure. Therefore, the visualization of temporal data should be able to display the usage features of both group of vehicle in an easily discernible way.

Moreover, Insights described in Table 4.12 reveals some hints about the feature of temporal data visualization. It is believed that the vehicle usage contributed to the failure is something that accumulated over time. Therefore, there needs to be another data visualization that shows the statistics of the selected usage feature relative to the time when the failures happened,

1. User selects a feature from the feature list

Visualization of Vehicle Usage Based on Position Data for Root-Cause Analysis

Master Programme in Human-Computer Interaction

Department of Informatics and Media

Examensarbete

Visualization of Vehicle Usage

Based on Position Data for Root-Cause Analysis

A Case study at Scania CV AB

by

Ramadhan Kurniawan Sagala

2018-05-28

Examensarbete

Visualization of Vehicle Usage

Based on Position Data for Root-Cause Analysis

A Case study at Scania CV AB

by

Ramadhan Kurniawan Sagala

2018-05-28

Abstract

Sammanfattning

Acknowledgments

Contents

List of Figures

List of Tables

1 Introduction

1.1 Background

1.2 Motivation

1.3 Aim

1.4 Research questions

1.5 Delimitations

2 Theory

2.1 User-Centered System Design

2.2 Data and Information Visualization

3 Methods

3.1 Understanding FUMA Data

3.2 Interviews

3.3 PACT analysis

3.4 Use Cases

3.5 Prototyping

3.6 Usability Testing

3.7 Ethical Consideration

4 Data Gathering and Analysis

4.1 Data Source

4.2 Understanding FUMA Data

4.3 Understanding Root Cause Analysis Process

4.4 Design Requirements