In case of the structuring of complex and comprehensive networks on the basis of the deterministic FlexRay bus in the vehicle it is necessary to comprehensively check both the logical characteristics of a control unit on a FlexRay bus and the physical signal transmission. In this case, it is primarily a question of the characteristics of individual Test-ECU's with faults, malfunctions or delays in the signal transmission. But also in further cases of application, data must be synchronized and manipulated in one FlexRay network or between two FlexRay networks.
Illustration 1: V-Model: Software solutions from EB on the right of the V-Model open possibilities for data manipulation on the FlexRay bus)
EB supplies two software tools on the right side of the V-model (Illustration 1). 1. With the EB tresos Inspector, procedures on the FlexRay, CAN and LIN bus can be measured and analyzed exactly, 2. the EB tresos Busmirror is presented as a solution for the residual bus simulation and the testing of FlexRay or CAN control units. Either the EB 6100 or the EB 5100 acts as a hardware interface. With a new FlexRay-FlexRay gateway as an add-on to the EB tresos Busmirror, EB opens up further fields of application for the efficient testing and debugging of FlexRay networks and control units.
With FlexRay there exists a special feature: Considerably higher demands on the time-related precision of the test system apply in relation to CAN, which a real-time-capable hardware, which works time-synchronously with the FlexRay bus, has as prerequisite. In practice, FlexRay defines a clear timing which includes binding specifications for all control units with regard to their communication slots. If functions should be implemented directly on the real-time hardware, these can be defined with the so-called Target User Modules (TUM) and dynamically fed in with ongoing test.
Illustration 2: The OEM-specific adapters are individually selected
The FlexRay-FlexRay Gateway is easy to configure as an add-on to EB tresos Busmirror: The user generates a new project in the software, he selects a template which includes information, for example, for necessary OEM-specific adapters (see Illustration 2), he stipulates a memory location for the project and imports a description file of the FlexRay network, usually a FIBEX file. In case of two different FlexRay clusters, a second FIBEX file is necessary, where appropriate. Following this, the sub-divisions are decided on as to which stations really exist and which are emulated. The software then generates a proposal for a routing list based on name consistencies, which can then be changed manually in a second step. Convenient editors are available for this purpose. As early as with the stipulation of the routing table, static data manipulations are possible - at this point the user stipulates conversions on the basis of certain algorithms or a different semantics. (Illustration 3: In this way the user has everything at hand with the configuration).
Illustration 3: In this way the user has everything at hand with the configuration (For higher resolution, click here)
The user then defines OEM-specific adaptations, such as alive-counter and more complex fault interferences, over the Target User Modules, which also open a data channel between the EB 6100 hardware and the host PC for control and dynamic parameterization. The software then generates a final configuration which, as an image, includes the executable firmware for the EB 6100.
The most frequent cases of application of the gateways are indicated in the following.
