CN103679823A - 兼容多种应用的obu及其实现方法、etc系统、及obu初始化 - Google Patents

Abstract

本申请公开了一种兼容多种应用场景的OBU及其实现方法、以及采用该OBU的ETC系统及OBU初始化方法。其中，实现方法包括：在车载单元的安全应用模块中建立分别对应多种应用场景的文件结构；将多种应用场景的服务原语增加到车载单元的应用层；车载单元的数据链路层中增加多种应用场景的各时间指标或各时间指标的整合结果。本申请通过事先建立好各级文件目录以适应不同的应用场景，使得若有新增应用时仅需增加相应的目录文件，不需要对OBU软件做任何改进；此外，OBU的应用层支持多种应用的服务原语，且数据链路层也支持多种应用的时间指标，从而OBU可兼容多种应用，不仅降低二次开发和维护成本，也提升了OBU产品的竞争力。

Description

兼容多种应用的OBU及其实现方法、ETC系统、及OBU初始化

技术领域

本申请涉及智能交通（Intelligent Transportation System，简称ITS）领域，尤其涉及一种兼容多种应用场景的电子不停车收费（ETC，Electronic TollCollection）车载单元及其实现方法、以及采用该车载单元的ETC系统及OBU初始化方法。

背景技术

随着智能交通技术的飞速发展，其应用范围由最初的高速路应用逐渐向城市的交通管理渗透，如武汉地区的自由流应用、北京部分小区的停车场应用、深圳的一卡通应用等。部分运营商和厂商已开始研究建立一个公共平台以兼容各种应用需求的可行性。

发明内容

根据本申请的第一方面，提供一种兼容多种应用场景的车载单元的实现方法，包括：文件整合步骤，在车载单元的安全应用模块中建立分别对应多种应用场景的文件结构；服务支持步骤，将多种应用场景的服务原语增加到车载单元的应用层；时序支持步骤，将多种应用场景的各时间指标增加到车载单元的数据链路层，或者将多种应用场景的各时间指标进行整合，并将整合结果增加到车载单元的数据链路层。

根据本申请的第二方面，提供一种兼容多种应用场景的车载单元，包括：文件整合模块，用于在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，该多个应用目录装载与之对应的应用场景的相关信息文件；服务支持模块，用于将多种应用场景的服务原语增加到车载单元的应用层；时序支持模块，用于将多种应用场景的各时间指标增加到车载单元的数据链路层，或者将多种应用场景的各时间指标进行整合，并将整合结果增加到车载单元的数据链路层。

根据本申请的第三方面，提供一种采用上述车载单元的电子不停车收费系统。

根据本申请的第四方面，提供一种电子不停车收费的实现方法，包括通信链路建立及应用信息获取阶段，该阶段包括：发送步骤，路侧设备向车载设备发送信标服务表BST信息，所述车载设备包含如上所述的车载单元；应用选择步骤，所述车载单元根据所述信标服务表BST信息选择与之对应的应用场景的相关信息文件；反馈步骤，所述车载单元根据所述相关信息文件发送车辆服务表VST信息给所述路侧设备。

根据本申请的第五方面，提供一种车载单元的初始化方法，包括：发行前在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，该多个应用目录装载与之对应的应用场景的相关信息文件，所述相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件；根据上位机发来的发行指令发行车载单元。

本申请的有益效果是：在OBU的安全应用模块中事先建立好各级文件目录以适应不同的应用场景，使得若有新增的应用场景时仅需增加相应的目录文件，不需要对OBU软件做任何改进；此外，OBU的应用层支持多种应用场景的服务原语，并且OBU的数据链路层也支持多种应用场景的时间指标，从而OBU可兼容多种应用场景，同时不仅极大地降低二次开发或后期维护成本，也极大地提升了OBU产品的竞争力。

附图说明

图1为本申请一种实施例的兼容多种应用场景的OBU的实现方法流程示意图；

