AMI-C 3003 IDB 1394 Specificationspds12.egloos.com/pds/200812/13/51/Automotive... · fer video or...

AMI-C 3003-3

AMI-C

1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) v1.00

2003-05-12

AMI-C

2 AMI-C 3003-3 2000-05-12

LEGAL DISCLAIMER THE FOLLOWING AMI-C SPECIFICATIONS ARE COPYRIGHTED. BY PUB-LISHING THESE AMI-C SPECIFICATIONS, AMI-C IS NOT GRANTING BY IMPLICATION, ESTOPPEL, OR OTHERWISE, ANY LICENSES OR RIGHTS UNDER ANY PATENTS, COPYRIGHTS, TRADE SECRETS, TRADEMARKS OR ANY OTHER INTANGIBLE RIGHTS (“INTELLECTUAL PROPERTY”) THAT AMI-C HAS OR MAY ACQUIRE RELATING TO THE DEVELOPMENT, MANUFACTURE, USE, SALE, OFFER FOR SALE, IMPORT, COPYING, DIS-TRIBUTION OR EXPLOITATION OF PRODUCTS, SYSTEMS OR SERVICES THAT ARE BASED ON OR COMPLIANT WITH THESE AMI-C SPECIFICA-TIONS. AMI-C HAS A POLICY OF LICENSING ITS INTELLECTUAL PROP-ERTY RIGHTS ON A NON-DISCRIMINATORY BASIS TO ANY ENTITY HAV-ING A NEED FOR SUCH RIGHTS THROUGH THE AMI-C STANDARD LI-CENSE AGREEMENT. ANY USE OR IMPLEMENTATION OF THE AMI-C SPECIFICATIONS REQUIRES EXECUTION OF THE AMI-C STANDARD LI-CENSE AGREEMENT. THE AMI-C SPECIFICATIONS ARE PROVIDED “AS-IS”. AMI-C EXPRESSLY DISCLAIMS ANY IMPLIED WARRANTIES OF ANY KIND, INCLUDING WITH-OUT LIMITATION, ANY WARRANTY OF QUALITY, PERFORMANCE, MER-CHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. AMI-C DOES NOT WARRANT, GUARANTEE OR MAKE REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE AMI-C SPECIFICATIONS OR ANY OTHER MATERIALS IN TERMS OF ACCURACY, CORRECTNESS, RELIABILITY, OR OTHERWISE. AMI-C ALSO MAKES NO REPRESENTATIONS OR WARRANTIES AS TO: (A) THE VALIDITY OR SCOPE OF ANY INTELLECTUAL PROPERTY THAT MAY BE EMBODIED IN THESE AMI-C SPECIFICATIONS; (B) INFRINGE-MENT OF ANY PATENT OR COPYRIGHT BY THE AMI-C SPECIFICATIONS OR THEIR USE; (C) WHETHER THE AMI-C SPECIFICATION MAY BE LE-GALLY USED IN ALL COUNTRIES THROUGHOUT THE WORLD. NOTIFI-CATIONS MADE TO AMI-C CONCERNING INTELLECTUAL PROPERTY RIGHT ASSERTIONS ARE LISTED AT www.ami-c.org. TO THE EXTENT TRADEMARKS, BRAND AND/OR PRODUCT NAMES AP-PEAR IN THE AMI-C SPECIFICATIONS, THEY ARE THE SOLE PROPERTY OF THEIR RESPECTIVE OWNERS. ALL RIGHTS RESERVED. Copyright AMI-C 2003

http://www.ami-c.org/

AMI-C

AMI-C 3003-3 3 2003-05-12

Trademarks cited in this document Any trademarks, registered trademarks, or service marks used in this document are the property of their respective owners and are hereby recognized. Name Phrase i.Link® i.Link is a registered trademark of the Sony Electronics, Inc. Linux® Linux® is a registered trademark of Linus Torvalds Red Hat Red Hat is a trademark of Red Hat Inc. Visual C++® Visual C++ is a trademark of Microsoft Corporation Win32 Win32 is a trademark of Microsoft Corporation Windows® Windows is a trademark of Microsoft Corporation

AMI-C

4 AMI-C 3003-3 2000-05-12

Revision log NOTE – Refer to the public document section of www.ami-c.org for most cur-rent baseline and revision. Document no. 3003-2

Version no. 1.00

Version date: 2003-05-12

Document title AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) Revision date Affected sections 2003-05-12 Version 1.00 released for publication. This version is the basis for all

future revisions.

http://www.ami-c.org/

AMI-C

AMI-C 3003-3 5 2003-05-12

Contents Foreword ............................................................................................................ 7 Introduction......................................................................................................... 8 1 Scope....................................................................................................... 10 2 References............................................................................................... 10 2.1 Normative references............................................................................. 10 2.2 Informative references ........................................................................... 11 3 Terms and definitions............................................................................... 11 3.1 Requirement and recommendation language ........................................ 11 3.2 Definitions .............................................................................................. 11 4 Descriptions of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3)............................................................................................. 11 4.1 Overview................................................................................................ 11 4.2 Components of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) ................................................................... 13 4.2.1 Vehicle Interface (VI).......................................................................... 13 4.2.2 AV controller....................................................................................... 15 4.2.3 Vehicle Device Emulator (VDE).......................................................... 16 4.2.4 Vehicle Device Controller (VDC) ........................................................ 17 4.2.5 CD & MD changers ............................................................................ 20 4.2.6 Audio processor ................................................................................. 20 4.2.7 Media converter.................................................................................. 21 4.2.8 1394 repeaters ................................................................................... 21 4.2.9 1394 POF cables................................................................................ 21 4.2.10 DV camcorder .................................................................................... 21 4.2.11 DV video monitor................................................................................ 21 4.3 Data format ............................................................................................ 22 4.3.1 Command data................................................................................... 22 4.3.2 Streaming Data .................................................................................. 22 4.4 Message mapping.................................................................................. 22 4.4.1 AV message mapping ........................................................................ 22 4.4.2 Vehicle Message Mapping ................................................................. 31 4.5 Sequence examples .............................................................................. 32 4.5.1 Connection sequence......................................................................... 33 4.5.2 Windows (Get) sequence ................................................................... 33 4.5.3 Initialization sequence ........................................................................ 34 5 Guidelines and recommendations............................................................ 35 Annex A Requirement and recommendation language................................. 38 A.1 Requirements ........................................................................................ 38 A.2 Recommendations ................................................................................. 38 Annex B Request for change form ................................................................ 39

AMI-C

6 AMI-C 3003-3 2000-05-12

