Flexible Scheduling on Controller Area Network

1
Flexible Scheduling on Controller Area Network

• Paulo Pedreiras Luís Almeida

DET IEETA Universidade de Aveiro Aveiro-Portugal
RTS 2002 Paris, France Mars 27, 2002
2
Presentation outline

• Brief description of the FTT-CAN protocol
• Flexible scheduling on CAN using FTT-CAN
• Example using EDF
• Comparison with other approaches for EDF message
  scheduling on CAN
• Conclusions

3
FTT-CAN Protocol

• FTT-CAN Flexible Time-Triggered Communication
  on CAN
• Communication structured in ECs
• Time and event-triggered traffic (sync and async,
  resp.)
• Centralized scheduling and
• On-line admission control for TT traffic

4
Scheduling on FTT-CAN

• Functional architecture of Master node

Synchronous Requirements Table (SRT)
Init. phase
Id
Period
Deadline
Tx. time
Priority
1
1
1
0
670
1
3
2
2
1
890
2
...
...
...
...
...
...
N
11
11
4
760
5
Scheduler
EC
Mesgs
Dispatcher
k-1
1
3
11
EC-schedules
k
1
5
k1
1
3
8
9
CAN BUS
5
Scheduling on FTT-CAN (2)

• Stations follow EC-schedules conveyed in the
  Trigger Message
• they are unaware of the scheduling policy in use
• native MAC handles collisions within the EC
• EC-schedules are built using SRT parameters
• supports any scheduling policy (EDF, fair sched)
• Scheduling policy can change on-the-fly.
• Message parameters can change on-the-fly.

6
Scheduling on FTT-CAN (3)

• Scheduler prevents message transmission from
  extending beyond an upper limit of the
  Synchronous Window (S)
• messages that do not fit are delayed to the
  following ECs ? Inserted Idle Time

EC-schedule k
EC-schedule k1
Max. Sync. window
Max. Sync. window
SM1
SM3
SM4
SM1
SM8
SM8
7
Sync and async traffic

• FTT-CAN forces temporal isolation between
  time-triggered (synchronous) and
  event-triggered (asynchronuos) traffic
• Asynchronous messages are handled as in CAN (but
  only during asynchronous windows)

Asynchronous window
Synchronous window
TM
TM
SM1
SM3
SM4
AM21
AM7
8
Example EDF on FTT-CAN

• Motivation
• Higher bus utilization with guaranteed
  timeliness
• Liu Laylands U bound for tasks (with
  preemption)
• Ulub 1
• U bound considering inserted idle-time (X)
• Ulub 1

9
EDF on FTT-CAN (2)

• Level of schedulability - RM vs EDF (simulation
  results)
• 10.000 random sets with 32 messages each
• Message periods in 3 groups (fast, medium and
  slow)
• Data length 1..8 bytes

Sched by RM
Sched by EDF
Max. Sync. Window 80 LEC
100
80
60
All sets schedulable for
Scheduled sets()
40
20
0
63
65
67
69
71
73
75
77
79
81
Utilisation factor()
10
EDF on FTT-CAN (3)

• Downside of EDF scheduling
• Computational cost in the Master node
• Solutions
• Software-based e.g. Planning scheduler
• (scheduler builds PLANs with several ECs)
• Hardware-based e.g. FPGA co-processor, powerful
  ?P

11
EDF on FTT-CAN (4)

• Reducing computational cost of scheduling using
  the Planning Scheduler

Experimental results
EDF-Max
EDF-Avg
80
75
RM-Max
70
RM-Avg
65
60
Scheduler CPU load
55
50
45
40
35
30
2
3
4
5
7
10
20
30
40
ECs / Plan
12
EDF on FTT-CAN (5)

• Reducing computational cost of scheduling
  using hardware support
• Under EDF, the Planning scheduler does not reduce
  computational cost on average
• Hardware-based solutions imply extra cost but it
  is confined to the Master node, only.

13
EDF on CAN vs. FTT-CAN

• Previous work concerning EDF scheduling on CAN
  relied on the native ID-based arbitration.
• Dynamic priorities are encoded in the CAN ID
  field and must be updated as deadline approaches.

CAN ID field
Dinamic priority
Message ID
Encodes the priority. Changes with the time.
Identifies the message
14
EDF on CAN vs. FTT-CAN (2)

• Drawbacks of previous approaches
• Undesired compromise between nº of bits for
  priority and nº of bits for identification
• Requires frequent dequeuing and requeuing of
  messages in all nodes to update priorities
• Requires explicit clock synchronization
• In FTT-CAN none of these drawbacks hold

15
EDF on CAN vs. FTT-CAN (3)

• Comparing data efficiency between
• FTT-CAN based EDF implementation
• CAN-based EDF implementation (Di Natale, RTSS00)

EDF FTT-CAN
EDF 9
100
90
80
70
60
Schedulable sets ()
50
40
30
20
10
0
5
10
15
20
25
30
35
40
45
50
55
60
Data utilisation ()
16
Conclusions

• FTT-CAN supports a high degree of flexibility
• combines time and event-triggered traffic
• efficiently supports flexible scheduling of TT
  traffic
• Scheduling policy can be any
• Scheduling policy can change on-line
• Comm. requirements can change on-line

17
Conclusions

• An example concerning EDF was shown
• Using EDF instead of RM scheduling allows
• Greater bus utilization factor with timeliness
• however ...
• greater processing power is required to build
  EC-schedules (in the Master node).

18
Conclusions

• The FTT-CAN based EDF implementation
• Is easy to develop
• Is more efficient
• Greater data efficiency
• Greater CPU efficiency (added complexity
  confined to the Master node)
• No compromise in the CAN native addressing
  scheme
• No limit in the deadline ranges