In-vehicle networks: Timing analysis of CAN and FlexRay networks

Car data bus

A typical modern car will be equipped with various buses and protocols and choose the right network from LIN, CAN, FlexRay, MOST and Ethernet. Multimedia/audio-visual signals and car surround camera systems require higher data rates, so car manufacturers and OEMs choose Ethernet instead of MOST for network solutions. But for many standard automotive functions, the bandwidth and performance provided by LIN and CAN are sufficient.

In the automotive architecture, ECUs are grouped together to form "clusters" that are connected via communication "gateways". Clusters typically share the same type of bus, so to achieve high reliability and high speed standards, a FlexRay network is used, but less demanding door lock ECUs can be handled by CAN or LIN. ECU gateways often have to connect different types of signals and perform mapping and conversion functions between different bus architectures. The automotive industry has a strong demand for continuous improvement in safety and compliance with standards such as ISO26262, which has improved the performance of in-vehicle networks while also reducing manufacturing and component costs. Continuously evolving network standards can accommodate higher and higher data rates, and automotive cables have also achieved the goal of being safe and low-cost. See Table 1 for the characteristics and applications of typical automotive network solutions.

Table 1: Automotive network buses

Network Timing Analysis

Next, let's look at timing analysis of CAN and FlexRay networks in more detail. It is useful to understand the basic characteristics and differences between these two types of networks.

CAN Network:

CAN is a widely used type of in-vehicle network, with ISO 15765-2 as the operating standard. The CAN bus provides a high level of system flexibility, making it relatively easy to add new ECU receiver nodes to an existing CAN network without making major hardware or software changes to the existing ECU nodes. For automotive designers, this can greatly help them expand or upgrade existing networks, or design new variants.

FlexRay Network:

The FlexRay protocol is more deterministic than CAN. FlexRay is a "time-triggered" protocol that provides different options for sending messages to a destination within a precise time frame - down to 1us. FlexRay messages can be up to 254 bytes, so the capacity for complex messages that need to be exchanged between ECUs is large. FlexRay also has a higher data rate than CAN. Because the timing is predetermined, the arrangement of messages needs to be planned in advance and is generally pre-configured or designed by the automotive OEM or Tier 1 supplier partner. In a network using the CAN protocol, ECU nodes only need to know the correct baud rate when communicating, but ECU nodes on a FlexRay network must know how the various parts of the network are configured and connected when communicating. Checking and verifying the timing of a FlexRay network is time-consuming - therefore, automated timing analysis and packaging of messages into time frames can reduce errors and design cycle time.

Defining Network Timing

The first step in simulating automotive network timing is to accurately define the connections between ECUs. The software approach proposed by AUTOSAR defines all automotive functions as a collection of software components and maps them to physical ECU hardware. An ECU may have several functions, and internal signals are passed between them. Once the connections are defined, the timing parameters of each object in the design (if known) can be defined. There are several external sources of timing information; a widely used automotive standard is FIBEX - a standardized XML-based file format defined by the Association for Standardization of Automation and Measuring Systems (ASAM).

The physical path of the example system is shown in Figure 1 and Figure 2. The brake position monitor module is connected to the controller ECU, which in turn is connected to the actuator. Within each module, individual software components also contribute to latency. We will look at the impact of these components on the overall system latency.

Overview of brake system signal paths

Braking system using AUTOSAR components - detailed timing parameters can be defined

Table 2: Transfer steps for the AUTOSAR braking example

In the example provided in Table 2, the maximum allowable end-to-end signal path is 100ms. From actual measurement results, we know that the sender needs 5ms and the receiver needs 10ms, so the maximum allowable communication path delay is 85ms.

If you use an advanced AUTOSAR component editor, such as Mentor's VSA COM Designer tool, you can enter the timing information for each component in the path, but this is also a difficult task. Another approach is to import the timing and connectivity information from an external database.

When simulating a CAN bus data path, it is necessary to account for the uncertainty at the start of a transmission. It is possible that a higher priority message will occupy the data bus, causing a delay in the transmission. Therefore, it is necessary to find the jitter factor that causes delay variation - usually knowing in advance how many higher priority signals may be on the bus so that the jitter factor can be predicted as accurately as possible. Using these parameters and automated design rule checking (DRC), the maximum delay from step (3) to step (7) is 74.5 milliseconds, which allows the design to pass. This is a "worst case" test, and the designer needs to trust that the path delay will never be worse than this, and in fact it will be much better.

Typical timing report from the VSA COM timing analysis tool showing DRC violations

Figure 3 shows a typical timing report with signal path violations highlighted in red. The overall bus utilization is shown at the top of the table (3.69%).

Automotive Communication Matrix Synthesis

The overall definition of the automotive network timing schedule is typically stored in a “communication matrix” that is part of a central gateway ECU. Mentor has developed a design tool solution that can be used to automatically synthesize this database and package all the different information into frames in the correct order.

AUTOSAR signal information is grouped into protocol data units (PDUs), which are then grouped into transmission frames. For CAN and LIN frames, there is one PDU per frame, but a FlexRay frame may contain multiple signal PDUs.

One challenge in installing a fully defined communications architecture is that subsequent architectural changes are difficult and may require a complete redesign of the network, but the high speed and determinism of transmission make this approach very attractive for FlexRay applications and can ensure the safety-critical functions of the car.

in conclusion

AUTOSAR provides predefined standard methods for in-vehicle network and ECU design. However, designers still face challenges in improving the efficiency and performance of their designs. By using design automation tools to calculate timing and generate in-vehicle communication systems, the utilization of valuable network bandwidth can be greatly improved while maintaining a safe range of automotive performance. As the complexity of CAN, FlexRay, and Ethernet convergence increases, the use of automated design rule checking and timing performance synthesis tools will help shorten design time and avoid tedious manual verification processes.