Figures Figure 1 — AMI-C 1394 Automotive proof-of-concept implementation............ 12 Figure 2 — The hardware layout of AMI-C 1394 Automotive .......................... 13 Figure 3 — The graphical user interface for the AV controller ......................... 16 Figure 4 — The vehicle device emulator interface........................................... 17 Figure 5 — Main window of vehicle device controller ...................................... 19 Figure 6 — Door Lock GUI .............................................................................. 19 Figure 7 — Window GUI.................................................................................. 20 Figure 8 — Parking Light GUI.......................................................................... 20 Figure 9 — Mapping of Track Information (Set)............................................... 24 Figure 10 — Mapping of Track Information (Confirm) ..................................... 25 Figure 11 — Mapping of Window (Set)............................................................ 32 Figure 12 — Sequence chart of connection..................................................... 33 Figure 13 — Windows (Get) sequence............................................................ 34 Figure 14 — Initialization sequence................................................................. 35 Tables Table 1 — Command Data .............................................................................. 22 Table 2 — Streaming Data .............................................................................. 22 Table 3 — AMI-C Function Type – 1394 AV/C Subunit Type .......................... 26 Table 4 — AMI-C Message Type – 1394 AV/C Command Type..................... 26 Table 5 — AMI-C Message Type – 1394 AV/C Response .............................. 26 Table 6 — AMI-C Amplifier Error Codes – 1394 AV/C Response Codes ........ 27 Table 7 — AMI-C General Player Error Codes – 1394 AV/C Response Codes

................................................................................................................. 27 Table 8 — AMI-C Disk Media Error Codes – 1394 AV/C Response Codes .... 27 Table 9 — AMI-C Management Message........................................................ 28 Table 10 — Connection Management ............................................................. 28 Table 11 — Amplifier Messages...................................................................... 28 Table 12 — General Player Messages............................................................ 29 Table 13 — Disk Media Message.................................................................... 30 Table 14 — Tape Media Message................................................................... 30 Table 15 — Disk Information Attribute............................................................. 31 Table 16 — Play Time Information Attribute .................................................... 31

AMI-C

AMI-C 3003-3 7 2003-05-12

Foreword The Automotive Multimedia Interface Collaboration, Inc. (AMI-C) is a non-profit corporation of worldwide motor vehicle manufacturers. It was established to facilitate the development, promotion and standardization of automotive infor-mation and entertainment interfaces to motor vehicle communication networks. AMI-C has motor vehicle manufacturers as Members and has automotive com-ponent manufacturers, consumer electronics manufacturers, software firms, telematics service companies, and telematics technology companies as Con-tributing Organizations. AMI-C produces a set AMI-C Technical Documents (requirement, specification and reference documents) concerning automotive information and entertainment interfaces. An AMI-C requirement document defines the requirements of one or more inter-faces for one or more elements in the AMI-C architecture. It may not have technical details for implementation. An AMI-C specification document defines the interfaces of an element in the AMI-C architecture with sufficient technical details for successful implementations. An AMI-C reference document helps users of AMI-C requirement documents and AMI-C specification documents understand them. The AMI-C Technical Documents are prepared by the AMI-C technical teams of subject matter experts from AMI-C Members and Contributing Organizations. These documents are approved for publication by the AMI-C Program Man-agement Committee. In preparing its publications, AMI-C adapts the drafting convention of the ISO/IEC Directive, Part 2, Rules for the structure and drafting of international standards, fourth edition, 2001, for its document format. In October 2000, AMI-C released a series documents to the public. Those documents, collectively known as AMI-C Release 1 documents, served as the foundation for the continuation of AMI-C document development and provided ways for identifying and resolving discrepancies and deficiencies in early AMI-C document development. However, they were not “build-to” specifications. The AMI-C documents of the current release are the definitive source by which AMI-C compliant components are to be designed and constructed. The future AMI-C publications will reflect the continuous improvements and expansion of the body of AMI-C documentation to match upgrades to existing technologies, evolving market demands, and emerging technologies in the evolution of infor-mation and entertainment systems in motor vehicles. The AMI-C document release will be administered by AMI-C using an AMI-C document version management system.

AMI-C

8 AMI-C 3003-3 2000-05-12

Introduction The IEEE 1394 network technology enables simple, high-bandwidth isochro-nous (real-time) data interfacing among computers, peripherals, and consumer electronics products such as camcorders, VCRs, printers, PCs, TVs, and digital cameras. With IEEE 1394-compatible products and systems, users can trans-fer video or still images from a camera or camcorder to a printer, PC, or televi-sion, with no image degradation. AMI-C adopts 1394 audio/video messages for 1394 Automotive networks and addresses technical issues related to 1394 Automotive specification (physical layer). The AMI-C 1394 Automotive proof-of-concept implementation demonstrates how IEEE-1394 high-speed network technology is seamlessly integrated not only with audio/video entertainment information for consumer electronics but also with control/data signals for vehicle-specific information. The AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) document describes the first 3 steps in AMI-C’s 7-step approach to 1394 Automotive proof-of-concept implementation. It is an informative document. AMI-C has divided its efforts in the 1394 Automotive proof-of-concept imple-mentation into the following seven steps: Step 1: To test AV/C commands to control audio and video devices on AMI-C network protocol requirements for vehicle interface access in an emulated vehi-cle environment. In this phase, audio or video stream data is transported through analog line, and not transported as isochronous data over 1394 net-work. Step 2: To test audio and digital video (DV) streaming transported as isochro-nous data over 1394 network in an emulated vehicle environment. The audio stream is transported between an audio player, such as CD player or MD player and an amplifier with speakers. The DV stream is transported between a DV camcorder and a DV monitor. Step 3: To test the Vehicle Interface Protocol (VIP) with emulated vehicle ser-vices. The VIP was developed by AMI-C based on AMI-C network protocol re-quirements for vehicle interface access. The VIP provides a way for integrating 1394 Automotive network with emulated vehicle services. Step 4: To test MPEG2 video streaming for DVD movies in an emulated vehicle environment. The video stream is transported as isochronous data over a 1394 network between a DVD player and a DVD monitor. Copy protection functions, such as DTCP (Digital Transmission Content Protection), are not included in this phase.

AMI-C

AMI-C 3003-3 9 2003-05-12