图2为国标ESAM的文件结构示意图；

图3为自由流应用ESAM的文件结构示意图；

图4为本申请实施例车载单元ESAM整合后的文件结构；

图5为本申请实施例的车载单元发行的处理流程示意图；

图6为路侧设备与车载设备信息交互的示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明作进一步详细说明。

电子不停车收费（ETC，Electronic Toll Collection）利用安装在车辆上的车载设备（OBU）与安装在路侧的路边设备（RSU），在需要收费的地点在车辆行驶过程中进行信息交换，从而实现不停车完成整个收费过程。ETC的应用场景有多种，包括自由流应用、国标ETC应用、停车场管理等。自由流应用属于无障碍通行，不分隔车道和设置栏杆，车辆不限定车道行驶，并可以高速通行，因此采用后台计费的方式，而国标ETC应用可通过后台计费或直接扣费。

这里以国标ETC、自由流、停车场三种应用场景中的OBU为例进行说明。对于国标ETC应用场景中的OBU，其硬件平台包括射频（如5.8G射频）、微处理器MCU、智能IC卡、嵌入式安全应用模块（ESAM，Embedded SecureApplication Module）等，应用流程包括一次发行、二次发行、激活和交易；对于自由流应用场景中的OBU，其应用流程与国标ETC应用场景相同，但其硬件平台与国标ETC应用场景的差别在于不需要智能IC卡；而对于停车场应用场景的OBU，其除了射频、MCU外，智能IC卡和ESAM为可选。这三种应用场景的共同之处包括：硬件驱动完全相同，例如读卡驱动都遵守ISO7816和ISO14443TYPEA标准；物理层参数都遵循或参照国标；协议层服务原语都遵循或参照国标；OBU仅作通道实现外设之间的信息交互而不参与ETC系统的逻辑控制。尽管存在着一些共同之处，但这三种应用场景还存在着不同点包括：硬件组成结构不尽相同，例如高速公路上使用的OBU可以满足自由流和停车场的应用，但反之则可能不行；ESAM文件结构不尽相同，例如存储车辆信息和密钥信息的文件目录不同；发行和交易流程不尽相同，例如自由流应用中的时间窗申请是其它两种应用场景所没有使用的；停车场应用目前较为简单，只是读取一下I D号即可。这些存在的不同点这使得目前的OBU应用至少具有如下缺陷：如果需要既应用于自由流又应用于国标ETC收费，使用者需要在一台车上安装多个OBU，既增加成本又占用车辆空间，甚至可能干扰ETC的交易流程。

基于此，本申请在遵循关于DSRC应用的国家标准的基础上，设计一种新的OBU软件平台来实现对多种应用场景的兼容。

从ETC的应用场景来看，涉及到的OBU分为单片式和双片式两种。其中，单片式在物理结构上是一个不可拆分的整体，既存储了车牌号、车型等车辆物理参数，也记录了用户的消费账号、账户金额方面的信息，其应用于不需要IC卡的场景如武汉的自由流应用；双片式通常由固定安装的车载机和可插拔的IC卡两部分组成，车载机里存储了车牌号、车型等车辆物理参数，而用户的消费账号、账务金额方面的信息则存储在IC卡里面，其应用于需要IC卡的场景如高速路收费站等。

鉴于单片式OBU和双片式OBU都是基于专用短程通信技术（目前为5.8G专用短程通信）实现，差别只是是否具有操作IC卡的物理接口，其余硬件平台可完全统一，因此，本申请的设计出发点是提供一个共用软件平台，借助这一软件平台，通过对应用场景的自动识别启用相应的协议进行信息交互，从而为实现如国标ETC、停车场、自由流等ETC应用的相互兼容提供了具有可操作性的技术支撑。

实施例1：

本实施例提出了一种兼容多种应用场景的ETC车载单元的实现方法，如图1所示，包括：

