• No results found

Visualizing Complex Systems: Variability in E/E Architecture

N/A
N/A
Protected

Academic year: 2022

Share "Visualizing Complex Systems: Variability in E/E Architecture"

Copied!
73
0
0

Loading.... (view fulltext now)

Full text

(1)

IT 19 044

Examensarbete 30 hp Juli 2019

Visualizing Complex Systems

Variability in E/E Architecture Imad Collin

Institutionen för informationsteknologi

(2)
(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

Visualizing Complex Systems (Variability in E/E Architecture)

Imad Collin

Scania builds complex products (trucks and busses) from many different parts which must be combined according to particular rules. These rules have to be considered when building the Electrical and/or Electronic system (E/E) architecture of a vehicle.

At Scania, the E/E architecture is a combination of Electrical Control Units (ECU) s, Actuators, and Sensors. This architecture is visualized using graph layouts and because of the complexity and the difficulty of reading and understanding such systems, it is essential to choose the right adapted visualization algorithms to the problem domain. For instance, the generated E/E diagrams in many cases are hard to understand, and see the entities and the relations between them. Moreover, in some case there is duplication or reused parts showed. Hence, the diagrams become more complicated to see how different parts interact with each other. Similarly, finding creative solutions to visualize different levels of granularity of the system (high level and low level) is a challenge. All of these challenges require an extensive

investigation of how to build simple, readable, and interactive diagrams which simplify the E/E architectures in a way that is easier to understand.

This degree project explores different techniques for complex systems, visualization, with the aims to give a comprehensive account of the variability problems raised at Scania. It is also considering a case study for adapting variability issues raised at Scania by concentrating on E/E architecture variability limited to two aspects, Time and Configuration. Moreover, finding creative solutions to visualize different levels of granularity of the system (high level and low level). Besides, it discusses different techniques for making an interactive diagram where the user can interact with such systems in an efficient way that increases the readability, understand-ability, and user satisfaction.

In this work, the complex system E/E architecture visualization is well studied with a focus on the literature review as a core method. Similarly, different interactive techniques examined as hypotheses intending to resolve the presented problem. On the other hand, the Iterative design process is carried out to represent the proposed system. Finally, the results of this study, describe how visualization improves the readability of complex systems (E/E architecture) alongside it aims to prove how different interactive techniques enhance the readability and help to simplify complex systems which significantly impacts the users’ satisfaction.

IT 19 044

Examinator: Mats Daniels

Ämnesgranskare: Iordanis Kavathatzopoulos Handledare: Sofia Cassel & Oscar Thydén

(4)
(5)

I

Acknowledgements

I want to express my sincere gratitude to Sofia Cassel, the thesis supervisor, for all the support and guidance from the beginning of this work until the end.

Also, I would like to thank Oscar Thydén, the technical expert at Scania for introducing me to the topic and assisting me with all the necessities for achieving this work since the initial day of starting the project. Similarly, a special thanks to both Henrik Linder and Marcus Dahlberg for all the support and assistance.

Further, I would like to thank Scania’s experts who shared their precious time during the period of conducting this work and their excellent cooperation. Thanks to those people who were involved and participated actively in surveys, meetings, and providing valuable feedback.

Moreover, I would express my gratitude to my reviewer, Iordanis Kavathatzopoulos from Uppsala University, for all the support and worthy supervision.

Finally, I would thank all Uppsala University members, especially the thesis coordi- nator Justin Pearson as well as the student advisor at technology department Liselott Dominicus for all the support and help.

Södertälje, Sweden 2019 I. Collin

(6)

Table of Contents

Abstract 0

Acknowledgements I

List of Tables V

List of Figures VI

List of Acronyms VIII

Terms Used in this Paper IX

1 Introduction 1

1.1 About Scania . . . . 1

1.2 Problem Statement . . . . 1

1.2.1 Problem Domain (Scania) . . . . 1

1.2.2 How to Interact with Users . . . . 2

1.3 Purpose . . . . 2

1.4 Research Questions . . . . 2

1.5 Key Words . . . . 3

1.6 Limitation and Delimitation . . . . 3

2 Background 4 2.1 Complex Systems . . . . 4

2.2 Software Product Line Engineering . . . . 5

2.3 Information Visualization . . . . 5

2.4 Variability Visualization . . . . 7

2.5 Graphs . . . . 7

2.5.1 Graph Drawing . . . . 8

2.5.2 Graphs and Networks? . . . . 9

2.6 Interactive Visualization . . . . 9

3 Automotive Architecture and Variability 10 3.1 Automotive Architecture . . . . 10

3.1.1 Automotive Architecture as Complex System . . . . 10

3.1.2 Automotive Architecture Topology . . . . 11

3.1.3 Automotive Architecture at Scania . . . . 12

(7)

Table of Contents III

3.1.4 Scania Modular System . . . . 14

3.2 Variability and Software Product Line Engineering . . . . 15

3.2.1 Variability and Configuration Visualization . . . . 16

3.2.2 Commonality . . . . 17

3.2.3 Feature model extraction / Extraction of sub-trees . . . . 18

3.2.4 Variability Changes Over Time . . . . 18

3.2.5 Variations by Join Type . . . . 20

3.3 Graph Drawing in Literature . . . . 20

3.3.1 Layout Algorithm . . . . 21

3.3.2 Aesthetic Issues . . . . 21

3.3.3 Graph Applications . . . . 21

4 Interactive Graph Visualization 22 4.1 Introduction . . . . 22

4.2 Interactive techniques . . . . 22

4.2.1 Fish-eye . . . . 22

4.2.2 Emphasis and Highlighting . . . . 24

4.2.3 Filtering . . . . 24

4.2.4 Panning and Zooming . . . . 25

4.2.5 Degree Of Interest . . . . 25

5 Methodology 27 5.1 Research Design . . . . 27

5.2 Research Questions . . . . 27

5.3 Data Collection . . . . 28

5.3.1 Literature Review . . . . 28

5.3.2 Interviews . . . . 28

5.3.3 Questionnaires . . . . 29

6 Design & Evaluation 31 6.1 Introduction . . . . 31

6.1.1 From Problems to Solutions . . . . 31

6.2 Design Process . . . . 32

6.3 Tools and Wire-framing . . . . 33

6.3.1 yEd Graph Editor . . . . 33

6.3.2 Balsamiq Wire-framing . . . . 33

6.3.3 Draw.IO . . . . 33

6.3.4 HTML, CSS, Node JS, and JQuery . . . . 33

6.4 Evaluation (Usability) . . . . 33

6.4.1 Goals . . . . 34

6.4.2 Evaluation Checklist . . . . 34

(8)

6.5 Test of Mock-ups . . . . 34

6.5.1 Variability Changes Over Time . . . . 34

6.5.2 Visualizing Different Levels of Electrical and/or Electronic system (E/E) for better Readability . . . . 36

6.5.3 Complex E/E Level Visualized . . . . 37

6.5.4 Emphasis and Highlighting . . . . 41

6.5.5 Feature Tree . . . . 42

6.5.6 Overview and Navigation . . . . 42

6.5.7 Panning and Zooming . . . . 43

6.5.8 Fish-eye . . . . 43

7 Results 44 7.1 RQ1 . . . . 44

7.2 RQ2 . . . . 46

7.3 RQ3 . . . . 46

8 Conclusion 48 8.1 Conclusion . . . . 48

8.2 Future Work . . . . 49

8.2.1 Graph Drawing Aesthetics . . . . 49

8.2.2 Variability Visualizing for E/E Architecture . . . . 49

8.2.3 Interactive E/E Diagrams . . . . 49

8.2.4 Computational Constraints . . . . 49

Literature 50 Appendices 57 .1 Interviews . . . . 57

.2 Questionnaires . . . . 58

.3 Interfaces Comparison . . . . 59

(9)

List of Tables V

List of Tables

Table 5.1: Interviewees at Scania . . . . 29

Table A1: Component n1 Interface . . . . 60

Table A2: Component n2 Interface . . . . 60

Table A3: Interface Comparison Table . . . . 60

(10)

List of Figures

Figure 2.1: SPL for Developing Portfolios of similar Products . . . . 5

Figure 2.2: Travelling on the Tube, the map of the London Underground . . . . 6

Figure 2.3: Basic Graphs Pictures . . . . 7

Figure 2.4: Traditional Graph Layouts . . . . 8

Figure 2.5: 3D Graph Layouts . . . . 8

Figure 3.1: Automotive E/E Architecture . . . . 10

Figure 3.2: Automotive Architecture Topology . . . . 12

Figure 3.3: ECU Deployment Example . . . . 13

Figure 3.4: ECUs Communication Example . . . . 14

Figure 3.5: Scania Modular System Example . . . . 15

Figure 3.6: FODA Example . . . . 16

Figure 3.7: Variability Visualization . . . . 17

Figure 3.8: Commonality in Software Product Line Engineering . . . . 18

Figure 3.9: Feature Views . . . . 19

Figure 3.10: Feature Additions Views . . . . 19

Figure 3.11: Variation by Join Type . . . . 20

Figure 4.1: Basic concept of the Fish-eye . . . . 22

Figure 4.2: Fish-eye Tree Views . . . . 23

Figure 4.3: A graph with 134 vertices and 338 edges . . . . 23

Figure 4.4: Emphasis and Highlighting . . . . 24

Figure 4.5: Protégé class browser visualization . . . . 25

Figure 4.6: DOITrees based on the multiple focus and context . . . . 26

Figure 4.7: DOITree with more than 600 nodes . . . . 26

Figure 6.1: E/E Example . . . . 31

Figure 6.2: Interface comparison . . . . 35

Figure 6.3: Interface comparison Filtering Menu . . . . 35

Figure 6.4: The flow of visualizing E/E . . . . 37

Figure 6.5: Variability In E/E Diagram . . . . 37

Figure 6.6: E/E Level 0 . . . . 38

Figure 6.7: E/E Level 1 . . . . 39

Figure 6.8: E/E Level 2 . . . . 39

Figure 6.9: E/E Variant Selection . . . . 40

Figure 6.10: Sets Operations . . . . 40

(11)

List of Figures VII

Figure 6.11: E/E Level 3 . . . . 41

Figure 6.12: Emphasis and Highlighting . . . . 41

Figure 6.13: Feature Tree filtering . . . . 42

Figure 6.14: E/E Diagram Overview . . . . 42

Figure 6.15: Interactive Diagram using Fish-eye . . . . 43

(12)

List of Acronyms

UI User Interface FV Function Variable AE Allocation Element SPL Software Product Line ECU Electrical Control Unit GPU Graphics Processing Unit InfoVis Information Visualization R and D Research and Development SPLE Software Product Line Engineering SOPS Scania Onboard Product Specification E/E Electrical and/or Electronic system

EPXA Systems Functional Architecture group at Scania

SESAMM-Tool 2 a tool used for presenting E/E architecture at Scania version 2 ASAD “Automated driving assistance system” or “Advance driving assistance system”

SESAMM-Tool 1 a tool used for presenting and editing the E/E architecture version 1

(13)

List of Acronyms IX

Terms

SOPstand for Scania on-board Product Specification, mostly it is describing the process or complementing the customer order. The intent is to reach user satisfaction and fulfill customer needs.

Productin this paper, the product means a vehicle which might be a truck or a bus.

Variability Managementit is the fundamental concept in Software Product Line Engi- neering (SPLE) to support variants, it means the principles, methods, and tools (that defining which product configuration are realized by an artifact). Not only considering the commonality but also the Variability [1].

OASit is "a tool used at Scania for Variability management in production.

Artifact the result of engineering activity that includes software and hardware, and documentation, that describes a component or any functionality of one or more product configuration.

Objecteach object is a type of an artifact describing a part of the product; where each object has a type and unique numerical identifier.

ISO 26262 an E/E system functional safety standard introduced for the automotive industry, defined as "absence if unreasonable risk due to the hazard caused by malfunction behavior and E/E system" [2].

Standardizationthe aim to increase product individualization, deciding which variant, what cost and benefits of the variants to be determined. (for expanding the commonal- ity).

Logical Viewit describes the application in terms of the problem domain [3].

Architectural Texturerefereeing to a collection of standard development rules in order to realize the system [3].

Users at Scaniain this paper, the users at Scania refer to engineers and system architects (who use E/E architecture in their daily work activity).

(14)

1 Introduction

This chapter gives a short introduction about Scania and it describes the problem state- ment and the objective of this paper. In addition, it illustrates some limitations of this work.

1.1 About Scania

Scania AB is one of the significant Swedish manufacturers of commercial vehicles (heavy trucks and buses) and engines. Scania AB was formed in 1981 [4], and Scania grew fast with about 42,000 employees in nearly 100 countries [5].

Scania today is ranked as one of the world’s foremost manufacturing leaders in sus- tainable transport (Scania annual report 2014) with a successful history delivering customized heavy trucks and busses. Scania contributes to community development in several ways, by providing high-quality services such as offering engines in parallel with many co-operations, providing low carbon solutions and continuous improvement of fuel efficiency.

Most of Scania’s research is conducted at the Research and Development (R and D) department, which is placed in Södertälje, Sweden, with a workforce of 3,500. However, the concept of modularity was introduced at Scania during the 1940s [4] (described in chapter 3). This concept comes as a need to enhance the customer choice and to guarantee users’ satisfaction [4]. The idea of modularity supports the user having a diversity of options. Allow as many variations as possible [6] to build a suitable vehicle that satisfies the users’ needs.

1.2 Problem Statement

1.2.1 Problem Domain (Scania)

Scania builds complex products (see Terms) from many different parts which must be combined according to particular rules (for example, certain parts can never be in the same vehicle, whereas other parts require the presence of specific other parts in the same vehicle in order to work). Scania also builds products individually, according to customer requests, which means that no two vehicles (almost) are the same. However, when visualizing the E/E architecture of a vehicle, we must consider these conditions.

(15)

Introduction 2

For instance, what objects (see Terms) should be shown where and when as well as the sheer amount of different vehicle individuals.

1.2.2 How to Interact with Users

Given the needs of users, what do they want to see? How do they want to interact with E/E systems?

1.3 Purpose

The objectives of this work contribute to science by:

1. Exploring the variability problem limited to two Time and Configuration.

2. Addressing the topic of visualization in a very complex problem domain, and finding creative solutions by visualizing different levels of granularity of the system as follow:

a) High level, where the users may want to see how parts of the system are connected.

b) Lower levels, where the users may want to see and model different variants of each part and which functionality each part is responsible for.

3. Investigating the variability problem arises in vehicle architecture by performing a case study.

4. Investigating how users’ need and wants should interact graphically with com- plex E/E architectures in a comfortable, simple, and less complicated way.

1.4 Research Questions

RQ1

Given the variability constraints (Time and Configuration), how can we best visualize E/E architecture?

RQ2

How to visualize different levels of granularity of such E/E architecture that guarantee both the simplicity and readability of E/E diagrams?

RQ3

Given the variability constraints above, how can we use interactive techniques for enhancing the readability and simplicity of E/E architecture?

(16)

1.5 Key Words

Graph drawing, product line engineering, variability, modularity, graph layout algorithms, complex systems, interactive design, visualization algorithms, Human–Computer Interaction.

1.6 Limitation and Delimitation

For this work, there could be some limitations and delimitations as follow:

E/E architecture could be found in different scientific domains. Therefore, the concern of this study will be the E/E architecture at Scania’s vehicles.

For this work, the variability problem is considered from the visualization per- spective. Therefore, techniques such as clustering and classifications will not be considered in this work.

Different studies have been conducted previously at Scania to tackle close problem domains. Therefore, this work will not concentrate on the techniques that were already studied. However, the previous work’s results could be used during this work if needed.