Step 5: To test power management in an emulated vehicle environment. The power management protocol is to control power state (e.g. active, sleep, off) of each device. Basic protocol and procedure for the power management are de-fined in IDB-1394. Step 6: To integrate steps 4 and 5 above. Step 7: To integrate steps 1 through 6. There are three key objectives for AMI-C to develop its 1394 Automotive proof-of-concept implementation (step 1, 2, and 3): 1. To verity the Vehicle Interface Protocol (VIP) developed by AMI-C for 1394 Automotive networks. 2. To verify that A/VC commands specified by 1394 Trade Association for MD player, CD player, audio processor, and DV camera work in vehicle environment. 3. To verify that data stream for CD player, MD player, and DV camera works in vehi-cle environment. In the first 3 steps, AMI-C used audio, video and vehicle messages from the AMI-C Common Message Set through an emulated AMI-C vehicle services in-terface. With this proof-of-concept implementation, AMI-C validated its Vehicle Interface Protocol (VIP) for 1394 specification and tested interoperability of some 1394 enabled audio/video devices. Based on the findings from the tests, AMI-C made specific recommendations to 1394 TA to improve interoperability of 1394 audio/video devices.

AMI-C

10 AMI-C 3003-3 2000-05-12

1 Scope This document covers information related to the first 3 steps in the 7-step AMI-C 1394 Automotive proof-of-concept implementation. The information is pre-sented in the following areas: An overview of the proof-of-concept implementation (steps 1, 2 and 3) cov-

ering the purposes, the architecture and the hardware layout of the imple-mentation.

The components involved in the proof-of-concept implementation (steps 1, 2, and 3) including requirements on it, the functions supported, the devel-opment environment, the system setup, and the software components.

The data format used in the proof-of-concept implementation for both command data and streaming dada

The message mapping for AV/C commands and vehicle messages Some sequence example are then presented Finally, AMI-C guidelines and recommendations based on the learning from

the proof-of-concept implementation were presented. AMI-C has a plan to demonstrate and test the elements of 1394 Automotive re-lated to DVD applications, the system power management, and the Consumer Convenience Port (CCP) with the AMI-C proof-of-concept implementation. The related information will be made available at a later time.

2 References The following documents form a part of the specification to the extent specified herein. In the event of a conflict between the text of this specification and the documents cited herein, the text of this specification takes precedence.

2.1 Normative references AMI-C 2001, AMI-C network protocol requirements for vehicle interface access,

v1.00 AMI-C 2002, AMI-C Common Message Set, v1.01 AMI-C 3003, AMI-C requirements and guidelines for 1394 Automotive net-

works, v1.00 AV/C Disc Subunit General Specification, Ver. 1.0, January 26, 1999. AV/C Disc Media Type Specification – CD - DA. Ver. 1.0, January 26, 1999. AV/C Information Block Types Specification Version 1.0, July 23, 2001. AV/C Digital Interface Command Set General Specification Version 4.0, July

23, 2001. AV/C Tape Recorder/Player Subunit Specification, Ver. 2.1, January 26, 1999. AV/C Audio Subunit Specification 1.0, October 24, 2000. AV/C Descriptor Mechanism Specification Version 1.0, July 23, 2001. AV/C Disc Media Type Specification – MD Audio, Version 1.0, January 26,

1999.

AMI-C

AMI-C 3003-3 11 2003-05-12

IEC61883-1, Consumer audio/video equipment – Digital Interface Part1, 1998-02.

2.2 Informative references None

3 Terms and definitions 3.1 Requirement and recommendation language Annex A provides guidance on verbal expressions used throughout this docu-ment that are indicative of requirements and recommendations.

3.2 Definitions

3.2.1 1394 Automotive an automotive version of IEEE 1394 network technology

3.2.2 isochornous data data that arrive at the destination at the same rate that they leave the source. The word “isochronous” means “equal time”. Isochronous data are used for streaming video and audio data.

3.2.3 MD mini-disk

3.2.4 POF plastic optic fiber

4 Descriptions of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3)

4.1 Overview By October 2002, AMI-C finished the first 3 steps of its 1394 Automotive proof-of-concept implementation. The purpose of the implementation is multifold:

1. To validate AV/C commands to control AV devices over AMI-C network protocol requirements for vehicle interface access

2. To validate the Vehicle Interface Protocol (VIP) specification that AMI-C developed for 1394 Automotive networks

3. To test the validity of AMI-C Common Message Set 4. To validate Audio/Video stream control and management

AMI-C

12 AMI-C 3003-3 2000-05-12

5. To test the validity of physical components In essence, the AMI-C 1394 Automotive proof-of-concept implementation was to demonstrate how the IEEE 1394 technology could be used with vehicle en-tertainment. The AMI-C 1394 Automotive proof-of-concept implementation employed a Ve-hicle Interface (VI), audio/video devices, a AV controller with a user interface, a Vehicle Device Controller (VDC) with a user interface, a Vehicle Device Emula-tor (VDE), 1394 POF’s, and 1394 repeaters from different manufacturers. Figure 1 is an architecture schematic of the AMI-C 1394 Automotive proof-of-concept implementation. The implementations of DVD and CCP have not been completed at the time of this publication. The current level of the AMI-C 1394 Automotive proof-of-concept implementation contains the following modules:

1. Vehicle Interface (VI) 2. AV controller 3. Vehicle Device Emulator (VDE) 4. Vehicle Device Controller (VDC) 5. CD changer 6. MD changer 7. Audio processor 8. DV camcorder 9. DV video monitor

Figure 1 — AMI-C 1394 Automotive proof-of-concept implementation

architecture schematic

Automaker Domain

AV Controller

Automaker’s Proprietary Network Emulation

CDC

MDC

DV Camcorder

Display

13

94

Door Lock

Antenna

Window

Parking Light

Vehicle Speed

Vehicle Interface

Vehicle Device Controller

DVD

CCP

Vehicle Device Emulator

AMI-C Domain

To Consumer Electric Devices

AMI-C

AMI-C 3003-3 13 2003-05-12

Figure 2 shows the hardware layout of the current level proof-of-concept im-plementation. Details of the hardware are in the sections that follow.

Figure 2 — The hardware layout of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3)

4.2 Components of AMI-C 1394 Automotive proof-of-concept implemen-tation (steps 1, 2, and 3)

4.2.1 Vehicle Interface (VI) The VI, developed by Sumitomo Electric Industries, Ltd. (Sumitomo), is the em-bedded platform including gateway functionality, which is able to handle the message exchange between AMI-C 1394 messages for audio and vehicle in-formation and automaker’s proprietary network messages. The implementation is adapted using Sumitomo’s original protocol as an automaker’s proprietary protocol. In the proof-of-concept implementation, AMI-C Common Message Set (CMS) is used between the AV Controller and the VI. The VI converts AV/C commands to AMI-C CMS or vice versa.

Media Converter

NTSC

Repeater

1394 Metal

DV Camcorder

Repeater

AV/C MessagesAV Stream 1394 Metal

1394 POF

Vehicle Device Emulator

AV Controller

AV Message

Vehicle Message

Automaker’s Proprietary Network

Vehicle Interface

CD Changer

1394 Metal