文件整合步骤S101，在OBU的安全应用模块中建立分别对应多种应用场景的文件结构；具体是指，在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，该多个应用目录装载与之对应的应用场景的相关信息文件，其中，OBU的安全应用模块包括ESAM，相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件。

服务支持步骤S103，将多种应用场景的服务原语增加到车载单元的应用层；

时序支持步骤S105，将多种应用场景的各时间指标增加到车载单元的数据链路层，或者将多种应用场景的各时间指标进行整合，并将整合结果增加到车载单元的数据链路层

上述步骤S101~S105之间没有必然的时序关系，即可先执行步骤S103或步骤S105后再执行其它步骤。各步骤的具体说明见下文。

一般地，OBU的数据存放在ESAM中，这些数据采用目录与文件进行组织，如图2和图3所示，图2和图3分别为国标ESAM和自由流ESAM的文件结构示意图。不论哪种应用场景，OBU的ESAM文件结构都包括主文件MF（MasterFile），MF为根目录，MF包含所有其它目录如专用文件（DF，Dedicated File）和所有的文件如基本文件（EF，Elementary File）。这些文件分为密钥文件和应用文件，密钥文件存储用以控制应用数据的安全访问的密钥，应用文件用于存储应用数据。下表1所示为国标ESAM的密钥信息列表。其它应用场景下的密钥信息列表与表1部分类似。

表1国标ESAM的密钥信息

从图2和图3可以看出，不同的应用场景其所要求的ESAM文件结构类似，差别只在对应的应用目录（即专用文件）不同如国标为DF01、自由流为DF03和DF04、停车场为DF05或其它，以此类推，因此，通过将各种应用场景的ESAM文件结构进行整合可得到如图4所示的文件结构，只要ESAM空间容量允许，一个ESAM芯片可兼容多种应用场景。

由于OBU出厂后还需经历一次发行、二次发行、激活等操作最终才能被安装到车上以供正常交易使用，其具体处理流程如图5所示，其中，信息的更新需要在认证通过后方可进行，故必须放在密钥更新之后进行。发行阶段主要是替换ESAM中的各种默认密钥和改写存放在ESAM中的系统信息和车辆信息，其中一次发行主要功能是初始化OBU的初始密钥，创建系统信息文件和车辆信息文件，并初始化系统信息文件，二次发行主要是将车辆信息等个性化信息写入车辆信息文件。激活操作主要是清除掉拆卸位（用以识别OBU是否从车上拆卸过），OBU不激活无法在路上使用。

图5所示处理流程在各应用场景中几乎都是一样的，差别只是所选择的目录不同而已。对于OBU而言，发行设备下发的指令都是透明传输，即OBU仅作为透明通道，不对指令内容做判断和处理，只负责将指令发给ESAM、然后将ESAM的应答信息回传给外部的发行设备。因此，本实施例通过整合后的ESAM文件结构（即类似图4所示的文件结构），使得OBU软件平台可适用于任意种应用场景，例如，

（I）对于国标应用，其流程可以是选择DF01目录→更新DF01目录下的密钥信息→更新DF01目录下的车辆信息；

（II）对于自由流应用，其流程可以是选择DF03/DF04目录→更新DF03/DF04目录下的密钥信息→更新DF03/DF04目录下的文件信息；

（III）对于停车场应用，其流程可以是选择DF05/DFXY目录→更新DF05/DFXY目录下的密钥信息→更新DF05/DFXY目录下的文件信息。

从而，OBU厂商可以针对不同的应用场景定制ESAM，在ESAM出厂时就建立好各级文件结构以适应不同的应用场景。若以后再有新增的应用场景，只需要增加相应的新的目录文件而已，不用对OBU软件做任何改动，从而可极大地降低二次开发或后期维护成本，同时也极大的提升了OBU产品的竞争力。

