FlexRay - FlexRay Synchronization with CANoe as

Gateway
Version 2.0
2017-06-12
Application Note AN-IND-1-010

Author Vector Informatik GmbH

Restrictions Public Document
Abstract Time synchronization is central for FlexRay systems. This document describes how to
achieve synchronism for two FlexRay buses via a FlexRay - FlexRay gateway.

Table of Contents
1.0 Overview ........................................................................................................................................1
1.1 Use Case / Motivation ..........................................................................................................2
1.2 Problem that is Handled in this Application Note .................................................................2
2.0 Synchronizing two FlexRay Buses..............................................................................................2
2.1 Solutions ..............................................................................................................................2
2.1.1 Hardware Controlled Synchronization .................................................................................3
2.1.2 Software Controlled Synchronization ...................................................................................4
2.2 Benefits vs. Restrictions .......................................................................................................4
3.0 Demonstrator .................................................................................................................................5
3.1 Goal ......................................................................................................................................5
3.2 Hardware/Software Setup of the Demo ...............................................................................5
3.3 Observation / Result ............................................................................................................6
4.0 Additional Information ..................................................................................................................6
5.0 Contacts .........................................................................................................................................6

1.0 Overview
One FlexRay bus provides a global system time on which all ECUs can synchronize. When two
FlexRay buses are required, they run normally independently of each other. Even if both buses
implement the same schedule, they have an offset to each other and they possibly drift. The
synchronous FlexRay time for ECUs on the different buses gets lost.
Moreover, when data must be transferred from one bus to the other, a so-called FlexRay – FlexRay
gateway creates a non-negligible delay in terms of multiples of the cluster’s period (in any of the
directions), because of the time-triggered bus access. For event-triggered buses (like CAN) the delay
only depends (on low bus loads) nearly on the reaction delay (which is much smaller than the
message’s cycle period) of the gateway application.
Additionally, due to a normally non-existing synchronization between both FlexRay clusters, they will
drift to each other. Therefore, the routing delay may vary during run-time and is in-deterministically.
 FlexRay - FlexRay Synchronization with CANoe as Gateway

1.1 Use Case / Motivation

A FlexRay – FlexRay gateway can be used to separate one FlexRay bus into two segments in order to
manipulate the frames’ payload while forwarding them. This allows the modification of FlexRay signals
of real existing ECUs. These data manipulations might be necessary, because responses of a specific
real existing ECU under test should be checked while stimulated with dedicated and manipulated input
frames from the remaining real ECUs. In this case the original FlexRay cluster is split into two real
existing FlexRay buses that are interconnected by a FlexRay – FlexRay gateway, while the application
assumes only one bus and no gateway. This FlexRay – FlexRay gateway normally forwards any
message unchanged from one bus to the other. Thereby specific messages can be manipulated /
adapted or even substituted / deleted by the gateway application. Such a gateway can be
implemented by CANoe.FlexRay using for both buses the same database description (FIBEX file).
Another application scenario might be the integration of a new version of a FlexRay ECU (with new
TDMA parameters) into an already existing (old) cluster. The FlexRay – FlexRay gateway will then
logically interconnect both different clusters.

1.2 Problem that is Handled in this Application Note

Both real existing clusters that are connected via the FlexRay – FlexRay gateway build only one
“virtual” cluster. Both real clusters should run synchronously and the gateway’s forwarding delay
should be minimized. This application note presents two possible solutions (one in hardware and one
in software) in order to run both FlexRay buses synchronous to each other. That means the offset and
drift will nearly be set to 0. This allows minimizing the propagation delay of the FlexRay – FlexRay
gateway (in either one or both directions).

2.0 Synchronizing two FlexRay Buses

All FlexRay controllers that are connected to a FlexRay bus support a distributed clock
synchronization. This is achieved by sending specific reference messages. The measured deviation of
the local observed reception time to the globally defined expected send time can be used to correct
the local clock. Under well-defined assertions this assures a minimal but limited maximum deviation of
all local clocks. The average time of all local clocks is known as the virtual global time base.
In order to synchronize two FlexRay buses their local synchronization mechanism must be combined
(via hardware) or a higher-level protocol in software must take influence on the clock control of both
buses.

2.1 Solutions
A FlexRay controller can handle two FlexRay channels (A/B) for one bus. The clock synchronization
can work with either one or both channels. If the application requires only one channel, then the
second channel can be used for synchronization with the other bus (see Hardware Controlled
Synchronization).
Each FlexRay controller allows the ECU to add/subtract values from the local clock correction vector
via the CHI (Controller Host Interface). In normal application scenarios this is not required. This
feature allows synchronizing the cluster (under certain circumstances) to a super ordinate master
clock. This master clock might be the FlexRay clock of another bus.

Copyright © 2017 - Vector Informatik GmbH 2

Contact Information: www.vector.com or +49-711-80 670-0
 FlexRay - FlexRay Synchronization with CANoe as Gateway

2.1.1 Hardware Controlled Synchronization

This solution is applicable to one channel clusters. A pre-requisite is that the FlexRay TDMA
parameters of both FlexRay clusters must be absolutely equal. The FlexRay – FlexRay gateway
extends the FlexRay cluster to a two channel cluster. But only the gateway’s FlexRay interfaces use
the second channel in order to run both segments synchronously. The topology is depicted in Figure
1.

ECU ECU ECU Gateway ECU

A B C D
IF 1 IF 2

Channel A – Segment Channel A – Segment 2

Channel
Figure 1 – Hardware Synchronization via Channel B

This topology is not fully supported by the FlexRay specification. The FlexRay specification does not
allow the splitting of channel A into two segments while the second channel B is not split (IF1 and IF 2
of the gateway use the same line for channel B but different ones for channel A). For this reason
additional assumptions must be made:
1. On segment 2 of channel A exactly one extra ECU (except the gateway’s second interface) that is
sending a startup and/or sync frame must be connected (additional non-sync nodes are allowed).
This Sync Node may be the cold start helper of the gateway’s second interface itself.
2. On segment 1 of channel A at least one startup and/or sync node (in addition to the gateway’s first
interface) must exist. This Sync Node may be the cold start helper of the gateway’s first interface
itself.
3. The ECUs on the different segments of channel A and the gateway must be started in a well-
defined order. It must be assured that either segment 1 or segment 2 is already synchronous
before the other segment will be started.
4. It must be possible to send two additional startup/sync frames on channel A (one for segment 1
and the other for segment 2). These startup/sync frames must be sent by the gateway (one per
interface) on both channels (A and B).
5. For both segments the same FlexRay schedule (including the same TDMA parameters) must be
implemented.
6. The gateway’s FlexRay TDMA parameter pChannels for both interfaces must be set to 3 in order
to operate with both channels.
7. First segment 1 with IF 1 must be started and then segment 2 with IF 2 must be started.
If these requirements are fulfilled, then both segments will run absolutely synchronously (no offset and
no drift). In fact the common channel B connects both segments of channel A to ONE FlexRay cluster.
Nevertheless, all frames that have to be routed from one segment to the other by the gateway will
have a routing delay of at least one cycle length of the FlexRay bus. The received frame of one
segment can be sent soonest at the next possible cycle according to the frame’s scheduling on the
other segment. This is valid for both directions. Because of the synchronous execution of both
segments the minimal routing delay will be equal for both directions.

Copyright © 2017 - Vector Informatik GmbH 3

Contact Information: www.vector.com or +49-711-80 670-0
 FlexRay - FlexRay Synchronization with CANoe as Gateway

2.1.2 Software Controlled Synchronization

The software controlled synchronization is applicable also to two channel clusters. Both clusters must
not necessarily implement the same TDMA cluster parameters (nevertheless, the parameters must be
compatible in order to find common synchronization points, e.g. the cluster cycle period must be a
multiple of the other cluster’s cycle period). The hardware topology is depicted in Figure 2.

ECU ECU ECU Gateway ECU

A B C influence clock correction
D
IF 1 IF 2

Channel A – Cluster Channel A – Cluster

Channel B – Cluster Channel B – Cluster
Figure 2 – Software Synchronization of two Clusters via the External Clock Correction of Interface 2.

Also for this solution some restrictions must be fulfilled in order to work properly:
1. On cluster 2 exactly one extra ECU (except the gateway’s second interface) that is sending a
startup and/or sync frame must be connected (additional non-sync nodes are allowed). This Sync
Node may be the cold start helper of the gateway’s second interface itself (when ECU D is a non-
sync node).
2. The cycle period of cluster 1 must be a multiple of the cycle period of cluster 2 (or vice versa).
3. A special program on the gateway must periodically compare the cycle periods of both FlexRay
clusters. According to this deviation it must influence the clock synchronization of interface 2 in
order to explicitly prolong or shorten the cluster’s cycle period by manipulating the external clock
correction values.
This solution cannot guarantee absolutely synchronously running clusters. Their drift can be
eliminated, but a minimal offset may remain. Additionally the offset (+/- a specific minimal delta) can
deliberately be chosen, e.g. it is not required to be 0. This allows minimizing the routing delay for one
direction (while the routing delay for the other direction increases).

2.2 Benefits vs. Restrictions

The following table summarizes the main benefits and restrictions of both solutions:

Measure Hardware Solution Software Solution

TDMA Parameters of Cluster 1 compared to
equal Compatible
Cluster 2
Number of separated Sync Nodes ≤1 ≤1
Usable Application Channels only A A, A and B
Time required for Synchronization approx. none ≤ 5 min
Achievable Precision 100% ± 50 us
Table 1 – Benefits and Restrictions of the Hardware and Software Controlled Synchronization Solution

Copyright © 2017 - Vector Informatik GmbH 4

Contact Information: www.vector.com or +49-711-80 670-0
 FlexRay - FlexRay Synchronization with CANoe as Gateway

3.0 Demonstrator
A sample configuration is delivered with CANoe.FlexRay version ≥ 7.1 SP3. See start menu CANoe →
User Assistance → Sample Configurations → FlexRay → 2 Cluster Gateway. In this demo refer
especially to the desktop “FRFR Synchronization”.

3.1 Goal
Synchronize two FlexRay clusters by software. The time difference between the cycle starts of both
clusters can be set to a desired offset value. After the requested offset is achieved the clusters will be
synchronized within a given deviation interval in order to prevent drifting of the clusters.

3.2 Hardware/Software Setup of the Demo

The configuration of CANoe uses 2 FlexRay measurement channels, resp. clusters. Both clusters are
assigned the same FIBEX database that describes the “PowerTrain” example of the CANoe.FlexRay’s
system demo. All ECUs are simulated and are distributed onto both FlexRay networks. Additionally a
gateway is simulated by CANoe that forwards all FlexRay messages from the first to the second
cluster and vice versa.
For the time synchronization of both FlexRay clusters the gateway’s CAPL program includes the
CAPL program “FRFRSynchronize.cin”. Additionally the database “EnvVar_FRFRSync.dbc” with the
definitions of some required environment variables is attached to the second cluster.

Figure 3 – Screenshot of the Demo Application

Copyright © 2017 - Vector Informatik GmbH 5

Contact Information: www.vector.com or +49-711-80 670-0
 FlexRay - FlexRay Synchronization with CANoe as Gateway

The panel “FRFR Sync Control” that is shown in Figure 3 controls the synchronization (resp. the CAPL
include). With the sliders you can request a particular difference of the cycle starts of both clusters.
nd
The shifting of the 2 cluster will be started when the 'Automatic Adjust' is enabled. The shifting is
nd
performed by shortening or prolonging the 2 cluster's cycle time. This is achieved by manipulating
the external offset and rate correction of the FlexRay controller.

Note
If you run this demo in 'Real bus' mode, then you must pay attention to the following
requirements:
> 2 VN interfaces have to be connected to CANoe and must be mapped to channel
FlexRay 1 and FlexRay 2.
> Do NOT connect any nodes to the interfaces! All nodes are currently simulated.
> Do NOT interconnect the FlexRay channels between the interfaces!
> You must connect the hardware synchronization line between both interfaces by a
'Sync cable'!
> You must enable the hardware synchronization in the hardware configuration settings
of CANoe.
> Pay attention to the Write window that the hardware time synchronization works
properly during run-time.

3.3 Observation / Result

The panel “FRFR Sync Control” shows you the requested and the current time difference between
both clusters (“Cluster Offset”, resp. “Cycle Offset”).
The Graphics window “FRFR Start Of Cycle 0” shows you the positions of the cluster’s cycle starts
only for cycle 0 as a peak for both clusters. This allows you to estimate the total time difference
between both clusters (“Cluster Offset” = value of environment variable “envDiff_SOC0_FR1FR2”) in
the range from [0, 64 * gdCycle [.
The Graphics window “FRFR Cluster Start of All Cycles” shows you the positions of the cluster’s cycle
starts for all cycles. This allows you to estimate the time difference within one cycle (“Cycle Offset” =
value of environment variable “envDiff_SOC_FR1FR2”): [0, gdCycle [ ).
Observe that the shifting takes considerable time until the requested offset is reached.

4.0 Additional Information

VECTOR APPLICATION NOTE
AN-IND-1-003 Time Synchronization in Multibus Environments

5.0 Contacts
For a full list with all Vector locations and addresses worldwide, please visit http://vector.com/contact/.

Copyright © 2017 - Vector Informatik GmbH 6

Contact Information: www.vector.com or +49-711-80 670-0