| [auto-iwg] [Eclipse AUTO IWG] [Edona project] Newsletter n° 2, July 2009] + [TIMMO Newsletter June 2009] |
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 ====================================== Work Package Specific Information ====================================== 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. ====================================== 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 Agenda Date: Tuesday,
September 29,
2009, 09:00-16:00 Place: Denso
AUTOMOTIVE
Deutschland GmbH, Freisinger Str. 21, 85386 Eching, (near
====================================== ====================================== ================ Work Package Specific Information ================ ================ 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. ================ ================ 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:
For the
validation and verification
of the timing requirements (expressed in TIMMO TADL), the following
tools are
applied:
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 Commissariat à l'Énergie
Atomique LIST Continental
Automotive GmbH DENSO ETAS
Entwicklungs- und
Applikationswerkzeuge für elektronische Systeme GmbH Robert Bosch
GmbH Siemens AG -
Siemens IT Solutions
and Services Symtavision GmbH TTTech
Computertechnik AG Volkswagen AG Volvo ZF
Friedrichshafen AG
[1] These requirements can be expressed using the EAST-ADL
element
ADLRequirement. This element is specialized to specify different types
of
[non-functional] requirements, like design constraints, quality,
safety, etc. [2] The Implementation Phase is described in the next
newsletter (July
2009) in detail. 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 |
Attachment:
EDONA Newsletter July 2009-v7.pdf
Description: Adobe PDF document
begin:vcard fn:Patrice Raynal n:Raynal;Patrice org:Obeo;Model Driven Company adr:;;2, route de la Noue BP76;Gif-sur-Yvette;;91193 ;France email;internet:patrice.raynal@xxxxxxx tel;work:+33 (0)1 64 86 58 50 tel;fax:+33 (0)1 64 86 18 19 tel;cell:+33 (0)6 89 99 85 29 url:www.obeo.fr version:2.1 end:vcard