Ref: z2727153m
Automotive in-vehicle networks are moving toward a network-of-networks model, in which multiple networking standards are used to meet the wide range of performance requirements for automotive systems. The hardware foundation of the network-of-networks model is a gateway hub, which provides a hardware interface to every network in the vehicle. Similarly, the TCP/IP (transmission control protocol/Internet protocol) layers provide a common software foundation for all devices on the in-vehicle network. Any application software running on any node is completely interoperable with applications on other nodes, using TCP/IP as the common interface.
This article describes a layered software architecture for implementing a network-of-networks model to handle all of the needs of future vehicle designs, including: vehicle systems control (power train, running gear, airconditioner/heater, etc), entertainment audio/video, cellphone, and Internet access.
Layered communication protocols
Layering provides flexibility and scalability in communication protocols. By hiding implementation details from higher-level functions, a layer makes those functions independent of the implementation. For example, a file transfer protocol might not even be aware of which technology is used to carry its data. A lower-level protocol might select an optical data link for high-bandwidth communication, but if the link is broken it may switch over to a lower-bandwidth cable as a backup to maintain connectivity. As long as the data link protocols implement the same protocol, higher-layer protocols will be able to use them interchangeably.
Figure 1 describes how communication protocols are implemented without layers. Typically, an application would implement a driver to provide a specific set of services over a specific type of data link.
This might not be an unreasonable implementation when the application does not require complex services or scalability to future designs. Consider a simple digital camera that communicates over a serial port to a host PC. The problem of scalability occurs when the need arises to make any change to the product. For example, if the market demands a USB interface, this would not be a simple modification to a serial port driver. If the camera-side driver handles high-level functions for the application software such as file transfer services, low-level functions such as parity checking over the data link, and all of the functions between these levels, this will be a complex piece of software. Making a fundamental change to this software (such as modifying an RS232 driver to handle USB) is likely to be more difficult than creating a completely new implementation.
Another important goal of the layered approach is to simplify software design by providing the programmer with a high-level application programming interface (API). If the programmer wants to transfer a file, a high-level file transfer protocol would provide the simplest set of services needed to specify the file, destination, etc. Low-level mechanisms such as retransmitting a block when a parity error occurs would be handled in layers below the API. Figure 2 describes the programmer's view of the API provided by layered communication protocols.
From the point of view of the application programmer, the API presents a highly simplified user interface, in which all of the nuisance details of data communication are handled transparently. The API implements an idealised virtual connection, in which the programmer can ignore details like parity errors, flow control, etc. The programmer only needs to provide the essential information needed to implement the connection (destination address, pointers to memory buffers, etc).
At some level, there will have to be a physical connection through which the data is transmitted, but the protocol layers between the API and the physical layer handle all of the underlying mechanisms for supporting the virtual connection model. Figure 3 shows the layers inside a TCP/IP protocol stack.
The four layers in this model are:
* Application layer - provides protocols which are used directly by application software. The protocols include File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), HyperText Transport Protocol (HTTP), etc.
* Transport layer - the Transmission Control Protocol (TCP) implements a bidirectional end-to-end connection for transmission of TCP segments. The User Datagram Protocol (UDP) implements a message-based model for sending and receiving UDP datagrams.
* Network layer - handles transmission, forwarding, and reception of packets over the network. Most network layers implement the Internet Protocol (IP) for transmission of packets called IP datagrams.
* Physical layer - interfaces to the data link hardware. This is the layer of the protocol stack which actually loads and unloads data to/from communication peripheral registers and memory buffers. CAN and Ethernet networks are common cable-based networking standards. Bluetooth radio networks (called piconets) are dominant for wireless headsets, hands-free remote control of cellphones, and other short-range audio/data communication. The IrDA standard is used for wireless infrared communication.
Layered protocols provide scalability because they impose modularity and standard interfaces. For example, if someone invents a new data link technology, running the complete protocol stack over the new medium only requires writing a compatible physical layer driver. All of the other layers stay the same, so with minimal effort the new technology can be a drop-in replacement for the old technology.
Network-of-networks model
Because of the need for networks with varying degrees of reliability and bandwidth, multiple network types will be used in future in-vehicle networks. The combination of layered protocols with a gateway processor provides communication across different networking technologies, as shown in Figure 4.
Future in-vehicle networks are likely to include:
* CAN network - medium-bandwidth, high-reliability network already standard in the automotive industry.
* Bluetooth piconets - medium-bandwidth, wireless network already standard for communication with cellphones and mobile computers.
* Audio/video network - high-bandwidth network for entertainment media. Several protocols are competing for this niche, including Domestic Data Bus (D2B), FireWire (IEEE 1394), Media Oriented Systems Transport (MOST), and Mobile Media Link (MML).
* Low-overhead networks - UART-based networks (LIN) and chip-to-chip buses such as I²C, SPI, and Microwire support low-cost interface to keypads, displays, sensors, etc.
Future in-vehicle networks typically will have multiple CAN networks: low-speed (10-125 Kbps) networks for serving devices like door locks and tail light clusters which use CAN to reduce wiring, and high-speed (126 Kbps-1 Mbps) networks for critical high-performance functions such as powertrain control.
Example of in-vehicle network implementation
Figure 5 shows an example of an in-vehicle network based on a gateway processor that can be built today using highly cost-effective components.
The gateway processor acts as a host for the CAN networks, because the CAN nodes themselves do not run IP-based protocol stacks. When a web browser needs to access a CAN node, it communicates with the web server. The web server interprets the actions requested by the browser and generates communication on a CAN network to carry out the requested actions.
The gateway also acts as a host for external analog and digital I/O, as well as external peripherals interfaced on low-overhead chip-to-chip networks. A navigation system could be interfaced as a network device if it ran its own protocol stack or it could be hosted by the gateway processor.
An example of a cost-effective gateway processor offered by National Semiconductor is the CP3BT26, a member of the CP3000 family of connectivity processors. It includes features such as:
* 24 MHz 16-bit RISC CPU with 32-bit extensions.
* 256 Kbytes on-chip flash memory.
* 8 Kbytes flash data memory (programmable while executing from 256 K flash).
* 32 Kbytes SRAM.
* Bluetooth baseband controller.
* Dual CAN 2.0B active controllers with object storage (formerly called fullCAN).
* USB 1.1 full-speed node.
* ACCESS.bus, SPI, and Microwire/Plus low-overhead chip-to-chip buses.
* Quad UART.
* AAI codec interface (compatible with SSI interface).
* 8-channel, 12-bit A/D converter.
* 54 general-purpose I/O port pins.
* General-purpose timers.
* Watchdog timer.
* Low-power modes.
Complete Bluetooth and TCP/IP protocols stacks are available. The device comes with comprehensive support for a pre-tested suite of software development tools, peripheral drivers, and a realtime operating system.
The software architecture used by the diagnostic system is shown in Figure 6.
A high-level driver in each CAN node implements an application-specific protocol for responding to requests received from the web server. The driver is responsible for parsing and decoding the protocol data units (PDUs) and spawning any local tasks needed to satisfy the actions requested by the PDU. Once the local tasks terminate, any results generated by the tasks are formatted and returned to the web server over the CAN bus.
A dynamic node configuration (DNC) server maintains a list of active nodes. When a node is added to the CAN network (this can occur 'hot' or 'cold'), it immediately begins broadcasting configuration requests to the DNC server running on the gateway. Modelled after the Dynamic Host Configuration Protocol (DHCP) used by many PCs to automatically acquire the network configuration, a similar (simplified) protocol can be implemented to allow CAN nodes to acquire certain needed network configuration data. Using this mechanism, nodes may be added and deleted in a manner similar to the plug-and-play mechanism used in PCs. CAN nodes use DNC requests to advertise their randomly generated node ID - the 'alias' it wishes to use as its name or 'address' on the CAN network (this is not to be confused with the message-based filtering and IDs used on a CAN network).
When the gateway's DNC server receives a DNC request, it first checks that the ID requested by the node is valid and that it does not conflict with any of the other nodes currently on the network. The server checks that it has the memory space available to add the node's configuration table to its list of active nodes. Finally, if all goes well, the DNC server acknowledges the request and assigns the node a unique number to serve as its name while active. The node's ID is also added to the server's list of active nodes. All subsequent communications directed at that node will use the negotiated ID. Should the requested ID be invalid, the gateway rejects the request, which prompts the node to request another ID until it finds one that is acceptable.
Future trends
Optimising across all these distributed systems will be essential for:
* Making the vehicle lighter to meet future fuel efficiency requirements.
* Increasing the range of personalised services to enhance the mobility experience.
* Automatic ad hoc networking with wireless personal electronic devices (cellphone, PDA, laptop) brought within range of the vehicle.
* Simplifying the addition of new features and functionality.
* Integrating complex systems that include software from multiple vendors.
Most key electrical sub-systems of a vehicle will all be networked on a private 'intranet'. Services that will be networked include:
* Power management and configuration information.
* Identification and configuration information.
* Dashboard displays (vehicle status, speed, fuel level, odometer, etc).
* Body status and control (door locks, mirrors, seats, etc).
* Diagnostic data display (RPM, oil temperature, etc).
* Diagnostic test modes (adjusting timing, fuel/air mix, etc).
* Powertrain status.
* Navigational system (moving map display).
* Entertainment system status and control.
* Human-machine interface (displays, speech, etc).
The vehicle will increasingly rely on being networked to the mobile (personal) and external environment. One of the most valuable features of a wireless Internet connection is remote collection of operational data. The manufacturer can check to see whether the customer is following the preventive-maintenance procedures, monitor changes in performance that indicate wear-out and failure, and send service reminders and warnings.
The new term 'intelligent body network' refers to equipping sensors and actuators of the vehicle body electronics with the intelligence required to exploit them in an optimum way. Sharing data over networks is critical for implementing an intelligent body network, because it allows every system to optimise its function using that data.
| Tel: | +27 11 923 9600 |
| Email: | [email protected] |
| www: | www.altronarrow.com |
| Articles: | More information and articles about Altron Arrow |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version