The AUTOSAR Timing Model --- Status and Challenges. Dr. Kai Richter Symtavision GmbH, Germany

Transcription

1 The AUTAR Timing Model --- Status and Challenges Dr. Kai Richter Symtavision GmbH, Germany

2 Symtavision GmbH Who we are! Spin-off from Technical University of Braunschweig, Germany, founded May 2005 Timing and scheduling analysis tool suite SymTA/S 30+ MY research and development of technology Expertise in system integration Primary market: Automotive 2

3 Symtavision Expertise: Real-Time Systems Analysis Real-time correctness Reliability / Dependability Optimization Cost component selection dimensioning scheduling Interrupt controller Enhanced JTAG Clocks IC debug CPU debug Universal serial bus Universal async. receiver/transmitter (UART) ISO UART Reset D$ I$ MIPS (PR3940) CPU MIPS bridge MIPS PI bus Fast PI bus Fast C-Bridge MIPS C-Bridge High-performance 2D-rendering engine Exp. bus interface MPEG-2 video decoder Adv. image composition Processor Phillips Nexperia TM Video input unit PCI/XIO Platform processor I²C IEEE 1394 link layer controller CRC DMA External SDRAM Memory controller Mem. Mgmt. IF bus C-bridge TriMedia C-Bridge Memory-based scaler MPEG system proc. TriMedia (TM32) CPU TriMedia bus PI D$ I$ Interrupt ctrl. Audio I/O Sony Philips Digital I/O Transport stream DMA General-purpose I/O Synchronous serial interface Flexibility Quality 3

4 Solution: Flexible, Modular SymTA/S Tool Suite Screenshots by 4

5 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 5

6 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 6

7 Key AUTAR Concepts portable software components virtual function bus (VFB) ports and connectors several communication semantics (send/recv, client/server) crossing module boundaries (function distribution) crossing company boundaries (supply chain, black box) configurable/customizable run-time environment Needs standardized APIs to facilitate implementation! 7

8 Key AUTAR "Methodology and " Flexible mapping of software components enabled by standardized run-time environment () 8

9 Mapping in More Detail: SW Component Structure and Execution Platform Vehicle Function Sensor Sensor SWC SWC1 Actuator SWC Actuator Sensor SWC SWC-1 Actuator SWC BSW BSW Sensor Signal Path / Data Flow Actuator Standardized eases compiling & linking together several SW components from different teams/vendors/... 9

10 Typical AUTAR Use Cases Function distribution & partitioning one function - several SW components one several ECUs one ECU - several SW-Cs from different functions / vendors Adding new functions product variants, face lifts, platforms Optimizations Configuration (CAN IDs, signal-to-frame assignment, etc.) Re-mapping of SW components Network modifications (topology, protocols, gatewaying) New business models Software as a product Improved supply-chain "contracting" (liabilities) 10

11 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 11

12 Introduction of Timing Effects: Framework Function development imposes timing constraints High-level specification based on SW components AUTAR goal: break down the software structure into "manageable" blocks timing chains and timing chain segments connected at hand-over points (HOPs) consider each segment / HOP individually Goals: divide and conquer "timing analysis" top-down assignment of responsibilities locally verifiable, then result composition bottom-up 12

13 Timing Chains and Hand-Over Points (HOPs) Sensor SWC SWC-1 Actuator SWC BSW BSW Sensor Signal Path / Data Flow Actuator INTER-ECU INTRA-ECU Sensor Sensor SWC communication SWC1 communication Actuator SWC Actuator Sens I/O BSW Sensor SWC BSW CAN BSW SWC1 Actuator SWC BSW I/O Act HOPs timing chain segments end-to-end timing chain 13

14 Introduction of Local Timing Effects Reasoning about timing requires considering two views: static software components vs. dynamic execution platform behavior operating systems and scheduling; SW components vs. runnables and tasks communication semantics; SW-C structure vs. timing dependencies middleware / driver structure; standardized protocols vs. non-standardized implementation & BSW 14

15 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 15

16 SW-Components vs. "Runnables" and Tasks SW architecture: 2 SW components, 6 runnables SW-C 1 runnablea runnableb runnablec ECU 1 runnabley runnablex runnablez SW-C2 BSW Implementation: 3 Tasks runnablearunnabley runnablexrunnablecrunnableb runnablez Schedule and timing dependencies SW-C 1 runnablea runnableb runnablec Task 4 runnabley runnablex runnablez SW-C 2 16

17 Challenge: Associating Schedules with Timing Chain Segments software component w/ 3 runnables SW-C 1 runnablea runnableb runnablec sequential model BSW SW-C 1 BSW actual implementation timing chain segment Task 4 B Task 4 B meaning? what about runnable B start of runnable A end of runnable C 17

18 Software Component Structure vs. Timing Dependencies Software component view captures "logical" dependencies (data flow) SWC 1 SWC 2 SWC 3 Implementation timing dependencies can be very different!!! time-driven and event-driven activation send/recv and client/server communication (remote procedure call) over- / undersampling event-driven task time-driven task TT SWC 1 TT SWC 2 SWC 3 N7 BSW M2 N7 BSW M2 TT cyclic CAN frames N7 BSW M2 CAN immediate CAN frames (event-driven) remote procedure call 18

