The AUTOSAR alliance has been changing the way vehicle networks and ECUs are designed. Different domains in the car have different safety and performance requirements, and the in-vehicle networks must have predictable and secure performance.
Since its formation in 2003 the AUTOSAR (AUTomotive Open System ARchitecture) alliance has been changing the way vehicle networks and electronic control units (ECUs) are designed.
AUTOSAR offers an industry-standard approach to automotive network design, and the ability to integrate, exchange, and transfer functions, data, and messages within a car network. The standard offers tremendous benefits to the interface between automotive OEMs and their Tier 1 suppliers, as they are able to exchange design information in a consistent, well defined, machine-readable format.
Different domains in the car have different safety and performance requirements, and the in-vehicle networks supporting them must have predictable and secure performance. Automotive technology has evolved using a range of bus technologies to connect up to 100 different ECUs on a luxury vehicle -- these usually include LIN, CAN, FlexRay, MOST, and Ethernet-based architectures.
Managing the thousands of messages and interactions among these ECUs has become an impossible task if approached manually. Therefore automated design and synthesis tools to help predict network performance and correct in-vehicle functionality have become mandatory for designers in the automotive ecosystem.
Vehicle data buses
A typical modern vehicle will have a mixture of bus types and protocols with the appropriate network chosen from a choice of LIN, CAN, FlexRay, MOST, and Ethernet. The higher data-rates needed for multimedia/audio-visual signals and surround-car vehicle cameras have led car makers and their OEMs to implement Ethernet as a network solution in place of MOST. But for many standard vehicle functions the bandwidth and performance provided by LIN and CAN is sufficient.
ECUs are grouped into network “clusters” in the vehicle architecture, and these clusters are linked by communication “gateways.”
Clusters will normally share the same bus type, so a high-reliability, high-speed network might be FlexRay based, while a less critical door-lock ECU could be CAN or LIN based.
ECU Gateways often have to interface different signal types and perform mapping and conversion functions between the different bus architectures.
The strong industry demand for continuously improved safety and compliance to standards such as ISO26262 has increased vehicle network performance while reducing manufacturing and component costs. Network standards have been evolving to accommodate ever higher data rates, on secure, low-cost, physical cables. The characteristics and uses of typical automotive network options are summarized in Table 1.
Table 1: Automotive vehicle network buses
Network timing analysis
Let’s take a more detailed look at the timing analysis of CAN and FlexRay networks. It is useful to examine the essential characteristics and differences of these two network types.
CAN-based networks: CAN-based networks are universally used in vehicle networks, and their operation is defined by standard ISO 15765-2. The CAN bus offers a high degree of system flexibility; it is relatively easy to add new ECU receiver nodes to an existing CAN network without making any significant hardware or software modifications to the existing ECU nodes.
This is attractive to designers wishing to expand or upgrade existing networks, or adding new variants to existing production vehicles.
During the real-time operation of a CAN network the urgency of messages to be exchanged over the network can vary greatly. For the ECU managing engine fuel injection, for example, feedback on instantaneous engine load needs to be immediate while a parameter like engine temperature can be sampled less frequently.
The priority, at which a message is transmitted compared to another less urgent message, is specified by an “identifier” contained in each message.
The transmission priorities are defined during system design and cannot be changed dynamically. In a CAN architecture, bus access conflicts are resolved by bit-wise arbitration of the identifiers involved -- the CAN bus has no master, and the arbitration on network use is carried out equally at all ECU nodes connected to the bus. If the first bit is a "0" the message is given priority over the others.
This is called a "dominant" message. If the first bit is a "1" it is given a lower priority (a "recessive" message).
Thus the highest-priority messages always get through to their intended destinations, but the low-priority messages may be temporarily blocked until the traffic eases up. ECU nodes wanting to send lower-priority messages will not reattempt transmission until the bus is available again. The CAN bus can carry messages between ECUs with up to 8 bytes of data, and the signals to be transmitted on CAN are packed into message “frames.”
FlexRay-based networks: The FlexRay protocol is much more deterministic than CAN. FlexRay is a “time-triggered” protocol that provides options for messages to arrive in precisely defined time frames -- to a resolution of one microsecond.
FlexRay messages can be up to 254 bytes long, so there is a high capacity for complex messages to be exchanged between ECUs.
It can also run at much higher data rates than CAN. Because the timing is predefined, the messaging arrangements need to be planned well in advance, and typically pre-configured and designed by the automotive OEM or Tier 1 partner. In a CAN protocol network, ECU nodes only need to know the correct baud rate to communicate, but ECU nodes on a FlexRay network must know how all the pieces of the network are configured and connected in order to communicate.
Checking and validating the timing of FlexRay network is a time-consuming task -- this is where automating timing analysis and synthesizing message packing into time frames can reduce errors and design cycle time.