BS ISO 22902-4-2006 Road vehicles - Automotive multimedia interface - Network protocol requirements for vehicle interface access《道路车辆 车用多媒体接口 车辆接口信道的网络协议要求》.pdf

《BS ISO 22902-4-2006 Road vehicles - Automotive multimedia interface - Network protocol requirements for vehicle interface access《道路车辆 车用多媒体接口 车辆接口信道的网络协议要求》.pdf》由会员分享，可在线阅读，更多相关《BS ISO 22902-4-2006 Road vehicles - Automotive multimedia interface - Network protocol requirements for vehicle interface access《道路车辆 车用多媒体接口 车辆接口信道的网络协议要求》.pdf（34页珍藏版）》请在麦多课文档分享上搜索。

1、 g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58Part 4: Network protocol requirements for vehicle interface accessICS 43.040.15Road vehicles Automo

2、tive multimedia interface BRITISH STANDARDBS ISO 22902-4:2006BS ISO 22902-4:2006This British Standard was published under the authority of the Standards Policy and Strategy Committee on 30 November 2006 BSI 2006ISBN 0 580 49717 8Amendments issued since publicationAmd. No. Date Commentscontract. User

3、s are responsible for its correct application.Compliance with a British Standard cannot confer immunity from legal obligations. National forewordThis British Standard was published by BSI. It is the UK implementation of ISO 22902-4:2006.The UK participation in its preparation was entrusted to Techni

4、cal Committee AUE/16, Electrical and electronic equipment.A list of organizations represented on AUE/16 can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a Reference numberISO 22902-4:2006(E)INTERNATIONAL STANDARD ISO22902-4First

5、 edition2006-11-01Road vehicles Automotive multimedia interface Part 4: Network protocol requirements for vehicle interface access Vhicules routiers Interface multimdia pour lautomobile Partie 4: Exigences du protocole de rseau pour accs linterface du vhicule BS ISO 22902-4:2006ii iiiContents Page F

6、oreword iv Introduction v 1 Scope . 1 2 Network architecture 1 2.1 Outline 1 2.2 Component 1 2.3 Vehicle interface . 2 2.4 Network application layer 2 2.5 Network transport layer 2 2.6 Functional module 2 2.7 Component control module (CCM) . 3 2.8 Registry 3 3 Addressing 3 3.1 Unicast . 3 3.2 Broadc

7、ast 4 3.3 Multicast 4 4 Message frame format 5 4.1 Message length. 6 4.2 System bit (Sys) 6 4.3 Reserved (Rsv) 6 4.4 Priority (Pri) . 6 4.5 More bit field (More) 6 4.6 Transaction identifier (T-ID). 6 4.7 Multi-frame sequence Id (M-ID) . 6 4.8 AMI-C message . 6 5 Application transaction 7 5.1 Messag

8、e format. 7 6 System transaction. 10 6.1 Message format. 10 7 Initialization process 16 7.1 Resource manager FM . 17 7.2 Instance numbers allocation process 19 7.3 Recovery process. 20 8 Address resolution process 20 8.1 ARP mechanism 20 8.2 No responder error handling . 21 9 FM discovery / removal

9、process . 22 9.1 Dynamic I-Num allocation when new component plugs in 22 9.2 Dynamic I-Num deallocation when component un-plugs. 22 9.3 Multicast resource allocation 22 10 Service discovery . 22 10.1 Protocol identification 22 10.2 Service identification 22 10.3 Service discovery messages. 23 Annex

10、A (informative) Registry table . 24 BS ISO 22902-4:2006iv Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committe

11、es. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the Inte

12、rnational Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International S

13、tandards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the su

14、bject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO 22902-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment. ISO 22902 consists of the following parts, under the general titl

15、e Road vehicles Automotive multimedia interface: Part 1: General technical overview Part 2: Use cases Part 3: System requirements Part 4: Network protocol requirements for vehicle interface access Part 5: Common message set Part 6: Vehicle interface requirements Part 7: Physical specification BS ISO

16、 22902-4:2006vIntroduction This part of the standard network architecture provides a set of common interfaces for accessing network-connected devices and vehicle functions through the vehicle interface. This network architecture has two elements: network protocol requirements for vehicle interface a

