Automotive System and
Software Architecture
Yanja Dajsuren
2IW80 Software Specification and Architecture
March 24, 2016
Electronic Spark Timing
(EST) System (1 ECU)
2000 functions enabled by
software (70-100 ECUs)
90% innovation 50-70% development cost
http://www.cvel.clemson.edu/auto/systems/auto-systems.html
Why more software?
Automotive supply chain software integration
Architecture-driven: • (Partially) Automated
• Early detection of errors
• Less effort/cost to change
Document-centric: • Manual
• Error prone
• Costly to change
Adapted from http://www.edibasics.hu/edi-resources/edi-by-industry/automotive.htm
Siemens – Automotive Software
Architecture Description
Language (ADL)
Architecture Framework (AF)
Automotive architecture modeling
PAGE 6 24-3-2016
• Top-down system development i.o. bottom up
• Separation of concerns in different architectural models/views
• Model-driven i.o. document-centric approach
• Improved design quality by detecting errors early
• …
/ Department of Mathematics and Computer Science
Automotive companies and ADLs
• Automotive Modeling Language (AML)
• COmponent Language (COLA)
• EAST-ADL
• Timing Augmented Description Language
(TADL)
• The ICT MAENAD project EAST-ADL2
/ Department of Mathematics and Computer Science PAGE 7 24-3-2016
EAST-ADL
• EAST-ADL
• Advancing Traffic Efficiency and Safety through Software
Technology 2 (ATESST) project
• Refined EAST-ADL2 language, profile, methodology, tools
• It provides means to represent the embedded system in several
abstraction levels.
• Main source: http://www.east-adl.info/
/ Department of Mathematics and Computer Science PAGE 8 24-3-2016
EAST-ADL and AUTOSAR
PAGE 9 24-3-2016
http://maenad.eu/
EAST-ADL Abstraction Levels
/ Department of Mathematics and Computer Science PAGE 11 24-3-2016
EAST-ADL Abstraction Levels
/ Department of Mathematics and Computer Science PAGE 12 24-3-2016
Example of function-to-component Mapping
/ Department of Mathematics and Computer Science PAGE 13 24-3-2016
EAST-ADL Metamodel Structure
/ Department of Mathematics and Computer Science PAGE 14 24-3-2016
/ Department of Mathematics and Computer Science PAGE 15 24-3-2016
PAGE 16 24-3-2016 http://www.east-adl.info/Tooling.html
EAST-ADL Summary
• Defines several abstraction levels and mapping between them
• Extensions to traditional ADLs:
• Requirements
• Variability
• Timing
• Dependability
• Safety (alignment with ISO26262)
• Environment modeling
• Not well applied yet in automotive industry
/ Department of Mathematics and Computer Science PAGE 17 24-3-2016
SysML and UML
PAGE 18 24-3-2016
SysML Diagram Taxonomy
SysML Diagram
Structure
Diagram
Behavior
Diagram
Use Case
Diagram
Activity
Diagram
Internal Block
Diagram
Block Definition
Diagram
Sequence
Diagram
State Machine
Diagram
Parametric
Diagram
Requirement
Diagram
Modified from UML 2
New diagram type
Package Diagram
Same as UML 2
PAGE 19 24-3-2016
20
Blocks are Basic Structural Elements
• Provides a unifying concept to describe the structure of an element or system
• System
• Hardware
• Software
• Data
• Procedure
• Facility
• Person
• Multiple standard compartments can describe the block characteristics • Properties (parts, references, values, ports)
• Operations
• Constraints
• Allocations from/to other model elements (e.g. activities)
• Requirements the block satisfies
• User defined compartments
Compartment
Label
values DutyCycle : Percentage
allocatedFrom «activity»Modulate BrakingForce
«block» BrakeModulator
21
Using Blocks
• Based on UML Class from UML Composite Structure
• Supports unique features (e.g., flow ports, value
properties)
• Block definition diagram describes the relationship
among blocks (e.g., composition, association,
specialization)
• Internal block diagram describes the internal
structure of a block in terms of its properties and
connectors
• Behavior can be allocated to blocks
Blocks Used to Specify Hierarchies and Interconnection
22
Block Definition vs. Usage
Definition
• Block is a definition/type
• Captures properties, etc.
• Reused in multiple contexts
Usage
– Part is the usage of a block
in the context of a
composing block
– Also known as a role
Block Definition Diagram Internal Block Diagram
23
Internal Block Diagram (ibd) Blocks, Parts, Ports, Connectors & Flows
Enclosing
Block
Connector
Port
Item Flow
Internal Block Diagram Specifies Interconnection of Parts
Part
24
Reference Property Explained
•S1 is a reference part*
•Shown in dashed outline box
*Actual name is reference property
s
25
SysML Ports
• Specifies interaction points on blocks and parts
• Integrates behavior with structure
• portName:TypeName
• Kinds of ports
• Standard (UML) Port
− Specifies a set of required or provided operations
and/or signals
− Typed by a UML interface
• Flow Port
− Specifies what can flow in or out of block/part
− Typed by a block, value type, or flow specification
− Atomic, non-atomic, and conjugate variations Standard Port and Flow Port
Support Different Interface Concepts
26
Port Notation
Standard
Port
Flow
Port
provided interface
(provides the operations)
required interface
(calls the operations)
item flow
Flow Port
part2: part1:
part1: part2:
27
State Machines
• Typically used to represent the life cycle of a block
• Support event-based behavior (generally
asynchronous)
• Transition with trigger, guard, action
• State with entry, exit, and do-activity
• Can include nested sequential or concurrent states
• Can send/receive signals to communicate between
blocks during state transitions, etc.
• Event types
• Change event
• Time event
• Signal event
28
stm HSUVOperationalStates
Operate
Idle
Accelerating/
CruisingBraking
engageBrake/
accelerate/
when (speed = 0)
releaseBrake/
shutOff/stop engine
Off
start[in neutral]/start engine Nominal
states only
keyOff/
Operational States (Drive)
Transition notation:
trigger[guard]/action
PAGE 29 24-3-2016
Adaptive Cruise Control (ACC) in SysML
Modeling the ACC system for an E-truck with a top-
down approach in SysML
/ Department of Mathematics and Computer Science PAGE 30 24-3-2016
Image: http://www.extremetech.com/
PAGE 31 24-3-2016
Requirements Diagram
Source: Artisan Software Tools
Use Case diagram
• Provides means for
describing basic
functionality in terms of
usages of system by
actors
• Generally elaborated via
other behavioral
representations to
describe detailed
scenarios
/ Department of Mathematics and Computer Science PAGE 32 24-3-2016
Source: Artisan Software Tools
System architecture
PAGE 33 24-3-2016
System integration
• Software
• Hardware
PAGE 34 24-3-2016
Running ACC_UI on Freescale board
PAGE 35 24-3-2016
SysML summary
• SysML provides a general purpose modeling language to support specification,
analysis, design and verification of complex systems
• Subset of UML 2 with extensions
• 4 Pillars of SysML include modeling of requirements, behavior, structure, and parametrics
• Intended to improve communications, tool interoperability, and design quality
• Multiple tools available
• IBM –Rhapsody
• Sparx Systems -Enterprise Architect
• Atego –Artisan Studio etc.
/ Department of Mathematics and Computer Science PAGE 36 24-3-2016
AUTOSAR (AUTomotive Open System
Architecture)
• An open and standardized automotive
software architecture
• Architecture
• Methodology
• Application Interfaces
AUTOSAR Milestones
/ Department of Mathematics and Computer Science PAGE 38 24-3-2016
http://autosar.org/
AUTOSAR Layered Architecture
http://autosar.org/
AUTOSAR Methodology
http://autosar.org/
PAGE 41 24-3-2016
http://autosar.org/
AUTOSAR Application Interface
AUTOSAR Use Case
http://autosar.org/
PAGE 43 24-3-2016
AUTOSAR Benefits
http://autosar.org/
Automotive Standards
• ISO 26262:
• Absence of unreasonable risk due to hazards caused by
malfunctioning behavior of E/E systems
• IEC 61508:
• Part of the overall safety related to the equipment under
control (EUC) that depends on the correct functioning of
the safety-related system.
• MISRA C:
• Software development standard PAGE 44 24-3-2016
ISO 26262
/ Department of Mathematics and Computer Science PAGE 45 24-3-2016
KoenLeekens, ISO-26262 introduction, 2012
Safety in V cycle
/ Department of Mathematics and Computer Science PAGE 46 24-3-2016
Safety Analysis in ISO 26262
PAGE 47 24-3-2016
KoenLeekens, ISO-26262 introduction, 2012
MISRA C
• MISRA C is a software development standard for the
C programming language developed by MISRA
(Motor Industry Software Reliability Association).
• Its aims are to facilitate code safety, portability and
reliability in the context of embedded systems,
specifically those systems programmed in ISO C
• As with many standards the MISRA C guideline
documents are not free to users or developers
/ Department of Mathematics and Computer Science PAGE 48 24-3-2016
2014 record recall year
Software problem that could cause
• the cars to stop suddenly
• accelerate without warning
• overheats/damages power
electronics
• …
Ex
am
ple
ap
pli
ca
tio
ns
Fu
nc
tio
na
l
do
ma
ins
Hybrid Innovations for
Trucks (HIT) project Safety-Critical Domain
Certification
InMotion, Solar Team, “Cars
in Context” TU/e projects
HIT Results • Architecture modeling approaches
• ADL evaluation
• Architecture framework
• Quality framework
• Validated metrics for Simulink
• Metrics tool
• Visualization
EM Evaluation
PAGE 53
• Model clones may have the
effect of increasing code size
and duplication of errors.
• Number of duplicates affects
modifiability as well.
Contribution to GMM based Editors
Safety Case Specific MM
Domain Concepts from
Standard (ISO 26262)
or Project
Generic
MetaModel
SM Editor
Add domain
concepts
Automatic
generated Link to
Metamodel
Transformation
Summary
• In the automotive industry, more and more software
and electronics system require system and software
architecture methods.
• Automotive specific and generic purpose ADLs are
being developed and applied.
• Many stakeholders, functionalities, safety and
environment requirements require automotive
specific standards.
/ Department of Mathematics and Computer Science PAGE 55 24-3-2016
V2V V2V
Internet, V2I
Congestion control Road maintenance
Environment control
And whatever sensing you can think of…
Driver Control
Driver Control
V2V network
Accident prevention
Local Control
Local Control
Local Control
In-car network
Driver Control
•System/software architecture for ITS
and autonomous cars
•Safety, security mechanisms
•...
Interesting Topics for
Future Research
Johan J. Lukkien, TU/e
Contact information:
Yanja Dajsuren
Tel: +31(0)402475052
Email: [email protected]
Address:
MF 6.085, Eindhoven University of Technology
5612 AZ Eindhoven, The Netherlands
www.fastcodesign.com