Vehicle Device Controller

Speakers

Power Amplifier Audio Processor

Analog Audio

1394 Metal

1394 Metal

DV Video Monitor

RS

232C

RS 232C

MD Changer

AMI-C

14 AMI-C 3003-3 2000-05-12

On the other hand, AMI-C Vehicle Interface Protocol (VIP) is employed be-tween the Vehicle Device Controller (VDC) and the VI, and Sumitomo’s original messages are employed between the Vehicle Device Emulator (VDE) and the VI. The VI converts the AMI-C VIP messages to Sumitomo’s original messages. The VI contains 1394 LINK and PHY chips with microprocessor. It has metal 1394.a ports and RS 232C interfaces. The AV Controller and the VDE on a PC are connected to the VI with RS 232C cables, which represent an automaker’s proprietary network. A metal 1394.a cable connects the VI and a 1394.b/a repeater, which opens up the AMI-C net-work for AMI-C devices.

4.2.1.1 Control messages in VI The following messages are implemented in the VI:

1. Audio/Video Control functions 1.1. Complete IEEE 1394 connection setup

1.1.1. Allocate Channel 1.1.2. Deallocate Channel 1.1.3. Connect Source 1.1.4. Disconnect Source 1.1.5. Connect Sink 1.1.6. Disconnect Sink

1.2. CD/MD changer control

1.2.1. Play 1.2.2. Stop 1.2.3. Track Control (Up/Down) 1.2.4. Pause 1.2.5. Disk Information 1.2.6. Track Information 1.2.7. Play Time Information

1.3. Amplifier control

1.3.1. Sound Volume Control (Up/Down) 1.3.2. Bass Control (On/Off) 1.3.3. Mute Control (On/Off)

1.4. DV camcorder control

1.4.1. Play 1.4.2. Stop 1.4.3. Fast Forward 1.4.4. Fast Backward

AMI-C

AMI-C 3003-3 15 2003-05-12

2. Vehicle device control functions 2.1. ARP (Address Resolution Protocol)

2.1.1. ARP Request 2.1.2. ARP Response

2.2. Initialization messages

2.2.1. RM Inquiry 2.2.2. RM Response 2.2.3. I-Num Request 2.2.4. I-Num Response 2.2.5. I-Num Unallocation 2.2.6. Suspected RM Failure Warning 2.2.7. Reset I-Num Request

2.3. Management messages

2.3.1. Release version number 2.3.2. Node Information Announcement 2.3.3. Vehicle Configuration Service 2.3.4. Current Time and Date 2.3.5. General Service Information

2.4. Vehicle information

2.4.1. Vehicle Identification Number 2.4.2. Manufacture Information 2.4.3. Vehicle Description

2.5. Vehicle device control

2.5.1. Window control 2.5.2. Door Lock control 2.5.3. Antenna control 2.5.4. Vehicle Speed information 2.5.5. Parking Light control

4.2.1.2 Development environment for VI The VI was developed under the following environment:

OS ITRON Driver Developed by Sumitomo Electric Indus-

tries, Ltd. (Sumitomo) 1394 stack Developed by Sumitomo Port Connector RS-232C 9 pin

IEEE 1394.a 6 pin

4.2.2 AV controller The AV controller developed by Sumitomo is the application software on PC that allows the user to control the AV devices through the VI. It sends the AMI-C CMS to the VI for the conversion to AV/C commands, and receives the AMI-

AMI-C

16 AMI-C 3003-3 2000-05-12

C CMS from the VI, in which AV/C commands are translated into the AMI-C CMS. The AV Controller is connected to the VI with a RS 232C cable, which repre-sents the automaker’s proprietary network.

4.2.2.1 Development environment for AV controller The AV controller was developed under the following environment:

OS Windows 98 SE Application Win32 (built on Visual C++ 6.0) Port Connector RS-232C 9 pin

4.2.2.2 User interface The Graphical User Interface (GUI) of AV controller is shown in Figure 3 below. The right window shows the AMI-C Common Message Set (CMS) running be-tween the AV controller and the VI.

Figure 3 — The graphical user interface for the AV controller

4.2.3 Vehicle Device Emulator (VDE) The VDE, developed by Sumitomo, is the application software that emulates the devices in the vehicle. The emulator is connected to the VI with a RS 232C cable. A simple transport protocol, which is composed of a header and a message length with the vehicle information, is employed over RS232C between the VDE and the VI.

AMI-C

AMI-C 3003-3 17 2003-05-12

4.2.3.1 Development environment for VDE The VDE was developed under the following environment:

OS Windows 98 SE Application Win32 (built on Visual C++ 6.0) Port Connector RS-232C 9 pin

4.2.3.2 User interface The vehicle device emulator interface (Figure 4) shows the current condition of the vehicle. The left window shows the AMI-C CMS received by the VDE.

Figure 4 — The vehicle device emulator interface

4.2.4 Vehicle Device Controller (VDC) The Vehicle Device Controller (VDC), which is developed by Wipro Technolo-gies (Wipro), is the application software, which controls the vehicle devices emulated in the VDE. It sends AMI-C VIP messages to the VI for vehicle de-vice controls, and receives the AMI-C VIP message responses from the VI.

AMI-C

18 AMI-C 3003-3 2000-05-12

A metal 1394.a cable connects the VDC and VI with/without repeaters in be-tween. In this particular implementation, two 1394.b/a repeaters are set up be-tween the VDC and VI.

4.2.4.1 Development environment for VDC The VDC was developed under the following environment:

OS Red Hat Linux Ver. 7.2 Driver Developed by Wipro Technologies 1394 stack Developed by Wipro Technologies Application Developed by Wipro Technologies Port Connector IEEE 1394.a 4 pin

4.2.4.2 User interface A child window for a particular vehicle device pops up when a device function is chosen from the combo box and “OK” button is pressed in the main window. Figure 5 shows the main window of the vehicle device controller. If the confir-mation of a message is needed, the “Set Confirmation bit” button is pressed and the button text changes to ”Clear Confirmation bit”. Pressing the button once more changes the text back to “Set Confirmation bit”, clears the confirma-tion bit and confirmations for messages are stopped. If the confirmation is no longer needed after setting the confirmation bit, the “Set Confirmation bit“ but-ton is pressed once more.

AMI-C

AMI-C 3003-3 19 2003-05-12

Figure 5 — Main window of vehicle device controller

Figures 6 to 8 show the controller GUIs (child windows) of Door Lock, Window, and Parking Light.

Figure 6 — Door Lock GUI

AMI-C

20 AMI-C 3003-3 2000-05-12

Figure 7 — Window GUI

Figure 8 — Parking Light GUI

