General Introduction to the TIMMO Projectadt.cs.upb.de › timmo-2-use › timmo › pdf › 2_General_Introduction.pdf · Application Interfaces Methodology Architecture • Methodology:

2009-09-29 TIMMO's Final Open Workshop Slide 1

ITEA 2 – 06005: TIMMOTiming Model

General Introduction to the TIMMO Project

Friedhelm Stappert, TIMMO Project Co-ordinator


Project Facts

• ITEA2 Project

• Project Duration:– April 2007 – September 2009

• Consortium:– Audi, Volvo Technology, VW/Carmeq– Bosch, Continental, Denso Europe, ZF– ETAS, Mentor Graphics, Symtavision, TTTech– CEA-LIST, Chalmers University, C-LAB

• Budget: 8 Mio €, 64 PY

• Website: www.timmo.org


Project Goals

• Formal and standardized specification, analysis, and verification of timing constraints– across all levels of abstraction and– across all development phases

• Improved and predictable development cycle– timing can be addressed early in the development

process


Results

• Modelling Language for Timing– for modelling aspects like hardware resources, time consuming elements,

relationships between such elements, and timing constraints– Timing Augmented Description Language (TADL), based on an existing

Architecture Description Language: EAST-ADL

• Methodology– describe the steps that have to be followed during the different design

stages and on the different levels of abstraction– developed with Eclipse Process Framework (EPF)

• Validation– show the applicability of language and methodology– prototype developments of use cases and scenarios (5 different

demonstrators)


Example SystemWhat we want to express

Vehicle FunctionalityBraking

Stop LightActuation

Brake ForceActuation

Brake ForceActuation

Wheel Speed

Calculation

Brake Pedal PositionMonitor

Brake Controller

End-to-End DelayLatency

Synchronization

Synchronization

End-to-End DelayLatency


Context

• AUTOSAR– Specification of Timing Extensions

• The EAST-ADL2 Architecture Description Language– developed further by the ATESST2 project

• The relation to the TIMMO Project


AUTOSAR


What is AUTOSAR?

• AUTOSAR – AUTomotive Open System ARchitecture• De-facto standard, jointly developed by automobile

manufacturers, suppliers and tool developers • More than 100 member companies

• “Cooperate on standards, compete on implementation.”

• AUTOSAR …– paves the way for innovative electronic systems that

further improve performance, safety and environmental compatibility,

– is a key enabling technology to manage the growing E/E complexity,

– facilitates the exchange and update of software and hardware over the service life of the vehicle.


ApplicationInterfacesMethodology

Architecture• Methodology:

Exchange formats or description templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs and it includes even the methodology how to use this framework.


Architecture• Application Interfaces:

Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software.


Architecture• Architecture:

Software architecture including a complete basic or environmental software stack for ECUs – the so called AUTOSAR Basic Software – as an integration platform for hardware independent software applications.

AUTOSARMain Working Topics


ECU-Hardware

AUTOSAR Runtime Environment (RTE)

ActuatorSoftware

Component

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftware

Basic Software

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

Micro-controller

Abstraction

AUTOSARSoftware

Component

Interface

ECUFirmware

StandardSoftware

StandardizedAUTOSARInterface

Services ECUAbstraction

AUTOSARInterface

ComplexDeviceDrivers

AUTOSARInterface

API 2VFB & RTErelevant

Communi-cation

OperatingSystem

API 1RTErelevant

API 0Standardized

Interface

StandardizedInterface






API 3 PrivateInterfaces inside Basic Software

possible

AUTOSAR ECU Software Architecture


AUTOSAR Methodology on one slide

Virtual Functional Bus

SW-C

1

SW-C

2

SW-C

3

SW-C

n...

ECU m

AU

TOSA

RSW

-Cn

RTE

Basic Software

...

Mapping

System ConstraintDescription

ECUDescriptions

System configuration

Gateway

SW-C Description

ECU II

AU

TOSA

RSW

-C2

RTE

Basic Software

ECU I

AU

TOSA

RSW

-C1

RTE

Basic Software

AU

TOSA

RSW

-C3

Standardized exchange formats and methodology


ActuatorSoftware

Component

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftware

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

Basic Software Micro-controller

Abstraction

StandardizedAUTOSARInterface

Services ECUAbstraction

AUTOSARInterface

ComplexDeviceDrivers

AUTOSARInterface

Communi-cation

OperatingSystem








Application LayerAUTOSAR

InterfaceAUTOSARInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

Semantics of Interfaces: § Physical properties, units, etc.§ Supporting re-use across products

Syntax of Interfaces: § Supporting transferability within the network

AUTOSAR Application Interfaces


AUTOSARSummary

• De facto standard for automotive system architecture

• 3 main areas:– Architecture– Methodology– Application interfaces

• What was missing:– Means to handle timing information in the 3 areas


EAST-ADL


EAST-ADL2

Architecture Description Languagefor handling all engineering information required to sustain theevolution of vehicle electronics

• A template for how engineering information is organized and represented

• Provides separation of concerns:– feature definition, requirements engineering, V&V, safety analysis,

functional modeling/integration, product line engineering• Embrace the de-facto

representation ofautomotive software –AUTOSAR

Vehicle Level

Analysis Level

Design Level

Implementation Level

Operational Level

Feature content

Abstract functional architecture

Functional architecture,HW architecture, platform abstractions

AUTOSAR Software architecture

Embedded system in produced vehicle


EAST ADL2Abstraction Levels and AUTOSAR Views

Level of abstraction

Artifact

ImplementationLevel

OperationalLevel

Implementation ArchitectureAUTOSAR Implementation

VFB, System, and ECU View

Operational ArchitectureAUTSAR Implementation

System and ECU View

FeatureLevel

AnalysisLevel

DesignLevel

HardwareDesign

Architecture

FeatureModel

Functional AnalysisArchitecture

Functional DesignArchitecture

MiddlewareAbstraction

Mapping

EnvironmentModels

AUTOSAR DesignVFB View


Principles of Realization

• Entities on lower abstraction levels realize entities on higher abstraction levels


Relation to other Approaches

• Why Not UML?– EAST-ADL is implemented as a UML2 profile, adding properties

for embedded systems.

• Why not SysML?– EAST-ADL is a specialization of applicable SysML concepts

• Why not AUTOSAR?– EAST-ADL complements AUTOSAR with additional abstraction

levels

• Why not proven proprietary tools (Simulink, Statemate, Modelica, ASCET, …)?– EAST-ADL2 integrates external tools and provides an information

structure for the engineering data regardless of tool


… back to TIMMO


ImplementationLevel

FeatureLevel

AnalysisLevel

DesignLevel

OperationalLevel

Level of abstraction

AUTOSAR

Timingon different Abstraction Levels

OEM – «Constraint» The doors shall be unlocked not later than 1 seconds after a valid [transponder] key has been recognized.

Supplier – «Property» The function (runnable) unlockDoorresponds within 120 ms (nominal) to a request to unlock the doors. [Assumption: The function is executed on a X12 6MHz processor ... ]

?How are timing constraints broken down into timingconstraints/properties; and how are timing properties

transformed into timing constraints/properties?

«Property», «Constraint»...

«Constraint», «Property»...


Relation to other projects

• AUTOSAR– TIMMO Timing Model aligned with AUTOSAR– AUTOSAR "Specification of Timing Extensions" (for R4.0) developed in

cooperation with TIMMO• TIMMO Partners worked in the AUTOSAR Timing Subgroup

– TIMMO Methodology aligned with AUTOSAR

• ATESST2 / EAST-ADL2– TIMMO covers all abstraction levels of the EAST-ADL2– TIMMO Timing Model to be included

in EAST-ADL2 (common UML Profile)– TIMMO Methodology and

ATESST2 Methodologyshall be aligned

Vehicle Level

Analysis Level

Design Level

Implementation Level

Operational Level


Overall Timeline

2006 2008

ATESST

2010

ATESST2

TIMMO

AUTOSAR

2005 2007 20092004


TIMMO Validators

• Validator 1: Anti-lock Braking SystemContributor: Volvo Technology

• Validator 2: Steer-by-Wire and Active DampingContributors: TTTech, University of Paderborn, Symtavision

• Validator 3: Engine ControlContributors: Bosch, ETAS

• Validator 4: Transmission ControlContributors: ZF Friedrichshafen AG, Symtavision

• Validator 5: Cruise Control & Security SystemContributor: Continental

• Validator 6: Vehicle Dynamics ControlContributor: Denso


DiscussionQuestions and Answers

Thank you very much for your attention!

Documents

General Introduction to the TIMMO Projectadt.cs.upb.de › timmo-2-use › timmo › pdf › 2_General_Introduction.pdf · Application Interfaces Methodology Architecture • Methodology: