FlexRay - FlexRay Synchronization with CANoe as Gateway

Size: px

Start display at page:

Download "FlexRay - FlexRay Synchronization with CANoe as Gateway"

Griselda Stokes
6 years ago
Views:

1 FlexRay - FlexRay Synchronization with CANoe as Gateway Version Application Note AN-IND Author Restrictions Abstract Vector Informatik GmbH Public Document 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 Use Case / Motivation Problem that is Handled in this Application Note Synchronizing two FlexRay Buses Solutions Hardware Controlled Synchronization Software Controlled Synchronization Benefits vs. Restrictions Demonstrator Goal Hardware/Software Setup of the Demo Observation / Result Additional Information Contacts Overview One FlexRay bus provides a global system time on which all s 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 s 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.

2 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 s. These data manipulations might be necessary, because responses of a specific real existing under test should be checked while stimulated with dedicated and manipulated input frames from the remaining real s. 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 (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 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 Vector Informatik GmbH 2

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.

3 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. A B C Gateway IF 1 IF 2 D 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 (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 s on the different segments of channel A and the gateway must be started in a welldefined 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 Vector Informatik GmbH 3

4 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. A B C Gateway influence clock correction IF 1 IF 2 D Channel A Cluster Channel B Cluster Channel A 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 (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 D is a nonsync 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 Cluster 2 equal Compatible 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 Vector Informatik GmbH 4

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.

5 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 s 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 Vector Informatik GmbH 5

6 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. The shifting of the 2 nd cluster will be started when the 'Automatic Adjust' is enabled. The shifting is performed by shortening or prolonging the 2 nd 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 Time Synchronization in Multibus Environments 5.0 Contacts For a full list with all Vector locations and addresses worldwide, please visit Copyright Vector Informatik GmbH 6

Simulation based Timing Analysis of FlexRay Communication at System Level. Stefan Buschmann Till Steinbach Franz Korf Thomas C.

Simulation based Timing Analysis of FlexRay Communication at System Level Stefan Buschmann Till Steinbach Franz Korf Thomas C. Schmidt stefan.buschmann@haw-hamburg.de {till.steinbach, korf, schmidt}@informatik.haw-hamburg.de