The TIMMO Methodology Guest Lecture at Chalmers University February - PowerPoint PPT Presentation

ITEA 2 – 06005: TIMMO Timing Model The TIMMO Methodology Guest Lecture at Chalmers University February 9 th , 2010 Stefan Kuntz, Continental Automotive GmbH 2010-02-09 Chalmers University, Göteborg Slide 1

Objectives TIMMO • Solving the problem of describing the timing requirements imposed on and temporal behavior of a distributed real-time embedded software- intensive system • Define a language to specify – timing requirements and constraints – timing properties • Provide the capability to analyze and assess timing, a.k.a. temporal behavior, of a system beginning at early stages of the development process • Define a methodology that enables one to apply the language in different scenarios • Alignment with Aut omotive O pen S ystem Ar chitecture AUTOSAR 2010-02-09 Chalmers University, Göteborg Slide 3

Objectives AUTOSAR Timing Subgroup and TIMMO AUTOSAR Timing Subgroup 1 Timing Model TIMMO • Augmenting AUTOSAR with • Methodology. Formal and timing properties for the analysis standardized specification, of a system’s dynamics analysis, and verification of timing properties and constraints • Augmenting AUTOSAR with across all development phases. timing constraints for the validation of a system’s • Language. Formal and dynamics standardized specification, analysis, and verification of • Consolidated and consistent timing properties and constraints representation of timing on all levels of abstraction. information • Early validation. Improved and • Integration of feedback from predictable development cycle ITEA 2 project TIMMO 1 AUTOSAR Release 4.0 2010-02-09 Chalmers University, Göteborg Slide 4

Objectives Reflections on Timing Requirements and Properties OEM – «Requirement» The doors shall be unlocked not later than 1 second after a valid [transponder] key has been Vehicle recognized. Level (EAST-ADL) «Requirement», Analysis «Property» ... Level (EAST-ADL) ? Design How are timing constraints broken down into timing constraints/properties; and how are timing properties Level (EAST-ADL) transformed into timing constraints/properties? Implementation «Property», Level (AUTOSAR) «Requirement» ... Operational Supplier – «Property» The function (runnable) unlockDoor Level (AUTOSAR) responds within 120 ms (nominal) to a request to unlock the doors. [Assumption: The function is executed on a X12 6MHz processor, etc.] Level of abstraction 2010-02-09 Chalmers University, Göteborg Slide 5

Objectives Time Budgeting OEM – «Constraint» The doors shall be Vehicle Time Budget unlocked not later Level (EAST ADL) 1s than 1 second after a valid [transponder] key has been recognized. Analysis 200 75 200 400 125 ms ms ms ms ms Level (EAST ADL) Design 25 100 30 75 ms ms ms ms Level (EAST ADL) Supplier – «Property» Implementation 33 9 The function Level (AUTOSAR) ms ms (runnable) unlockDoor responds within 1,2 ms (nominal) to a Operational request to unlock the 3,5 1,2 4,1 doors. [Assumption: Level (AUTOSAR) ms ms ms The function is executed on a X12 6MHz processor ... ] Level of abstraction Time Budget 2010-02-09 Chalmers University, Göteborg Slide 6

EAST-ADL Level of Abstraction Vehicle Feature Model Level Analysis Preliminary Functional Analysis Hardware Design Level Architecture Architecture/Model Design Hardware Environment Functional Design Middleware Design Models Architecture Abstraction Level Architecture/Model Implementation Implementation Architecture AUTOSAR AUTOSAR VFB, Software Component, System, ECU Resource Level Basic Software Module, and ECU view Description Operational Operational Architecture AUTOSAR ... Level Level of abstraction Artifact 2010-02-09 Chalmers University, Göteborg Slide 7

Modeling Methodology SPEM and Eclipse Process Framework (EPF) Composer • Software Process Engineering Role – Performer Meta-Model • Method content elements: Task, work product, and role • Process elements: Phase, activity, task, milestone Task Artifact Artifact Input Output Work Product Work Product • Special care has been taken on the highly iterative and repeatable nature of the methodology on different levels: – Task – Sequence of tasks – Phases (Abstraction Levels) 2010-02-09 Chalmers University, Göteborg Slide 8

