本发明涉及一种移动出行技术，尤其是涉及一种汽车时段化租赁信息处理方法、租赁方法及系统。
背景技术
传统的出行领域，以有人值守的租车方法进行车辆的租借和还车，这一方法需要租车单位有专门的人员进行车辆的交接，这种方式导致只能在固定的一些租车点进行交易，租车点太少，对用车人来说并不方便，导致交易量小；同时由于有人值守，也会导致运营成本非常高，使得这种模式无法大规模普及。
近年出现的分时租赁方式，通过车联网技术使得用车人可以找到车辆，进行租赁。例如中国专利cn107798582a公开了一种基于互联网的电动汽车分时租赁系统，包括用于与车辆及充电设施通信连接的分时租赁运营平台及移动客户端，所述移动客户端与所述分时租赁运营平台通过无线网络通信连接，所述分时租赁运营平台包括资产管理模块、客户服务模块、车辆计费管理模块、设施监控模块等，所述系统还可包括与所述分时租赁运营平台通信连接的web服务网站。该系统为一种车桩位结合、多企业、集管理、运营、租赁、监测等功能于一身的分时租赁系统，实现了多家企业同时运营、资源和交易独自维护；移动客户端手机app实现手机下单及操控车辆，实现无人值守自助租车；web服务网站可作为系统的推广平台。但是包括上述系统在内的现有分时租赁系统，只考虑了用车人即时用车的场景，每一次租赁都是针对特定车辆建立人与车之间绝对的1对1的关系，导致用车人在遇到车辆状况异常导致的该车不能租赁、非即时用车而是预约用车的场景下，无法满足需要。
技术实现要素：
本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种汽车时段化租赁信息处理方法、租赁方法及系统。
本发明的目的可以通过以下技术方案来实现：
一种汽车时段化租赁信息处理方法，包括：
连接车辆源系统，接收、存储并更新车辆信息及状态；
接收车辆使用即时或预约请求后，结合车辆信息为该请求对应的用户生成云钥匙，其中，所述云钥匙被配置有权益信息；
接收云钥匙兑换请求后，结合车辆信息和状态为该请求对应的云钥匙分配并关联车辆。
所述为该请求对应的用户分配车辆包括：
解析云钥匙兑换请求，得到至少包括云钥匙所对应的车型信息和用户的位置的待匹配信息；
根据所述待匹配信息匹配得到车辆，并关联该车辆和所述云钥匙；
根据云钥匙的权益信息进行车辆信息交互和控制。
所述方法还包括：
接收到云钥匙终止请求后，解除车辆和和云钥匙的关联。
所述方法还包括：
根据云钥匙的生成、兑换记录信息，生成统计信息并通过报表方式呈现。
一种基于上述信息处理方法的租赁方法，包括：
云钥匙系统分别对接车辆源系统和业务源系统；
业务源系统订阅云钥匙服务，并通过云钥匙系统从车辆源系统订阅车辆；
车辆源系统定期向云钥匙系统发送订阅车辆的车辆信息及状态，云钥匙系统接收、存储并更新车辆信息及状态；
业务源系统根据用户需求信息向云钥匙系统发送车辆使用即时或预约请求，由云钥匙系统结合车辆信息为该请求对应的用户生成云钥匙，并根据所述用户需求信息为云钥匙配置权益信息；
业务源系统向云钥匙系统发送云钥匙兑换请求，由云钥匙系统结合车辆信息和状态为该请求对应的云钥匙分配并关联车辆。
所述业务源系统根据用户需求向云钥匙系统发送车辆使用即时或预约请求，包括：
接收用户的下单数据；
解析用户的下单数据，得到至少包含用户所需要使用的车型信息、使用时间的用户需求信息；
向云钥匙系统发送包含所述用户需求信息的车辆使用即时或预约请求。
一种汽车租赁系统，包括：
车辆源系统，用于管理车辆信息；
业务源系统，用于接收管理用户信息；
其特征在于，还包括：
云钥匙系统，用于生成用于兑换车辆使用权益的云钥匙，并完成云钥匙的兑换以关联云钥匙和指定车辆。
所述云钥匙系统中配置有运营运维监控模块，通过对完成业务的关键环节的日志或者异常告警捕获对整个云钥匙系统的运转情况进行实时监控，在有异常产生时通过邮件、短信、管理网站告警方式通知提醒关联的运营和运维人员。
所述云钥匙系统中配置有统计模块，用于对所有云钥匙的使用情况进行统计，汇总得到云钥匙平台的运营情况，并通过报表方式展现。
与现有技术相比，本发明具有以下有益效果：
1）通过云钥匙的定义，将每一辆车的使用权限进行权益化，而这种权益化是时段化的，可以根据用车人的需要精确到最小粒度的时间，任何授权的用车人可以基于自己用车的精准时间，兑现自己所享有的用车权益，这种权益可以是即时的，也可以是预约的。
2）权益的兑现不是针对特定某一辆汽车的，而是基于用车人真实使用车辆的时刻，由云钥匙平台进行即时调配的，解决了现有分时租赁系统只能租赁特定车辆而导致的资源抢占情况下无法成交的问题。
附图说明
图1为本发明实施例中租赁系统的结构示意图；
图2为本发明实施例中租赁系统的数据流结构示意图；
其中：1、云钥匙系统，2、车辆源系统，3、业务源系统。
具体实施方式
下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。
实施例1：
如图1所示，通过云钥匙实现移动出行，需要车辆源系统2、业务源系统3和云钥匙系统1（云钥匙平台）三方合作实现。
车辆源系统2，由现有的车联网系统完成，车联网系统通过t-box硬件，将车辆连入网络。车辆实时或者静态数据可以通过车联网系统获取，车辆的远程控制，也可以通过车联网系统向车辆发送指令完成；
业务源系统3，基于使用汽车做不同运营服务的运营方而定，包括使用乘用车、新能源车进行分时租赁的运营系统；包括使用商业车进行智慧物流的运力管理平台。
云钥匙系统1，核心系统是车辆管理系统、云钥匙管理系统、服务管理系统，此外辅助以数据管理系统、运营运维管理系统，共同组成支撑使用云钥匙进行车辆时段化运营的整体系统。
云钥匙系统1各部分的职能如下：
（1）车辆管理系统：完成与多家车厂车联网系统（tsp）或其他车辆源系统2的对接，使得投入运营的车辆得到车联网系统的授权，可以基于业务的需要，将这些车辆的数据上报给云钥匙平台，并且基于云钥匙平台传递的车辆控制指令，进行相应的指令执行。由于车辆上报数据量巨大，而且频度较高，通常是30秒一次/车。所以车辆管理系统必须支持大数据量、高并发；同时由于对接车厂的车联网系统，所以对于传输安全必须进行相应考虑
（2）服务管理系统：完成与多家移动出行运营方系统的对接，使得不同的运营方可以根据自己的业务类型，订阅相应的服务，从车辆管理系统获取到对应所需要的服务数据、并且通过车辆管理系统完成对应的业务所需的远程控制命令。作为一个运营平台，云钥匙平台为运营方提供云钥匙服务，收取相应的收益，所以在服务管理系统内，设计包含了相关的服务使用统计、结算体系，用于跟不同业务运营方进行费用结算
（3）云钥匙管理系统：
a）云钥匙生成：基于业务源系统3的订阅情况和云钥匙生成请求，为每一次的业务生成云钥匙和对应的权益。每把云钥匙，在生成时就赋予了相应的权利，包括可以获取哪些数据、进行哪些远程控制或者其他功能。
b）云钥匙权益兑换：云钥匙的权益根据云钥匙用户的需要，通过即时或者预约的方式完成权益兑换，这个过程也就是云钥匙的生命周期管理的过程。而通过云钥匙管理系统与车辆管理系统的对接，可以基于用户兑现云钥匙的时间点，智能精准的为用户寻找当时条件下最适合他的车辆，而不是预先指定了一辆也许在用户需要兑现权益时已经不可用的车辆。这种车辆使用的兑现，是通过大数据实时计算的方式完成。所以整个云钥匙平台，也是一个大数据平台；
c）云钥匙使用统计：每一把云钥匙代表了一次服务的全生命周期，所以对每一把云钥匙的使用情况统计，汇总成为整个平台的运营情况，也是业务运营结算的基础，本平台通过报表等方式，完成云钥匙的使用统计展现和报表输出
（4）运营运维监控系统：作为一个高并发大数据强安全性要求的平台，平台配套以运营监控和运维监控功能。通过对完成业务的关键环节的日志或者异常告警捕获，可以对整个系统的运转情况进行实时的监控，一旦有异常产生，相关的运营和运维人员可以通过邮件、短信、管理网站告警提醒等多种方式，实时得到通知，投入对应的问题排查解决中。
以tsp系统作为车辆园系统为例，如图2所示，系统的业务流程具体包括：
步骤1和步骤2：云钥匙系统1分别对接车辆源系统2和业务源系统3；
步骤3：业务源系统3订阅云钥匙系统1提供的移动出行服务；
步骤4：业务源系统3订阅车辆，具体为订阅指定类型的车辆；
步骤5：云钥匙系统1接收到业务源系统3的订阅信息后，从tsp订阅车辆；
步骤6：tsp定期向云钥匙系统1发送订阅的车辆信息及状态；
步骤7：云钥匙系统1将车辆信息及状态反馈给业务源系统3；
步骤8：业务源系统3中用户进行下单操作；
步骤9：业务源系统3解析用户的下单数据，得到至少包含用户所需要使用的车型信息、使用时间的用户需求信息，向云钥匙系统1发送包含用户需求信息的车辆使用即时或预约请求；
步骤10：云钥匙系统1根据用户需求信息为云钥匙配置权益信息；
步骤11：为业务源系统3授予云钥匙；
步骤12：用户获得云钥匙及权益；
步骤13：用户选择兑换云钥匙的权益；
步骤14：业务源系统3发送兑换请求；
步骤15：云钥匙系统1结合车辆信息和状态为该请求对应的云钥匙分配并关联车辆。
步骤16：用户结束使用并归还云钥匙；
步骤17：业务源系统3终止云钥匙；
步骤18：云钥匙系统1终止云钥匙权益。
实施例2：
本实施例中，与实施例1中相同之处不再叙述，仅叙述不同之处。
本实施例中与实施例1相比的显著不同之处在于，本实施例中步骤8和步骤9中，用户的使用需求可以分为即时使用或者预约使用，业务源系统3根据用户需求信息向云钥匙系统1发送车辆使用即时或预约请求，由云钥匙系统1结合车辆信息为该请求对应的用户生成云钥匙，并根据用户需求信息为云钥匙配置权益信息。
实施例3：
本实施例中，与实施例1中相同之处不再叙述，仅叙述不同之处。
本实施例中与实施例1相比的显著不同之处在于，本实施例中为了避免因车辆不足导致的云钥匙分发过渡，可以辅助一些云钥匙发放数量限制，数量显示可以根据各类车型的数量和未兑换的云钥匙权益确定。
实施例4：
本实施例中，与实施例1中相同之处不再叙述，仅叙述不同之处。
本实施例中与实施例1相比的显著不同之处在于，本实施例中对于互补的云钥匙权益，在兑换时可以指向同一辆车辆，从而实现类似于“拼车”的效果。