Ignasi Aragonès Just

System Architecture Definition of an A-SPICE

compliant Automotive Body Controller

TRABAJO FINAL DE GRADO

Supervised by Prof. Javier Calvente

Josep Lluís Plana (Lear Tutor)

Degree in Industrial Electronics and Automation Engineering

Tarragona

2015

2

Confidential information

This is the public version of the document. For its publishing and following the

instructions of the confidentiality agreement (see next page) of the Final Degree Project,

the confidential parts have been deleted from the full document version.

For more information:

LEAR CORPORATION HOLDING SPAIN, S.L.U.

C/ Fusters 54 Polígon Industrial

43800 Valls TARRAGONA

Phone 977617100

3

4

Table of Content

1 Introduction ....................................................................................................7

1.1 Background ...............................................................................................7

1.2 Purpose .....................................................................................................7

1.3 Scope ........................................................................................................7

2 Basic Knowledge .............................................................................................8

2.1 System, System Element and System Function ..........................................8

2.2 System Architecture ..................................................................................8

3 System Modeling Language ...........................................................................9

3.1 Behavior Diagrams .................................................................................. 10

3.1.1 Use case diagram ................................................................................. 10

3.1.2 Activity diagram .................................................................................. 10

3.1.3 Sequence diagram ................................................................................ 11

3.2 Structure Diagrams .................................................................................. 11

3.2.1 Internal Block diagram ........................................................................ 11

3.2.2 Block Definition diagram..................................................................... 12

4 Automotive SPICE (A-SPICE) .................................................................... 12

4.1 Overview ................................................................................................ 12

4.2 Work product: System architectural design ............................................. 14

[Some parts have been deleted here due to confidential issues. For more

information go to page number 2.]

5 Conclusions ................................................................................................... 18

6 Bibliography ................................................................................................. 19

5

List of Figures

Figure 1: Apollo program is a good leading system engineering project example .....7

Figure 2: E-costs/overall production costs ................................................................7 Figure 3: Representation of the structure and behavior view of a car system ............9

Figure 4: SysML Diagrams ......................................................................................9 Figure 5: Use Case Diagram .................................................................................. 10

Figure 6: Activity Diagram .................................................................................... 10 Figure 7: Sequence Diagram .................................................................................. 11

Figure 8: Internal Block Diagram ........................................................................... 12 Figure 9: Block Definition Diagram ....................................................................... 12

Figure 10: Companies of the Automotive Special Interest Group (SIG) .................. 13 Figure 11: Capability levels of Automotive SPICE ................................................ 13

Figure 12: V model defined in the Automotive SPICE ........................................... 13

6

List of Tables

Table 1: Features of "system architectural design".................................................. 16

7

1 Introduction

1.1 Background

Some years ago, the presence of electronic systems in the automotive world was

almost nonexistent. As we get closer to the present time it is possible to see how the

amount of them increase, arriving to nowadays, where almost every part of an automobile

has some electronic systems attached. To see this information with tangible data, in 2005

the cost in electronics in a car was around 20% of the total cost. In 2015 this percentage

increased approximately 40%.

Until now, the electronic systems in the

automobiles had low complexity, and for that

reason there were no additional analysis to define

them. Currently, this level of complexity has

increased significantly. For this reason a “new”

field of engineering is starting to be applied to

the automotive world. This field is called System

Engineering and it was used for first time in the

Bell Telephone Laboratories in the 1940s.

System Engineering is an interdisciplinary

approach and means to enable the realization of

successful systems. It focuses on defining

customer needs and required functionalities

early in the development cycle, documenting

requirements, then proceeding with design

synthesis and system validation1. To

accomplish these tasks analysis is required,

which is made through the System

Architecture. The System Architecture is the

conceptual model that defines the different

views of a system, the most important being

the behavior and structural ones.

1.2 Purpose

The intention of this project is to define a reusable process with which to create a

System Architecture’s definition using as an example a project owned by Lear

Corporation. This project is a Body Control Module or BCM from Lear’s OEM. This

process definition will be created in order to obtain a standard process which will follow

