FlexRay and CAN cluster emulation solutions

How would you like being able to test ECUs in a FlexRay, CAN or LIN network while keeping your existing equipment and the know-how and processes you established during the course of many years of testing? We can help you with that. We upgrade your existing test systems to make them fit for FlexRay.

ECUs have to pass a lot of tests in the course of their life-cycle, during pre-development, development, component testing and end-of-line testing. In order to test ECUs in a FlexRay network you need a real-time capable test system. That is because FlexRay is a time triggered protocol, a schedule determines the exact point in time when each message has to be sent. Accordingly, messages that are sent out of schedule are identified as errors and are therefore not allowed. So what are your options in order to make your existing test systems real-time capable?

We offer you a set of three different hardware interfaces that provide the necessary computing power and real-time capability to emulate the remaining cluster during testing. Each one of these hardware interfaces is tailored to a specific application and always integrates with existing test systems via standardized interfaces.

EB interface hardware variants for every use case

EB 2100 - developer interface hardware

The EB 2100 interface hardware allows for an inexpensive start with cluster emulation. It is a powerful stand-alone interface hardware for use at the office. It comes in a light-weight casing and uses standardized SUBD connectors.

EB 61×0 – automotive grade interface hardware

If you wish to emulate and test under harsh conditions in climate chambers or during real world long-term durability tests, the EB 61×0 stand-alone interface hardware is what you need. It comes in a rugged casing (protection category IP 65) and with automotive grade self-locking ODU connectors.

EB 5100 - upgrade card for existing testing systems

An easy way to upgrade your existing test systems is to use our EB 5100 interface hardware, a slot card based on the PMC standard. It can be integrated into virtually any system, thanks to comprehensive driver support. The EB 5100 can also be used on various carrier boards in PCI, PXI, VME or also PHS bus-based systems.

Comparison of EB bus interface hardware variants

EB 61x0	EB 2100	EB 5100
2x FlexRay	2x FlexRay	5x Physical layer module slots for FlexRay, CAN and LIN
2x CAN	4x CAN
1x LIN	2x LIN
Protection class IP 65 - automotive grade housing	Light weight desktop housing	PMC standard board with adaptor boards for PCI, PXI, cPCI,
Ambient temperature range -30°C to +70°C	Ambient temperature range 0°C to +50°C
ODU/Lemo connectors	DSUB9 connectors

Cluster emulation principle

The emulation of other ECUs with the bus system allows you to start-up and test a system even if the remaining ECUs are not avaliable. Hence you can test and validate a node without having to set up an actual cluster. The global design and the description of the system down to the partitioning of the ECUs are typically provided by the OEM, in the form of a FIBEX-file. Our cluster emulation software EB tresos Busmirror helps you configure the cluster emulation to mirror the behaviour of the ECUs at the various levels – on the level of service functions (e.g. network management) as well as at the application level.

Our cluster emulation solution separates these levels. Parts that are closely related to the network protocol are executed directly on the our interface hardware. These protocol-parts in turn form the basis for parts of the application with functionalities specific to the application. The application-parts can be processed either on the hardware, if they have to be executed in real-time, or on the host-system.

The application design can be broken down into two basic cases. Namely the synchronous and the asynchronous, as compared to the cycle of the FlexRay bus, application design. Synchronous design means that the application is synchronized with the FlexRay bus. That way the applications most recently calculated values can be sent via the bus in every new cycle of the schedule. In contrast, asynchronous design does not specify that kind of synchronisation. This means of course that application data is not available on the bus in every new cycle. The appeal of the asynchronous design is that it doesn’t require a lot of changes in your existing test system when integrating our EB tresos Busmirror solution. We do of course support both application design variants.

How to set up a cluster emulation

The configuration of a FlexRay cluster emulation with our EB tresos Busmirror is highly automated. You can simply import the communication matrix which comes in a FIBEX-file. Our software tool then extracts the necessary information for the FlexRay configuration from that FIBEX-file. This XML-based file describes the FlexRay signals, their mapping to signal-groups and related frames as well as the entire schedule. In the next step select the nodes you wish to be emulated and transfer the schedule, customized to the target hardware, to an EB interface hardware of your choice. The EB interface hardware then emulates the other ECUs with the bus system based on this configuration. The generated configuration is independent from the host-system. The advantage of this approach is that you need to to configure this set-up only once and can then distribute it to other departments that work on the same project.