对于OBU的交易阶段，由于交易阶段涉及较多的是时序和服务原语，因此，本实施例的OBU软件平台在设计时支持所有应用场景可能会用到的服务原语，时序方面则可根据场景的不同自动调整或者进行整合。

图6展示了路侧设备RSU与车载单元OBU信息交互过程，其遵循关于DSRC应用的国家标准。其中，物理层L1规定了上行链路和下行链路的要求，提供了设备之间利用无线信道进行数据传输的服务。数据链路层L2包含MAC和LLC两个子层；MAC子层提供包括专用链路建立、帧接收/发送等服务；LLC子层提供不确认无连接方式和确认无连接方式。应用层L7包含广播内核（B-KE）、初始化内核（I-BE）和传送内核（T-BE）三个核心模块；T-KE的主要功能是通过将预定义的服务原语转换为传输报文（T-APDU）及其逆过程，并通过L2在通信实体间传输报文；I-KE主要负责通信的初始化，包含RSU端BST的重复发送、OBU端BST的接收处理和VST的发送、RSU端对VST的应答等；B-KE提供OBU和RSU的广播群组交换功能，为RSU和OBU的各种应用实现广播信息分发和收集。设备应用层包含了用于ETC应用的技术要求、数据结构、应用接口和应用安全，其中OBU设备内数据采用目如前述的目录与文件进行组织。ETC应用在应用层原语ACTION上扩展出ETC应用的接口。

本实施例在设计应用层L7时，使OBU软件平台支持所有可能用到的服务原语，以便能够兼容不同应用场景下应用层可能会发出的不同服务请求。如下表2所示为国标中规定的几种服务，每个应用场景可以根据需要自行选择采用何种服务。

表2国标规定的服务

如下对几种应用场景给出与其对应的一些服务原语及其服务描述。

对于国标ETC，其服务原语包括：

（1）INITIALZATION.indication：建立专用链路请求，OBU端接收BST指示；

（2）NITIALIZATION.response：建立专用链路应答，OBU端给出VST应答；

（3）GET:GetSecure.request：安全的读取信息请求（ESAM中的车辆信息）；

（4）GET:GetSecure.response：安全信息应答（OBU端给出加密后的车辆信息）；

（5）GET:GetRand.request：获取8字节随机数请求；

（6）GET:GetRand.response：获取到的8字节随机数；

（7）Action:Transferchannel.request：通道传输请求（IC卡、ESAM、蜂鸣器、LCD等）；

（8）Action:Transferchannel.response：通道传输应答（IC卡、ESAM、蜂鸣器、LCD等）；

（9）Action:SetMMI.request：OBE人机界面指示请求；

（10）Action:SetMMI.response：OBE人机界面应用应答；

（11）EVENT-REPORT:EvenReport：链路释放。

对于自由流应用，其服务原语包括：

（1）INITIALZATION.indication：建立专用链路请求，OBU端接收BST指示；

（2）INITIALIZATION.response：建立专用链路应答，OBU端给出VST应答；

（3）Action:PrivateWindow.request：请求专有链路窗口，OBU端发起；

（4）Action:PrivateWindow.response：分配专有链路窗口，OBU端接收；

（5）SET:SetSecure.request：认证RSU合法性，安全的写入交易记录信息；

（6）SET:SetSecure.response：认证OBU合法性，获取请求结果；

（7）Action:QuickResult.response：快速响应，OBU端发起；

（8）Action:GetResult.request：取快速响应结果请求，RSU端发起；

（9）Action:GetResult.response：取结果应答，OBU端发起；

（10）EVENT-REPORT:EvenReport：链路释放。

对于停车场应用，其服务原语包括：

（1）INITIALZATION.indication：建立专用链路请求，OBU端接收BST指示；

（2）INITIALIZATION.response：建立专用链路应答，OBU端给出VST应答；

（3）GET:GetSecure.request：安全的读取信息请求（ESAM中的车辆信息）；

（4）GET:GetSecure.response：安全信息应答（OBU端给出加密后的车辆信息）；

