18-03-2011, 03:54 PM
hello sir I am sneha. i want seminar report on In Vehicle Networking..
|
In Vehicle Networking
|
hello sir I am sneha. i want seminar report on In Vehicle Networking..
30-03-2011, 01:31 PM
ABSTRACT
Today’s vehicles include a complex symbiosis of intelligent electronic systems and integrated mechanical structures. Today, electronic components and systems account for over 20% of the cost of a high-end passenger car, and this percentage figure is increasing rapidly.
Electronic systems now provide the technology to enable the manufacturer to deliver new features and to meet the mandatory regulation requirements in a cost-effective manner. Vehicle electronic systems are now commonplace and are growing in terms of both quantity and complexity.
In this paper, we will provide an insight into the In Vehicle network systems, overview and the emerging Vehicle networking standards.
INTRODUCTION
Where as a typical Local or Wide Area Network has many personal computers, servers, printers etc. communicating with each other [3], a typical vehicle network has many control modules communicating with each other. Examples of control modules are Engine Control Modules, Transmission Control Modules and Body Control Modules etc. These modules will usually communicate with each other in a vehicle, in real time, helping in the operation of the vehicle.
With stringent limitations placed on the emission gases for the automobiles, it has become impossible to attain this level of control without the help of on-board computing devices. On-board electronic devices also have contributed substantially to vehicle performance, occupant comfort, ease of manufacture and cost effectiveness. Where as at one time a radio probably was the only electronic device in an automobile, nowadays practically everything in the automobile has some electronic feature in them. Some electronic modules used in the vehicles today are:
• Engine Control
• Transmission Control
• ABS Control
• Body Feature Control (Power locks, Power Windows etc.)
• Entertainment (Radio, CD Player, DVD etc.)
An electronic module usually gets its input from sensors (speed, temperature, pressure etc.) that it uses in its computation. Various actuators are used to enforce the actions determined by the module (turn the cooling fan on, change gear etc.). The modules need to exchange data among themselves during the normal operation of the vehicle. (The engine needs to tell the transmission what the engine speed is, the transmission needs to tell everybody when the gear shift occurs, ABS needs to tell the engine and transmission that the wheels are locking). That is how vehicle networks came about. The vehicle network is the medium of data exchange.
Let us assume that every module needs to exchange data with every other module. Let us say Engine Control Module needs to tell all other modules what the engine speed is, Transmission control module needs to tell all modules what the current gear is etc. Wiring the vehicle to connect all the modules together to achieve this communication is a nightmare let alone being highly error prone as shown in Figure 1.
Engine
Control
Module
Transmission
Control
Module
ABS
Control
Module
Body
Control
Module
HVAC
Control
Module
Figure - 1
Now imagine the scenario where some vehicles on the assembly line don't have the ABS option, some don't have power locks/windows option etc. requiring different wiring harnesses. Stocking up on wiring harnesses for all possible combination of options and installing these in the vehicles will become a Herculean task. As a result cost of the vehicle goes up. Also because of the complicated wiring diagnosing and fixing problems becomes a challenge.
The industry's answer to this nightmare was the use of networks in vehicles as shown in Figure 2 also called Multiplexing. This allowed for ease of manufacture, better maintenance capability and flexibility in being able to add and remove options without affecting the entire vehicle's wiring architecture. Each module, a node on the vehicle network, is an island of control; controlling specific components related to their function and communicating with the other modules as necessary, using a standard protocol, over the vehicle network.
Figure - 2
Networks were not new, but their application to the vehicle was. The networks for the vehicles called for:
• Low Cost
• Immunity from electronic noise
• Adaptability to harsher operating environment
• Overall robustness
Although the vehicle network did not place too much emphasis on the data throughput (remember, amount of data that can be transferred in a second) it is changing quickly as more and more computing is done on-board requiring faster networks.
There are several network types and protocols used in the vehicles by various manufactures. Even though there is a push to standardize one network protocol for all manufacturers that dream is still a long way away.
Some examples of transmission media use in vehicle networks:
• Single wire
• Twisted pair of wires
• Optic Fiber
• Untwisted pair of wires
Some protocols used in Vehicle Networks:
• Controller Area Network (CAN) (Used in Europe, Some US vehicles starting 2004)
• J1850 – SCP (Used on many Ford vehicles)
• J1850 – Class2 (Used on GM vehicles)
• J1708 – (Used in Trucks and buses)
• ISO 9141 (Various flavors used in diagnostics)
MULTIPLEXING STANDARDS
The early days of networking involved proprietary serial buses using generic UART (Universal Asynchronous Receiver/Transmitter) or custom devices. This was acceptable in the US because the Big Three (Ford, GM, Chrysler) were vertically integrated and were not highly dependent on external suppliers. However, in Europe and increasingly now in the US, the car manufacturers utilize many external suppliers. Proprietary protocols pose many difficulties with suppliers who need many special system designs to conform to the different protocols. Standard protocols allow modules from many suppliers to easily page link together forming a type of `open architecture.' An open architecture will allow standardized diagnostic and emissions testers and will allow suppliers to benefit from the economies of scale of mass-produced standard protocol devices.
Engine
Control
Module
Transmission
Control
Module
SAE CLASSIFICATION
To classify the various standards, SAE has defined three basic categories of in-vehicle networks based on network speed and functions:
Class A
• Low Speed (<10 Kbits /Second)
• Convenience features (entertainment, audio, trip computer, etc.)
Class B
• Medium Speed (10K b/s to 125K b/s)
• General information transfer (instrument cluster, vehicle speed, legislated emissions data, etc.)
Class C
• High Speed (125K b/s to 1M b/s or greater)
• Real-time control (power train control, vehicle dynamics, brake by wire, etc.)
Class D
• Speeds greater than 1 Mb/sec.
• Used in applications such as Internet, digital TV, x-by-wire.
Table - 1
CLASS A MULTIPLEXING
Most Class A functions require inexpensive, low-speed communication and typically utilize for low-end, non-emission diagnostic, general-purpose communication.
Most of these Class A protocols are UARTs. UART is very simple and economical to implement. Most microcontrollers have the necessary SCI module built-in, or it can be implemented without a microprocessor. The
ABS
Control
Module
Body
Control
Module
HVAC
Control
Module
Vehicle
Networ
k
transceiver is smaller and cheaper than those of other protocols. The transceiver IC may be a custom chip combining multi-protocol capability with regulators, drivers, etc. Right now the leading candidate for a Class A world standard is Local Interconnect Network (LIN).
CLASS B MULTIPLEXING
In the US, the SAE adopted J1850 as the standard protocol for Class B networks. J1850 has been a recommended practice for over seven years and has gained wide acceptance throughout North America. Today J1850 is implemented in many production vehicles for data sharing and diagnostic purposes. The widespread integration of J1850 in-vehicle networks is contingent on low-cost implementation into applications such as body electronics, diagnostics, and instrumentation.
SAE J1850 was a joint effort among the Big Three and is actually a combination of GM's Class 2 protocol and Ford's SCP (Standard Corporate Protocol). The resulting standard has two basic versions. The first is a 10.4 Kb/s VPW (Variable Pulse Width) type, which uses a single bus wire. The second is a 41.6 Kb/s PWM (Pulse Width Modulation) type, which uses a two-wire differential bus. Chrysler adopted a variation of the 10.4Kb/s version.
A strong force driving the standardization of J1850 was emissions legislation. CARB (California Air Resources Board) established OBD-II (On Board Diagnostics II), which requires the implementation of diagnostic tools for emission-related systems. OBD-II specifies that stored fault codes be available through a diagnostic port via a standard protocol. Currently, OBD-II specifies J1850 and the European standard, ISO 9141-2.
CLASS C MULTIPLEXING
The predominant Class C protocol is CAN 2.0. The CAN protocol is targeted at high-speed, real-time control and can operate at up to 1 Mb/s. Robert Bosch GmbH developed the CAN protocol in the early 1980s and worked with Intel on the first silicon implementation, namely, the 82526 controller. This initial implementation of CAN version 1.2 (now known as version 2.0 part A) only allows for an 11-bit message identifier, thus limiting the number of distinct messages to 2032. In 1993 Intel released a new controller, the 82527, the first component to support the latest version of CAN version 2.0B. CAN 2.0B supports both the standard 11-bit and enhanced 29-bit identifier, allowing millions of distinct messages.
ISO in Europe has adopted CAN as the high-speed networking protocol. European automakers have expressed immediate need for the CAN protocol, particularly for luxury models, due to the advantages in-vehicle networking offers to the highly distributed nature of their electronic subsystems. The CAN protocol was first implemented in a 1991 S-class Mercedes Benz, and has since been adopted by BMW, Volvo, VW, Renault, PSA, and others.
In the US, CAN acceptance is growing. The SAE Truck and Bus Control and Communications subcommittee selected CAN in 1994 as the basis for J1939, the class C network for truck and bus applications. For class C automotive networks, the SAE formed a task force to develop a recommended practice for US passenger cars utilizing the CAN protocol. Members from the Big Three, module suppliers, and silicon vendors are participating.
EMERGING AUTOMOTIVE NETWORKING TRENDS
The new categories (Class D) that are emerging are Emission diagnostics, Safety, Mobile Media and X-by Wire [1].
EMISSIONS DIAGNOSTICS
Usage is to satisfy OBD-II, OBD-III, or E-OBD. It must be a legally acceptable protocol. Since this data page link is only needed between the engine controller and the off-board connector, a simple approach is sufficient. Most automakers and truck makers are using KWP2000 already so this is rapidly becoming the emissions diagnostic standard.
MOBILE MEDIA
Usage is for “PC-on-wheels” applications. Three different networks and protocols may be necessary. These sub-categories are low speed, high speed, and wireless. SAE nomenclature is IDB-C, IDB-M, and IDB-Wireless respectively. Bit rate is between 250 Kb/s and 100 Mb/s+.
Low Speed - Usage is for telematics, diagnostics, and general information passing. IDB-C has turned out to be a token-passing form of CAN at 250 Kb/s.
High Speed - Usage is for real-time audio and video streaming. Fiber optics will be necessary due to high speed. It will probably have to be compatible with industry-standard systems such as Connected Car PC, or AutoPC. D2B has seen the first usage (Mercedes 1999 S-class) but MOST is a contender. The IDB Forum is leaning toward Firewire at this time.
Wireless - Usage somewhat undetermined at this time. It will be necessary (initially) for cell phones. Protocols used here are IEEE 802.11b and Bluetooth.
DRIVE-BY-WIRE
Usage is for brake-by-wire, throttle-by-wire, steer-by-wire, etc. applications. Bit rate is between 1 Mb/s and 10 Mb/s. Fiber optics will be necessary due to high speed. Utmost in reliability, performance, and real-time capability is required.
Some protocol candidates are: TTP (Time Triggered Protocol), TTCAN and FlexRay
TTP has its “foot in the door”, but work is underway to see if CAN is capable of doing the job. Major issue is how much fault tolerance is really required. TTFlex is a new unproven method. Any scheme will require dual bus interfaces, dual microprocessors, bus watchdogs, timers, etc. Cost is a big problem. The level of fault-tolerance needed requires a lot of silicon and software, which, of course, is expensive.
PRESENT VEHICLE NETWORK ARCHITECTURE
The present day vehicles have 4 or 5 different data buses for different needs as shown in Figure – 3.
Figure - 3
They are,
LIN
Smart connector sub-buses
CAN - B
General purpose multiplexing (Body Electronics)
CAN - C
High Speed data (power train control, vehicle dynamics, brake by wire etc.)
Emissions / Diagnostics
(ISO – 9141)
Off board communication (memory downloads, emissions test etc.)
ITS Bus / MOST
Used in applications such as Internet, digital TV, Telematics and Navigation
TOOLS FOR NETWORK DEVELOPMENT
There are plenty of tools available in the market today to model, design, simulate and test the different network configurations. Tools are available as hardware interfaces / adapters to plug in to PCs with different form factors like RS232, USB, Parallel port, Ethernet, PCI, PC104 and ISA. The PC based software will help in analyzing the traffic on the different vehicle networks. There are some advanced tools available that work in stand-alone mode with no need of PC. These can be installed inside the vehicle itself to monitor, record and analyze the onboard data even when vehicle is under motion.
CONCLUSION
The Vehicle is well on its way to becoming a node on a private network or even the Internet. This helps to achieve couple things:
1. Bring the world to the automobile
• Navigation System
• Internet Access, Email
• Streaming digital Audio and Video
• Traffic patterns etc.
2. Provide access to the Automobile from the outside
• Remote Diagnostics
• Vehicle Tracking
• Remote Vehicle Access (lock/unlock etc.)
DEFINITIONS, ACRONYMS, ABBREVIATIONS
CAN: Controller Area Network
LIN: Local Interconnect Network
IEEE: Institute of Electrical and Electronic Engineers
OBD: On Board Diagnostics
UART: Universal Asynchronous Receiver / Transmitter
CARB: California Air Resources Board
TTP: Time Triggered Protocol
TTCAN: Time Triggered CAN
IDB: ITS Data Bus
ITS: Intelligent Transportation Systems
MOST: Media Oriented Systems Transport
D2B: Digital Data Bus
Today’s vehicles include a complex symbiosis of intelligent electronic systems and integrated mechanical structures. Today, electronic components and systems account for over 20% of the cost of a high-end passenger car, and this percentage figure is increasing rapidly.
Electronic systems now provide the technology to enable the manufacturer to deliver new features and to meet the mandatory regulation requirements in a cost-effective manner. Vehicle electronic systems are now commonplace and are growing in terms of both quantity and complexity.
In this paper, we will provide an insight into the In Vehicle network systems, overview and the emerging Vehicle networking standards.
INTRODUCTION
Where as a typical Local or Wide Area Network has many personal computers, servers, printers etc. communicating with each other [3], a typical vehicle network has many control modules communicating with each other. Examples of control modules are Engine Control Modules, Transmission Control Modules and Body Control Modules etc. These modules will usually communicate with each other in a vehicle, in real time, helping in the operation of the vehicle.
With stringent limitations placed on the emission gases for the automobiles, it has become impossible to attain this level of control without the help of on-board computing devices. On-board electronic devices also have contributed substantially to vehicle performance, occupant comfort, ease of manufacture and cost effectiveness. Where as at one time a radio probably was the only electronic device in an automobile, nowadays practically everything in the automobile has some electronic feature in them. Some electronic modules used in the vehicles today are:
• Engine Control
• Transmission Control
• ABS Control
• Body Feature Control (Power locks, Power Windows etc.)
• Entertainment (Radio, CD Player, DVD etc.)
An electronic module usually gets its input from sensors (speed, temperature, pressure etc.) that it uses in its computation. Various actuators are used to enforce the actions determined by the module (turn the cooling fan on, change gear etc.). The modules need to exchange data among themselves during the normal operation of the vehicle. (The engine needs to tell the transmission what the engine speed is, the transmission needs to tell everybody when the gear shift occurs, ABS needs to tell the engine and transmission that the wheels are locking). That is how vehicle networks came about. The vehicle network is the medium of data exchange.
Let us assume that every module needs to exchange data with every other module. Let us say Engine Control Module needs to tell all other modules what the engine speed is, Transmission control module needs to tell all modules what the current gear is etc. Wiring the vehicle to connect all the modules together to achieve this communication is a nightmare let alone being highly error prone as shown in Figure 1.
Engine
Control
Module
Transmission
Control
Module
ABS
Control
Module
Body
Control
Module
HVAC
Control
Module
Figure - 1
Now imagine the scenario where some vehicles on the assembly line don't have the ABS option, some don't have power locks/windows option etc. requiring different wiring harnesses. Stocking up on wiring harnesses for all possible combination of options and installing these in the vehicles will become a Herculean task. As a result cost of the vehicle goes up. Also because of the complicated wiring diagnosing and fixing problems becomes a challenge.
The industry's answer to this nightmare was the use of networks in vehicles as shown in Figure 2 also called Multiplexing. This allowed for ease of manufacture, better maintenance capability and flexibility in being able to add and remove options without affecting the entire vehicle's wiring architecture. Each module, a node on the vehicle network, is an island of control; controlling specific components related to their function and communicating with the other modules as necessary, using a standard protocol, over the vehicle network.
Figure - 2
Networks were not new, but their application to the vehicle was. The networks for the vehicles called for:
• Low Cost
• Immunity from electronic noise
• Adaptability to harsher operating environment
• Overall robustness
Although the vehicle network did not place too much emphasis on the data throughput (remember, amount of data that can be transferred in a second) it is changing quickly as more and more computing is done on-board requiring faster networks.
There are several network types and protocols used in the vehicles by various manufactures. Even though there is a push to standardize one network protocol for all manufacturers that dream is still a long way away.
Some examples of transmission media use in vehicle networks:
• Single wire
• Twisted pair of wires
• Optic Fiber
• Untwisted pair of wires
Some protocols used in Vehicle Networks:
• Controller Area Network (CAN) (Used in Europe, Some US vehicles starting 2004)
• J1850 – SCP (Used on many Ford vehicles)
• J1850 – Class2 (Used on GM vehicles)
• J1708 – (Used in Trucks and buses)
• ISO 9141 (Various flavors used in diagnostics)
MULTIPLEXING STANDARDS
The early days of networking involved proprietary serial buses using generic UART (Universal Asynchronous Receiver/Transmitter) or custom devices. This was acceptable in the US because the Big Three (Ford, GM, Chrysler) were vertically integrated and were not highly dependent on external suppliers. However, in Europe and increasingly now in the US, the car manufacturers utilize many external suppliers. Proprietary protocols pose many difficulties with suppliers who need many special system designs to conform to the different protocols. Standard protocols allow modules from many suppliers to easily page link together forming a type of `open architecture.' An open architecture will allow standardized diagnostic and emissions testers and will allow suppliers to benefit from the economies of scale of mass-produced standard protocol devices.
Engine
Control
Module
Transmission
Control
Module
SAE CLASSIFICATION
To classify the various standards, SAE has defined three basic categories of in-vehicle networks based on network speed and functions:
Class A
• Low Speed (<10 Kbits /Second)
• Convenience features (entertainment, audio, trip computer, etc.)
Class B
• Medium Speed (10K b/s to 125K b/s)
• General information transfer (instrument cluster, vehicle speed, legislated emissions data, etc.)
Class C
• High Speed (125K b/s to 1M b/s or greater)
• Real-time control (power train control, vehicle dynamics, brake by wire, etc.)
Class D
• Speeds greater than 1 Mb/sec.
• Used in applications such as Internet, digital TV, x-by-wire.
Table - 1
CLASS A MULTIPLEXING
Most Class A functions require inexpensive, low-speed communication and typically utilize for low-end, non-emission diagnostic, general-purpose communication.
Most of these Class A protocols are UARTs. UART is very simple and economical to implement. Most microcontrollers have the necessary SCI module built-in, or it can be implemented without a microprocessor. The
ABS
Control
Module
Body
Control
Module
HVAC
Control
Module
Vehicle
Networ
k
transceiver is smaller and cheaper than those of other protocols. The transceiver IC may be a custom chip combining multi-protocol capability with regulators, drivers, etc. Right now the leading candidate for a Class A world standard is Local Interconnect Network (LIN).
CLASS B MULTIPLEXING
In the US, the SAE adopted J1850 as the standard protocol for Class B networks. J1850 has been a recommended practice for over seven years and has gained wide acceptance throughout North America. Today J1850 is implemented in many production vehicles for data sharing and diagnostic purposes. The widespread integration of J1850 in-vehicle networks is contingent on low-cost implementation into applications such as body electronics, diagnostics, and instrumentation.
SAE J1850 was a joint effort among the Big Three and is actually a combination of GM's Class 2 protocol and Ford's SCP (Standard Corporate Protocol). The resulting standard has two basic versions. The first is a 10.4 Kb/s VPW (Variable Pulse Width) type, which uses a single bus wire. The second is a 41.6 Kb/s PWM (Pulse Width Modulation) type, which uses a two-wire differential bus. Chrysler adopted a variation of the 10.4Kb/s version.
A strong force driving the standardization of J1850 was emissions legislation. CARB (California Air Resources Board) established OBD-II (On Board Diagnostics II), which requires the implementation of diagnostic tools for emission-related systems. OBD-II specifies that stored fault codes be available through a diagnostic port via a standard protocol. Currently, OBD-II specifies J1850 and the European standard, ISO 9141-2.
CLASS C MULTIPLEXING
The predominant Class C protocol is CAN 2.0. The CAN protocol is targeted at high-speed, real-time control and can operate at up to 1 Mb/s. Robert Bosch GmbH developed the CAN protocol in the early 1980s and worked with Intel on the first silicon implementation, namely, the 82526 controller. This initial implementation of CAN version 1.2 (now known as version 2.0 part A) only allows for an 11-bit message identifier, thus limiting the number of distinct messages to 2032. In 1993 Intel released a new controller, the 82527, the first component to support the latest version of CAN version 2.0B. CAN 2.0B supports both the standard 11-bit and enhanced 29-bit identifier, allowing millions of distinct messages.
ISO in Europe has adopted CAN as the high-speed networking protocol. European automakers have expressed immediate need for the CAN protocol, particularly for luxury models, due to the advantages in-vehicle networking offers to the highly distributed nature of their electronic subsystems. The CAN protocol was first implemented in a 1991 S-class Mercedes Benz, and has since been adopted by BMW, Volvo, VW, Renault, PSA, and others.
In the US, CAN acceptance is growing. The SAE Truck and Bus Control and Communications subcommittee selected CAN in 1994 as the basis for J1939, the class C network for truck and bus applications. For class C automotive networks, the SAE formed a task force to develop a recommended practice for US passenger cars utilizing the CAN protocol. Members from the Big Three, module suppliers, and silicon vendors are participating.
EMERGING AUTOMOTIVE NETWORKING TRENDS
The new categories (Class D) that are emerging are Emission diagnostics, Safety, Mobile Media and X-by Wire [1].
EMISSIONS DIAGNOSTICS
Usage is to satisfy OBD-II, OBD-III, or E-OBD. It must be a legally acceptable protocol. Since this data page link is only needed between the engine controller and the off-board connector, a simple approach is sufficient. Most automakers and truck makers are using KWP2000 already so this is rapidly becoming the emissions diagnostic standard.
MOBILE MEDIA
Usage is for “PC-on-wheels” applications. Three different networks and protocols may be necessary. These sub-categories are low speed, high speed, and wireless. SAE nomenclature is IDB-C, IDB-M, and IDB-Wireless respectively. Bit rate is between 250 Kb/s and 100 Mb/s+.
Low Speed - Usage is for telematics, diagnostics, and general information passing. IDB-C has turned out to be a token-passing form of CAN at 250 Kb/s.
High Speed - Usage is for real-time audio and video streaming. Fiber optics will be necessary due to high speed. It will probably have to be compatible with industry-standard systems such as Connected Car PC, or AutoPC. D2B has seen the first usage (Mercedes 1999 S-class) but MOST is a contender. The IDB Forum is leaning toward Firewire at this time.
Wireless - Usage somewhat undetermined at this time. It will be necessary (initially) for cell phones. Protocols used here are IEEE 802.11b and Bluetooth.
DRIVE-BY-WIRE
Usage is for brake-by-wire, throttle-by-wire, steer-by-wire, etc. applications. Bit rate is between 1 Mb/s and 10 Mb/s. Fiber optics will be necessary due to high speed. Utmost in reliability, performance, and real-time capability is required.
Some protocol candidates are: TTP (Time Triggered Protocol), TTCAN and FlexRay
TTP has its “foot in the door”, but work is underway to see if CAN is capable of doing the job. Major issue is how much fault tolerance is really required. TTFlex is a new unproven method. Any scheme will require dual bus interfaces, dual microprocessors, bus watchdogs, timers, etc. Cost is a big problem. The level of fault-tolerance needed requires a lot of silicon and software, which, of course, is expensive.
PRESENT VEHICLE NETWORK ARCHITECTURE
The present day vehicles have 4 or 5 different data buses for different needs as shown in Figure – 3.
Figure - 3
They are,
LIN
Smart connector sub-buses
CAN - B
General purpose multiplexing (Body Electronics)
CAN - C
High Speed data (power train control, vehicle dynamics, brake by wire etc.)
Emissions / Diagnostics
(ISO – 9141)
Off board communication (memory downloads, emissions test etc.)
ITS Bus / MOST
Used in applications such as Internet, digital TV, Telematics and Navigation
TOOLS FOR NETWORK DEVELOPMENT
There are plenty of tools available in the market today to model, design, simulate and test the different network configurations. Tools are available as hardware interfaces / adapters to plug in to PCs with different form factors like RS232, USB, Parallel port, Ethernet, PCI, PC104 and ISA. The PC based software will help in analyzing the traffic on the different vehicle networks. There are some advanced tools available that work in stand-alone mode with no need of PC. These can be installed inside the vehicle itself to monitor, record and analyze the onboard data even when vehicle is under motion.
CONCLUSION
The Vehicle is well on its way to becoming a node on a private network or even the Internet. This helps to achieve couple things:
1. Bring the world to the automobile
• Navigation System
• Internet Access, Email
• Streaming digital Audio and Video
• Traffic patterns etc.
2. Provide access to the Automobile from the outside
• Remote Diagnostics
• Vehicle Tracking
• Remote Vehicle Access (lock/unlock etc.)
DEFINITIONS, ACRONYMS, ABBREVIATIONS
CAN: Controller Area Network
LIN: Local Interconnect Network
IEEE: Institute of Electrical and Electronic Engineers
OBD: On Board Diagnostics
UART: Universal Asynchronous Receiver / Transmitter
CARB: California Air Resources Board
TTP: Time Triggered Protocol
TTCAN: Time Triggered CAN
IDB: ITS Data Bus
ITS: Intelligent Transportation Systems
MOST: Media Oriented Systems Transport
D2B: Digital Data Bus
28-12-2011, 09:49 PM
Hai ,
I am anupama.Please send me more details about in-vehicle networking..
I am anupama.Please send me more details about in-vehicle networking..
29-12-2011, 09:32 AM
to get information about the topic" In Vehicle Networking" refer the page link bellow
http://studentbank.in/report-in-vehicle-...4#pid60524
http://studentbank.in/report-in-vehicle-...4#pid60524
04-01-2012, 07:41 PM
sir can u plz send me full information about in-vehicle networking......i need to give seminars...plz sir mail me...
05-01-2012, 09:45 AM
to get information about the topic" In Vehicle Networking" refer the page link bellow
http://studentbank.in/report-in-vehicle-...4#pid60524
http://studentbank.in/report-in-vehicle-...4#pid60524
16-03-2012, 10:32 AM
to get information about the topic "vehicle networking" full report ppt and related topic refer the page link bellow
http://studentbank.in/report-in-vehicle-networking
http://studentbank.in/report-in-vehicle-...ing--19921
|
« Next Oldest | Next Newest »
|
