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

Transcription

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

2 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 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 AMI-C

3 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 i.link Linux Red Hat Visual C++ Win32 Windows Phrase i.link is a registered trademark of the Sony Electronics, Inc. Linux is a registered trademark of Linus Torvalds Red Hat is a trademark of Red Hat Inc. Visual C++ is a trademark of Microsoft Corporation Win32 is a trademark of Microsoft Corporation Windows is a trademark of Microsoft Corporation AMI-C

4 Revision log NOTE Refer to the public document section of for most current baseline and revision. Document no Version no Version date: Document title AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) Revision date Affected sections Version 1.00 released for publication. This version is the basis for all future revisions. 4 AMI-C

5 Contents Foreword... 7 Introduction Scope References Normative references Informative references Terms and definitions Requirement and recommendation language Definitions Descriptions of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) Overview Components of AMI-C 1394 Automotive proof-of-concept implementation (steps 1, 2, and 3) Vehicle Interface (VI) AV controller Vehicle Device Emulator (VDE) Vehicle Device Controller (VDC) CD & MD changers Audio processor Media converter repeaters POF cables DV camcorder DV video monitor Data format Command data Streaming Data Message mapping AV message mapping Vehicle Message Mapping Sequence examples Connection sequence Windows (Get) sequence Initialization sequence Guidelines and recommendations Annex A Requirement and recommendation language A.1 Requirements A.2 Recommendations Annex B Request for change form AMI-C

6 Figures Figure 1 AMI-C 1394 Automotive proof-of-concept implementation Figure 2 The hardware layout of AMI-C 1394 Automotive Figure 3 The graphical user interface for the AV controller Figure 4 The vehicle device emulator interface Figure 5 Main window of vehicle device controller Figure 6 Door Lock GUI Figure 7 Window GUI Figure 8 Parking Light GUI Figure 9 Mapping of Track Information (Set) Figure 10 Mapping of Track Information (Confirm) Figure 11 Mapping of Window (Set) Figure 12 Sequence chart of connection Figure 13 Windows (Get) sequence Figure 14 Initialization sequence Tables Table 1 Command Data Table 2 Streaming Data Table 3 AMI-C Function Type 1394 AV/C Subunit Type Table 4 AMI-C Message Type 1394 AV/C Command Type Table 5 AMI-C Message Type 1394 AV/C Response Table 6 AMI-C Amplifier Error Codes 1394 AV/C Response Codes Table 7 AMI-C General Player Error Codes 1394 AV/C Response Codes Table 8 AMI-C Disk Media Error Codes 1394 AV/C Response Codes Table 9 AMI-C Management Message Table 10 Connection Management Table 11 Amplifier Messages Table 12 General Player Messages Table 13 Disk Media Message Table 14 Tape Media Message Table 15 Disk Information Attribute Table 16 Play Time Information Attribute AMI-C