（5）Action:Transferchannel.request：通道传输请求（IC卡、ESAM、蜂鸣器、LCD等）；

（6）Action:Transferchannel.response：通道传输应答（IC卡、ESAM、蜂鸣器、LCD等）；

（7）Action:SetMMI.request：OBU人机界面指示请求；

（8）Action:SetMMI.response：OBU人机界面应用应答；

（9）EVENT-REPORT:EvenReport：链路释放。

以上分别为三种应用场景可能用到的服务原语，本实施例的OBU软件平台支持所有应用场景可能会用到的服务原语。对于时序方面，几种应用场景下的时序要求如下表3所示。

表3几种应用场景下的时序要求

从上表可以看出不同应用场景下的时序要求有所差别，对此，在设计车载单元的数据链路层时，使OBU软件平台支持所有应用场景的各个时间指标，以便能够根据应用场景的不同进行自动调整，或者，在设计车载单元的数据链路层时，将多种应用场景的各时间指标进行整合，即针对每项时间指标，选择该项时间指标在多种应用场景中的极限值（包括上限值和下限值），并将该项时间指标设置为该极限值。本实施例中，对各项时间指标的设计参考同一部分的极限值，例如：“OBU收转发间隔”只要设计值<=192us即可满足三种应用场景下的需要。从而，可以将时序方面做调整，使得每一项时间指标的设计为各种应用场景所对应的时序的极限值，即可得到一个调整后的时序值，该值可用于各种应用场景。

通过以上将不同应用场景的ESAM文件结构进行整合，并支持所有应用场景可能会用到的服务原语，此外还对时序进行调整，使得OBU软件平台能够对应用场景的自动识别启用相应的应用进行信息交互，为实现多种应用场景的相互兼容提供了具有可操作性的技术支持。

实施例2：

本实施例提出一种多种应用场景的车载单元，包括：文件整合模块，用于在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，该多个应用目录装载与之对应的应用场景的相关信息文件；服务支持模块，用于将多种应用场景的服务原语增加到车载单元的应用层；时序支持模块，用于在车载单元的数据链路层中，针对每项时间指标，将该该项时间指标在多种应用场景中的极限值设置为该项时间指标的值。具体各模块的说明参考实施例1，在此不作重述。应理解，本实施例的车载单元还可包括现有的OBU具有的其它功能模块，在此不作详述。

实施例3：

本实施例提出了一种电子不停车收费系统，该系统采用实施例2的车载单元，车载单元的具体描述见实施例2，在此不再重述。

实施例4：

本实施例提出了一种电子不停车收费的方法，该方法遵循关于DSRC的国家标准如GB20851.4-2007等，包括通信链路建立及应用信息获取阶段、获取OBU数据阶段、消费交易阶段、用户提示及链路释放阶段等，其中，获取OBU数据阶段、消费交易阶段、用户提示及链路释放阶段可采用现有ETC收费方法的相应处理过程实现。对于通信链路建立及应用信息获取阶段，该阶段主要完成通信链路的建立，协商通信参数，协商应用参数，获取部分应用信息等，其具体包括：

发送步骤，由路侧设备RSU向车载设备发送信标服务表（BST）信息，该车载设备包含实施例2的车载单元OBU，具体车载单元的描述见实施例2，在此不再重述；

应用选择步骤，根据BST信息选择BST中指定的应用场景，OBU选择相对应的相关信息文件，包括密钥、系统信息、用户车辆信息等；

反馈步骤，车载单元OBU根据相关信息文件向路侧设备RSU发送车辆服务表（VST）信息。

具体上述步骤的发送、选择、反馈过程可采用现有ETC相对应的技术方案实现，在此不作详述。

实施例5：

