Applying Static WCET Analysis to Automotive Communication Software

1. Applying Static WCET Analysis to Automotive Communication Software Susanna Byhlin, Andreas Ermedahl,Jan Gustafsson, Björn Lisper, Mälardalen Real-Time Research Center (MRTC) Västerås, Sweden

2. Embedded & Automotive • A modern car cancontain a variety of embedded control units (ECU) • Large diversity in processor types: • 8-bit CPUs (PIC, HC08) - door locks, lights, etc. • 16-bit CPUs (C167, HC11, HC12) - most functions • 32-bit CPUs (PPC, V850) - engine control, airbags • Large amount of code: 40-50 MB

3. Networks and ECUs • The ECUs are often connected by one or more communication networks • Often several network types in the same vehicle • CAN, LIN, Most, FlexRay, ... • Resulting systems are often hard real-time • Methods to support timing verification needed! • To provide overall system timing guarantees we need: • Timing bounds on the network communication • Timing bounds of the tasks running on the different ECUs This work has looked into the latter!

4. Are you sure to find the worst case execution? Definition of WCET actual BCET actual WCET probability possible execution times safe BCET estimates safe WCET estimates time 0 • Timing bound: • Worst Case Execution Time - WCET • Other measures: • Best case execution time – BCET • Average case execution time – ACET • Assumption: One task run in isolation • Task interference, interrupts, etc. are a scheduling / analysis issue

5. Static WCET Analysis • Do not run the program – analyze it! • Relying on models of the program and the hardware upon which it runs • Theoretically safe WCET • If the models and all inputs are correct actual BCET actual WCET probability safe BCET estimates safe WCET estimates time Measurements give values in this region Static analyses give values in this region

6. embedded system development Status WCET analysis • Static WCET analysis is today mature enough to be used in real industrial settings • Avionics software • Real-time operating system code • Space applications • Timing analysis research has developed into companies • AbsInt (static analysis) • Tidorum (static analysis) • Rapita Systems (measurements) • WCET tools have a potential to be a standard part of the embedded system developer’s tool chest! debugger profiler compiler simulator WCET analysis emulator

7. WCET analysis on automotive communication code • Work performed by one MSc student (Susanna Byhlin) • Supervised by Ermedahl, Lisper, Kallerdahl • Took about 5 months • Performed at the Volcano Communication Technologies (VCT) company • Using state-of-the art WCET analysis tool (aiT) • Analysing code for controlling LIN traffic • Code running on MC9S12DP256 ECUs WCET? ECU frame ECU LIN network ECU ECU

8. Questions asked • Can today’s WCET analysis tools be used in automotive software development? • The actual WCET values are not so interesting • How labour intensive is the analysis? • How much code understanding is required? • How many manual annotations are required? • Characteristics of obtained WCET values? • One WCET per task or many? • Other valuable insights? • Input for WCET tool providers

9. The LIN network • Several nodes forms a LIN clusters • One master-slave node, several slaves nodes • Master controls communication over the network • Master sends out header, slave gets activated and sends response part • Communication follows predefined schedule • Messages (frames) consists of id, data(s), and a checksum • Data fields consists of signals or byte arrays • Several frame types • Unconditional, event-triggered, sporadic, diagnostic • Links to CAN

10. Target ECU The VCT LIN tool suite • Tool suite for designing and implementing in-vehicle LIN network communication • LNA = LIN Network Architect • Captures network design requirements • Packs signals into frames, assignsid:s and generate scheduling table • Result in LDF file • LTP = LIN Target Package • Includes configuration tool & pre-compiled object libraries • Generates target dependent code • Other tools for testing, verifying and emulating communication Network Requirements Database LNA - LIN Network Architect LIN Descrip-tion File (LDF) Hardware node details LTP - LIN Target Package Compiler/Linker/Loader ECU Appli-cation code Volcano Libraries Executablecode

11. The target hardware • Execution time depends (of course) on the target hardware • VCT supports many target platforms • The selected MC9S12DP256 board features a 16-bit Star12 CPU core • MC68HC12 family • Three stage pipeline • Many addressing modes • No cache • Different memory areas • Flash, EEPROM, SRAM • Different access times