19 Software Component Structure vs. Timing Dependencies Software component view captures "logical" dependencies (data flow) SWC 1 SWC 2 SWC 3 Timing dependencies can be very different!!! time-driven and event-driven activation send/recv and client/server communication (remote procedure call) over- / undersampling internal state client server oversampling sender/receiver undersampling SWC 1 SWC 2 SWC 3 19

20 Sender-Receiver vs. Client-Server I INTRA-ECU communication: both SW-Cs on one ECU merely an issue of software structure global register vs. local variable (with get Method) INTER-ECU communication: SW-Cs on different ECUs has large influence on bus / ECU timing periodic sender cyclic frame asynchronous (event driven) server task cyclic req. frame periodic client asynchronous data frame sender-receiver client-server Screenshots by 20

21 Sender-Receiver vs. Client-Server II sender-receiver w/ cyclic tasks and frames bus message timing ECU 2 timing client-server solution w/ asynchronous servers and frames Screenshots by 21

22 Protocols vs. Non-Standardized BSW BSW CAN BSW COM timing chain segment SIG SEND/ RECV INT MO signal register COM layer tasks or interrupts driver interrupt message object (HW buffer) SWC 2 SWC 1 SWC 3 SWC 3 Frame generation timing (cyclic and/or event+driven) SIG SIG SIG SIG SIG SEND CAN BSW RECV Buffering strategy (FIFO, priority ordered, hybrid) Queue INT INT MO MO MO CAN HW MO Use of message objects (hardware buffers) 22

23 Priority Queue vs. FIFO in CAN Networks buffering strategy (inside ECU) has huge influence on network timing Shared FIFO Buffer Shared priority-ordered buffer undermines the CAN protocol's priority scheme high priority 3 messages share a FIFO low blocking due to non-preemptiveness low-priority frames benefit from FIFO high-priority frames must wait for low-priority frames Screenshots by 23

24 Challenge: Associating Schedules with Timing Chain Segments SIG SIG SIG SEND INT MO complex mutual dependencies complex mutual dependencies MO INT RECV SIG SIG???? CAN BSW BSW 24

25 Summary: Local Timing Effects Complex timing is not directly reflected in the software architecture is induced by the execution platform! runnables and tasks Task 4 timing dependencies and communication semantics internal state client server oversamplingsender/receiver undersampling SWC 1 SWC 2 SWC 3 non-standardized drivers and SIG SIG SIG middleware (BSW) SEND Queue CAN BSW INT MO MO MO CAN HW etc... 25

26 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 26

27 Bottom-up: Timing effects during integration Key Message: Local Changes can have Global Effects!!! network timing network config COM/BSW concepts end-to-end timing driver interrupts RT config task scheduling 27

28 Example: Task Timing Changed, e.g. Function Added new constraints still valid? Screenshots by 28

29 Example: New Frame on Network indirect dependencies schedule distotrion buffer overflow direct dependencies new Screenshots by 29

30 Example: COM Layer Queuing Changed (FIFO -> priority) indirect dependencies direct dependencies end-to-end timing still valid? Screenshots by 30

31 Use Case: System Integration (white box) two individual subsystems integrated using shared bus network timing network config COM/BSW concepts end-to-end timing RT config driver interrupts task scheduling Question: How can this be analyzed & controlled? Screenshots by 31

32 Use Case: System Integration (black box) Even worse: Only partial information available How to analyze this at all? Screenshots by 32

33 Timing Analysis in Practice Today Local analysis of individual components good systematic approaches available but mostly simplified "environment models" later integration problems network timing network config Testing of (sub-) systems after integration whole environment available but: unknown critical interactions prohibits corner case coverage decreasing reliability COM/BSW concepts end-to-end timing RT config driver interrupts task scheduling 33

34 Established V-Model Design Process Design Test Analysis coverage? Requirements Test System Design OEM composition? System Test Supplier Module Design Module Test / Analysis Implementation Function Test 34

35 Summary: Bottom-Up System Integration Many local decisions have global effect, and are mutually dependent COM/BSW concepts network timing end-to-end timing RT config driver interrupts task scheduling network config Technical Issue: System-level modeling of complex timing interaction Business Issue: Contracting & data availability along complex supply chains Current practice needs improvements? Key challenge for the AUTAR Timing Model! 35

36 Overview AUTAR in general & target use cases Top-down: SW architecture vs. execution platform A closer look to key technical details Bottom-up: Integration & timing analysis practice Implications w.r.t AUTAR goals Conclusion 36

37 Review: AUTAR Goals AUTAR shall be a vehicle for: Integration of SW-Cs from different SW suppliers Integration of ECUs from different tier-1 suppliers Platform design re-use, extensibility, platform variants portability and configurability at all levels Approach: Standardized software architecture Modular and flexible function integration 37

