Diapositive 1

1

• Introduction
• Automotive embedded systems are increasingly
  critical and complex and require adequate
  management of engineering information for
  development. The ATESST project delivers an
  Architecture Description Language (EAST-ADL2.0)
  as a means to handle the complexity and improve
  safety, reliability, cost, and development
  efficiency.
• The ATESST Project
• Addresses system modeling techniques as a means
  to improve development practice,
• Delivers an automotive architecture description
  language (EAST-ADL2.0) as a UML2 profile,
• Uses EAST-ADL1.0 from the ITEA EAST-EEA project
  (http//www.east-eea.net/) as a basis, and
• Takes existing approaches into account including
  Autosar, Object Management Group (UML2, Testing
  profile, MARTE profile, SysML profile, etc.), and
  AADL.
• Uses the open source Eclipse UML2 Modeling
  Environment Papyrus developed by CEA
• EAST-ADL2.0
• Is an information structure for engineering
  information related to automotive software
  development. The structure covers for example
• requirements,
• system architecture,

Structure of EAST-ADL2 System model
Demonstrator based on the EUCAR ISP
architecture Prototype tool allowing
system modeling of the vehicle EE architecture
and environment
EC Project IST, DG Comp. Systems Budget 4
M Funding 2 M Duration 27
months Start 2006 Q1 Coordinator Henrik
Lönn, Volvo Technology Contact atesst-coordinator
_at_vtec.volvo.se Website www.atesst.org
OEM Partners Daimler, Volvo Car Corp, Volvo
Technology Corp, VW/Carmeq Suppliers Tool
vendors Delphi/Mecel, Continental, ETAS,
Mentor Graphics Research CEA, Kungliga
Tekniska Högskolan, TU Berlin
2
EAST-ADL2 Model Organization On Vehicle Level,
the Vehicle Feature Model represents the
externally visible properties of the vehicle On
Analysis Level, the abstract functional
definition of the vehicle systems is captured, to
allow analysis of vehicle content independently
of detailed design. On Design Level, the Design
Architecture represents the detailed design of
the functional content and hardware. The
Implementation Level is based on AUTOSAR, and
thus contains the Software Architecture and
target hardware. The Environment Model captures
the surrounding environment including vehicle
mechanics and external systems. This model is
common to all abstraction levels, as the external
environment is the same, regardless of
representation of the EE architecture. Sensors
and actuators on the respective abstraction level
serve as interface to the Environment Model
Vehicle level
1
2
Analysis Level
6
Design Level
5
4
Implementation Level
3
The EAST-ADL2 is organized in several abstraction
levels, to allow focus on a limited set of
concerns in the respective sub-model. Each
sub-model is a representation of the EE System of
the vehicle on the respective level of
abstraction.
1 Product Line definition is captured by a
feature model on vehicle level. Models on lower
abstraction levels realize the content and
variability.
5 The artefact models are complemented by error
models to support safety related aspects.
Hazards, failures and failure propagation are
defined to support documentation and analysis.
3 The Software Architecture is represented by
AUTOSAR entities.
4 The EE System model on the respective
abstraction level is connected to the Environment
Model using connectors.
6 Requirements can be allocated to any entity in
the model. Requirements can be traced from the
top level requirements to refined requirements.
2 Entities on a lower abstraction level are
realizations of entities on the higher levels.
This is modelled and traced.
Orthogonal aspects like requirements,
variability, VV and traceability information are
associated to any entity, incl. AUTOSAR entities.
3
Variability Modeling Prototype tool allows
feature modeling of the vehicle and system
characteristic at the VFM level
Support of RIF-conforming project-specific
specification extensions
Requirements/VV Domain model and prototype
tool supports description and traceability from
Requirement to VV Test Case
On the artifact level (e.g. Analysis/Design
level) variability is driven by the vehicle
feature model as a starting point.
Artifact-specific variability is represented as a
feature model for each artifact element and for
all artifact lines
RIF Requirements Interchange Format is
currently defined by german automobile
manufacturers (HIS Hersteller Initiative
Software), see www.automotive-his.de
Safety Example from demonstrator Domain model
allows modeling of likely component errors and
their propagations of various types and capturing
of the traceability to system requirements, VV
cases, and environmental conditions
Prototype plug-in allows automatic synthesis of
fault trees and FMEA tables and detailed safety
analysis through an external tool (HiP-HOPS).
AUTOSAR Example from demonstrator Prototypes
tool supports capturing AUTOSAR systems and
software component via UML2 profile and specify
relation of AUTOSAR models with ADL
entities AUTOSAR Integration via ETAS INTECRIO
(Integrated prototyping environment for virtual
rapid prototyping)
Tool Platform Papyrus, Open Source UML2 Modeling
and profiling Environment based on
Eclipse http//www.papyrusuml.org