BS EN ISO 14906-2011 Electronic fee collection Application interface definition for dedicated short-range communication《电子收费 专用短程通信的应用接口定义》.pdf

1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationBS EN ISO 14906:2011Electronic fee collection Application interface definition for dedicated short-range communication (ISO 14906:2011)Provided by IHSNot for ResaleNo reproductio

2、n or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011 BRITISH STANDARDNational forewordThis British Standard is the UK implementation of EN ISO 14906:2011. It supersedes BS EN ISO 14906:2004 which is withdrawn.The UK participation in its preparation was entrusted to Technical C

3、ommittee EPL/278, Road transport informatics.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. BSI 2011 ISBN 978

4、 0 580 64539 6 ICS 03.220.20; 35.240.60 Compliance with a British Standard cannot confer immunity from legal obligations.This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 October 2011.Amendments issued since publicationDate T e x t a f f e c

5、 t e dProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN ISO 14906 October 2011 ICS 03.220.20; 35.240.60 Supersedes EN ISO 14906:2004English Version Electronic fee collection - Application interface d

6、efinition for dedicated short-range communication (ISO 14906:2011) Perception du tlpage - Dfinition de linterface dapplication relative aux communications ddies courte porte (ISO 14906:2011) Elektronische Gebhrenerhebung - Anwendungsschnittstelle zur dezidierten Nahbereich-Kommunikation (ISO 14906:2

7、011) This European Standard was approved by CEN on 20 August 2011. CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical

8、 references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member. This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of

9、 a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions. CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungar

10、y, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre:

11、 Avenue Marnix 17, B-1000 Brussels 2011 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN ISO 14906:2011: EProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011EN ISO 1

12、4906:2011 (E) 3 Foreword This document (EN ISO 14906:2011) has been prepared by Technical Committee ISO/TC 204 “Intelligent transport systems“ in collaboration with Technical Committee CEN/TC 278 “Road transport and traffic telematics” the secretariat of which is held by NEN. This European Standard

13、shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by April 2012, and conflicting national standards shall be withdrawn at the latest by April 2012. Attention is drawn to the possibility that some of the elements of this docu

14、ment may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. This document supersedes EN ISO 14906:2004. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are

15、 bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spa

16、in, Sweden, Switzerland and the United Kingdom. Endorsement notice The text of ISO 14906:2011 has been approved by CEN as a EN ISO 14906:2011 without any modification. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011ISO 14906:2011

17、(E) ISO 2011 All rights reserved iiiContents Page Foreword iv Introduction . v 1 Scope 1 2 Normative references 2 3 Terms and definitions . 2 4 Abbreviated terms . 5 5 EFC application interface architecture 7 5.1 Relation to the DSRC communication architecture . 7 5.2 Usage of DSRC application layer

18、 by the EFC application interface 9 5.3 Addressing of EFC attributes . 9 5.4 Addressing of components 11 6 EFC Transaction Model . 12 6.1 General . 12 6.2 Initialisation Phase 12 6.3 Transaction phase . 15 7 EFC Functions . 17 7.1 Overview and general concepts 17 7.2 EFC functions 21 8 EFC Attribute

19、s . 34 8.1 General . 34 8.2 Data group CONTRACT 36 8.3 Data group RECEIPT . 36 8.4 Data group VEHICLE . 36 8.5 Data group EQUIPMENT . 37 8.6 Data group DRIVER . 37 8.7 Data group PAYMENT . 37 Annex A (normative) EFC data type specifications 51 Annex B (informative) CARDME transaction 67 Annex C (inf

20、ormative) Examples of EFC transaction types . 93 Annex D (informative) Functional requirements 103 Annex E (normative) Mapping table from LatinAlphabetNo2 Efc-ContextMark (incl. the ContextVersion), denoting the implementation version, provides a means to ensure co-existence of different implementat

21、ion versions by means of a look-up table and associated appropriate transaction processing. This will enable the software of the RSE to determine the version of the OBE and his capabilty to accept the new features of this version of this International Standard. Annex A provides the normative ASN.1 s

22、pecifications of the used data types (EFC action parameters and attributes). Annex B presents an informative example of a transaction based on the CARDME specification, including bit-level specification. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-

23、,-BS EN ISO 14906:2011ISO 14906:2011(E) vi ISO 2011 All rights reservedAnnex C presents informative examples of EFC transaction types, using the specified EFC functions and attributes. Annex D presents an informative listing of functional requirements, which can be satisfied by using the tools provi

24、ded by this International Standard. Annex E presents an informative mapping table from LatinAlphabetNo2 End Application (at RSE); Register Application RSU (at RSE); Deregister Application (at RSE and OBE); Notify Application OBU (at OBE); Register Application OBU (at OBE) are used to realise the EFC

25、-specific initialisation mechanism (see Clause 6); The GET service is used to retrieve EFC attributes (For attribute specifications see Clause 8); The SET service is used to set EFC attributes; The ACTION services are applied to realise additional EFC specific functionality needed to support EFC app

26、lication processes, such as TRANSFER_CHANNEL, SET_MMI and ECHO (see 7.2). In the following, the EFC-specific usage of the DSRC Layer 7 services is specified in detail. NOTE The EVENT-REPORT-service can be implicitly used by EFC application processes. It is e.g. used indirectly as part of an already

27、defined command to release an application process (see EN 12834/ISO 15628, Ready Application). However as the EVENT-REPORT-service is not explicitly used by EFC application processes, this service is not further referred to in this International Standard. 5.3 Addressing of EFC attributes 5.3.1 Basic

28、 mechanism EFC Attributes are used to transfer the EFC application-specific information. EFC Attributes are composed of one or more data elements of specified ASN.1 types. Each data element is associated with, within the context of this International Standard, an unambiguous name. To each EFC Attrib