38 Challenge: Timing Dependencies SW architecture does not reflect timing dependencies Sensor SWC SWC-1 Actuator SWC runnablea runnableb runnablec SW-C 1 BSW BSW vs. runnabley runnablex runnablez SW-C 2 SIG SIG SEND SIG CAN BSW Sensor Signal Path / Data Flow Actuator Task 4 Queue INT MO MO MO CAN HW Timing is mapping dependent (execution platform) not as compositional/modular as the software architecure complex a fundamental technical issue Timing currently not thoroughly addressed by AUTAR counters platform independent software & portability 38

39 What is needed? Controlling timing dependencies requires reasonable specification models that are supported by analysis (tools) "There is no point in modeling something that cannot be analyzed!!!" (during some timing team meeting) Appropriate timing model technology Appropriate design "culture" business processes 39

40 How Could a Successful Timing Model Look Like? captures the complex dynamic timing dependencies, and the environment considers the used mechanisms (, protocols, BSW,...) enables de- / composition & local timing analysis allows black-box integration and IP protection applicable at different levels of detail global dependencies and common mechanisms decomposition local analysis Task 4 reasonable interfaces IP protection black box / IP prot. 40

41 Software Suppliers can do: Timing Characterization runnablez runnablea runnableb SW-C 1 runnablea runnabley runnablec runnabley CPU, periherals, runnablex runnablecrunnableb runnablez runnablex SW-C 2 coprocessors, memory archit. execution time runnablez runnablea runnabley runnablex runnablec runnableb + information about communication + information about activation events, interrupts, timers... (volume & access type) 41

42 ECU Suppliers can do: Timing Analysis on ECUs, scheduling, drivers, BSW, interrupts, timers runnablez A runnablex runnableb runnablec black boxes B N C black boxes runnablea runnabley interface captures dynamic I/O behavior (jitter, min/max delays) A Screenshots by 42

43 OEM can do: Control Timing on Bus/Network network config, protocols, gateways, etc. black box constraint not met ECUs black box ECUs interface captures dynamic component interactions Screenshots by 43

44 Design Process Tomorrow? Design Test & Analysis Analysis Performance Estimation Architecture Optimization Integration Verification Requirements Test System DesignFlexibility OEM Analysis Supplier Module Design Refinement Implementation Requirement Verification Integration Bottleneck DetectionModule Test Function Test System Test 44

45 Cultural Issues Many approaches to timing modeling exist None has been chosen yet for AUTAR Why??? Timing challenges require re-thinking of roles!!! 45

46 Suppliers Role Traditional role of Suppliers function implementation execution platform development.. New to suppliers responsible for ECU-network interactions very detailed requirements / constraints traceable verification, clear responsibility / liability disclosure of information relevant for timing more competition due to comparability 46

47 OEMs Role Traditional role of OEMs in E/E design function design (Matlab, etc..) prototyping taking suppliers liable for correct functioning New to OEMs network timing effects out of supplier responsibility timing is a technical problem requiring a technical solution (no management solution) consideration of SW architecture and execution platforms dealing with systematic timing and QoS contracts OEM needs to reason about integration much earlier Quality can not be added at the end of "cooking" (like salt)! 47

48 Supplier-OEM Communication Scenario Function Design & OEM Matlab/Simulink Simulation Prototype & OEM RP tool chain Prototype +? Critical Supply Chain Communication ECU Supplier Integration & OEM 48

49 New OEM Responsibilities and Possibilities Facing timing as a technical challenge, OEMs can understanding network timing more systematic dimensioning, configuration, optimization focusing on the interaction of ECUs with the network more systematic timing constraints for suppliers (timing chains and HOPs) increasing integration reliability / reduced risk better understanding of COM-layer effects systematic implementation constraints for suppliers (OEMs defines a "standard BSW core") guaranteed compliance of supplied ECUs with OEMs network 49

50 Research Bodies Role Traditionally develop solution approaches for technical problems are used to industry requesting their help develop foundations for EDA tools AUTAR: an entire community with an obvious problem long time not asking for direct assistance Why is that? 50

51 MO SIG MO SIG INT SIG MO Industry-Research Mismatch??? Automotive Industry Sensor SWC BSW Sensor Actuator SWC-1SWC Signal Path BSW / Data Flow Actuator Task 4 runnablea runnableb runnablec runnabley runnablex runnablez SW-C 1 Queue SW-C 2 SEND CAN BSW CAN HW complex systems, manifold dependencies revolutionary problems 51

52 MO SIG MO SIG INT SIG MO Industry-Research Mismatch??? Automotive Industry Research Community Sensor SWC BSW Sensor Actuator SWC-1SWC Signal Path BSW / Data Flow Actuator Task 4 runnablea runnableb runnablec runnabley runnablex runnablez SW-C 1 Queue SW-C 2 SEND CAN BSW CAN HW complex systems, manifold dependencies clear semantics, well-defined interactions revolutionary problems revolutionary solutions 52

53 Conclusion Timing is "quite new" to automotive industry (esp. OEMs) SW architecture view not sufficient to capture timing Must take into account the execution platform systematically, is complex Needs formal models -> EDA Tools -> confident users Allows engineers to reason about alternatives Need to come: SW engineering view enhancements better (more systematic) platform mechanisms / basic software more flexible design rules revised way of thinking (especially for OEMs) 53