By Christopher J. Loberg, Tektronix
The automotive industry is a very competitive environment where manufacturers are constantly looking for product differentiation and cost savings. Intelligent networks are becoming an important part of this effort to get ahead and stay competitive because the primary benefits they deliver are automotive safety and infotainment.
The availability of lower-cost serial data networks to manage the delivery of automotive safety and infotainment is enabling rapid adoption of new features such as on-board video, personalized climate control, and intelligent drivetrains. As a result, according to Credit Swiss First Boston, automotive semiconductor sales will reach 30% of all semiconductor sales by 2010. Semiconductor sales for automobile applications are expected to be approximately $105 billion by 2010.
The two most common intelligent networks today are CAN (Controller Area Network) and LIN (Local Interconnect Network). CAN has been available in the market for over 13 years. It was originally developed for automotive applications in the early 1980's. The CAN protocol was internationally standardized in 1993 as ISO 11898-1. CAN was adopted to provide the necessary infrastructure for vehicle diagnostics, powertrain/chassis and basic car control (windows, doorlocks, etc.). The CAN network has expanded over time to support ABS (antilock braking systems), tire pressure monitoring, infotainment systems, and other emerging intelligent vehicle applications. Industry estimates predict over 300 million CAN nodes will ship in 2005, growing to almost 500 million nodes shipping by the end of the decade.
As the applications supporting CAN grew in the '90s, it became obvious that CAN bus systems are expensive because of increased costs per node, and with high overall network traffic, they can be extremely difficult to manage. To help reduce costs and simplify network management, the LIN Bus architecture was developed in 2000 to provide the industry with a cost-competitive sub-bus network. LIN enables manufacturers to offload traditional CAN network tasks to a lower-cost implementation that is more flexible, albeit at a lower speed. Some LIN Consortium members believe that some premium vehicles in the next decade will have more LIN nodes than CAN nodes.
View a full-size image
Intelligent automotive network design challenges
As the two networks grow in popularity and application usage, there are challenges facing automotive designers. One is determination of the optimized network architecture. Also important are managing timing differences in the CAN network and understanding the impact sub-networks (LIN) will have, when added to an existing CAN design, on timing and network management.
Implementing either or both networks requires at least a pair of physical interface devices to establish communications. As a result, there is need for a set of standards for compatibility. The Bosch CAN specification does not dictate physical layer specifications for anyone implementing a CAN network. This is both a blessing and a curse to the designer. The Society of Automotive Engineers has developed specs that enable designers in the U.S. (ISO in Europe) to test for compatibility, but the actual physical layer implementation is left open to the designer. With this flexibility comes the opportunity for confusion and finger-pointing.
CAN network optimization issues will surface when physical interfaces support a lower-cost, buffer-based system and network traffic levels are "bursty" enough to outstrip the buffers and data is lost. In another case, a CAN network topology includes physical interfaces with a FIFO (first in, first out) traffic management system and the need for near real-time updates is not met. These situations and others can occur when the overall network design needs are not considered up front. It is important when developing a CAN Network to ensure bus traffic is optimized.
Managing timing between CAN nodes on a network is vital for reliable system performance. Programming the CAN bit time registers, by taking real-world data of quartz oscillator tolerance values and propagation delay between CAN nodes, is critical for CAN node synchronization.
Ensuring that the quartz-based oscillator is running properly is essential for network synchronization. If the oscillator is not operating properly, there are many different issues, which could happen and not surface as a critical error. Oscillator tolerance depends on aging of the component, operating temperature, and noise. CAN bit register programming could cause errors in timing the sample point, causing error frames, with priority CAN nodes losing out in accessing the bus.
With the various implementations of protocols on a single network inter-connected using a gateway, there is a need for accurate and in-time communication between different segments of network across that gateway. It is important to monitor protocol activity across all of these implementations while maintaining a single interface point for signal integrity purposes. As designers continue to look for ways to optimize network performance at the lowest possible cost, the ability to change gateways, data link layers, and protocol wording is very important. However, even more important is the need to maintain a singular testing/monitoring point on the network that looks through all of the different implementations in place.
Measurement tools and design tips
By Christopher J. Loberg, Tektronix
There are a variety of software and hardware solutions for design, development and testing of intelligent automotive networks. PC-based analysis tools can be used for protocol decode and simulation, enabling designers to design predictable performance into their networks. For example, Vector’s CANalyzer enable this type of network management and simulation. These PC-based tools provide good overall protocol layer viewing and help engineers with design and simulation capabilities such as:
Listing of bus data traffic (tracing)
Display of the data contents of specific messages
Interactive sending of predefined messages
Sending of logged messages
Statistics on messages
Oscilloscopes, typically a general-purpose measurement instrument, can become very good tools for real-time feedback of network performance. For instance, when outfitted with the proper triggering capabilities and analysis software, an oscilloscope provides designers with the ability to simultaneously monitor and decode of two segments of the network (CAN-CAN or CAN-LIN or a combination of the two).
Oscilloscope-based protocol decoding tools can offer simultaneous decoding of CAN and LIN data. Users can choose the message that is being transferred from LIN to CAN and view it in protocol decoded format (see below). This will assist designers in knowing whether a LIN message is accurately translated to CAN or not, and also to determine the latency across the network. With tools like these, the designer can select specific LIN and CAN messages and zoom in. With a cursor-driven data readout, the designer can view the latency time across the gateway.
CAN/LIN decoded protocols are shown in a time-synchronized view (Tektronix TDSVNM software)
View a full-size image
Automated oscillator tolerance and propagation delay measurements offer real-world data, enabling accurate programming of the CAN bit time registers in the CAN controller.
Noise
The automotive environment is electrically very noisy. The noise can cause the CAN signal to degrade quickly. Noise can be in the form of glitches, spikes, and unit interval changes, or even timing aberrations. It is difficult to interpret this noise when it exists on an non-return-to-zero (NRZ) encoded CAN signal. A real-time oscilloscope has the ability to identify each unit interval (UI) and the overlap between each UI to give the designer a comprehensive view of the CAN message. This approach enables designers to quickly locate problems caused by noise.
This CAN eye diagram is generated from a Tektronix TDS5000B oscilloscope.
View a full-size image
The real-time 'scope can also enhance efficiency of network debugging and system integration by triggering on various network conditions, as well as on CAN message content, such as ID, data, and error frame.
星期五, 三月 06, 2009
订阅:
博文评论 (Atom)
没有评论:
发表评论