The TIMMO Methodology

Transcription

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

2 Objectives TIMMO Solving the problem of describing the timing requirements imposed on and temporal behavior of a distributed real-time embedded softwareintensive 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 Automotive Open System Architecture AUTOSAR Chalmers University, Göteborg Slide 3

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

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

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

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

7 Modeling Methodology SPEM and Eclipse Process Framework (EPF) Composer Software Process Engineering Meta-Model Role Performer Method content elements: Task, work product, and role Process elements: Phase, activity, task, milestone Artifact Task Artifact Input Work Product Output 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) Chalmers University, Göteborg Slide 8

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

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 Chalmers University, Göteborg Slide 10

10 Events and Event Chains Event Chains Relating events Causality Stimulus EC Response Response/Stimulus ECS ECS ECS ECS Strands ECS ECS EC Event Chain ECS Event Chain Segment Segment Segment Chalmers University, Göteborg Slide 11

11 Events and Event Chains Constraints and Description «Event Constraint» Periodic, Sporadic,... «Delay Constraint» Age/Reaction «Synchronization C.» Input/Output «Event Constraint» Periodic, Sporadic,... Stimulus Observable Event «Event Chain» «Timing Description» Response Observable 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 Chalmers University, Göteborg Slide 12

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

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

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

15 Example Vehicle Level Automatic Transmission Basic Braking mandatory Braking Deceleration optional Anti Blocking System ABS optional Electronic Stability Program ESP Cruise Control CC ACC (distance, velocity) Hybrid Electric Vehicle Electronic Stability Program ESP Timing requirement: The response time of the [feature] brake shall be less than 500. [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 Chalmers University, Göteborg Slide 16

16 Example Vehicle Level One proposal... not yet approved «Delay Constraint» Reaction, Age Stimulus Response «EM» Brake Pedal «Feature» Braking «EM» Vehicle The environment model of the Brake Pedal describes how the brake pedal is pressed and which physical means are used to carry the information how strong the brakes should be applied. The environment model of the Vehicle describes how the vehicle is slowed-down when the brake pedal is pressed. On this level of abstraction the stimulus occurs sporadic... no one is braking periodically! Chalmers University, Göteborg Slide 17

17 Example Analysis Level Vehicle State Diagnosis Vehicle Functionality Braking «FD» Brake Pedal «ADLFunction» Brake Controller «FD» Brake Actuation Exterior Light «FD» Stop Light Actuation Four Wheels (Passenger Car) «FD» Functional Device The component which interacts with the environment Chalmers University, Göteborg Slide 20

18 Example Analysis Level Vehicle State «Delay Constraint» Reaction, Age Diagnosis «Synchronization C.» Output Vehicle Functionality Braking Stimulus Response 1..4 «FD» Brake Pedal «ADLFunction» Brake Controller «FD» Brake Actuation «Delay Constraint» Reaction, Age Exterior Light «FD» Stop Light Actuation Response Four Wheels (Passenger Car) «FD» Functional Device The component which interacts with the environment Chalmers University, Göteborg Slide 21

19 Example Design Level First Approximation based on Analysis Level Vehicle State Diagnosis Vehicle Functionality Braking «LDM» Brake Pedal «ADLFunction» Brake Controller «LDM» Brake Actuation Exterior Light «LDM» Stop Light Actuation Four Wheels (Passenger Car) «LDM» Local Device Manager The component which interacts with abstract function dealing with sensors and actuators Chalmers University, Göteborg Slide 22

20 Example Design Level Time Budgets given from Analysis Level Vehicle State «Delay Constraint» Reaction, Age Diagnosis «Delay Constraint» Reaction, Age «Delay Constraint» Reaction, Age Stimulus Vehicle Functionality Braking Response Stimulus Response Stimulus Response «LDM» Brake Pedal «ADLFunction» Brake Controller «LDM» Brake Actuation «Delay Constraint» Reaction, Age Exterior Light «LDM» Stop Light Actuation Response Four Wheels (Passenger Car) «LDM» Local Device Manager The component which interacts with abstract function dealing with sensors and actuators Chalmers University, Göteborg Slide 23

21 Example Design Level Possible Design of the Brake Controller Stimulus «Delay Constraint» Reaction, Age «ADLFunction» Brake Controller Response Check Signal Plausibility Brake Force Arbiter Brake Actuator Monitor Brake Force Calculation Diagnosis Arbiter Vehicle State Monitor Brake Safety Monitor Elementary ADL Function Chalmers University, Göteborg Slide 24

22 Example Implementation Level AUTOSAR Virtual Function Bus View Sensor SW-C SW-C #1 Brake Coordinator SW-C #2 Brake Controller SW-C #3 Brake Force Arbiter SW-C #4 FL Actuator SW-C Wheel FL Virtual Function Bus ECU Abstraction Component (Sensor) AUTOSAR Service «Latency Timing C.» Reaction ECU Abstraction Component (Actuator) SW-C Software Component Observable Events Chalmers University, Göteborg Slide 25

23 Example Implementation Level AUTOSAR Component View... First alternative RE Check Signal Plausibility SW-C Brake Controller 1 «Execution Order C.» Stimulus RE Activated RE Brake Actuator Monitor 2 RE Diagnosis Arbiter RE Vehicle State Monitor 6 RE Brake Safety Monitor «Latency Timing C.» Reaction RE Brake Force Calculation RE AUTOSAR Runnable Entity Response RE Terminated Chalmers University, Göteborg Slide 26

24 Between Views VFB View and Software Component View «Latency Timing C.» Reaction RE Check Signal Plausibility SW-C #2 Brake Controller Stimulus Data Received Response RE Activated 1) RE Brake Actuator Monitor RE Diagnosis Arbiter VFB Response Data Sent Stimulus RE Terminated 1) RE Vehicle State Monitor RE Brake Safety Monitor AUTOSAR Service «Latency Timing C.» Reaction RE Brake Force Calculation 1) Not shown in VFB view SW-C Software Component RE AUTOSAR Runnable Entity Chalmers University, Göteborg Slide 28

25 Example Implementation Level AUTOSAR System View ECU #1 ECU #2 ECU #3 ECU Wheel FL Sensor SW-C SW-C SW-C SW-C #1 SW-C #2 SW-C #3 SW-C #4 Actuator SW-C RTE RTE RTE RTE Basic SW First Transmission Basic SW Bus #1 Basic SW Third Transmission Basic SW Bus #2 Second Transmission Sensor «Latency Timing C.» Reaction Actuator Observable Events SW-C Software Component ECU Electronic Control Unit RTE Run Time Environment Chalmers University, Göteborg Slide 29

26 Example Implementation Level AUTOSAR ECU View ECU #1 Sensor SWC SWC Basic SW RTE «Latency Timing C.» Reaction/Age Sensor SWC I/O HW Abstraction I/O Drivers Peripheral RTE SWC Communication Services Communication Hardware Abstraction Communication Drivers Communication Controller ECU View: Basic Software Module Entry Called, Basic Software Module Entry Returned Internal Behavior: Runnable Entity Activated, Runnable Entity Started, Runnable Entity Terminated, Basic Software Module Entity Activated, Basic Software Module Entity Started, Basic Software Module Entity Terminated Communication: Signal Sent To COM, Signal Available For RTE, IPDU Sent To Interface, IPDU Received by COM, Frame Queued for Transmission, Frame Transmitted on Bus, Frame Received by Interface Observable Events Chalmers University, Göteborg Slide 30

27 Questions and Discussion Thank you very much for your attention! Chalmers University, Göteborg Slide 31