Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
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