4.2.5 CD & MD changers The CD/MD changers with the IEEE 1394 interface were developed by Alpine Electronics, Inc. (Alpine), for the interoperability test of the proof-of-concept im-plementation. The CD/MD changers that support AV/C Disc Subunit command set are con-nected to a 1394.a port of a 1394.b/a repeater. The AV controller controls the CD/MD changer, and the CD/MD charger sends audio data to an audio proces-sor to generate sound. The audio data transfers as isochronous stream data (IEC 61883-6).

4.2.6 Audio processor The audio processor with an IEEE 1394 interface was developed by Alpine for the interoperability test of the proof-of-concept implementation.

AMI-C

AMI-C 3003-3 21 2003-05-12

An audio processor is a unit that supports the AV/C Audio Subunit command set. It consists of an amplifier and speakers. Sound data are transported from the CD/MD changer as 1394 isochronous stream data (IEC 61883-6), and transported to the amplifier from its analog line.

4.2.7 Media converter A media converter developed by Sumitomo was used for the proof-of-concept implementation with the IEEE 1394 interface. It receives data in DV format from the DV camcorder and converts the data to NTSC format for DV video monitor.

4.2.8 1394 repeaters Sumitomo and Yazaki Corporation (Yazaki) provided the IEEE 1394 repeaters for the proof-of-concept implementation. Data from one port are transported to other ports. A 1394.b port of a repeater is connected to the 1394.b port of another repeater. A 1394.a port is connected to audio/video devices, or a device controller. The 1394 repeater from Sumitomo has two optical 1394.b ports and one con-ventional 1394.a port. The 1394 repeater from Yazaki has one optical 1394.b port and two conventional 1394.a ports.

4.2.9 1394 POF cables Sumitomo and Yazaki provided the POF cables for the proof-of-concept imple-mentation. A data link between 1394.b/a repeaters is to transport 1394.b signals. The maximum transport rate is at least S100 (125Mbps). The specification is de-scribed in 1394 TA document 1394 Automotive (IDB-1394).

4.2.10 DV camcorder The DV camcorder (SONY TRV-20) with the IEEE 1394 interface (i.Link) was used for the interoperability test of proof-of-concept implementation. A general conventional DV camcorder that supports i.Link (IEEE 1394-1995) and Tape Subunit command set is connected to 1394.a port of a 1394.b/a re-peater. An AV controller controls a DV camcorder, and video stream data (DV format IEC 61883-2) runs from the camcorder to media converter.

4.2.11 DV video monitor A DV video monitor was used for the proof-of-concept implementation with the IEEE 1394 interface. It receives the NTSC format video data from the media converter.

AMI-C

22 AMI-C 3003-3 2000-05-12

4.3 Data format There are two kinds of data running in the system, command data and stream-ing data. The command data is the data that carries the message to control devices. The streaming data is the data that carries audio and/or video infor-mation.

4.3.1 Command data There are four kinds of command data running in the system. Table 1 shows the list of command data used in the proof-of-concept implementation.

Table 1 — Command Data

Connection Data Format AV Controller – VI AV related CMS VDC – VI VIP VI – VDE Simple transport protocol VI – CD/MD Player or Audio Processor AV/C VI – DV Camcorder AV/C

4.3.2 Streaming Data There are four kinds of streaming data running in the system. Table 2 shows the list of streaming data format used in the proof-of-concept implementation.

Table 2 — Streaming Data

Connection Data Format Audio Processor – CD/MD Changer A&M (IEC 61883-6) Audio Processor – Power Amplifier Analog Audio DV camcorder – Media Converter DV (IEC 61883-2) Media Converter – DV Video Monitor NTSC

4.4 Message mapping The proof-of-concept implementation includes two kinds of devices to be con-trolled. One is AV device such as CD changer or DV camcorder. The other is vehicle device such as window or door lock. In order the devices are properly controlled from the different network, the message mapping is done in the VI. AMI-C Common Message Set (CMS) is mapped to or from AV/C command for AV devices, while AMI-C Vehicle Interface Protocol (VIP) is mapped to or from Sumitomo’s original protocol representing the automaker’s proprietary protocol in the proof-of-concept implementation. The sections 4.4.1 and 4.4.2 explain how the mapping is done in details.

4.4.1 AV message mapping When AMI-C application frame format is mapped to IEEE 1394 AV/C frame format, the Destination Function Type (F-Type) and Destination Instance Num-ber (I-Num) in application frame are mapped to Network Adaptation Registry Table. The node ID and Subunit type is found out from the registry table and

AMI-C

AMI-C 3003-3 23 2003-05-12

mapped to Destination Node ID and Subunit Type in AV/C frame respectively. MType is mapped to Ctype. The mapping of Track Information (Set) is shown in Figure 9 of the next page. The example is particularly showing the mapping of Search Track No. 3. When IEEE 1394 AV/C frame format is mapped to AMI-C application frame format, the Source Node ID in AV/C frame is mapped to Network Adaptation Registry Table to find out its Function Type and Instance Number. The Func-tion Type and Instance Number are then mapped to Source F-Type and Source I-Num in application frame. The Ctype is mapped to MType. The Figure 10 shows the Track Information (Confirm). The example is particularly showing the mapping of Search Track No. 3 Confirm. The following sections from 4.4.1.1 to 4.4.1.5 show the cross-reference be-tween AMI-C CMS and 1394 messages used in the proof-of-concept implemen-tation.

AMI-C

24 AMI-C 3003-3 2000-05-12

Figure 9 — Mapping of Track Information (Set)

Message Body Length0000-0010-10

Transaction ID0000-0001

Multi-frame Sequence ID0000-0000

Message Class0100-0001

Object Property0000-0111

Operand[1]0000-0000

Operand[2]0000-0000

S0

M0

Rsv00

Pri00

Reserved0000

C1

Mtype010

Application frame formatApplication frame format

Network Adaptation Registry TableNetwork Adaptation Registry Table

Destination Node ID1111-1111-1100-0010

tcode0001

Pri0000

tl0000-10

Rt00

Source Node ID1111-1111-1100-1011

Destination Address (High)1111-1111-1111-1111

Destination Address (Low)1111-0000-0000-0000-0000-1011-0000-0000

Data Length0000-0000-0000-1011

Extended tcode0000-0000-0000-0000

CTS0000

Ctype0000

Subunit Type0001-1

Subunit ID000

Opecode0101-0000

Operand[0]1111-1111

Operand[1]0000-0001

Operand[2]0000-0000

Operand[3]0000-0000

Operand[4]0000-0000

IEEE 1394 AV/C frame for-mat IEEE 1394 AV/C frame for-mat

Destination F-Type0101-0001

Destination I-Num1000-0010

