Post on 26-Jun-2020
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
2009-09-29 TIMMO's Final Open Workshop Slide 2
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
2009-09-29 TIMMO's Final Open Workshop Slide 3
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
2009-09-29 TIMMO's Final Open Workshop Slide 4
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)
2009-09-29 TIMMO's Final Open Workshop Slide 5
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
2009-09-29 TIMMO's Final Open Workshop Slide 6
Context
• AUTOSAR– Specification of Timing Extensions
• The EAST-ADL2 Architecture Description Language– developed further by the ATESST2 project
• The relation to the TIMMO Project
2009-09-29 TIMMO's Final Open Workshop Slide 7
AUTOSAR
2009-09-29 TIMMO's Final Open Workshop Slide 8
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.
2009-09-29 TIMMO's Final Open Workshop Slide 9
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.
ApplicationInterfacesMethodology
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.
ApplicationInterfacesMethodology
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
2009-09-29 TIMMO's Final Open Workshop Slide 10
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
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
API 3 PrivateInterfaces inside Basic Software
possible
AUTOSAR ECU Software Architecture
2009-09-29 TIMMO's Final Open Workshop Slide 11
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
2009-09-29 TIMMO's Final Open Workshop Slide 12
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
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
StandardizedInterface
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
2009-09-29 TIMMO's Final Open Workshop Slide 13
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
2009-09-29 TIMMO's Final Open Workshop Slide 14
EAST-ADL
2009-09-29 TIMMO's Final Open Workshop Slide 15
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
2009-09-29 TIMMO's Final Open Workshop Slide 16
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
2009-09-29 TIMMO's Final Open Workshop Slide 17
Principles of Realization
• Entities on lower abstraction levels realize entities on higher abstraction levels
2009-09-29 TIMMO's Final Open Workshop Slide 18
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
2009-09-29 TIMMO's Final Open Workshop Slide 19
… back to TIMMO
2009-09-29 TIMMO's Final Open Workshop Slide 20
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»...
2009-09-29 TIMMO's Final Open Workshop Slide 21
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
2009-09-29 TIMMO's Final Open Workshop Slide 22
Overall Timeline
2006 2008
ATESST
2010
ATESST2
TIMMO
AUTOSAR
2005 2007 20092004
2009-09-29 TIMMO's Final Open Workshop Slide 23
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
2009-09-29 TIMMO's Final Open Workshop Slide 24
DiscussionQuestions and Answers
Thank you very much for your attention!