Reaching the user satisfaction could be such a hard task to achieve; however, in this paper user’s satisfaction meant Scania E/E Engineers satisfaction (namely people who work with E/E architecture at Scania).

For computation constraints, the Graphics Processing Unit (Graphics Processing Unit (GPU)) will not be one of the core concepts of this work; instead, some aspect will be considered since GPU, in many cases is involved for drawing diagrams.

Finally, for this work, considering different layouts for graph drawing will not be covered but, the layouts used by Scania.

(17)

Background 4

2 Background

This chapter describes the core concepts of complex systems and variability in software product line engineering. Similarly, it comprises a summary of information visualizing and illustrating different aspects of building the interactive diagrams which simplify the complex system.

2.1 Complex Systems

Complex systemsare almost everywhere nowadays and appear in a wide variety of fields [7] [8]. Even though there is no concise definition of a complex system [8] however, a complex system is known as a system which consists of many components [9], where these components may interact with each other or not. Many examples around us can be illustrated and described as complex systems such as climate, the human brain, or even imagining the cities and how they are organized and connected.

On the other hand, a complex system has many concepts to be considered such as complexity, nonlinearity, networks, adaptation, and emergence. Hence, the behavior of such systems are hard to model, and the reason is merely that of the dependencies between the components, the relations between these components and the interaction among its parts [7]. Therefore, designing any complex system is not an easy task, it requires an eye on both the performance and also the cost [10]. Anyhow, thanks E/E architecture which is stands for Electrics and Electronics where it plays a fundamental role for efficient and safe systems [10] and helps to link between different components and functions.

