本发明涉及交通运输技术领域，具体而言，涉及一种obu设备激活方法、终端设备及服务器。
背景技术：
车载单元(onboardunit，简称obu)设备是指电子收费(electronictollcollection，简称etc)系统中的车载端，一般安装于车辆挡风玻璃的内侧，obu设备安装好后需要激活才能使用。然而在obu设备的使用过程中可能会由于软件故障等原因导致设备无法继续使用，需要重新对obu设备进行激活，然而在现有技术中缺少对obu设备进行重激活的有效解决方案，司机在面对obu设备故障时无法自主进行激活，只能求助于obu设备相关的渠道、网点，故障处理效率低下。
技术实现要素：
本申请实施例的目的在于提供一种obu设备激活方法、终端设备及服务器，以改善上述技术问题。
为实现上述目的，本申请提供如下技术方案：
第一方面，本申请实施例提供一种obu设备激活方法，应用于终端设备，所述方法包括：尝试激活obu设备，并在激活obu设备失败时保存错误数据；向服务器发送所述错误数据，以使所述服务器根据所述错误数据生成第一obu指令集；接收所述服务器发送的所述第一obu指令集；利用所述第一obu指令集重新激活所述obu设备。
在上述方法中，obu设备通过由终端设备写入obu指令集的方式进行激活。在obu设备故障时，用户(如司机)首先可使用终端设备尝试obu设备激活，若激活失败，终端设备会收集错误数据，并在适当的时机将错误数据上报服务器。而服务器在收到错误数据后会根据错误数据的内容生成第一obu指令集并将第一obu指令集返回给终端设备，终端设备可以利用收到的第一obu指令集对obu设备进行重新激活。
该方法提供了一种用户在面对obu设备故障时自主进行设备激活的解决方案，用户仅需简单操作终端设备就可以高效地完成obu设备的重新激活。有效避免了用户在obu设备发生故障时不清楚找谁解决、或者即使找到了相关解决渠道但问题修复周期过长的问题。
在第一方面的一种实现方式中，所述错误数据包括以下至少一种：激活失败时采用的第二obu指令集、所述obu设备的设备信息、使用所述终端设备的用户信息以及安装有所述obu设备的车辆信息。
在第一方面的一种实现方式中，所述向服务器发送所述错误数据，包括：当尝试激活的重试次数已经达到预设次数但所述obu设备仍未激活成功时，向所述服务器发送所述错误数据。
尝试重激活的方式可以为终端设备自动或用户手动，若尝试了预设次数还未能成功激活，表明仅依赖目前的obu指令集无法实现obu设备的重激活，因此可以将收集到的错误数据上报给服务器，以使服务器可以自动或者借助于人工对错误数据进行分析，重新确定激活方案，实现obu设备的重激活。并且，由于在重试期间积累了比较充分的错误数据，所以服务器可以有效确定错误原因进而获得比较精准的解决方案。
在第一方面的一种实现方式中，所述利用所述第一obu指令集重新激活所述obu设备，包括：响应用户在可视化界面上作出的激活操作，利用所述第一obu指令集重新激活所述obu设备。
obu设备激活可以实现为终端设备上的应用程序(例如手机上的app等)，并在应用程序中提供可视化界面(例如一个页面)，用户通过在可视化界面上作出激活操作(例如点击页面上的激活按钮)即可快速完成obu设备的激活，其操作非常方便，对普通用户友好，无需任何技术门槛。
在第一方面的一种实现方式中，在所述向服务器发送所述错误数据之后，所述方法还包括：接收所述服务器发送的obu设备故障原因并在可视化界面上显示所述obu设备故障原因。
服务器根据上报的错误数据还可以确定obu设备故障原因，该原因可以显示在可视化界面上供用户了解。
第二方面，本申请实施例提供一种obu设备激活方法，应用于服务器，所述方法包括：接收终端设备发送的错误数据；将所述错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；向所述终端设备发送所述第一obu指令集。
在上述方法中，服务器在收到终端设备上报的错误数据后会将错误数据与预设的规则进行匹配，若匹配成功，表明对于该错误数据所表征的故障服务器上存在对应的解决方案。此时可根据对应的解决方案生成第一obu指令集，并将该指令集发往终端设备，以使终端设备根据第一obu指令集进行obu设备的重新激活。即服务器可以在数据的驱动下确定重激活方案，并迅速将解决方案提供给用户以解决obu设备故障，使得用户在短时间内就完成obu设备的重新激活。有效避免了用户在obu设备发生故障时不清楚找谁解决、或者即使找到了相关解决渠道但问题修复周期过长的问题。
在第二方面的一种实现方式中，所述错误数据携带在所述终端设备发送的消息中，在所述接收终端设备发送的错误数据之后，以及在所述将所述错误数据与预设的规则进行匹配之前，所述方法还包括：确认需要对携带有所述错误数据的消息进行响应。
携带错误数据的消息可以视为终端设备向服务器发送的获取obu指令集的请求，但服务器并非要对所有的请求进行响应，例如，一些非法的请求则无需进行响应。上述实现方式即在服务器响应消息前先对消息内容进行甄别。
在第二方面的一种实现方式中，所述确认需要对携带有所述错误数据的消息进行响应，包括确认以下项目中的至少一项：根据所述错误数据中携带的用户信息确认对应的用户为注册用户；根据所述错误数据中携带的设备信息确认对应的obu设备是通过指定的渠道发行的obu设备；根据所述错误数据中携带的车辆信息确认对应的车辆和申领obu设备时登记的车辆一致。
若用户未注册，即该用户不属于服务提供方服务的对象，服务提供方可不提供obu设备重激活服务；若obu设备的发行渠道不是服务提供方指定的渠道(例如和服务提供方未建立合作关系)，服务提供方可不提供obu设备重激活服务；若车辆信息和登记信息不匹配，表明obu设备未被正常使用，服务提供方可不提供obu设备重激活服务。
在第二方面的一种实现方式中，所述方法还包括：若所述错误数据未与预设的规则匹配成功，则接收由人工录入的第一obu指令集。
上述实现方式还支持人工处理obu设备故障，例如对于某些错误数据所表征的故障服务器上不存在现成的解决方案则可交由人工进行支持，以便为用户提供更好的服务。对于人工处理的方式，工作人员还可根据错误数据中携带的用户信息与用户取得联系，及时为其提供帮助。
在第二方面的一种实现方式中，所述方法还包括：获取与所述错误数据对应的obu设备故障原因，并向所述终端设备发送所述obu设备故障原因。
服务器根据上报的错误数据还可以通过自动或人工的方式确定obu设备故障原因，该原因可以发往终端设备以使用户获知。
第三方面，本申请实施例提供一种终端设备，包括：激活模块，用于尝试激活obu设备，并在激活obu设备失败时保存错误数据；错误数据发送模块，用于向服务器发送所述错误数据，以使所述服务器根据所述错误数据生成第一obu指令集；指令接收模块，用于接收所述服务器发送的所述第一obu指令集；重激活模块，用于利用所述第一obu指令集重新激活所述obu设备。
第四方面，本申请实施例提供一种服务器，包括：错误数据接收模块，用于接收终端设备发送的错误数据；错误数据匹配模块，用于将所述错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；指令发送模块，用于向所述终端设备发送所述第一obu指令集。
第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面、第二方面或两方面的任意一种可能的实现方式提供的方法。
第六方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面、第二方面或两方面的任意一种可能的实现方式提供的方法。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种obu设备的激活场景的示意图；
图2示出了本申请实施例提供的一种obu设备激活方法的流程图；
图3示出了本申请实施例提供的一种终端设备的功能模块图；
图4示出了本申请实施例提供的一种服务器的功能模块图；
图5示出了本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
同时，术语“第一”、“第二”等仅用于将一个实体或者操作与另一个实体或操作区分开来，而不能理解为指示或暗示相对重要性，也不能理解为要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
图1示出了本申请实施例提供的一种obu设备的激活场景的示意图。参照图1，该场景包括obu设备100、终端设备110以及服务器120。
其中，obu设备100安装于车上，作为etc系统的车载端，目前发生了故障，需要重新进行激活才能继续使用。需要指出，上述故障常见于obu设备100的软件故障，但也有一些obu设备100需要重激活的情况并非因为软件故障，例如目前的obu设备100基本都具有防拆功能，一旦将其强行拆下，将导致设备无法使用，也需要重新激活，也可以适用本申请提供的方法。
终端设备110可以由用户持有，例如可以是用户的手机，也可以安装在车上，例如作为车载设备供用户操作，等等，其结构可以参考图5。终端设备可以和obu设备100通信，在图1中以箭头示出。
服务器120可以设置在远端，其结构可以参考图5。服务器120可以和一台或多台终端设备110通信，以向用户提供obu设备100的重激活方案，在图1中以箭头示出。
本申请中的用户可以指司机，但并不限于司机，例如也可以是乘员或者其他人。
图2示出了本申请实施例提供的一种obu设备激活方法的流程图。参照图2，该方法包括：
步骤s200：终端设备尝试激活obu设备。
在obu设备发生故障时，用户可以通过终端设备先尝试激活obu设备。在一些实现方式中，终端设备上安装有应用程序，例如手机上的app，应用程序中可提供可视化界面，例如一个页面，用户通过在可视化界面上作出激活操作即可进行obu设备的激活，例如点击页面上的激活按钮即可触发终端设备将obu指令集写入到obu设备中，从而完成obu设备的激活，其操作非常方便快捷，对普通用户友好，无需任何技术门槛。
为便于区分步骤s200中使用的obu指令集和后续服务器根据收到错误数据生成的obu指令集，不妨将步骤s200中使用的称为第二obu指令集，后续服务器根据收到错误数据生成的称为第一obu指令集。第二obu指令集可以由终端设备从服务器获取后再用于obu设备激活，但如果第二obu指令集已经缓存在终端设备上，直接将其用于obu设备的激活即可。另外，还需要指出，对于不同型号的obu设备(可能由不同的厂商生产)，其激活所需的obu指令集可能是不同的，终端设备为用户屏蔽了这些细节问题，用户只需简单操作终端设备即可进行obu设备激活，无需关心设备的型号。
步骤s210：终端设备在激活obu设备失败时保存错误数据。
步骤s200中尝试激活obu设备未必都会成功，也可能会发生失败。例如，在终端设备写入第二obu指令集的过程中若发生异常则可确认激活失败。在终端设备确认激活失败后，可以在本地保存与本次激活有关的错误数据，以便在后续步骤中使用。在一些实现方式中，一次激活失败后，终端设备可以自动进行激活重试(重新执行步骤s200)，例如尝试重新写入第二obu指令集，或者重新从服务器获取第二obu指令集后再尝试重写入，当然也不排除在一些实现方式中，终端设备不会自动进行激活重试，而需要用户手动进行重试。若在重试过程中obu设备激活成功，则设备可以恢复使用(此时也不必再执行后续步骤)，若持续重试依然失败，则终端设备可以将每次重试时的错误数据都记录下来，例如保存为日志。
上述错误数据可以包括以下几项信息中的一种或多种：激活失败时采用的第二obu指令集、激活失败的obu设备的设备信息、使用终端设备的用户信息(例如，app的用户账号)以及安装obu设备的车辆信息。当然，也不排除错误数据还包括其他信息，例如尝试激活的时间、异常描述信息等。后文将会对其中一些信息项的用途作出具体说明。
步骤s220：终端设备向服务器发送错误数据。
若尝试激活obu设备始终未成功过，终端设备会在适当的时机会将步骤s210中保存的错误数据打包后上报至服务器。这里所谓适当的时机在不同的实现方式中可以有不同的定义：
例如，可以是在重试激活的次数达到了预设次数但obu设备仍未激活成功时由终端设备自动上报。因为重试了多次仍未激活成功，足以说明仅依赖目前的obu指令集无法激活obu设备，从而可以将收集到的错误数据上报给服务器，以使服务器自动或者借助于人工对错误数据进行分析，重新确定激活方案，实现obu设备的重激活(详见后续步骤)。此种方式下，由于在重试期间积累了比较充分的错误数据，所以服务器可以有效确定错误原因进而获得比较精准的解决方案。
又例如，可以是在终端设备判断自己在激活重试的过程中已经收集到了足够多的错误数据，足以获得激活的解决方案时，才将错误数据打包上报，而并非在重试固定的次数后上报错误数据。
又例如，终端设备也可以不主动上报错误数据，而是由用户决定是否要上报错误数据，用户的决定可以通过终端设备的可视化界面下达。
终端设备在上报错误数据时，可以组织一定格式的消息，将错误数据携带在消息内容中。
步骤s230：服务器将错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；若匹配不成功，则接收由人工录入的第一obu指令集。
服务器在收到终端设备上报的错误数据后会将错误数据与预设的规则进行匹配，若匹配成功，表明对于该错误数据所表征的obu设备故障服务器上存在对应的解决方案，此时可根据匹配的规则对应的解决方案生成第一obu指令集。若匹配不成功,表明对于该错误数据所表征的obu设备故障服务器上不存在对应的解决方案，此时可转入人工处理，例如可由工作人员对错误数据进行分析，然后在服务器提供的页面上录入第一obu指令集。服务器自动处理结合人工处理可为用户提供更好的服务，尽可能解决用户的obu设备故障。其中，对于人工处理的方式，工作人员还可根据错误数据中携带的用户信息与用户取得联系，直接为其提供一对一的帮助。
需要指出，在匹配不成功时提供人工服务是可选的，也不排除在某些实现方式中不提供人工服务，只由服务器根据规则匹配情况生成第一obu指令集，若预设的规则无法匹配成功，服务器则向终端设备发送消息，告知用户目前无法激活obu设备。
上述预设的规则与错误数据的内容相对应，错误数据与某个规则匹配成功是指错误数据的内容与该规则中指定的内容一致。例如，预设的规则可以包括多项，每项规则对应一种obu设备的一种故障原因，规则的内容可以包括obu设备的型号以及错误数据中一些信息项的取值，若错误数中携带的设备信息与某项规则中的obu设备型号一致，并且错误数据中其他一些信息项的取值和该项规则中指定的取值一致，则表明错误数据与该项规则是匹配的，从而故障原因可以确定下来，进而针对此故障的解决方案可以确定下来，最终第一obu指令集也可以根据相应的解决方案生成。比如，若故障原因是obu设备中的车辆信息错误，则服务器可以重新同步车辆信息，并在第一obu指令集中包含写入新同步的车辆信息的指令，以便修复该错误。
携带错误数据的消息可以视为终端设备向服务器发送的获取第一obu指令集的请求，但服务器并非要对所有的请求进行响应，例如对一些非法的请求则服务器无需进行响应。因此在一些实现方式中，服务器执行步骤s230之前，还可以先判断是否需要对携带有错误数据的消息进行响应，若需要响应才会执行步骤s230产生第一obu指令集，否则可以直接忽略掉该消息或者向发送消息的终端设备反馈消息内容非法。
比如，服务器可以判断如下项目中的一项或几项(当然还可以包括其他验证项目)：
其一，判断错误数据中携带的用户信息对应的用户是否为注册用户(比如，app的注册用户)，只有注册用户服务提供方才会对其提供支持，否则无需向其提供支持。
其二，判断错误数据中携带的设备信息对应的obu设备是否是通过指定的渠道(例如，服务提供方自身)发行的obu设备，只有通过指定的渠道发行的obu设备服务提供方才会为其生成用于激活的第一obu指令集，否则无需为其生成第一obu指令集。
其三，判断错误数据中携带的车辆信息对应的车辆和申领obu设备时登记的车辆是否一致，若二者一致则表明对obu设备的使用是正常的、合法的，从而服务提供方可以为其提供重激活服务，否则表明该车辆未正常使用obu设备(例如，非法使用了其他车辆的obu设备)，无需为其提供重激活服务。
若所有的判断项目判断结果都为“是”，则说明服务器需要对携带有错误数据的消息进行响应，若有任意一个判断项目的结果为“否”，则服务器无需响应该消息。
服务器可能同时接收多个终端设备的消息，对这些消息服务器可以进行排队，按照先后顺序进行处理，或者按照优先级进行处理，等等。
步骤s240：服务器向终端设备发送第一obu指令集。
在步骤s230中生成第一obu指令集后，服务器可以将第一obu指令集发送给终端设备。例如，在一种实现方式中，第一obu指令集可以封装为消息的形式，通过服务器上运行的消息推送服务推送给终端设备。
步骤s250：终端设备利用第一obu指令集重新激活obu设备。
终端设备接收到第一obu指令集后，可以再次尝试激活obu设备，由于第一obu指令集是根据终端设备收集到的错误数据生成的，因此具有很高的针对性，重激活obu设备成功的概率较高。
步骤s250既可以由终端设备在接收到第一obu指令集后自动执行，也可以由用户指示终端设备将第一obu指令集写入obu设备。例如，用户可以在终端设备的可视化界面上作出激活操作，作为对该操作的响应，终端设备会利用第一obu指令集重新激活obu设备。用户无需关心具体的激活过程，也无需关心obu设备型号，也无需关心obu设备的发行方是谁，即可实现obu设备的“一键激活”，激活过程自动化、智能化程度较高。
目前，一些obu设备在故障时会显示错误代码，但用户不清楚代码含义反而造成困惑，或者虽然有的obu设备会给出提示信息，但信息内容对于普通用户难于理解，缺少实际意义。在本申请的一些实现方式中，服务器还可以获取与错误数据对应的obu设备故障原因，并向终端设备发送obu设备故障原因。而终端设备在接收到故障原因后，可以将其显示在可视化界面上供用户了解obu设备故障原因。例如，服务器在执行步骤s230时，可以根据错误数据与规则的匹配情况可以自动分析出obu设备故障原因，或者在转交人工处理后，工作人员也可以在确认obu设备故障原因将其录入到服务器。总之，服务器可以得到明确的、易于用户理解的故障原因描述并将其发送给终端设备显示。故障原因可以随第一obu指令集一起发送给终端设备，也可以单独发送。
综上所述，在本申请实施例提供的obu设备激活方法中，obu设备通过由终端设备写入obu指令集的方式进行激活。在obu设备故障时，用户首先可使用终端设备尝试obu设备激活，若激活失败，终端设备会收集错误数据，并在适当的时机将错误数据上报服务器。而服务器在收到错误数据后，会基于错误数据的内容，通过自动(将错误数据与预设的规则匹配)或者人工(在错误数据与规则匹配失败时由工作人员录入)的方式生成第一obu指令集并将第一obu指令集返回给终端设备，终端设备进而可以利用收到的第一obu指令集对obu设备进行重新激活。
该方法提供了一种用户在面对obu设备故障时自主进行设备激活的解决方案，用户仅需简单操作终端设备就可以完成obu设备的重新激活。而从服务器角度来看，则可以在错误数据的驱动下快速确定重激活方案，并将解决方案提供给用户。总之，该方法可以高效地重新激活obu设备，使得故障obu设备能够很快重新投入使用，将给用户带来的损失降到最低。并且，该方案还有效避免了目前用户在obu设备发生故障时不清楚找谁解决、或者即使找到了相关解决渠道但问题修复周期过长的问题。
进一步的，该方法中还包含人工处理机制，工作人员可以和用户及时取得联系，共同解决obu设备故障，用户不会再陷于求助无门的境地。
图3示出了本申请实施例提供的终端设备110的功能模块图。参照图3，终端设备110包括：
激活模块111，用于尝试激活obu设备，并在激活obu设备失败时保存错误数据；
错误数据发送模块112，用于向服务器发送所述错误数据，以使所述服务器根据所述错误数据生成第一obu指令集；
指令接收模块113，用于接收所述服务器发送的所述第一obu指令集；
重激活模块114，用于利用所述第一obu指令集重新激活所述obu设备。
在终端设备110的一种实现方式中，所述错误数据包括以下至少一种：激活失败时采用的第二obu指令集、所述obu设备的设备信息、使用所述终端设备的用户信息以及安装有所述obu设备的车辆信息。
在终端设备110的一种实现方式中，错误数据发送模块112向服务器发送所述错误数据，包括：当尝试激活的重试次数已经达到预设次数但所述obu设备仍未激活成功时，向所述服务器发送所述错误数据。
在终端设备110的一种实现方式中，重激活模块114利用所述第一obu指令集重新激活所述obu设备，包括：响应用户在可视化界面上作出的激活操作，利用所述第一obu指令集重新激活所述obu设备。
在终端设备110的一种实现方式中，终端设备110还包括：显示模块，用于在错误数据发送模块112向服务器发送所述错误数据之后，接收所述服务器发送的obu设备故障原因并在可视化界面上显示所述obu设备故障原因。
本申请实施例提供的终端设备110，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。
图4示出了本申请实施例提供的服务器120的功能模块图。参照图4，服务器120包括：
错误数据接收模块121，用于接收终端设备发送的错误数据；
错误数据匹配模块122，用于将所述错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；
指令发送模块123，用于向所述终端设备发送所述第一obu指令集。
在服务器120的一种实现方式中，所述错误数据携带在所述终端设备发送的消息中，服务器120还包括：校验模块，用于在错误数据接收模块121接收终端设备发送的错误数据之后，以及在错误数据匹配模块122将所述错误数据与预设的规则进行匹配之前，确认需要对携带有所述错误数据的消息进行响应。
在服务器120的一种实现方式中，校验模块确认需要对携带有所述错误数据的消息进行响应，包括确认以下项目中的至少一项：根据所述错误数据中携带的用户信息确认对应的用户为注册用户；根据所述错误数据中携带的设备信息确认对应的obu设备是通过指定的渠道发行的obu设备；根据所述错误数据中携带的车辆信息确认对应的车辆和申领obu设备时登记的车辆一致。
在服务器120的一种实现方式中，错误数据匹配模块122还用于若所述错误数据未与预设的规则匹配成功，则接收由人工录入的第一obu指令集。
在服务器120的一种实现方式中，错误数据匹配模块122还用于获取与所述错误数据对应的obu设备故障原因，指令发送模块123还用于向所述终端设备发送所述obu设备故障原因。
本申请实施例提供的服务器120，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。
图5示出了本申请实施例提供的一种电子设备的结构示意图。参照图5，电子设备300包括：处理器310、存储器320以及通信接口330，这些组件通过通信总线340和/或其他形式的连接机构(未示出)互连并相互通讯。
其中，存储器320包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(randomaccessmemory，简称ram)，只读存储器(readonlymemory，简称rom)，可编程只读存储器(programmableread-onlymemory，简称prom)，可擦除只读存储器(erasableprogrammableread-onlymemory，简称eprom)，电可擦除只读存储器(electricerasableprogrammableread-onlymemory，简称eeprom)等。处理器310以及其他可能的组件可对存储器320进行访问，读和/或写其中的数据。
处理器310包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器310可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、微控制单元(microcontrollerunit，简称mcu)、网络处理器(networkprocessor，简称np)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(digitalsignalprocessor,简称dsp)、专用集成电路(applicationspecificintegratedcircuits，简称asic)、现场可编程门阵列(fieldprogrammablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
通信接口330包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行设备间的数据交互，通信接口330可以包括有线和/或无线通信的接口。例如，手机(一种终端设备)和obu设备之间常见可通过蓝牙进行通信，手机和服务器之间可以通过移动通信网络进行通信。
在存储器320中可以存储一个或多个计算机程序指令，处理器310可以读取并运行这些计算机程序指令，以实现本申请实施例提供的obu设备激活方法以及其他期望的功能。
可以理解，图5所示的结构仅为示意，电子设备300还可以包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。例如，在采用硬件方式实现时，电子设备300可以是pc机、笔记本电脑、平板电脑、手机、智能穿戴设备、车载设备、etc专用设备、服务器等；在采用软件方式实现时，电子设备300可以是虚拟机、虚拟化容器等。并且，电子设备300不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。于本申请实施例中，终端设备和服务器都可以采用电子设备300的结构来实现。
本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的obu设备激活方法。例如，计算机可读存储介质可以实现为图5中电子设备300中的存储器320。
在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
1.一种obu设备激活方法，其特征在于，应用于终端设备，所述方法包括：
尝试激活obu设备，并在激活obu设备失败时保存错误数据；
向服务器发送所述错误数据，以使所述服务器根据所述错误数据生成第一obu指令集；
接收所述服务器发送的所述第一obu指令集；
利用所述第一obu指令集重新激活所述obu设备。
2.根据权利要求1所述的obu设备激活方法，其特征在于，所述错误数据包括以下至少一种：激活失败时采用的第二obu指令集、所述obu设备的设备信息、使用所述终端设备的用户信息以及安装有所述obu设备的车辆信息。
3.根据权利要求1所述的obu设备激活方法，其特征在于，所述向服务器发送所述错误数据，包括：
当尝试激活的重试次数已经达到预设次数但所述obu设备仍未激活成功时，向所述服务器发送所述错误数据。
4.根据权利要求1所述的obu设备激活方法，其特征在于，所述利用所述第一obu指令集重新激活所述obu设备，包括：
响应用户在可视化界面上作出的激活操作，利用所述第一obu指令集重新激活所述obu设备。
5.根据权利要求1-4中任一项所述的obu设备激活方法，其特征在于，在所述向服务器发送所述错误数据之后，所述方法还包括：
接收所述服务器发送的obu设备故障原因并在可视化界面上显示所述obu设备故障原因。
6.一种obu设备激活方法，其特征在于，应用于服务器，所述方法包括：
接收终端设备发送的错误数据；
将所述错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；
向所述终端设备发送所述第一obu指令集。
7.根据权利要求6所述的obu设备激活方法，其特征在于，所述错误数据携带在所述终端设备发送的消息中，在所述接收终端设备发送的错误数据之后，以及在所述将所述错误数据与预设的规则进行匹配之前，所述方法还包括：
确认需要对携带有所述错误数据的消息进行响应。
8.根据权利要求7所述的设备激活方法，其特征在于，所述确认需要对携带有所述错误数据的消息进行响应，包括确认以下项目中的至少一项：
根据所述错误数据中携带的用户信息确认对应的用户为注册用户；
根据所述错误数据中携带的设备信息确认对应的obu设备是通过指定的渠道发行的obu设备；
根据所述错误数据中携带的车辆信息确认对应的车辆和申领obu设备时登记的车辆一致。
9.根据权利要求6所述的obu设备激活方法，其特征在于，所述方法还包括：
若所述错误数据未与预设的规则匹配成功，则接收由人工录入的第一obu指令集。
10.根据权利要求6-9中任一项所述的obu设备激活方法，其特征在于，所述方法还包括：
获取与所述错误数据对应的obu设备故障原因，并向所述终端设备发送所述obu设备故障原因。
11.一种终端设备，其特征在于，包括：
激活模块，用于尝试激活obu设备，并在激活obu设备失败时保存错误数据；
错误数据发送模块，用于向服务器发送所述错误数据，以使所述服务器根据所述错误数据生成第一obu指令集；
指令接收模块，用于接收所述服务器发送的所述第一obu指令集；
重激活模块，用于利用所述第一obu指令集重新激活所述obu设备。
12.一种服务器，其特征在于，包括：
错误数据接收模块，用于接收终端设备发送的错误数据；
错误数据匹配模块，用于将所述错误数据与预设的规则进行匹配，若匹配成功，则根据匹配的规则对应的解决方案生成第一obu指令集；
指令发送模块，用于向所述终端设备发送所述第一obu指令集。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-10中任一项所述的方法。
14.一种电子设备，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求1-10中任一项所述的方法。
技术总结