the Automotive SPICE model. The System Architecture definition will be created using

the modeling language System Modeling Language or SysML.

Thanks to the System Architecture of a system, it will improve the quality of the

design process of any system desired increasing at the same time the ASPICE level of it.

1.3 Scope

This project has three main objectives. The first one is analyze the different tools

available in the market capable of managing the System Modeling Language. The second

one will be to create a set of models based on the Body Control Module system. The last

1 http://ocw.mit.edu/courses/engineering-systems-division/esd-33-systems-engineering-summer-2010/

Figure 1: Apollo program is a good leading system engineering project example

Figure 2: E-costs/overall production costs1

8

one will be define the reusable process and create a manual to apply this process with the

selected tool.

2 Basic Knowledge

In this part will be explained the basic knowledge required for the correct

comprehension of this project. Some concepts may seem abstracts but later on in this

project, some of them, will be shown as an example so it will be easier to understand.

2.1 System, System Element and System Function

To properly understand this project, it is necessary to begin defining the most basic

concepts, which will be the concept of system. The system definition is highly complex

due to the huge amount of things that this can be. To solve this problem, a set of system

definitions made by various experts are exposed next:

● “A system is a value-delivering object” 2

● “A system is defined as a set of concepts and/or elements used to satisfy a

need or requirement" 3

● “A system is an array of components designed to accomplish a particular

objective according to plan” 4

The “concepts”, “elements” or “components”, which these definitions describe as the

parts of which a system is made, and are also known as system elements. This will be the

term to refer to them in this project. These system elements are really important for the

system architecture design because they help to split a large and complicate system into

multiple parts which are easier to analyze. This concept will be widely used in the static

definition/view of a system.

Coming back to the definitions of system made before, a system is “used to satisfy a

need or requirement” therefore has a “particular objective”. To accomplish this objective

the systems have what is known as system function. It is possible to define system function

as an action or set of actions taken by the system to which it belongs to achieve a goal.

This concept will be widely used in the dynamic definition/view of a system.

2.2 System Architecture

To define exactly what system architecture means, a definition was made by the

INCOSE organization (International Council on System Engineering) and was introduced.

It defines system architecture as “the aggregation of decomposed system functions into

interacting system elements whose requirements include those associated with the

aggregated system functions and their interfaces requirements/definition”. The INCOSE

organization clarifies this description when it says, “When used as a noun, the System

Design is the same as the System Architecture”5. This description of system architecture is

really complex but, at the same time, very precise.

2 Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm. Verlag, Berlin, Heidelberg, New York:

Springer. 3 Miles, R.F. (ed). 1973. System Concepts. New York, NY, USA: Wiley and Sons, Inc. 4 Johnson, R.A., F.W. Kast, and J.E. Rosenzweig. 1963. The Theory and Management of Systems. New York, NY,

USA: McGraw-Hill Book Company. 5 http://members.tripod.com/Rick_Steiner/Evolarch.pdf

9

To describe what a system architecture is in a simple way, it is possible to say that it

is a conceptual model which defines different views of a same system, being the structure

(related to the system elements and their interfaces) and behavior (related to the system

functions) views being the most important ones.

3 System Modeling Language

System Modeling Language or SysML is the modeling language used in this project

to describe the different views of the system.

SysML is a subset of the widely known software system modeling language, UML

(Unified Modeling Language). SysML, as the name already indicates, is focused in

modeling all kind of systems and that is the reason why it has been chosen in this project.

This modeling language is based on a set of different diagrams which are used to describe

the different views of a system.

The next figure6 shows all the diagrams that SysML contains. It is also possible to

see the relationship between this language and UML.

In this project there are three diagrams which will not be used. The diagrams are

“Requirement Diagram”, “Parametric Diagram” and “State Machine Diagram". None of

them are interesting for the purpose of this project. Following, all the other diagrams will

be explained by dividing them into behavior diagrams and structure diagrams.

6 http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdf

bdd [Package] Block Definition Diagram [SysML]

Requirement

Diagram

Behav ior

Diagram

Block Definition

Diagram

Internal Block

