Designing, managing in-vehicle networks
Andrew Patterson of Mentor Graphics discusses how AUTOSAR provides a pre-defined approach for ECU and vehicle network design. However, designers still face challenges in implementing time-efficient and performance-secure systems.
The AUTomotive Open System Architecture (AUTOSAR), which was formed in 2003, has since been responsible for the progressive design of vehicle networks and electronic control units (ECUs). It 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.
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 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.
|Related Articles||Editor's Choice|