AMI-C SPEC 1001-0-0
`
`Architecture
`Specification
`– Release 1
`
`Release 1, 2001
`
`AHM, Exh. 1023, p. 1
`
`

`

`
`
`Architecture Specification –
`Release 1
`
`
`Legal Disclaimer and Copyright Information
`
`
`All Automotive Multimedia Interface Collaboration, Inc. (AMI-C) specifications are
`copyrighted and are subject to the following terms and limitations:
`
`AMI-C specifications are for information and evaluation purposes only. Certain elements
`of AMI-C specifications may be subject to third-party intellectual property rights including,
`without limitation, patent rights (such a third party may or may not be a member of AMI-
`C). By releasing an AMI-C specification, AMI-C grants no license, expressed or implied,
`by estoppel or otherwise under AMI-C’s or any third party’s intellectual property rights,
`which may be embodied in such AMI-C specifications.
`
`AMI-C is not responsible and shall not be held responsible in any manner for identifying
`or failing to identify any or all such third-party intellectual property rights. In light of the
`above, AMI-C specifications may not be used for the design, development, production or
`commercialization of products, unless proper licenses are taken from the owners of
`intellectual property rights that pertain to each AMI-C specification and the information
`contained therein.
`
`The AMI-C specifications and the information contained therein are provided on an “as
`is” basis. AMI-C disclaims all warranties, expressed or implied, including but not limited
`to any warranty that the use of the information therein will not infringe the intellectual
`property rights of a third party or any warranties of merchantability or fitness for a
`particular purpose.
`
`In no event is AMI-C liable for any loss of profits, loss of business, loss of use of data,
`interruption of business, or for direct, indirect, special or exemplary, incidental, punitive,
`or consequential damages of any kind in connection with an AMI-C specification or the
`information contained therein or the use thereof by anyone.
`
`All brand and product names may be trademarks that are the sole property of their
`respective owners. All rights reserved.
`
` Copyright AMI-C 2000.
`
` 
`
`
`
`
`
`
`
`
`
`AHM, Exh. 1023, p. 2
`
`

`

`AMI-C SPEC 1001.0.0
`
`
`
`Revision Log
`
`[Notice: Refer to the public document section of www.ami-c.org for most current baseline and revision.]
`
`Baseline Date
`
`01/01/01
`
`Document No.
`
`AMI-C SPEC 1001
`Document Title:
`
`Architecture Specification – Release 1
`
`
` 0
`
`Baseline No:
`
`
`
`
`Revision Date
`
`
`Affected Sections
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Revision No.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`AHM, Exh. 1023, p. 3
`
`

`

`AMI-C SPEC 1001.0.0
`
`Request for Change Form
`
`
`
`[Notice: Use this form to identify any errors or deficiencies or to make general change recommendations.]
`
`Revision No.
`
` 0
`
`
`
`Document No.
`
`AMI-C SPEC 1001
`Document Title:
`
`Architecture Specification – Release 1
`
`
` 0
`
`Baseline No.
`
`
`
`
`REQUESTOR INFORMATION
`
`
`
`
`Mail to:
`Don Ingersoll
`AMI-C Vice President
`280 Enterprise Drive, Bloomfield Hills,
`
`Michigan, USA 48302-0312
`
`Fax to:
`Don Ingersoll
`AMI-C Vice President
`c/o Results Systems Corp.
`(248) 244-8504
`
`
`Name:
`
`Organization:
`
`E-mail:
`
`Phone:
`
`Description of Change:
`
`
`
`
`Rational for Change:
`
`
`
`
`Proposed Revision:
`
`
`
`
`Affected Sections:
`
`
`
`
`
`E-mail to:
`
`Don Ingersoll
`AMI-C Vice President
`secretary@ami-c.org
`
`
`
`AHM, Exh. 1023, p. 4
`
`

`

`AMI-C SPEC 1001.0.0
`
`
`
`Table of Contents
`
`FOREWORD...................................................................................................... 1
`
`INTRODUCTION................................................................................................ 1
`
`1. SCOPE ....................................................................................................... 1
`
`1.1.
`
`Intended Audience.......................................................................................... 2
`
`2. NORMATIVE REFERENCES..................................................................... 2
`
`2.1. AMI-C Documents........................................................................................... 2
`
`2.2. Other Documents............................................................................................ 3
`
`3. TERMS AND DEFINITIONS....................................................................... 3
`
`4. SPECIFICATION ........................................................................................ 3
`
`4.1.
`
`Flexibility......................................................................................................... 3
`
`4.2. Expandability .................................................................................................. 3
`
`4.3.
`
`Interoperability................................................................................................ 3
`
`4.4. Upgradeability................................................................................................. 4
`
`4.5. Structural Architecture................................................................................... 4
`4.5.1.
`Architectural Components (NORMATIVE)................................................. 4
`4.5.2.
`Networks................................................................................................... 4
`4.5.2.1.
`IDB-C Low- Speed Network ................................................................................5
`4.5.2.2. High-Speed Network ...........................................................................................5
`4.5.3.
`Bridges and Gateways .............................................................................. 5
`4.5.3.1. Routing ................................................................................................................6
`4.5.3.2. Protocol Matching................................................................................................7
`4.5.3.3. Application Layer Message Translation ..............................................................7
`4.5.3.4. Discovery Protocol Resolution.............................................................................8
`4.5.3.5. Discovery on the High-Speed Network ...............................................................8
`4.5.3.6.
`Issues to be Resolved (INFORMATIVE) .............................................................8
`4.5.4.
`Vehicle Interface (INFORMATIVE)........................................................... 9
`4.5.4.1. Power and Ground interface..............................................................................10
`4.5.4.2. Power Modes.....................................................................................................10
`4.5.4.3. Boot Sequence ..................................................................................................12
`
`4.6. Configurations .............................................................................................. 13
`
`
`
`AHM, Exh. 1023, p. 5
`
`

`

`AMI-C SPEC 1001.0.0
`
`4.6.1. Minimum Configuration ........................................................................... 16
`4.6.2. Multiple Network Configurations.............................................................. 16
`
`Functional Architecture (INFORMATIVE) .................................................... 16
`4.7.
`4.7.1.
`Network Message Sets ........................................................................... 17
`4.7.2.
`IDB-C...................................................................................................... 17
`4.7.2.1. Network Management .......................................................................................17
`4.7.3.
`Physical and Link Layers......................................................................... 18
`4.7.4.
`Transport Layer....................................................................................... 18
`4.7.5.
`Application Layer..................................................................................... 18
`
`4.8. High-Speed Network..................................................................................... 19
`4.8.1.
`Network Management ............................................................................. 19
`4.8.2.
`Physical and Link Layers......................................................................... 19
`4.8.3.
`Transport Layer....................................................................................... 19
`4.8.4.
`Application Layer..................................................................................... 19
`
`4.9.
`
`Internetworking............................................................................................. 20
`
`Vehicle Interface Functions...................................................................... 21
`4.10.
`4.10.1. Supported Functionality........................................................................... 21
`4.10.1.1.
`Core Services................................................................................................21
`4.10.1.2.
`Security Services...........................................................................................22
`4.10.1.3.
`Vehicle Status Services ................................................................................22
`4.10.1.4.
`Vehicle Diagnostic Services..........................................................................23
`4.10.1.5.
`Body Status and Control Services ................................................................23
`4.10.1.6.
`OEM Reserved Services...............................................................................25
`4.10.1.7.
`Driver Display Services .................................................................................25
`4.10.1.8.
`Positioning Services and E-Call Services .....................................................26
`4.10.2. Mandatory Minimum Set ......................................................................... 26
`
`5. RELEASE 2 ARCHITECTURE SCOPE (INFORMATIVE) ....................... 26
`
`5.1. Aspects to be Specified in the Next Architecture Release ........................ 26
`5.1.1.
`Network Transport................................................................................... 26
`5.1.2.
`Software Interfaces / APIs....................................................................... 27
`
`5.2. Aspects of the Architecture that Will Not be Specified by AMI-C.............. 27
`
`APPENDIX A: REQUIREMENT AND RECOMMENDATION LANGUAGE ... 28
`
`
`
`AHM, Exh. 1023, p. 6
`
`

`

`AMI-C SPEC 1001.0.0
`
`Table of Figures
`
`Figure 1.
`IDB Application Layer Header Format ....................................................... 7
`Figure 2. Power Mode Transitions.......................................................................... 10
`Figure 3.
`Transitions with Additional Reduced Power States.................................. 11
`Figure 4. Vehicle Interface Reset Actions............................................................... 13
`
`
`
`
`
`
`AHM, Exh. 1023, p. 7
`
`

`

`AMI-C SPEC 1001.0.0
`
`AMI-C SPEC 1001.0.0
`
`Architecture Specification – Release 1
`
`
`
`Foreword
`
`The Architecture Specification is part of the AMI-C Release 1 Specification Set.
`
`Release 1 specifications are not the definitive source by which AMI-C compliant
`components are to be designed and constructed, but they do serve as the
`foundation for the continuation of specification development activities and
`provide a method for identifying and resolving any discrepancies and
`deficiencies that may be present.
`
`The specification set resulting from the next phase of development will provide
`the “build-to” requirements for ensuring the interoperability, expandability and
`upgrade-ability of AMI-C compliant components.
`
`Introduction
`
`This document describes the architecture of an Automotive Multimedia Interface
`Collaboration, Inc. (AMI-C) compliant Release 1 System. The architecture
`described here is intended to fulfill the requirements described in the AMI-C
`functional requirements specification. Individual components are described in
`the vehicle interface, network message set and gateway documents, which
`should be read in conjunction with this document.
`
`The Release 1 Architecture Specification contains the release one specific
`elements of the architecture described in the AMI-C Architecture Outline. The
`AMI-C architecture was developed under the leadership of Francois Ougier.
`Other team members who contributed to the development of this document
`include: Fabien Bergeret, Stefan Glaeser, Yasuharu Hattori, Yoichi Iwata, Dr.
`Hans-Ulrich Michel and Walter Savio. Significant contributions were also made
`to the Release 1 Architecture by members of other AMI-C technical teams,
`including Jim Minewiser, Ralph Robinson and Bill Wong.
`
`1. Scope
`
`This specification describes the architecture of an AMI-C compliant Release 1
`system, but does not specify the individual components of the system. It
`designates the networks that will be used in AMI-C compliant systems and
`describes the vehicle interfaces to these networks and the gateways between
`them. It does not describe support for AMI-C defined applications or the
`software APIs that applications must use to interface to the AMI-C compliant
`
`Architecture Specification – Release 1 Page 1 of 28
`
`AHM, Exh. 1023, p. 8
`
`

`

`AMI-C SPEC 1001.0.0
`
`system. These aspects of the architecture are deferred until the next
`specification release.
`
`The Release 1 specification addresses devices and controllers without hosts.
`The purpose of this release of the architecture is to support existing
`components that were designed to use the native protocols of the supported
`networks. The architecture also indicates the direction that will be taken by the
`next specification release, in order to allow implementers to minimize the impact
`of upgrading their designs.
`
`NOTE 1: Much of this document describes information that is present in other
`Release 1 specifications and, is thus, informative rather than normative. Those
`sections that are intended to provide normative specifications are described, as
`such, in the headings.
`
`NOTE 2: Certain aspects of a multimedia system architecture are not specified
`as part of Release 1.
`
`NOTE 3: Section 4.7, Functional Architecture (INFORMATIVE), of this
`document indicates those aspects that will be specified in the next specification
`release by AMI-C and those that will not be specified.
`
`1.1. Intended Audience
`
`Implementers of Release 1 AMI-C compliant systems for vehicles, and
`designers who will be designing AMI-C compliant multimedia devices should
`read this document.
`
`2. Normative References
`
`The following documents form a part of the specification to the extent specified
`herein. Unless otherwise noted, this specification refers to the most recent
`version of a particular document.
`In the event of a conflict between the text of this specification and the
`documents cited herein, the text of this specification takes precedence. Nothing
`in this specification, however, supersedes applicable laws and regulations,
`unless a specific exemption has been obtained.
`
`
`2.1. AMI-C Documents
`
`To be added.
`
`
`Architecture Specification – Release 1 Page 2 of 28
`
`AHM, Exh. 1023, p. 9
`
`

`

`AMI-C SPEC 1001.0.0
`
`2.2. Other Documents
`
`To be added.
`
`
`3. Terms and Definitions
`
`Refer to the AMI-C REF DOC 6001, AMI-C Technical Glossary, for definitions of
`terms and acronyms used throughout this document. Also refer to Appendix A:
`Requirement and Recommendation Language for guidance on verbal
`expressions used throughout this specification that are indicative of
`requirements and recommendations.
`
`
`4. Specification
`
`Following are the high-level requirements imposed on the AMI-C Architecture
`by this specification.
`
`4.1. Flexibility
`
`The AMI-C specifications are intended to apply to a range of low- to high-end
`systems. Release 1 must accommodate this range, although it will not
`completely specify the higher-end systems.
`
`4.2. Expandability
`
`AMI-C compliant systems should be expandable by the addition of new
`software that provides additional functionality and new components through the
`customer access connector.
`
`Release 1 does not support expandability through the addition of software-
`provided functionality, since software interfaces are not defined in this release.
`Expandability through the addition of hardware components, however, is
`supported in Release 1.
`
`4.3. Interoperability
`
`An important requirement for an AMI-C compliant system is that it provides
`interoperability between the multimedia systems of different manufacturers, so
`that components working in one system will also work in any other AMI system.
`In the next specification release and beyond, this will apply to both hardware
`and software components. In this Release 1 specification, however,
`interoperability only applies to hardware components because software
`interfaces are not specified.
`
`Architecture Specification – Release 1 Page 3 of 28
`
`AHM, Exh. 1023, p. 10
`
`

`

`AMI-C SPEC 1001.0.0
`
`4.4. Upgradeability
`
`Upgradeability has several meanings, with respect to the Release 1
`architecture. In the weakest sense, it means that the architecture of Release 1
`is consistent with that of later releases. For example, networks supported in
`Release 1 will continue to be supported in the next specification release.
`
`In a stronger sense, upgradeability means that any component used in a
`Release 1 system can also be used in a future release system.
`
`In the strongest sense, upgradeability means that a Release 1 system itself will
`be compliant with future release systems, and that it can be expanded to
`include any future release functionalities that are not defined in Release 1. The
`latter sense will only apply to a Release 1 system if it does not use any
`reserved functionality (that is, functionality not defined in Release 1, but which
`will be defined in future releases).
`
`4.5. Structural Architecture
`
`4.5.1.
`
`Architectural Components (NORMATIVE)
`
`An AMI-C compliant system shall consist of:
`• One or more AMI-C networks to which multimedia components are
`attached;
`• A vehicle interface that provides access to vehicle-specific information, such
`as vehicle diagnostics; and,
`• Gateways between the networks in the system.
`
`AMI-C compliant components are divided into 3 classes: devices, controllers,
`and hosts, depending on their capabilities. This specification covers the
`interfaces between:
`• The networks and the components on the networks;
`• The vehicle and the components; and,
`• Different networks.
`
`4.5.2.
`
`Networks
`
`AMI-C specifies two networks: A low-speed network and a high-speed network.
`In the future, a local wireless network will also be specified. An AMI-C
`compliant system may have any or all of these networks.
`
`Architecture Specification – Release 1 Page 4 of 28
`
`AHM, Exh. 1023, p. 11
`
`

`

`AMI-C SPEC 1001.0.0
`
`4.5.2.1.
`
`IDB-C Low- Speed Network
`
`The low-speed network is IDB-C, which is described in SAE J2366-1, SAE
`J2366-2, SAE J2366-4, SAE J2366-7 and IDB.0002.0B.
`
`The individual specifications describe the physical layer, the link layer, the
`transport layer and the application layer (OSI layers 1,2,4,7). IDB-C does not
`define a network layer or session or presentation layers.
`
`The physical layer is just CAN, while the link layer is a modification of the CAN
`link layer, which is based on a virtual token ring technology. The transport layer
`is called a "thin" transport layer. Its principle function is to accommodate
`messages that are too large in a single CAN packet.
`
`The link layer protocols have a mechanism, whereby a different transport layer
`protocol can be substituted for the IDB-C transport protocol. The application
`layer defines a format for application layer messages, as well as a set of
`categories for grouping application messages.
`
`The actual application layer messages are defined in the IDB lexicon.
`
`4.5.2.2. High-Speed Network
`
`For Release 1, AMI-C has not endorsed a specific high-speed network. There
`are two candidates for endorsement in the next specification release -- namely
`IEEE 1394b and MOST. Both networks are based on Plastic Optical Fiber
`(POF) and have the bandwidth required for video and audio.
`
`IEEE 1394, also known as FireWire™, is a packet switched network that uses a
`tree topology. MOST is a circuit switched network that uses a ring topology.
`
`4.5.3.
`
`Bridges and Gateways
`
`AMI-C specifies three gateways between in-vehicle networks in Release 1:
`
`a) The IDB / OEM gateway connects the AMI-C defined IDB-C network with
`the OEM network(s) in the vehicle.
`
`b) The High Speed Network / OEM gateway (HSN / OEM gateway) connects
`the AMI-C defined high-speed network with the OEM network(s) in the
`vehicle.
`
`c) The IDB / HSN gateway connects the AMI-C defined IDB-C network with the
`AMI-C defined high-speed network.
`
`A gateway is a connection between two networks running distinct protocols that
`support application-level communications between nodes on different networks.
`
`Architecture Specification – Release 1 Page 5 of 28
`
`AHM, Exh. 1023, p. 12
`
`

`

`AMI-C SPEC 1001.0.0
`
`A bridge is a device that connects two networks with different physical layers,
`but common protocol layers. An example is a device that connects an optical
`fiber based 1394 network to a wire based 1394 network. A bridge does not
`provide protocol translation.
`
`Two types of gateways exist in AMI-C systems. 1) Native gateways translate
`between the native protocols of the connected networks. 2) Transmission
`Control Protocol (TCP) / Internet Protocol (IP) gateways support internetworking
`using TCP / IP protocols. Only native gateways are defined for Release 1.
`
`An AMI-C compliant gateway must support protocol translation between the
`application layers of the connected networks, as defined in the appropriate AMI-
`C gateway specification. In general, the gateway specification will define
`translation between a limited set of the protocols available on each network.
`Translation of additional protocols not defined in the appropriate gateway
`specification is unsupported.
`
`In Release 1, the only supported gateway is used to connect an IDB-C network
`to a high-speed network. The specification of this gateway is given in AMI-C
`SPEC 3004,1394 to IDB-C Gateway.
`
`A gateway shall provide four services:
`
`a) Routing
`
`b) Protocol matching below the application layer
`
`c) Application layer message translation
`
`d) Discovery protocol resolution
`
`4.5.3.1. Routing
`
`The gateway shall accept packets addressed to nodes on a different network
`and reissue them on the destination network.
`
`In doing so, it must replace the link layer packet headers from the originating
`network with the appropriate headers from the destination network. To do this, it
`must keep a table of local addresses for each network. These tables are filled
`using the discovery protocols of the respective networks. This is a fairly
`straightforward process if there are only two local networks, because the
`gateway is a direct participant in both networks. However, if there are more than
`two local networks, a routing protocol, such as RIP, would be required to
`correctly fill the routing tables in the gateway.
`
`The Release 1 architecture avoids the need for such a protocol by prohibiting
`peer-to-peer interactions between nodes that are not on adjacent local
`
`Architecture Specification – Release 1 Page 6 of 28
`
`AHM, Exh. 1023, p. 13
`
`

`