Diagram

System Modeling

Language

Package

Diagram

Parametric

Diagram

Sequence

Diagram

State Machine

Diagram

Structure

Diagram

Use Case

Diagram

Activ ity Diagram

Same as UML 2

Modified from UML 2

New in SysML

Legend

Figure 3: Representation of the structure and behavior view of a car system

Figure 4: SysML Diagrams

10

3.1 Behavior Diagrams

3.1.1 Use case diagram

The Use Case Diagram (UC) describes the necessary actions to be carried out by a

system to accomplish a certain goal. It also describes the interactions between the system

and its actors (who or what interacts with a system). An example of it is shown next:

Figure 5: Use Case Diagram

This is the first diagram made in the process and, with it, starts the function analysis.

It is important not to miss any use case to properly model the system.

3.1.2 Activity diagram

The Activity Diagram (ACT) is a graphical representation of the stepwise workflow

made by simple actions necessary to accomplish every use case.

This diagram gives the behavior representation of the system and splits the different

set of activities among all the system elements so, in that way, it is possible to check

whether all the activities are covered or not.

Figure 6: Activity Diagram

uc [Package] FUNCTION1_EXAMPLE [UC_FUNCTION1_EXAMPLE]

System Function: FUNCTION1_EXAMPLE

USE_CASE1

ACTOR1 ACTOR2

act [Activ ity] ACT_Use_Case1 [ACT_Use_Case1]

External_Vehicle System_Element1 System_Element2

ActivityInitial

Activ ity1 Activ ity2

Is the required

condition TRUE?

ActivityFinal

Signal

Path 2

Path 1

[No]

[Yes]

11

On the left side it is possible to find the starting point with the input signal for this

diagram. In the middle of this diagram there are the activities required to accomplish the

functionality of the use case which it describes, and on the top of it there are the different

system elements. With this diagram it is easy to see, with the different inputs of a system

(input signals), what has to be done (activities) and who has to do it (system elements).

3.1.3 Sequence diagram

The Sequence Diagram (SEQ) shows the interactions between the different elements

involved in the system represented in a chronological order (top part starts, on the bottom

ends). There might be as many Sequence Diagrams as different paths in the Activity

Diagram, although in this process it is going represent only the paths with complex

interactions between system elements.

This diagram gives an easy view of all the interactions and data flow between the

elements forming the system.

Figure 7: Sequence Diagram

3.2 Structure Diagrams

3.2.1 Internal Block diagram

The Internal Block Diagram (IBD) shows a representation of the system, by using

white blocks which show the relationship, i.e. interfaces, between them.

sd SEQ_PATH1

Termination

Request

Termination

Request

:SYSTEM_ELEMENT1 :SYSTEM_ELEMENT2

:ACTOR1 :ACTOR2

Send_Signal()

Signal_Adaption()

Send_Signal()

Send_Signal()

12

Figure 8: Internal Block Diagram

3.2.2 Block Definition diagram

The Block Definition Diagram (BDD) shows a representation of the system with

“black box” blocks showing the hierarchy between them.

Figure 9: Block Definition Diagram

4 Automotive SPICE (A-SPICE)

4.1 Overview

These last decades the automobile industry had had a huge change. Systems that

some years ago were only a dream, nowadays, are implemented as standard in the

automobiles. Systems such as the Antilock Brake System (ABS), the electronic fuel

injection (EFI), automatic suspension, smart lighting etc. All this new technology includes

new difficult problems to solve, such as safety problems. Even more, the automobile world

is a competitive world, a world where a small problem can cost millions of Euros, or

something even worse, the reputation of a company. For this reason, the car manufacturers

had a problem of trust with their suppliers because there was not a way to “measure” the

quality of the products that they were buying. As a consequence, in 1993, the major car

manufacturers formed a group called Automotive Special Interest Group (SIG), which

created what today is known as Automotive SPICE. This group was formed by:

ibd [Package] FUNCTION1_EXAMPLE [IBD_FUNCTION1]

SYSTEM_ELEMENT3

SYSTEM_ELEMENT1