Source F-Type1001-0010

Source I-Num 1000-0110

Operand[0]0000-0011

Function Type Instance Number Node ID Subunit type

51H 82H 02H 03HReg[12]92H 86H 0BHReg[16]

Operand[5]0000-0001

Operand[6]0000-0000

Operand[7]0000-0011

AMI-C

AMI-C 3003-3 25 2003-05-12

Figure 10 — Mapping of Track Information (Confirm)






S0

M0

Rsv00

Pri00

Reserved0000

C0

Mtype011




tcode0001

Pri0000

tl0000-10

Rt00

Source Node ID1111-1111-1100-0010



Data Length0000-0000-0000-1011

Extended tcode0000-0000-0000-0000

CTS0000

Ctype1001

Subunit Type0001-1

Subunit ID000

Opecode0101-0000

Operand[0]0000-0000

Operand[1]0000-0001

Operand[2]0000-0000

Operand[3]0000-0000

Operand[4]0000-0000

IEEE 1394 AV/C frame for-mat IEEE 1394 AV/C frame for-mat





Operand[0]0000-0000


51H 82H 02H 03HReg[12]92H 86H 0BHReg[16]

Operand[5]0000-0001

Operand[6]0000-0000

Operand[7]0000-0011

AMI-C

26 AMI-C 3003-3 2000-05-12

4.4.1.1 AMI-C Function Type – AV/C Subunit Type cross-reference The correspondence of the AMI-C Function Type and 1394 AV/C Subunit Type is listed in Table 3 below.

Table 3 — AMI-C Function Type – 1394 AV/C Subunit Type

AMI-C Function Type 1394 AV/C Subunit Type CD (50H) Disc (03H)

- Media type 101H (Descriptor) MD (51H) Disc (03H)

- Media type 301H (Descriptor) Amplifier (6FH) Audio (01H) VCR (56H) Tape recorder/Player (04H) Monitor (5AH) Tape recorder/Player (04H)

- 1394 – NTSC media converter

4.4.1.2 AMI-C Message Type – AV/C Command Type Cross-Reference Table 4 shows the correspondence of AMI-C Message Type and 1394 AV/C Command Type.

Table 4 — AMI-C Message Type – 1394 AV/C Command Type

AMI-C Message Type 1394 AV/C Command Type Inquire (000B) Status (01H) Set (010B) Control (00H) Command (100B) Control (00H) Report (001B) Status (01H) Confirm (011B) no mapping Warning (101B) no mapping

4.4.1.3 AMI-C Message Type – AV/C Response Cross-Reference Table 5 shows the correspondence of AMI-C Message Type and 1394 AV/C Response. More details about Confirm AMI-C Message Type are described in the next section below.

Table 5 — AMI-C Message Type – 1394 AV/C Response

AMI-C Message Type 1394 AV/C Response Inquire (000B) no mapping Set (010B) no mapping Command (100B) no mapping Report (001B) no mapping Confirm (011B) See Table 6 - 8 below Warning (101B) no mapping

4.4.1.4 AMI-C Error Codes – AV/C Response Cross-Reference Table 6 shows the correspondence of AMI-C Amplifier Confirm Error Codes and AV/C Response Codes

AMI-C

AMI-C 3003-3 27 2003-05-12

Table 6 — AMI-C Amplifier Error Codes – 1394 AV/C Response Codes

AMI-C Error Code 1394 AV/C Response noError (00H) Accepted (09H)

Implemented/Stable (0CH) unspecifiedError (01H) Rejected (0AH)

In Transition (0BH) Changed (0DH)

notSupported (02H) Not Implemented (08H) Table 7 shows the correspondence of AMI-C General Player Confirm Error Codes and AV/C Response Codes

Table 7 — AMI-C General Player Error Codes – 1394 AV/C Response Codes




notSupported (02H) Not Implemented (08H) noMedia (03H) No mapping unreadableMedia (04H) No mapping

Table 8 shows the correspondence of AMI-C Disk Media Confirm Error Codes and AV/C Response Codes

Table 8 — AMI-C Disk Media Error Codes – 1394 AV/C Response Codes




notSupported (02H) Not Implemented (08H) noMedia (03H) No mapping unreadableMedia (04H) No mapping

4.4.1.5 AMI-C – AV/C Command cross-reference The list below shows the references referred in this section: [1] AV/C Disc Subunit General Specification, Ver. 1.0, January 26, 1999 [2] AV/C Disc Media Type Specification – CD - DA. Ver. 1.0, January 26, 1999 [3] AV/C Information Block Types Specification Version 1.0, July 23, 2001 [4] AV/C Digital Interface Command Set General Specification Version 4.0, July 23, 2001 [5] AV/C Tape Recorder/Player Subunit Specification, Ver. 2.1, January 26, 1999 [6] AV/C Audio Subunit Specification 1.0, October 24, 2000 [7] AV/C Descriptor Mechanism Specification Version 1.0, July 23, 2001 [8] AV/C Disc Media Type Specification – MD Audio, Version 1.0, January 26, 1999 [9] AMI-C 2002, AMI-C Common Message Set [10] IEC61883-1, Consumer audio/video equipment – Digital Interface Part1, 1998-02

AMI-C

28 AMI-C 3003-3 2000-05-12

The following tables in this section use the square brackets listed above to indi-cate cross-references Table 9 below lists the AMI-C Management Message.

Table 9 — AMI-C Management Message

AMI-C commands AV/C Command AV/C Reference [9] Connect Source [4] Output Plug Signal

Format [1] Associate List with Plug

[4] 12.11.2 Output Plug Signal Format status command [1] 10.4 Associate List with Plug, subfunc-tion_1=01H(set a specified list/plug association), list_id=1001H(Audio Child con-tents list)

[9] Connect Sink [4] Input Plug Signal Format

[4] 12.10.2 Input Plug Signal Format status command

Table 10 lists the mapping of [9] CMS and [10] IEC61883-1 for connection management.

Table 10 — Connection Management

AMI-C commands IEC61883-1 Plugs and plug control register [9] Allocate Chan-nel

Allocate channel (CHANNELS_AVAILABLE, BANDWIDTH_AVAILABLE)

[9] Deallocate Channel

Deallocate channel (CHANNELS_AVAILABLE, BANDWIDTH_AVAILABLE)

[9] Connect Source

Set allocate channel in oPCR, Set oPCR data rate and overhead-ID, Set oPCR connection counter

[9] Disconnect Source

Decrement connection counter in oPCR

[9] Connect Sink Set allocate channel in iPCR, Set iPCR connection counter [9] Disconnect Sink

Decrement connection counter in iPCR

Table 11 is the cross-reference of AMI-C Amplifier messages and IEEE 1394 AV/C commands.