29、ute, an AttributeID is associated. The AttributeId enables to unambiguously identify and address an EFC Attribute. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011ISO 14906:2011(E) 10 ISO 2011 All rights reservedEXAMPLE Figure 3 i

30、llustrates the basic addressing mechanism. AttrlD = 0 AttrlD = 4Contract AuthenticatorAttrlD = nAttribute IDAttributeASN.1-Type.AttrlD = 3AttrlD = 2Contract VehicleContract ValidityContractAuthenticator :=ContractVehicle :=ContractValidity := SEQUENCE contractRestrictions OCTET STRING (SIZE(4) contr

31、actExpiryDate DateCompactFigure 3 Basic addressing mechanism 5.3.2 Role of the EID In a given OBE, the DSRC-EID (different from 0) is used to address an EFC context, identified by the EFC-ContextMark (see 6.2.3), in which Attributes can be addressed unambiguously by AttributeIDs inside an Element of

32、 the OBE. In the VST, the OBE specifies one or several of these EFC contexts, each corresponding to an EFC ContextMark and the EID to be used for addressing the attributes and using the EFC functions supported by it. EXAMPLE AttrlD = 0 AttrlD = 4Contract AuthenticatorAAttrlD = n.AttrlD = 3AttrlD = 2

33、Contract VehicleAContract ValidityAContract ValidityBContract VehicleBContract AuthenticatorB .Contract ValidityCContract VehicleCContract AuthenticatorC .EID = 1EID = 2EID = 3Figure 4 Role of the EID EID equals 0 shall be used to address application-independent functions and components, e.g. SET_MM

34、I and TRANSFER_CHANNEL (see 7.2). 5.3.3 Multiple Instances of Attributes There may be n, where n is an integer, instances of an Attribute available in an OBE. The maximum number of instances Nmax of one Attribute may be limited according to the needs of operators and users. The default maximum numbe

35、r of instances is Nmax=1. The value of Nmax is determined at the time of OBE configuration. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011ISO 14906:2011(E) ISO 2011 All rights reserved 11EXAMPLE AttrlD = 0 AttrlD = n.AttrlD = 5E

36、ID = 1.ReceiptServicePart2ReceiptServicePart1ReceiptServicePart 0Figure 5 Multiple instances (0-2) of attribute 5 The handling of multiple instances and the corresponding addressing mechanism are described in detail as part of the behaviour specification of the corresponding functions supporting mul

37、tiple instances (see 7.2.6 for GET_INSTANCE and 7.2.7 for SET_INSTANCE). 5.4 Addressing of components Components of an OBE to be addressed via the EFC Application Interface include for example: OBU; SAM 1; SAM 2; ICC; Display; Buzzer; Printer; Serial interface; Parallel interface; GPS; Tachograph; B

38、luetooth. Addressing of these components is enabled on two levels, device-specific and device-independent addressing. The device-specific transparent addressing mechanism enables the transfer of information, which shall be processed by the addressed device (such as an ICC-command). The addressed dev

39、ice is identified by a channel Id. The EFC function TRANSFER_CHANNEL (see 7.2.10) supports this functionality. EXAMPLE 1 Transfer of a bit string to an ICC. The device-independent addressing mechanism uses a set of commands, which describe a certain functionality, which can be performed by various O

40、BE components. In this case, the operating system of the OBE will address the corresponding components. The EFC function SET_MMI supports this functionality (see 7.2.12). EXAMPLE 2 Invocation of a SET_MMI(EID=0, ContactOperator) function activates an OBE MMI-device, e.g. a buzzer or a display. NOTE

41、In a specific implementation, specific attributes or data elements may activate some MMI function (e.g. a SET command on the attribute ReceiptText might display the text on an LCD display. A SET command on the attribute ReceiptServicePart with data element SessionResultOperational other than Session

42、OK might activate an alert beep). Proprietary addressing mechanisms are not defined by this International Standard. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011ISO 14906:2011(E) 12 ISO 2011 All rights reserved6 EFC Transaction

43、 Model 6.1 General The EFC Transaction Model related to the EFC Application Interface for the DSRC comprises two phases, the initialisation phase and the transaction phase. NOTE The purpose of the initialisation phase is to set up the communication between the RSE and OBEs that have entered the DSRC

44、 zone but have not yet established communication with the RSE, and to notify the application processes. It provides amongst others a multi-application switching mechanism, allowing for execution of several RTTT applications (in parallel) at one RSE station. The transaction phase can only be reached

45、after completion of the initialisation phase. The EFC functions, as defined in Clause 7, can be performed in the transaction phase. The GET and SET services (DSRC application layer functions) as defined in EN 12834/ISO 15628 (in 6.2) may also be used in an EFC transaction phase. 6.2 Initialisation P

46、hase 6.2.1 Overview This clause provides an overview of the functionality of, and the information exchanges in, the initialisation phase. The Initialisation procedures, by means of beacon service table (BST) and vehicle service table (VST) exchanges, are defined in EN 12834/ISO 15628 6.2.2 and 6.2.3

47、 below account for the EFC application-specific information that shall be included in the BST and VST, respectively. NOTE The OBE evaluates the received BST, and selects the applications that it wishes to perform out of the lists of applications supported by the RSE. If the OBE does not support any

48、of application(s) supported by the RSE, then it is recommended that the OBE does not exchange any information with the RSE. If the OBE supports at least one of the application(s) supported by the RSE, then it is recommended that the OBE informs the RSE of which application it wishes to execute in its corresponding VST. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-BS EN ISO 14906:2011ISO 14906:2011(E) ISO 2011 All rights reserved