When developing a control unit, the proper functioning tests are of enormous importance. However, the complete system is not available for testing the control unit in most cases. Therefore, one must simulate the missing control unit data by means of a so-called restbus simulation (RBS).
There are many application possibilities and deployment times of a restbus simulation in vehicle development. It can be used at an early stage for rudimentary ECU testing right through to partial integration testing of automotive networks. A restbus simulation is ideal whenever only parts of a network are present and the rest must be simulated. Missing functionalities of any control unit can be simulated in the RBS.
Usually the OEM provides the global design and description of the system up to the partitioning of the ECUs. Because such a system consists of a variety of signals with all kinds of properties and values, it is important to reduce the complexity involved. One must therefore identify the relevant signals that affect the ECU application. In addition, the configuration must provide adequate timing behaviour to enable real-time behaviour of the selected system.
Compared to previous bus systems, FlexRay has higher transmission rates and it is also capable of real-time operation thanks to Time Division Multiple Access. However, this places significantly higher demands on the development and structure of a FlexRay network, which also affects the FlexRay restbus simulation (RBS). In an RBS with FlexRay, messages must be sent at fixed times. This requires real-time scheduling.
For a FlexRay controller to even send data, various boundary conditions must be met. Among others, these include the presence of at least two start-up nodes, correctly calculated CRC algorithms, accurately transmitted network management messages, and Message (Alive) counters. All this must be taken into account by a FlexRay RBS in real time. Unlike with CAN, it makes more sense to run a RBS on dedicated hardware with FlexRay. A real-time hardware platform ensures that FlexRay messages are sent in their designated slots. An example of such a kind of hardware is the FlexDevice-L. Due to the variety of connection options (CAN, FlexRay, LIN, RS232, SPI, CAN-FD, Ethernet, BroadR-Reach), this hardware can be used in many application areas.