Due to the complexity of E/E systems, one challenge is raised, by imagining how it is hard for humans to understand, read, and interact with such complex systems and see the pattern and relations between each part. Therefore, representing such systems requires special attention. Besides, representing these systems and each component in a natural way is essential, where the user can easily read, understand, and see the components and relationships between them. Here the benefit of visualization has appeared. Visualization is known as the science of representing data visually [11]. Visualization also might be described as any techniques used for creating images, animation, or diagrams for transmitting a message. That to say another challenge will be to visualize complex systems quickly and guarantee better readability and simplicity of grasping such complex systems.

(18)

2.2 Software Product Line Engineering

SPLEstands for Software Product Line Engineering, traced back to 1970s, intending to lower cost and reduce the time of developing [12]. It strives to produce a set of a related products by reusing the commonly available components concerning the better quality and lower adoption barriers [13]. Software product line means to reuse the available parts, software, artifacts for efficient development, lower cost, and fewer adoption barriers. Further, many examples could be illustrated where Software Product Line (SPL) is required for developing similar products for example mobiles, cameras, automobiles, and computers.

The SPL definition is given by Clements and Northrop in [14][15], Software product lines. Where SPL is becoming increasingly prevalent to deliver high-quality product.

Definition “A software product line, is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a standard set of core assets in a prescribed way. [15]

Another definition is represented by Quali et al. [16] where SPL is defined as

"a process of maintaining and developing families of products by considering the advantage of their common aspects and predicted variabilities". The following figure describes how SPL is used for developing portfolios of very similar products.

Figure 2.1: Reinhard Stoiber 16 may, 2012 advanced software engineering, lecture notes, Zurich university, delivered 18 -mars 2019

2.3 Information Visualization

In the last few years, there has been a growing interest in Information Visualization (InfoVis). InfoVis is known as the use of computer-supported, visual representation of

(19)

Background 6

data [17]. It provides an easy way to represent a large amount of data with pattern recognition abilities [18] [19]. Furthermore, for simplifying the concept of visualization and reflect it to the real world, visualization could help to apply vision research to the practical problem of data analysis, as identical when engineers applying physics to the practical problem while building factories [20].

One typical example used in the visualization world is the history of the Tube Map (The map of London Underground), which was created by Harry Beck (Garland 1994). The figure 2.2 represents the New map by Harry. He describes the transportation network in such a way as an electrical circuit.

Figure 2.2: Travelling on the Tube, the map of the London Underground.

Not surprisingly, several advantages can be introduced by using InfoVis for instance, it provides a better way to comprehend extensive data, plus it makes the problems with the data become immediately apparent. Furthermore, visualization helps to reveal things about the data and the way these data are collected [7]. Despite, InfoVis is extensively used in different scientific domains (in Engineering, Bio-medicine, and Chemistry), however, still, many challenges arise in InfoVis and undoubtedly finding the best way to map the data to a natural, readable, and clean image is still the core of these challenges.

Definition InfoVis "The use of computer-supported, interactive visual representations of data to amplify cognition" Card, Mackinlay Shneiderman, 1998.

(20)

2.4 Variability Visualization

With the complexity introduced in SPL, the necessity of visualizing techniques is essential for handling this complexity, similarly, providing a high level of cognitive support, plus, underlying the structures more natural and in an efficient way is needed. Here the visualization is the key to help to accomplish that. Hence, efficiently handling the variability will guarantee the product quality, better productivity, and lower cost [3].

Visualization is considered as one of the fundamental aspects for comprehending com- plex systems with a high level of variability management (see Terms) (compared to other forms of data representation forms such as tabular data or list of objects). Therefore, the number of researches concerning variability visualization is growing more and more [21] [22]. Also, the complexity on the cognitive level as engineers in understanding, identifying, and handling the variability and configuration that lasts as a significant challenge [22]. Also, practical, understandable, and straightforward visualization will make the system comprehension faster and more comfortable [23].

2.5 Graphs

Nowadays, a graph is considered as an essential mathematical tool in many domains and subjects, that includes chemistry, linguistics, geography, and even electrical engineering and sociology [24].

Definition The term graph G means a non-empty finite set V(G) of elements “vertices or nodes”

and a finite set E(G) of unordered pairs of elements of V(G) “Edges” [24]. Another similar definition presented by Wilson and Loebi [24][25] as follows:

Definition A graph is an ordered pair of sets (V, E) where E is a subset of the set of unordered pairs of elements of V. V refers to a set of vertices such that V=V(G), and similarly, E refer to set of edges E=E(G).

On the other hand, u, v is the end vertices of this edge, and we say that u, v are adjacent vertices in G [25]. The following figure illustrates a graph.

Figure 2.3: Basic pictures of graph theory by Martin Loebl [25].

(21)

Background 8

2.5.1 Graph Drawing

Graph drawing has become utilized in many applications and because graphs are abstract mathematical objects for defining the relations between objects [18]. Therefore, drawing graphs is not an easy task, where the complexity of many graph drawings depend on the size of the graph, especially in the case of complex and colossal data.

Hence, finding the best way to draw a good representative picture of a graph is a challenge. That to say the size of the graph is a crucial issue for visualization [26].

On the other hand, several approaches and methods found for drawing graph (e.g., node-link diagram). Similarly, different graph drawing layouts are available depending on the application and the type of data.

Although drawing a graph is a core problem in InfoVis [18], still the quality of these layouts vary depending on the way they are used.

However, generating a good graph/network by using different layouts, is a challenge.