7 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 information and entertainment interfaces to motor vehicle communication networks. AMI-C has motor vehicle manufacturers as Members and has automotive component manufacturers, consumer electronics manufacturers, software firms, telematics service companies, and telematics technology companies as Contributing 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 interfaces 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 Management 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 information 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 Introduction The IEEE 1394 network technology enables simple, high-bandwidth isochronous (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 transfer video or still images from a camera or camcorder to a printer, PC, or television, 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 implementation 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 vehicle environment. In this phase, audio or video stream data is transported through analog line, and not transported as isochronous data over 1394 network. Step 2: To test audio and digital video (DV) streaming transported as isochronous 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 services. The VIP was developed by AMI-C based on AMI-C network protocol requirements 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. 8 AMI-C

9 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 defined in IDB 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 proofof-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 vehicle 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 interface. 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 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 presented in the following areas: An overview of the proof-of-concept implementation (steps 1, 2 and 3) covering the purposes, the architecture and the hardware layout of the implementation. The components involved in the proof-of-concept implementation (steps 1, 2, and 3) including requirements on it, the functions supported, the development 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 related 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 networks, v1.00 AV/C Disc Subunit General Specification, Ver. 1.0, January 26, AV/C Disc Media Type Specification CD - DA. Ver. 1.0, January 26, AV/C Information Block Types Specification Version 1.0, July 23, AV/C Digital Interface Command Set General Specification Version 4.0, July 23, AV/C Tape Recorder/Player Subunit Specification, Ver. 2.1, January 26, AV/C Audio Subunit Specification 1.0, October 24, AV/C Descriptor Mechanism Specification Version 1.0, July 23, AV/C Disc Media Type Specification MD Audio, Version 1.0, January 26, AMI-C

11 IEC , Consumer audio/video equipment Digital Interface Part1, Informative references None 3 Terms and definitions 3.1 Requirement and recommendation language Annex A provides guidance on verbal expressions used throughout this document that are indicative of requirements and recommendations. 3.2 Definitions Automotive an automotive version of IEEE 1394 network technology 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 MD mini-disk POF plastic optic fiber 4 Descriptions of AMI-C 1394 Automotive proof-ofconcept implementation (steps 1, 2, and 3) 4.1 Overview By October 2002, AMI-C finished the first 3 steps of its 1394 Automotive proofof-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 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 entertainment. The AMI-C 1394 Automotive proof-of-concept implementation employed a Vehicle Interface (VI), audio/video devices, a AV controller with a user interface, a Vehicle Device Controller (VDC) with a user interface, a Vehicle Device Emulator (VDE), 1394 POF s, and 1394 repeaters from different manufacturers. Figure 1 is an architecture schematic of the AMI-C 1394 Automotive proof-ofconcept 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 Automaker Domain AMI-C Domain Vehicle Speed Parking Light Door Lock Vehicle Device Emulator Automaker s Proprietary Network Emulation Vehicle Interface 1394 Display CDC MDC DV Camcorder Window Vehicle Device Controller Antenna AV Controller DVD CCP To Consumer Electric Devices Figure 1 AMI-C 1394 Automotive proof-of-concept implementation architecture schematic 12 AMI-C

13 AMI-C Figure 2 shows the hardware layout of the current level proof-of-concept implementation. Details of the hardware are in the sections that follow. DV Video Monitor Vehicle Device Controller DV Camcorder AV/C Messages AV Stream NTSC 1394 Metal 1394 Metal Media Converter Repeater Automaker s Proprietary Network 1394 Metal 1394 POF Repeater 1394 Metal MD Changer AV Message Vehicle Interface RS 232C 1394 Metal RS 232C CD Changer AV Controller Vehicle Message Analog Audio Speakers Vehicle Device Emulator Power Amplifier Audio Processor 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 implementation (steps 1, 2, and 3) Vehicle Interface (VI) The VI, developed by Sumitomo Electric Industries, Ltd. (Sumitomo), is the embedded platform including gateway functionality, which is able to handle the message exchange between AMI-C 1394 messages for audio and vehicle information 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. AMI-C

14 On the other hand, AMI-C Vehicle Interface Protocol (VIP) is employed between 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 network for AMI-C devices Control messages in VI The following messages are implemented in the VI: 1. Audio/Video Control functions 1.1. Complete IEEE 1394 connection setup Allocate Channel Deallocate Channel Connect Source Disconnect Source Connect Sink Disconnect Sink 1.2. CD/MD changer control Play Stop Track Control (Up/Down) Pause Disk Information Track Information Play Time Information 1.3. Amplifier control Sound Volume Control (Up/Down) Bass Control (On/Off) Mute Control (On/Off) 1.4. DV camcorder control Play Stop Fast Forward Fast Backward 14 AMI-C

15 2. Vehicle device control functions 2.1. ARP (Address Resolution Protocol) ARP Request ARP Response 2.2. Initialization messages RM Inquiry RM Response I-Num Request I-Num Response I-Num Unallocation Suspected RM Failure Warning Reset I-Num Request 2.3. Management messages Release version number Node Information Announcement Vehicle Configuration Service Current Time and Date General Service Information 2.4. Vehicle information Vehicle Identification Number Manufacture Information Vehicle Description 2.5. Vehicle device control Window control Door Lock control Antenna control Vehicle Speed information Parking Light control Development environment for VI The VI was developed under the following environment: OS ITRON Driver Developed by Sumitomo Electric Industries, Ltd. (Sumitomo) 1394 stack Developed by Sumitomo Port Connector RS-232C 9 pin IEEE 1394.a 6 pin 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 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 represents the automaker s proprietary network 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 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 between the AV controller and the VI. Figure 3 The graphical user interface for the AV controller 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. 16 AMI-C

17 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 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 Vehicle Device Controller (VDC) The Vehicle Device Controller (VDC), which is developed by Wipro Technologies (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 device controls, and receives the AMI-C VIP message responses from the VI. AMI-C

18 A metal 1394.a cable connects the VDC and VI with/without repeaters in between. In this particular implementation, two 1394.b/a repeaters are set up between the VDC and VI 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 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 confirmation 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 confirmation bit and confirmations for messages are stopped. If the confirmation is no longer needed after setting the confirmation bit, the Set Confirmation bit button is pressed once more. 18 AMI-C

19 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 Figure 7 Window GUI Figure 8 Parking Light GUI 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 implementation. The CD/MD changers that support AV/C Disc Subunit command set are connected 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 processor to generate sound. The audio data transfers as isochronous stream data (IEC ) Audio processor The audio processor with an IEEE 1394 interface was developed by Alpine for the interoperability test of the proof-of-concept implementation. 20 AMI-C

21 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 ), and transported to the amplifier from its analog line 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 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 conventional 1394.a port. The 1394 repeater from Yazaki has one optical 1394.b port and two conventional 1394.a ports POF cables Sumitomo and Yazaki provided the POF cables for the proof-of-concept implementation. 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 described in 1394 TA document 1394 Automotive (IDB-1394) 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 ) and Tape Subunit command set is connected to 1394.a port of a 1394.b/a repeater. An AV controller controls a DV camcorder, and video stream data (DV format IEC ) runs from the camcorder to media converter 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 4.3 Data format There are two kinds of data running in the system, command data and streaming 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 information 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 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 ) Audio Processor Power Amplifier Analog Audio DV camcorder Media Converter DV (IEC ) Media Converter DV Video Monitor NTSC 4.4 Message mapping The proof-of-concept implementation includes two kinds of devices to be controlled. 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 and explain how the mapping is done in details 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 Number (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 22 AMI-C

23 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 Function 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 to show the cross-reference between AMI-C CMS and 1394 messages used in the proof-of-concept implementation. AMI-C

24 Application frame format Message Body Length S 0 Rsv 00 Pri 00 M 0 Transaction ID Multi-frame Sequence ID Destination F-Type Destination I-Num Source F-Type Source I-Num Reserved 0000 C 1 Mtype 010 Message Class Object Property Operand[0] Operand[1] Operand[2] Network Adaptation Registry Table Function Type Instance Number Node ID Subunit type Reg[12] Reg[16] 51H 82H 02H 03H 92H 86H 0BH Destination Node ID Source Node ID IEEE 1394 AV/C frame format tl Rt 00 tcode 0001 Destination Address (High) Pri 0000 Destination Address (Low) Data Length Extended tcode CTS 0000 Ctype 0000 Subunit Type Subunit ID 000 Opecode Operand[0] Operand[1] Operand[2] Operand[3] Operand[4] Operand[5] Operand[6] Operand[7] Figure 9 Mapping of Track Information (Set) 24 AMI-C

25 Application frame format Message Body Length S 0 Rsv 00 Pri 00 M 0 Transaction ID Multi-frame Sequence ID Destination F-Type Destination I-Num Source F-Type Source I-Num Reserved 0000 C 0 Mtype 011 Message Class Object Property Operand[0] Network Adaptation Registry Table Function Type Instance Number Node ID Subunit type Reg[12] Reg[16] 51H 82H 02H 03H 92H 86H 0BH Destination Node ID Source Node ID IEEE 1394 AV/C frame format tl Rt 00 tcode 0001 Destination Address (High) Pri 0000 Destination Address (Low) Data Length Extended tcode CTS 0000 Ctype 1001 Subunit Type Subunit ID 000 Opecode Operand[0] Operand[1] Operand[2] Operand[3] Operand[4] Operand[5] Operand[6] Operand[7] Figure 10 Mapping of Track Information (Confirm) AMI-C

26 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 CD (50H) MD (51H) Amplifier (6FH) VCR (56H) Monitor (5AH) 1394 AV/C Subunit Type Disc (03H) - Media type 101H (Descriptor) Disc (03H) - Media type 301H (Descriptor) Audio (01H) Tape recorder/player (04H) Tape recorder/player (04H) NTSC media converter 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 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 Inquire (000B) Set (010B) Command (100B) Report (001B) Confirm (011B) Warning (101B) 1394 AV/C Response no mapping no mapping no mapping no mapping See Table 6-8 below no mapping 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 26 AMI-C

27 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 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) 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 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) nomedia (03H) No mapping unreadablemedia (04H) No mapping 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] IEC , Consumer audio/video equipment Digital Interface Part1, AMI-C

