The Timing Model TIMMO Methodology Guest Lecture at Chalmers University

Transcription

1 ITEA : Timing Model The Timing Model Methodology Guest Lecture at Chalmers University Stefan Kuntz, Continental Automotive GmbH Methodology Page 1 Welcome About Stefan Kuntz Studied Electrical Engineering (HW) und Computer Engineering (SW) Over 20 years experience in the software engineering domain in different positions and industries (mainly embedded distributed real-time systems) Worked in Italy and the United States Companies Corporations (Siemens AG, SGS Thomson) SMEs (FORCE Computers, MEDAG) Start-Up Today at Continental Automotive in the Innovation Center of the division Powertrain Engine Systems Modeling, Design and Implementation of Software intensive Systems (SiS) Active member of AUTOSAR Timing Subgroup work package 3 "Methodology" leader Research projects: mobilsoft,, Automotive Core Methodology Page 2 1

2 Warm-UP Some questions Why does one need methodology and methods respectively? Ever heard about processes and methods before? Who already did apply methods consciously? Do you know why methodology is important? What is architecture? Domain knowledge, notation, and methods. What are your expectations? Please, ask questions whenever you like! Methodology Page 3 Agenda Introduction to Overview of EAST ADL Events and Event Chains Example Questions and Discussion Methodology Page 4 2

3 Introduction to Funded Project Timing Model Funded by Information Technology for European Advancement ITEA Duration: April 2007 to September 2009 Partners AUDI AEV, Volkswagen carmeq, Volvo Technology BOSCH, Continental Automotive, DENSO Automotive, ZF Friedrichshafen ETAS, Mentor Graphics Sweden, Siemens Information Systems, SYMTA VISION, TTTech Chalmers University, C-Lab, University of Paderborn Methodology Page 5 Introduction to Objectives Solving the problem of describing the temporal/timing requirements and behavior of a distributed real-time embedded systems (DRES) 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 enable one to apply the language in different scenarios Alignment with Automotive Open System Architecture AUTOSAR Methodology Page 6 3

4 Introduction to Objectives of and AUTOSAR Timing Subgroup Timing Model 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, predictable development cycle. AUTOSAR WP II 1.2 Timing Subgroup (Release 4.0) 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 Methodology Page 7 Introduction to Timing and Abstraction s (EAST ADL) Feature EAST ADL OEM «Requirement» The doors shall be unlocked not later than 1 second after a valid [transponder] key has been recognized. Analysis EAST ADL «Requirement»... Design EAST ADL Implementation AUTOSAR? How are timing requirements broken down into timing properties; and how are timing properties transformed into timing constraints and requirements respectively? «Property»... Operational AUTOSAR EAST Electronics Architecture and Software Technology ADL Architecture Description Language Supplier «Property» The function (runnable) unlockdoor responds within 120 ms (nominal) to a request to unlock the doors. [Assumption: The function is executed on a X12 6MHz processor... ] Methodology Page 8 4

5 Introduction to Reflections on Timing Requirements and Properties Feature (EAST ADL) Analysis (EAST ADL) Design (EAST ADL) Implementation (AUTOSAR) OEM «Requirement» The doors shall be unlocked not later than 1 second after a valid [transponder] key has been recognized. «Requirement», «Property»...? How are timing constraints broken down into timing constraints/properties; and how are timing properties transformed into timing constraints/properties? «Property», «Requirement»... Operational (AUTOSAR) of abstraction Supplier «Property» The function (runnable) unlockdoor responds within 120 ms (nominal) to a request to unlock the doors. [Assumption: The function is executed on a X12 6MHz processor... ] Methodology Page 9 Overview of EAST ADL EAST ADL Abstraction s Functional View Feature This level describes the features visible to the user such as windscreen wipers, window lifter, cruise control. Analysis This level captures the behavior and algorithms of the vehicle functions and their inter-dependencies. Design This level represents the decomposition of the functionality analyzed in the Analysis View and its design. Implementation This level represents the logical software architecture, the technical architecture, and consists of the OS and middleware models. Operational of abstraction This level describes the mapping of the software components and the executable system including the binary code and [parameter] data. Software and Hardware View Methodology Page 10 5