`AMI-C SPEC 1001.0.0
`
`networks. The vehicle interface does not count as a gateway, in this respect,
`because there are no peer-to-peer interactions between a node on the AMI-C
`network and a node on any OEM network. AMI-C nodes always interact with
`the vehicle interface.
`
`
`
`
`
` Cntl SrcAdr SLgAd DesAd DlgAd Seqnr SAPID Msg Lngth
`
`Figure 1.
`
`IDB Application Layer Header Format
`
`A significant issue with routing is matching the address spaces of the two
`networks on the interface.
`
`IDB-C application layer packets have two address fields: A physical address
`and a logical address, each of which is four bits wide. Thus there can be up to
`16 physical components on the IDB-C network, one of which is the gateway to
`the other network.
`
`Each of these physical nodes can support up to 16 logical addresses. If the
`logical address was used to designate the node on the other network, which is
`the destination of a message, nodes would only be able to address 16 external
`nodes. However, both MOST and IEEE 1394b support up to 64 nodes. This
`problem can be overcome by using the SAPID field in the application layer
`header as part of the logical address.
`
`4.5.3.2. Protocol Matching
`
`The gateway must match the transport layer requirements of the two networks.
`For example, it must assemble / disassemble packets to match the packet
`length requirements of the destination network. It must also, for example, satisfy
`the flow control requirements of the destination network, using mechanisms
`available on the originating network
`
`IDB-C has a "Thin" transport layer, which only specifies how frames (messages)
`are packaged. It does not specify flow control.
`
`4.5.3.3. Application Layer Message Translation
`
`The gateway must translate application layer messages from the protocol of the
`originating layer to that of the destination layer.
`
`The gateway should not support internet work discovery for devices that do not
`have AMI-C defined translation message sets. However, even with this
`restriction, untranslatable messages may appear at the gateway due to
`changing versions of devices or non-conforming devices.
`
`Architecture Specification – Release 1 Page 7 of 28
`
`AHM, Exh. 1023, p. 14
`
`