17、ccess; Common Message Set (CMS). The CMS is the companion to the network protocol requirements: in general, the CMS specifies semantic requirements; the network protocol specifies syntactical requirements. It should be recognized that the network protocol requirements are focused on supporting acces

18、s to vehicle services; the CMS contains in addition to vehicle services semantic requirements for audio visual (AV) messages, phone messages, Human Machine Interface (HMI) messages, etc. As shown in Figure 1, vehicle interface is a component that is a proxy of the vehicle functions: interfacing obje

19、cts from functional modules may interact with the device it represents. The object abstracts and exposes the services of devices in the vehicle. Objects called doors, windows, lights and vehicle speed, correspond to the devices connected to an automakers proprietary network. Figure 1 Vehicle interfa

20、ce (example) This network protocol requirement for vehicle interface access is a network framework and high-level (meta) protocol that enables the abstraction of devices and thereby facilitates their communication with applications and networks. The AMI-C network protocol requires that each device o

21、bject consist of a network interface (called its network adaptation layer) to ensure compatibility with different networks and also several functional modules. This requirement makes it possible for network applications to access a vehicle interface independently from specific network technology. Ad

22、ditionally, the network technology must be able to support multiple application level protocols on the network devices. BS ISO 22902-4:2006vi AMI-C network protocol requirements for vehicle interface access define a Vehicle Interface Protocol (VIP) that can be instantiated on a network technology. A

23、 VIP is an application protocol to access a vehicles devices (functions) via the network transport protocol of AMI-C networks. This, in turn, allows devices on such an AMI-C network to communicate with an automakers proprietary vehicle network through that vehicle interface. AMI-C network protocol r

24、equirements for vehicle interface access apply to automotive multimedia networks that do NOT have existing protocols for transporting vehicle function messages to and from a vehicle interface. For example, network transport layers are supposed to be general: TCP (UDP)/IP, FCP for 1394 Automotive, or

25、 L2CAP for Bluetooth. However, MOST Coorporation has already defined how to transport vehicle functions over the MOST network. Hence, the AMI-C network protocol requirements for vehicle interface access do not apply to the MOST network. For specific network technologies, the CMS is instantiated into

26、 technology-specified message frames. A specific network technology may already include the functionality of some portion of the CMS. In those cases the CMS is not instantiated. Rather, the CMS permits a semantic mapping from AMI-C specifications to the messages of that particular network technology

27、. BS ISO 22902-4:20061Road vehicles Automotive multimedia interface Part 4: Network protocol requirements for vehicle interface access 1 Scope This document provides a communication model that contains the requirements for a Vehicle Interface Protocol (VIP) to access a vehicle interface over a netwo

28、rk transport protocol for AMI-C networks. It does not apply to networks that have pre-existing protocols and messages for transporting vehicle functions. A VIP defines how an application communicates over a simple network transport mechanism. These requirements can be applied to network technologies

29、 that use UDP/IP as the transport method. However, pre-existing systems may have unique protocols and messages for transporting messages about vehicle functions; therefore, this document does not cover such pre-existing technology. Messages transported are network-specific instantiations of the CMS.

30、 This document addresses the following aspects related to the AMI-Cs approach to network communication: message frame format; application transaction; system transaction; initialization process; address resolution; and functional module discovery and removal process. 2 Network architecture 2.1 Outli

31、ne The Network protocol requirements for vehicle interface access, which consists of component, functional modules, API, network application layer, and network transport layer. The vehicle interface is considered one of its components. 2.2 Component A component is a physical entity attached to an AM

32、I-C network (1394 Automotive, Bluetooth, and so on). A component contains one or more functional modules, the network application layer and the network transport layer. A component is identified within a network transport layer with a physical ID, such as node ID, AM address, or IP address. BS ISO 2

33、2902-4:20062 2.3 Vehicle interface For those services resident on the automakers network, the AMI-C vehicle interface (VI) is a component that provides access to vehicle services via an AMI-C-compliant network. It may act as a gateway to a network defined by a vehicle manufacturer or it may implemen