That to say, choosing the best layout require considering many aspects such as view- ability and usability [26]. Similarly, the understand-ability, cost, and aesthetics.

An example of different layouts is shown in the following two figures.

Figure 2.4: Traditional Layouts.

Figure 2.5: 3D Layouts.

(22)

2.5.2 Graphs and Networks?

The difference between the graph and the network is still not distinguished in the litera- ture [27]. Anyhow, back to graph definition “the graphs are an abstract mathematical concept”; whereas, the networks used for providing a clear real-world interpretation. For instance, the Internet could be described as a network where the computers are nodes, and physical connections between different devices exemplify edges. In contrast, the nodes in the graph denote the entities and the edges describe the relationships among these entities.

Further, networks are extensively used in science and engineering. Besides, networks are often complicated, mainly when they are illustrating static and dynamic data [28].

The reason is that the edges are considered as relations among objects or events [29].

Nevertheless, with such complex data, the network becomes difficult and some chal- lenges are presented, such as the network complexity and the necessity of finding an easy way to understand and read these complex networks. Hence the complexity of such systems should be considered and prioritized.

2.6 Interactive Visualization

It has been said that interactive visualization is the way to take a picture to worth thousands of words [30]. It could tell a rich story to answer a question related to a topic.

Interactive visualization is closely connected to InfoVis since the latter reduces the raw information [31]. On the other hand, interactive visualization is considered as a subset of InfoVis [16]. It allows the user to be in virtual dialogue with the visualization with the opportunity to manipulate elements optimally within 1/10 second [32]. Therefore, interactive visualization is an essential aspect for producing such a good representation of data, which will affect user satisfaction and the readability of complex systems.

Definition “Interactive Visualizations is the process of letting the primary source of information communicate directly with a viewer to support inquiry in a visually compelling, and interactive manner [31].”

Additionally, as stated by Nazemi [33] interactive visualization is a process that consists of the number of interlocking feedback loops divided into three classes as follows:

Low Level: data manipulation loop.

Intermediate Level: exploration and navigation loop.

High Level: problem-solving loop through.

Though the primary goal of interactive visualization is applications optimization, it helps to perform cognitive work in an efficient way [20]. Besides a good visualization is not just a picture or 3D environment where we can walk and look around (e.g., museum with many statues) but it is something that provides us with the ability to drill down and illustrate more data that we are interested in or essential to us to see in detail [20].

(23)

Automotive Architecture and Variability 10

3 Automotive Architecture and Variability

This chapter discusses the automotive E/E architecture and explains how it is considered as a complex system. Also, it illustrates the variability concept in SPLE. On the other hand, it describes the E/E architecture at Scania by describing the Scania modularity system. The last part of this chapter will focus on graph drawing and demonstrates some graph drawing applications.

3.1 Automotive Architecture

3.1.1 Automotive Architecture as Complex System

The term “ System and Architecture” is us used while developing automotive electrical systems, even though there is no specific definition of these terms, it has been widely referred to as " the placement of physical component and software", others say "System and Architecture" mean the rules and a guide for building a system and composition of elements and their relationships.

However, in vehicles, the E/E architecture is known as several Sensors, actuators, and Electrical Control Unit (ECU)sbesides other hardware components. Moreover, because of the strong relationship and the tight coupling between the hardware and software via wires, the Wires are considered as a part of architecture as well. Figure 3.1 is a simple representation of E/E architecture.

Figure 3.1: Automotive E/E Architecture

(24)

Further, Peter Wallin in his paper [34] described three different views when it comes to automotive electronic systems architecture as follows:

Physical View: describing how different ECUS, are placed “physically”, and how they are connected to each other.

Logical View: describes the logical relationships between different components

“logically”.

Electrical View: describe the distribution of electrical components (cabling, power generation).

After illustrating some facts about E/E architecture it will not require much of thinking to realize that E/E is itself considered as a complex system since it consists of several components and the relationship among different parts of such systems.

3.1.2 Automotive Architecture Topology

According to Mody et al. [35] automotive architecture topology is defined as a list of domains as follows:

1. Chassis and Safety domain where the ECUs are used to control Steering and Braking.

2. Power-Train domain where the ECUs control the Engine and Battery, also, some related function’s body.

3. Electronics domains when the ECU control Window, Mirrors, and also the Air condition.

4. Infotainment: The ECU control Displays (e.g., rear), beside the Navigation and Cameras.

5. “Automated driving assistance system” or “Advance driving assistance system”

(ASAD)/AD: where the ECUs control the Sensors and participating in decision making.

6. Connectivity Telematics: where ECUs provide externally connected to the car. (e.g.

Cellular connections).

The following figure shows the topology of automotive architecture.

(25)

Automotive Architecture and Variability 12

Figure 3.2: Automotive Architecture Topology.

3.1.3 Automotive Architecture at Scania

Electronic and Electricalsystems consist of many parts that include generators, transform- ers, and more. Previous research conducted with the focused on the design challenges of the electric distribution system and visualizing such systems using Matlab [36]. In this research, the authors were investigating the real-time visualizing and monitoring of an electrical distribution system, intending to increase the reliability and security with a more efficient system.

On the other hand, today almost all new cars engines are controlled by specialized computer [37], for instance determining how to supply the engine and reduce the emission of toxic also the fuel consumption. Similarly, controlling the real-time engine status is considered as an essential activity using the computer. Besides the controller

(26)

indicates the oxygen level in the gas, which helps to determine whether the cylinder is poor or rich [37].

Identically, at Scania, the electrical system is a combination of ECUs, Actuators, and Sensor all together are called SESAMM, which stands for “Scania Electrical System Archi- tecture made for Modularization and Maintenance”. ECU is becoming more complicated because of the fast-growing and variation of automotive with a different embedded sys- tem [38]. At Scania’s system, ECU consists of several Allocation Elements (AE)s, where these AEs are wrapped up in a logical layer. Figure 3.3 shows different deployments of an ECU.

