1、ICS 35.240.60;03.220.20 R 07 昌中华人民共和国国家标准GB/T 20610-2006/ISO/TS 14904: 2002 道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范Road transport and traffic telematics-Electronic fee collection(EFC)-lnterface specification for clearing between operators (ISO/TS 14904: 2002, IDT) 2006-11-07发布中华人民共和国国家质量监督检验检在总局中国国家标准化管理
2、委员会2007-04-01实施发布GB/T 20610-2006/ISO/TS 14904 ,2002 目次前言.I 1 范围2 规范性引用文件. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 术语和定义4参与方之间的清分接口.3 5 接口规范36 消息定义方法.7 7 消息8附录A资料性附录）概念模型.10 附录B（资料性附录）概念模型与现实运营要素间的关系.11 附录c（资料性附录）消息帧说明15附录0（资料性附录）消息帧定义u附录E（资料性附录）基于GB/T15150 1994数据元创建的支付对象2
3、5参考文献.、.27 GB/T 20610-2006/ISO/TS 14904 ,2002 ,.&.&., 目。言本标准等同采用ISO/TS14904, 2002道路运输和交通控制电子收费系统（EFCl参与方之间信息交互接口的规范（英文版）。为了便于使用，本标准做了下列编辑性修改ga) 删除了ISO/TS14904, 2002的前言；b) 删除了ISO/TS14904,2002的引言。本标准的附录A、附录B、附录C、附录D、附录E均为资料性附录。本标准由交通部公路科学研究院提出。本标准由全国智能运输系统标准化技术委员会（SAC/TC268）归口。本标准起草单位z北京云星宇交通工程有限公司。本标
4、准主要起草人z徐志斌、陈日强、傅宏杰。GB/T 20610-2006/ISO/TS 14904:2002 道路运输与交通信息技术电于收费（EFC）参与方之间信息交互接口的规范1 范围本标准是关于道路运输和交通信息技术电子收费（EFC）中参与方之间信息交互接口，及其相关的公共消息结构框架和数据元素的规范。本标准制定的目的在于实现电子收费CEFC）中不同收费系统之间和不同运营方（如收费代理方、清分服务方和服务提供方之间收费相关业务的数据交流。本标准支持不同的应用：不同的付费模式（例如g预付费，后付费川一一多种运输种类和运输相关的服务（公路通行费、停车费、渡口、桥梁和隧道通行费、公共运输费、路径引导
5、服务费及其他付款h各种运营服务（参与方间的协作）; 涉及上述不同收费应用的数据的安全性和保密性。本标准不包括对监管过程及组织结构的定义，不适用于更高级别标准。本标准不涉及非直接参与方，如政府，执法、立法等国家机构。本标准运营模型是通用的。实际运营系统可在本标准中选择相应的接口框架。2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T 17902. 1 1999信息技术安
6、全技术带附录的数字签名第1部分概述ISO/IEC 8825-1 信息技术ASN. l编码规则基本编码规则(BER）、标准编码规则CCER）和差别编码规则(DER）的规范3 术语和定义下列术语和定义适用于本标准。3. 1 分账apportionment 服务提供方依照所提供的服务量，获得用户所支付的相应服务费用。例：公共汽车经营者根据运送客户的数量而获得相应的服务费用。3.2 连锁服务chained services 多种相关服务组合在一起形成连锁服务。连锁服务中对某总消费服务提供优惠或特权。优惠的前提通常基于用户先前消费服务的累积结果。3.3 清分clearing 清分是由清分服务方提供的一种
7、服务在一个收费系统中按照账目拆分原则和清算规则，将从用户GB/T 20610-2006/ISO/TS 14904,2002 处收取的服务费用，分配给各服务提供方。它体现了参与方间的商业协议关系。例如：服务提供方通过清分得到发行方收取用户的服务费用中应得的部分。3. 4 清分服务方clearing operator (CO) 清分服务方收集一个或多个的服务提供方的交易信息，将单个服务提供方应得的交易金额划拨到该服务提供方，将多个服务提供方共同产生的交易金额在它们之间进行分账。3.5 收费代理方collection agent (CA) 收费代理方负责向用户介绍和推广付费的方式，并向用户收取服务费
8、用以及收集用户的相关数据和信息。3.6 合同contract 两个或更多的参与方在一个收费系统中或若干个收费系统之间合作协议的说明。例如，用户合同是用户和服务提供方在有偿服务系统中的关系，在这种情况下合同确定了用户可使用的服务和应支付的费用a3. 7 电子钱包electronic purse 货币的一种电子形式，以电子信息的形式存储在IC卡里，可以以安全认证的方式操作和储存，用于代替现金付款。3. 8 电子收费electronic fee collection 又称自动收费，在服务提供方和用户之间的服务与付费过程不直接用现金进行交易，而是通过数据交换实施的，可以是现场实施的，如使用电子钱包；也
9、可以是后台清分，如银行转账服务等o3. 9 监管方enforcement operator 追查服务提供方所检举的违规行为。3. 10 收费系统integrated payment system 涉及运营模型的金融系统，在这个系统框架中运营方之间和收费系统之间进行资金划拨和信息交换。3. 11 发行方issuer (IS) 发行方是负责将服务提供方提供的各种服务销售给用户的实体，设计付款方法并向用户陈述、宣传，代理开户业务并收集与用户相关的用户特征信息。3. 12 参与方operator 对各种实体如z清分服务方，收费代理方，服务提供方，监管方和可信任第二方的总称。3. 13 付费手段paym
10、ent means 通过发行方（或收费代理方）与用户之间的服务销售合间，规定的用户支付所获得服务费用的方法。如通过银行账户划拨服务费用或使用电子钱包现场付费等。3. 14 付费方式payment method 付费手段、付费模式和付费范围的合称。GB/T 20610-2006/ISO/TS 14904, 2002 3. 15 付费模式payment mode 根据用户支付服务费用的时间分为预付费和后付费。3. 16 付费范围payment scope 由服务提供方提供，由用户享受的交通运输或与交通运输相关部分的有偿服务范围，如全国或区域范围。3. 17 收费系统payment system 包
11、括从发行、收费、清分和交易整个业务流程在内的财务系统。3. 18 服务提供方service provider (SP) 直接为终端用户提供服务，并且通过服务获得商业收益的实体，可以是个体的人、公司、公共资产所有者、运营方。如道路所有者将道路提供给车辆使用并收取通行费，个体出租车司机为乘客提供服务收取车资等。服务使用费在一些情形中可能为零，例如在紧急情况下的紧急交通工具。3. 19 清算settlement 清算是由金融服务平台提供的一种服务，根据清分服务方提供的清分结果，将用户交付的服务费用，分配到各服务提供方的收款账户中，或者在多个收费系统中划拨资金。3.20 可信任第三方trusted t
12、hird party 负责运营监管，系统和安全评估（包括安全密钥管理，以及发放许可。3.21 用户user (US) 根据合同条款享受服务提供方的各种服务并支付相应的费用的实体。用户一般通过收费代理方获取服务并支付费用。4 参与方之间的清分接口本标准规定了收费系统运营方之间的基本接口，见表1,（参见附录A和附录B)表1本标准涉及的参与方接口参与方本标准不适用的范围本标准适用的范围运营方与运营方 用户与服务提供方 收费代理方与用户 注丰标准所定义的接口规范可允许增设用于不同收费系统间整合或运行时所需的参与方之间的通信通道。5 接口规范5. 1 目的本节定义在各个参与要素之间进行数据交换时采用的通
13、用消息格式。通用消息结构参见附录C中详细说明。注2如果未对消息类、消息类型、发送ID、接收ID、消息ID进行特别说明，它们将采用标准定义。GB/T 20610-2006/ISO/TS 14904: 2002 5. 2 消息结构消息结构传输可遵从本标准定义，也可采用其他通信协议定义，如TCP/IP, XML/EDI FACT 0 图1是电子收费EFCl的相关协议数据单元的数据结构的一个范例其中的数据对象可进行全局或单独加密。清且帧消息樊图1消息结构5. 3 标志字段标志字段是消息的开始部分，标志字段包含有版本号。版本号以数字类型表示，它标识了消息所采用的通讯协议版本。因为它存在于消息的第一个部分
14、，接收方根据它判断传输数据所使用的协议版本。注，ENV ISO 14904: 1997定义了消息通讯协议第一版a5. 4 消息帧按照图1定义，参见附录C中详细说明。5.5 披据安全电子收费（EFC）系统的数据保密体系主要用于保护各参与方的利益，保证数据的可用性、机密性、完整性和不可抵赖性并防止泄露用户隐私。系统中各参与方的相关数据对于其自身利益有着重要的意义。为达到涉及多个参与方的封闭系统的安全要求，本标准的接口规范考虑了在更高一级的收费系统中能适用，并且便于以后对规范的安全保密等相关项目进行补充。消息中的保密数据和保密数据对象构成了保密数据体系。相关的数据安全特性如下：机密性敏感数据应只可被
15、授权方使用。除了易于修改的财务交易数据外，一些在同一完整性认证不可抵赖性接口进行传输的信息如交易量、运营类型、网络参数等也是敏感信息。在目前对保密要求越来越高的情况下这些信息也很敏感。数据应是完整的，能够侦测到任何未经授权的修改。（内容和消息顺序的完整）数据和数据收发双方是经过认证的。（消息源认证、消息目标认证、对等实体认证）数据操作者参与了全部或部分数据交流后是能够确认的，不可否定的。应提供以下3个层次的确定性：确认发送方；确认正确传输，一一确认提交操作的操作者。可用性授权用户可以得到所需数据。审计通过使用时间变量参数，防止对数据的恶意破坏。能够说明数据的流程，如提供管理性的操作历史记录。G
16、B/T 20610-2006/ISO/TS 14904 :2002 5. 6 安全性和保密性电子收费CEFC）系统强调数据的安全性和保密性，其体系结构中专门进行了数据保密体系设计。涉及用户个人的隐私资料在系统内部和系统之间（如参与方之间的清分）存储和处理的过程中不会泄露。5. 7 鼓据保护体系图2所示模型阐述了数据保护模块的设计和运行主要元素之间的基本关系。事与方和用户层法掉与回事制度框蝇/ 应用域的需革和阻制罩绕层图2EFC系统数据保护体系模型图2中参与方和用户层的数据保密政策是根据系统总体需求、运营方和用户的要求、风险分析以及基本的数据保密原则制定的。风险分析主要由对以下3部分的评估所构成
17、：EFC系统数据安全的威胁要素，发生的可能性和发生的后果。它和数据保密措施、总体要求及目标一起详细定义了总体保密要求。这些要求用来解决EFC系统中出现的问题，消除其影响。定义这些相应措施时按均衡原则考虑了应用域的限制和外部要求与执行这些措施的成本之间的关系。确定系统数据保密政策和数据保密要求时要充分考虑法律法规、制度框架和应用域的限制和外部要求。最后，在再评估过程中，对系统的运行进行审计，对风险及其可能性和影响形成评估报告。5. 8 鼓据保护方法图3给出了数据保护的方法。GB/T 20610-2006/ISO/TS 14904 ,2002 参与方之间情分时的最据保护要求数据安全性可行措施量据章
18、圭的解在方法选择处理量据保密性可行措施量据保密的解战方法EFC革统管理的具体方法和机制EFC罩统运行的具体方法和机制圄3数据保护方法说明5. 9 密钥及密钥管理本节给出的密钥及密钥管理规则在结算过程中具有重要作用，应符合GB/T17902. 1 1999的规定。5. 9. 1 密钥在依赖于加密技术的电子收费系统中应保证密钥不被泄露、更改或删除。一般而言，密钥以树型结构保存。上一级的密钥用于保护下一级的密钥；最下层的密钥用于提供安全服务。安全系统一般包含两类密钥a) 用于加密数据的密钥：b) 用于加密密钥的密钥。通常第二类密钥比第一类更加重要。安全应用模型CSAM）会对提供密钥安全储备。密钥的生
19、命周期见图40 5. 9. 2 密钥管理密钥管理的目标是对密钥管理服务的过程提供安全保障，它主要包括密钥生成、密钥注册、密钥验证、取消密钥注册、密钥发行、密钥保存、密钥存档、密钥恢复、密钥删除、密钥派生、销毁密钥等。系统的各组成元素，如服务提供方、可信任第三方等，可根据其身份使用不同的密钥管理服务。密钥管理见图5。密钥在生命周期内处于何种状态是由其采用的安全保密系统所决定的，这意味着密钥管理使用对称和非对称技术。5.9.3 密钥发行密钥可在一个或者两个安全域中发行。在一个安全域中，两个需要共享密钥的单位可以直接共享密钥，也可以通过一个单独的密钥发行中心产生共享密钥。使用密钥发行中心的方式还可用
20、于在相互信任的安全域之间分发密钥，一方产生和分发的密钥可供另一方使用。见图6。GB/T 20610-2006/ISO/TS 14904,2002 重新激活密钥图4密钥的生命周期图5密钥管理服务授权中心A授权中心B实体A实体B图6密钥发行6 消息定义方法接口消息的数据结构定义采用抽象语法表示法第一版（AbstractSyntax Notation One, ASN. 1)。使用该表示法可以定义明确而又灵活的通用数据类型。这些数据结构定义不依赖于任何一种特定的编GB/T 20610-2006/ISO/TS 14904:2002 程语言，从而使用各参与方均可理解与修改。将通过抽象方法定义的数据类型转
21、换为可传输的数据流，需使用适当的编码规则。抽象语法符号采用根据ISO/IEC8825-1所定义的基本编码规则BER(Basic Encoding Rules）来规定接日消息的数据结构。接口使用双方也可根据各自需求协议一致采用不同的编码规则。注1,ASN. l是一个定义基础数据并以此可建立新的数据元素的正式语言。接口规范中所用的数据类型都是采用ASN. l所定义。ASN.1允许定义抽象语法，以陈述应用层标准，以此来定义信息传输的类型。注2,BER是可以使ASN.l转化成为一种所有数据类型都可由标签、长度、数值来定义的编码规则注3，由于所有数据类型都是由ASN.l统一定义，所以它们可采用不同的编码
22、规则来实现转换。目前最为常用的编码规则有两种2基本编码规则BER(BasicEncoding Rules）和分组编码规则PER(PackedEncoding Rules）。本消息定义方法包括了接口双方所需所用的基本数据元素，也可根据实际进行增加额外的数据元素。本标准以外的参与方也可利用本协议进行通信。7 消息消息类型包含不同运营要素间交换的所有数据。详细说明见5.2、5.3和附录CMessage : = SEQUENCE version INTEGER data ProtocolDataUnit versionl (1) , version2 ( 2) 每条消息以表示通讯协议版本号的整型数字开
23、始。版本号后是数据部分。因为消息的第一个元素一定是表示版本号的数字，所以接收方可以直接得到当前消息使用的通讯协议版本，以便后续处理。本标准定义为版本L8 ProtocolDataUnit可以有两种组成方式zProtocolDataUnit : ：二CHOICE EFCrelated OJ EFCRelated-PDU, other EXTERNAL EFCRelated-PDU : : = CHOICE glo ballySecuredEFCDa ta EXTERNAL, locally Sec uredEFCDa ta LocallySecuredEFCData 注：LocallySecme
24、dEFCData决定数据对象是否与安全对象关联，它可以单独设定和解除数据对象的保密状态。LocallySecuredEFCData参见附录DGB/T 20610-2006/ISO/TS 14904: 2002 外部数据类型用于本系统中引用其他标准定义的数据结构。例如，两个运营方之间已使用了一种通讯协议，在加入以本标准实施的系统后仍想使用原有协议交换部分数据，便可以将原有协议的数据结构包含在本标准的数据结构中。对于外部数据类型的数据，卒标准不予说明。外部数据类型通过标识来声明包含了哪些数据类型。哪些数据类型为外部由双方协商而定，或采用全局的对象标识。本标准未对标识进行定义。GB/T 20610-
25、2006/ISO/TS 14904 ,2002 附录A（资料性附录）概念模型本标准定义的规范基于对一般收费系统现实模型及其关系进行抽象而得的概念模型。这个概念模型有以下特点za) 严格按本标准设定pb) 对大多数情况有效，适用从简单的只有一项服务的本地运输系统到涉及多种服务，包括有服务提供方、收费代理方、发行方和清分服务方等的复杂系统；。适用多种组织模型；d) 兼容财务系统内使用的模型。图Al中所示的概念模型用抽象实体灵活有效地反映了现实中的组织结构。当前和未来运输系统的组织结构渐趋复杂，使用概念模型更能灵活高效地阐述说明各种类型的系统组成。概念模型中的各项实体是抽象的，并不一定能直接构成现实
26、组织。这样会出现以下结果：a) 概念模型中的抽象实体并不一定有对应完成这些功能的独立单位，这只取决于现实中组织的结构设定情况，如清分服务方和收费代理方就在现实中对应存在；b) 概念模型中不考虑如何盈利，c) 概念模型对现实运输系统模拟较为完善，并与财务系统中的模型兼容。概念模型定义了图A.l所示的运营参与要素，它们构成链状合同逻辑关系。固A.1概念模型这个概念模型结合了财务和运输系统的收费系统特点，支持预付费和后付费。注lz本概念模型中的要章与现实中的实体对应。（参见附录B)注2：本标准定义信息交互接口规范主要应用于图A.I中以实线连接的各参与方。但在定条件下，该规范也可应用于以虚线连接的各参
27、与方。在prENVISO 17573道路运输与交通信息技术EFC车辆运输服务系统框架模型中对收费系统模型有更为详细的描述。JO GB/T 20610-2006/ISO/TS 14904,2002 附录B（资料性附录）概念模型与现实运营要素间的关系本附录将提供实例讲解概念模型与现实运营要素间的关系。目前的电子收费（EFC）系统中还不存在一个能适用于任何情况的通用的组织结构。根据自治优先原则，本概念模型对收费系统及不同收费系统之间参与方的组织结构要求未作过于严格的限定。为使适用范围更为广泛，本概念模型完全采用抽象实体来描述现实的组织结构。有些抽象实体并不一定在现实组织中有对应的独立单位，如有些收费
28、系统并没有清分服务方或收费代理方。概念模型通过采用通用的抽象实体把现实的收费系统的组织结构进行了抽象并建立一个通用的模型。这使得模型抛开了收费系统的技术因素，只考虑其业务流程和财务运作的因素，从而适用于更广泛的范围。通过这样的抽象概括，概念模型中的抽象实体通过不同的组合能体现现实付费系统中的组织结构的工作运作过程。同时这意味着现实收费系统中的一个独立单位就能实现概念模型中的一个或多个抽象实体的功能，如某个收费系统用一个独立单位来行使发行方和清分服务方的功能。一个独立实体具体实现概念模型中哪些抽象实体的单独或组合功能是由实际情况决定的，可以是一个抽象实体对应一个独立实体，主H某独立实体只负责提供
29、硬件设备或提供付费手段，或只提供服务等情况；也可以是组合除用户外的抽象实体的功能。示例说明见图B.1。为简化模型，可信任第三方和监管方未予列出。监管方通常就是服务提供方。而可信任第三方则通常是一个对安全（如密钥安全）负责的外部的公司或部门。所以可信任第三方被看成是独立于示例中五个要素之外的实体。示例中，IS表示发行方，co表示清分服务方，CA表示收费代理方，us表示用户，SP表示服务提供方。a b) 图B.1 概念模型中与现实实体相对应的抽象实体组合11 GB/T 20610-2006/ISO/TS 14904,2002 12 IS 发行方5CA 收费代理方$SP 服务提供方pco-清分服务方
30、zus用户。cl e) g) d) f) h) 固B.1(续）GB/T 20610-2006/ISO/TS 14904:2002 图B.la）表示组成整个系统的5个要素分别由独立的实体构成。每个实体只负责对应系统要素所需承担的工作，各实体在功能上没有交叉。服务提供方只负责提供服务，由其他实体来向用户收取费用。图B.lb）表示一个实体即负责发行方的工作又承担收费代理方的角色，其他实体各自负责对应系统要素的工作。服务提供方只负责提供服务，由其他实体来向用户收取费用。图B.lc）表示一个实体承担发行方以及清分服务方的工作，其他实体负责与系统要素对应的职责。在这情况下不必设立清分服务方，而仅需保留其功
31、能。服务提供方只负责提供服务，由其他实体来向用户收取费用。图B.ld）表示一个实体执行清分服务方与服务提供方的工作，其他实体负责与系统要素对应的职责。如现实情况中服务提供方为发行方提供数据。图B.le）表示一个实体负责发行方、收费代理以及清分服务方的工作，由另一个实体负责为用户提供服务。在这情况下不必设立清分服务方，而仅需保留其功能。这个实体承担了收费的全部工作。服务提供方只负责提供服务，由其他实体来向用户收取费用。图B.10表示一个实体负责收费的所有工作。这常见于只有个服务提供商的封闭系统。图B.lg）表示一个实体承担服务提供方、收费代理方和清分服务方的工作。在这情况下不必设立清分服务方，而
32、仅需保留其功能。如实际中的多种服务的使用费用由发行方使用同一张收费卡进行收取。图B.lhl表示一个实体承担服务提供方和收费代理方的工作。如运输公司提供运输服务和票务发行。图B.2所示为多个单独收费系统组成的多收费系统模型。其中可信任第三方和监管方未列出。外部实体s电信公司、世备制造商、罩统集成商等A川HO一有川HVsd A川川川V一玄川川VAH川AV一六甘HHV付费革统(PS) / AH门忡VA川川V外部主体政府部门图章盘，地区组等图B.2 多收费系统模型/ 13 GB/T 20610-2006/ISO厅S14904,2002 图B.2的概念模型所示的是独立收费系统之间以及它们和不同外部实体之
33、间的数据交流。这些外部实体包括提供网络服务提供方或发放营业许可的政府相关机构。从图中我们可以看出，每个收费系统并不是只通过发行方和清分服务方进行外部数据交流，由于本标准的灵活性，它允许不同收费系统中的各参与方之间直接进行信息交流。14 GB/T 20610-2006/IS0/1百14904:2002c. 1 简介附录C（资料性附录）消息帧说明消息帧包括核心数据POU(ProtocolData Unit），不同的协议数据单元可用来定义消息帧。消息帧可由EFCPOU或外部的POU来定义：注g外部PDU包括zGB/T 15150 PDU、CEN/TC224PDU、EDIFACTPDU等。EFC PO
34、U的消息帧包括以下元素：消息类；消息类型，发送ID;接收ID;一一消息ID号事消息字段区。这些元素在c.2 c. 7进行说明eC.2 消息类me皿ageclass 消息类定义消息本身所完成的基本任务，所有的消息都属于以下6类消息类：请求、请求应答、建议、建议应答、通知、通知确认。C.2. 1 请求r呵nest请求是发送ID向接收ID要求执行某种操作，传输某种信息的消息类型，如确认交易信息和计算分账金额等。C. 2. 2 请求应答request response 作为对发送ID请求的回应，接收ID在执行相应操作后以本类消息向发送ID汇报执行结果或返回信息。c. 2. 3 建议advice 发送I
35、D向接收ID发送的一组对系统运行非常关键的信息，如用户状态名单或密钥管理信息等。c. 2. 4 建议应答advice r回ponse作为对建议的回应，此类信息不包含任何数据，仅表示接收到的建议是否被采纳。c. 2. 5 通知notification 发送ID向接收ID报告发送ID或第二方己执行的操作，例如发送方己生成了分账报告并发给了收费代理方。c. 2. 6 通知确认n。“ficationresponse 向通知的发送方确认是否正确接收了通知。15 GB/T 20610-2006/ISO/TS 14904: 2002 C.3 消息类型m田sagetype 承担收费系统各项功能的数据对象在接口
36、间进传输时根据消息类型进行分组。消息类型说明消息中包含的是何种数据，初步定义如下14类C.3. 1 服务列表service list 服务列表包含一组可为用户提供的服务。发行方可以通过该消息通知收费代理方收费系统己可为用户提供新的服务，收费代理方可以通过该消息从发行方那获取停车，通行费用等来告知用户。c. 3. 2 价目表fare products list 用于提供新的价目表或修改已有的价自表。发行方可以通过该消息通知收费代理方能提供的服务和产品及其价目。C.3.3 用户信息customer details 包含用户的信息，可在开户时使用。示例I收费代理方可以通过该消息告知发行方用户的个人资
37、料示例2，发行方可以通过该消息通知清分服务方用于清分结算的相关信息如交易的折扣信息和连锁服务的费用抽取等。c. 3. 4 分账规则japportionm四trules 向接收ID声明修改或增加新的分账规则。发行方可以通过该消息通知收费代理方向发行方划账的规则。示例1发行方通知收费代理方提交收费时的规则，包括应摘取的费用数量和比例等。示例2清分服务方在清分时可以通过该消息获知分账规则，如连锁服务中对用户进行了折扣时，清分服务方将对此予以考虑。C.3.5 对账总金额reconciliation totals 各个系统元素之间通报清分金额。示倒2丰消息用于查询邑金额。如清分服务方向服务提供方查询其营
38、业额。c. 3. 6 授权authorization 用于发行方对某一交易进行在线授权。C.3. 7 交易transaction 包含发生的交易信息。示例本消息包括收费代理方详细的销售记录和服务提供方与清分服务方之间的交易记录。本消息包含详细的交屠细节。c. 3. 8 报告巳发送report sent 发送ID通知接收ID报告已发送。c. 3. 9 密钥管理key management 本消息包含密码等与加密有关的信息。示例发行方通过该消息告知清分服务方新的密钥或采用一套新的加密方案16 GB/T 2061 0-2006/ISO月S14904,2002 c. 3. 10 状态名单status
39、list 用于标识服务提供方、用户或其他系统要素的状态。接收ID从数据的类型（请求、建议、通知）判断如何设定状态名单。示例z状态名单中不一定只喜付费一方的名单，在发行者向清分服务方发送的状态名单中可能包括服务提供方提供的黑名单，如服务提供方不再提供某项服务。C.3.11 设备状态吨uipmentstatus 本消息包含各个设备的状态。示例I丰消息标示设备的状态，如有效、试运行、失效等。示例2，本消息也可用于向清分服务方发送某一总量限制，如交易中的设备数量，c. 3. 12 例外事件event exception 此类消息用于特殊情况下确保交易数据的正确处理。示例本消息可用于传送抓拍图像，记录事
40、件发生时的情况。c. 3. 13 接受付费方式payment method acceptance 发行方按规则和补充协定通过此消息确认接受一种付费方式和相关信息，如现金交易、最大交易额或要求交易记录等。c. 3. 14 未定义的消息类型undefined me臼agetype 此类消息表示消息体中的消息类型值是未定义的。C.4 发送IDsender ID 发送ID是发送方在系统中的标识。它可分为简单类型和复杂类型两种。简单类型将发送ID作为一个抽象实体，复杂类型在收费系统中应是唯一的。示例z发送ID的数字编号按x.501或GB/T15694及其他编号规则确定。C.5 接收IDreceiver
41、ID 接收ID是接收方在系统中的标识。和发送ID一样，它也可分为简单类型和复杂类型两种。简单类型将发送ID作为一个抽象实体，复杂类型在收费系统中应是唯一的。C.6 示例接收ID的数字编号按x.501或GB/T15694及其他编号规则确定。注发送ID和接收ID的规定不适于“用户”。消息ID号me田ageID 作为消息的标识，它与发送ID、接收ID一起在整个系统中唯一确定一条消息。接收ID在返回消息中应包含对应的消息ID号。这使得每个消息的反馈都唯一对应其原始消息。c. 7 消息字段区m四sagebody 消息字段区包含一个或多个消息对象。17 GB/T 20610-2006/ISO月S14904
42、,2002 按下列格式定义消息帧。D.1 概述附录D（资料性附录消息帧定义在“7消息”中引用的EFCRelatedPOU包含有内部安全数据（LocallySecuredEFCData），定义如下gLocallySecuredEFCData : : = IMPLICIT SEQUENCE messageClass MessageC!ass message Type Message Type sender ID Sender AndReceiverd!D recetver!D Sender AndReceiverdID message!D Message ID messageBody 1essag
43、eBodyD.2 消息分类（M回回geCiass)所有消息均属于6种工作类型之.MessageClass = ENUMERATED Request (0), RequestResponse (1), Advice （幻，AdviceResponse (3), Notif1cation (4), N otificationAcknow ledgement ( 5) D.3 消息类型CM四sageType)D. 3. 1 概述消息类型MessageType包含如下的不同类型的数据。18 OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, GB/T 2
44、0610-2006/ISO/TS 14904: 2002 MessageType = ENUMERATED Services List (1), FareProductsList (2), CustomerDetails (3), ApportionmentRules ( 4), ReconciliationTotals (5), Authorisation （们，Payment (7), ReportSent (8), KeyManagement （幻，StatusL1st (10), EquipmentStatus (11) , EventException (12) , PaymentM
45、ethodAcceptance (13), Undefined Message Type 04), Undefined Message Type (1日，Undefined Message Type (16), Undefined Message Type (17), Undefined Message Type (18), Undefined Message Type (1的，D. 3. 2 付款（Payment)Payment对象描述一项交易中的付款情况，可选择不同的支付方式。Payment = SEQUENCE payment Type OBJECT IDENTIFIER, paymen
46、tContent ANY DEFINED BY paymentType a) 单一账户收费SimpleAccountPayment用对只需最少数据的情况，如其他类型数据都为隐含或只存储在中心时。SimpleAccountPayment = IMPLICIT SEQUENCE accountNumber, AccountN umber, transact10nAmount Amount, da teLocalTranactIOn N umericString 19 GB/T 20610-2006/ISO/TS 14904,2002 accountNumber是用来标识一项交易的数字，它的内容取决
47、于付费方式，如预付费卡的卡号或银行账号等。AccountNumber = CHOICE simple!D OJ Entity ID, cenTC224WGlllD l CENTC224WG11-ID 取自ENV1545-1 X50l!D 2 X501-ID, 取自GB/T16264 2005 IsoTC204飞!VG4ID3 lsoTC204WG4 ID 一取自ENVISO 14816亿b) 银行卡付费BankCardPayment的数据结构涉及以下业务范围预付费、后付费、用户账户、中心账户和一系列付费方式如信用卡和借记卡等。它是基于GB/T15150数据元创建的支付对象5wg9Payment和wglOPayment是由CEN/TC224标准定义的支付对象；wgl lPayment是由ENV1545标准定义的支付对象。D.3.3 报告已发送（ReportSent)此类消息表示报告数据已经发送。ReportSent = SET reportNumber OJ IMPLICIT INTEGER sentData l IMPLICIT UTCT1me sentTo 2 IMPLICIT PrintableString reportText 3 IMPLICIT PrintableStnng 以上各对象的定义由报告发送