`

`AMI-C SPEC 1001.0.0
`
`If there is no translation defined for a given message, the gateway must handle
`the error. Normally, the error should be handled using the error protocol of the
`originating network to return an error to the node that sent the untranslatable
`message. The gateway should not simply drop the packet without returning an
`error indication.
`
`NOTE: Application message translation requires that the gateway perform the
`packet assembly required to form a complete message.
`
`4.5.3.4. Discovery Protocol Resolution
`
`The gateway shall keep tables of the devices / services available on each
`network. Only devices whose message sets can be translated need to be
`included in the tables, however, the gateway should be able to translate the
`entire message set for such devices.
`
`IDB-C defines two stages in the discovery process:
`
`a) Device discovery and address assignment occurs when a node joins the
`network.
`
`b) Service discovery occurs when a device sends an APLNewStatus message
`specifying the services that it offers. This is a datagram message that is
`broadcast to the network when the device joins the network and whenever
`there is any change to the services offered by the node. In addition, any
`node can request another node to broadcast its status using the
`APLReqStatus message.
`
`4.5.3.5. Discovery on the High-Speed Network
`
`The gateway shall take the following steps to resolve the discovery protocols:
`
`a) It shall listen on each attached network for the APLNewStatus messages,
`and fill in the table of services that it will offer to the facing network.
`
`b) When each network stabilizes, it shall broadcast the table of services that it
`has built up to the facing network, using the APLNewStatus message on
`IDB and the XXX message on yyy.
`
`c) Whenever there is a change on one network, it shall update the table of
`services offered on that network and broadcast the update to the facing
`network.
`
`4.5.3.6.
`
`Issues to be Resolved (INFORMATIVE)
`
`A significant number of issues remain to be resolved with respect to discovery
`
`Architecture Specification – Release 1 Page 8 of 28
`
`AHM, Exh. 1023, p. 15
`
`

`

