EAST-ADL

1
EAST-ADL An Architecture Description Language
IFIP World Computer Congress Toulouse
France 27 August 2004 Workshop on Architecture
Description Languages WADL2004

• Vincent De Bruyne PSA Peugeot Citroën
• Françoise Simonot-Lion LORIA (UMR 7503)
• Yvon Trinquet IRCCyN (UMR 6597)

2
Contents

• Context - Problematic
• EAST ADL
• Verification process modelling
• A case study
• Conclusion

3
Context Problematic (1/6)
Automotive Electronic Features- Challenge
EMS
ABS
Transmission Control
ESP
ACC
BbW
XbW
1980
2010
Increasing complexity, criticality, design effort
... gt How to master the development of these
systems?
4
Context Problematic (2/6)

• Functional complexity

- Multivariable control laws - Complex
interaction between functions - Critical
functions - safety / reliability /
availability - performances / time
constraints

• Architectural complexity

- Distribution - Heterogeneity
(micro-controllers, networks) - Various vehicle
domains (body, chassis, Powertrain, telematics)
5
Context Problematic (3/6)

• Development process

- Shared between suppliers and car makers -
 black / white / grey boxes , IP -
Reusability, Standards

• Verification and Validation activities

- Various levels for the design ? various VV
techniques - At functional level ?
functional validation
(Matlab/Simulink, Automata, MSC
) - At a lower design level ?
Schedulability, Performance evaluation,
code verification, code coverage
(Timed automata, analytical techniques,
queuing systems, static analysis ) - At the
integration step ? tests
6
Context Problematic (4/6)

• Very complex system engineering
• Similar activities at different automotive
  companies
• Several projects involving car makers,
  suppliers EEA, Titus, Eucar-WGs
• ? EAST-EEA project proposal
• Electronic Architecture and Software Technology
  Embedded Electronic Architecture

7
Context Problematic (5/6)

• EAST-EEA project ITEA label

• - 4 countries Italy, Germany, France, Sweden
• - 23 partners Car Makers, Suppliers, Tool
  Editors, Research Institutes
• - 3 years (mid 2001 mid 2004)
• - Objectives
• - Common specification of middleware services
  for portability and interoperability
• of distributed software components
• - Specification of an Architecture Description
  Language
• - Concepts for integration of development
  tools
• - Prototypical validation
• ? A framework for a potential
  standardised middleware based
• software architecture for networked vehicle
  electronic systems

8
Context Problematic (6/6)

• EAST-EEA project workflow

WP2 Runtime Aspects
WP4 Domain specific Aspects (validators)
WP1 General Aspects
WP3 Development Validation Aspects
9
EAST ADL (1/4)

• A means to describe electronic functionalities
  on several abstraction levels - from high level
  user-visible electronic features - down to
  implementation details (tasks, frame )

• 5 levels of abstraction - Vehicle, Analysis,
  Design, Implementation, Operational which are
  populated by - 7 artefacts (the process
  elements that the language describes)

• The levels and artefacts have been selected to
  allow - various company specific development
  processes - enhanced separation of software and
  hardware development

10
EAST ADL (2/4)

• EAST-ADL also supports the modelling of
  non-structural aspects - Requirements -
  Behaviour description - Validation
  Verification activities

• EAST-ADL based mainly on UML2
• - Intention of constituting a UML2 profile

11
EAST ADL (3/4)

• EAST-ADL language elements 5 main parts (?
  language domains) - Structure FunctionalAnalysis
  Architecture, CompositeSoftwareFunction,
  FunctionPort, ElementarySoftwareFunction,
  OSTask, Frame, ECU - Behaviour
  ExternalBehaviour, NativeBehaviour -
  Requirements FunctionalRequirement,
  QualityRequirement, EndToEndDelay - V
  V VVCase, FormalAnalysisCase, Property -
  Variant handling

• Artefacts the result of a specific analysis a
  particular view - 4 artefacts for the
  application software Vehicle View, Functional
  Analysis Architecture, Functional Design
  Architecture, Logical Architecture
• - 3 artefacts for the implementation Hardware
  Architecture, Technical Architecture,
  Operational Architecture

12
EAST ADL (4/4)
Vehicle View
Functional Analysis Architecture
Functional Design Architecture
Hardware Architecture
Logical Architecture
Technical Architecture
Operational Architecture
13
VV process modelling
1..
1


1..

1..

1
1

1..
1..
1..


14
Case study a functional point of view
Functions F1, F2, , Fproducer , , Fconsumer ,
, Fn
exchanging signals S1, , VehicleSpeed , , Sp
VehicleSpeed
Quality Requirement -at Vehicle View,
 tolerance to EMI perturbations  -at
Functional point of view,  deadline for
VehicleSpeed exchange is 2ms percentage of
missed deadlines ? 20 
15
Case study a hardware point of view
ECU ECU1, , PowerTrainECU , ,
SteeringControlECU , , ECUm
connected on networks N1, , CANChassis , , Nr
CANChassis
16
Case study an operational point of view (1/3)

• ElementarySoftwareFunction objects
• are realized as FunctionInstance objects

• FunctionInstance objects are grouped into
  LogicalCluster objects

17
Case study an operational point of view (2/3)

• One LogicalCluster object is deployed on one
  OSTask object

• One OSTask object runs on one Processor object /
  one ECU object

18
Case study an operational point of view (3/3)

• Fproducer and FConsumer are realized through two
  distant OSTasks

• ? VehicleSpeed is exchanged through the
  CANChassis bus

Quality Requirement -at Vehicle View,
 tolerance to EMI perturbations  -at
Functional point of view,  deadline for
VehicleSpeed exchange is 2ms percentage of
missed deadlines ? 20  ?  the percentage of
missed deadlines for signal VehicleSpeed ? 20 
19
Case study a verification activity (1/8)

• Vacans is an analytical method applied to the set
  of frames (periodic or sporadic) transmitted on a
  CAN bus
• each frame m is described by
• Tm (period / minimum interarrival time),
• Cm (transmission time),
• Dm (deadline),
• Jm (maximum jitter)
• Analytical evaluation of the Worst-Case Deadline
  Failure Probability for each frame under a given
  error pattern

20
Case study a verification activity (2/8)

• error pattern modelled by a generalized Poisson
  process (l,u,a)

t
21
Case study a verification activity (3/8)

• Vacans method step 1
• For each frame m, evaluation of the
  maximum tolerable errors threshold and
  the corresponding response time
• For each k0, k1,
• Evaluation by a recurrent equation
  of , the response
• time of m when k errors occur
  
• is the last k so that

22
Case study a verification activity (4/8)

• Vacans method step 2
• For each frame m, evaluation of the probability
  that more than
• errors occur in

worst-case deadline failure
23
Case study a verification activity (5/8)
Property to verify  the percentage of missed
deadlines for signal VehicleSpeed ? 20 
signal  VehicleSpeed 
 Frame_25 
EAST-ADL compliant Data Base (XML)
24
Case study a verification activity (6/8)
Property to verify  the percentage of missed
deadlines for signal VehicleSpeed ? 20 
 Frame_25 
 CANChassis 
EAST-ADL compliant Data Base (XML)
 CANChassis 
25
Case study a verification activity (7/8)
Property to verify  the percentage of missed
deadlines for signal VehicleSpeed ? 20 
 CANChassis 
 Frame_2   Frame_25   Frame_43 
 Frame_2   Frame_25   Frame_43 
EAST-ADL compliant Data Base (XML)
 CANChassis 
26
Case study a verification activity (8/8)
Property to verify  the percentage of missed
deadlines for signal VehicleSpeed ? 20 
completed manually by
Vacans tool
27
Conclusion

• Major version of the language used in
  demonstrators
• The paper has only focused on partial VV
  aspects
• A language editor has been designed, based on
  GME2000 tool
• language specification freely available at
  http//www.east-eea.net (see dowload item)
• transfer of experience into pratice in AUTOSAR
  initiative http//www.autosar.org