本实施例提供了一种ETC车载单元的初始化方法，其在发行前在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，该多个应用目录装载与之对应的应用场景的相关信息文件，该相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件等，可参考实施例1。初始化后再根据上位机发来的发行指令发行车载单元。上位机可以是众多通用或专用的计算系统，例如：多处理器系统、服务器、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等。上位机还可以将整个发行过程的相关信息（如发行的OBU信息、发行成功与否等）发送给数据库系统进行存储。发行流程可参考实施例1及图5所示处理流程，具体涉及的相关步骤可参考现有的车载单元发行方法，在此不作详述。

本申请通过“共享平台+扩展应用”的设计理念，对构建智能交通这一基于物联网概念的新型产业有很重要的实际效用。通过将OBU统一硬件平台和构建类似互联网的软件系统，逐渐建立智能交通技术的“点”，后续可通过基于这些“点”之上的增值或拓展应用，制造更多的“点”之后再将“点”连成线、将“线”连成“面”，形成一个智能交通网。因此本申请提出的这一OBU软件平台的设计理念有着极其重要的参考价值。

本领域技术人员可以理解，上述实施方式中各种方法的全部或部分步骤可以通过程序来指令相关硬件完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器、随机存储器、磁盘或光盘等。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换。

Claims (10)

1.一种兼容多种应用场景的车载单元的实现方法，其特征在于，包括：

文件整合步骤，在车载单元的安全应用模块中建立分别对应多种应用场景的文件结构；

服务支持步骤，将多种应用场景的服务原语增加到车载单元的应用层；

时序支持步骤，将多种应用场景的各时间指标增加到车载单元的数据链路层，或者将多种应用场景的各时间指标进行整合，并将整合结果增加到车载单元的数据链路层。

2.如权利要求1所述的方法，其特征在于，所述将多种应用场景的各时间指标进行整合包括：针对每项时间指标，将所述每项时间指标在多种应用场景中的极限值设置为所述每项时间指标的值。

3.如权利要求1或2所述的方法，其特征在于，所述文件整合步骤包括：在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，所述多个应用目录装载与之对应的应用场景的相关信息文件。

4.如权利要求3所述的方法，其特征在于，所述相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件，所述多种应用场景包括：电子不停车收费应用、自由流应用、停车场应用。

5.一种兼容多种应用场景的车载单元，其特征在于，包括：

文件整合模块，用于在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，所述多个应用目录装载与之对应的应用场景的相关信息文件；

服务支持模块，用于将多种应用场景的服务原语增加到车载单元的应用层；

时序支持模块，用于将多种应用场景的各时间指标增加到车载单元的数据链路层，或者将多种应用场景的各时间指标进行整合，并将整合结果增加到车载单元的数据链路层。

6.如权利要求5所述的车载单元，其特征在于，所述将多种应用场景的各时间指标进行整合包括：针对每项时间指标，将所述每项时间指标在多种应用场景中的极限值设置为所述每项时间指标的值。

7.如权利要求5或6所述的车载单元，其特征在于，所述相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件，所述多种应用场景包括：电子不停车收费应用、自由流应用、停车场应用。

8.一种电子不停车收费系统，包括如权利要求5-7任一项所述的车载单元。

9.一种电子不停车收费的实现方法，包括通信链路建立及应用信息获取阶段，其特征在于，所述通信链路建立及应用信息获取阶段包括：

发送步骤，路侧设备向车载设备发送信标服务表BST信息，所述车载设备包含如权利要求5-7任一项所述的车载单元；

应用选择步骤，所述车载单元根据所述信标服务表BST信息选择与之对应的应用场景的相关信息文件；

反馈步骤，所述车载单元根据所述相关信息文件发送车辆服务表VST信息给所述路侧设备。

10.一种车载单元的初始化方法，其特征在于，包括：

在车载单元的安全应用模块中创建分别对应多种应用场景的多个应用目录，所述多个应用目录装载与之对应的应用场景的相关信息文件，所述相关信息文件包括密钥文件、系统信息文件和用户车辆信息文件。

Images