A System Level View of Automotive Network Design

May 1, 2008
This article provides insight into some of the available networking techniques and tools for the design of optimized and reliable automotive network solutions.

The role of automotive networking has evolved from supporting wiring harness cost and weight reduction, to fundamentally enabling implementation of most new vehicle functions. Today's in-car distributed systems have 80-plus electronic control units (ECUs) connected by multiple types of networks. Many of the inefficient practices introduced during the early days of “multiplexing” — as networks are often referred to — still prevail. Today's challenges call for a new approach.

According to domain experts, 90 percent of innovation in cars for the foreseeable future will be enabled through the electronic vehicle architecture. Networks constitute a major structural element of the car's EE architecture, and shall be treated as such. Successful implementation of complex distributed functions depends on reliable networks. Configuration of the network — being a shared resource — does represent a sizeable challenge, which has to be solved at the system level.


For well over a decade, design of multiplexed networks in automobiles has been a bottom-up style engineering exercise, with very few exceptions. The approach, focusing on agreed “messages” between the ECUs directly involved, has left the effects of unintentional interactions on the bus to be resolved by testing. “Build-and-test” has been the prevailing paradigm. Faults found in late phases of the car project were expensive, and risky to correct, associated with high risk for introducing secondary errors.

Network design practices of the day often mean early binding and late verification of the design. This is contrary to what the industry is striving for in any other technical area, namely; early verification and late binding of solutions.

Predictability in the time domain is a key factor in achieving reliability and efficiency. Timing requirements describe the behaviors that must occur for a function to be correct. Timing behavior defines what the system will do — in other words, it represents a model of the behavior of the system. Timing requirements are essential, representing the requirements for the design, as well as the goal for testing. As shown in Figure 1, a timing model can be used to describe the different elements — end-to-end, for the entire timing chain.

Timing analysis could be applied to the timing behavior, to produce results, which can be checked against the timing requirements. Known timing requirements and timing behavior are both essential prerequisites for scheduling analysis.

As an example, we should take a closer look at a production proven methodology and the tool — the Vehicle Network Architect (VNA).


A tool implementing the correct timing model can in the simplest case perform analysis of a manually created communication matrix to calculate worst-case message latencies for messages sent over a bus. The results can be checked against deadline requirements, derived from the vehicle function's end-to-end timing requirements. Interestingly, in a more advanced scenario, such a tool can perform complete cluster synthesis and gateway configuration, based on requirements declared in its input files. This mode offers fully automatic frame creation, signal packing and schedule table generation.

To be useful, such a tool has to handle all protocols used in a vehicle, to ensure transparent routing of signals, with guaranteed end-to-end latencies through gateways and multiple bus segments.

The dominating network solutions in automotive EE systems of today are control area network (CAN) and local interconnect network (LIN). To meet the demand for higher bandwidth in safety-critical applications, the industry initiated development of FlexRay. These protocols are expected to co-exist in cars for the foreseeable future. The reason for this is that each protocol has a specific field of application, where it represents the cost optimal solution.


System level design (SLD) is often referred to as the next frontier in electronic design automation (EDA), expected to bring substantial productivity and efficiency gains to the automotive industry. The resulting solutions are correct and optimized by design, rather than being a candidate for lengthy integration testing of components provided by a multitiered and multivendor supply chain.

Such a process cannot be implemented without advanced tools. A fragmented market, characterized by proprietary solutions, specific to each major OEM was not a feasible base for deployment of such products in the past. To realize the potential of SLD, and to turn the attention of the EDA industry toward automotive applications, a paradigm shift was required (Figure 2).


AUTomotive Open System Architecture (AUTOSAR) is an emerging standard for automotive software architecture. A lot of work has been spent on defining a multilayered software architecture with well-specified functions and interfaces, along with the file formats to describe configuration data. This complemented by a detailed metamodel, pave the way for novel SLD tool offerings.


