|
The Virtual Vehicle: Part 1 - In-vehicle networking simulation and analysis
In-vehicle networking allows room for optimization; however, it also allows opportunity for errors. The design of appropriate topologies for the physical layer has proven a tremendous challenge, requiring model-based methodologies and tools in order to validate topology concepts early in the design process.
|
|
By
Thorsten Gerke, Synopsys
|
Page 1 of 2
|
Automotive DesignLine
(01/09/2009 11:40 PM EST)
|
|
|
Edited by Rick DeMeis
State-of-the-art vehicle systems include a significant number of electronic control units (ECU)—upwards of a hundred in some cases. All ECUs are connected to each other through digital communication networks. The design of appropriate topologies for the physical layer has proven a tremendous challenge, requiring model-based methodologies and tools in order to validate topology concepts early in the design process.
In modern vehicles, networking between ECUs is done via digital communication buses. In most cases several technologies such as CAN, LIN, MOST or FlexRay are deployed concurrently. Parallel deployment is necessary to meet the requirements for data throughput, security, and cost optimization. The most widely used technology is the CAN Bus, implemented in almost every vehicle. Typical applications include networking of the power train as well as comfort functions.
Network topologies
The request for more new functions has significantly increased the number of ECUs. Up to 22 ECUs is not uncommon in today's high-speed CAN networks. When designing the networking topologies in terms of signal integrity however, several challenging issues should be considered beyond the number of ECUs.
The figure above summarizes those issues in a small network. The networking architecture can be separated into two parts: The logical and physical architecture. The logical architecture describes the transmitter/receiver relations and defines the network configuration, but does not include any information about the actual physical implementation of the network—such as:
Which topology is being chosen (star, linear, hybrid, etc.)?
How will the termination be realized?
What does the physical interface between the ECU and communication bus look like?
These questions are important for a properly functioning network and can be described by the physical network architecture. Even if the logical network architecture is functionally correct, an inappropriate implementation of the networks physical layer can severely impact network operation. In a worst case scenario, the targeted network architecture is not feasible at all. If an ECU sends a logical bit to the remaining ECUs, the shape of the signal received by the other devices (receivers) depends on the topology and the components used.
Signal integrity issues
In contrast to the ideal digital transmission of the controller signals, the signal behavior on the bus shows unwanted harmonic waves. Issues affecting signal integrity over the whole topology include:
Type of topology (star, linear, hybrid, etc.)
Structure of the physical control device interface
Use of EMC and ESD compatible elements (e.g. inductors, varistors)
Cable type and length, termination (central, de-central)
The implementation quality depends on the network designer's experience and skills. In-vehicle networking allows room for optimization; however, it also allows opportunity for errors. In extreme cases, a poorly balanced system can result in dramatic oscillations which lead to sampling errors by the communication controller. Under certain circumstances this can drastically reduce network performance or eliminate the electronic control unit (ECU) from communication altogether.
When specifying new topologies it is desirable to optimize the networks. However, this process presents a challenge for developers. For analysis of many criteria (e.g. propagation delays between the ECUs which refers to the time that a bit needs to traverse from device X to device Y), it is not sufficient to rely on simplified calculations. This limitation is especially true when dealing with various types of common mode chokes and significantly influences the dynamics during the transitions between the logical bit levels. To analyze such issues during topology specification, it is necessary to have the topology available already. In addition, the corresponding criteria would have to be determined by measurements.
At this point of development, the topology only exists on paper and measurements are not available. In order to solve this problem, automotive manufacturers rely on model-based design. This requires a development environment that enables virtual design of prototype topologies. The virtual prototypes serve as executable specifications for developers and allow detailed investigation of topologies directly from the network specification phase. The figure below shows an example of a high-speed CAN topology with 14 ECUs. In this case the high-speed CAN topology has been built as a cascaded star topology via twisted cables. The respective ECUs are represented by models of the CAN bus interface. For signal integrity analyses this complexity is sufficient.
View a full-size image
As an example, the following figure shows the model of an ECU. ECUs are represented by their physical bus interface only.
A model of the complete ECU is not necessary for signal integrity analysis. The components considered in the above model include:
Cable transceiver
Split termination
ESD and EMC protection
Communication controller
Common mode inductor
Oscillator
For the CAN communication controller, a model has been developed that has the relevant features for signal integrity. The model incorporates the bit timing as well as synchronization (hard and soft synchronization), arbitration, and acknowledgement. A complete communication controller is not necessary for these analyses because only a small part of the data link layer functionalities is required for the purpose of signal integrity analysis. The model has been implemented through a digital state machine.
The required simulation models listed are part of the Synopsys Saber development environment and include transceiver models from NXP, Infineon, Bosch, TI and other IC manufacturers. Models for common mode chokes from manufacturers such as Epcos and TDK are also part of the library. For state machine modeling, Saber provides a tool (StateAMS) which enables modeling of analog/mixed-signal state machines. While ordinary digital state diagrams facilitate timing driven modeling only, StateAMS also allows for modeling of analog parts as well.
|
|
 |
Related Companies |
 |
|
|
|
|
|
CAREER CENTER
|
Ready to take that job and shove it?
|
|
SPONSOR
|
|
|
|
RECENT JOB POSTINGS
|
|
|
For more great jobs, career related news, features and services, please visit EETimes' Career Center. |
|
