A Heuristic Approach based on Prioritized Quality Attributes for...
74
IN DEGREE PROJECT MECHANICAL ENGINEERING, SECOND CYCLE, 30 CREDITS , STOCKHOLM SWEDEN 2019 A Heuristic Approach based on Prioritized Quality Attributes for the Evolutionary Architecting of Automotive Embedded Systems HARIKRISHNAN RADHAKRISHNAN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT
Transcript of A Heuristic Approach based on Prioritized Quality Attributes for...
IN DEGREE PROJECT MECHANICAL ENGINEERING,SECOND CYCLE, 30 CREDITS
, STOCKHOLM SWEDEN 2019
A Heuristic Approach based on Prioritized Quality Attributes for the Evolutionary Architecting of Automotive Embedded Systems
HARIKRISHNAN RADHAKRISHNAN
KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT
Sammanfattning
Under åren har fordon blivit mycket komplexa system som involverar flera tekniska domäner. Detta
beror främst på tillkomsten av elektronik och dess användning i bilindustrin. Elektroniskt styrda system
erbjuder mycket mer flexibilitet och tillförlitlighet jämfört med konventionella mekaniska system.
Detta har också lett till en komplicerad systemarkitektur inklusive många elektroniska styrenheter,
robusta kommunikationssystem och ett komplicerat ledningsnät.
Utveckling av sådana mycket komplexa system är en besvärlig uppgift. I de flesta fall sker utvecklingen
stegvis snarare än en fullständig översyn. Denna typ av utvecklingsprocess kallas en evolutionär
architecting process (EAP). Två arkitekteringsmetoder, Architecture Trade-Off analysmetod och
kostnadsfördelanalysmetod, valdes för att studera EAP vidare i ett industriellt sammanhang. Baserat
på dessa två metoder föreslås ett lätt ramverk för arkitektoniskt beslutsfattande (LFAD) för att anpassa
sig till fordonsspecifika behov. Denna avhandling verifierar LFAD med ett riktigt industriellt fall i Scania
CV AB. LFAD-metoden ger ett snabbt sätt att tillverka tillgänglig information om ett projekt genom att
begränsa olika aspekter till en känd uppsättning kvalitetsattribut och organisera dem på ett användbart
sätt ur ett arkitektoniskt perspektiv.
Intervjuer valdes som en primär metod för att genomföra denna studie och de genomfördes på olika
bilföretag som Scania, Volvo Trucks, Volvo Cars och Einride. Intervjuerna gav input till metodstudierna
och för att identifiera kvalitetsattribut som vanligtvis beaktas för EAP. De resulterande
kvalitetsattributen visualiseras som ett verktygsträd tillsammans med dess beskrivning.
Avhandlingen undersöker också analysen av förspänningen i EAP med inblandning av flera tekniska
discipliner. Ingångar togs också från intervjuerna. Från studien framgår att olika organisatoriska
egenskaper påverkar beslutsprocessen. Till exempel är kunskapen om olika system som samlats under
åren väldigt mycket beroende på hur de är organiserade som grupper. Det finns också ett behov av
homogenitet i semantik bland dessa grupper när man hanterar komplexa tvärvetenskapliga system.
Och slutligen dras slutsatsen att partiskhet spelar en viktig roll i beslutsprocessen och måste hanteras
från fall till fall.
Examensarbete TRITA ITM-EX 2019:694
En heuristisk strategi baserad på prioriterade
kvalitetsattribut för arkitekturer för inbyggda
system för fordon
Harikrishnan Radhakrishnan
Godkänt
2019-11-08
Examinator
Martin Törngren
Handledare
Xinhai Zhang
Uppdragsgivare
Scania CV AB
Kontaktperson
Marcello Pasquale
2
Abstract
Over the years, vehicles have become very complex systems involving multiple domains of
engineering. This is mainly due to the advent of electronics and its use in the automotive industry.
Electronically controlled systems offer much more flexibility and reliability compared to conventional
mechanical systems. This has also led to a complicated system architecture including many electronic
control units, robust communication systems and an intricate wiring harness.
Development of such highly complex systems is an arduous task. In most cases, development is done
incrementally rather than a complete overhaul. This kind of development process is called an
evolutionary architecting process (EAP). Two architecting methodologies, Architecture Trade-Off
Analysis Method and Cost Benefit Analysis Method, were chosen to study EAP further in an industrial
context. Based on these two methodologies, a lightweight framework for architectural decision-
making (LFAD) is proposed to align with automotive-specific needs. This thesis verifies LFAD with a real
industrial case in Scania CV AB. The LFAD method provides a swift way to assimilate available
information regarding a project by narrowing down different aspects to a known set of quality
attributes and organise them in a useful way from an architectural perspective.
Interviews were chosen as a primary method to conduct this study and they were conducted at
different automotive firms like Scania, Volvo Trucks, Volvo Cars and Einride. The interviews provided
inputs to the method studies and in identifying the quality attributes that are usually considered for
EAP. The resulting quality attributes are visualised as a utility tree along with its description.
The thesis also delves into analysing the bias involved in EAP with the involvement of multiple
engineering disciplines. Inputs were taken from the interviews as well. From the study, it can be seen
that different organizational characteristics affect the decision-making process. For example, the
knowledge about different systems accumulated over the years are hugely dependent on how they
are organized as groups. There is also a need for homogeneity in semantics among these groups when
dealing with complex multi-disciplinary systems. And finally, it is concluded that bias does play a major
role in the decision-making process and must be addressed on a case by case basis.
Master of Science Thesis TRITA ITM-EX 2019:694
A Heuristic Approach Based on Prioritized Quality
Attributes for the Evolutionary Architecting of
Automotive Embedded Systems
Harikrishnan Radhakrishnan
Approved
2019-11-08
Examiner
Martin Törngren
Supervisor
Xinhai Zhang
Commissioner
Scania CV AB
Contact person
Marcello Pasquale
3
Contents Sammanfattning .................................................................................................................................1
Abstract ..............................................................................................................................................2
List of Figures ......................................................................................................................................5
List of Tables .......................................................................................................................................5
Nomenclature .....................................................................................................................................6
Foreword ............................................................................................................................................8
1 Introduction ................................................................................................................................9
1.1 Background .........................................................................................................................9
1.2 Scope ..................................................................................................................................9
1.3 Disposition ........................................................................................................................ 10
2 Theoretical Background............................................................................................................. 12
2.1 Automotive E/E System Architecture ................................................................................. 12
2.2 Evolutionary Architecting Process ...................................................................................... 15
2.3 ATAM ................................................................................................................................ 17
2.3.1 Quality Attributes ...................................................................................................... 18
2.3.2 Scenario Elicitation .................................................................................................... 19
2.4 CBAM ................................................................................................................................ 19
2.5 Lightweight Framework for Architectural Decision-Making (LFAD) ..................................... 21
2.6 Scania Electrical System ..................................................................................................... 22
3 Research Design ........................................................................................................................ 25
3.1 Motivation......................................................................................................................... 25
3.2 Research Question............................................................................................................. 25
3.3 Methodology Overview ..................................................................................................... 25
4 Interviews ................................................................................................................................. 27
4.1 Quality Attributes and Scenarios ........................................................................................ 27
4.2 Utility Tree ........................................................................................................................ 29
4.3 Interview Design ................................................................................................................ 30
4.3.1 Choosing Stakeholders ............................................................................................... 30
4.3.2 Introduction Meeting ................................................................................................. 30
4.3.3 Interview Procedure .................................................................................................. 30
4.3.4 Interview Transcription and Coding ............................................................................ 31
4.4 Interview Questionnaire Results ........................................................................................ 31
4.5 Interview Code Summary................................................................................................... 34
4
4.5.1 EAP ............................................................................................................................ 35
4.5.2 Feedback ................................................................................................................... 36
4.5.3 Quality Attributes and Refined Utility Tree ................................................................. 38
5 Case Study ................................................................................................................................ 42
5.1 Case 1: S-Order ECU........................................................................................................... 42
5.1.1 ATAM ........................................................................................................................ 44
5.1.2 CBAM ........................................................................................................................ 46
5.2 Case 2: City Door Project ................................................................................................... 49
6 Discussion ................................................................................................................................. 54
6.1 Interview Summary ........................................................................................................... 54
6.1.1 EAP ............................................................................................................................ 54
6.1.2 Feedback ................................................................................................................... 55
6.1.3 Quality Attributes ...................................................................................................... 56
6.2 Case Study: S-Order ECU .................................................................................................... 56
6.2.1 ATAM ........................................................................................................................ 56
6.2.2 CBAM ........................................................................................................................ 57
6.3 LFAD .................................................................................................................................. 58
6.4 Validity .............................................................................................................................. 58
6.4.1 Internal Validity ......................................................................................................... 58
6.4.2 External Validity ......................................................................................................... 59
6.5 Bias Analysis ...................................................................................................................... 59
6.5.1 Grouping A: Internal vs. External ................................................................................ 60
6.5.2 Grouping B: Internal System Architects vs. External System Architects ....................... 60
6.5.3 Grouping C: Internal System Architects vs. Internal System Owners ........................... 60
6.5.4 Grouping D: Internal S-Order vs. Internal R&D ........................................................... 60
6.5.5 Overall Analysis .......................................................................................................... 60
7 Conclusion & Future Work ........................................................................................................ 63
7.1 Conclusion ......................................................................................................................... 63
7.2 Future Work ...................................................................................................................... 63
8 Bibliography .............................................................................................................................. 65
9 Appendix ................................................................................................................................... 68
9.1 Appendix A: Coding Methods............................................................................................. 68
9.2 Appendix B: Interviewee Profile ......................................................................................... 70
9.3 Appendix C: CBAM Rankings .............................................................................................. 71
5
List of Figures Figure 1 Electronic Control Unit by Bosch. Taken from [7] ................................................................. 12
Figure 2 Block Diagram for a Microcontroller. Taken from [7] ........................................................... 13
Figure 3 Standard CAN Bus Message Frame [8] ................................................................................. 14
Figure 4 Extended CAN Bus Message Frame [8] ................................................................................. 14
Figure 5 CAN Bus Topology Example [8] ............................................................................................ 14
Figure 6 Context for CBAM. Taken from [26] ..................................................................................... 20
Figure 7 Scania E/E System [10]......................................................................................................... 22
Figure 8 Typical Tipper Truck Adapted by Bodybuilder [32] ............................................................... 23
Figure 9 Bodybuilder Interface Configuration Tool [33] ..................................................................... 24
Figure 10 Utility Tree (First Cycle)...................................................................................................... 29
Figure 11 Utility Tree (Second Cycle) ................................................................................................. 41
Figure 12 Simplified System Architecture .......................................................................................... 42
Figure 13 Hardware Topology Options .............................................................................................. 43
Figure 14 Truck Cab with a City Door [34].......................................................................................... 50
Figure 15 Grounded Theory [35] ....................................................................................................... 68
List of Tables Table 1 Embedded System Quality Attributes [29] ............................................................................ 18
Table 2 LFAD Sample ......................................................................................................................... 21
Table 3 Quality Attributes under consideration for RQ ...................................................................... 25
Table 4 Quality Attributes for Software/Functional Aspects .............................................................. 27
Table 5 Quality Attributes for Hardware Aspects ............................................................................... 28
Table 6 Initial Scenarios assessing Feasibility .................................................................................... 28
Table 7 Initial Scenarios assessing Time to Market ............................................................................ 28
Table 8 QA (Hardware) Ranking – First Cycle ..................................................................................... 32
Table 9 QA (Functional) Ranking – First Cycle .................................................................................... 32
Table 10 QA (Hardware) Rank – Second Cycle ................................................................................... 33
Table 11 QA (Functional) Rank – Second Cycle .................................................................................. 33
Table 12 Table of Codes .................................................................................................................... 34
Table 13 Hardware Specification Comparison ................................................................................... 43
Table 14 Sample CBAM Table ............................................................................................................ 46
Table 15 CBAM Functional QA........................................................................................................... 48
Table 16 CBAM Hardware QA ........................................................................................................... 48
Table 17 ROI Calculation with Equal Weights .................................................................................... 49
Table 18 ROI Calculation with Normalized Weights ........................................................................... 49
Table 19 LFAD Approach for D1......................................................................................................... 50
Table 20 LFAD Approach for D2......................................................................................................... 52
Table 21 Overall Variances ................................................................................................................ 61
Table 22 Functional QA Variances ..................................................................................................... 61
Table 23 Hardware QA Variances ...................................................................................................... 61
6
Nomenclature
AADL – Architecture Description & Analysis Language
AHP – Analytical Hierarchy Language
ALU – Arithmetic and Logical Unit
API – Application Programming Interface
ASIL – Automotive Safety Integrity Level
ATAM – Architecture Trade-off Analysis Method
BCI – Bodywork Communication Interface
CAN – Controller Area Network
CBAM – Cost Benefit Analysis Method
CPU – Central Processing Unit
DSM – Design Structure Matrix
EAP – Evolutionary Architecting Process
ECU – Electronic Control Unit
EMC – Electro-magnetic Compatibility
EMI – Electro-magnetic Interference
EXT - External
E/E – Electrical and Electronics
FFBD – Functional Flow Block Diagrams
FMEA – Failure Mode Effect Analysis
HARA – Hazard and Risk Assessment
LFAD – Lightweight Framework for Architectural Decision-making
LIN – Local Interconnect Network
OEM – Original Equipment Manufacturer
QA – Quality Attribute
RAP – Revolutionary Architecting Process
ROI – Return on Investment
SAE – Society of Automotive Engineers
SESAMM - Scania Electrical System Architecture made for Modularization and Maintenance
SRS – Software Requirement Specification
7
SysML – System Modelling Language
UML – Unified Modelling Language
8
Foreword
I couldn’t have conducted this study with this much of a breadth and produce results within this
timeframe if not for my 2 wonderful supervisors. Therefore, I would like to thank Xinhai Zhang and
Marcello Pasquale for sticking with me throughout the thesis, right from drafting the proposal to
finishing my presentation. I would like to thank my colleagues Johan Linder, Eduardo de Souza and Carl
Gunther at Scania for their support and encouragement during my thesis study and for making my time
at RSS enjoyable. Even bigger thanks to all the system architects and system owners who took time to
participate in this study and to give valuable inputs. I would like to thank Fredrik Asplund for helping
me figure out my research direction and giving me adequate guidance in conducting interviews. I
extend my gratitude to Martin Törngren for giving valuable insights into this field and for taking part
as an interviewee.
Thanks to Niklas Timarson, Utsav Khan and Max Ahlberg for helping me find the right people in
different firms for my study. Last but not least, I would like to thank my family for keeping me
motivated for the past few months. I would like to thank my friends for all the support they have given
me. Thanks to everyone who encouraged me along the way without which I would not have taken up
Mechatronics.
Harikrishnan R
Stockholm, November 2019
9
1 Introduction
Vehicle functions are increasingly becoming complex. As a result, it has now become a requirement to
have a robust electrical system that can act as a platform for implementing different functions. The
demand for these features has consistently increased during the years [1]. About 90% of all innovations
are being realized by electronics. They include the domains of performance, safety, comfort,
autonomy, and electrification. It is said that there are more lines of code on a modern car than a
commercial jet. Managing this cost and complexity on a system level has become a challenge and a
bottleneck for development. A system architecture is a conceptual model that describes the different
views of the system. The views could be at different levels of abstraction and they may be independent
domains [2]. A major role of this conceptual model is to capture extra-functional requirements that
specifies how the system should operate. The system architecture of the electrical system of vehicles
have become a centre-point for such technological advances. Moreover, extra-functional
requirements arising from customer feedback and field quality issues have also become more
important over the years.
1.1 Background A modern automotive electrical system is responsible for realizing various types of function. These
functions could vary from very simple tasks like switch on a lamp to complex functions like traction
control or autonomous driving. Growing needs have driven the electrical system to be more complex
and flexible to accommodate all kinds of functions in a cost-efficient manner. A typical automotive
electrical system consists of multiple electronic control units (ECU) connected by a communication
bus. These systems are distributed in nature and each ECU is aimed to tackle functions within its
domain. For example, the Engine Management Unit’s primary function is to control the performance
of the engine and its auxiliaries. However, these systems are not capable of functioning as a standalone
system. As the system becomes more complex and distributed, it becomes harder to manage
dependencies and making changes becomes a costlier affair [3]. Hence, it is more common to make
changes in smaller steps rather than performing larger changes at once, thus not risking the integrity
of the system. These smaller changes are called evolutionary architecting process (EAP) and are of
prime importance in the lifecycle of the existing system architecture.
The very nature of the EAP is complex. [4] shows that EAP currently relies on experience and ‘gut-
feeling’ from system architects to make developments on the electrical system. EAP is an unstructured
problem that has not yet been formalized through any methods. There are a few reasons as to why
and they include: involvement of many disciplines, complex dependencies, lack of common design
criteria for all systems [3], [5].
1.2 Scope The scope of this thesis is to conduct a study on existing methods related to architecture development
and study if they can be applied to an evolutionary architecting process. This thesis is done as part of
a course at KTH Royal Institute of Technology for 30hp and in collaboration with Scania CV AB. A case
of EAP that is being investigated is the addition of a new ECU to the existing system architecture.
Scania has 2 types of customer orders, namely A-order and S-order. A-orders are orders within the
capabilities of the product range offered by Scania. While S-order is an order where the customer
requests for a function/feature that is outside the capability of the existing product range. For example,
a customer can request a new axle configuration. This would need change to both hardware (new axle,
10
sensors, etc) and software (load distribution, brakes, etc). The customized truck development group
at Scania is responsible for implementing such requests. These custom functions are becoming more
popular, usually lower in complexity and lower volumes. These functions are currently implemented
by making changes on an existing ECU. There are a few drawbacks to this solution, like larger lead time
and restrictions in functions that can be provided to the customer. However, the possibility of a new
ECU solely for this purpose has been investigated. This is an interesting solution as it provides a
separate ECU for implementation of custom functions. The development process will become simpler,
shorter and in this case, cater to a wider range of custom order [6]. The case is further introduced in
Section 5.1. A second case called the city door project involving an adaptation to a truck cab as
requested by customers will be used for this study. It is another example of an S-Order project. This
case is further introduced in Section 5.2.
This is a typical example of an EAP where a new ECU must be integrated into an existing system
architecture. Specifically, there are 3 architectural decisions to be made:
1. Hardware Alternatives: It is important to identify which ECU within the family of ECUs used in
Scania trucks would be suitable for S-Order purposes. Different hardware have different
interfaces available and that would have an impact on the system architecture.
2. Hardware Topology: The system architecture consists of multiple CAN buses and sub-systems.
Hence it is important to understand the implications of introducing this ECU in various CAN
buses and which part of the network would be optimal.
3. Functional Architecture: This involves defining the interfaces for the new ECU system based
on the functionality that it will be adding. However, this is a broad topic and is not within the
scope of this thesis.
1.3 Disposition This section provides information about the content in this report and where to find them. The key
contributions are also mentioned here.
Chapter 2
This chapter introduces the theoretical background on which this thesis is extending on. It introduces
a typical automotive electrical system architecture and its components and the evolutionary
architecting process. Both the architecture evaluation methods Architecture Trade-Off Analysis
Method (ATAM) and Cost-Benefit Analysis (CBAM) method are introduced in Section 2.3 and Section
2.4 respectively. Section 2.5 describes a lightweight approach proposed as part of this thesis for making
architectural decisions. A brief background about the electrical system in Scania’s trucks is described
as well in Section 2.6.
Chapter 3
This relatively short chapter discusses the motivation behind this study followed by the research
question this thesis aims in answering. The primary methodology that will be used for answering the
research questions is also described.
Chapter 4
This chapter is dedicated to the interviews conducted. Section 4.1 introduces what quality attributes
and scenarios are and how they are going to be used in this study. Section 4.2 presents the utility tree
and how it fits into the methodology. The first version of the utility tree can be found here. Section 4.3
goes deep into the details of the interview methodology followed during the study right from choosing
the stakeholders to presenting the results in the form of codes in Section 4.5. The refined utility tree
11
formed based on the comments from the interviews are also present in Section 4.5. Section 4.4
presents the results from the questionnaires. A generalized list of prioritized quality attributes can be
found here.
Chapter 5
This chapter focuses on case studies that were investigated. The first case study is about the
introduction of a new ECU for customized trucks presented in Section 5.1. Both ATAM and CBAM were
performed in this case study. The results and recommendations for the architecture are also described
here. Section 5.2 describes the second case study that involves a new adaptation to truck cabs. A
heuristic approach was applied to this case study and results are presented here.
Chapter 6
This chapter discusses the key findings and observations found during the study. Section 6.1 discusses
the findings and elaborates on the major trends seen during the interviews. Different aspects about
EAP, Quality attributes and feedback on a heuristic approach is presented here. Section 6.2 looks deep
into the case study involving a new ECU for customized trucks. The challenges of applying this approach
to a new method, key aspects identified are presented here. Section 6.3 explains how the heuristic
approach can be used and what are its pros and cons. Section 6.4 discusses the validity of this thesis
study and what can be concluded from the thesis. Section 6.5 deeply analyses the responses obtained
from the interview questionnaires to identify bias among the participants. The topic of bias and its
effect on this method is briefly discussed here.
Chapter 7
This chapter draws attention to the overall conclusions that can be made from the thesis study and
how the research questions can be answered. It also delves into certain aspects that could be studied
in the future.
12
2 Theoretical Background
2.1 Automotive E/E System Architecture The electrical system architecture is one of the most complex parts of an automotive vehicle. A typical
electrical system consists of individual ECUs (Figure 1) connected by some form of a communication
bus.
Figure 1 Electronic Control Unit by Bosch. Taken from [7]
An ECU can be defined as a microcontroller system with adequate I/O capabilities and is doing specific
functions and interact with the environment. It is also a typical example of an embedded system. The
microcontroller usually consists of the following components:
1. Central Processing Unit: It contains a control unit and an arithmetic logic unit (ALU). It is
responsible for arithmetic and logical computations
2. Input and Output Devices: It consists of necessary peripheral devices and electrical circuitry to
handle signals both as input and outputs.
3. Memory: The memory of the ECU can be divided into program memory and data memory. The
program memory is the part of the memory where the compiled set of instructions (aka the
program) is stored. Data memory is the part of the memory where all the data and variables
needed for the execution of a program are stored. This can be either volatile or non-volatile.
4. Clock Generator: It ensures that all tasks take place within a specific time.
5. Logic circuits: These are modules that perform specialized tasks such as interrupts.
6. Bus System: It is an internal communication system through which all the above components
communicate with each other. [1]
13
Figure 2 Block Diagram for a Microcontroller. Taken from [7]
There are a few special features of an automotive ECU that sets it apart from other industrial
embedded systems for automotive use:
1. Operating Conditions: These ECUs are subjected to a wide variety of conditions depending on
what function it is performing and on what vehicle it is on. It will have to be resistant to
extreme temperatures, indirect materials (oil, fuel), effects of moisture, vibration and other
forms of mechanical stress. For example, an ECU that is managing the suspension of a truck
will have to be mounted close to the axles and will have to be rugged and robust in all
environmental conditions. Depending on the application they have additional EMC
requirements as well.
2. Real-time Capability: These ECUs are responsible for very time-critical functions like Anti-Lock
Brake system and Airbags. Even a delay in the order of milliseconds could prove fatal. Hence,
there are harsh requirements on these systems to complete tasks within predetermined
deadlines.
These ECUs are then connected by some form of a communication bus. The most popular bus for
automotive purposes is Controller Area Network (CAN). CAN is a communication protocol developed
by Bosch as a message broadcast system. It is a carrier sense multiple access protocols with collision
detection and arbitration based on message priority. It is a 2-wire protocol, namely CAN High and CAN
Low. Both the lines are at a median voltage to signify a recessive bit and CAN High is set to maximum
voltage and CAN Low is set to minimum voltage to signify a dominant bit. Data is transmitted as packets
in the bus through CAN Messages. Messages can be of 2 types, standard frame or extended frame and
both have a fixed but different structure. Each message has an identifier field. This identifier also
determines its priority if transmitted simultaneously with other messages. Lower the identifier ‘s
numerical value, higher is the message’s priority. Every message on the CAN bus can be accessed by
every node. Hence, it provides multiple access to the same data.
14
Figure 3 Standard CAN Bus Message Frame [8]
Figure 4 Extended CAN Bus Message Frame [8]
Figure 5 CAN Bus Topology Example [8]
CAN has become the industry standard for communication mainly due to its relatively simple hardware
realization and fault-tolerant nature. In addition to that, these systems can be modelled in a
deterministic way, thus providing assurance for critical communications. CAN enables multiple ECUs
to communicate with each other without having many wires going between them. It reduces the wiring
overhead, by having a single 2-wire twisted pair cable that runs among ECUs. As the bits are
represented with differential signals, a twisted pair makes it less susceptible to external EMI and
reduce its own emissions on other systems.
The J1939 standard was developed by SAE to unify working practices among automotive
manufacturers. It involved standardizing the signals and parameter groups that can be used for certain
physical quantitates. In simpler words, it specifies the namespace that can be used by manufacturers
for different signals they would like to use in their vehicles. This standard is built on the CAN 2.0 B
technology and with extended frames. ECUs are allotted source addresses based on this standard [9].
ECUs usually have a software architecture within itself to enable reusability and modularity. The
architecture usually consists of layers of abstraction. The lowest layer is the closest to the hardware
doing operations on the register level and interacting with the microcontroller resources and
peripherals. Then there would be a service layer which provides different services and utilities to the
top layer. Namely, timers, input, output functionality, interrupts, etc. The topmost layer is where the
actual function is implemented. It makes use of the API provided by the middle layer to realize those
functions efficiently. This form of development improves code readability and debuggability. It
provides a safe way of interacting with the hardware and ensuring no out-of-bound or implausible
15
occurs. For example, the lower levels of the API can handle safety checks for inputs from the
functionality. [10]
Over the years, system architecture has grown very complex and hard to fathom in a single document.
Hence multiple architectural views were used to evaluate and assess different aspects of the system
architecture much more easily. The views provide a logical abstraction to the details of the system
architecture. The most common views used are Functional view, Physical view and Behavioural view.
The functional view sees the system as a collection of functions interacting with each other to meet
the necessary requirements. They are usually represented through functional flow block diagrams
(FFBD). The physical view is more about the layout of the system. This could be the CAN network as
shown in Figure 7. The behavioural view is responsible for showing how the system behaves through
different scenarios and use cases. This can be done through activity diagrams, message sequence
charts etc [11]. A system architecture can be described in many ways using diagrams and documents.
However, in the past few years, architecture description languages have emerged to take care of
having a unified way of documenting system architecture. The most common ones are UML [12],
SysML [13], AADL [14], EAST-ADL [15].
An architectural decision primarily deals with how functionality should be modularized into functional
elements, what interfaces should these functional elements have, how SW elements should be
allocated to HW. It also addresses safety, security, evolvability and maintainability of the E/E System.
Cost and other business factors also weigh in an architectural decision. This will be the context in that
will be addressed in this thesis.
2.2 Evolutionary Architecting Process System Architecture Development is a huge endeavour. It takes multiple resources and a large part of
the organization. The development process can be largely classified into 2. It can either be a
revolutionary architecting process or an evolutionary architecting process. A revolutionary architecting
process (RAP) is when a system architecture is being developed from scratch and backward
compatibility is essentially broken or the systems are new. Whereas, evolutionary architecting process
(EAP) is when changes are made to existing system architecture. RAP is usually done less frequently
and tries to support and re-design the complete architecture and includes a speculative component to
gauge future requirements [16]. The scale and nature of change can be used to further classify them
as a local update or a system update. A local update affects only a part of the system while a system
update affects the whole system. A local update could be when new functionality needs to be
introduced to an ECU or a new ECU needs to be added to the system. A system update could be when
the CAN bus speed is changed all over the system or a new version of software architecture is
introduced in all ECUs.
[16] also delves into the technical areas that are affected during EAP for an automotive embedded
system. They are classified into 6 categories.
1. Systems structure: It is a broad category including the hardware topology of the ECUs,
functional dependencies, function to ECU allocation and all connections between different
ECU systems.
2. ECU Platform: This is mainly focusing on the Software architecture of the ECUs. They include
various abstraction layers that handle different functions like I/O Handling, communication
interfaces, software bootloader support, diagnostics etc.
3. Energy handling: It includes energy storage, generation and management.
16
4. Electrical distribution: It includes more physical aspects like fuse boxes, junction boxes,
grounding etc.
5. External interfaces: for communication and electrical power.
6. Vehicle information management: It includes vehicle configuration and identification.
Most research in this area focuses on software architecture [17]. [18] proposes best practices for
different steps involved in an EAP based on previously conducted industrial case studies. [18] points
out that EAP usually has the following steps in them.
1. Task planning and prioritization
2. Requirement analysis
3. Develop architectural solutions
4. Generate Architectural prerequisites
5. Plan strategic refactoring
6. Architecture Management
[19] suggests a method combining key figure analysis and design structure matrix (DSM) [20] with
qualitative reasoning to develop the architecture. [21] explores the use of methods like Architecture
Trade-off Analysis Method (ATAM) [22] and Analytical Hierarchy Process (AHP) [23] to make a decision
within automotive software and electronics. It concludes that this is a combined approach is usable
and has more benefits than using the above methods individually. It combines the reasoning element
for stakeholders from ATAM and the structured analysis based on AHP. [24] presents a different
approach that can be used for both EAP and RAP. A method using reference architectures are proposed
for architectural development. The main reasons to use a reference architecture are to provide a
documented process that aids task coordination and follow-up ensuring all activities are efficiently
managed and performed. [25] presents a software architecture evaluation method combining ATAM
and Cost-Benefit Analysis Method (CBAM) [26]. In this paper [26], ATAM and CBAM are applied to a
small-scale software project. One of its key findings is that CBAM was able to provide an economic
outlook in addition to the quality attribute-based study of ATAM. They also concluded that CBAM can
complement ATAM well.
[5] conducts multiple case studies to identify the key issues related to E/E system architecture
development. A total of 14 issues were identified ranging from lack of understanding of processes to
poorly motivated decision making. It suggests a few actions to mitigate these unwanted effects. Some
were organizational changes like clarifying responsibilities within the organizational and educating the
management about the architecture development process. Others were more process-oriented, a
need for structured decision making and processes for self-improvement needed to be in place. Hence,
changes both from an organizational and process point-of-view are needed for improving existing EAP
processes. [5] also suggests that the role of different stakeholders involved might identify different
problems and solutions and this can be researched even further.
The primary case study for this thesis involves the introduction of a new ECU system to existing system
architecture. The main purpose of the ECU is to facilitate development for customized truck solutions.
This is a classic example of an EAP; however, it is a special case. Customized solutions for the future
are a very wide problem-space and this poses a challenge for using any structured decision-making
process. However, based on the literature review, a combination of a qualitative and quantitative
method is a promising approach for an evolutionary process within the automotive domain. These
methods are further explored in the following sections.
17
2.3 ATAM ATAM stands for Architecture Trade-Off Analysis Method. This technique was primarily developed to
analyse software architecture. This method considers 4 main primary quality attributes: Performance,
Availability, Security and Modifiability. This method can also be used to analyse the legacy system and
then provide inputs for evolutionary development. The purpose of ATAM as per the document is as
follows:
The purpose of the ATAM is to assess the consequences of architectural decision in
light of quality attribute requirements. [22]
This method can be done early in the development phase and is rather inexpensive and quick. In order
to evaluate different architectural options, it is necessary to have precise requirements based on
Quality Attributes and end up with a clear explanation of different architectural decisions taken.
Hence, these are the main goals for ATAM.
The ATAM can be split into 4 phases
1. Presentation: This phase involves presenting the method, the team to the stakeholders. The
stakeholders can consist of managers, architects, user representatives, administrators, testers,
integrators etc. In addition, business drivers and system architecture are also presented in this
step.
2. Investigation and Analysis: This is the heart of the ATAM, starting by identifying different
architectural approaches. It is crucial to understand how different quality attributes add to the
utility of the system. This can be visualized and compiled into a Utility Tree, further discussed
in Section 4.1. Based on the high priority factors, the architectural options are analysed to
identify risks, sensitivity points and trade-offs.
3. Testing: This is a form of back testing to identify which of the shortlisted architectural options
would respond to different stimuli. These stimulus are recorded as scenarios and they
describe the interaction of the stakeholder with the system. Scenarios are elicited from the
assembled stakeholders. There are 2 suggested ways of doing this, either through a
brainstorming session with the stakeholders. This is more of a bottom-up approach. The
second method is to use utility trees made by the team and is further agreed upon by the
stakeholders. It is more of a top-down approach where the focus moves from a general outlook
to a lower level and specific quality attributes. They are prioritized through a voting process.
After this, the architectural options are re-analysed for further uncover addition risks,
sensitivity points and trade-offs.
4. Reporting: The last step in ATAM involves the presentation of the results to the stakeholder
group. The “pros” and “cons” for each architectural option are presented. All the
documentation including findings in each of the above step is also submitted to the
stakeholders.
The ATAM methods hugely depend on Quality Attributes. Natively, only 4 quality attributes were used
to define software architecture needs. However, an automotive E/E system perhaps cannot be defined
with just these Quality Attributes. Hence a literature study was done to identify what attributes would
be of interest. The findings of this literature study are discussed in Section 4.1. The consensus is also a
big part of how ATAM works and it is achieved through different activities including brainstorming
18
sessions, utility tree reviews and questionnaires. ATAM relies on stakeholders, ranking and voting for
scenarios to identify the most important scenarios that should affect the decision making.
2.3.1 Quality Attributes Software Quality attributes have been used to define non-functional software requirements for years.
They are also used for software architecture development as well [27]. These attributes are usually
first identified in the Software Requirements Specification (SRS) process where the developers write
the requirements in the initial phase of the project. In this phase, both functional and non-functional
requirements are explored and documented. There are standard IEEE templates available for this
process for example, IEEE Standard 830-1998 [28]. This standard includes a subsection for various
quality attributes [29]. However, they are only pertaining to software characteristics. In the next phase
of development, like the architecture development for a project, it is necessary to address these
requirements. The architecture should enable the fulfilment of both functional and non-functional
requirements. Hence, there was a need for architecture evaluation methods that involved quality
attributes to make use of this process and ensure the architecture is aligned with these requirements.
It is important to note that the goal of using different quality attributes is not to create an all-inclusive
set of QAs but to facilitate a framework of thinking.
Based on this need, a set of methods were developed by a research group at Carnegie Mellon
University (CMU). They created methods that evolved over time for software architecture
development. These methods have been adopted widely in different forms and contributed in making
Quality Attributes a more mainstream topic in the industry. Some of the methods they pioneered
were Architecture Trade-Off Analysis Method(ATAM) [22] and Cost-Benefit Analysis Method(CBAM)
[26]. They will be dealt with in the following sections.
Although these quality attributes provide a common basis for looking at requirements both at a lower
level and at an architectural level, they mainly address software issues. However, [29] addresses
quality attributes for embedded systems. This paper evaluates trade studies conducted during the
development of embedded systems. The main goal is to identify correlations among attributes and to
identify attributes that were cited the most. [4] also investigates the considered quality attributes in
academia vs. the industry and tries to identify issues and gaps between them. These sources provided
a starting to point as to which quality attributes should be considered for the primary study for this
thesis. Table 1 shows the initial set of quality attributes that were cited the most in trade studies.
Table 1 Embedded System Quality Attributes [29]
Embedded System Quality Attribute
Commonality/Compatibility
Complexity – CPU, System, Peripherals
Cost
Feature/Functionality
Performance
Physical Size
Power Consumption
Reliability
Weight
19
Embedded systems consist of both hardware and software. Its functionality depends on these
individual domains and the interaction between hardware and software. From the study, it is seen that
most quality attributes used for software can be extended to hardware with modification of its
definition and context. The study also saw that there are quality attributes that were peculiar for
embedded systems.
2.3.2 Scenario Elicitation In this context, scenarios are use cases over the system’s life cycle that are to be satisfied and they can
be elicited in different ways. An example of a scenario could be ‘Additional need of a CAN signal for
the implementation of a new function’. There are 2 methods proposed as part of ATAM and they are
Utility Trees and Brainstorming.
Utility trees are a more top-down approach where each quality attribute is used as a starting point to
further determine how it adds to the utility of the system. They are further discussed in Section 4.1.
This method is usually practiced by the ATAM practitioner along with system architects. The main
output of this goal is to generate a Utility Tree agreed upon by everyone involved and to help
concretize and prioritize driving quality attribute requirements.
Brainstorming is usually conducted in a group, including all kinds of stakeholders for the project. It is
more of a specific to a general approach to identify different scenarios of interest. This approach works
better in larger groups and it facilitates more creativity during the exercise.
2.4 CBAM ATAM provides a framework for architectural decision making and identifying trade-offs. One key
observation is that within the industry most trade-offs are against economics. The cost-benefit analysis
method [26] was developed to provide a quantitative approach to solve an economic trade-off. As the
name suggests, both costs and benefits are considered for each architectural option in this method. A
total return on investment (ROI) is calculated by Equation 1.
Equation 1 ROI
𝑅𝑂𝐼 =Σ𝐵𝑒𝑛𝑖𝑓𝑖𝑡
Σ𝐶𝑜𝑠𝑡
20
Figure 6 Context for CBAM. Taken from [26]
CBAM does not take the decision for the stakeholders, but it provides a tool and a metric for the
decision-makers to base their decision upon. The method assumes that business aspects affect the
architectural decision made. For example, if there is a project that has a short time-to-market then it
is more likely that a solution that satisfies the timeline will be chosen even if it’s not the optimal
solution from a technical point of view. Architectural options will satisfy quality attributes differently
and provide some utility to the stakeholder. These options will also incur some costs for its
implementation and maintenance. This information is important for stakeholders making the decision
and can be suitably captured by ROI. This method was created keeping in mind, its real-life use. [26]
presents a case study where this method was used in a NASA project to identify the architectural
strategy with the highest ROI. However, this method is mainly aimed at software architectures.
The steps involved in CBAM can be briefly described as follows.
1. Refine and rank scenarios: CBAM begins from the scenarios elicited as part of ATAM. Choose
the most important scenarios based on how they satisfy the business goals. Refine them by
giving more emphasis on the stimulus/response for each scenario. These scenarios are
prioritized by the stakeholders by assigning weights to them from a fixed total.
2. Assign utility: Utility is an abstract measure of the usefulness of the system with respect to a
quality attribute. The utility is determined on a relative basis for each of the scenario. It can be
done in levels like best-case, current, desired and worst-case. At this point, each scenario has
a weight associated with it from Step one and 4 values of its utility.
3. Develop architectural strategies that satisfy the scenarios. Identify which scenarios are
affected for each of the architectural strategy and how its response will change.
4. Determine expected utility: For the affected scenarios, an expected utility based on the
strategy must be determined from the change in response. This can be done by extrapolating
the utility curve obtained from the 4 levels of utility scores for the scenarios.
5. Calculate total benefit and cost for each strategy: Each architectural strategy now has a set of
scenarios that it affects and each of these scenarios has a current utility and expected utility.
Using these 2 values, a change in utility can be calculated. These values are then normalized
among all the strategies. In CBAM, it is assumed that the cost is available for different
strategies. They are normalized across all strategies. The sum of all the utilities for a strategy
gives its total benefit and the sum of all costs will give its total cost.
6. Calculate ROI using Equation 1.
7. Confirm results with intuition.
21
This method has been used in domains like enterprise architecture and portfolio valuations [30]. This
method has been recommended for automotive E/E system architecture development in [5] but was
not implemented. [31] looks more deeply into the operationalizing aspect of this method and issues
associated with it. Quality attributes are used extensively throughout this method and in most cases,
they are an abstract concept. This leads to an ‘interpretation problem’ where the stakeholders can
have different interpretations for the same QA based on their background, context etc. Providing clear
definitions can mitigate this effect. Another issue is the possibility of gaming the analysis. Once the
stakeholders understand how the analysis is carried out, they can favour certain scenarios and
attributes to drive the case for their preferred strategy. One way this is mitigated in ATAM is that most
processes are carried out as a group and consensus are essential. For CBAM, this is not a practical
option. One way to mitigate this effect is to be clear on who the primary stakeholders and secondary
stakeholders are. All the rankings and scoring involved in CBAM introduces a lot of uncertainty in the
responses. The same stakeholders can respond differently based on a lot of other factors. CBAM does
provide a way to calculate uncertainty using a probability distribution and finding its variance, to help
determine the certainty of the results.
2.5 Lightweight Framework for Architectural Decision-Making (LFAD) Three observations from both ATAM and CBAM is that they are very extensive methods to guide
decision-making, it requires many stakeholders to be part of the process and is time-consuming. This
led to a proposal of a more lightweight approach that can be used for EAP. It is important to note that
this method merely presents all the information and only aids the decision-making process.
The LFAD approach is a proposed heuristic framework that can be used to view all the available
information about architectural options in question in a more structured and systematic way. This
method is used in Section 5.2 for case study 2 and is further discussed in Section 6.3. The steps involved
in this framework are briefly described as follows:
1) The first step in the framework is to identify the quality attributes that are importance for
architectural decision-making related to automotive electrical systems. This was obtained
from the series of interviews conducted as part of this study. In most cases, the list of attributes
won’t change and hence is a one-time step.
2) These quality attributes need to be ranked based on the priority for the case in question. In
other words, higher the rank higher is its importance. The primary stakeholders of the project
will be responsible for relatively ranking the attributes.
3) Different architectural options must be determined and all available information about these
options should be filled into a table as shown in Table 2.
4) For each quality attribute, a choice must be made among the different architectural option.
5) Make a recommendation based on a heuristic. The choice of heuristic in this step is up to the
practitioner. Some examples are, to choose the option with more high ranking attributes in
favour, or to take a total count of attributes in favour for each option and choice a higher one,
or to add all the ranks of attributes in favour and choose the one with lowest sum.
Table 2 LFAD Sample
Quality Attribute Available Information Architectural option of choice
Availability Option 1 has a larger uptime in theory
Option 1
22
2.6 Scania Electrical System Scania’s electrical system is called SESAMM (Scania Electrical System Architecture made for
Modularization and Maintenance). SESAMM is composed of multiple ECU families and variants. The
hardware topology consists of a central ECU called the Coordinator (COO), which mainly acts as a
gateway between different CAN buses. Each ECU is responsible for one system on the truck. The
electrical system itself can have different variants.
Each CAN bus is separated by its criticality to normal vehicle function. Every truck is equipped with 4
main CAN buses. They are denoted by the 4 colours Red, Yellow, Orange and Green. The ECUs on the
Red bus controls safety-critical functions, for example, the Engine Management System (EMS). The
Orange and Yellow bus consist of ECUs that do affect vehicle function but are not safety critical.
However, there is a difference between them. The Yellow bus is only present in the cabs of the trucks,
while the Orange bus is also present in the chassis of the truck. An example system on the Yellow bus
is the Instrument Cluster (ICL) and for the Orange CAN Bus is the Chassis Management System (CMS).
The ECUs on the Green bus is responsible for functions that do not affect the vehicle’s operation, for
example, Climate Control System (CCS). Figure 7 is a representative figure of the Electrical system,
mainly the hardware architecture.
Figure 7 Scania E/E System [10]
Each ECU on one of these 4 main buses can have a subsystem within them. And they can consist of
different communication protocols like LIN, Ethernet etc.
Bodybuilders form an integral part of the truck supply chain. They are responsible for building extra-
functional equipment on trucks as per customer needs. An example could be, a tipper truck would
need a tipping bucket, which is fitted in by the bodybuilder. The SESAMM system also provides an
23
interface for these bodybuilders. They have access to an External CAN bus, and it provides basic truck
information to bodybuilders for them to build different functionalities. The external CAN network
reduces cost, makes for a simpler installation, ensures higher system reliability and more possibilities
for bodybuilders.
Figure 8 Typical Tipper Truck Adapted by Bodybuilder [32]
The external CAN interface is provided through an ECU called the Bodywork Communication Interface
(BCI) which is on the Yellow CAN bus. The bodybuilders also have a Graphical tool called the Bodywork
Interface Configuration Tool (BICT) shown in Figure 9. They can use this tool to program simple
functionality to realize their functions. The tool consists of a set of functionalities including arithmetic
and logical operators.
24
Figure 9 Bodybuilder Interface Configuration Tool [33]
Scania also provides customized trucks, which partly makes use of this bodywork interface to realize
certain functionalities. The BCI and BICT provides a safe and fast interface to the truck to implement
low volume functions, without affecting the larger product line offered by Scania. However, there are
a few drawbacks to this system.
1. Reduced safety: Since the BICT is an open program, the body-builders have the possibility to
override or modify the factory solution. This is not advisable to customers but is identified as
an anticipated misuse.
2. Reduced functional possibilities: There is a limitation on the information available on the
external CAN bus as they are accessible by bodybuilders. This is done to ensure the safety of
the EE system of the truck and for security concerns
3. Competing for resources: Making use of BCI and BICT reduces the resources (memory, physical
pins) available for bodybuilders to implement their functions. This is a waste of functionality
from the bodybuilder/customer point of view.
25
3 Research Design
3.1 Motivation EAP is a complex and multi-dimensional process. It involves many stakeholders and is usually tagged
to business goals. There are a few interesting aspects of EAP. As pointed out in [5] a lack of a structured
process is one of them. It is difficult to generalize the evolutionary process as there are many variables
and constraints. They vary from project to project and from manufacturer to manufacturer. The
existing systems, business goals, budget and timeline all vary and can affect the decision-making
process. Hence, it might be more suitable to formalize it through a heuristic approach. Another aspect
is the involvement of multiple stakeholders from different backgrounds and a need for a balanced
outcome. These are opposed to an extent and it would be interesting to identify the effects of this on
the outcome. Based on the above aspects and literature review ATAM and CBAM both can be used to
form a decision-making framework for an EAP. As these methods are primarily meant for software
architecture evaluation there will be some modifications that would be needed to make it applicable
for automotive embedded systems. To start with, the quality attributes recommended by ATAM might
not be suitable. [4] and [29] have discussed important attributes from an embedded system
perspective. The concept of scenarios might work in a different way for this domain. It will be
important to understand how bias affects the decision-making process as well.
3.2 Research Question Table 3 Quality Attributes under consideration for RQ
Quality Attribute
Bandwidth Utilization
E2E Latency and Synchronization
CPU and Memory Utilization of the ECU
Flexibility: Physical interfaces and resources
Variability & Reusability: Functional Interfaces
Energy Consumption
Cost: Material cost, development cost, operational and maintenance cost
Physical Size & Weight
Function Complexity
Time to Market
Communication Conflicts
RQ: In the consideration of expanding the ATAM and CBAM methods for distributed embedded system
architecture, which of the above quality attributes should be considered for making architectural
decisions in an evolutionary architecting process? In this extension, is there a bias in the CBAM process
due to the involvement of multiple engineering disciplines?
3.3 Methodology Overview The research question consists of 2 parts. Firstly, to understand how quality attributes can be used to
make architectural decisions with ATAM and CBAM in this domain. Secondly, to understand how a
distributed decision-making framework can lead to bias and understand its effect from an industrial
point of view. The first part can be answered by applying the ATAM process with stakeholders of the
S-Order ECU project, further discussed in Section 5.1. The ATAM process usually involves group
26
activities that last for a few days. As that was not feasible due to availability reasons, individual
interviews were chosen to replace that.
Interviews and questionnaires were used to arrive at an averaged priority ranking from all participants.
Interviews provide a systematic method for documenting stakeholder concerns, views on the S-Order
project and about the use of heuristic methods. The participants will be needed to answer questions
about their development process and about risks, weaknesses for each of the architectural options.
This information will then be used as inputs to the ATAM method. A case study approach will be used
to apply ATAM and CBAM in a specific context. The S-Order ECU Project will serve as the main case
study for both the methods. An additional case study based on the city door project is used to test the
Lightweight Framework for Architectural Decision-making (LFAD) based on quality attributes. Both the
case studies are presented in Chapter 5.
The second part of the research question shall be answered by applying the CBAM process and
acquiring insights regarding scenarios for different architectural strategies. The rankings of quality
attributes and scenarios from different stakeholders through questionnaires shall be used to identify
bias based on their variances in the response. An understanding of the existing processes and the
organizational structure is required to identify logical groups among the stakeholders.
27
4 Interviews
The aim of the interviews is to gain an insight on the current state of practice for evolutionary
architecting. It will aid in capturing the views of stakeholders on the use of quality attributes and
heuristic methods for evolutionary architecting. ATAM requires many inputs from participating
stakeholders including a survey of risks, sensitivities and trade-offs for the chosen case studies from
their point of view. The participants will also need to answer questionnaires for ranking quality
attributes and scenarios for both ATAM and CBAM. Interviews have always been the go-to method to
conduct qualitative research in a systematic way. They ensure a high response rate and reduces
ambiguity. It also gives room for adding follow-up questions to clearly make a case from the
interviewee. Within the scope of this thesis, interviews seem to be the best way to elicit requirements
and ideas from stakeholders regarding EAP and about different architectural strategies.
Section 4.1 presents the quality attributes and scenarios chosen for the S-Order Project. Section 4.2
presents the utility tree showing the link between the quality attributes and scenarios. Section 4.3
explains how the interviews were conducted and what was the procedure followed. A generalized
ranking of quality attributes from both cycles is presented in Section 4.4. The results of the interview
are presented in Section 4.5 as interview codes but are discussed in Chapter 6. Based on the first cycle
of interviews a more complete and relevant set of quality attributes were obtained. The refined utility
tree is presented in Section 4.5.3.
4.1 Quality Attributes and Scenarios There are 2 aspects to the S-Order ECU solution that needs to be addressed through quality attributes.
Firstly, the set of QAs that is relevant for deciding the functional and software aspects of an
evolutionary change. Secondly, the ones that address the hardware aspects of the solution. Based on
both these aspects, the list of quality attributes was then divided into the following 2 sets. Each
interviewee was asked to rank them from 1-12 based on the importance of that QA for decision making
from their own point of view. The attributes are shown in Table 4 and Table 5.
Table 4 Quality Attributes for Software/Functional Aspects
QUALITY ATTRIBUTES
1 Bandwidth Utilization
2 E2E Latency and Synchronization
3 Functionality
4 Variability: Software
5 Reusability: Software
6 Flexibility: Physical Interfaces
7 Time to Market
8 Communication Conflicts
9 Development Cost
10 Operational Cost
11 Maintenance Cost
12 Safety
28
Table 5 Quality Attributes for Hardware Aspects
QUALITY ATTRIBUTES
1 CPU and Memory of the ECU
2 Energy Consumption
3 Functionality
4 Flexibility: Physical Interfaces
5 Time to Market
6 Material Cost
7 Development Cost
8 Operational Cost
9 Maintenance Cost
10 Physical Size
11 Weight
12 Safety
Scenarios form an integral part of this process. They were elicited using the methods discussed in
Section 2.3.2. A set of scenarios were first generated together with stakeholders and they were then
linked to different quality attribute in the utility tree as seen in Figure 10. The scenarios that were of
most concern to the stakeholders were about feasibility and time-to-market. The scenarios for
assessing these 2 aspects are shown in Table 6 and Table 7. Scenarios about feasibility are different
use-cases expected to be relevant during the lifecycle of a system architecture. It comprises of the
usual changes that would be done with the addition of new functionality or change in existing ones.
Scenarios about time-to-market reflects on the effects of organizational processes during evolutionary
architecting. These scenarios together represent how time-to-market can be regarded as a business
goal.
Table 6 Initial Scenarios assessing Feasibility
S1 Additional need for I/O
S2 Additional need for external hardware (sensor, actuators etc.)
S3 Additional CAN message within the same CAN bus
S4 Additional CAN messages on another CAN bus
S5 Shared functionality with other ECUs on the same CAN Bus
S6 Shared functionality with other ECUs on another CAN Bus
Table 7 Initial Scenarios assessing Time to Market
S7 Time for change request acceptance (System-level)
S8 Time for integration testing of new functions
S9 Time for implementation of new functions
S10 Time for change requests in development toolchain
S11 Time required for change requests in the diagnostic toolchain
S12 Time required for answering a product request
29
4.2 Utility Tree
Figure 10 Utility Tree (First Cycle)
The utility tree shows the relation between the quality attributes and scenarios considered for
decision-making. It provides a common basis among all stakeholders and is important to make system
goals more specific and concrete. The utility tree in Figure 10 was created from discussions involving
the primary stakeholders during a brainstorming session and also referring to relevant literature like
[29]. However, its validity has been tested throughout all the interviews. The interviewees were asked
to evaluate each of the quality attributes as to whether it is something considered by them when
30
dealing with evolutionary changes. They were also asked if they would like to add or remove any
attribute in addition to the ones listed. The findings were then incorporated into a refined utility tree,
further discussed in Section 4.5.3.
4.3 Interview Design
4.3.1 Choosing Stakeholders Stakeholders were determined both from a general organizational aspect and from the S-Order ECU
project aspect. The only pre-requisite needed for the interviewees was that they had to be working
within the domain of embedded systems. 3 groups of stakeholders were identified. Firstly, primary
stakeholders to the project. They included engineers from the special trucks division of Scania. They
were the immediate practitioners and enablers for the evolutionary change. Secondly, the system
architect. They were part of the organization that manages the electrical platform of for Scania. Their
roles included functional architecture, hardware architecture and safety. Thirdly, engineers within
Scania working with other ECU systems. Their roles included both system-responsible and function-
responsible.
Apart from the above 3 categories, it was seen that there was a need for a 4th category: engineers
outside of Scania within this domain to validate the generality of the interview results. The external
interviewees included engineers from Volvo Trucks, Volvo Cars, Einride and researchers from KTH.
These companies were chosen based on accessibility and availability within the automotive domain in
Sweden. The different areas of work of the interviewees included functional architecture, hardware
architecture, safety architecture and system owners. The interviewees in total were 10 engineers from
Scania and 5 outside of Scania. A short brief about the interviewees is available in Appendix 9.1.
4.3.2 Introduction Meeting Prior to the interviews, an introduction presentation was given to all stakeholders individually, where
they were given information about this thesis, and the purpose of the interviews. However, detailed
information about the procedure was withheld as it might sabotage the outcome of the interviews.
Information about how different rankings will be used for analysis was not disclosed.
The meeting introduced the evolutionary task at hand, the introduction of a new ECU to the existing
system architecture. It was made clear that the interviews would be recorded for further analysis and
that the content from the interviews will be made use for this study that it will be publicly available as
a disclaimer.
4.3.3 Interview Procedure The interviews are divided into 2 sections. The first section involves 2 questionnaires. The first
questionnaire is a list of quality attributes where each participant is asked to rank them based on
importance while decision making. As each participant is dealing with different aspects of the system
architecture, they were asked to answer it from their point of view, rather than a general outlook. The
list of quality attributes has been split into 2 sets. It was seen that the set of attributes considered
making decisions related to hardware were different from the ones considered for functional aspects.
Hence, the participants were asked to rank them separately. The second questionnaire is about
understanding the feasibility and time required for different processes. These 2 aspects were chosen
as it was the most important from the stakeholder’s point of view and were at least measurable in a
relative way.
As shown in Figure 10, some of the quality attributes have been linked to different scenarios (S#) shown
to the right. These scenarios are then ranked based on feasibility and time as they are considered
31
important by the stakeholder. Feasibility is to be thought with respect to time, resources and number
of systems involved in that scenario.
The questionnaires are followed by a set of open-ended questions with 3 goals. Firstly, to understand
the rationale behind the choice of quality attributes and scenarios. Secondly, to understand their
thought process in decision making and about the procedure followed for evolutionary architecting.
Lastly, to understand the risks and strengths of the different alternatives for adding a new ECU to an
existing system. The responses for the questionnaire were logged and for the open-ended questions
were recorded.
However, the external interviews had a slightly different structure. The questions for them were aimed
at evaluating this process from their point of view. And to validate this approach compared to their
daily practice. They were also asked to evaluate the Utility Tree and the chosen Quality Attributes.
These interviews provide a means of calibration of both the methodology and the outcome of this
thesis.
4.3.4 Interview Transcription and Coding All interviews were recorded and transcribed individually. The transcription was then coded manually
based on a small set of high-level codes followed by a few sub-codes to further represent the case in
point. These recordings were subsequently transcribed and coded for further analysis. The
transcription was checked by other employees at Scania, to ensure validity between the recordings
and the transcription. A few techniques have been used for this process.
A code in this context means a word or a short phrase that represents and captures the essence of a
portion of the interview. This portion of data can then be used for further analysis and for allowing
different ideas and theories to emerge from the data. Coding is considered as a provocative thinking
exercise, allowing the researcher to evaluate the data systematically and thoroughly. Coding can be
done in cycles, usually 2 cycles. The First Cycle usually consists of an initial set of codes, words or
phrases. The Second Cycle might have a further explanation of these solutions and possibly
reconfiguration of the First Cycle Codes. The next step is to develop categories from the codes. This is
done more heuristically to determine which data are ‘look-alike’ and ‘feel-alike’. These categories will
be used as inputs to develop themes and concepts.
Magnitude coding was used for questions about different architectural options. There were aspects
that were for and against each option, which were denoted by the codes ‘POSITIVE’ and ‘NEGATIVE’
respectively. Most of the transcription was coded using the descriptive coding method, where a single
word or a phrase was used along with sub codes. Simultaneous coding was used in some parts as there
were multiple aspects to answers. There were coding outliers, were a set of codes could not be used
to represent the answer. In those cases, In-Vivo coding was used, where the codes were direct
paraphrasing of parts of the answer. A brief overview of the coding methods used can be found in
Appendix A: Coding Methods.
4.4 Interview Questionnaire Results The first cycle of the study involved one-to-one interviews. The interviewees were asked to rank the
quality attributes in the order of importance for decision making. The first set of quality attributes
(Table 4 and Table 5) were used for the ranking. The results (Table 8 and Table 9) were then averaged
in 2 categories, internal (w.r.t. Scania) and External. An overall averaged rank was also calculated.
32
After the first set of interviewees, many additions and clarifications were made to the list of quality
attributes. They were then visualized as a utility tree as shown in Figure 10. A smaller set of internal
stakeholders were then asked to rank the new set of attributes. The results from the second cycle are
presented in Table 10 and Table 11.
The analysis of bias and the topic of validity will be dealt with in Chapter 6.
Table 8 QA (Hardware) Ranking – First Cycle
QA (Hardware) Internal External Overall
CPU and Memory of ECU 6 7 6
Energy Consumption 7 9 8
Functionality 2 3 2
Flexibility: Physical Interfaces 3 6 3
Time to Market 4 4 4
Material Cost 5 5 5
Development Cost 9 2 7
Operational Cost 8 11 10
Maintenance Cost 10 12 11
Physical Size 11 8 9
Weight 12 10 12
Safety 1 1 1
Table 9 QA (Functional) Ranking – First Cycle
QA (Functional) Internal External Overall
Bandwidth Utilization 6 7 7
E2E Latency and Sync 8 5 8
Functionality 1 1 1
Variability: Software 3 9 5
Reusability: Software 4 6 4
Flexibility: Physical Interfaces 5 8 6
Time to Market 7 3 3
Communication Conflicts 9 12 9
Development Cost 10 4 11
Operational Cost 12 10 12
33
Maintenance Cost 11 11 10
Safety 2 2 2
Table 10 QA (Hardware) Rank – Second Cycle
Rank QA (Hardware)
1 Safety
2 Flexibility/ Physical Interface
3 Flexibility/ Variability
4 Robustness
5 Performance/ Synchronization
6 Flexibility/ Ease of Integration
7 Availability
8 Security
9 Performance/ E2E Latency
10 Flexibility/ Extendability, Evolvability
11 Reusability
12 Modularity/ Testability
13 Time to Market
14 Maintainability/ Backward Compatibility
15 Cost/ Material
16 Cost/ Operational
17 Physical Parameters/ Energy Consumption
18 Cost/ Development
19 Physical Parameters/ Size
20 Cost/ Maintenance
21 Physical Parameters/ Weight
Table 11 QA (Functional) Rank – Second Cycle
Rank QA (Functional)
1 Safety
2 Robustness
3 Flexibility/ Variability
34
4 Functionality
5 Usability
6 Flexibility/ Ease of Integration
7 Performance/ Synchronization
8 Security
9 Time to Market
10 Reusability
11 Performance/ E2E Latency
12 Flexibility/ Extendability, Evolvability
13 Availability
14 Modularity/ Testability
15 Maintainability/ Backward Compatibility
16 Cost/ Development
17 Cost/ Operational
18 Cost/ Maintenance
4.5 Interview Code Summary The different aspects raised in all the interviewees are presented in this section. The transcribed data
was then classified and categorized based on the codes in Table 12. The discussion about the most
important findings is in Chapter 6. Codes related to Quality attributes will be presented in Section 4.5.3.
Codes related to the S-Order ECU Case study will be presented in Section 5.1.1.
Table 12 Table of Codes
Main Code Sub Code Sub-Sub Code Description
[EAP:
Evolutionary Architecting Process : Scope]
Scope of EAP
: Examples]
Examples of EAP from stakeholders : Constraints]
Constraints for EAP
[QA:
Quality Attribute : Additional]
Additional QA added by stakeholder
: Rationale]
The rationale for giving importance to certain QA
: Preserved]
Preserved QA during EAP
[Case:
Case Study about S-Order ECU : Risks]
Risks identified for each concept
: Trade-Offs]
Trade-Offs identified for each concept : Sensitivities
Identified sensitivities for S-Order ECU
: S-Order] Sensitivities for S-Order : Organizational] Sensitivities for the organization
35
: Concept]
Functional concepts for S-Order ECU
[Feedback:
Feedback on the method, ATAM, CBAM : Weaknesses]
Weaknesses identified for the method
: Strengths]
Strengths identified for the method : Utility Tree]
Specific feedback about utility tree
4.5.1 EAP This section presents different aspects of evolutionary architecting from the interviewee’s point of
view.
[EAP: Scope]
1. Change in requirements is a very common way of triggering a change in an existing system.
Requirements change due to many reasons like new legal requirements, a new customer base,
competitor market etc.
2. Continuous improvement is another factor that contributes to EAP. Each system usually has a
roadmap that plans for different performance steps to be shipped to the customer. These
performance steps usually call for smaller evolutionary changes for the system architecture.
3. Major technological trends also affect the roadmap of existing systems. For example, the
introduction of automotive ethernet and the advent of data-rich sensor systems together have
pushed the manufacturer to adopt new communication standards.
4. Field quality issues are issues logged from a customer via a workshop/distributor. These can
point out unseen flaws of the system or missed scenarios during development. They are
usually higher in priority and is considered as an EAP. An example could be, a particular
functionality like lifting an axle is not meeting customer requirements in a specific truck axle
configuration. This will then have to be resolved as an EAP.
[EAP: Examples]
While [EAP: Scope] describes what are the possibilities that can lead to an EAP, [EAP: Examples]
presents a few typical changes that would qualify as an EAP for an existing system.
1. Parameterization: Most manufacturers use a parameter-based system for managing vehicle
configurations and vehicle data. In Scania, this is done using FPC codes where different
executions can lead to different functionalities being present or absent from the truck. A
change in parameterization is required when new configurations are being supported.
2. New functionality: This would usually entail software changes and hardware changes like a
new sensor or actuator.
3. Change in functionality: Improvements are always made on existing functionality based on
field-quality, competitors etc.
4. New ECU system: The S-Order ECU project is a typical example, where a new need has been
recognized and is not being handled by any of the existing systems. Hence, there is a need for
a new ECU system. This would trigger a rather elaborate process including hardware and
software introductions.
5. New function allocation: Over time, the introduction of new systems can lead to more
optimized allocation of existing functionalities. Software allocations are usually changed to
reduce the interfaces and dependencies between systems.
6. Change in a supplier: Often externally supplied systems are very rigid and don’t offer room for
customization. This might lead to systems being internally developed and can cause hardware
36
changes. Sometimes, hardware becomes limited or outdated and this can cause a change in
the supplier as well.
[EAP: Constraints]
1. Legacy System: This is probably one of the biggest constraints for an EAP. It is also a reason
why EAP could not be formalized through a process. Most automotive manufacturers have
their own E/E system. Each of these systems was designed based on different philosophies and
design choices. Several aspects of the existing system are usually carried over from previous
generations and can act as constraints during EAP. For example, the physical position of
systems, CAN characteristics and CAN bus segregation, Backward compatibility, Diagnostic
architecture and principles, a toolchain for development, testing and aftermarket needs.
2. Hardware Constraints: This could include the limited number of I/O pins available, resolution
for sensors, CAN baud rate, maximum current and voltage limitations, incompatibility of newer
communication protocols.
3. Manufacturability: Often the best ideas on paper end up being too hard to be assembled in a
reasonable time at the production line. This poses a constraint for changes that can be made
on an evolutionary basis. If the changes were revolutionary, usually the mechanical and
production aspects are also re-engineered but that’s not the case for EAP. Another important
component for any automotive E/E system is the wiring harness. Wiring harnesses are a
complex made-to-measure component specifically build for a vehicle. Adding or removing
connectors or changing physical positions also affect the wiring harness.
4. Certification: There are a lot of certifications involved in the automotive industry. A few
common ones that affect the E/E system were pointed out in the interviews. Electromagnetic
compatibility (EMC), Brake certification, Certification related to perception sensors and
autonomous driving. Recently certification for functional safety based on ISO 26262 has
started becoming an important aspect for architects in the industry. ISO 26262 will force
manufacturers to ensure end-to-end traceability in processes and redundant mechanisms to
be in place. These certification criteria can also act as constraints as it requires additional time
and cost for its fulfilment.
5. Existing Process: Many insights about the processes followed at different OEMs were obtained.
Surprisingly, they all can be described with a few characteristics. All the processes are largely
based on a few experienced individuals, namely system architect. The processes involve
multiple presentations and decision meetings thus slowing down the process. Achieving
consensus in these meetings takes more time than anticipated. An interviewee mentioned that
‘whiteboarding’ is also used as a method to brainstorm and present ideas for evolutionary
changes. Primary practitioners involved in an EAP are unaware of the processes and lead times
downstream after the development is completed.
6. Knowledge base: This is connected to the existing process. Engineers tend to accumulate
knowledge and expertise of a system over the years that they work. As the current process
heavily depends on experienced individuals, it affects the efficiency of the evolutionary
process undertaken by the group. Individuals tend to move within the organization which
contributes to this delay as well.
4.5.2 Feedback This section presents the feedback obtained from the interviewees about the use of ATAM and CBAM
in comparison to their existing process for evolutionary architecting.
37
[Feedback: Strengths]
1. Documentation: The most pointed out strength is that the ATAM and CBAM processes creates
documentation for a process that was largely unstructured. This is a big advantage and
incentive for companies to adopt this practice. The documentation can also serve as a marker
when a revolutionary design phase happens.
2. Pre-study: This method appeals to some as a pre-study. It provides a framework for exhausting
different conceptual solutions before actually spending more time and resources on a project.
The interviewees feel that this process can be adapted to fit in a smaller work footprint so that
it can even be done by a part-time employee/consultant or a thesis student.
3. Structured format: All the interviewees agree that this process is much more structured than
their current approach. The current approach involves investigations by development
engineers to identify feasible options followed by a series of meetings with all stakeholders
and system architects to reach a consensus. The quality of this process and the depth of the
investigation is not measured and is dependent on the engineer responsible. In current
practice, there is very little documentation generated during solution generation and the
subsequent decision making.
4. Verification step: This is connected to the below aspect (A need for high-level questions). The
interviewees are comfortable using this method to verify the findings of the initial set of high-
level questions that determine the direction of the EAP. They agree that this method provides
an easy-to-understand way of looking at architectural options.
[Feedback: Weaknesses]
1. Interpretation problem: A key insight here is that the definition of the quality attributes was
not clear for all the participants. There was a room for interpretation of these quality attributes
based on their own experience and knowledge. Hence, the second cycle of quality attributes
included definitions.
2. Clarity of the level of abstraction for QA: Some aspects of the evolutionary problem are to be
dealt at the system level where the architects must be involved whereas other aspects would
be at a functional level. However, these factors could be related to each other. Lack of this
clarity could affect the success of this method
3. People Bias: The first criteria for this method to be successful is to find the right people with
the right expertise as participants. This is a hugely subjective process. Even after that, there
can be a bias among the participant depending on which part of the organization they belong
to and what their role is.
4. Scope: The scope of this method was not clear to most participants. The participants were
from different parts of the organisation and they had different perspectives about architecture
development processes. They had questions like whether this is to be practiced on a system-
level or for each project or both.
5. Constraints vs. QA: It was seen that most engineers easily mixed up constraints with quality
attributes. This is again linked to the interpretation problem.
6. Measurable QA vs. Abstract QA: Some of the QAs are measurable and concrete like bandwidth
utilization, size, weight, cost while others are more abstract like flexibility, availability and it is
hard to grasp the importance of these QA while ranking. Some of the quality attributes can be
linked to each other. They don’t have clear boundaries and can get fuzzy which might affect
the outcome of this method.
7. The need for a balanced solution: A weakness pointed out was the averaging process of QA
rankings were not very intuitive. The distinction between averaging and biasing needs to be
38
clearer. There was no way to measure or ensure if the final solution addresses most of the
concerns by the stakeholders or not apart from ‘confirming with intuition’.
8. A need for high-level questions: In most cases of evolutionary changes, architects and
stakeholders begin by asking a few high-level questions like how many vehicles does this
change affect, what’s the urgency from the market, how does this affect the on-going projects
for these systems etc. These cannot be fully captured by this method. However, this method
could be used after passing these high-level questions to aid their decision-making process
[Feedback: Utility Tree]
1. Generalizable: Most interviewees agree that the use of a utility tree is generalizable and quite
universal to get all stakeholders on the same view efficiently. There was also interest in
adopting this as a tool that they can use as a checklist for every project.
2. Good for identifying risks: It is a systematic and easy way to think through all the aspects
involved with an EAP. It provided a measurable way to identify strengths and risks for each QA.
They also believe the list of QAs will also be more complete over time. In this way, dependence
on a small number of highly experienced individuals can be reduced.
3. Good for reducing interpretation issues: A suggestion that came out was to include definitions
of QA in the utility tree and this can mitigate the interpretation problem. It reduces
miscommunication among engineers of different backgrounds and expertise.
4. Varying scope of QA: Even though we try to define the QA as concretely as possible, its scope
can vary depending on the project at hand. An example given is the QA ‘Flexibility’ can have
multiple interpretations that are valid but some more important than the others for certain
projects. There is no structured way of handling this discrepancy.
4.5.3 Quality Attributes and Refined Utility Tree
[QA: Additional]
This section explains the different Quality attributes that were added by interviewees in the first cycle
of the study.
1. Availability: An important aspect to stakeholders was the total uptime of a system and how it
is affected by the change introduced. It involves the scope of the change introduced and what
the operable case is. The effect of the evolutionary change on the operation or uptime of any
dependent system is also a part of availability.
2. Safety & Security: Initially in this study, QA were considered from a broad point of view and
these aspects were considered as a part of reliability. However, it was pointed out that they
are more important and had to be dealt with separately. Safety and security are at the core of
any automotive design philosophy. ‘Safety’ addresses the fact that the vehicle can be operated
safely while ‘Security’ ensures that the vehicle itself cannot be easily tampered with. ASIL
ratings, HARA and FMEA were also mentioned as part of acknowledging these QA in the
development process.
3. Robustness: involves the ability of the system to withstand erroneous inputs from the
environment or the user. This is important to reduce the possibility of misuse and unexpected
behaviour.
4. Modularity: This is part of the design philosophy to make functionality modular to reduce
complex dependencies. This is an architectural concern and must be addressed for all
evolutionary changes.
39
5. Maintainability: This QA is interpreted by the interviewees as how functionality can be
maintained from the OEM’s point of view. It includes factors like backward compatibility,
development required in the future etc. Maintainability is assessed from this point of view,
where a newly introduced functionality will undergo changes to increase its useful like,
maximize efficiency, reliability, safety or to cope with new requirements and new
environment.
6. Modified Flexibility: Flexibility was considered in the initial set of QAs but more facets of it
were discovered during the interviews. Hence it was modified for the second cycle of study. In
the first cycle, only flexibility of physical interfaces and ease of integration were considered.
However, the interviewees mentioned they also investigate evolvability, variability,
extendibility as characteristics of flexibility. Evolvability is the ability of the system to change
in the future and how rigid the system is. Variability is how well the architecture can be
expanded or modified to produce variants. An example could be the same architecture being
used for both trucks and buses as two variants. Extendibility refers to the ad-hocness of the
architecture where new systems can be added without affecting existing systems.
Hypothetically, the addition of another CAN bus specifically for special trucks to the Scania
Electrical System would not affect other existing systems, except for the gateway ECU. All
these above factors can be interpreted as some form of flexibility.
[QA: Rationale]
This set of codes highlights the rationale behind some of the highly ranked Quality attributes.
1. Bandwidth & Latency: These were ranked higher because of 2 reasons. Firstly, it was a problem
experienced by the interviewees in their work and secondly because performance criteria are
almost always a design requirement.
2. Flexibility: Usually flexibility is customer demand for OEMs. Customers might want to use a
function in a few configurations. Flexibility also caters to a better business case, as the OEM
aims to achieve more by doing less. It enables them to provide more performance steps to
customers.
3. Functionality: This is always at the core of every discussion and meeting that takes place during
an EAP. Good functionality is defined by the interviewees as meeting all customer and legal
requirements, easy to develop and maintain and have ample possibilities for integration and
evolving in the future.
4. Time to Market: In most cases, it’s a customer demand. It can also be affected by the
competitor outlook, market and economic conditions and technological trends. Time to
market weighs in a lot for the business aspect of an evolutionary change.
5. Safety: This is at the core of the design philosophy and development process at all the OEMs
interviewed. It is only logical to have this is a criterion of prime importance from a
development point of view.
[QA: Preserved]
1. Hardware Topology: within the system architecture evolves very slowly and can be considered
as preserved from an EAP point of view. This means the overall CAN topology and the
functional domains associated with them as well. It is briefly discussed in Section 2.5. The
domains supported by each CAN bus and the network structure is included as well.
2. Modularization: This is an over-arching principle that exists and can trickle down to multiple
QAs. The core idea is that functionality should be separated into logically discrete modules for
better utility. Backward compatibility is enhanced with better modularity. Testing of individual
modules followed by system and vehicle tests are possible. Failure modes are separated across
40
systems, where a failure of one system might not lead to the failure of the vehicle. Interfaces
between functions are the most important part of creating a modular system. All these aspects
are tried to be maintained during evolutionary development. Changes are accepted with clear
reasoning and benefits
3. Physical I/O: Vehicles have multiple configurations which lead to different ECU configurations.
However, the capabilities of individual I/O pins are already fixed and limited. Capabilities like,
certain pins could be used for high current applications while others cannot be used. To
manage them efficiently and reduce complexity, they are usually preserved during
evolutionary processes.
Refined Utility Tree
Based on the above additions and modifications, a more comprehensive utility tree was created for
the second cycle of the study as shown in Figure 11.
41
Figure 11 Utility Tree (Second Cycle)
42
5 Case Study
Evolutionary architecting is a special breed of system architecture development. To understand it
further and to consolidate this heuristic approach a few cases from Scania will be used. Traditionally
for ATAM, this check would be done using scenarios. However, since the nature of the problem within
Customized Trucks is unique, historical cases at Scania are also used to see how previous solutions
match up with the prioritized list of QAs.
The S-Order ECU project will be the primary case study and it involves the introduction of an ECU for
customized trucks. Both ATAM and CBAM will be applied to this case and compared. Feedback from
stakeholders on the results will be sought after the process.
The database of change requests was surveyed to choose cases that were suitable for this kind of
analysis. There were 2 cases that were typical evolutionary development, with enough information
available about the project and involved architectural decision. They were chosen for further analysis.
The first case involves a special adaptation to a truck cab. The second case is about the introduction of
a new feature for lifting axles. Both these cases are good examples of evolutionary development. The
prioritized quality attributes obtained from the interviews will be tested on these 2 cases.
5.1 Case 1: S-Order ECU Scania electrical system consists of 4 main CAN buses gatewayed by a co-ordinator (COO) ECU. The
CAN buses are denoted by the colours red, yellow, green and orange. They have certain characteristics
assigned to them. For example, the red CAN bus is for safety-critical application while the orange CAN
bus is for systems on the chassis etc. A simplified diagram of the electrical system is shown in Figure
12. The bodywork communication interface is located on the yellow CAN bus and it also provides an
external CAN bus to bodybuilders, denoted by blue CAN bus.
Figure 12 Simplified System Architecture
S-order stands for Special Order. If a customer requests a feature that is not currently offered by
Scania’s existing product range, then it becomes an S-Order. Currently, there are 2 ways of
implementing such features. If the functionality is simple and can be realized using simple logic
functions without many dependencies from other systems, then it is implemented via the Bodywork
Communication Interface (BCI). This process has a shorter lead time; however, it makes use of
43
resources meant for bodybuilders and they can tamper with the functionality. If the function has many
dependencies to other systems than it is introduced as a standalone function. In this case, the lead
time is much longer but is safer and more robust of a solution. Both these options have their own
drawbacks as explained in Section 2.5.
Eventually, it became clear that a new ECU system was required for custom functions to provide a
more safe and robust solution to customer with a shorter lead time. An investigation regarding the
new ECU was done as part of a Master’s Thesis [6]. A demand analysis was conducted in [6] where a
survey was conducted on previously implemented S-Order functions to determine which CAN bus was
the most impacted. A fair amount of future functionality was speculated for the analysis. The analysis
suggests that the most impacted CAN bus is the Yellow CAN bus. Another recommendation was the
external Blue CAN bus, as it would provide an abstraction to the existing system architecture. This
evolutionary change of introducing a new ECU is broken down to 3 architectural decisions. The first
architectural decision that needs to be taken is which of these CAN buses will be more suitable for S-
Order, as shown in Figure 13. Recommendations for this decision are made through a qualitative
analysis as a part of ATAM and through a quantitative analysis as a part of CBAM.
Figure 13 Hardware Topology Options
[6] also investigates possible hardware options available for this new ECU. The primary set of demands
concluded from the study are:
• Number of I/O: More than 30 pins
• Type of I/O: Digital, analog, pulse width modulation, interrupt-specific
• Interface: CAN bus, coaxial cable, Ethernet
• Highest output power: approximate 220W
• Maximum current of output: 20A
Based on these requirements there were 2 hardware options that were narrowed down. Some of the
different technical specifications for the 2 options denoted by HW1 and HW2 are given in Table 13.
This architectural decision will be made with the help of quantitative analysis as part of CBAM.
Table 13 Hardware Specification Comparison
Feature HW1 HW2
Low Side Digital Input 8 18
Frequency Inputs 2 4
44
High Power Digital PWM Pin 2 0
Total General-Purpose IO 66 66
CAN Interfaces 6 1
Ethernet Interfaces 2 0
LIN Interface 1 0
Flash Memory (in MB) 6 4
RAM (in KB) 768 512
Cost (in Euro) 500 400
The third architectural decision is to identify a feasible functional concept (To identify major
dependencies for the introduction of this new ECU, how the embedded platform should be set up for
S-Order needs etc.) for the S-Order ECU. A solution that can be both flexible to customer needs yet
have a short lead time. This includes the specification of the interfaces to the ECU. A recommendation
for this will be made from the ATAM process.
5.1.1 ATAM The 2 architectural decisions that need to be made using the ATAM process are the hardware topology
and functional concept. Questions related to these aspects and the case study were asked during the
interviews and were denoted with the prefix [Case:…]. The results from the interviews pertaining to
this case study are presented here.
[Case: Risks]
1. Gateway ECU dependency: If the ECU is to be placed in the external CAN bus, there will always
be a dependency on the BCI ECU as it will be gatewaying messages to other systems within the
truck. It is identified as a risk as there will be more development time required each and every
time a new function/feature has to be introduced or changed. Additional resources will be
required in order to maintain the interface.
2. Integration to current release process: A major concern for the primary stakeholders is to
manage the lead time. Usually, S-Order trucks take about 1 to 2 years of development which
is not ideal. If the ECU is to be introduced in the Yellow CAN bus, every change in function will
trigger a change request process which takes about the same time or longer. The risk here is
the long lead time.
3. New release process: Another option is to have an S-Order release process, that doesn’t
interfere with the releases from other systems. This will force the ECU to be in the external
CAN bus and it also means more workload to develop and test a new release process.
4. Geometric aspect: The new ECU will need to be physically mounted somewhere on the truck.
One possible heuristic is to determine where most of the historical functions were realized,
either in the chassis or the cab. Based on historical data, the ECU should be within the cab, but
physical space is scarce. Wiring and additional electrical units for fuses are also hard to allocate
as the needs for the ECU will vary from customer to customer.
5. Reduced system access: If the ECU is to be in the external CAN bus, the ECU will only have
reduced access to CAN messages and will also be restricted in what functions it can trigger.
This is primarily because the external CAN bus is shared with bodybuilders and they are
considered as external parties. Any CAN message that can affect vehicle operation are usually
not allowed to be used in the external CAN message. In this case, the BCI will have the
additional responsibility of ensuring safety and security.
45
6. Development vs. Volume: Volume of trucks is an important factor that affects the priority of a
project during development. Higher the volume of trucks affected, higher will be its priority.
Usually, custom trucks are ordered in lower volumes and hence suffers during prioritization of
projects.
[Case: Trade-offs]
1. Process quality, Better testing, Flexibility vs. Time to market: As these are new ECUs that are
planned to be used, eventually a new workflow or a modified workflow would be needed for
day-to-day development and testing. This would include steps like requirements management,
software development, testing, documentation. The fidelity of these steps would increase the
time required to introduce a new function. A typical test strategy would include module
testing, function testing, system testing, integration testing and vehicle testing. However,
historically S-Order functions have not been integrated well into the system as it only affected
a certain special configuration and is made to order by a customer. More integration calls for
more testing which increases time to market. Customer orders hugely vary in the functional
domain and size. The process needs to be flexible enough to handle these variations but at the
same time be more flexibility might reduce the quality of the process. More flexible processes
enable a faster time to market. An example for this is the ECU software development can be
based on baselines which are thoroughly tested and introduced, and customer requests can
induce small changes in an already approved SW, and this ensures the faster lead time.
2. Safety vs. Autonomy: If the ECU is in the yellow CAN bus, it will have to follow the existing
release process which has evolved over time and best accommodates different system needs
and manage system interfaces to avoid inconsistencies and ensure more integrity. However,
it means there will be more limitations on the kind of changes that can be done. On the other
hand, if the ECU is on the external CAN bus there will be less overhead due to the release
process, but the quality and safety of the solution might be affected.
[Case: Sensitivities]
1. Need for software development: It is identified that if a change request does not need
software development but only re-parameterization of the software, the lead time is the
lowest (about 1-3 months). If software development is required, the lead time on an average
is 1-3 years. This is a huge difference and hence is a sensitivity for the S-Order ECU.
2. Hardware flexibility: Typically, the allocation of physical pins of an ECU is static. As most ECUs
are function specific the role of a pin rarely changes during the lifecycle of an ECU. However,
this is not the case for customized trucks. A change in the allocation of pins also increases the
lead time. Introducing new hardware takes a much longer time than changes that only require
a software update.
3. Driver Interface: Almost all of the special functions have some kind of interaction with the
driver. It could be an icon on the display or a switch available to the driver to activate or
deactivate a function. It is identified that changes to the driver interface alone increase the
lead time by a year. There is room for modularizing the interface. An example is, bodybuilder
have access to 3 generic buttons and a few tell-tale lights that can be configured through the
BICT (see Section2.5).
[Case: Concept]
1. Firewall Concept: The most repeated idea from most of the stakeholders was a firewall
concept. The primary concern from most system architects is that they needed a way to ensure
that these custom functions will not affect the functioning of the truck. The answer to that is
the firewall concept, where the S-Order ECU will be behind a software firewall that ensures
46
only CAN messages which are tested to be safe are sent or received by the ECU. If the ECU is
in the yellow CAN bus, the firewall will be a functional element within the ECU. If the ECU is on
the external CAN bus, the gateway ECU (BCI) will be the firewall monitoring the
communication. There is an additional risk to this aspect as the BCI will not be able to
distinguish between the S-Order ECU or any bodybuilder connected CAN device.
2. Parameterization: Another concept that can facilitate a short lead time and flexibility is making
use of parameterization. The software in a vehicle can be parameterized to behave differently.
This does not require actual software development and hence has a shorter lead time. The
extent of configurability depends on the functionality and the developer itself.
5.1.2 CBAM The cost-benefit analysis started with an initial set of quality attributes as shown in Table 4 and Table
5. During the interviews conducted with the stakeholders, they were asked to rank them in
importance. The results of the ranking are shown in Table 8 and Table 9. They were also given a chance
to suggest additional quality attributes that they consider for evolutionary changes. This resulted in a
refined set of Quality Attributes. They were again ranked by the stakeholders, resulting in Table 10 and
Table 11. These ranks are used to make weight of the attributes for making a decision.
The output of CBAM is a numerical parameter called Return on Investment (ROI) calculate by Equation
1. In order to calculate ROI, the quality attributes were then split into 2 categories Benefits and Costs.
The heuristic behind splitting the attributes into costs and benefits is, if more of an attribute is better
for the system then it is considered as a benefit otherwise, it’s considered as a cost. In other words,
attributes that is beneficial to be maximized are benefits and the remaining are costs. For example,
weight is an aspect to be minimized and therefore considered as a cost. Reusability in the long run
reduces cost and is a desirable feature hence is considered as a benefit. Even though increasing
reusability might mean increasing material cost, it will still be considered as a benefit since the overall
cost for reusing a part is almost always higher than introducing changes to the existing hardware
platform.
3 primary stakeholders at the S-Order Organization were asked to vote for the 2 options. A template
like Table 14 was given to them and asked to rank each of the options available pertaining to one QA.
Each attribute had a total of 100 votes, and they can be split among the options. This was done for
both choosing the CAN bus and the hardware alternative.
Table 14 Sample CBAM Table
Functional Aspects Stakeholder 1
Split 100
Cost/Benefit Yellow CAN External CAN
Performance/ Synchronization Benefit 65 35
These responses were then analyses to calculate the ROI. The ranking for each quality attribute was
done where 1 was the highest. Equation 2 and Equation 3 are used to calculate the normalized weight
of each attribute. It first reverses the scale of ranking, so that a rank of 1 would have the highest weight,
while a rank of 10 would be lower. They are then normalized on a scale of 0 to 1. Since there are a
larger number of benefit QAs than cost QAs, they must be normalized so that the final ROI is not always
skewed.
47
Equation 2 Normalized Weight (Benefit)
𝑊 𝑖𝐵 =
(𝑇 − 𝑅𝑖)
∑ (𝑇 − 𝑅𝑖)𝐵𝑖=0
Equation 3 Normalized Weight (Cost)
𝑊 𝑖𝐶 =
(𝑇 − 𝑅𝑖)
∑ (𝑇 − 𝑅𝑖)𝐶𝑖=0
Where,
- T = Total number of Quality Attributes (For functional-related its 18 and hardware related
its 21)
- R = Average Rank based on the Second Cycle (See Table 10 and Table 11)
- B = Total number of all benefits
- C = Total number of all costs
Equation 4 Normalized Benefit
𝐵𝑖𝑛𝑜𝑟𝑚 = 𝐵 𝑖
× 𝑊 𝑖𝐵
Equation 5 Normalized Cost
𝐶𝑖𝑛𝑜𝑟𝑚 = 𝐶 𝑖
× 𝑊 𝑖𝐶
Where,
- 𝐵 𝑖 = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑑 𝐵𝑒𝑛𝑒𝑓𝑖𝑡
- 𝐶 𝑖 = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒𝑑 𝐶𝑜𝑠𝑡
- 𝐵𝑖𝑛𝑜𝑟𝑚 = 𝑁𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 𝐵𝑒𝑛𝑒𝑓𝑖𝑡
- 𝐶𝑖𝑛𝑜𝑟𝑚 = 𝑁𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 𝐶𝑜𝑠𝑡
- 𝑊 𝑖𝐵 = 𝑁𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 𝑊𝑒𝑖𝑔ℎ𝑡 𝑓𝑜𝑟 𝐵𝑒𝑛𝑒𝑓𝑖𝑡 𝐵
- 𝑊 𝑖𝐶 = 𝑁𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 𝑊𝑒𝑖𝑔ℎ𝑡 𝑓𝑜𝑟 𝐶𝑜𝑠𝑡 𝐶
Equation 6 Total Benefit with Equal Weights
𝐵𝑒𝑞𝑢𝑎𝑙 = ∑ 𝐵 𝑖
𝐵
𝑖=0
Equation 7 Total Cost with Equal Weights
𝐶𝑒𝑞𝑢𝑎𝑙 = ∑ 𝐶 𝑖
𝐵
𝑖=0
Equation 8 Total Benefit with Normalized Weights
𝐵𝑛𝑜𝑟𝑚 = ∑ 𝐵𝑖𝑛𝑜𝑟𝑚
𝐵
𝑖=0
48
Equation 9 Total Cost with Normalized Weights
𝐶𝑛𝑜𝑟𝑚 = ∑ 𝐶𝑖𝑛𝑜𝑟𝑚
𝐵
𝑖=0
Table 15 CBAM Functional QA
Functional QA Cost/Benefit 𝑹𝒊 𝑾 𝒊𝑩
Yellow
CAN(𝑩 𝒊 )
External CAN
(𝑩 𝒊 )
Yellow CAN
(𝑩𝒊𝒏𝒐𝒓𝒎)
External CAN
(𝑩𝒊𝒏𝒐𝒓𝒎)
1 Performance/ Synchronization Benefit 7 0.08 68.33 31.67 5.29 2.45
2 Performance/ E2E Latency Benefit 11 0.05 61.67 38.33 3.18 1.98
3 Availability Benefit 13 0.04 55.00 45.00 2.13 1.74
4 Flexibility/ Variability Benefit 3 0.10 53.33 46.67 5.51 4.82
5 Flexibility/ Extendability, Evolvability Benefit 12 0.05 56.67 43.33 2.56 1.96
6 Flexibility/ Ease of Integration Benefit 6 0.08 50.00 50.00 4.19 4.19
7 Reusability Benefit 10 0.06 50.00 50.00 2.90 2.90
8 Maintainability/ Backward Compatibility Benefit 15 0.03 53.33 46.67 1.38 1.20
9 Modularity/ Testability Benefit 14 0.03 56.67 43.33 1.83 1.40
10 Safety Benefit 1 0.12 56.67 43.33 6.58 5.03
11 Security Benefit 8 0.07 71.67 28.33 5.09 2.01
12 Robustness Benefit 2 0.11 63.33 36.67 6.95 4.02
13 Functionality Benefit 4 0.10 60.00 40.00 5.81 3.87
14 Usability Benefit 5 0.09 53.33 46.67 4.82 4.22
Functional QA Cost/Benefit 𝑹𝒊 𝑾 𝒊𝑪
Yellow
CAN(𝑪 𝒊 )
External
CAN(𝑪 𝒊 )
Yellow CAN
(𝑪𝒊𝒏𝒐𝒓𝒎)
External CAN
(𝑪𝒊𝒏𝒐𝒓𝒎)
15 Time to Market Cost 9 0.63 80.00 20.00 50.00 12.50
16 Cost/ Development Cost 16 0.19 66.67 33.33 12.50 6.25
17 Cost/ Maintenance Cost 18 0.06 53.33 46.67 3.33 2.92
18 Cost/ Operational Cost 17 0.13 46.67 53.33 5.83 6.67
Table 16 CBAM Hardware QA
Hardware QA Cost/Benefit 𝑹𝒊 𝑾 𝒊𝑩
HW1(𝑩 𝒊 ) HW2(𝑩 𝒊 ) HW1
(𝑩𝒊𝒏𝒐𝒓𝒎)
HW2
(𝑩𝒊𝒏𝒐𝒓𝒎)
1 Performance/ Synchronization Benefit 5 0.09 63.33 36.67 5.55 3.21
2 Performance/ E2E Latency Benefit 9 0.07 63.33 36.67 4.24 2.46
3 Availability Benefit 7 0.08 50.00 50.00 3.87 3.87
4 Flexibility/ Physical Interface Benefit 2 0.10 60.00 40.00 6.19 4.12
5 Flexibility/ Variability Benefit 3 0.10 50.00 50.00 4.90 4.90
6 Flexibility/ Extendability, Evolvability Benefit 10 0.06 60.00 40.00 3.71 2.47
7 Flexibility/ Ease of Integration Benefit 6 0.08 58.33 41.67 4.81 3.44
8 Reusability Benefit 11 0.06 53.33 46.67 3.02 2.65
49
9 Maintainability/ Backward Compatibility Benefit 14 0.04 53.33 46.67 2.20 1.92
10 Modularity/ Testability Benefit 12 0.05 50.00 50.00 2.58 2.58
11 Safety Benefit 1 0.11 50.00 50.00 5.41 5.41
12 Security Benefit 8 0.07 50.00 50.00 3.61 3.61
13 Robustness Benefit 4 0.09 53.33 46.67 4.95 4.33
Hardware QA Cost/Benefit 𝑹𝒊 𝑾 𝒊𝑪
HW1(𝑪 𝒊 ) HW2(𝑪 𝒊 ) HW1
(𝑪𝒊𝒏𝒐𝒓𝒎)
HW2
(𝑪𝒊𝒏𝒐𝒓𝒎)
14 Time to Market Cost 13 0.24 50.00 50.00 12.16 12.16
15 Cost/ Material Cost 15 0.19 58.33 41.67 11.04 7.88
16 Cost/ Development Cost 18 0.11 50.00 50.00 5.41 5.41
17 Cost/ Maintenance Cost 20 0.05 50.00 50.00 2.70 2.70
18 Cost/ Operational Cost 16 0.16 51.67 48.33 8.38 7.84
19 Physical Parameters/ Size Cost 19 0.08 55.00 45.00 4.46 3.65
20 Physical Parameters/ Weight Cost 21 0.03 55.00 45.00 1.49 1.22
21 Physical Parameters/ Energy Consumption Cost 17 0.14 51.67 48.33 6.98 6.53
Table 17 ROI Calculation with Equal Weights
Yellow CAN External CAN HW1 HW2
𝑩𝒆𝒒𝒖𝒂𝒍 4.13 3.01 4.23 3.46
𝑪𝒆𝒒𝒖𝒂𝒍 15.42 9.58 6.59 5.91
𝑹𝑶𝑰𝒆𝒒𝒖𝒂𝒍 0.27 0.31 0.64 0.59
Table 18 ROI Calculation with Normalized Weights
Yellow CAN External CAN HW1 HW2
𝑩𝒏𝒐𝒓𝒎 4.16 2.99 4.23 3.46
𝑪𝒏𝒐𝒓𝒎 17.92 7.08 6.58 5.92
𝑹𝑶𝑰𝒏𝒐𝒓𝒎 0.23 0.42 0.64 0.58
Based on the CBAM analysis, the hardware topology where the ECU is on the external CAN and is using
hardware option HW1 have a better ROI than the other options. The results are similar in both cases
where the weights are taken to be equal and normalized based on the ranks.
5.2 Case 2: City Door Project The City Door Project is a project for special trucks, where the passenger door in the truck cab is
replaced with a sliding door. This was a request from garbage vehicle collectors as they needed to get
in and out of the vehicle several times a day. Opening and closing the truck door repeatedly was not
an ergonomic solution and is accompanied by fatigue for the user. For applications within the city, and
in narrow spaces, having an inward sliding door will improve the usability for the customer. This feature
will initially be available in the L-Series cabs sold by Scania. The sliding mechanism will be powered by
DC Motor which needs to be controlled by an ECU. This is a typical example of an S-Order Function as
it involves the addition of hardware, functionality and signals/messages to the system. For the
complete implementation of this function, the new hardware will also have to be interfaced with the
existing door control system and central locking system. This function can be implemented in many
ways and determining among different alternatives from an architecture perspective can be an ideal
example for this case study. A prototype of such a cab and a door is shown in Figure 14. There were 2
50
architectural decisions as part of evolutionary development in this project. Background information
about the decisions was available and will be used in the framework of Quality attributes. However,
the information was unstructured and hence will be classified based on the affected quality attribute.
Figure 14 Truck Cab with a City Door [34]
The averaged quality attribute ranking obtained from the interviews might not be valid for this case
study. As constraints, stakeholders, customer requirements vary from project to project, it is necessary
to understand what the priorities are for this case. Hence, a new prioritized ranking for this project
was obtained from the stakeholder and will be used in LFAD.
D1: BCI vs. DCS
One of the first steps followed in an EAP is to determine if there are any existing systems that can cater
to the customer requirements. If not, the closest candidate systems are chosen for further
investigation. There were 2 candidate systems chosen for this project. The bodywork communication
interface (BCI) and the Door Control System (DCS). The LFAD approach is performed for the available
options as shown below.
Table 19 LFAD Approach for D1
Case-specific Rank
QA Available Information Preference
1 Functionality Same irrespective of ECU Equal
2 Availability DCS has better availability because all information and interfaces required for the functionality is already available. For example, lock status. BCI will not be
DCS
51
available for one scenario when compared to DCS.
3 Time to Market The faster development time for BCI as PDS was an externally developed system
BCI
4 Cost/ Development Development cost would be higher for the DCS system as it’s an externally supplied system.
BCI
5 Security Same as both systems are internal systems. Same failure modes and risks apply to both.
Equal
6 Safety Same as both systems are internal systems. Same failure modes and risks apply to both.
Equal
7 Flexibility/ Variability
BCI is a more flexible system as it is a Scania developed node.
BCI
8 Flexibility/ Ease of Integration
BCI is easier to integrate as it is developed by Scania and has been used for previous projects. This gives engineers a more familiar technical background.
BCI
9 Flexibility/ Extendability, Evolvability
There are limited options for evolving with the BCI as it is not within the functional domain of this project. In the long term, the functionality would be handled by the DCS
DCS
10 Usability Same irrespective of ECU Equal
11 Performance/ Synchronization
Not significant
12 Performance/ E2E Latency
DCS is already within the primary functional domain and will have a higher performance compared to BCI.
DCS
13 Modularity/ Testability
Same irrespective of ECU Equal
14 Robustness If the truck is switched off in the middle of performing an action, there is a chance of data loss, if the function is implemented in the BCI.
DCS
15 Reusability Same irrespective of ECU Equal
16 Maintainability/ Backward Compatibility
Backward compatibility not applicable as it’s a new introduction
17 Cost/ Operational Same irrespective of ECU Equal
18 Cost/ Maintenance BCI will have lower cost as its internally developed system.
BCI
This framework gives the stakeholder an overview of which option is better considering different
attributes. The heuristic used here is to look at the architectural option that satisfies most quality
attributes in total. More of the higher-ranked quality attributes (Time to market, Development Cost,
and Variability) favours the BCI option. The actual decision and the outcome from this framework both
agree in choosing the BCI for the implementation.
52
D2: BCI vs. EXT-ECU
As part of the project, external ECU(EXT-ECU) options were also investigated. This led to the second
architectural decision where the BCI option is compared with an External ECU. The same framework
followed in D1 is repeated. The decision-making process was made through a string of meetings that
spanned for about 6-8 weeks.
Table 20 LFAD Approach for D2
Case-specific Rank
QA Available Information Preference
1 Functionality BCI system was not able to develop the functionality to meet requirements
EXT-ECU
2 Availability Same irrespective of ECU Equal
3 Time to Market EXT-ECU requires less development compared to BCI and hence is preferred.
EXT-ECU
4 Cost/ Development BCI will be cheaper to develop as it is an internal system
BCI
5 Security Same irrespective of ECU Equal
6 Safety Same irrespective of ECU Equal
7 Flexibility/ Variability
BCI cannot allocate pins dynamically, but future changes are easier than tw465
BCI
8 Flexibility/ Ease of Integration
BCI is easier to integrate from an S-Order point of view
BCI
9 Flexibility/ Extendability, Evolvability
The hardware specifications of the EXT-ECU are better compared to BCI and will be able to accommodate changes more easily in the future.
EXT-ECU
10 Usability Same irrespective of ECU Equal
11 Performance/ Synchronization
Not significant
12 Performance/ E2E Latency
Not significant
13 Modularity/ Testability
EXT-ECU will be tested by the supplier and can be validated using their tools. As it’s a standalone system with only 1 CAN interface it is easier to test and validate compared to the BCI which has multiple other functions.
EXT-ECU
14 Robustness BCI will be a more robust system as its BCI
15 Reusability The external ECU will not be reusable for similar purposes as it will be made to satisfy the requirements of this project. On the other hand, BCI can be developed in a reusable way.
BCI
53
16 Maintainability/ Backward Compatibility
Backward compatibility not applicable as it’s a new introduction
17 Cost/ Operational Same irrespective of ECU Equal
18 Cost/ Maintenance BCI will have lower cost as it’s an internal system
BCI
In this case, the above table shows that EXT-ECU meets more of the highly ranked attributes than the
BCI. The actual decision was also to use the external ECU as the project was closer to its timeline and
that is very high in priority (ranked 3rd). The LFAD approach was useful in laying out all the available
information in a prioritized manner.
54
6 Discussion
6.1 Interview Summary In this section, the responses from the interview will be analysed further. The following sections are
divided by their interview codes.
6.1.1 EAP One key observation was the different parts of the organization had different views on what causes an
EAP. Although, the actual scope and definition of an EAP were the same throughout. Change in
requirements, continuous improvements, major technological trends and field quality issues were the
main causes for an EAP. The interviewees closer to research and development in the organisation cited
major technological trends and continuous improvements, while interviewees closer to aftermarket
and sales cited a change in customer demands and field quality issues. Even though the current job
positions are system architecture related, their previous work experience seems to weigh in on their
outlook.
The interviewees were also asked to give examples of an EAP according to them. There were many
constraints expressed by the interviewees regarding performing an evolutionary change on the system
architecture. The biggest concern was that their heavy dependence on the existing system. These
systems have evolved over the years to the specific needs of the OEM and it is quite hard to generalize
this aspect and is an obstacle in developing a generalized method for EAP. Even if they could be
formalized, manufacturing criteria and legal requirements are vastly different between OEMs. Safety-
critical systems are developed using rigorous testing and validation procedures, sometimes including
external validation. Heuristic approaches don’t offer the level of certainty required by system architect
at OEMs and it will be difficult to introduce such a method to daily practice. Functional safety is
becoming a hot topic within system architecture development among experts. All manufacturers
interviewed are adapting their processes and systems to meet the functional safety standards ( for e.g.
ISO 26262 standard). There isn’t even a clear distinction of systems that would have to satisfy these
requirements yet. These uncertainties make it harder for formalizing an evolutionary process.
An organizational aspect of development is that knowledge and expertise about different systems are
accumulated over the years in different parts of the organization. This means that there is a possibility
that the most relevant engineers for making evolutionary decisions might end up being left out of the
process. Even though system architects can provide insights about system impact and pros and cons
for a decision, detailed expert views might be lost. All the OEMs interviewed has expressed this issue.
Sometimes evolutionary decisions like function allocation and development are affected by how the
organization is structured rather and if a smaller development group can or cannot undertake the
development responsibility.
There was a stark contrast between the interviewees working with heavy vehicle and passenger cars.
The major difference seen is the time horizon of both these industries are quite different. Heavy vehicle
manufacturers usually have a larger time frame for development (3 years to 10 years) while its much
shorter for light vehicle manufacturers (less than a year to 3 years). Heavy vehicles offer much more
variability in the products as these trucks sold are eventually used by businesses. Each business has a
varying set of requirements and a larger product variability means that they do more evolutionary
changes than passenger vehicles.
55
6.1.2 Feedback There were many aspects bought up by the interviewees. They were classified as strengths,
weaknesses and utility tree related. In contrast to the current process for evolutionary changes, this
method of using ATAM and CBAM created more documentation and was more structured. Another
advantage pointed out by interviewees are that this method can be used as a framework for doing a
pre-study of evolutionary changes. The current method followed for a pre-study involves 2 main steps.
Firstly, to determine if there are any existing system where the evolutionary change is most logical and
secondly, to determine if there exists an external off-the-shelf solution that can be used. These are
conducted by the responsible engineers in a very unstructured way and usually does not result in a lot
of documentation. However, if the same processes are conducted using the ATAM and CBAM approach
it would create documentation and provide a framework in choosing among different alternatives. The
challenge is to balance the effects of different quality attributes.
A more conservative approach mentioned in the interviews was to use this new approach as a
verification step in addition to the investigation conducted by development engineers. This mitigates
the effects of weighing certain attributes differently to an extent but provides a means for checking
their primary decision against something else. Providing a rather definite set of quality attributes to
engineers to determine the end value of their solution is itself a better approach to EAP than the
Scania’s development method.
One of the major weakness pointed out by the interviewees is the ‘interpretation problem’. The
engineers working with these problems are not particularly well-versed with the concept of quality
attributes. The terms used for quality attributes are rather broad and have a room for interpretation.
This can prove to be costly if different engineers have their own definitions. This did happen in the first
cycle of the study and hence, definitions were introduced for the second cycle of the study. The
interpretation problem leads to other issues like clarity in the level of abstraction, mixing up QAs with
constraints and the concept of measurable and abstract QAs. All these issues were identified during
the interviews. Quality attributes often have a certain level of system abstraction to which it is
applicable. Certain attributes are more system-level while others are more related to the function. For
example, Usability is an attribute that is assessed on a functional level while flexibility is assessed on
an architectural level as it is the collective flexibility of all systems, interfaces and topology. Constraints
are the limits of the project scope and quality attributes are the different desirable aspects of the
system of interest that improves its utility. It was seen more than once that engineers did mix them
up. Some QAs are not physically measurable quantities for example flexibility. System architect pointed
out that guidelines would be needed in how these QAs can be measured.
The interpretation problem can be addressed only through introductory training of some kind to
prospective practitioners. This enables a uniformity within an organization in how these attributes are
perceived and dealt with. The need for homogeneity in semantics is key for this method to be
successful in an organization. System architects mentioned that there are other factors that affect their
decision making that is not captured in this method, like the demands from the market and
competitors or the volume of trucks affected and budget available for the project. These aspects need
to be dealt with separately as they impose over-arching constraints on the decision-making process
and their addition to the list of attributes might hinder architects from choosing the best concept from
the technical standpoint. The ATAM/CBAM approach needs to be modified to include such questions.
A suggestion was to implement a 2-phase process, where the first phase is about identifying
constraints and over-arching design philosophies for the EAP. This phase would be different for each
OEM as it is dependent on their existing system, design philosophy, business condition etc. The second
56
phase can be rather generalized and be performed using the ATAM/CBAM approach based upon the
limitation imposed in phase 1.
The utility tree provided a more visual representation of the quality attributes to the interviewees. It
was a guiding tool for them before they could prioritize and rank the QAs. It is seen that this can be
generalizable among different automotive manufacturers if the system of interest is an automotive
embedded system. However, the rankings and scope of different quality attributes considered might
vary depending on the project at hand and is not adequately captured by this method. It might be
useful to evaluate the scope on a case-by-case basis instead of trying to universally define it. Quality
attributes can be interpreted differently based on the problem at hand and that needs to be
considered.
6.1.3 Quality Attributes The initial choice of quality attributes has been evaluated by the interviewees. Suggestion on additional
attributes that they consider were also recorded. The first cycle of the study consisted of broader and
fewer QAs, but it was observed that system architects prefer a more specific set of QAs. This led to
breaking down multiple QAs into sub Quality Attributes and defining them accordingly. ISO 25000
elaborates on quality attributes with respect to software aspects and gives standard definitions for
them. This was used to further develop definitions and classifications of the quality attributes. Several
quality attributes were added by the interviewees during the interviews. They were either clarifications
to existing ones or aspects that were missed in the first cycle of the study. Various interpretations of
quality attributes also led to some additions. For example, flexibility could apply to hardware interfaces
and ease of integration, evolvability and variability management.
Certain attributes were consistently ranked as one of the top QAs. There were 2 major reasons that
drove the affinity to certain attributes. Either it was part of the OEM’s design philosophy or it was a
problem that they have recently faced. Another observation was that some quality attributes or
features of the system were very rarely changed. These include the overall hardware topology and
physical I/O allocation of pins on an ECU.
It is clear that there is a need of a common basis of evaluation and quality attributes are certainly
equipped for doing that. However, it is important to note that producing a prioritized list of quality
attributes that is universally applicable is close to impossible. As seen from the case studies system
needs are different from that of project needs. The closest to a universal ranking is presented in Table
10 and Table 11.
6.2 Case Study: S-Order ECU
6.2.1 ATAM
The ATAM process included a set of interviews with stakeholders and system architects. Different
concerns from them were identified and recorded pertaining to the S-Order ECU case study. Risks,
trade-offs and sensitivities were identified.
Among the risks that were identified the biggest one was related to the release process. Release
processes are used to systematically introduce tested and validated software to production and
subsequently to the aftermarket. The requirements for the S-Order ECU are very different from most
existing systems and probably cannot be accommodated in the existing release process. Integration
testing and vehicle testing would be a major bottleneck as S-Order will be testing very custom features
on very custom configured trucks. This would slow down the release for all other systems and that is
not acceptable. Geometrical and production-related issues were also bought up. These are concerns
that are usually not handled by research and development but can save a lot of time and money
57
downstream if they are considered early in the development process. The ATAM process forces
engineers to look at all aspects that would result in some kind of utility during decision making.
According to system architects, trade-offs are the hardest part of decision making. The first step
involved identifying the trade-offs which can be achieved through this process. Some of the trade-offs
identified were quality of development vs. time to market. Especially for S-Order where time to market
is much shorter, there must be trade-offs made to the amount of testing that can be done or the extent
of performance steps that can be offered to the customer. Another way to reduce time to market is to
reduce the overheads involved in processes. Overheads are the parts of the processes that overflow
from its designated timeline. These arise due to complex dependencies, inefficient decision-making
etc. This is also a trade-off as more of the milestones in a typical development process are bypassed,
there are risks that the function doesn’t meet organizational requirements like aftermarket support.
However, ATAM does not help in determining the thresholds for these trade-offs.
ATAM was also useful in identifying the factors that had the most impact on the outcome. For example,
if customer requirements can be satisfied without software development or new hardware then it is
much easier and faster to make a change in the system. Another bottleneck identified was the need
for a driver interface. Most of the functionalities developed need some kind of driver interaction and
by finding a way to modularize it can speed up the development time in the long run.
In its essence, ATAM provides a structured way of surveying different aspects of a project. OEMs
currently rely on group meetings and presentations for this and there is a good chance that certain
aspects are missed or overlooked. The use of quality attributes to classify and identify risks, trade-offs
and sensitivities make it easier to prove coverage of the investigation conducted. As shown through
this case study it can be easily extended to the automotive embedded systems. The quality attributes
and the utility tree that have been formed during this thesis is fairly generalizable as validated by
external interviewees. However, the process can be further adapted to fit the different manufacturer’s
needs. More time would be needed to reach a consensus about the quality attributes that are of
concern and what its interpretation should be within the organisation.
6.2.2 CBAM CBAM introduces a quantitative aspect of the decision-making process. It uses the ranks given by the
stakeholders on different quality attributes as its weight. Quality attributes are divided into 2
categories: Benefits or Costs. The primary stakeholders then rank different architectural options for
each of these quality attributes and then averaged out to give a total cost and benefit for each option.
A total return-on-investment or benefit-over-cost is then calculated for each of the options indicating
which option would yield a higher benefit at a lower cost.
There are a few challenges that were identified during the study. It is hard to explain the physical
significance of ROI values. These ROI values are generated from the ranking procedure and don’t
clearly show the ratio between benefits and cost. However, the cost can be measured more reliably.
Most quality attributes of the system cannot be measured. The weights obtained from the process
shows the relative importance of different quality attributes and they should not be mistaken as
measures of these quality attributes. There is a risk of losing important information while averaging
out the responses from all the stakeholders. This can lead to a distorted outcome rather than a
balanced one and it is really hard to address it in a mathematical way. However, one test that was
done during the case study was to calculate ROI with and without considering the weights. Table 17
shows the ROI calculation considering equal weights among all the attributes and Table 18 shows the
ROI calculation considering the weight obtained from the ranking procedure. Even though the
58
outcome of both these rankings is the same, it is hard to guarantee that no valuable information was
lost in the process.
6.3 LFAD The lightweight framework for architectural decision-making (LFAD) is a spin-off from the ATAM/CBAM
approach considering the time and effort required to perform the latter for a project. ATAM or CBAM
requires many stakeholders from different parts of the organization to take part in order to arrive at a
decision. This might not be practical in most OEMs. Hence, a simpler approach was devised using
quality attributes as the basis to aid architectural decision making. The approach involves collecting
and presenting information based on each quality attribute for different architectural options
available.
The pros of this process are that it is a lightweight version of the ATAM process. It requires less
involvement from other groups in the organisation. It can reuse the already agreed upon the template
of quality attributes. The cons of the process are that, even this method requires all practitioners to
have the same interpretation of quality attributes and that it is homogeneous within the organisation.
There can be aspects that relate to multiple quality attributes in different ways and that can be hard
to capture in this simple approach. During the case study, it was seen that the QA ranking can change
drastically depending on the technical domain of the project, the timeline involved, market conditions,
the number of groups in the project etc. Hence, a case-specific ranking is needed to address these
changes on a case by case basis.
6.4 Validity Validity is an important aspect of studies involving interviews and case studies. It gives an idea about
what can be safely concluded from this thesis.
6.4.1 Internal Validity The choice of interviewees can hugely impact the outcome of the study. For this study, the
interviewees were chosen with the help of both industrial and academic supervisor. The primary areas
of expertise were identified first. This included system architecture development, function
development for the case studies. System architects were the first choice within Scania as they were
the closest job roles with the responsibility of architectural development. There was an equal
representation of hardware architects and functional architects. As the case study involved the
integration of a new ECU to the existing system architecture, historical projects that were of the same
nature was first searched for. One such project which is recent and 3 engineers that worked with the
systemization and introduction of the new ECU was also included as interviewees. A profile of all the
interviewees is available in Section 9.2. The resulting utility tree and relevant quality attributes are
dependent on the participants and their backgrounds as well. It might be the case that, with different
participants the study would have resulted in a different set of quality attributes.
The total number of internal interviewees were limited to 10 as the time plan for this thesis study only
allowed for that. This might have some effects on the results. As the sample size is low, there might be
chances of certain important aspects being missed out. The outcomes of the ranking questionnaire are
limited to what the participants believe based on their knowledge and experience of the subject. Since
the sample size is low, there are no claims of the averaged outcomes to be of any statistical
importance.
All the interviews were recorded and transcribed. The transcription was checked twice by the
interviewer. The samples were randomly checked by another colleague and industrial supervisor at
Scania. There is an unconscious or conscious tendency of the interviewer to search for certain
59
information. To reduce this effect, most questions were open-ended, and the interviewees were
expected to make their point.
The methods used such as ATAM and CBAM also had to be modified slightly to extend them to a new
domain and for practical reasons. ATAM is generally performed in groups, where all the stakeholders
are attending a multi-day workshop and they perform all the processes together. In this way,
consensus can be almost guaranteed at the end of the workshop. However, in a practical sense, it was
very difficult to assemble the 10 participants for a workshop. Since the participants will have to be
from different technical backgrounds it would be easier to conduct an interview individually instead of
conducting it in smaller groups. Hence, individual interviews were chosen and to ensure consensus a
second cycle of the study was introduced where they were given a chance to review a refined utility
tree and provide their rankings. The CBAM method was slightly modified as well. Usually, the costs and
benefits are ranked against scenarios. Scenarios are possible situations of interest in the system.
However, for this specific case study involving a custom ECU, it is almost impossible to determine which
scenarios are of importance. Hence, the ranking was done directly against the quality attributes
assuming there will be a one-to-one relationship between the quality attributes and the scenarios,
which nullifies the effect of ranking against quality attributes.
6.4.2 External Validity It is crucial to show that this study is valid in a similar environment or for another organization within
the same industry. To address this aspect, interviews were also conducted with system architects from
other organizations like Volvo trucks, Volvo cars and Einride. A brief profile of the interviewees is
available in Section 9.2.
6.5 Bias Analysis A key aspect of this study is to identify bias among different participants in an architectural
development process. It is logical that bias will exist among practitioners within an organization, but it
is important to know if that is of considerable nature or not and whether that affects the outcome of
the heuristic process. The participants within Scania are tagged as internal and outside of Scania as
external.
The first cycle of the questionnaire was used to identify bias. A total of 14 participants took part in the
study and they could be divided in multiple ways. The first way was to divide them as internal (10) and
external (4). As the external participants all were system architects and 4 of the internal participants
were system architects as well, they were divided as system architects and system owners. Among the
internal participants, they were divided in 2 ways. Firstly, as system architects and system owners.
Secondly, as engineers within S-Order departments and the rest. The quality attribute rankings were
averaged in these subgroups and variance was calculated for each QA. This was done to give a measure
of how much were the groups in agreement with each other. There were 2 aspects that became clear
during the interviews. System architects and system owners have quite a different point of view. The
organizational goals and scope between R&D and S-Order are also different. Hence, they are split
based on these aspects. Comparing them to external stakeholders was done to improve the validity of
this study. The following section elaborates on the key trends seen in the analysis.
Variances are calculated using the following equation
Equation 10 Equation for Variance
𝜎2 = ∑(𝑋 − 𝜇)2
𝑁
Where X is the sample, µ is the mean of all sample and N is the total number of samples.
60
6.5.1 Grouping A: Internal vs. External Among the 4 groupings, this grouping seems to be the most in agreement. This can be attributed to
the fact that most of the opinions are getting averaged out and are approaching a similar ranking. The
biggest disagreement among the group was regarding development cost. It was seen that the external
participants used the term lifecycle cost in their day to day work rather than development cost.
However, it was a more common term within Scania. The external architects gave more importance to
development cost than internal stakeholders. Lack of familiarity of terms could be a reason why this
was judged differently. Software variability was given more importance by internal stakeholders than
external. This could be because of Scania’s design philosophy which involves a modular approach
where different solutions can be used for any truck configuration. Effectively the customers can mix-
and-match the features they would like on their trucks.
6.5.2 Grouping B: Internal System Architects vs. External System Architects There were a few aspects of disagreement among the architects. The primary one is regarding cost.
External architects believe that cost consideration should not weigh into an architectural
consideration. A reason given by one of the external interviewees was that cost over the life-cycle of
system architecture is different from the cost from a project perspective and precedence should be
given to better system architecture qualities which will help reduce its life cycle cost in the long run.
This could mean that a costlier option might be better in the short run but could save more in the long
term. Another aspect of disagreement was regarding time to market. Internal architects think that it
should not factor into their decision-making process. This could be due to different business drivers in
different organizations that have caused this bias.
6.5.3 Grouping C: Internal System Architects vs. Internal System Owners A key observation in this grouping is that the hardware specifications of the system are not that
important for system architects while it is crucial for system owners. This shows that there is a conflict
of interest between the two groups. The system architects optimize for the system architecture as a
whole, while system owners optimize for an ECU subsystem. Software variability is also more
important for system owners as it reduces work for the individual group. However, it does not factor
that much for system architects.
6.5.4 Grouping D: Internal S-Order vs. Internal R&D The biggest disagreement among these groups is regarding time to market. The S-Order organization
considers it as one of the most important criteria for development while the system architect believes
system properties are more important. This is due to the different goals of both organizations. The S-
order gains a good market advantage by having a short time to market while the main goal of the
system architects is to evolve the system architecture to satisfy a wide range of business and technical
goals part of their design philosophy. Software variability is more important for S-Order as they gain a
lot of configuration abilities by having good variability in the architecture/system. The total cost to the
OEM is considered more important to R&D than the S-Order organization. The outlook on customer
requests varies quite a lot between the two organizations. R&D deals with changes that can affect
1000’s of trucks while S-Order deals with much smaller volumes of custom trucks. Hence the emphasis
and margins on cost are different for both these organizations.
6.5.5 Overall Analysis This section looks at key trends between groupings and overall responses. Table 21 shows the overall
variances among different groupings. Hardware QAs are more in agreement than functional aspects,
and this is mainly because aspects of hardware are fairly universal, irrespective of the organization.
However, functional aspects are harder to generalize as they are dependent on many factors.
61
Table 21 Overall Variances
Grouping A Grouping B Grouping C Grouping D
Functional QA 62 98 84 76
Hardware QA 45 67 56 82
Overall 107 165 140 158
Table 22 Functional QA Variances
Functional QA Variance
Bandwidth Utilization 4.77
E2E Latency and Sync 5.95
Functionality 2.2
Variability: Software 11.20
Reusability: Software 9.57
Flexibility: Physical Interfaces 7.20
Time to Market 9.94
Communication Conflicts 8.05
Development Cost 12.35
Operational Cost 4.23
Maintenance Cost 10.55
Safety 8.02
Table 23 Hardware QA Variances
Hardware QA Variance
CPU and Memory of ECU 12.54
Energy Consumption 5.92
Functionality 6.78
Flexibility: Physical Interfaces 4.67
Time to Market 8.94
Material Cost 7.41
Development Cost 7.94
Operational Cost 5.52
Maintenance Cost 6.60
Physical Size 7.35
Weight 3.94
Safety 12.54
Table 22 and Table 23 shows the overall variances for the quality attributes. Except for a very few QAs,
the responses are varying to a big degree. This could be attributed to many reasons apart from the
ones mentioned already in the above sections. The perspective of participants differs based on their
current job roles. System-level job roles like system architects have an objective of optimizing system-
level quality attributes while job roles dealing with individual systems tend to focus on attributes only
pertaining to the system. This theme is also seen during the interview analysis. Organizational goals
are also different and can contribute to a larger variance. The challenges faced by the participants
during their work and previous job roles that they have held also affect their responses. Different
projects within an organization can have their priorities set differently. For example, the city door
62
project had its own set of priorities that were used during the case study. As the variances are large
when the responses are taken from a larger sample in a general sense, it might be more useful to look
at this on a project-by-project basis. If variances are low within the project then CBAM could be a useful
approach. A generalized set of priorities might not be effective and cannot be validated in any way
against bias. For example, when safety is ranked with cost and time to market in a general sense in
almost all cases safety will be ranked higher than cost which is higher than time-to-market. But when
a project is under consideration, these might change depending on internal and external factors.
Now referring back to the research question in Section 3.2, From the refined utility tree it is clear what
quality attributes are relevant in an evolutionary architecting context for automotive systems. The bias
analysis addresses the second part of the research question. However, the bias analysis points to
certain factors that could lead to bias and that it is inevitable in large organizations. It is almost
impossible to quantify its effects on the architectural decision making process.
63
7 Conclusion & Future Work
7.1 Conclusion The evolutionary architecting process is a very complex process unique to every OEM and unique each
and every time an evolutionary change is made. No two evolutionary changes are the same. Different
manufacturers have different ways of working, design philosophy, business goals. Hence making a
general procedure for evolutionary processes is a difficult task. However, adopting a heuristic
approach to fit the needs of an organization is a better way to solve the problem.
The use of quality attributes for the evolutionary process has its own pros and cons. They provide a
common basis for forming decisions. It is easier to develop a criterion based on quality attributes as
they are general to the system and can be used for all kinds of evolutionary changes. The most relevant
quality attributes found in this study are presented as a refined utility tree in Figure 11. Prioritizing
them to form a ranking seems like a logical way to base an architectural decision upon. However, it
leads to biases that are not easy to explain or be generalized in any way. But if the scope is restricted
enough for example within a project or a functional domain, these prioritized QA could be used as a
basis for architectural decisions. An advantage of using a set of quality attributes is that it forces the
practitioner to look at the problem from different perspectives and this can be very useful in the long
run. A drawback for using quality attributes is that everyone practicing it within the organization should
have a common understanding of its semantics. Homogeneity in semantics is important for such an
approach to be successful in an organization. It would mean that the OEM will have to spend time on
understanding what attributes are important for them and how they would like to define them.
The research question for this thesis is to identify a prioritized set of quality attributes that can be used
for evolutionary architecting processes. A generalized ranking is presented in Section 4.4. However, it
is important to know when such a generalized attribute is applicable. These rankings can be used to
set the overall direction of evolutionary development. However, individual project needs vary and, in
these cases, a project by project ranking would also be needed to make more informed architectural
decisions. The S-Order ECU case study was chosen as a special case for EAP and both ATAM and CBAM
was performed. ATAM was definitely more structured when compared to existing processes. CBAM
provided another perspective but practitioners could not connect the results of CBAM (ROI Values) to
any physical significance. The first step for any EAP is to correctly identify and define constraints and
limitations. Constraints have a very large effect on the decision-making process but in the current
approach, constraints have to be dealt with separately from quality attributes.
Evolutionary architecting involves multiple people from different technical backgrounds. When using
a procedure involving quantitative ranking, it is important to identify bias and its effects on the process.
As seen in 6.5, bias does exist within different parts of an organization. There are many reasons to
which this can happen. The outcome of the process can largely be affected by this bias. However, if
these rankings are considered on a project by project basis, it is less likely to affect the outcome. A
heuristic approach based on quality attributes could also mitigate these effects of bias as shown in
Section 5.2.
7.2 Future Work During this study, there were many aspects uncovered that couldn’t be further investigated due to
limited time and resources. The breadth of the study was largely limited to automotive manufacturers
within Sweden as it was easier to set up interviews and conduct a study. It will be very useful to include
manufacturers from other demographics and other types of vehicles. As seen during the study, firms
64
dealing with passenger cars have different outlooks when compared to firms dealing with heavy
vehicles. The challenges involving architectural development might be totally different for
manufacturers of electric and autonomous vehicles.
AUTOSAR and other architectural standards have not been considered for this study and how that
affect architectural decision making. That is an area that could be further researched. One niche of
evolutionary changes are changes related to safety-critical systems. This is a special case and a whole
thesis could just be dedicated to the study of EAP for safety-critical systems and how functional safety
is affected during architectural changes.
In this thesis, it is assumed that different architectural approaches have already been defined and
quality attribute-based methods could be used to identify which of these approaches is better. Usually,
in these cases, the exploration of solutions and the decision-making process goes hand in hand. Design
space exploration for evolutionary changes could also be an interesting topic to look at.
65
8 Bibliography
[1] K. Reif, Automotive Mechatronics, Springer, 2015.
[2] H. Jaakkola and B. Thalheim, “Architecture-driven modelling methodologies,” in Information
Modelling and Knowledge Bases XXII, 2011.
[3] L. . Braun, M. . Armbruster and E. . Sax, “Stakeholder issues concerning the automotive E/E-
architecture,” , 2016. [Online]. Available: https://publikationen.bibliothek.kit.edu/1000068525.
[Accessed 23 8 2019].
[4] X. . Zhang, N. . Mohan, M. . Törngren, J. . Axelsson and D. . Chen, “Architecture exploration for
distributed embedded systems: a gap analysis in automotive domain,” , 2017. [Online]. Available:
https://ieeexplore.ieee.org/document/7993377. [Accessed 25 6 2019].
[5] P. . Wallin, S. . Johnsson and J. . Axelsson, “Issues Related to Development of E/E Product Line
Architectures in Heavy Vehicles,” , 2009. [Online]. Available: http://dblp.uni-
trier.de/db/conf/hicss/hicss2009.html. [Accessed 27 6 2019].
[6] Y. Liu, “Investigation for the development of a new electric control unit for customized trucks,”
KTH, 2019.
[7] M. . Kaiser, U. D. Schaefer and G. . Haaf, “Electronic control unit,” , 2015. [Online]. Available:
https://link.springer.com/chapter/10.1007/978-3-658-03975-2_3. [Accessed 27 6 2019].
[8] S. Corrigan, “Introduction to the Controller Area Network,” May 2016. [Online]. Available:
http://www.ti.com/lit/an/sloa101b/sloa101b.pdf. [Accessed 14 6 2019].
[9] H. R. Pegorer, J. V. Júnior and M. M. D. Santos, “Communication Protocols Analysis for
Automotive Diagnostic: KWP2000, J1939 and UDS,” , 2013. [Online]. Available:
https://sae.org/publications/technical-papers/content/2013-36-0248. [Accessed 25 6 2019].
[10] SCANIA CV AB, “General Information on CAN,” SCANIA, 02 September 2016. [Online]. Available:
https://til.scania.com/w/bwm_0001111_01. [Accessed 2019 6 14].
[11] T. . Weilkiens, J. G. Lamm, S. . Roth and M. . Walker, “Perspectives, Viewpoints and Views in
System Architecture*,” , 2015. [Online]. Available:
http://onlinelibrary.wiley.com/doi/10.1002/9781119051930.ch9/pdf. [Accessed 27 6 2019].
[12] Unified Modeling Language User Guide, The, ed., vol. , , : Addison-Wesley, 2005, p. 496.
[13] J. . Holt and S. . Perry, “Sysml for Systems Engineering: A Model-Based Approach,” , 2008.
[Online]. Available: https://digital-library.theiet.org/content/books/pc/pbpc020e. [Accessed 27
6 2019].
[14] “AADL,” , . [Online]. Available: http://www.aadl.info. [Accessed 27 6 2019].
[15] “AADL,” , . [Online]. Available: http://www.east-adl.info/. [Accessed 27 6 2019].
66
[16] J. . Axelsson, “Evolutionary architecting of embedded automotive product lines: An industrial
case study,” , 2009. [Online]. Available:
http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.ieee-000005290796. [Accessed 10 7
2019].
[17] A. . Jansen and J. . Bosch, “Software Architecture as a Set of Architectural Design Decisions,” ,
2005. [Online]. Available: http://ics.uci.edu/~andre/ics223w2006/jansenbosch.pdf. [Accessed
10 7 2019].
[18] J. . Axelsson, “Improving the evolutionary architecting process for embedded system product
lines,” , 2011. [Online]. Available: http://diva-portal.org/smash/record.jsf?pid=diva2:1043015.
[Accessed 10 7 2019].
[19] O. . Larses, “Architecting and Modeling Automotive Embedded Systems,” , 2005. [Online].
Available: http://diva-portal.org/smash/record.jsf?pid=diva2:14365. [Accessed 10 7 2019].
[20] D. V. Steward, “The design structure system: A method for managing the design of complex
systems,” IEEE Transactions on Engineering Management, vol. , no. 3, pp. 71-74, 1981.
[21] P. . Wallin, J. . Fröberg and J. . Axelsson, “Making Decisions in Integration of Automotive Software
and Electronics: A Method Based on ATAM and AHP,” , 2007. [Online]. Available:
http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.ieee-000004228592. [Accessed 10 7
2019].
[22] R. . Kazman, M. . Klein and P. C. Clements, “ATAM: Method for Architecture Evaluation,” , 2000.
[Online]. Available: http://lore.ua.ac.be/teaching/capitamaster/assignment/atam-tr.pdf.
[Accessed 5 6 2019].
[23] T. L. Saaty and K. P. Kearns, “The Analytic Hierarchy Process,” , 1985. [Online]. Available:
https://sciencedirect.com/science/article/pii/b9780080325996500088. [Accessed 10 7 2019].
[24] K. . Lind and R. . Heldal, “Automotive System Development Using Reference Architectures,” ,
2012. [Online]. Available: http://ieeexplore.ieee.org/document/6479801. [Accessed 10 7 2019].
[25] Y. . Lee and H.-J. . Choi, “Experience of combining qualitative and quantitative analysis methods
for evaluating software architecture,” , 2005. [Online]. Available: http://dblp.uni-
trier.de/db/conf/acisicis/acisicis2005.html. [Accessed 10 7 2019].
[26] R. Kazman, J. Asundi and M. Klein, “Making Architecture Design Decisions: An Economic
Approach,” 2002.
[27] I. Gorton, “Software Quality Attributes, Chapter 3,” 2011. [Online]. Available:
https://link.springer.com/chapter/10.1007/978-3-642-19176-3_3. [Accessed 23 8 2019].
[28] I. C. Society, IEEE Recommended Practice for Software Requirements Specifications, ed., vol. , , :
Institute of Electrical and Electronics Engineers, Inc, 1998, p. .
[29] T. . Sherman, “Quality Attributes for Embedded Systems,” , 2008. [Online]. Available:
https://link.springer.com/chapter/10.1007/978-1-4020-8741-7_95. [Accessed 5 6 2019].
67
[30] D. A. C. Quartel, M. . Steen and M. M. Lankhorst, “Application and project portfolio valuation
using enterprise architecture and business requirements modelling,” Enterprise Information
Systems, vol. 6, no. 2, pp. 189-213, 2012.
[31] M. Moore, R. Kazman, M. Klein and J. Asundi, “Quantifying the Value of Architecture Design
Decisions: Lessons from the field,” in 25th International Conference on Software Engineering,
2003. Proceedings., Portland, OR, USA, 2003.
[32] SCANIA CV AB, “Scania Media Provider,” [Online]. Available:
https://media.scania.com/fotoweb/. [Accessed 14 6 2019].
[33] SCANIA CV AB, “BCI - Bodywork Communication Interface,” 02 September 2016. [Online].
Available: https://truckbodybuilder.scania.com. [Accessed 14 6 2019].
[34] C. Walton, “IAA 2018: Scania talks "street-smart, moneymaking machine",” Commercial Motor,
26 09 2018. [Online]. Available: https://www.commercialmotor.com/news/product/iaa-2018-
scania-talks-street-smart-moneymaking-machine. [Accessed 20 08 2019].
[35] J. Saldana, The Coding Manual for Qualitative Research, 3rd Edition, 2015.
[36] R. L. Nord, M. R. Barbacci, P. C. Clements, R. . Kazman, M. . Klein, L. . O’Brien and J. E. Tomayko,
“Integrating the Architecture Tradeoff Analysis Method ( ATAM ) with the Cost Benefit Analysis
Method ( CBAM ),” , 2003. [Online]. Available: http://sei.cmu.edu/reports/03tn038.pdf.
[Accessed 5 6 2019].
[37] Robert Bosch GmbH, Bosch Automotive Electrics and Automotive Electronics, Robert Bosch
GmbH, 2007.
[38] T. L. Saaty, “Decision making with the analytic hierarchy process,” International Journal of
Services Sciences, vol. 1, no. 1, pp. 83-98, 2008.
68
9 Appendix
9.1 Appendix A: Coding Methods Source: J. Saldaña, The coding manual for qualitative researchers, 3. edition. 2015.
- Coding method chosen is it related to the research question.
- Coding is a heuristic (from the Greek, meaning "to discover") an exploratory problem-solving
technique without specific formulas to follow:'" Coding is only the initial step toward an even
more rigorous and evocative analysis and interpretation for a report. Coding is not just
labelling, it is linking of different ideas and datapoints. "It leads you from the data to the idea,
and from the idea to all the data pertaining to that idea" (Richards & Morse, 2007, p. 137).
Coding is considered as a Provocative thinking exercise.
- Frequency counts of different codes were used to identify emphasis (LeCompte & Schensul,
1999)
- Coding can be done in iterations refining each time.
Figure 15 Grounded Theory [35]
Different types of coding methods:
1. Attribute coding: good variety of data source. Field: Value Format
2. Magnitude Coding: intensity (strong, moderately, no opinion), frequency (high, medium,
low, none, instances, exchanges), positive/negative/neutral, present/absent/unknown,
yes/no/maybe.
3. Simultaneous Coding: Multiple codes to the same data, useful if multiple meanings. may
cause indecisiveness.
4. Structural coding: Applies a content-based representation of topics. Structural code for
segments, analysis, frequency count.
5. Descriptive coding: Also, topic coding. Easy method. One word for sections. If too many,
sub codes are possible.
6. In Vivo Coding: Literal coding. Codes in double-quotes. Will need the second cycle of
coding.
7. Process coding: More useful for ongoing action/interaction. More -ING words for actions.
Analysis through lists, flowcharts. Process codes lead to outcomes for results.
69
8. Initial Coding: Open-ended approach. Line by line approach. Making write-ups for each
important code subsequently.
9. Evaluation coding: Suitable for organizational studies. codes are positive, negative with a
sub code.
10. Pattern coding: Finding patterns among codes, to themes.
11. Focused codes: Making a list of categories and assigning codes to each category.
70
9.2 Appendix B: Interviewee Profile
Name Role Firm Experience (in Years)
Eduardo de Souza
Development Engineer Scania 1
Johan Linder Development Engineer Scania 3
Marcello Pasquale
Development Engineer Scania 2
Johan Svahn Senior Technical Manager, Functional Architecture
Scania 20
Ove Bergmark Functional Architect Scania 13
Ola Bergqvist Senior Technical Manager, Hardware Architecture
Scania 31
Erik Karlsson Senior Technical Manager, Hardware Architecture
Scania 39
Markus Svensson System Owner Scania 8
Jan-Åke Bergstrand
System Owner Scania 13
Arvid Sundbald Function Owner Scania 2
Martin Törngren Professor KTH 17
Anders Magnusson
Technology Specialist (Logical Architecture)
Volvo Trucks
32
Lance Higgins Technology Specialist (Hardware Architecture)
Volvo Trucks
15
Matthijs Klomp Solution Architect Volvo Cars 2
Sebastian Holmqvist
Development Engineer Einride 5
71
9.3 Appendix C: CBAM Rankings C
PU
an
d
Mem
ory
of
ECU
1
10
2
9
2
4
12
7
12
7
7
6
9
3
Ener
gy
Co
nsu
mp
tio
n
6
11
10
4
9
5
11
6
7
6
4
10
8
5
Fun
ctio
nal
i
ty
3 3 3 1 4 2 2 3 2 3 12
2 2 1
Flex
ibili
ty:
Ph
ysic
al
Inte
rfac
es 4
8
4
5
3
3
7
4
1
1
6
8
4
6
Tim
e to
M
arke
t
2 4 5 6 10
10
8 1 3 8 1 7 3 7
Mat
eri
al C
ost
9 1 9 10
7 6 3 5 8 5 2 3 6 8
Dev
elo
pm
ent
Co
st
7
2
6
8
6
7
10
12
9
10
3
4
5
4
Op
erat
ion
al C
ost
8
6
7
7
5
8
4
11
10
9
8
11
12
11
Mai
nte
nan
ce
Co
st
12
7 8 2 8 9 9 8 11
11
10
12
10
12
Ph
ysic
al
Size
10
9 11
11
12
11
5 9 5 4 5 5 7 9
Wei
ght
11
12
12
12
11
12
6 10
6 12
11
9 11
10
Safe
ty
5 5 1 3 1 1 1 2 4 2 9 1 1 2
Par
tici
pan
t
1 2 3 4 5 6 7 8 9 10
11
12
13
14
72
TRITA ITM-EX 2019:694
www.kth.se
![Vidya Harikrishnan 2017-18 [III batch PGDLT] · Vidya Harikrishnan 2017-18 [III batch – PGDLT] TABLE of CONTENTS Section A My Personal journey as a learner: Page 3 My Educational](https://static.fdocuments.in/doc/165x107/5ede1152ad6a402d6669579d/vidya-harikrishnan-2017-18-iii-batch-pgdlt-vidya-harikrishnan-2017-18-iii-batch.jpg)
![[IJET V2I5P12] Authors: Mr. Harikrishnan U, Dr. Bos Mathew Jos, Mr.Thomas P Rajan](https://static.fdocuments.in/doc/165x107/58f1f9901a28abe56b8b4595/ijet-v2i5p12-authors-mr-harikrishnan-u-dr-bos-mathew-jos-mrthomas-p.jpg)