VNA has been built based on a holistic concept, defining a protocol-independent design methodology for distributed real-time networks in vehicles. The concept is dealing with technical and non-technical entities (i.e., partitioning of re-sponsibilities into well-defined roles in the development process). The vision is “enabling correctness by design.” The majority of system-related issues can be identified and solved early in a project. The concept is based on a foundation of guaranteed message latency, and a signals-based publish/subscribe communication model. This provides abstraction by hiding the network and protocol details, allowing the developer to work in the application domain with signals, functions and related timing information.

VNA has been developed to support a development process, based on strict systems engineering principles, starting with requirement capturing, and then taking the user through the stages, leading to a highly optimized design, with fully predictable timing behavior. Clear partitioning of roles and responsibilities is part of the philosophy behind the tool (Figure 3).

The amount of information required to properly define the networks are vast. To support data input VNA provides automated import from third-party tools using an XML-based format, as an alternative to manual data input via the GUI. A built-in multilevel consistency checker verifies all data.

The workflow in VNA ensures that all relevant information about the network is captured. Global objects shall be created first, and then (re-)used in several projects. The VNA user works with objects of types such as signals/nodes/interfaces, etc. These objects are used to build up the networks used in a car. Signals are defined by name and type, and can have logical or physical encoding information attached. Interfaces detailing hard-ware requirements are defined, describing actual nodes on a network. For each node, receive and transmit signals are defined, and timing requirements are provided for the signals. This information is intended for “global use,” that is, across car variants, platforms, etc. When all global data have been collected the network will be designed by connecting the interfaces in a desired configuration.

VNA has strong project and variant handling. Different configurations can selectively use or adapt the global objects, for example by removing a high-end feature from a low-end car model. This means that VNA can manage multiple configurations, designs and releases, with version and variant handling.

All data objects, both global and configuration specific, are stored in a common database. All complex, time-consuming VNA operations are performed toward a local RAM mirror of the database to shorten response times.

Extensive functionality for consistency checking is built into the VNA tool. The consistency check can be activated on demand, normally running continuously to check user input and provide immediate warning when errors are detected. The consistency check ensures that the network design follows all predefined rules.


Much effort has been spent on developing and refining the timing analysis in VNA. The timing analysis dealing with CAN is built upon a scheduling model called dead-line monotonic analysis (DMA), and calculates the worst-case latency for each frame amongst a defined set of frames sent on the bus. Parts of this functionality have been built into the consistency check routine, but the real power of the VNA tool is found in the frame packer/frame compiler functionality.

The frame packer/compiler attempts to create the optimal packing of signals into frames, than calculate the proper IDs to every frame, ensuring that all the timing requirements captured earlier in the process are fulfilled if possible (some set of requirements might represent a non-schedulable scenario). This automatic packing of multiple signals into each frame makes more efficient use of the data bus, by amortizing some of the protocol overheads involved, thus lowering bus load (Figure 4). Beyond the bandwidth gains, the combined effect of multiple signals per frame and perfect filtering results in lower interrupt and CPU load for ECUs. To handle carry-over nodes, which are not configurable, their associated frames can be defined as “fixed.” Frame packing can also be performed manually if desired.


A network normally consists of multiple network segments using different protocols. Signals may be transferred from one segment to another through a gateway node. Gatewaying of data — even across multiple protocols — is automatically configured by VNA. Handling of timing requirements over one or more gateways is also handled by VNA. This solution requires no special gateway hardware.


VNA automatically creates a set of configuration files, representing the complete network, as well as configuration data specific for each node in the system. Use of reconfigurable nodes makes the system very flexible, since the concept separates application-dependent information, and network-dependent information. A change in the network by the system integrator can easily be applied to a vehicle without having to recompile the application software for the ECU. A variety of files for control of third-party analysis and measurement tools can be generated as an option.

The VNA tool enables the OEMs to easily share data with their suppliers. Support of standards such as FIBEX and XML further simplify information sharing and constitutes a basis for configuration of third-party communication layers.


Consequent use of automated tools implementing deterministic scheduling brings significant improvements in reliability and efficiency, and leads to repeatable processes in network design. Since the network is correct-by-design, the only remaining validation effort is to verify correctness of the implementation.


Antal Rajnak is chief scientist for automotive network design in Mentor Graphics Corp.'s System Level Engineering division.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!