6 Overview of EAST ADL EAST ADL Abstraction s and AUTOSAR Views Functional View Feature Feature Model Analysis Functional Analysis Architecture/Model Design Functional Design Architecture/Model Middleware Abstraction Hardware Design Architecture/Model Implementation Environment Models Implementation Architecture/Model AUTOSAR VFB, System, and ECU view ECU Resource Descriptions Operational Operational Architecture/Model AUTOSAR... of abstraction Artifacts Software and Hardware View Methodology Page 11 EAST ADL Abstraction s, Events, and Timing Feature Analysis Design Transformation from EAST ADL Design to AUTOSAR views [Timing]. Implementation Transformation from continuous time into discrete time domain. 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 Event Occurrences time Methodology Page 12 6

7 Event Models Periodic event model Sporadic event model Pattern event model Arbitrary event model Methodology Page 13 Periodic Event Model Methodology Page 14 7

8 Sporadic Event Model Methodology Page 15 Pattern Event Model Crankshaft 0 60 Camshaft Observable events: Start of crankshaft (position 0 ), Top-Dead-Center of cylinders/piston (TDC1, TDC2,...) Bottom-Dead-Center of cylinders (BDC1,BDC2,...), Start of segment and half-segment of cylinders, open inlet valve, close inlet valve, open outlet valve, close outlet valve, etc Methodology Page 16 8

9 Arbitrary Event Model Methodology Page 17 Event Chains Relating events Causality Stimulus EC Response Response/Stimulus ECS ECS ECS ECS ECS ECS EC Event Chain ECS Event Chain Segment Methodology Page 18 9

10 Example: Braking System (High System View) The Driver Brake Pedal Brake System Brake/Stop Lights Brake/Stop Light Rear Right 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 Methodology Page 19 Example: Braking System (The Hardware View) Brake Actuator 2 Pedal Module Brake Pedal Network, e.g. CANbus, FlexRay TM Wheel Speed Sensor 4 Steering Angle Sensor Methodology Page 20 10

11 Feature Basic Braking mandatory Braking Deceleration optional Anti Blocking System ABS optional Electronic Stability Program ESP Windscreen Wiper Rain-Light-Sensor 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 ms. [The driver shall make the experience that the breaks are taking into effect immediately after she/he presses the brake pedal.] This requirements may change depending on other available features Methodology Page 21 Analysis Vehicle State Diagnosis Vehicle Functionality Braking «FD» Brake Pedal 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 Methodology Page 22 11

12 Design Vehicle Function Braking Brake Pedal Position Monitor Brake Force Actuation Brake Controller Brake Force Actuation Methodology Page 23 Implementation AUTOSAR Virtual Function Bus Sensor #1 #2 #3 #4 FL Actuator Wheel FL Virtual Function Bus ECU Abstraction Component (Sensor) AUTOSAR Service ECU Abstraction Component (Actuator) Software Component Observable Events Methodology Page 24 12

13 Implementation AUTOSAR Virtual Function Bus Sensor #1 #2 #3 #4 Actuator Wheel ECU Abstraction Component (Sensor) Virtual Function Bus AUTOSAR Service These components are mapped four times to specific ECUs. (ECU Wheel FL,... FR,... RL,... RR) ECU Abstraction Component (Actuator) Software Component Observable Events Methodology Page 25 Implementation AUTOSAR System View ECU #1 ECU #2 ECU #3 ECU Wheel FL Sensor #1 #2 #3 #4 Actuator RTE RTE RTE RTE Basic SW Basic SW Basic SW Basic SW Bus #1 Bus #2 Sensor Actuator Signal Path RTE Run Time Environment ECU Electronic Control Unit Observable Software Component Events Methodology Page 26 13

14 Implementation AUTOSAR ECU View ECU #1 Sensor Basic SW RTE Sensor I/O HW Abstraction I/O Drivers Peripheral RTE 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 Methodology Page 27 Questions and Discussion Thank you very much for your attention! Methodology Page 28 14