28 The following tables in this section use the square brackets listed above to indicate cross-references Table 9 below lists the AMI-C Management Message. Table 9 AMI-C Management Message [9] Connect Sink [4] Input Plug Signal Format AMI-C commands AV/C Command AV/C Reference [9] Connect Source [4] Output Plug Signal [4] Output Plug Signal Format status command Format [1] 10.4 Associate List with Plug, subfunction_1=01h(set a specified [1] Associate List with Plug list/plug association), list_id=1001h(audio Child contents list) [4] Input Plug Signal Format status command Table 10 lists the mapping of [9] CMS and [10] IEC for connection management. Table 10 Connection Management AMI-C commands IEC Plugs and plug control register [9] Allocate Channel Allocate channel (CHANNELS_AVAILABLE, BANDWIDTH_AVAILABLE) [9] Deallocate Deallocate channel (CHANNELS_AVAILABLE, BANDWIDTH_AVAILABLE) Channel [9] Connect Set allocate channel in opcr, Set opcr data rate and overhead-id, Set opcr Source connection counter [9] Disconnect Decrement connection counter in opcr Source [9] Connect Sink Set allocate channel in ipcr, Set ipcr connection counter [9] Disconnect Decrement connection counter in ipcr Sink 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] 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] 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] Bass Control, 28 AMI-C