Table 11 — Amplifier Messages

AMI-C commands AV/C Command AV/C Reference [9] Codec [9] Volume [6] Function Block [6] 10.3.2 Volume Control,

function_block_type = 81H (feature function block), audio_channel_number = 00H (master), control_selector = 02H (Volume Control)

[9] Mute [6] Function Block [6] 10.3.1 Mute Control, function_block_type = 81H (feature function block), audio_channel_number = 00H (master), control_selector = 01H (Mute Control)

[9] Fade [9] Balance [9] Chime [9] Treble [9] Midrange [9] Bass [6] Function Block [6] 10.3.5 Bass Control,

AMI-C

AMI-C 3003-3 29 2003-05-12

function_block_type = 81H (feature function block), audio_channel_number = 00H (master), control_selector = 0BH (Bass Control)

[9] Restore Equal-izer

[9] Register Equal-izer

[9] Clear Equalizer Table 12 is the cross-reference of AMI-C General Player messages and IEEE 1394 AV/C commands.

Table 12 — General Player Messages

AMI-C commands AV/C Command AV/C Reference [9] Current Player State

[1] Stop [1] 10.22 Stop [9] Stop [5] Wind [5] 4.30 Wind, subfunction=60H(Stop) [1] Configure [1] Play

[1] 10.7 Configure, Subfunction_1 = 01H (set a specified configuration), plug_configuration = 8808H (playback order info block), playback_order = 00H (In order), repeat_mode = 10b (play an entire list), track_boundary_operation = 00b (no special operation at the track boundary) [1] 10.17 Play, subfunction_1 = 75H (forward)

[9] Play

[5] Play [5] 4.15 Play, playback_mode = 75H (forward) [9] Pause [1] Play [1] 10.17 Play, subfuntion_1 = 7DH (forward pause) [9] Fast Forward [5] Wind [5] 4.30 Wind, subfunction = 75H (fast forward) [9] Rewind [5] Wind [5] 4.30 Wind, subfunction = 65H (rewind) [9] Track Up [1] Search [1] 10.21 Search, subfunction_1 = 01H (absolute unit),

measurement_unit = 00H (track boundary) [9] Track Down to the Current

[9] Track Down to the Previous

[1] Search [1] 10.21 Search, subfunction_1 = 01H (absolute unit), measurement_unit = 00H (track boundary)

[9] Eject [9] Subscribing Status

[9] Subscribe Data [7] Open Descriptor [7] Read Descriptor [7] Open Descriptor