EAST-ADL Methodology and Timing Artifacts – Simplified View Vehicle Create Annotate Analyze Validate V Level/Phase VFM VFM Timing Timing TR Analysis Create Annotate Analyze Validate A Level/Phase FAA FAA Timing Timing TR Design Create Annotate Analyze Validate D FDA, FAA, Timing Timing Level/Phase TR HDA, ... HDA, ... Implementation Create Annotate Analyze Validate AR Level/Phase SW-CT, ... SW-CT, ... Timing Timing TR Operational Measure Annotate Validate Runtime Models Timing Level/Phase VTR Vehicle Timing Requirements ATR Analysis Timing Requirements XML Level of abstraction/phase Task DTR Design Timing Requirements ARTR AUTOSAR Timing Requirements 2010-02-09 Chalmers University, Göteborg Slide 9

Events and Event Chains Events • Event – State or Change in State – Observable at specific locations in the system subject to analysis • Event Model – Periodic – Sporadic – Pattern – Arbitrary 2010-02-09 Chalmers University, Göteborg Slide 10

Events and Event Chains Event Chains Stimulus Response • Relating events • Causality EC Response/Stimulus ECS ECS ECS ECS ECS ECS Strands Segment Segment EC Event Chain ECS Event Chain Segment 2010-02-09 Chalmers University, Göteborg Slide 11

Events and Event Chains Constraints and Description «Event Constraint» «Delay Constraint» «Synchronization C.» «Event Constraint» Periodic, Sporadic, ... Age/Reaction Input/Output Periodic, Sporadic, ... «Event Chain» Stimulus Response «Timing Description» Observable Observable Event Event TADL specifies a couple of predefined Observable Events on the Analysis and Design Level: EventADL- InFlowPort, EventADLOutFlowPort, EventADLServerPort, EventADLClientPort, etc. On Implementation Level AUTOSAR Timing Extensions (R4.0) specifies a couple of predefined Observable Events. 2010-02-09 Chalmers University, Göteborg Slide 12

Events and Event Chains EAST ADL Abstraction Levels, Events, and Timing Events are refined across the Event Vehicle levels of abstraction. An event on Level (EAST ADL) one level may be refined into a sequence of events (causality) on Analysis the level of abstraction beneath. Level (EAST ADL) Event models (periodic, sporadic, pattern, arbitrary) are specified for Design events. Level (EAST ADL) On the operational level all events given on the implementation level Implementation occur over time. Level (AUTOSAR) Operational Level (AUTOSAR) Event Occurrences time Level of abstraction 2010-02-09 Chalmers University, Göteborg Slide 13

Example Braking System – Boundaries Brake/Stop Brake Pedal Lights Rear Right Brake/Stop Brake System Light Rear Middle Other Brake/Stop Traffic The Driver Light Rear Left Participant From the actor/user's (driver, other From a vehicle's point of view the traffic participants) perspective the Brake System simply is a box without brake system consists of a brake pedal any input/output arrows. So what is the (sensor) and the stop lights relation with other vehicle functions? (actuators). An assumption is that the For example, the vehicle function brake actuators are part of the system Cruise Control also senses the brake called 'Brake System' but are not pedal in order to temporarily turn off its shown in the figure depicted above, due to the fact that these actuators are operation when the driver pedals the not directly visible to actors (driver and brake pedal. In this case the brake traffic participants). pedal becomes a global visibility in the vehicle's system. 2010-02-09 Chalmers University, Göteborg Slide 14

Example Braking System – The Hardware View 1 1 3 3 5 2 4 3 3 1 1 1 Brake Actuator 2 Pedal Module – Brake Pedal 5 Rear Body Controller Unit Wire Network, e.g. CANbus, FlexRay TM Wheel Speed Sensor Steering Angle Sensor 3 4 2010-02-09 Chalmers University, Göteborg Slide 15

Example – Vehicle Level Automatic Transmission Braking Cruise Control Deceleration • CC • ACC (distance, velocity) mandatory optional optional Hybrid Electric Vehicle Basic Anti Blocking Electronic Braking System Stability Electronic Stability ABS Program Program ESP ESP • Timing requirement: The response time of the [feature] brake shall be less than 500 ms. [The driver shall make the experience that the breaks are taking into effect immediately after she/he presses the brake pedal.] • The value of this requirement may change depending on other available features. 2010-02-09 Chalmers University, Göteborg Slide 16