Dear group,
Please find enclosed the second EDONA Newsletter.
You will find it also included in the EDONA website from September.
here is the link where you can find information about this project:
http://www.edona.fr/scripts/home/publigen/content/templates/show.asp?L=EN&P=55&vTicker=alleza
About communication from TIMMO project:
************ Sorry for
multiple copies ************
TIMMO
Newsletter June 2009
======================================
TIMMO’s Final Open Workshop
Work Package Specific Information
http://www.timmo.org/
======================================
Dear
Colleague,
this
newsletter gives current
information of the TIMMO project for you interested in the area of
Timing
Modelling, Automotive Systems Development, and AUTOSAR.
This sent
newsletter gives only some
overview information. Please find the complete newsletter including
figures on
the TIMMO website: https://www.timmo.org/newsletter0609.html.
======================================
TIMMO’s Final Open Workshop
Participation
to the TIMMO Final
Open Workshop is free of charge and open to everyone interested. Please
inform
Ramin Tavakoli Kolagari (ramin.tavakoli@xxxxxxxxx)
if you intend to join the workshop stating your name and company latest
until Friday, September 18, 2009.
Please refer to
the TIMMO website https://www.timmo.org/events.htm for
detailed
information on the Final Workshop.
IMPORTANT: The Final Workshop will
take place parallel to the Munich
“Oktoberfest”,
so make sure that you are quick with booking the hotel.
Agenda
Date: Tuesday,
September 29,
2009, 09:00-16:00
Place: Denso
AUTOMOTIVE
Deutschland GmbH, Freisinger Str. 21, 85386 Eching, (near Munich Airport), Germany
08:00 – 09:00
|
|
Arrival and Coffee
|
09:00 – 09:20
|
1.
|
Introductory Note
and round table
|
09:20 – 10:00
|
2.
|
General Introduction
to the TIMMO project and relation to other projects
|
10:00 – 10:20
|
3.
|
Tools for Timing
(TADL VSA, Symta/S, TTTech, ETAS)
|
10:20 – 11:00
|
4.
|
Timing Modelling at the Vehicle Level (TADL syntax
and semantic and TIMMO methodology and one validator view (practical
experience, also with applied tools))
|
11:00 – 11:15
|
|
Coffee Break
|
11:15 – 12:15
|
5.
|
Timing Modelling at the Analysis and Design Level (TADL syntax
and semantic and TIMMO methodology and one validator view (practical
experience, also with applied tools))
|
12:15 – 13:00
|
6.
|
Timing Modelling at the Implementation Level (TADL syntax
and semantic and TIMMO methodology and one validator view (practical
experience, also with applied tools))
|
13:00 – 13:10
|
7.
|
Wrap-up
|
13:10 – 14:00
|
|
Lunch
|
14:00 – 16:00
|
|
Coffee Break and Exhibition of TIMMO Validators, TIMMO
Tools, TIMMO Methodology, Poster Presentations
|
======================================
======================================
================
Work Package Specific Information
WP3 TIMMO Methodology
WP4 Validation
================
================
WP3 TIMMO Methodology
In the last
newsletter—May
2009—the purpose of the Analysis Phase has been described. In this
newsletter we discuss what happens during the Design Phase. The focus
of the
Design Phase is the abstraction level called Design Level. The main
artefacts
created and altered respectively are the Functional Design Architecture
(FDA),
the Middleware Abstraction (MWA), the Hardware Design Architecture
(HWDA), the
Communication Design Architecture (CDA), the Design Constraints, and
the Design
Timing Requirements. The first four work products are combined to form
the
deliverable Design Architecture (DA).
The TIMMO
methodology specifies a
number of tasks that are performed during the Design Phase.
The three
activities/tasks of the
Design Phase "Create functional design architecture", "Create
middleware abstraction", and "Create hardware and communication
architecture" can be performed concurrently. In this case the roles
performing these tasks shall ensure the proper collaboration and
synchronization among each other.
By and
large, in the Design Phase
the Functional Analysis Architecture (FAA) is transformed into the
Functional
Design Architecture (FDA) considering the Analysis Timing Requirements
and
additional requirements stated in a requirements document[1]. [In the case that a
FDA already exists then this existing FDA is altered. Typically, this
is the
case when an existing system is being changed. For example a new
function is
added to the FAA, which means that a new feature—specified in the
VFM—is becoming available in the vehicle eventually.] Once the FDA is
completed the Design Timing Requirements are stated which shall be
considered
during the next phase, the Implementation Phase[2]. The second half of the
Design Phase is dealing with mapping functions in the FDA to
hardware/processing elements, assigning the resulting timing
properties to
the solution, and to analyze and verify the resulting timing of the
particular
solution. These steps can be repeated for possible mappings that
one—most
likely the role FDA Architect—can identify (Design Space Exploration,
Architectural Exploration).
The tasks of
the Design Phase are
briefly described in the following.
Assign
functionality to HW or SW. Based on the given timing
requirements the decision
has to be taken whether a function and/or parts of such function are
provided
by hardware or software, or both, eventually. Typically, on this level
of
abstraction one—most likely the role Architect[3]—has already a
conception/idea of the specific target system and its capabilities, for
example
regarding processing capabilities. Based on this knowledge and
assumptions
one concludes that a particular function needs to be realized in
hardware on
the Implementation Level/Phase, because of the fact that the timing
requirements are too tight for a software realization. Why should this
decision
be taken at the beginning of this phase? The reason is that the
decision be
taken have an impact on the design of the Functional Design
Architecture,
Middleware Abstraction, and Hardware Design Architecture. Once one
specified
that a function shall be realized in hardware, then the middleware must
provide
the corresponding services to access and control the hardware, and the
Functional Design Architecture must provide means to access the
middleware. And
last but not least, the specific hardware elements should be included
in the
Hardware Design Architecture.
Create Functional
Design Architecture. The main purpose of this
task is to create the
design based on the Functional Analysis Architecture. In essence, this
task is
answering the question how the system achieves the requested
functionality—in contrast to the question answered on the Analysis
Level:
What the system shall perform? The Functional Analysis Architecture and
the
Analysis Timing Requirements are mandatory work products for this task.
[In
addition an existing Functional Design Architecture is/must be used,
too.] The
work product created or altered by this task is the Functional Design
Architecture. Decisions taken during this task possibly have an impact
on the
Middleware Abstraction and the Hardware Design Architecture.
In a first
step all ADL Functions
and the Functional Devices in the FAA are transformed into separate ADL
Functions and Local Device Managers in the FDA.
For example
the function Brake
Controller is transformed into an ADL Function called Brake Controller;
the
functional devices Brake Pedal, Brake Actuation, and Stop Light
Actuation are
transformed to the Local Device Managers called Brake Pedal, Brake
Actuation,
and Stop Light Actuation. The ports attached to these components are
transformed one-by-one, too. All inter-connections between the
functions,
functions and functional devices that connect the ports with each other
are
also transformed into the FDA.
With regard
to timing, the events,
event chains and event chain segments given in the FAA are transformed
to the
FDA as well. The timing requirements/constraints attached to the
various event
chains and event chain segments are considered as time budgets for
performing
any refinement on this level of abstraction. The events, event chains
and event
chain segments introduced on the Analysis Level were shown and
described in the
TIMMO newsletter May 2009.
In a second
step the FDA is refined,
and in the given example the composite ADLFunction Brake Controller is
decomposed and refined respectively into elementary ADLFunctions.
The event
chain segment #2 (ECS #2)
still applies to the composite ADLFunction Brake Control and is the
time budget
for the path consisting of the elementary ADLFunctions Check Signal
Plausibility, Brake Force Calculation, and Brake Force Arbiter. This
time
budget—event chain—can be broken into three smaller time
budgets—event chain segment—for each of the three mentioned
elementary ADLFunctions. Besides this event chain and event chain
segments a
lot more event chains and event chain segment can be specified. For
example an
event chain can be specified for the path including the ADLFunctions
Check
Signal Plausibility, Brake Safety Monitor, and Brake Force Arbiter. At
this
point the main question to be answered is where is the critical path
(event
chain) in terms of timing, and how the other identified event chains
and event
chain segment respectively are related to this path, for example
identifying
points where synchronization is an important topic, or at which rates
the data
should be provided and processed.
Create Middleware
Abstraction. The purpose of this task is
to create the work
product Middleware Abstraction (MWA). This work product describes the
common
services required by the various ADLFunctions in the FDA, or from
another point
of view describes common services of the [runtime/execution platform]
infrastructure that can be used by the ADLFunctions in the FDA. Such
services
are storing and retrieving diagnostic data in/from the persistent
storage,
libraries for performing mathematical calculations, messaging services,
etc.
Create HW design
and communication architecture. The work products Hardware
Design
Architecture (HWDA) and Communication Design Architecture (CDA) are
created by
this task. By and large the sensors, actuators, electronic control
units (ECU),
and networks/busses are described that are part of the vehicle's
electrical and
electronic (EE) system.
The
Communication Design
Architecture (CDA) contains the description of network topology and
further
characteristics/information about communication aspects which are
important for
design decisions regarding network that are taken in the next phase the
Implementation Phase.
Create Design
Requirements. The main purpose of this
task is, in addition to
specify the design requirements, a.k.a. design constraints, to specify
the
timing requirements/constraints. In essence, the FDA and MWA are
annotated
using the language elements provided by the Timing Augmented
Description
Language. For example event chains, reaction constraints, age timing
constraints, etc.
Map functional
design architecture to HW design architecture. This
task maps the
ADLFunctions described in the FDA to available electronic control units
defined
in the HWDA. For example, the Logical Device Manager Brake Pedal is
mapped to
the electronic control unit Brake Pedal, the Logical Device Manager
Brake
Actuator is mapped four times to the four electronic control unit Brake
Actuator, and last but not least the ADLFunction Brake Controller is
mapped to
the electronic control unit Rear Body Controller Unit. This is one
possible
mapping among other ones which means that the ADLFunction Brake
Controller can
be mapped to the electronic control unit Pedal Module, as well.
The impact
of different mappings can
be analyzed in the timing analysis tasks that follow later. Upon the
results of
the timing analyses one can select another mapping in order to improve
the [timing]
robustness of the system.
Assign Timing
Properties. After a possible mapping or
deployment of the various ADLFunctions
have been performed, this task assigns timing properties to the
components,
like busses, ADLFunctions, etc. if they are already known.
The tasks
described below are
related to the timing analysis of the Design Phase's work products, in
other
words the timing analysis of the proposed functional design. Each of
these
tasks listed below has a specific purpose and scope regarding timing.
The
results of the analyses performed by the tasks are captured in the work
products (outcomes) Response Time Analysis Report, Performance Report,
and
Resource Consumption Assessment Report.
The timing
analyses during this
phase shall verify whether the given solution satisfies the given
timing
requirements stated in the Analysis Timing Requirements. In addition,
the
analyses shall make sure that the timing requirements stated in the
Design
Timing Requirements are sufficient for the next phase, the
Implementation Phase.
Analyze response
times. The purpose of this task is
to perform a response time analysis in
order to determine whether the selected functional design and very
first
mapping to hardware components satisfy the given timing requirements.
Analyze application
timing. The purpose of this task is
to perform the analysis of the
application's performance. The scope is the application rather the
entire
system and to come up with results that help to decide which parts in
the
functional design shall be revised.
Assess resource
consumption. The purpose of this task is
to asses the resource
consumption of the selected functional design. The main objective of
this task
is to obtain "good enough" data on resource consumption, like
processing performance, bandwidth consumptions ("bus load"), in order
to make a recommendation about whether to proceed with the subsequent
phase.
Check the results
of the Design Phase. At the end of the Design
Phase a milestone called
'Gate Design Phase' is defined. The purpose of this milestone is to
check that
all necessary work products are available and that the contents are
sufficient
in order to proceed with the next phase. At this point the decision is
taken
whether to continue, or to repeat the Design Phase in order to resolve
the
uncovered issues.
The
newsletter of this month is
rather long and I spent a significant amount of time on writing this.
For an
author nothing is more frustrating, than getting no feedback. Frankly,
I like
to hear from you and I am looking forward to get some feedback from
you. You
may have also spent a significant amount of your time on reading the
newsletter
so send me a message with your opinion to Stefan.Kuntz@xxxxxxxxxxxxxxxxxxxxxxxxxxx.
================
================
WP4 Validation
The general
functionality of the
Engine Management validator is the calculation of suitable ignition
times and
injection times for the combustion processes in the individual
cylinders of an
8-cylinder gasoline engine. Furthermore, it controls the throttle
attached to
the engine which governs the airflow in the intake system and thus
dictates the
delivered engine momentum.
The
objective of this validator is
to evaluate the developed concepts for TADL and its methodology based
on a
stand-alone ECU system with an AUTOSAR-compliant software architecture.
>From a
TIMMO methodology perspective, the focus is on the lower architecture
abstraction levels of the TIMMO system model, i.e. the design level
(EAST-ADL2)
and implementation level (AUTOSAR). The main goal of this validator is
the
validation and verification of timing properties of timing critical
functionalities which are implemented as AUTOSAR-compliant ECU system
against
their timing requirements.
Applied Tools
The
following tools are applied to
realize the Engine Management validator:
- ASCET v6.0: ASCET from ETAS has been
used to specify the AUTOSAR software components. The existing
functional model of the engine control application has been
“componentized” to AUTOSAR software components.
- RTA-RTE v2.1: RTA-RTE is an ETAS tool for
the generation of an AUTOSAR RTE for an ECU system. The tool has been
used to generate an optimized RTE from the ECU extract describing the
AUTOSAR ECU software architecture.
- RTA-OSEK v5.0: RTA-OSEK from ETAS is a
tool for the generation of an OSEK / AUTOSAR-OS compatible operating
system. RTA-OSEK is employed as operating system in the Engine
Management validator.
For the
validation and verification
of the timing requirements (expressed in TIMMO TADL), the following
tools are
applied:
- RTA-TRACE: RTA-TRACE from ETAS is a
logic analyzer which integrates with the RTA-OSEK operating system and
allows monitoring the dynamic real-time behaviour of an ECU system.
RTA-TRACE is used to measure the gross and net execution times of
operating system tasks as well as the RunnableEntities of the software
architecture. The measured values are used for a system-level timing
analysis by means of the system-level timing analysis tool SymTA/S.
- SymTA/S: SymTA/S from Symtavision is
a system-level timing analysis tool suite based on formal analysis in
the form of scheduling analysis. The system-level model of the software
is based on the tasks which constitute the executional behaviour of the
system and their dependencies in terms of data-flow and activation.
SymTA/S provides an upper bound for the maximum CPU utilization as well
as response times for individual software tasks (OS-tasks). Signal
paths spanning multiple OS-tasks can also be analyzed, resulting in
upper bound for signal-flow based response times.
Conclusions so far
The Engine
Management validator
shows the principal applicability of the TADL and the TIMMO methodology
based
on a single AUTOSAR-compliant ECU system.
With
adequate tool support
(RTA-TRACE and SymTA/S) it was possible to verify the system with
respect to
its timing behaviour.
In summary,
it can be stated that
TIMMO TADL and methodology are adequate means to handle timing related
engineering information during the development of AUTOSAR-compliant
systems.
================
======================================
Kindest
regards
the TIMMO
Project Team
Audi Electronics Venture
GmbH
Chalmers University
Commissariat à l'Énergie
Atomique LIST
Continental
Automotive GmbH
DENSO Europe
ETAS
Entwicklungs- und
Applikationswerkzeuge für elektronische Systeme GmbH
Mentor Graphics
Paderborn University
Robert Bosch
GmbH
Siemens AG -
Siemens IT Solutions
and Services
Symtavision GmbH
TTTech
Computertechnik AG
Volkswagen AG
Volvo Technology AB
ZF
Friedrichshafen AG
The TIMMO methodology defines a couple of roles called
Architect
which are responsible for the creation of different work products on
the Design
Level: FDA Architect, MWA Architect, and HWDA Architect.
Kind Regards,
And wishing you great holidays,
Patrice Raynal
Obeo
Model Driven Company
2 route de la Noue
91193 Gif-sur-Yvette
Phone: +33 (0)1 64 86 58 50
Mobile: +33 (0)6 89 99 85 29