Model-based design in Controller Area Network systems

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Design flow
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
7/35

14. Design flow
Component
reuse
Tools
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
7/35

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. 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. 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. 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. 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. 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. 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. 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. Modeling the CAN protocol
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
12/35

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. 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. 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. 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. 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. 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. Controller component
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
17/35

31. CAN bus component
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
18/35

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. 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. 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. Modeling the application software
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
21/35

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. 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. 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. The CAN-based system model
Lekidis, Bozga, Mauuary, Bensalem
A model-based design flow for CAN-based systems
24/35

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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