34、t some or all of the vehicle services directly. Vehicle information and services such as vehicle speed, door lock, windows, and diagnostic services are members of the automakers proprietary network and a functional module on the VI represents each device. There may be more than one vehicle interface

35、 component on a network. Network Transport Layer(FCP for 1394 Aut omot ive)(L2CAP for Bluet ooth)(UDP/ IP)Network Transport Layer(FCP for 1394 Automotive)(L2CAP for Bluet oot h)(UDP/ IP)API APIFigure 2 AMI-C meta protocol conceptual architecture 2.4 Network application layer A network application la

36、yer provides the interface through an API for functional modules to access transport layers (and also, as necessary, lower layers) of network protocol. This document establishes the requirements for the application layer protocol. The instantiation of the application layer requirements into a specif

37、ic network technology is the vehicle interface protocol for that network. A VIP allows devices on an AMI-C network to communicate with an automakers proprietary vehicle network through a vehicle interface. 2.5 Network transport layer Common network transport layers include TCP(UDP)/IP, FCP for 1394

38、Automotive, or L2CAP for Bluetooth. MOST has defined a layer for transporting vehicle functions. 2.6 Functional module Within the AMI-C network architecture, a functional module (FM) is an abstraction of a device. An AMI-C component can have one or more FMs. An FM defines the properties of a device

39、(e.g., the up/down position of a car window). It also defines commands (e.g., set position) that control the properties of a device. An FM is addressed through a logical address, composed of function type (F-Type) and instance number (I-Num). There can be more than one FM with the same F-Type (4 win

40、dows, for example). To distinguish between these identical F-Types, I-Nums are statically or dynamically assigned. BS ISO 22902-4:200632.7 Component control module (CCM) Each AMI-C component (including the VI) must have a component control module (CCM). The CCM is the FM that performs initialization

41、, network management, address resolution, service discovery, as well as registry maintenance and update. The I-Num of a CCM serves as the Component ID. A CCM in each component communicates with other FMs to exchange attributes and status regarding FM installed in its components during initialization

42、 or when a component joins the network at the first time or leaves the network. In addition, the CCM is able to reply to service discovery queries from remote functional modules about all FMs inside its own component and component hardware status. The CCM keeps track of the status information in a r

43、egistry, such as the power status of a remote module, or visibility of a remote module in the network. 2.8 Registry A Registry is an address-mapping table between the Logical Address of an FM (that is, F-Type and I-Num) and the network-specific ID of the AMI-C component containing this FM (e.g., nod

44、e number in the case of 1394 Automotive). The registry contains this matching information about remote and local FMs throughout the AMI-C Network. It is beyond the scope of this specification to define the format of the registry, and how often it should be updated. 3 Addressing There are three types

45、 of addressing: unicast, broadcast and multicast. 3.1 Unicast Unicast addressing defines a point-to-point transaction. Unicast is characterized by F-Type values from 00H to EFH, and I-Num values from 00H to FEH. Unicast is the most common type of transaction. For example, an application (hosted by a

46、n FM) needs information that can be supplied by a remote FM. It sends an INQUIRE message to that remote FM and waits for the corresponding REPORT message from that remote FM. The logical address (F-Type and I-Num) of the destination FM is specified in the header. The Logical Address of the source FM

47、 is also specified in the header so that the destination FM can respond to the source component (See Figure 3), illustrates a unicast transaction. Figure 3 Unicast transaction mechanism BS ISO 22902-4:20064 3.2 Broadcast The network protocol requirements for vehicle interface access define 3 types o

48、f broadcast transactions: a broadcast message sent from an FM to all the instances of the same F-Type, e.g. lock all windows. In order to address all the instances of a particular F-Type, the I-Num field is given the maximum value: FFH. F-Type field specifies the Function Type. a broadcast message s

49、ent from a FM to all the FMs of the AMI-C Network. In order to address all the FMs of the network, the F-Type field is given the maximum value: FFH and I-Num field is FFH. a broadcast message for an address request or response (e.g. request to know which component contains a specific FM). When the system field (Sys, see section 4.2) equals 1B, this indicates that the message is a system transaction; therefore, it is always a broadcast message. The subsequent resp