Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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:

About communication from TIMMO project:

************ Sorry for multiple copies ************


TIMMO Newsletter June 2009



TIMMO’s Final Open Workshop

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:



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 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.



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


Introductory Note and round table

09:20 – 10:00


General Introduction to the TIMMO project and relation to other projects

10:00 – 10:20


Tools for Timing (TADL VSA, Symta/S, TTTech, ETAS)

10:20 – 11:00


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


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


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



13:10 – 14:00



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

[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.

[3] 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
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

fn:Patrice Raynal
org:Obeo;Model Driven Company
adr:;;2, route de la Noue BP76;Gif-sur-Yvette;;91193 ;France
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

Back to the top