12. The aiT WCET analysis tool • A commercial WCET analysistool from AbsInt GmbH • Supports manytarget platforms • Examples: • HCS12/Star12,ARM7, ColdFire5307, PowerPC555/565/755, Infineon C166/167

13. The aiT WCET Tool • Analyzes the binary executable • Analysis steps performed: • Reconstruction of CFG from the binary executable • Value analysis • Loop-bound analysis • Pipeline (& Cache) analysis • Calculation using IPET • Many analyses based onabstract interpetation

14. The aiT WCET Analysis Tool • Includes a graphical interface to visualize the obtained results and the program Call-graph and WCET Basic block opened CFG opened

15. aiT & Manual Annotations • aiT supports many user anno-tations to provide extra infor-mation to the WCET analysis • Clock frequency • Start and stop address of task to analyze • Targets of function calls and branches • Iteration bounds for loops • Known register values • Memory mapping • Branch condition outcome • Code to be excluded from the analysis • Accessed memory address

16. The LIN API • The interface between the LIN network and the application program • Nine different LIN API function selected • Implemented as C functions (one function might call other functions) Rather small codes Few annotations needed WCETs obtained!

17. General observations • WCETs for all LIN API functions obtained! • However, often not a constant value, but dependent on some system parameters • Number of frames within the network • The type of the frames • The size of the frames • Number of flags latched to signals withinthe frames • Hard to directly see how these system parameters affected the WCET • Much code inspection / understanding required

18. Example: l_star12sci_sch_tick() • The function that drives the communication within the LIN network • Called on a periodical time basis • Follows the predefined transmission schedule • Consists of eight different loops • Most dependent on some system parameters • Each required a loop bound annotation

19. l_star12sci_sch_tick() cont. • A WCET valid under all possible system configurations overly pessimistic for most situations • Each function therefore analyzed under some special conditions / CASEs • Seven cases found for l_star12sci_sch_tick() • For each case a WCET was found • Most cases required some extra manual annotations

20. Example: WCET CASE1 • How do the max frame size and max number of latched flags affect WCET for the l_star12_sci_sch_tick() function? • Parametrical WCET formula obtained (by hand): WCETCASE1: 5343 + #Flags * 23 + Framesize * 162 • #Flags and Framesize available in the LDF file WCET / flag (CASE1) WCET / frame size (CASE1)

21. Example: CASE2 & CASE3 • CASE2: No event-triggered or sporadic frames transmitted • Three extra code removal annotations required • Parametrical WCET formula obtained (manually): WCETCASE2: 2005 + #Flags * 23 + Framesize * 162 • CASE3: No event-triggered or sporadic frames transmitted, no sleep request, and no errors • Seven extra code removal annotations required • Parametrical WCET formula obtained (manually): WCETCASE3: 994 + Framesize * 85

22. CG before: WCET: 11174 cycles CG after: WCET: 325cycles Example: CASE10 • The l_star12sci_s_rx() function • Executed when slave receives one char of data over the network • WCET from receiving frame ID until sending first response byte • Required five additional annotations • Large reduction in code size and WCET

23. Conclusions • Possible to obtain WCET for all analyzed LIN API functions • Static WCET analysis applicable on this type of automotive communication software • Detailed system and code knowledge often required • WCET tool should preferebly be used during system design/implemention • Hard to derive afterwards by MSc worker • Usefulness would improve with higher level of automation and support • E.g., improved loop bound analysis

24. More conclusions • Absolute WCET bounds overly pessimistic for many situations • Better support for mode- or input sensitive WCET analysis needed • Obtained WCET bounds often parametrically dependent on some system parameters • Hard to directly see how these system parameters affected the WCET • Better support for parameterical WCET analysis needed

25. VCT & WCET Analysis • VCT supports many target platforms • To incorporate WCET analysis in their development environment it must be available for a large variety of platforms • Portability of WCET analysis important • Informative and user-friendly tool • Good graphical tool interface important • Bounds on task jitter often wanted • Better support for BCET analysis needed

26. TheEnd!