29 [9] Restore Equalizer [9] Register Equalizer [9] Clear Equalizer function_block_type = 81H (feature function block), audio_channel_number = 00H (master), control_selector = 0BH (Bass Control) 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 [9] Stop [1] Stop [1] Stop [5] Wind [5] 4.30 Wind, subfunction=60h(stop) [9] Play [1] Configure [1] 10.7 Configure, [1] Play 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] Play, subfunction_1 = 75H (forward) [5] Play [5] 4.15 Play, playback_mode = 75H (forward) [9] Pause [1] Play [1] 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] Search, subfunction_1 = 01H (absolute unit), measurement_unit = 00H (track boundary) [9] Track Down to the Current [9] Track Down to [1] Search [1] Search, the Previous 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 [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 Information [9] Disk Information [7] Open Descriptor [9] Track Information (only Set) [9] Play Time Information [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) [1] Search [1] Search, subfunction_1 = 10H (relative unit), measurement_unit = 00H (track boundary) [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. AMI-C commands [9] Tape Property [9] Time Counter [9] Tape Direction Table 14 Tape Media Message AV/C Command AV/C Reference 30 AMI-C

31 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 commands AV/C Command AV/C Reference [9] CurrentTrack- info blocks [3] 4.3 Position Indicator Info Block of [1] Table 7-16 Number plug_status_info_block [9] CurrentRelativeTime plug_status_info_block info blocks [3] 4.3 Position Indicator Info Block of [1] Table 7-16 [9] CurrentAbsDisk- Time 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 application 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 Application frame format Message Body Length S 0 Rsv 00 Pri 00 M 0 Transaction ID Multi-frame Sequence ID Destination F-Type Destination I-Num Source F-Type Source I-Num Reserved 0000 C 1 Mtype 010 Message Class Object Property Operand[0] Network Adaptation Registry Table Function Type Instance Number Node ID Subunit type Reg[12] Reg[16] 13H 02H 0BH 94H 80H 00H IDB-1394 frame format Destination Node ID tl Rt 00 tcode 0001 Pri 0000 Source Node ID Destination Address (High) Destination Address (Low) CTS (0100b) Data Length ACC (0000b) Reserved Extended tcode Message Body Length S 0 Rsv 00 Pri 00 M 0 Transaction ID Multi-frame Sequence ID Destination F-Type Destination I-Num Source F-Type Source I-Num Reserved 0000 C 1 Mtype 010 Message Class Object Property Operand[0] Figure 11 Mapping of Window (Set) 4.5 Sequence examples In this section, several sequence examples are shown in order to see the message exchanges between devices visually. 32 AMI-C

33 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. CMS AV/C AV Controller Vehicle Interface CD or MD Changer Audio Processor Allocate Channel (Cmd) Allocate Channel (Cnf) Connect Source (Cmd) Output Plug Signal Format Associate List with Plug Connect Source (Cnf) Connect Sink (Cmd) Input Plug Signal Format Connect Sink (Cnf) Figure 12 Sequence chart of connection Windows (Get) sequence The Vehicle Device Controller (VDC) sends the VIP message to Vehicle Interface (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. AMI-C

34 VIP OEM Proprietary Vehicle Device Controller Vehicle Interface Vehicle Device Emulator Windows (Inquire) OEM Proprietary OEM Proprietary Windows (Receive) Figure 13 Windows (Get) sequence 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 described above is shown in Figure AMI-C

35 VI Not Initialized Bus Reset VDC Initialized ARP Request no response RM Inquiry ignore Vehicle Initialization ARP Request (retry) no response ARP Request (retry) Node Information Announcement ignore no response Initialized ARP Request (retry) ARP Response Figure 14 Initialization sequence 5 Guidelines and recommendations AMI-C tested the following aspects in the AMI-C 1394 Automotive proof-ofconcept 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 available DV camcorder c. IDB1394 vehicle device interoperability with an emulator AMI-C

36 d. IEEE 1394 physical components connectivity with prototype repeaters 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 specifications 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 message (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 selected (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 implementation. 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. 36 AMI-C

37 7. The ARP information kept in each node is cleared after a network reset. 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 Response, 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 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 Shall, Must, Will Shall Not, Will Not Equivalent Expressions Is to Is required to It is required that Has to Only is permitted It is necessary Is not allowed [permitted] [acceptable] [permissible] A.2 Recommendations The following verbal forms are indicative of recommendations or courses of action that are preferred, but are not necessarily required. Verbal Form Should Should Not May May Not Can Cannot Equivalent Expressions It is recommended that Ought to It is not recommended that Is permitted Is allowed Is permissible Need not It is not required that No is required Be able to There is a possibility of It is possible to Be unable to There is no possibility of It is not possible to 38 AMI-C