DIGITAL_IO1~Send_Signal

DIGITAL_IO2~Send_Signal

DIGITAL_IO3~Set_Config

SPI_0~Send_Signal

SYSTEM_ELEMENT2

DIGITAL_IO3~Set_Config

SPI_0~Send_SignalDIGITAL_IO5~Send_Signal

ACTOR1DIGITAL_IO1~Send_Signal

DIGITAL_IO2~Send_Signal

ACTOR2

DIGITAL_IO5~Send_Signal

bdd [Package] SYSTEM_EXAMPLE [BDD_SYSTEM_EXAMPLE]

«block»

SYSTEM_ELEMENT3

«block»

SYSTEM_ELEMENT1

«block»

SYSTEM_ELEMENT2

«block»

ACTORS

«block»

ACTOR2

«block»

ACTOR1

13

● AUDI AG

● BMW Group

● Daimler AG

● Fiat Auto S.p.A.

● Ford Werke GmbH

● Jaguar

● Land Rover

● Dr. Ing. h.c. F. Porsche AG

● Volkswagen AG

● Volvo Car Corporation

The Automotive SPICE is an adaption

for the automobile industry of the standard

ISO/IEC 15504, also known as SPICE

(Software Process Improvement and Capability dEtermination). Automotive SPICE is an

assessment process formed by a set of technical documents aiming an optimal design.

The level of compliance of this standard is shown through what is known as

capability levels of Automotive SPICE. Every capability level is measured through process

attributes.

The technical documents that Automotive SPICE defines for a project are

represented in what is known as Automotive SPICE’s “V model”. The V model is the one

shown next:

Figure 10: Companies of the Automotive Special Interest Group (SIG)

1.1 Process Performance

2.1 Performance Management 2.2 Work Product Management

3.1 Process Definition 3.2 Process Deployment

4.1 Process Measurement 4.2 Process Control

5.1 Process Innovation 5.2 Process Optimization.

Figure 11: Capability levels of Automotive SPICE

14

This project is going to be focused on defining the process to follow to create the part

“Define System Architecture (Define Reused Components)” of the V model.

4.2 Work product: System architectural design

In this section it is going to be analyzed the different points of the work product

“System architectural design” described in A-SPICE to see which of them are covered with

the process described.

WP ID: 04-06

WP Name: System architectural design

1. Provides an overview of

all system design

Once the system is modeled, in the project browser, there

are all the elements used in the system design process.

2. Describes the

interrelationship between

system elements

The Internal Block Diagram shows the interrelationship

between system elements through the FlowPorts.

Moreover, the Sequence Diagram shows,

chronologically, the interactions between system

elements.

3. Describes the relationship

between the system

elements and the software

With the actual process is not possible to get this

relationship, but if instead of connect the system

elements to the “Processing Unit”, they are connect to the

“Model”, it will be possible to show the relationship.

4. Specifies the design for each required system element, consideration is given to things

like:

15

4.1 Memory/capacity

requirements

It is not the intention of this project to show this

information.

4.2 Hardware interfaces

requirements

The hardware interface timing requirements will be

represented in the sequence diagram.

4.3 User interfaces

requirements

If the required function is modeled, it is possible to

obtain the user interface requirements.

4.4 Commands structures

It is not the intention of this project to show this

information.

4.5 Security/data

protection

characteristics

It is not the intention of this project to show this

information.

4.6 System parameter

settings

It is possible to have this information if the parameters

are set as an attributes.

4.7 Manual operations

If the required function is modeled, it is possible to

obtain the manual operations

4.8 Reusable components

It is not the intention of this project to show this

information.

5. Mapping of requirements

to system elements

It is possible to map the requirements to system elements

in EA but the mapping will be realized in DOORS.

6. Description of the

dependencies among the

system components

(startup, shutdown, sleep

mode, diagnosis mode,

etc.)

With the correct function modeled, the dependencies will

be displayed in the Activity Diagram.

7. Description of the

dependencies among the

system components

regarding the operation

modes.

With the function Sleep/Awake modeled, the

dependencies will be displayed in the Activity Diagram.