Figure 3.3: ECU Deployment

Moreover, Allocation Element (AE)s are communicating be sending and receiving dif- ferent messages. Messages are shown in an arbitrary container called Function Vari- able (FV), besides these messages can have different signals as well. we might imagine the ECU as a parent of AEs hence all message which is sent/receiving between different AEs could be seen by ECU in addition to all different AEs. However to simplify the relation between the ECU and AE we could say that the interface of an ECU is defined by the “Union” of all interfaces that defined for AEs, which are allocated to that specific ECU, that to say, in order to define ECU interface we should go through AEs that belong to a specific ECU.

To visualize different E/E systems, at Scania, a tool used for presenting E/E architecture at Scania version 2 (SESAMM-Tool 2) have been developed by Scania engineers. This tool is using an auto-generated layout for representing the E/E diagram, but still, some limitation of using this tool is presented. For instance, the generated diagrams are in many cases are hard to understand and see the entities and the relations between them (ECU components as well the relationships among AEs). Figure 3.4 show how two ECUs are communicating, where Tx and Rx mean the send & received messages and the Green color signal means the signal is Green.

(27)

Automotive Architecture and Variability 14

Figure 3.4: Abstract level of two ECUs communication.

Some limitations of the current tools at Scania:

1. The diagrams are too big; hence, it is very complicated to follow and understand.

(Sometimes about 700 unique AEs depend on the product configuration).

2. The similar component which supports the same messages/signals not appropri- ately presented.

3. The complexity (e.g., large diagrams, many instances of the same part, hard to visually compare/see differences between similar parts); hence, the system is not accepted according to the users.

4. Much connection between different part of the same diagram which makes it hard to recognize and follow how various parts are connected.

3.1.4 Scania Modular System

The Modular product design at Scania has been found since the 1960s [39], At Scania, the Modular system has been the main reason for the company to keep profitable each year since 1934 [40], that applied for architecture as well.

Scania’s Modularity system provides customers with vehicles and engines with specific requirements. Moreover, at Scania, the building block and the different combinations possibility of the module system is defined as a "set of user factors". These factors should meet the customer specific transport requirement(e.g., how best the vehicle to be used [41]).

The figure 3.5 is an example of some types of designation for a truck with a possible combination of components that could be used for different customer needs (Truck model, Type of transport, Chassis adoption, Chassis height, etc.).

(28)

Figure 3.5: Scania Modular System Example.

3.2 Variability and Software Product Line Engineering

Numerous publications have performed in recent year documenting the variability in several domain engineering artifacts (such as requirement, architecture, component, test cases, etc.). As a definition, variability is the ability to change the behavior of a system through customization [4]. Not far, still, the number of researches is increasing intending to underline the variability challenges and issues introduced in SPL domain.

Since the focus of this paper is the variability in E/E architecture, therefore, the basic concept and definition of the variability are summarized into three different concepts:

Features, Feature Model, and FODA. According to Ommen and Rock [42] the Features, and the Feature model is definition is given as follows:

Definition Feature might be functions or characteristic that differentiates between members of the software product line [42][45].

Definition Feature model a collection of all features and the relationship among these features.

Furthermore, according to Greevy [46] the feature model is a requirement engineering technique, used widely in requirement analyzing accurately for product families. It describes the functionalities of the system and the relationships between the features.

Hence it enables requirement variability modeling [46].

Definition FODA-notation stand for Feature-Oriented Domain Analysis, is a simple model with the feature that organized using “consist of” and “generalization/specialization” relationship using AND/OR graph. Moreover, it is a way to visualize the variability [45].

(29)

Automotive Architecture and Variability 16

On the other hand, the Feature Tree View is a commonly used term in SPLE. It is the tradi- tional tree layout is used while representing feature models for variability management.

The reason behind using the traditional tree layout is the simplicity and effortless to learn from users [42]. Additionally, when modeling features the graphical representation is called a Feature Diagram based on the hierarchical structure [42], where each node represents a single feature and the features could be either optional or mandatory, the figure below is an example.

Figure 3.6: FODA Example: A Car Feature Model specifying Features and Feature Relationships

However, because the tree structure can’t model the relationships between features [35], those relationship are not categorized under the feature tree , therefore the cross tree constraint (CTCs) used to solve this issue, this represented a logical formula for instance (A or B ) or (both A and B shouldn´t be selected together).

3.2.1 Variability and Configuration Visualization

In [42] P. Trinidad, et al. have addressed the issues of visualizing large and complex product lines using different Visualization techniques for efficient visualization of vari- ability. However, this paper’s focus was limited to the interactive methods of cross-tree constraints .

Also, another research conducted by G. Botterweck, et al. [44] where an attempt has been made for improving the drawing space of the feature model [43]. The paper focused on developing a new method to draw feature models using tree cones. However, the lack is that the author did not consider the case of a cross tree or complex constraints [42][43].

Further, another study was conducted, and a new tool presented for product configura- tion visualization called VISIT-FC by Kang, at al. [45]. However, the drawback of this tool was while displaying the cross-tree constraints, where the overlaps are presented while visualizing more extensive feature mode is not considered [45].

(30)

The figure 3.7 depicts the possible configuration with one truck where the architecture might choose Light Axel or Heavy Axel.

Figure 3.7: An example of possible configurations with one truck 3.2.2 Commonality

The commonality is considered as a fundamental part of the SPL scope, and it has been studied in widely. To describe the commonality briefly, it means "multiple uses of the same component in a product family (component sharing or component standardization (see Terms)."

However, component Commonality is crucial because it is enabling companies to reduce the complexity of the products, hence enhancing the economy scale for the company (less complexity in product will help make the product line more efficient)—[47].

