Design Article
The Virtual Vehicle: Part 1 - In-vehicle networking simulation and analysis
Thorsten Gerke, Synopsys
1/9/2009 11:40 PM EST
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:
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:
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.
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.
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:
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.
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.
|
|
|
|
|
Paul Stoaks
1/14/2009 1:39 PM EST
Thanks Thorsten for this excellent application note. The ability to validate network architectures in this way is extremely helpful for systems designers in many fields. I have found it useful to further raise the abstraction level (prior to the level of analysis you discuss here) by creating a system-level model in order to evaluate network topologies and select physical-layer technologies. Using a Model Based Systems Engineering approach enables high level design space exploration prior to committing to detailed analysis in any one area and speeds the design process as well as improving the quality of the design. Please forgive the plug, but I'd like to point out that Foresight (http://www.foresight-mands.com) is an excellent choice for this high-level system modeling.
Again, thanks for the excellent article.
paul
Sign in to Reply