8. Description of the

dynamics behavior of the

The dynamic behavior description is allocated in the

16

system and the system

components.

Activity and Sequence Diagram.

Table 1: Features of "system architectural design"

17

[Some parts have been deleted here due to confidential issues. For

more information go to page number 2.]

18

5 Conclusions

This project had an ambitious main objective, defining a reusable process to create

the system architecture definition of a real project. Accomplishing this objective has been

an arduous task, because in order to carry it out, it has been necessary to properly

understand the behavior and structure of the whole system. Besides the system

comprehension, it was also important the study of the assessment process Automotive

SPICE, and was mandatory to be applied in the system architecture design. Furthermore, it

must be taken into account that the system architecture is a new field, yet to be developed

in Lear Corporation, there was neither any previous information nor process defined. All

these characteristics made this project a great challenge. Therefore, to fulfill the goals

initially proposed in the project, this challenge has been split into three different tasks. The

first one, analysis of the different capable tools for defining the system architecture,

secondly, a set of model examples had to be defined, and last but not least, a definition of

the reusable process as well as the creation of a manual for reproducing it with the tool

selected has been performed.

As far as the tool chosen is concerned, there was an economical restriction which

forced us to go for the most inexpensive option, even though a few weeks passed until we

finally agreed on selecting the official tool to be used in the project.

The modeling section has been the most difficult part of the whole project and the

most interesting. The necessary system requirements used to understand and define the

system functions properly were difficult to comprehend due to the technical language used.

The main problem was that some of the information was not properly documented due to

different problem sources (they were working on the documentation, the information

generated was already know by the people who needed it, therefore there was no “need” to

document it, etc.). However, support of various specialists from the different areas has

been essential.

Finally, the definition of the process and the consequent manual for applying it with

the official tool has been relatively straight forward. With all the knowledge acquired from

the modeling part, it was adequate to have clear ideas of how the system architecture

definition should be done.

All the work completed in this project will aid the company Lear Corporation to

reach the needed Automotive SPICE’s level, a fact that will help Lear generate more

projects. Even so, introducing a new process into the company has been challenging work.

Changing the way people is work is not simple, however, this important evidence will help

Lear Corporation reach the top high tech companies in the electronic automotive market.

19

6 Bibliography

• D Little, A. (2006). Market and technology Study Automotive Power Electronics 2015.

Retrieved March 12, 2015, from http://www.adlittle.com/downloads/tx_adlreports/ADL_Study_Power_Electronics_2015.pdf

• Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm. Verlag,

Berlin, Heidelberg, New York: Springer.

• Miles, R.F. (ed). 1973. System Concepts. New York, NY, USA: Wiley and Sons, Inc.

• Johnson, R.A., F.W. Kast, and J.E. Rosenzweig. 1963. The Theory and Management of

Systems. New York, NY, USA: McGraw-Hill Book Company.

• Steiner, R., Naval, R., & Systems, M. (n.d.). System Architectures and Evolvability:

Definitions and Perspective. Retrieved January 21, 2015, from

http://members.tripod.com/Rick_Steiner/Evolarch.pdf

• Friedenthal, S., Moore, A., & Steiner, R. (2009, September 1). OMG Systems Modeling

Language (OMG SysML™) Tutorial. Retrieved November 10, 2014, from http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdf

Gathering Knowledge:

• Roques, P. (2011, October 16). SysML vs. UML 2: A Detailed Comparison. Retrieved

November 13, 2014, from http://ecs.victoria.ac.nz/foswiki/pub/Events/MODELS2011/Material/MODELS_2011_T2-Roques-

SysML_UML2.pdf

• Automotive SIG. (2010, May 10). Automotive SPICE® Process Assessment Model.

Retrieved December 11, 2014, from http://www.automotivespice.com/fileadmin/software-

download/automotiveSIG_PAM_v25.pdf

• Sparx Systems. (2015, March 27). Which Enterprise Architect Edition Should I

Purchase? Retrieved April 16, 2015, from http://www.sparxsystems.com/downloads/pdf/editions.pdf