Since Commonality as a concept is described in several sources, therefore in this work, the Commonality is defined as follows:

Definition Commonality is a list of assumptions that are true for all family members. Fur- ther, according to Wozniak and Clements [48], they have concluded that even though commonality might also distinguish between common and uncommon components, however, assigning a commonality level for a product family is considered as a best practice rather than distinguishing between component.

The following figure describes the Configurator concept, where it is exercising of shared assets variation points to a specific product instance [48].

(31)

Automotive Architecture and Variability 18

Figure 3.8: Configurator concept, where it is exercising of shared assets variation points to a specific product instance

3.2.3 Feature model extraction / Extraction of sub-trees

When the tree becomes large and complex, it becomes harder to follow and experience.

Therefore, it might be useful to extract a part of the tree to examine separately [22].

By displaying the sub-tree in a new window, the user will be able to focus more on a specific model, where users will be able to see the relationships among the entities, categories under a specific node, and recognize the tree structure much easily, similarly meets the requirement “extract.” By extracting of sub-trees in a new window, it will be easier to have an overview and get additional details of the selected feature tree view [22]. Interestingly producing the “best” hierarchy is a challenge, because a different group of people organizes feature in different ways, hence providing a better approach to produce the same set of the feature will be useful [14]. One approach to achieve that and organize the feature in a meaningful way is the extraction process [14].

3.2.4 Variability Changes Over Time

Development artifacts (see Terms) are affected by time and space [39], beside the cat- egorization of the occurrence of variability in a development artifact can change over time [38]. However, at Scania, the functional changes are strongly required; this requires updating the architecture (electronics, hardware and even software). Safety assurance (accurately assuring ISO 26262 standards)(see Terms) is one reason for considering changes at Scania’s products. On the other hand, at Scania, the cost reduction also is considered as a reason to consider the changes at E/E architecture level.

Hence, at Scania, in E/E architecture, for each variant, it is not unusual to see more than one version of the same component but with some additional features to that variant. For instance, the fuel indicator might change over time, therefore visualizing these changes is also a challenge. Two approaches are illustrated by Blecker and Abdelkafi [47] where the authors described two variations for visualizing the feature changes over time.

(32)

Feature additions view: where it takes care of the only added entities.

Feature intersection view: where it shows the source entitles that added in both development tracks of a system (e.g., the intersection of additions)

The following diagrams show both approaches for visualizing the changes. The goal of such visualization is to support the software engineer when reasoning about a system [47] on the other hand, choosing a color scheme that can be identified by everyone.

Where many people have color vision deficiencies, color blindness, and awareness.

Figure 3.9: Feature View

Figure 3.10: Feature Additions Views

(33)

Automotive Architecture and Variability 20

3.2.5 Variations by Join Type

Because compound components (the components which consist of different parts e.g., several AEs,) can have a diversity of parameters, besides grouping components and interfaces to larger units might be hard, therefore handling this challenge is crucial in order to grant the user a mechanism to differentiate component interfaces.

For differentiating the interfaces of the components, the basics of Set theory is the key, as is described by Georg Cantor "A set is a Many that allow itself to be thought of as a One".

Moreover, Venn Diagrams [49] in figure 3.11, used for depicting different operations that could be performed between Sets. Where each relationship showed as a circle and another circle is overlapped if the sets intersected.

Back to E/E architecture at Scania, the interfaces of the components are represented as Sets/lists of different parameters. Database terms are used in this work instead of mathematical terms because the component’s interfaces are shown as tables of various entities (these interfaces are not handled as database tables in the code, but the approach in this study show them as database tables for making them readable). The purpose of applying Database queries is to allow the users to specify a table resulting from a join operation [50]. Those operations are such as inner join, left outer join, and right outer join.

Figure 3.11: Different operations that could be performed between sets

3.3 Graph Drawing in Literature

Several studies investigating graph drawing carried out, for instance, graph node con- nectivity, edges, and other elements, has been addressed in numerous studies [26], [18], [51]–[53]. However, still, several types of research are active because of the problems with graphs drawing [26]. Graphs in InfoVis have been divided into two different categories:

Unstructured Data: the role of InfoVis is to discover the relationship.

Structured Data: InfoVis is used of representation (relations and elements).

(34)

Graph layout is used in many different fields and domains that include mathematics, computer science, biology, and more [54]. Different approaches exist today and proven by science such as force-based layout, spectral layout, Orthogonal layout, tree layout, circular layout.

As described in section 3.3 with graph visualization some limitations are presented such as the size of the graph, which makes the loss of readability, therefore generating a clean layout, is needed.

3.3.1 Layout Algorithm

Even though computing a graph layout is not or concern for this work, but still, we can perform the work using the Monte Carlo process [54]. However, instead, the focus on this work will be the auto-generated layout, namely the Orthogonal layout since Scania´s current tool using this layout for visualizing the E/E architecture.

3.3.2 Aesthetic Issues

To select a proper graph layout the Aesthetic issues, have to be considered, it has become an essential aspect when it comes to drawing. Dwyer et al. [56] Studied different aspects of evaluating different way for generating layout (user-generated vs. automatic layout) with a focus on different “rules-of-thinking” for what makes a functional layout and how to improve the drawing. Even though in this study, about 6,500 people participated, the major drawback of this approach is that people were from a different background.

However, this approach may not be conventional in all situation; for instance, and the author did not mention whether the result is applicable for complex system or not.

3.3.3 Graph Applications

A survey conducted by Melancon and Marshall [26] showed a considerable use of a graph in different applications such as file hierarchies, biological taxonomies, and genetic maps. Besides in computer science, data structure, systems those are object-oriented, ER diagrams, and website maps [26].