`AMI-C SPEC 1001.0.0
`
`protocol resolutions in the Release 1 architecture. Resolutions for these issues
`require the selection of a high-speed network. Specifically, the open issues
`include the following:
`
`a) How should a change of physical nodes or services on the IDB network be
`modeled on the high-speed network? For example, IEEE 1394 requires a
`bus reset and potential topology change whenever a node is added to or
`deleted from the network. Whenever IDB-C bus topology changes,
`IEEE1394 also requires bus reset. See the 1394 to IDBC gateway
`specification [AMI-C SPEC 3004: 1394 to IDB-C Gateway] for more details.
`
`b) Both IEEE 1394 and MOST reassign physical addresses to nodes on the
`network when a node is added or removed. IDB does not. Thus, the addition
`or removal of a node on the high-speed network will require the gateway to
`reconstruct its routing table, while a change on the IDB network will only
`require a single entry to be changed.
`
`c) The packet size must be reconciled between the two networks. IDB-C
`supports messages of up to 64k bytes using the thin transport layer.
`Messages are fragmented into 64 bit frames. MOST allows packets of up to
`1014 bytes on the asynchronous data channel, while the packet size on
`IEEE 1394 depends on the bus speed. For a 100Mb/sec bus, it is 512 bytes.
`This will require buffering in the gateway.
`
`d) A flow control mechanism needs to be identified on each of the supported
`networks, since the gateway is connecting networks of different speeds that
`may transmit large amounts of data across the gateway as part of a single
`transaction.
`
`4.5.4.
`
`Vehicle Interface (INFORMATIVE)
`
`The vehicle interface connects the AMI-C compliant system to the vehicle. It
`presents all services offered by the vehicle to AMI-C compliant components and
`hides the implementation of those services from the system. The vehicle side of
`this interface is not specified by AMI-C and will differ between vehicles,
`depending on the specific OEM network that is used and on other manufacturer
`specific details.
`
`The module that implements the vehicle interface may also implement a
`gateway between two or more AMI-C networks, but the gateway functions are
`logically distinct from the vehicle interface functions. The functionality that is
`implemented by the vehicle interface is described in section 4.10.
`
`The Release 1 specification also includes the physical and electrical side of the
`vehicle interface. The physical specification covers the connectors for IDB-C
`and for the high-speed network. The electrical specification describes the
`power, which must be sourced by the vehicle interface and the power mode
`
`Architecture Specification – Release 1 Page 9 of 28
`
`AHM, Exh. 1023, p. 16
`
`

`

