LIN or CAN communications have represented standards in automotive communication systems for quite a while now. Their flexibility, versatility and robustness make them obvious choices and often design engineers choose them by default. Nevertheless, one of the primary objectives of every commercial system is to be cost effective, therefore a solution that would allow usage of existing physical interfaces for alternative communication purposes would provide an efficient tool for reducing the cost of the equipments and would further reduce the weight of the vehicle harness (one of the most important contributors to the weight of a vehicle). This paper introduces a hardware solution for completely eliminating all the layers of the common communication methods (CAN and LIN) in automotive camera systems.

The emerging demand for automotive camera systems has recently put new strains on the companies designing such devices. Their complexity steadily grew along the years and the specifications became more detailed and more restrictive with respect to the used technologies. The primary need for such systems is in high-end personal vehicles and in coaches. However the reasons behind each application might be different. In personal vehicles, the role of such a system might be assisted parking or T-junction visibility increase (therefore helping the driver), while in coaches the system can be used to allow the passengers to monitor the cargo bay during stops or to present them an extended view of what is in front or behind the vehicle (therefore having a security and entertainment role).

Fig.1. Enhancing vehicle Field of View using Camera System

Existing Architectures
During recent developments of such camera systems, several approaches have won the preference of the engineers. Most of them resemble a star configuration, but what is common to all of them is the need to have a bidirectional communication between each camera in the system and the central ECU which performs the digital image processing or the central processing unit of the car (see Fig. 2)

Fig. 2. Typical Architecture for an Automotive Video System

Through this bidirectional communications channel, the ECU can control the functional mode of the camera (active/sleep), can configure various parameters of the cameras and can read them back. It can also be used as a high-level diagnostic method in case it is needed (and in most of the cases it is!).

Basically, in such a configuration, it is the task of the cameras only to capture the images and to send them back to the Camera ECU. Here the video is edited at a very low level. Corrections are made to compensate for the lens distortion, overlays are added to help the driver in whatever it is he wants to do. Also text messages can be combined with the image captured by any of the camera, allowing the system to present disclaimers or other important warnings to the driver.
Once the ECU selects the desired view, it edits the image data and them passes it further to the Display Unit. One of the important aspects of such systems is the way video data is transmitted. Normally, due to the higher quality, a digital approach would be preferred (Fig. 4). The fact that most image sensors used in cameras are digital, further advocates this solution. Embedded clock bits SerDes are especially well suited to applications that transmit raw data plus other signals such as control, parity, frame, sync, status, etc.

However, due to the particular nature of the application, as an automotive system, one of the most stringent requirements is to have a minimum number of cables in the various harnesses (going from camera to the ECU or from the ECU to the Display Unit). This actually rules out the option of a digital bus which would require at least 8 data lines in addition to the various control lines. Depending on the video format, in addition to the video data, there are four control signals:

HREF horizontal blanking
VREF vertical sync
VACTIVE active video
PIXCLK 2 x sample clock

The other options are an analogue video transmission (NTSC typically) or high speed LVDS lines.

Fig. 3. Straight digital connection: cables between camera and ECU would total to more than 10!

Fig. 4. Useful solution: only three wires between camera and ECU!

It is beyond the scope of this article to give an overview of the LVDS or NTSC standards. What I want to underline is the fact that it is possible to build architectures with a minimal number of connections between the camera and its controller, even with existing technologies.

LIN (Local Interconnect Network) is a concept for low cost automotive networks, which complements the existing portfolio of automotive multiplex networks [4]. However, although low cost, what can be easily noticed is that the number of LIN physical connections proportionately increases with the number of cameras. And this adds to the cost, complexity and weight of the vehicle harness, not to mention the need of having some sort of LIN transceivers on both the camera and the ECU. Another major drawback of using LIN type of connection in this particular type of systems is the need to bring the battery voltage to the cameras, which could otherwise be supplied by a much lower voltage (5V or 3.3V).

Taking into account that the number of connections can already be reduced to 3 (or 5, if we count the Power line and the ground), we draw the conclusion that dropping the need for one particular line would actually decrease the harness and the number of connections by a significant 20% (worst case), which is a good number for such a competitive industry.

A new generation of integrated circuits, which is to be provided by several manufacturers (Maxim, National Semiconductors), makes it now possible to study the feasibility of not using the old LIN method of communication, but using the LVDS lines for a bidirectional transfer of data. Video data will be transmitted from the camera towards the ECU. Configuration data and commands can be transmitted from the ECU towards the camera, using various protocols and methods. This is known as backchannel communication.

LVDS Connection
The LVDS connection is a result of the need to have a reduced number of connections for transmitting digital video between two devices. The differential nature of LVDS has many inherent advantages. The most fundamental of these advantages is the ability to reject common-mode noise [5]. As such, a wide variety of components exist on the market which allow the conversion of digital video data (large bus) to LVDS data (two differential lines, but with higher frequencies – above 1GHZ). Such components usually come in pairs (to convert LVDS data back to conventional digital video standards) and are known as serializers and deserializers.

Fig. 5. Typical architecture of LVDS connection; also used in automotive industry

Basically, every major IC manufacturer provides its own pair of such components with various parameters, performances and of course, drawbacks.

The particularly high frequency of the communication poses real problems with respect to shielding EMC and distances larger than 1-2 meters. However, these are all solved by today’s standard methods. What can be noticed from the above figure, is that in a standard LVDS construction, the data lines only allow communication in one direction: from the serializer to the deserializer. In the regular LVDS signal everything is encoded: the video data, the pixel clock, and the horizontal and vertical synchronisation pulses. There are possibilities however, that information can be passed even the other way around, from the deserializer to the serializer, provided that both of them have the appropriate hardware mechanisms. One example of such a pair of integrated circuits is the MAX9257 (serializer) and MAX9258 (deserializer) which will be soon delivered to the market by Maxim.

Fully Programmable Serializer/Deserializer with UART/I2C Control Channel
The MAX9257/MAX9258 bidirectional serializer/deserializer pair, with integrated control channel, form a complete digital video link over a single differential line or twisted-wire pair. The MAX9257/MAX9258 serializer/deserializer convert up to 18 bits of parallel data into a high-speed serial data stream.

Amongst their features we can count on:

• No Reference Clock Required at Deserializer
• Integrated UART/I2C Control Channel
• Programmable Serial Data Rate
• Programmable Spread Spectrum
• PRBS Loop-Back Self Test
• Remote Power-Up

They allow either a UART interface, either an I2C one providing just enough flexibility in the potential architecture of the video camera. Using such an approach, the overall architecture of the system presented in the first image of this paper can be very much simplified, yielding a more robust configuration (Fig. 6).

Fig. 6. Improved for an Automotive Video System

References
- http://www.maxim-ic.com.cn/pdfserv/en/da/MAX9257_MAX9258-AD.pdf
- Dave Lewis, “SerDes Architectures and Applications”, Design Conference 2004, pp. 7 (http://www.national.com/appinfo/lvds/files/designcon2004_serdes.pdf)
- Keith Jack, “Video Demystified”, Fifth Edition, 2007, pp. 154
- LIN Specification Package, Revision 2, Chapter 2, pp. 3
- NI Developer Zone, “Understanding LVDS for Digital Test Systems”, Chapter “Benefits and Advantages of LVDS” (http://zone.ni.com/devzone/cda/tut/p/id/4441#toc2)

Read the Italian version: LVDS - Eliminare il ricorso alla comunicazione LIN o CAN nei sistemi video automotive