[7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 01H (read open) [7] 9.5 Read Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), See Table 15. [7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 00H (close open)

AMI-C

30 AMI-C 3003-3 2000-05-12

[9] Unsubscribe Data

Table 13 is the cross-reference of AMI-C Disk Media messages and IEEE 1394 AV/C commands.

Table 13 — Disk Media Message

AMI-C commands AV/C Command AV/C Reference [9] Repeat Track [9] Repeat Disk [9] Random In Disk [9] Random In Magazine

[9] Magazine Infor-mation

[9] Disk Information [7] Open Descriptor [7] Read Descriptor [7] Open Descriptor

[7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 01H (read open) [7] 9.5 Read Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), See Table 15 [7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 00H (close open)

[9] Track Informa-tion (only Set)

[1] Search [1] 10.21 Search, subfunction_1 = 10H (relative unit), measurement_unit = 00H (track boundary)

[9] Play Time Infor-mation

[7] Open Descriptor [7] Read Descriptor [7] Open Descriptor

[7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 01H (read open) [7] 9.5 Read Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), See Table 16 [7] 9.4 Open Descriptor, descriptor_specifier_type = 80H (status descriptor), reference_method_specific = 00H (full descriptor), subfunction = 00H (close open)

Table 14 is the cross-reference of AMI-C Tape Media messages and IEEE 1394 AV/C commands.

Table 14 — Tape Media Message

AMI-C com-mands AV/C Command AV/C Reference

[9] Tape Property [9] Time Counter [9] Tape Direction

AMI-C

AMI-C 3003-3 31 2003-05-12

Table 15 is the cross-reference of AMI-C Disk Information Attribute and IEEE 1394 AV/C commands.

Table 15 — Disk Information Attribute

AMI-C commands AV/C Command AV/C Reference [9] CurrentDisk-Number

[9] DiskType info blocks [1] Table 6-7 supported_media_type field [9] DiskTitle [9] DiskArtist [9] DiskGenre [9] NumOfTrack info blocks [3] 4.14 Number of Items Info Block of [8] Table 8-8

number_of_items_info_block [9] totalDiskTime Table 16 is the cross-reference of AMI-C Play Time Attribute and IEEE 1394 AV/C commands.

Table 16 — Play Time Information Attribute

AMI-C com-mands AV/C Command AV/C Reference

[9] CurrentTrack-Number

info blocks [3] 4.3 Position Indicator Info Block of [1] Table 7-16 plug_status_info_block

[9] CurrentRela-tiveTime

info blocks [3] 4.3 Position Indicator Info Block of [1] Table 7-16 plug_status_info_block

[9] CurrentAbsDisk-Time

4.4.2 Vehicle Message Mapping The Destination F-Type and Destination I-Num in AMI-C frame are mapped to Network Adaptation Registry Table. The node ID is found out from the registry table and mapped to Destination Node ID in IEEE-1394 frame. The whole ap-plication frame is mapped to the part of FCP (Function Control Protocol) frame. Figure 11 shows how the mapping of Window (Set) is done. In this particular case the driver side window is opened halfway (80H).

AMI-C

32 AMI-C 3003-3 2000-05-12

Figure 11 — Mapping of Window (Set)

4.5 Sequence examples In this section, several sequence examples are shown in order to see the mes-sage exchanges between devices visually.







S0

M0

Rsv00

Pri00

Reserved0000

C1

Mtype010





Operand[0]1000-0000



13H 02H 0BHReg[12]94H 80H 00HReg[16]


tcode0001

Pri0000

tl0000-10

Rt00

Source Node ID1111-1111-1100-0000

Data Length0000-0000-0001-0000

Extended tcode0000-0000-0000-0000

IDBIDB--1394 frame format 1394 frame format

CTS(0100b)

ACC(0000b) Reserved








S0

M0

Rsv00

Pri00

Reserved0000

C1

Mtype010





Operand[0]1000-0000

AMI-C

AMI-C 3003-3 33 2003-05-12

4.5.1 Connection sequence In order for the CD or MD changer to establish the audio connection with an audio processor, the AV controller sends CMS commands to the VI and VI sends AV/C commands to the CD or MD changer and audio processor. Figure 12 shows the sequence of the connection establishment.

Figure 12 — Sequence chart of connection

4.5.2 Windows (Get) sequence The Vehicle Device Controller (VDC) sends the VIP message to Vehicle Inter-face (VI) in which the VIP message is translated to the automaker’s proprietary message. The VI sends the corresponding automaker’s proprietary message to the Vehicle Device Emulator in order to control the vehicle device emulated in the PC. Figure 13 shows the sequence example in which the VDC requests for the status of the window.

Vehicle Interface

CD or MD Changer

Allocate Channel (Cmd)

Allocate Channel (Cnf)

Output Plug Signal Format

Connect Source (Cmd)

Associate List with Plug

Connect Source (Cnf)

Connect Sink (Cmd)

Input Plug Signal Format

Connect Sink (Cnf)

CMS AV/C

AV Con-troller

Audio Processor

AMI-C

34 AMI-C 3003-3 2000-05-12

Figure 13 — Windows (Get) sequence

4.5.3 Initialization sequence During the initialization of the VI, although the VI issues RM Inquiry and Node Information Announcement, the VDC ignores the message. At the same time the VI does not respond the ARP Request from the VDC. The sequence de-scribed above is shown in Figure 14.

Vehicle Interface

Vehicle Device

Emulator

Windows (Inquire)

OEM Proprietary

Windows (Receive)

OEM Proprietary

OEM Proprietary

Vehicle Device

Controller

VIP

AMI-C

AMI-C 3003-3 35 2003-05-12

VI VDC

Bus Reset

ARP Request

InitializedNot

Initialized

Initialized

no response

RM Inquiry

ARP Request (retry)

no response

ARP Request (retry)

ARP Response

Vehicle Initialization

Node Information Announcement

ignore

ignore

no response

ARP Request (retry)

Figure 14 — Initialization sequence

5 Guidelines and recommendations AMI-C tested the following aspects in the AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3):

a. IEEE 1394 audio device interoperability with a prototype CD changer, an MD changer, and an audio amplifier

b. IEEE 1394 video device interoperability with a commercially avail-able DV camcorder

c. IDB1394 vehicle device interoperability with an emulator

AMI-C

36 AMI-C 3003-3 2000-05-12

d. IEEE 1394 physical components connectivity with prototype re-peaters

The following lists show the implementation decisions made by AMI-C for the purpose of this proof-of-concept implementation only. These decisions had to be made due to the insufficient information from the 1394 Automotive specifica-tions for interoperable implementations. AMI-C considers these decisions as guidelines to help developers build a similar system. AMI-C also proposes these implementation guidelines as recommendations to 1394 TA for 1394 Automotive specification refinements.

Audio/Video device control 1. When the VI is powered on, AV/C devices ignore the broadcast mes-

sage (CTS = 0100B; Automotive message). 2. Interruptions from navigation and telephone are ignored. 3. The LR balance is set to neutral, and the sound volume is set to the

minimum when the audio devices are powered on. 4. Only the current track information is provided. 5. The usage of descriptor is temporally settled. 6. When Unit is on and Subunit is off, the status request is valid but the

control command is invalid. 7. The sound volume unit is used with db. The maximum value is 0 and

the minimum value is –∞. 8. The first form of Volume Control is used for the Audio Subunit Function

Block Command parameter. 9. Boot-up is cold start every time. 10. When the system power is turned on, the sound volume is set to 10 in

AMI-C value. 11. The “Retry” is done after confirming power command with CTYPE ==

STATUS. 12. A delay is provided for command retry from VI. 13. When the VI is powered on, a “Link-on” packet to all nodes is issued. 14. Changing track is done by search_type = relative. 15. The process of getting track information is done when a device is se-

lected (during connect). Vehicle device control 1. The VDC sends ARP request every 3 seconds during the initialization

of the VI. 2. The pre-assigned I-Num (‘80H’) is used for the VDC. 3. The VDC follows P1212 specification for the ConfigROM implementa-

tion. 4. The VI does not support any power management. 5. The VI does not respond to a message sent to an unavailable module. 6. The VI becomes the root node.

AMI-C

AMI-C 3003-3 37 2003-05-12

7. The ARP information kept in each node is cleared after a network re-set.

8. The FCP Packet Frame (COMMAND) is used for VIP INQUIRE, VIP SET, VIP COMMAND, and VIP WARNING.

9. The FCP Packet Frame (RESPONSE) is used for VIP REPORT, and VIP CONFIRM.

10. The System Transaction Frame (COMMAND) is used for RM Inquiry, I-Num Request, ARP Request, Suspected RM Failure Warning, and Reset I-Num Request.

11. The System Transaction Frame (RESPONSE) is used for RM Re-sponse, I-Num Response, and ARP Response.

12. The value of Message Length in the Application Transaction Frame Format does not include CTS, ACC, Reserved, Message Length, Sys, Rsv, Pri, More, Transaction ID, Multi-frame Sequence ID fields nor Zero Pad Bytes.

AMI-C

38 AMI-C 3003-3 2000-05-12

Annex A Requirement and recommendation language A.1 Requirements The following verbal forms are indicative of requirements that are to be followed in order to achieve conformance to this specification. No deviation is permitted from a requirement. Verbal Form Equivalent Expressions Shall, Must, Will Is to

Is required to It is required that Has to Only … is permitted It is necessary

Shall Not, Will Not Is not allowed [permitted] [acceptable] [permissible]

A.2 Recommendations The following verbal forms are indicative of recommendations or courses of ac-tion that are preferred, but are not necessarily required. Verbal Form Equivalent Expressions Should It is recommended that

Ought to Should Not It is not recommended that May Is permitted

Is allowed Is permissible

May Not Need not It is not required that No … is required

Can Be able to There is a possibility of It is possible to

Cannot Be unable to There is no possibility of It is not possible to

AMI-C

AMI-C 3003-3 39 2003-05-12

Annex B Request for change form Use this form to identify errors or deficiencies or to recommend general changes. Document no.

Version no.

Version date

Document title

Requestor Information Name:

Organization:

E-Mail:

Phone:

Description of Change: Rational for Change: Proposed Revision: Affected Sections: E-mail to: Don Ingersoll AMI-C Vice President [email protected]

Mail to: Don Ingersoll AMI-C Vice President 280 Enterprise Drive Bloomfield Hills, MI USA 48302-0312

Fax to: Don Ingersoll AMI-C Vice President +1 248.322.5976

AMI-C 3003 IDB 1394 Specificationspds12.egloos.com/pds/200812/13/51/Automotive... · fer video or...

Documents

Transcript of AMI-C 3003 IDB 1394 Specificationspds12.egloos.com/pds/200812/13/51/Automotive... · fer video or...