Successfully reported this slideshow.

Design flow for Controller Area Network systems

2,433 views

Published on

Model-based design in Controller Area Network systems

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Design flow for Controller Area Network systems

  1. 1. A model based design flow for CANbased systems Alexios Lekidis1, Marius Bozga1, Didier Mauuary2, Saddek Bensalem1 1UJF-Grenoble 1 / CNRS-VERIMAG, 2Cyberio 14th international CAN Conference Eurosites Republique, Paris (France) November 12-13,2013 Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 1/35
  2. 2. Outline 1) Design challenges for CAN-based systems 2) Model-based design flow using BIP • • • • BIP overview CAN protocol model Application software modeling Construction of the system model 3) Application and experimental results 4) Conclusion and ongoing work Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 2/35
  3. 3. Outline 1) Design challenges for CAN-based systems 2) Model-based design flow using BIP • • • • BIP overview CAN protocol model Application software modeling Construction of the system model 3) Application and experimental results 4) Conclusion and ongoing work Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 2/35
  4. 4. CAN system example: automotive application Engine Control Transmission Control Traction Control Gearbox Control Seat Control Suspension Control Environment Control Dashboard Airbag Control Antilock Breaks Each unit in the network may incorporate many subsystems Lekidis, Bozga, Mauuary, Bensalem Lights Control • Increased communication complexity • System design becomes difficult A model-based design flow for CAN-based systems 3/35
  5. 5. Emergence of higher layer protocols • Organize and abstract low-level communication complexity • Extend its usage to a wide range of applications including: • Machine automation, medical devices, photovoltaic systems, maritime electronics e.t.c. CANopen DeviceNet J1939 CAN Controller CAN Bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 4/35
  6. 6. Emergence of higher layer protocols • Organize and abstract low-level communication complexity • Extend its usage to a wide range of applications including: • Machine automation, medical devices, photovoltaic systems, maritime electronics e.t.c. CANopen DeviceNet J1939 System integration and validation is too difficult CAN Controller CAN Bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 4/35
  7. 7. Emergence of higher layer protocols • Organize and abstract low-level communication complexity • Extend its usage to a wide range of applications including: • Machine automation, medical devices, photovoltaic systems, maritime electronics e.t.c. CANopen DeviceNet CAN Controller CAN Bus Lekidis, Bozga, Mauuary, Bensalem J1939 System integration and validation is too difficult Successful design remains a challenge A model-based design flow for CAN-based systems 4/35
  8. 8. Conformance testing  Verifies the correct implementation and integration of the system  Essential step towards interoperability and portability Occurs late in the development cycle Requires the final system implementation  Potential design errors can lead to a new implementation of the system  Performance aspects are ignored during the design process Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 5/35
  9. 9. Solution: Model-based design Formal approach expressing the behavior and functionality of embedded systems • Validation and verification enabled at any stage • Formal models for the software and hardware allowing: • Separation of concerns • Modularity • Reusability Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 6/35
  10. 10. Solution: Model-based design Formal approach expressing the behavior and functionality of embedded systems • Validation and verification enabled at any stage • Formal models for the software and hardware allowing: • Separation of concerns • Modularity • Reusability  Previous work is based on multilanguage frameworks, in order to provide a design flow for automotive systems Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 6/35
  11. 11. Solution: Model-based design Formal approach expressing the behavior and functionality of embedded systems • Validation and verification enabled at any stage • Formal models for the software and hardware allowing: • Separation of concerns • Modularity • Reusability  Previous work is based on multilanguage frameworks, in order to provide a design flow for automotive systems Semantically unrelated formalisms lead to lack of continuity Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 6/35
  12. 12. Solution: Model-based design Formal approach expressing the behavior and functionality of embedded systems • Validation and verification enabled at any stage • Formal models for the software and hardware allowing: • Separation of concerns • Modularity • Reusability  Previous work is based on multilanguage frameworks, in order to provide a design flow for automotive systems Semantically unrelated formalisms lead to lack of continuity Lekidis, Bozga, Mauuary, Bensalem Rigorous design flow for CAN-based systems: • Based on a single semantic framework • Encapsulates the protocol’s communication mechanisms and primitives • Incremental design using composite components A model-based design flow for CAN-based systems 6/35
  13. 13. Design flow Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 7/35
  14. 14. Design flow Component reuse Tools Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 7/35
  15. 15. Design flow Component reuse Tools Verification of safety properties Lekidis, Bozga, Mauuary, Bensalem Platform dependent skeleton C/C++ code A model-based design flow for CAN-based systems 7/35
  16. 16. Outline 1) Design challenges for CAN-based systems 2) Model-based design flow using BIP • • • • BIP overview CAN protocol model Application software modeling Construction of the system model 3) Application and experimental results 4) Conclusion and ongoing work Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 8/35
  17. 17. BIP component framework • BIP (Behavior-Interaction-Priority) is a formal language for the hierarchical construction of composite components Composition glue Priorities (conflict resolution) Interactions (collaboration) B • E H A V I O R Atomic components Provides a rich set of tools for analysis and performance evaluation Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 9/35
  18. 18. BIP: Atomic components  Finite state automata (Petri nets) extended with data and functions described in C/C++ TICK s:=0 t:=0 SEND s [s<100] S_COM RECV r SEND s:=s+1 TICK t:=t+1 TICK S_COM Lekidis, Bozga, Mauuary, Bensalem r:=0 t:=0 R_COM RECV print(r) TICK TICK t:=t+1 R_COM A model-based design flow for CAN-based systems 10/35
  19. 19. BIP: Interactions  Communication between components involving data exchange s:=0 t:=0 SEND s [s<100] S_COM r:=r+s TICK RECV r SEND s:=s+1 TICK t:=t+1 TICK S_COM Lekidis, Bozga, Mauuary, Bensalem r:=0 t:=0 R_COM RECV print(r) TICK TICK t:=t+1 R_COM A model-based design flow for CAN-based systems 10/35
  20. 20. BIP: Interactions  Communication between components involving data exchange s:=0 t:=0 SEND s [s<100] S_COM r:=r+s TICK RECV r SEND s:=s+1 TICK t:=t+1 TICK S_COM Lekidis, Bozga, Mauuary, Bensalem r:=0 t:=0 R_COM RECV print(r) TICK TICK t:=t+1 R_COM A model-based design flow for CAN-based systems 10/35
  21. 21. BIP: Priorities  Used among competing interactions TICK<R_COM s:=0 t:=0 SEND s [s<100] S_COM r:=r+s TICK RECV r SEND s:=s+1 TICK t:=t+1 TICK S_COM Lekidis, Bozga, Mauuary, Bensalem r:=0 t:=0 R_COM RECV print(r) TICK TICK t:=t+1 R_COM A model-based design flow for CAN-based systems 10/35
  22. 22. The BIP toolset Offers:  Translators from various languages and models into BIP  Source-to-source transformers  Code generation by dedicated compilers More information and related material at: http://bip-components.com Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 11/35
  23. 23. Modeling the CAN protocol Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 12/35
  24. 24. Main aspects of the CAN protocol model (1) • • • • Represents the classic CAN protocol functionality [CAN specification version 2.0] Supports the Basic CAN interface [ISO 11898-1] Is compliant with the High-Speed physical layer standard [ISO 11898-2] Does not consider transmission errors Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 13/35
  25. 25. Main aspects of the CAN protocol model (1) • • • • Represents the classic CAN protocol functionality [CAN specification version 2.0] Supports the Basic CAN interface [ISO 11898-1] Is compliant with the High-Speed physical layer standard [ISO 11898-2] Does not consider transmission errors Engine Control Airbag Control Traction Control Seat Control CAN Bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 13/35
  26. 26. Main aspects of the CAN protocol model (1) • • • • Represents the classic CAN protocol functionality [CAN specification version 2.0] Supports the Basic CAN interface [ISO 11898-1] Is compliant with the High-Speed physical layer standard [ISO 11898-2] Does not consider transmission errors Engine Control Airbag Control Traction Control Seat Control CAN Bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 13/35
  27. 27. CAN protocol model REQUEST frame RECV frame REQUEST CAN station SOF ARBITRATION CONTROL SOF DATA frame RECV frame CAN station ACK ARBITRATION EOF SOF CONTROL ARBITRATION DATA ACK CONTROL DATA ACK EOF CAN bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 14/35 EOF
  28. 28. Main aspects of the CAN protocol model (2) Each CAN frame: • Is one of the following types: • • • Data transmission (data frame) Data request (remote frame) Contains the following fields: • • • • • arb : frame identifier rtr : Remote Transfer Request (RTR) bit ide : Identifier Extension (IDE) bit length : Length of data payload : Frame data Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 15/35
  29. 29. CAN station component REQUEST RECV frame frame RECV Controller HANDLE frame arb SOF • rtr ide ARBITRATION length DATA Queuing policy is of type: • • Filter payload CONTROL frame First-In-First-Out (FIFO) High Priority First (HPF) Lekidis, Bozga, Mauuary, Bensalem ACK EOF • Acceptance filters: I. II. Receive every frame from the Bus Deliver it to the application or ignore it A model-based design flow for CAN-based systems 16/35
  30. 30. Controller component Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 17/35
  31. 31. CAN bus component Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 18/35
  32. 32. CAN bus component: Timing model  Discrete time step advance Transmission of one bit (τ bit ) corresponds to one tick Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 18/35
  33. 33. CAN bus component: Timing model (2)  Used for the transmission of each frame field  Duration is indicated by a fixed number of ticks  Overall frame transmission time is: • C frame = [32 + g + (8 × length) + s ]τ bit , where: • • g denotes the number of ticks spent in the arbitration phase • Equal to 12 for a standard frame • Equal to 32 for an extended frame s denotes the number of additional ticks related to bit-stuffing  The computation of the bit-stuffing for every frame can be: • Fixed • Stochastic Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 19/35
  34. 34. CAN bus component: Timing model (3)  The additional transmission time due to bit-stuffing is: s   , where: • = (23 + w + 8 × length − 1) C stuffing τ bit  • w g −1 = • • • 100  Equal to 11 for a standard frame Equal to 31 for an extended frame s ∈ [1, 25] , where the upper bound indicates the worst case  The detailed frame transmission time is: • = C total  s   + C stuffing  [32 + g + (8 × length) + s ] + (23 + w + 8 × length − 1) =  C frame 100  τ bit    Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 20/35
  35. 35. Modeling the application software Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 21/35
  36. 36. Modeling the application software • • Every application consists of a number of Devices Each Device generates a set of frames • Transmission is defined by the following attributes: • • • • Currently provided by XML-based descriptions • • Periodic, event-triggered or purely stochastic With or without offsets Abortable or non-abortable request Compliance with NETCARBENCH [Navet et al., 2007] Accordingly provided Device examples with focus on the transmission part Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 22/35
  37. 37. Device examples ECU with periodic transmission N periodic frames, where periods are: P[i] , i=1,…,N Lekidis, Bozga, Mauuary, Bensalem ECU with stochastic transmission N frames, with a transmission jitter chosen by a given distribution and periods: D[i] , i=1, .. N A model-based design flow for CAN-based systems 23/35
  38. 38. Device examples ECU with periodic transmission N periodic frames, where periods are: P[i] , i=1,…,N Lekidis, Bozga, Mauuary, Bensalem ECU with stochastic transmission N frames, with a transmission jitter chosen by a given distribution and periods: D[i] , i=1, .. N A model-based design flow for CAN-based systems 23/35
  39. 39. The CAN-based system model Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 24/35
  40. 40. Constructing the system model Device 1 REQUEST RECV Device 2 REQUEST Lekidis, Bozga, Mauuary, Bensalem RECV Device 3 REQUEST RECV Device n REQUEST RECV A model-based design flow for CAN-based systems Application model 25/35
  41. 41. Constructing the system model Device 1 REQUEST Device 2 RECV REQUEST REQUEST RECV RECV Device 3 REQUEST REQUEST RECV RECV Device n REQUEST REQUEST RECV Application model RECV CAN station 1 CAN station 2 CAN station n COMM COMM COMM CAN protocol model COMM CAN bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 25/35
  42. 42. Constructing the system model Device 1 REQUEST Device 2 RECV REQUEST REQUEST RECV RECV Device 3 REQUEST REQUEST RECV RECV Device n REQUEST REQUEST RECV Application model RECV CAN station 1 CAN station 2 CAN station n COMM COMM COMM CAN protocol model COMM CAN bus Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 25/35
  43. 43. Outline 1) Design challenges for CAN-based systems 2) Model-based design flow using BIP • • • • BIP overview CAN protocol model Application software modeling Construction of the system model 3) Application and experimental results 4) Conclusion and ongoing work Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 26/35
  44. 44. Deterministic powertrain network Case study using the BIP design flow, where: • The application software consists of: • • 5 Devices 30 periodic frames with associated: • • • • • • CAN identifier, period and payload HPF queuing policy in every Device Fixed 10% bit-stuffing for all the frames No transmission offsets The Bus has a bit-rate of 500 kbit/s Load equally distributed among the Devices Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 27/35
  45. 45. Experiments The generated system model contains: • • • • 20 atomic components 60 connectors 255 transitions 1250 lines of BIP code Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 28/35
  46. 46. Results: Response times • Lekidis, Bozga, Mauuary, Bensalem 1 hour of real system time was simulated in 5 minutes and 30 seconds A model-based design flow for CAN-based systems 29/35
  47. 47. Results: Response times • • 1 hour of real system time was simulated in 5 minutes and 30 seconds The same results can be obtained using RTaWSim [RealTime-at-Work] • Much shorter simulation time (13.5 seconds) Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 29/35
  48. 48. Stochastic powertrain network • Extension to the previous case study: I. II. Probabilistic margin (jitter) for every period Stochastic bit-stuffing Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 30/35
  49. 49. Stochastic powertrain network • Extension to the previous case study: I. II. Probabilistic margin (jitter) for every period Stochastic bit-stuffing Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 30/35
  50. 50. Stochastic powertrain network • Extension to the previous case study: I. II. Probabilistic margin (jitter) for every period Stochastic bit-stuffing Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 30/35
  51. 51. Stochastic powertrain network • Extension to the previous case study: I. II. • Probabilistic margin (jitter) for every period Stochastic bit-stuffing This analysis cannot be performed with RTaW-Sim Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 30/35
  52. 52. Outline 1) Design challenges for CAN-based systems 2) Model-based design flow using BIP • • • • BIP overview CAN protocol model Application software modeling Construction of the system model 3) Application and experimental results 4) Conclusion and ongoing work Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 31/35
  53. 53. Summary Proposed method: Rigorous design flow resolving effectively the current challenges in CAN-based systems • • • • Encapsulates the primitives and communication mechanisms of the CAN protocol Separates software and hardware design issues Fully automated and tool-supported Leads to the construction of a mixed hardware and software system model used for: • • • • Performance analysis Verification of functional and extra-functional properties Code generation Conducted experiments on existing benchmarks illustrate the capabilities and the method’s scalability Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 32/35
  54. 54. Ongoing work • CAN protocol model • • • Selection of the most appropriate distribution for the bit-stuffing and the period margin Design flow for CAN FD-based systems Considered application software • MATLAB/Simulink to BIP translation • Further extensions • Analysis and verification of properties using the Statistical Model Checking BIP tool Generation of optimal device configurations Validation of CAN-higher layer protocols, such as CANopen • • Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 33/35
  55. 55. Extensions related to the CAN FD protocol Applied only in the CAN protocol model • Additional frame fields: • Flexible Data Format (FDF) bit • • If recessive, RTR bit becomes automatically disabled • Bit Rate Switch (BRS) bit Timing model: • Transmission of one bit will be shorter than one tick (τ bit ) • Switch factor related to the selection of CAN hardware components • The additional transmission time due to bit-stuffing in CAN FD is:   7 + w + 8 × length   =  + 4 τ bit C stuffing    s   Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 34/35
  56. 56. Thank you for your attention. Further details: alexios.lekidis@imag.fr Lekidis, Bozga, Mauuary, Bensalem A model-based design flow for CAN-based systems 35/35

×