With a design cycle that is much longer for cars than for electronics, and with the electronic content of automobiles increasing each model year, major automakers-General Motors, Ford, Chrysler, Toyota, Nissan, Honda and the like-have conceded they have a design-cycle problem.
Currently, last year's electronics-car stereos, global positioning systems, navigation systems and car computers-won't appear in an automobile until model year 2002. That means vehicle makers have to guess what devices will be desirable three to five years in advance. And they worry about installing electronic devices with higher costs and lower feature content than will be available in the near future.
A consortium of leading automotive companies hopes to shorten the design cycle for cars by defining the industry's first set of interface standards for automotive information, communications and entertainment systems. Borrowing a page from the information-technology industry, the Automotive Multimedia Interface Collaboration (AMIC) and the Telematics Suppliers Consortium are trying to create a set of open, standard hardware interfaces-as well as programming interfaces for application software. The intelligent transportation systems (ITS) data bus (IDB) will ideally provide a universal backplane for swapping electronics equipment in new-generation automotive systems.
To fully realize the benefits of intelligent transportation systems, many new electronics devices will be added to vehicles. These include communications devices, computing devices, navigation and positioning devices. It is hoped that software and hardware vendors will use the IDB and other standard interfaces to create products they sell directly to the consumer. Consumers can then add those products to their automotive systems at any time during the system's life cycle.
Although auto manufacturers are indeed using multiplex buses, there remain a number of problems. For a variety of reasons, auto companies have hesitated to adopt a single standard. As a result, electronic-device manufacturers must design and build multiple versions of their products to attach to the various buses, and that raises the cost to consumers. Furthermore, a device connected to the auto's multiplex bus must be qualified through the normal design cycle of the auto, which does not allow unplanned-for electronics to be added by the manufacturer, the dealer or the customer. Certainly for safety, warranty and liability reasons, electronic devices must not be allowed to interfere in any way with the operation of the auto or of any of its subsystems, so they cannot be retrofitted to the auto's multiplex bus.
A dual-bus architecture is proposed, in which an ITS data bus is connected to the auto's multiplex bus through a gateway. That would allow electronic-device manufacturers to build a single, automotive version of their product that plugs into the IDB on any auto. In addition, the IDB would be independent of all auto systems, except for dc power, eliminating the need for a full electrical bench qualification. The gateway, under the control of the auto company, would act as a firewall, allowing only authorized message traffic to pass between the auto's multiplex bus and the IDB's devices, ensuring safe operation of all vehicle systems.
In spite of that restriction, the IDB would enable a wide variety of applications in the vehicle. For example, the bus could process message traffic for wireless Internet access, remote vehicle diagnostics, security/authentication codes for e-commerce or read diagnostic information from vehicle computers, sensors or air bags.
The Society of Automotive Engineers (SAE) IDB Committee has thus far agreed upon a number of features for devices to operate "plug-and-play." First, devices must operate peer to peer. Second, IDB devices must be able to talk to each other even if the IDB is not connected to a car via a gateway. They must have a low incremental cost per node-preferably below $1. Devices in the bus must be self-configuring. With no fixed device addresses, the dealer for the consumer must be able to equip new modules easily with no "programming." Devices should be easily movable from vehicle to vehicle.
The IDB is designed primarily for control oriented -functions. In order to be economical as well as robust, the date rate will be no more than 250 kbits/s. Future plans call for a higher-speed bus designed to handle multimedia applications in the vehicle. Tentatively called IDB-Multimedia (IDBM), this bus will transport digititized audio and video. There must be some mechanism for guaranteed message delivery when required by the application. A priority-sensitive flow is recommended.
Finally, unshielded twisted pair is required to keep costs and complexity down-a challenge due to the noisy environment. And all devices must meet automotive physical and electrical specifications.