`AMI-C SPEC 1001.0.0
`
`protocol, as well as the way in which the AMI-C power modes relate to the
`vehicle power modes.
`
`4.5.4.1. Power and Ground interface
`
`The vehicle interface supplies power to the devices connected to the AMI-C
`system through the Vehicle Interface connector set. The requirements for this
`power supply are detailed in AMI-C SPEC 4001, Physical Specification. The
`vehicle interface must also supply a signal, designated PMODE, to each
`attached network that indicates the vehicle power mode.
`
`4.5.4.2. Power Modes
`
`AMI-C networks and components shall implement at least three power modes:
`• Fully powered mode (ON)
`• Unpowered mode (OFF)
`• Reduced power mode
`
`The reduced power mode is defined by the requirement that each component
`consume no more current than a specified minimum. This minimum is defined
`in AMI-C SPEC 4001, Physical Specification. The transitions between modes
`shall be controlled by the vehicle interface. The transition diagram for these
`power modes is shown below.
`
`
`
`
`
`
`
`
`
`
`
`
`
`ON
`
`Reset
`
`OFF
`
`PMODE pulse or
`Net reset signal
`Reset
`
`REDUCED
`POWER
`
`
`
`
`
`Figure 2.
`
`Power Mode Transitions
`
`
`
`Architecture Specification – Re