Some of us retreat to our vehicles and enjoy alittle quiet time; others are road warriors,

multitasking in the car while driving from oneappointment to the next. For drivers at both endsof the spectrum, increasing connectivity in thecar by adopting multimedia standards has thepotential to improve their desired driving expe-rience. For instance, classical music lovers couldunwind on the commute by listening to theirfavorite MP3s downloaded to the car stereo froma music service. The traveling salesman could eas-ily and safely launch hands-free phone calls fromhis electronic organizer’s contact list. The soccermom could choose from a variety of rear-seatentertainment options like videos and games tooccupy the attention of her back-seat passengers.

For a variety of reasons, vehicles have laggedbehind home and mobile computing deviceswhen it comes to productivity and multimediatools. Safety, durability, cost, and design timehave all factored into auto manufacturers’delayed acceptance of the new technology.

One of the greatest hindrances to aftermarketdevices reaching the vehicle has been the diffi-culty of installation, caused by a lack of standardvehicle interfaces. The best example in today’smarket is the cell phone hands-free kit. Despiterepeated warnings about the dangers of usinghandheld cell phones while driving, only a smallpercentage of drivers frequently use a hands-freekit, which can be integrated with the vehicle’sexisting audio system. Complexity and cost ofinstallation limits the rate of hands-free kit adop-tion. However, implementation of a gatewaystandard greatly simplifies the installationprocess and could enable the industry to changethe way electronics enter the vehicle.

Translating messaging protocols between theproprietary vehicle network and consumer elec-tronics networks, the gateway standard makes itso auto manufacturers don’t need to standardize

their proprietary vehicle networks—a dauntingtask. Likewise, this gateway approach preventsconsumer electronics manufacturers from need-ing to support every proprietary vehicle network,also a challenging task. While even the decisionon what messaging protocols a gateway shouldsupport requires debate, auto manufacturers arelooking for new ways to differentiate their prod-uct in an increasingly crowded marketplace, andmultimedia standards are among the solutionsbeing championed.

Enter the standardsOrganizations such as the Automotive Multi-

media Interface Collaboration (AMI-C) have anopportunity to be the driving force behind stan-dardization efforts. AMI-C is a three-year-oldeffort to develop a common set of device-independent interface standards between multi-media devices and the automobile. AMI-C is aglobal organization of vehicle manufacturerswhose members produce the majority of theworld’s vehicles each year. Numerous technolo-gy companies and suppliers support the organi-zation. These supporters contribute theirtechnical expertise to help AMI-C achieve con-sensus on common core requirements for mobileinformation and entertainment systems. Initial-ly the effort included all the major manufactur-ers of cars, but in 2001 Volkswagen, BMW, andDaimlerChrysler pulled out to pursue their ownset of standards more quickly.

Released in 2001, AMI-C specification v1.0 con-tains a physical layer specification, a messagingprotocol based on the intelligent-transportation-systems data bus-CAN (IDB-C) specification, anduse cases for many potential client connections toa vehicle. Release 2.0 is just now rolling out as wego to print. Several documents will be available asthe year’s first quarter progresses, including appli-cation programming interface specifications.

76 1070-986X/03/$17.00 © 2003 IEEE Published by the IEEE Computer Society

Standards Editor: Peiya LiuSiemens Corporate Research

Lori Guglielmetti

Standardizing AutomotiveMultimedia Interfaces

The significant advantage of the AMI-C phys-ical layer and protocol standards is the flexibilityof the completed system. Devices like mobilephones, video game units, video playbackdevices, and multimedia computers can all inter-act with the vehicle subsystem for the cost of theAMI-C interface. While work remains, AMI-C hassolved many of the auto-specific issues regardingconnectors, cabling, and protocols. This letsdevice manufacturers focus more time on designcycles and product development.

The AMI-C standard specification is currentlyavailable, but there haven’t yet been press releas-es heralding AMI-C compatible devices. As withany new proposed standard, a critical mass ofsupporters and adopters must embrace the stan-dard in product implementations. It must be inthe interest of both the automaker and the devicemanufacturer to invest in the cost of standardiz-ing their equipment to the specifications. Somedevice manufacturers are faced with the toughquestion of which comes first, the standardizedinterface in the vehicle or the consumer demandfor that interface—spawned by widespread avail-ability in common consumer devices.

So, automakers and consumer electronicsmanufacturers continue to evaluate the potentialcosts and benefits to AMI-C implementation.While work continues to modernize AMI-C inrelease 2.0, AMI-C, like all standards, is likely toage quickly if implementation is delayed. As mul-timedia devices change protocols and bus speeds,AMI-C could become less relevant if adoptiondoesn’t occur.

The specificationThe AMI-C specification proposes the use of a

gateway device installed in the vehicle, whichserves as a translator between numerous poten-tial communication protocols. IDB-C is thenative, low-speed messaging protocol, whichAMI-C is using to develop its vehicle message setat the application layer. It’s used in conjunctionwith the low-impedance stereo audio (LISA) bus,the AMI-C native analog audio standard. TheIDB-C message set passes parameters such asvehicle power state, current audio settings, andaudio setting change requests between the vehi-cle and other networked devices. Once the net-worked devices gain access to the vehicle audiosystem, the LISA implementation transfers audiodata between the networked devices.