Moreover, several attempts have been made to provide some tools for Graph Visualiza- tion; here, the illustration of some tools used widely nowadays.

1. ILOG Jveiw Graph Layout: it is a Java library for highly demanding graph-based applications [57].

2. Tom Sawyer: a toolkit for the layout of the graphs [53].

3. yEd: a Java library for Visualization and automatic layout of the graph structure [57], [87].

Although extensive research has been carried out on graph generating tools, yet it is not clear whether a particular generated graph diagram is readable or not.

(35)

Interactive Graph Visualization 22

4 Interactive Graph Visualization

4.1 Introduction

This chapter discusses various techniques and methods for interactive graph explo- ration. Also, it discusses some widely known taxonomies of InfoVis tasks introduced by Schneiderman such as Overview, Zoom, Filter, and Detailed on Demand.

4.2 Interactive techniques

Several techniques for interactive visualization are available nowadays because working with large graphs requires providing the users with better interaction, which is vital and a challenge. To allow the users to navigate and illustrate largely and complicate graphs, interactively is an essential aspect for better readability due to the difficulty of the graph in reading fashion [70]. Before illustrating different interaction techniques, considering the representation space matter in case of large and complex systems; therefore, the display space in this section is a single view.

4.2.1 Fish-eye

Figure 4.1: Basic concept of the Fish-eye Fish-eye introduced by Furnas, 1960, it enables users to

explore the extensive data set such as graph or network details while maintaining context, that by zooming in or zooming out [71]. The concept of the fish-eye is that the user applies a distortion, where the selected area becomes the fish-eye center and it zoomed-in and other parts of the display zoomed-out. In other words, the distortion allows the users to focus on only the part they are interested in. The figure 4.1 shows a tree where the interested node zoomed-in.

Further, significant effort has been devoted to this new technique, for instance, Tominski, et al. [72] present an interactive visual aid that helps both the navigation and exploration of graph layouts, combines different Visualization techniques such as (focus + context and also overview + details). The study aims to display the substantial graph information which could be almost impossible to grasp and understand the relations between its

(36)

parts. Besides, usually, the lens techniques used for exploring the graphical layouts, providing an interactive way of accessing local group information. They used to bring the neighbors of some focused vertices to the same focus position [72]. In the figure 4.2 the textual tree view shows labels that can be optionally magnified by a fish-eye transformation.

Figure 4.2: Differently zoomed Fish-eye Tree Views

Similarly, Sarkar and Brown [73] described the fish-eye techniques for viewing and browsing graphs using a software analog of the fish-eye lens. In this study, they added some effort to apply the global transformation to the original fish view technique. They conclude to the quotes "graphical fish-eye views are promising techniques for viewing large structure". In this paper, it is obvious to see the position of the item and size concerning the level of details displayed [73]. Figure 4.3 shows a graph with 134 vertices and 338 edges. The vertices represent significant cities in the United States, and the edges represent paths between neighboring cities [73].

Figure 4.3: A graph with 134 vertices and 338 edges. The vertices represent significant cities in the United States, and the edges represent paths between

neighboring cities.

(37)

Interactive Graph Visualization 24

4.2.2 Emphasis and Highlighting

It has been said that a strong signal of any of the opponent channel will attract attention better than a weak signal [74]. The signal is considered as "strong" depending on the difference of its background. Also, the visual object is more visible when its background has less contrast [74]. However, in graph diagrams, this technique is respected as an essential because the vertices position could change between two subsequent time steps in the graph and this will lead to losing the mental maps hence the viewer will not be able to track the changes [75].

Highlighting is done by clicking on the vertices or even using filter function where the user can select specific vertices and edges [75]. To sum up, Liang and Huangin [76]

conclude that highlighting "is required to rise to a higher level of information Visualization process" [76].

The following figure shows two p ’s have been highlighted "using the color" [74].

Figure 4.4: Two p’s have been highlighted “using the color".

4.2.3 Filtering

Filtering allows the users to drive what aspect of the data to be displayed. Based on what Shneiderman mentioned in his paper "The eyes have it: a task by data type taxonomy for information visualizations" [77], "Overview first, zoom and filter, then details on demand".

The importance of filtering techniques is presented, besides selecting the level of detail and using filtering the user will be able to explore the different level of the nested graph without hierarchy [53].

Furthermore, another advantage of using filtering is represented in the case of the large graph where visual clutter typically happens; this clutter occurred because of the overwhelming number of edges. Using filtering will reduce this clutter [78]. On the other hand, because the dynamic graph consists of many dimensions (e.g., vertices, edges, etc.) and besides, different attributes could be attached such as textual attributes and weights, therefore, the role of filtering (filtering could be nodes or edges) become essential to simplify the complexity of such a graph [75].

References

Related documents

This thesis provides several conceptual design ideas on how to create a better user experience that takes into account the different users who are using the Seco Tools Online

Detta är även något som Liseberg påtalar då allting inte kan ordnas genom Facebook utan de måste bli omdirigerade till hemsida eller telefon, men de anser ändå att

Nordlund et al (2001) menar att det är i den direktupplevda situationen, där saker finns i sitt rätta sammanhang som kunskaperna blir bäst befästa. Det ska finnas gott om utrymme för

Through case study of NTT DoCoMo’s i-mode, we compare with the development situation of E-commerce innovation in China and suggest the E-commerce companies in China how to coping

This knowledge contribution adds further insights to the existing theories about challenges related to IT-supported learning in rural areas of developing countries described in

Another possible positive consequence exemplified by our first interview subject was the description of Enterprise Architecture is a tool for analyzing and structuring

Specifically we explore the interconnection between national e-readiness and cultural values, and address the research question: How do cultural values impact a nation's readiness

The aim of Study II was to study personality traits in relation to central serotonergic neurotransmission and years of excessive alcohol intake in 33 alcohol-