The model shown in Figure 1 is one possibleimplementation of a combination of vehicle inter-

faces. In Figure 1, the open IDB-C specificationinterfaces devices such as a cell phone to the vehi-cle electronics. While IDB-C has had almost noadoption, Bluetooth has caught on in the con-sumer market for these types of functions. This isbecause the companies in the consumer electron-ics industry have persevered in continually bring-ing down the cost and complexity of Bluetooth toa more acceptable level for the consumer.

The current AMI-C specification releasedefines in great detail the low bandwidth andwired IDB-C protocol and LISA standard, butleaves several high-speed and wireless data pro-tocols for others to define. This is part of theAMI-C strategy to adopt existing standards, whenavailable, rather than define new ones. AMI-Cspecifically provides details regarding integrationwith two high-speed networks—Media OrientedSystems Transport (MOST) and IEEE-1394—andhas specifically approved MOST for integrationwith the AMI-C standard. The MOST standardemerged when the three European auto manu-facturers mentioned previously dropped out ofAMI-C because of their preference for a more lim-ited in-scope, high-bandwidth fiber-based net-work. Several European manufacturers areimplementing MOST as an internal vehicle net-work, as well as considering it as a potential com-mon standard. This differentiates MOST fromIDB-C, as IDB-C is currently only defined as agateway protocol between the vehicle and exter-nal devices.

The other contender for a high-speed vehicleinterface bus is IEEE-1394. Popularized in multi-media computer applications, IEEE-1394 hasgained momentum in the consumer electronicsspace, and has the widest acceptance in that mar-ket. However, the addition of IEEE-1394 or anynew high-speed protocols will increase the costof the gateway that will provide translationbetween the high-speed protocol and the propri-etary vehicle network.

A wireless communication protocol specifica-tion is also not defined in the AMI-C standard.

77

Ap

ril–June 2003

Camcorder

Cellphone

GatewayVehicle

IDB-C

LISA

IEEE-1394

Vehicleproprietary

Figure 1. Possible

vehicle interfaces.

The AMI-C documentation refers users who wanta wireless interface with the vehicle to the Blue-tooth protocol. The AMI-C approach here is toleverage the knowledge of the mobile consumerelectronics industry and approve an existing pro-tocol, like Bluetooth, for integration with theAMI-C standards. AMI-C release 2.0 will includeperformance and design specifications for Blue-tooth networks.

What it means to the driverComparing today’s vehicle to a vehicle

equipped with an open standard like AMI-C andimplemented with a consumer-friendly bus likeIEEE-1394, is similar to comparing a proprietaryMacintosh computer to an open-architectureWintel computer. And just like in the computerindustry, if vehicle networks were open to third-party developers, a huge hurdle in the develop-ment of vehicle-friendly hardware and softwarewould be pushed aside.

Common use cases would be cell phone dock-ing and MP3 playback. However, an industrycould be built around potential new use casessuch as location-aware services, including navi-gation, traffic, travel logs, and advertising. Third-

party software applications would help toincrease the variety of applications available.

In each use case, the principle hardwarewould be the gateway. By translating from theconsumer electronics friendly networking stan-dard to the vehicle-accepted network, the gate-way would enable synergy in both devices, asFigure 2 shows.

Future activitiesIn an effort keep the AMI-C specifications cur-

rent, the AMI-C organization has already estab-lished a timeline for release 3.0 content. AMI-Cis currently considering the addition of morefunctionality to address concerns about recoup-ing gateway cost. These additions would likelyinclude support of financial transactions andreprioritizing use cases.

To promote its upcoming development andtesting phase, AMI-C recently launched a solici-tation for contributing organizations to partici-pate in actual development work. Selectedparticipants will work directly with experts fromvehicle manufacturers and suppliers to developand test specifications for automotive multime-dia and telematics products.

In addition, AMI-C is currently developing adetailed IEEE-1394 interface. The eventualapproval of IEEE-1394 could help provide a poolof network-aware consumer electronics withwhich vehicles could interface. MM

For further information, readers may contact Sensoria Cor-

poration at 15950 Bernardo Center Dr., Suite J, San Diego,

CA 92127, http://www.sensoria.com.

Contact Standards editor Peiya Liu, Siemens Corporate

Research, 755 College Road East, Princeton, NJ 08540,

email Peiya.Liu@scr.siemens.com.

78

IEEE

Mul

tiM

edia

Standards

End user EnterpriseWireless LANSensoriaTelematicsServer Suite

Third party application providers (location, navigation, real-time traffic, music download, diagnostics)Cellular WAN

Broadcast

Sensoria gateway andTelematics Client Platform

Figure 2. The gateway

as a network

translator.

Further InformationVisit the following Web sites for further

information.

❚ Automotive Multimedia Interface Collabora-tion and the 2.0 specification: http://www.ami-c.org

❚ Media Oriented Systems Transport system:http://www.mostnet.de

❚ IEEE-1394: http://www.standards.ieee.org

❚ Gateway software and hardware solutions:http://www.sensoria.com