CN110766506A

CN110766506A - 一种订单生成方法、装置、电子设备和存储介质

Info

Publication number: CN110766506A
Application number: CN201811519678.5A
Authority: CN
Inventors: 李成
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-12-12
Filing date: 2018-12-12
Publication date: 2020-02-07

Abstract

本申请提供了一种订单生成方法、装置、电子设备和存储介质，涉及互联网技术领域。本申请所提供的订单生成方法，先根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；其中，第一客户端为服务请求方使用的客户端；之后，将生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令；最后根据第一确认指令所确认使用的规划路线，生成出行订单。由于在给第一客户端发送规划路线进行确认的时候，还同时将该规划路线的安全信息同时发送给了第一客户端，使得服务请求方可以参考安全信息来生成第一确认指令，提高了服务请求方确认路线的准确度。

Description

一种订单生成方法、装置、电子设备和存储介质

技术领域

本申请涉及互联网技术领域，具体而言，涉及一种订单生成方法、装置、电子设备和存储介质。

背景技术

近年来，网约车业务的出现，给乘客和司机都带来了极大的便利，乘客可以在自己出行前就下达订单，来提前预约出行时间和出行地点，以免在出行时需要花费大量时间在路边等待可以搭乘的合规车辆；同时，司机也可以在承接订单前提前预知订单中的目的地，进而选择自己期望的订单来承接。

发明内容

本申请实施例的目的在于提供一种订单生成方法、装置、电子设备和存储介质。

第一方面，本发明实施例提供了一种订单生成方法，包括：

根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；第一客户端为服务请求方使用的客户端；

将生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令；

根据第一确认指令所确认使用的规划路线，生成出行订单。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，方法还包括：

根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为目标第二客户端；第二客户端为服务提供方使用的客户端；

将出行订单分配给目标第二客户端。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，步骤将出行订单分配给目标第二客户端包括：

将出行订单中的规划路线和规划路线的安全信息发送给目标第二客户端，以获取目标第二客户端所返回的第二确认指令；

根据第二确认指令，确定是否向目标第二客户端分配出行订单。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，还包括：

生成规划路线的拥堵信息；

步骤将生成的规划路线和规划路线的安全信息发送给第一客户端包括：

将生成的规划路线、规划路线的安全信息和规划路线的拥堵信息发送给第一客户端。

结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，安全信息包括以下任意一种或多种信息：

规划路线的整体安全评分；规划路线的整体安全提示信息；规划路线中指定路段的安全评分；规划路线中指定路段的安全提示信息。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，步骤根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息包括：

根据服务请求生成至少一个规划路线；

使用如下任意一个或多个参数，分别计算每个规划路线的安全评分；

乘客信息、出行时间、天气状况、规划路线的偏僻程度、规划路线所对应的道路的交通事故发生概率。

结合第一方面，本发明实施例提供了第一方面的第六种可能的实施方式，其中，还包括：

判断生成的规划路线的安全信息是否满足预设的要求；

在确定生成的规划路线的安全信息不满足预设的要求后，执行步骤将生成的规划路线和规划路线的安全信息发送给第一客户端；

在确定生成的规划路线的安全信息满足预设的要求后，执行步骤根据规划路线生成出行订单。

结合第一方面，本发明实施例提供了第一方面的第七种可能的实施方式，其中，步骤根据第一确认指令所确认使用的规划路线，生成出行订单包括：

识别第一确认指令；

在确定第一确认指令为选择指令后，执行步骤根据第一确认指令所确认使用的规划路线，生成出行订单；

在确定第一确认指令为订单修改指令后，根据订单修改指令重新生成至少一条规划路线和规划路线的安全信息，并将重新生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令。

结合第一方面，本发明实施例提供了第一方面的第八种可能的实施方式，其中，还包括：

在出行订单被分配后，实时根据第一客户端的行进路线或被分配出行订单的第二客户端的行进路线生成实际行进路线；

计算实际行进路线的实时安全评价值；

根据实际行进路线的实时安全评价值进行安全操作。

结合第一方面，本发明实施例提供了第一方面的第九种可能的实施方式，其中，步骤根据实际行进路线的实时安全评价值进行安全操作包括：

判断实时安全评价值是否低于预设的阈值；

在确定实时安全评价值低于预设的阈值后，根据实际行进路线的实时安全评价值进行安全操作。

结合第一方面，本发明实施例提供了第一方面的第十种可能的实施方式，其中，步骤根据实际行进路线的实时安全评价值进行安全操作包括：

根据预先设置的实时安全评价值与安全操作方式之间的对应关系，确定与计算的实时安全评价值相对应的安全操作方式；

根据查找到的安全操作方式进行操作。

结合第一方面，本发明实施例提供了第一方面的第十一种可能的实施方式，其中，安全操作方式包括：

系统自动干预操作、人工干预操作和紧急干预操作。

结合第一方面，本发明实施例提供了第一方面的第十二种可能的实施方式，其中，系统自动干预操作包括以下的任意一种或多种：

发送在应用程序内显示的安全提示弹窗、发送在应用程序内播放的语音提示信息、发送在应用程序内显示的提示信息；

人工干预操作包括以下的任意一种或多种：

发送进行安全确认的短信息、通过人工客服进行语音安全确认；

紧急干预操作包括以下的任意一种或多种：

将实际行进路线或出行订单向紧急联系人发送、通过专属客服进行语音安全确认、与第三方安全机构进行联动。

结合第一方面，本发明实施例提供了第一方面的第十三种可能的实施方式，其中，步骤计算实际行进路线的实时安全评价值包括：

根据以下任意一个或多个参数计算实际行进路线的实时安全评价值；

第一客户端所发出的安全反馈信息、第二客户端所发出的安全反馈信息、实时时间、实时天气状况、实际行进路线的偏僻程度、实际行进路线与出行订单中规划路线的偏离程度、乘客信息。

结合第一方面，本发明实施例提供了第一方面的第十四种可能的实施方式，其中，还包括：

获取第一客户端或被分配出行订单的第二客户端所发送的关于出行订单的出行评价数据；

根据出行评价数据确定事故等级；

若事故等级超过预定的数值，则执行事故等级所对应的操作机制。

第二方面，本发明实施例还提供了一种订单生成装置，包括：

第一生成模块，用于根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；第一客户端为服务请求方使用的客户端；

第一发送模块，用于将生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令；

第二生成模块，用于根据第一确认指令所确认使用的规划路线，生成出行订单。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，装置还包括：

第一选择模块，用于根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为目标第二客户端；第二客户端为服务提供方使用的客户端；

第一分配模块，用于将出行订单分配给目标第二客户端。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，第一分配模块包括：

第一发送单元，用于将出行订单中的规划路线和规划路线的安全信息发送给目标第二客户端，以获取目标第二客户端所返回的第二确认指令；

第一确定单元，用于根据第二确认指令，确定是否向目标第二客户端分配出行订单。

结合第二方面，本发明实施例提供了第二方面的第三种可能的实施方式，其中，装置还包括：

第三生成模块，用于生成规划路线的拥堵信息；

第一发送模块包括：

第二发送单元，用于将生成的规划路线、规划路线的安全信息和规划路线的拥堵信息发送给第一客户端。

结合第二方面，本发明实施例提供了第二方面的第四种可能的实施方式，其中，安全信息包括以下任意一种或多种信息：

结合第二方面，本发明实施例提供了第二方面的第五种可能的实施方式，其中，第一生成模块包括：

第一生成单元，用于根据服务请求生成至少一个规划路线；

第一计算单元，用于使用如下任意一个或多个参数，分别计算每个规划路线的安全评分；

结合第二方面，本发明实施例提供了第二方面的第六种可能的实施方式，其中，还包括：

第一判断模块，用于判断生成的规划路线的安全信息是否满足预设的要求；在确定生成的规划路线的安全信息不满足预设的要求后，执行步骤将生成的规划路线和规划路线的安全信息发送给第一客户端；

结合第二方面，本发明实施例提供了第二方面的第七种可能的实施方式，其中，第二生成模块包括：

识别单元，用于识别第一确认指令；

在确定第一确认指令为选择指令后，则驱动第二生成模块工作；

在确定第一确认指令为订单修改指令后，则所述识别单元，还用于根据所述订单修改指令重新生成至少一条规划路线和规划路线的安全信息，并将重新生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端，以获取第一客户端返回的第一确认指令。

结合第二方面，本发明实施例提供了第二方面的第八种可能的实施方式，其中，还包括：

第四生成模块，用于在出行订单被分配后，实时根据第一客户端的行进路线或被分配出行订单的第二客户端的行进路线生成实际行进路线；

第一计算模块，用于计算实际行进路线的实时安全评价值；

第一操作模块，用于根据实际行进路线的实时安全评价值进行安全操作。

结合第二方面，本发明实施例提供了第二方面的第九种可能的实施方式，其中，第一操作模块包括：

第一判断单元，用于判断实时安全评价值是否低于预设的阈值；

第一操作单元，用于在确定实时安全评价值低于预设的阈值后，根据实际行进路线的实时安全评价值进行安全操作。

结合第二方面，本发明实施例提供了第二方面的第十种可能的实施方式，其中，第一操作模块包括：

第二确定单元，用于根据预先设置的实时安全评价值与安全操作方式之间的对应关系，确定与计算的实时安全评价值相对应的安全操作方式；

第二操作单元，用于根据查找到的安全操作方式进行操作。

结合第二方面，本发明实施例提供了第二方面的第十一种可能的实施方式，其中，安全操作方式包括：

系统自动干预操作、人工干预操作和紧急干预操作。

结合第二方面，本发明实施例提供了第二方面的第十二种可能的实施方式，其中，系统自动干预操作包括以下的任意一种或多种：

人工干预操作包括以下的任意一种或多种：

紧急干预操作包括以下的任意一种或多种：

结合第二方面，本发明实施例提供了第二方面的第十三种可能的实施方式，其中，第一计算模块包括：

第二计算单元，用于根据以下任意一个或多个参数计算实际行进路线的实时安全评价值；

结合第二方面，本发明实施例提供了第二方面的第十四种可能的实施方式，其中，还包括：

第一获取模块，用于获取第一客户端或被分配出行订单的第二客户端所发送的关于出行订单的出行评价数据；

第一确定模块，用于根据出行评价数据确定事故等级；

第二操作模块，若事故等级超过预定的数值，则用于执行事故等级所对应的操作机制。

第三方面，本发明实施例还提供了一种一种电子设备，包括：处理器、存储介质和总线，存储介质存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储介质之间通过总线通信，处理器执行机器可读指令，以执行时执行如第一方面的订单生成方法的步骤。

第四方面，本发明实施例还提供了一种一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如第一方面的订单生成方法的步骤。

本申请所提供的订单生成方法，先根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；其中，第一客户端为服务请求方使用的客户端；之后，将生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令；最后根据第一确认指令所确认使用的规划路线，生成出行订单。由于在给第一客户端发送规划路线进行确认的时候，还同时将该规划路线的安全信息同时发送给了第一客户端，使得服务请求方可以参考安全信息来生成第一确认指令，提高了服务请求方确认路线的准确度。

某一种实现方式中，本申请所提供的方法通过选择与安全信息相匹配的第二客户端作为目标第二客户端；其中，第二客户端为服务提供方使用的客户端；而后，将出行订单分配给目标第二客户端。通过将出行订单分配给符合安全信息要求的第二客户端，出行订单能够被更加有针对性的第二客户端所承接，提高了出行订单分配的准确性。

某一种实现方式中，本申请所提供的方法将生成的规划路线、规划路线的安全信息和规划路线的拥堵信息发送给第一客户端，使得第一客户端的使用者可以依据规划路线的拥堵情况和安全情况综合的判断，以选择出更加合理的规划路线来形成出行订单。

某一种实现方式中，本申请所提供的方法在出行订单被分配后，还会持续的实时监控车辆的实际行进路线，并计算出实际行进路线的实时安全评价值，而后，再依据实时安全评价值进行安全操作，使得乘客在出行过程中也能够有一定的安全保障。并且，这种出行过程中的安全监控方式和确认出行订单时由第一客户端依据规划路线的安全信息来选择规划路线的方式相结合，更为立体的提高了乘客的安全程度。

某一种实现方式中，本申请所提供的方法在出行订单完成后，还通过出行评价数据确定了事故等级，并在符合预定条件的时候，执行了事故等级所对应的操作机制。这种完成出行订单后，还会进行追溯的机制，进一步提高了乘客出行的安全性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的一种订单生成方法的基本流程图；

图2示出了本申请实施例所提供的订单生成方法中，第一客户端显示规划路线和规划路线的安全信息的示意图；

图3示出了本申请实施例所提供的订单生成方法中，将出行订单分配向目标第二客户端进行分配的流程示意图；

图4示出了本申请实施例所提供的订单生成方法中，将出行订单分配向目标第二客户端进行分配后，对出行过程进行监控的流程示意图；

图5示出了本申请实施例所提供的订单生成方法中，实例1的流程示意图；

图6示出了本申请实施例所提供的订单生成方法所依据的系统的系统架构示意图；

图7示出了本申请实施例所提供的电子设备的示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

生活中，网约车业务的出现给乘客和司机都带来了极大的便利。乘客可以提前下达网约车订单来安排出行，避免了在出行时乘客需要临时到路边找寻可搭乘的车辆而浪费时间的问题。司机则可以在承接网约车订单之前了解到乘客的出行路线或者是出行目的地，从而承接自己想承接的网约车订单，使得司机可以更好的安排工作计划。

相关技术中，为了给用户来更方便的体验，某些网约车业务中可以让让乘客自由选择行车路线(司机运送乘客时所计划走的路线)，也就是在乘客下达了网约车订单之后，系统(可以认为是处理网约车订单的服务器)首先会和乘客确定行车路线，在确定了行车路线之后，系统再利用确定的行车路线生成网约车订单，并向司机派发网约车订单。

相关技术中，系统和乘客确定行车路线的过程如下：

步骤1，乘客向系统发起服务请求，服务请求中携带有上车地点和到达地点；

步骤2，系统在接收到服务请求之后，先根据上车地点和到达地点的之间的道路连通状况，生成多条候选路线(每个候选路线都是从上车地点通往到达地点的)；

步骤3，系统根据当前道路的拥堵情况分别计算每个候选路线的通行时间(汽车走完指定的候选路线所预计花费的时间)；

步骤4，系统向乘客推送通行时间最少的几个候选路线，和每个候选路线的通行时间；

步骤5，乘客在接收到步骤4中的候选路线之后，向系统回复选择指令(选择指令中携带有说明乘客选择哪个候选路线作为行车路线的信息)；

步骤6，系统根据选择指令选择指定的候选路线作为出行路线。

而后，系统可以根据出行路线的生成出行订单，并将出行订单向司机派发了，而后由承接出行订单的司机来负责运送乘客。但乘客在选择出行路线的时候，只考虑道路的拥堵情况是不够合理的。

进而，本申请提供了一种订单生成方法，如图1所示，包括：

S101，根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；第一客户端为服务请求方使用的客户端；

S102，将生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令；

S103，根据第一确认指令所确认使用的规划路线，生成出行订单。

步骤S101中，服务请求是第一客户端的使用者(即服务请求方、乘客)通过操作第一客户端发出的。步骤S101中，在根据服务请求生成规划路线之前，先需要确定用于生成规划路线的端点(起点和终点)。并根据该端点和道路连通的情况来生成至少一条规划路线，在确定了规划路线之后，才能确定规划路线的安全信息。为了使服务器(步骤S101-S103的执行主体)能够更准确的生成至少一条规划路线和规划路线的安全信息，服务请求方可以在服务请求中携带上路线要求，比如不走偏僻的路段、不走国道等，以使服务器可以有针对性的为服务请求方生成对应的规划路线和规划路线的安全信息。

即，步骤S101可以按照如下方式执行：

根据第一客户端所发出的服务请求中的路线要求，生成至少一条规划路线和规划路线的安全信息。

其中，路线要求指的是服务请求方对规划路线的具体要求，比如优先选择的路段，或者绝对不走的路段等。具体如不走偏僻的路段、优先考虑走国道等。在具体实现时，路线要求中可以携带有多个路线要求，每个路线要求中均携带有具体路段和具体路段所对应的优先级(优先级反映了是否优先选择某个路段)，进而，该步骤在执行的时候，可以考虑各个路线要求的优先级来生成规划路线，并生成对应的安全信息。在具体执行的时候，可以是先根据起点和终点生成至少一条候选路线，而后，根据路线要求的优先级，分别计算每个候选路线的评分(如候选路线中包含优先级较低的路段，则该候选路线的评分就较低；如候选路线中包含优先级较高的路段，则该候选路线的评分就较高)，并最终选择评分排名靠前的，或评分足够高的候选路线作为规划路线。

步骤S101中，安全信息指的是说明规划路线安全情况的信息，比如安全信息可以是说明规划路线安全程度的信息(如整个规划路线的安全评分，或者是该规划路线中某个路段的安全评分)，也可以是给服务请求方提供的文字形式的路线描述信息(如在什么时间发生过交通意外、该路线在未来几个小时内可能会封闭、该路段危险程度较高等)。整体来看安全信息，其作用至少是可以帮助服务请求方在选择规划路线时，从安全角度进行参考的信息(或者说，安全信息能从安全的角度来区分不同的规划路线)，即，能够从安全的角度来区分不同的规划路线的信息都可以视为安全信息。

如前文中的说明，在确定规划路线的之前，首先需要确定规划路线的端点(司机接起乘客的起点和乘客所期望到达的终点)，确定规划路线的端点的方式可以分为两种。下面分别进行说明：

第一种确定规划路线的端点的方式：

由服务请求方直接提供端点信息。即端点信息是由服务请求方发出的，如端点信息可以是携带在服务请求中发出的。进而，步骤S101可以按照如下方式实现：

步骤1011，提取携带在服务请求中的端点信息；端点信息包括规划路线的起点，和/或终点；

步骤1012，根据携带在服务请求中的端点信息生成至少一条规划路线和规划路线的安全信息。

携带在服务请求中的端点信息可以是以地点名称(如XXX小区南门)的形式出现，也可以是以某种编码(如坐标，或者某种代号)的形式出现。其中，端点信息可以是只包括起点信息，也可以只包括终点信息，还可以既包括起点信息，也包括终点信息。

第二种确定规划路线的端点的方式：

由服务请求方提供能够查询到端点信息的提示信息。即，端点可以根据携带在服务请求中的提取信息从某个存储设备中获取的，也就是在服务请求中携带有提取信息(说明端点信息存在什么位置)，之后可以直接利用提取信息来获取到端点信息。进而，步骤S101可以按照如下方式实现：

步骤1013，获取携带在服务请求中的提取信息；

步骤1014，根据提取信息，从指定的存储位置获取端点信息；端点信息包括规划路线的起点，和/或终点；

步骤1015，根据获取到的端点信息，生成至少一条规划路线和规划路线的安全信息。

第二种确定规划路线的端点的方式，规划路线的端点并不是直接携带在服务请求中的。服务请求中所携带的提取信息反映了获取到端点信息的方式。比如提取信息可以是说明端点信息的存储位置(该存储位置可以指向指服务器内部的某个存储区域，也可以是指向服务器外部的某个存储区域)，进而服务器可以从该存储位置处获取到端点信息。提取信息也可以是说明提取端点信息所需要验证码，服务器就可以通过向第三方设备提供该验证码来使得第三方设备返回端点信息。其中，端点信息可以是只包括起点信息，也可以只包括终点信息，还可以即包括起点信息，也包括终点信息。

具体实现时，可以在服务器中预存有用户预先提供的提取信息与端点信息的对照关系(如可以以数据表的形式存在)。在获取到提取信息后，可以根据提取信息，从提取信息与端点信息的对照关系中查询到对应的端点信息，并在步骤1015中，使用查询到的端点信息，生成至少一条规划路线和规划路线的安全信息。

这两种确定规划路线的端点的方式相比，第二种更侧重于对服务请求方信息的保护(在发送服务请求的时候没有将端点信息直接携带在服务请求中)。

步骤S101中所生成的规划路线至少有一条，每个规划路线都对应有一个安全信息，从而在步骤S101执行完成时，可以得到一个或多个规划路线和每个规划路线的安全信息，比如可以生成如下表1所示的表格：

表1

编号	规划路线	安全信息
			1	路线A	AAAA
2	路线B	BBBB
			3	路线C	CCCC
4	路线D	DDDD

由表1可见，所生成每个规划路线都有对应的安全信息。更具体来说，每个规划路线都有唯一一个与该规划路线相对应的安全信息。

在生成了规划路线和规划路线的安全信息之后，步骤S102中就可以将该规划路线和对应的安全信息发送给第一客户端，以让第一客户端的使用者(服务请求方)确定是否按照发送来的某个规划路线来出行。

服务请求方在确定是否按照发送来的某个规划路线来出行时，主要是依据的是安全信息。如前文中的描述，安全信息能够从安全的角度来区分不同路线，从而使得服务请求方可以根据安全信息来选择更适合的路线。除了安全信息以外，辅助服务请求方进行选择的还有规划路线本身，规划路线应当一定程度上反映出由起点(司机接起乘客的位置)至终点(乘客所期望到达的位置)之间所经过的地点。进而，服务请求方可以同时依据规划路线和规划路线的安全信息做出选择。

第一确认指令的内容可以是不唯一的，比如第一确认指令可以是选择指令(说明服务请求方期望选择哪个规划路线)，这样，在步骤S103中就可以直接根据选择指令来选择指定的规划路线作为出行路线，并根据该出行路线生成出行订单了。又比如，第一确认指令可以是拒绝指令(说明服务请求方不期望选择任何一个规划路线)，此时则应当终止流程，或者是重新向服务请求方提供建议(重新提供的建议可以是重新生成规划路线让用户进行选择，也可以是生成调查问卷，询问服务请求方具体的拒绝原因)。

第一确认指令还可以是订单修改指令，这主要是针对服务器向第一客户端所发送的规划路线和安全信息不符合服务请求方的要求的情况，此时，服务请求方可以变更要求，并让服务器重新生成至少一条规划路线和规划路线的安全信息，并将重新生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令。

此处，重新生成规划路线的方式和步骤S101的方式是相同的，但通常，订单修改指令中还会携带服务请求方的新要求(如避免使用安全评分小于预定数值的路段组成规划路线，规划路线的整体安全评分应当大于80，不使用曾经发生过重大交通事故的路段组成规划路线)、新端点，因此，重新生成的规划路线应当是与步骤S101中生成的是有差别的。之后，在将重新生成的规划路线和规划路线的安全信息发送给第一客户端后，第一客户端就可根据重新生成的规划路线和规划路线的安全信息返回第一确认指令了，进而，服务器可以根据重新返回的第一确认指令来确定哪个规划路线作为出行路线，或者是当重新反馈的第一确认指令为订单修改指令，则还要再根据订单修改指令重新生成至少一条规划路线和规划路线的安全信息，或者是当第一确认指令是拒绝指令(说明服务请求方不期望选择任何一个规划路线)时，可以终止流程，或者是重新向服务请求方提供建议(重新提供的建议可以是重新生成规划路线让用户进行选择，也可以是生成调查问卷，询问服务请求方具体的拒绝原因)。

在服务请求方通过操作第一客户端来生成第一确认指令，并将第一确认指令向服务器(服务器)发送后。步骤S103中，服务器可以根据第一确认指令确定出对应的出行路线(第一确认指令所确认使用的规划路线)，并根据出行路线生成出行订单。如，服务器向第一客户端发送了如表1中所示的4个规划路线，则第一确认指令中可以携带有表示“选择路线C”的信息，这样，在步骤S103中，服务器就可以根据路线C生成出行订单，也就是司机在接受出行订单后，就需要按照路线C来运送服务请求方了。

而后，服务器可以将出行订单向指定的一个司机(服务提供方)进行分配，也可以将出行订单向多个司机进行广播，并根据司机所回复的第二确认指令来确定将出行订单向哪个司机分配，或者是是否向指定的司机进行分配。

某些情况下，服务器可以不向服务请求方询问是否需要选择哪个规划路线作为出行路线，比如当生成的规划路线的安全度都很高的时候，实际上就可以不询问服务请求方，而是服务器直接确定出行路线。

也就是，本申请所提供的方法还可以包括如下步骤：

判断生成的规划路线的安全信息是否满足预设的要求；

具体的，步骤判断生成的规划路线的安全信息是否满足预设的要求，有两种情况，下面分别进行说明：

第一种情况是生成规划路线只有一条，这样，只判断该生成的一条规划路线的安全信息是否满足要求即可。

判断生成的一条规划路线的安全信息是否满足要求的具体规则可以是判断规划路线的整体安全评分是否超过预定的数值，或者是判断规划路线中指定路段的安全评分是否超过预定的数值。当然，具体的判断规则还可以有其他的形式，使用时可以视具体情况来调整规则。

第二种情况是生成的规划路线有多条，此时，一般就需要分别判断每条规划路线的安全信息是否满足预设要求了，并根据每条规划路线的安全信息满足预设要求的情况，来确定生成的规划路线的安全信息是否满足预设的要求。

具体的，判断某一条规划路线的安全信息是否满足要求的规则可以参照第一种情况中的方式，此处不重复说明。在此基础上，服务器还可以进一步判断满足预设要求的规划路线是否足够多，如果足够多的话，则可以确定生成的规划路线的安全信息满足预设的要求。

也就是，第二种情况下，步骤判断生成的规划路线的安全信息是否满足预设的要求可以按照如下方式执行：

判断安全信息满足预设要求的规划路线的数量是否超过预定的阈值；

在确定安全信息满足预设要求的规划路线的数量超过预定的阈值后，执行步骤将生成的规划路线和规划路线的安全信息发送给第一客户端；

在确定安全信息满足预设要求的规划路线的数量未超过预定的阈值后，执行步骤根据规划路线生成出行订单。

第二种情况下，生成的规划路线和安全信息是多个，此时，服务器可以自动的选择安全信息最好的规划路线生成出行订单。比如，可以是将规划路线的整体安全评分最高的规划路线认为是安全信息最好的规划路线。或者是使用安全信息中的具体信息(规划路线的整体安全评分；规划路线的整体安全提示信息；规划路线中指定路段的安全评分；规划路线中指定路段的安全提示信息)计算出规划路线的评价值，并将评价值最高的规划路线作为安全信息最好的规划路线。

如前文中的说明，安全信息指的是说明规划路线安全情况的信息。该安全信息有两种体现形式，分别是数值形式(安全评分)和文字形式(描述路线情况的文字信息，即安全提示信息)。通常情况下，安全评分较为直观，是能够帮助服务请求方快速的区分不同规划路线的安全程度(也可以理解为从安全角度来看的出行推荐程度)的信息。但安全评分是一种标准化的表述信息，无法反映出某个规划路线的特点，进而，为了反映规划路线的特点，就需要使用文字描述的安全提示信息来说明路线的特点了。

可见，安全评分和安全提示信息各有优点，安全评分较为直观，可以快速的帮助服务请求方区分不同的规划路线，但安全评分无法反映出某个规划路线的特点(如由于什么具体原因造成的安全评分较低或较高)。安全提示信息相较于安全评分而言，不够直观，但安全提示信息描述的较为精确，可以使得服务请求方直销更准确的关于安全方面的信息。

进而，在实现时，安全信息中可以只携带有规划路线的安全评分，也可以只携带有安全提示信息，还可以是同时携带有安全评分和安全提示信息。

由于规划路线是较长的，一个规划路线通常是由多个路段所构成的，因此，为了保证向服务请求方提供的安全信息的准确性，安全提示信息中可以针对每个路段(或指定路段)都设置安全评分或者是设置安全提示信息。

进而，具体实现时，安全信息中可以包括如下4种具体内容：

上述4种具体实现的形式可以并存，也就是安全信息包括以下任意一种或多种信息：

当安全信息中只包括有一种具体信息时，安全信息中可以只包括有规划路线的整体安全评分。安全信息中可以只包括有规划路线的规划路线的整体安全提示信息。安全信息中可以只包括有规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线中指定路段的安全提示信息。

当安全信息中只包括有两种具体信息时，安全信息中可以只包括有规划路线的整体安全评分和规划路线的整体安全提示信息。安全信息中可以只包括有规划路线的整体安全评分和规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线的整体安全评分和规划路线中指定路段的安全提示信息。安全信息中可以只包括有规划路线的整体安全提示信息和规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线的整体安全提示信息和规划路线中指定路段的安全提示信息。安全信息中可以只包括有规划路线中指定路段的安全评分和规划路线中指定路段的安全提示信息。

当安全信息中只包括有三种具体信息时，安全信息中可以只包括有规划路线的整体安全评分、规划路线的整体安全提示信息和规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线中指定路段的安全提示信息、规划路线的整体安全提示信息和规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线中指定路段的安全提示信息、规划路线的整体安全评分和规划路线中指定路段的安全评分。安全信息中可以只包括有规划路线中指定路段的安全提示信息、规划路线的整体安全评分和规划路线的整体安全提示信息。

当然，安全信息中可以同时包括有这四种具体信息，即，安全信息包括规划路线的整体安全评分、规划路线的整体安全提示信息、规划路线中指定路段的安全评分和规划路线中指定路段的安全提示信息。

此处的规划路线的整体安全评分指的是描述规划路线整个路径的安全程度的分值；该整体安全评分可以是根据规划路线上每个路段的安全评分计算得到的(如采用加权计算的方式计算得到)。

此处的规划路线中指定路段的安全评分，指的是属于规划路线中某个局部路段的安全评分。

此处的安全提示信息(规划路线的整体安全提示信息和规划路线中指定路段的安全提示信息)指的是有助于精确识别不同规划路线区别的文字信息，并且安全提示信息描述的是和安全方面相关的信息。如，安全提示信息可以是表述该路段/路线曾经发生过交通意外的情况(交通意外的发生时间、严重程度、伤亡人数等信息)、表述该路段/路线危险程度的文字、表述该路段/路线偏僻程度的文字等。

上文的内容介绍了安全信息的具体构成，下面对安全信息的生成方式进行介绍，一般情况下，安全信息(安全评分或者是安全提示信息)可以是根据如下任意一个或多个参数计算得到的：

在具体计算的时候，可以使用乘客信息、出行时间、天气状况、规划路线的偏僻程度、规划路线所对应的道路的交通事故发生概率中的任一个来计算安全信息，但考虑到计算的准确性，通常是使用至少两个参数计算安全信息。

其中，乘客信息指的是用于描述乘客属性/类别的信息，如年龄、性别、职业等信息。

出行时间描述的是司机按照规划路线的运载乘客的时间，该时间可以是使用服务请求方所提供的乘客上车的时间。如服务请求方表示期望中午十二点让司机接乘客，并运载乘客，则中午十二点就可以作为出行时间。如果该出行时间表示的是乘客上车的时间，则该时间越接近午夜，则安全评分通常越低。该时间还可以是指服务器计算出的司机完成规划路线所需要的时间。如果该出行时间表示的是司机完成规划路线所需要的时间，则该时间越长，则安全评分通常越低。

天气状况表示的司机运送乘客时的天气状况，该天气状况通常是通过网络上的天气预报信息来确定。即，服务器首先要确定司机运送乘客时的时刻，而后，从网络上的信息中提取到天气预报信息中，来查询该时刻所对应的天气状况。

规划路线的偏僻程度指的是规划路线偏离市中心、或者是偏离主干道(如市区内主干道、国道等道路)的程度。该规划路线的偏僻程度可以根据规划路线与市中心的距离，和规划路线与主干道的距离计算得到。

规划路线所对应的道路的交通事故发生概率也可以理解为规划路线所对应的道路的历史交通事故发生情况。二者的区别在于事故发生概率通常是以数值的形式存储在网络上，或者是存储在服务器中的；历史交通事故发生情况通常是以文字或者结构化的表达式记录在网络上，或者是存储在服务器中的，事故发生概率更加直观(计算时，服务器可以快速调用)，历史交通事故发生情况反映的则更加准确(能够反映出曾经发生的事故的具体情况)。

如图2所示，示出了在向第一客户端发送规划路线和规划路线的安全信息后，第一客户端显示规划路线和规划路线的安全信息的具体形式。图2中，上方的规划路线是路线1，通行的总距离为250km，该规划路线的整体安全评分是75分；下方的规划路线是路线2，通行的总距离为200km，路线整体安全评分为90分。

其中，路线1可以分为两部分，分别是粗实线的局部路段和细实线的局部路段，粗实线的局部路段的安全程度较低，在左上方的圆圈中标注出了针对粗实线的局部路段的安全提示信息，即“由AA至BB的路段偏僻，在X月发生过交通事故”。类似的，路线2也可以分为两部分，分别是粗实线的局部路段和细实线的局部路段，粗实线的局部路段的安全程度较低，并且粗实线部分的所对应的注释为“由CC至DD的路段安全度一般，该路段的安全评分为70，请注意”。可见，该注释中既有该局部路段的安全评分，也有针对该局部路段的安全提示信息。

步骤S103中，在生成了出行订单之后，就可以向司机派发出行订单了，通常情况下，派发出行订单的方式是向全体司机广播该出行订单，并在司机回复后，根据司机回复的消息来确定将出行订单分配给哪个司机。但这种直接向全体司机广播出行订单进而完成订单分配的方式并不合理，主要是不同的司机所适合承接的订单不同，因而，为了提高出行订单的分配准确度，应当先行对司机进行筛选，在并将出行订单分配给筛选出来的司机。

也就是，如图3所示，本申请所提供的方法还包括：

S301，根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为目标第二客户端；第二客户端为服务提供方使用的客户端；

S302，将出行订单分配给目标第二客户端。

步骤S301中，出行订单中的规划路线是使用第一确认指令所确认的规划路线，即该规划路线是服务请求方所选择的规划路线。选择与安全信息相匹配的第二客户端作为目标第二客户端，指的是根据预先保存在服务器里的第二客户端与安全信息对应关系，查找与出行订单中的规划化路线的安全信息相匹配的第二客户端。比如，可以在服务器中预先存储有如下表2所示的表格：

表2

由表2中可以看出，不同的第二客户端所对应的安全信息的内容是有区别的，比如编号为A12345的第二客户端所对应的安全信息的内容是“只承接具有整体安全评分超过80分的规划路线的出行订单”，这样，图2中所示的路线1就不能分配给该第二客户端。

类似的，对于编号为B23456和E34567的第二客户端而言，也有对应的要求。也就是，如果出行订单中的规划路线不满足该第二客户端的安全信息的内容，则不能够将该第二客户端作为目标第二客户端，即不能将出行订单向该第二客户端分配。

此处，预先记录在服务器中的第二客户端与安全信息对应关系可以是服务器根据各个司机所上报的内容确定的(即司机自己向服务器上传与自己适合的安全信息)。第二客户端与安全信息的对应关系还可以是服务器根据司机平时的驾驶情况来确定的，比如某些司机经常在较为偏远的地域运营，则服务器可以自动记录该司机可以承接具有偏远规划路线的出行订单；又比如，某些司机经常在容易发生事故的地域运营，则服务器可以自动记录该司机可以承接具有较低安全评分的规划化路线的出行订单。

具体的，步骤S301执行方式有两种，分别是选择出指定数量(如一个)的第二客户端作为目标第二客户端和选择出所有与安全信息相匹配的第二客户端作为目标第二客户端。

下面，分别对这两种执行方式进行介绍。

步骤S301的第一种执行方式，即选择出指定数量(如一个)的第二客户端作为目标第二客户端。

步骤S301可以按照如下方式执行：

步骤3011，根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为候选第二客户端；

步骤3012，根据候选第二客户端的历史安全行驶记录，从候选第二客户端中选择预定数量的第二客户端作为目标第二客户端。

也就是，首先从全部第二客户端(可以是指全部处于在线状态的第二客户端)选择出与出行订单中的规划路线的安全信息相匹配的第二客户端所为候选第二客户端(即选择出符合出行订单中的规划路线的安全信息要求的第二客户端作为候选第二客户端)。之后再从候选第二客户端中选择出历史安全行驶记录较好的一个或多个第二客户端作为目标第二客户端。

步骤3012中，第二客户端的历史安全行驶记录反映了司机曾经发生过的交通意外的情况。比如，历史安全行驶记录中可以记录有司机发生运营安全问题的数量、发生运营安全问题的次数，还可以记录有司机曾经发生过的运营安全问题的严重程度。此处的运营安全问题可以是指交通事故、危险驾驶行为，或者是司机做出危害乘客安全的行为的情况。

也就是，历史安全行驶记录能够反映司机运营的安全情况，根据历史安全行驶记录，服务器可以自动的选择不容易出现安全问题，或者是不容易出现严重安全问题的司机来为服务请求方进行服务。

步骤3012在执行时，可以先判断候选第二客户端的数量是否小于预定数量，如果候选第二客户端的数量小于预定数量，则可以将当前的候选第二客户端直接作为目标第二客户端。如果候选第二客户端的数量大于预定数量(如超过10个)，则需要执行步骤根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为候选第二客户端。

步骤3012在执行时，可以根据服务请求方的级别/权限来确定选择不同级别的第二客户端作为目标第二客户端，即服务请求方(第一客户端的使用者)的级别越高，则确定的目标第二客户端的历史安全行驶记录就应当越良好。即，步骤3012，根据第二客户端的历史安全行驶记录，从候选第二客户端中选择预定数量的第二客户端作为目标第二客户端，可以按照如下方式执行：

根据服务请求方的级别，确定对应的服务要求；

选择历史安全行驶记录与服务要求相匹配的第二客户端作为目标第二客户端。

即，在执行时，也要考虑到乘客的级别，首先确定与服务请求方级别相对应的服务要求，而后，在根据服务要求确定哪个第二客户端的历史安全行驶记录符合要求，进而完成目标第二客户端的选择。其中，服务请求方的级别可以是根据服务请求中所携带的用户身份信息来确定。服务请求方的级别与服务要求的对应关系可以通过预先在服务器中以数据表的形式来记录，比如，服务要求的具体内容可以是不选择曾经过线过重大事故的司机，不选择最近两个月出现过闯红灯情况的司机等。

步骤S301的第二种执行方式，即，选择出所有与出行订单中的规划路线的安全信息相匹配的第二客户端作为目标第二客户端，此种方式确定出的目标第二客户端通常较多。

步骤S301的这两种执行方式相比，第一种执行方式可以根据第二客户端的历史安全行驶记录，控制目标第二客户端的数量，从而进一步提高向服务请求方提供的司机的质量。

如前文中的说明，步骤S102中可以采用向服务请求方进行询问的方式来确定服务请求方期望选择哪个规划路线出行，同样的，也可以采用向司机进行询问的方式来确认哪个司机期望承接出行订单，即步骤S302可以按照如下方式实现：

步骤3021，将出行订单中的规划路线和规划路线的安全信息发送给目标第二客户端，以获取目标第二客户端所返回的第二确认指令

步骤3022，根据第二确认指令，确定是否向目标第二客户端分配出行订单。

步骤3021中，将规划路线和规划路线的安全信息发送给目标第二客户端的目的是让司机进行参考，以辅助司机判断自己是否愿意承接这个订单。如果某个司机愿意承接该订单，则可以向服务器发送确定接单的指令(第二确认指令)，以使服务器确定出行订单的分配。

此处，出行订单的分配有两种方式，一种是广播式，一种是指定式。

其中，广播式指的是，当确定出的目标第二客户端有多个时，此时服务器可以同时向这些目标第二客户端广播出行订单中的规划路线和规划路线的安全信息(也可以理解为直接广播出行订单)，而后哪个目标第二客户端先回复表示接单的第二确认指令，就将出行订单分配给该目标第二客户端。

指定式指的是，确定的目标第二客户端只有一个，或者按照既定的派发规则，只是先向某一个目标第二客户端分配该订单，此时，服务器就指向这一个目标第二客户端推送出行订单中的规划路线和规划路线的安全信息(也可以理解为直接广播出行订单)，而后，如果该目标第二客户端同意承接出行订单就回复表示接单的第二确认指令，就将出行订单分配给该目标第二客户端。如果该目标第二客户端不同意承接出行订单就回复表示不接单的第二确认指令，或者是该目标第二客户端过长时间没有回复第二确认指令，服务器就可以将出行订单分配给其他第二客户端了，或者是取消该出行订单。

为了使服务请求方能够更加准确的判断自己选择哪个规划路线作为出行路线，可以是在发送规划路线和对应安全信息的时候，也将规划路线的拥堵信息发送给服务请求方，以辅助服务请求方进行判断。即，本申请所提供的方法还包括：

生成规划路线的拥堵信息；

步骤S102，将生成的规划路线和规划路线的安全信息发送给第一客户端，包括：

其中，生成的拥堵信息可以是表示拥堵时间的数据(表示司机完成出行路线所需要时间的数据)，也可以是表示拥堵程度的数据(说明出行路线拥堵程度的数据，如道路通畅、道路拥堵、道路严重拥堵等)，当然，也可以是这两种数据都携带在拥堵信息中。

在将生成的规划路线、规划路线的安全信息和规划路线的拥堵信息发送给第一客户端后，服务请求方可以同时根据这三个数据(规划路线、安全信息和拥堵信息)来判断具体选择哪个规划路线作为出行路线。

不仅服务请求方在选择哪个规划路线作为出行路线的时候可以使用到拥堵信息，司机在判断自己是否愿意接单的时候，也可以使用拥堵信息进行辅助，也就是，步骤将出行订单中的规划路线和规划路线的安全信息发送给目标第二客户端包括：

将出行订单中的规划路线、规划路线的安全信息和规划路线的拥堵信息发送给目标第二客户端。

通过这种方式能够使司机能够更为有利的判断自己是否愿意承接出行订单，提高了司机判断的准确度。

在司机同意承接出行订单后，服务器可以对司机运载乘客的过程进行安全监控，以提高运载乘客过程中，乘客的安全度。

也就是，如图4所示，本申请所提供的方法还包括：

S401，在出行订单被分配后，实时根据第一客户端的行进路线或被分配出行订单的第二客户端的行进路线生成实际行进路线；

S402，计算实际行进路线的实时安全评价值；

S403，根据实际行进路线的实时安全评价值进行安全操作。

步骤S401中，出行订单被分配后，指的是司机回复第二确认信息表示愿意承接出行订单，并且服务器将出行订单分配给对应的司机之后(或者是说司机成功接单后)。

实际行进路线反映了第一客户端的行进路线或者是承接出行订单的司机所使用的第二客户端的行进路线。通常情况下，第一客户端的行进路线和承接出行订单的司机所使用的第二客户端的行进路线应当是相同的，因为司机和乘客应当乘坐同一辆车出行，因此，可以直接将第一客户端的行进路线或者是承接出行订单的司机所使用的第二客户端的行进路线作为实际行进路线。

大部分的情况下，实际行进路线和出行订单中的出行路线应当是一致的，也就是司机应当按照出行路线来运载乘客，但实际上，司机可能会有绕路或者是其他不按照规定路线运载乘客的行为，又或者是随着时间的推移，司机运载乘客时，出行路线的安全状态和服务请求方在确认出行路线时的安全状态发生了改变，因此，还需要实时的计算实际行进路线的安全评价值，并根据安全评价值进行相应的安全操作，以保证司机和乘客的安全。

进而，步骤S402中，需要根据实际行进路线的参数计算实际行进路线的安全评价值。计算实际行进路线的安全评价值所使用到的参数可以是一下的任意一个或多个：

第一客户端所发出的安全反馈信息、第二客户端所发出的安全反馈信息、实时时间、实时天气状况、实际行进路线的偏僻程度、实际行进路线与出行订单所对应的规划路线的偏离程度、乘客信息。

其中，第一客户端所发出的安全反馈信息，指的是乘客手动输入的表示乘客/司机当前安全情况的信息，安全反馈信息的内容可以是处于危险状态、处于正常状态等，还可以是进一步表示具体安全情况的描述性文字，如司机正在开车打电话，处于危险驾驶状态。类似的第二客户端所发出的安全反馈信息是由司机手动输入的表示乘客/司机当前安全情况的信息。某种程度上，第一客户端所发出的安全反馈信息、第二客户端所发出的安全反馈信息可以作为乘客或司机直接进行安全预警的信息，如果安全反馈信息表示司机或乘客处于较为危险的状态，则服务器可以直接选择与第三方安全机构直接进行沟通。

实时时间指的是计算实时安全评价值时所处的时间。实时天气状况指的是计算实时安全评价值时的天气情况，天气情况具体有雨、雪、阴晴情况、气温等条件，当然，还可以进一步细化每种条件的具体内容。比如，小雨、中雨、大雨、暴雨、下雪中、雪停、路面有残留积雪、阴天高温等。这些天气状况都一定程度上会影响司机的驾驶安全。比如，刚下雨和刚下雪的时候，路面会比较滑，会影响司机驾驶的安全；又比如，在积雪很厚的时候驾驶，要比在刚下雪的时候驾驶更安全一些，因此，通常积雪很厚和刚下雪这两种情况会导致实时安全评价值有着不同的计算结果。通常情况下，天气情况越恶劣，则计算得到的实时安全评价值的数值就应当越低。

实际行进路线的偏僻程度指的是当前的位置的偏僻程度，或者是当前所走的路段的偏僻程度，该偏僻程度可以反映出车辆与主路之间的距离，或者是反映出车辆与人群集中地(如某个住户较多的小区，或者是某些聚集有大量自然人的地区)之间的距离。该偏僻程度主要是根据当前位置/当前路段与交通主干道(如国道、省道、市内环路等主干道)、小区的距离，或者是根据当前位置/当前路段与小区、集会中心这种人数较多的道路的距离计算得到的。通常情况下，实际行进路线的越偏僻，则计算得到的实时安全评价值的数值就应当越低。

实际行进路线与出行订单中规划路线的偏离程度，可以是根据实际行进路线与出行订单中规划路线计算重合度，该重合度即可以表征实际行进路线与出行订单中规划路线的偏离程度。具体计算的时候，可以是先计算出实际行进路线中未与出行订单中的规划路线相重合的路段(未重合路段)，之后，再计算未重合路段与出行订单中的规划路线中最近的路段之间的距离(该距离可以使用欧氏距离进行表示，也可以使用从未重合路段行驶至出行订单中的规划路线中指定路段的距离来表示)。

乘客信息指的是用于描述乘客类别/属性的信息，如年龄、性别、职业等信息。

使用上述参数中的一种或多种计算实际行进路线的实时安全评价值后，就可以根据该实际路线的实时安全评价值进行相应的安全操作。

在实际执行安全操作之前，可以先对安全评价值进行判断，如果安全评价值较高，则说明目前车辆行驶处于安全状态，此时不需要通过安全操作进行干预。

进而，步骤S403，根据实际行进路线的实时安全评价值进行安全操作，可以按照如下方式执行：

判断实时安全评价值是否低于预设的阈值；

在执行安全操作的时候，由于安全评价值的数值是有差别的(不同的安全评价值说明当前车辆的运行处于不同的安全级别，或者是说明当前车辆的运行处于不同的安全状况)，因此可以针对不同的安全评价值设置不同操作规则，以针对性的进行处理。

也就是，步骤根据实际行进路线的实时安全评价值进行安全操作包括：

根据查找到的安全操作方式进行操作。

其中，预先设置的实时安全评价值与安全操作方式之间的对应关系是预存在服务器中的，服务器应当可以在确定实时安全评价值后，马上通过调用的方式获取到实时安全评价值与安全操作方式之间的对应关系。安全操作方式应当有多种，每种安全操作方式的内容应当是有差别，即随着安全评价值的变化，对应的安全操作方式也应当适应性的进行调整。如当安全评价值为0-10区间内，则对应的是第一种安全操作方式；当安全评价值为11-50区间内，则对应的是第二种安全操作方式；当安全评价值为51-100区间内，则对应的是第三种安全操作方式。

通常情况下，安全操作方式可以有至少两种，即进行安全操作和不进行安全操作，此处的不进行安全操作指的是不进行任何处理。或者是，安全操作方式可以有至少两种，即进行轻度的安全操作和进行重度的安全操作。

通常情况下，预存的安全操作方式应当至少有一种，经过本申请发明人的测试，认为，安全操作方式可以包括以下的任意一种或多种：

系统自动干预操作、人工干预操作和紧急干预操作。

其中，系统自动干预操作指的是基本不需要人工干预，只是由服务器所在的系统自动响应所完成的操作，比如发送应用程序(如打车的APP)内显示的提示信息(只有用户打开应用程序后，才会在用户的手机上显示安全提示弹窗，或者是在应用程序的界面上显示相应的文字提示信息)、发送应用程序内播放的语音提示信息等。发送的数据(提示信息、语音信息)可以是只向第一客户端发送，也可以是只向被分配出行订单的第二客户端发送，还可以是同时向第一客户端和被分配出行订单的第二客户端发送。提示信息的内容可以入“请回复当前是否处于安全状态”。

人工干预操作指的是由工作人员亲自执行，但干预强度较低的操作。人工干预操具体如，发送进行安全确认的短信息、通过人工客服进行语音安全确认。发送的短信息可以是只向第一客户端发送，也可以是只向被分配出行订单的第二客户端发送，还可以是同时向第一客户端和被分配出行订单的第二客户端发送。类似的，语音安全确认也可以是只和第一客户端确认，也可以是只和被分配出行订单的第二客户端确认，还可以是分别和第一客户端和被分配出行订单的第二客户端确认。进行安全确认的短信息可以入“请回复短信息以说明安全状态”。发送在应用程序内播放的语音提示信息和通过人工客服进行语音安全确认的差别在于，应用程序内播放的语音提示信息并不是实时通话，而通过人工客服进行语音安全确认则是要通过实时通话来完成安全确认。

紧急干预操作指的是干预强度超过人工干预操作的操作(紧急干预操作通常也是由人工来完成的)。紧急干预操作具体如，将实际行进路线或出行订单向紧急联系人发送、通过专属客服进行语音安全确认、与第三方安全机构进行联动。

其中，紧急联系人可以是司机的紧急联系人，也可以是乘客的紧急联系人。在将实际行进路线或出行订单向紧急联系人发送前，服务器首先需要确定紧急联系人的联系方式，该紧急联系人的联系方式通常是司机或乘客预先上报给服务器的。第三方安全机构通常是指公立的具有安全监督职能的机构。通过专属客服进行语音安全确认指的是和司机进行语音安全确认，也可以是指和乘客进行语音安全确认，还可以是指和司机的紧急联系人进行语音安全确认，也还可以是指和乘客的紧急联系人进行语音安全确认。

通过专属客服进行语音安全确认和通过人工客服进行语音安全确认的差别在于，专属客服可以理解为只服务于该司机或该乘客的客服，该客服的工作内容相对单一，不会造成由于处理其他事情而导致客服与乘客或司机联系缓慢的情况。当然，专属客服还可以理解为只进行紧急干预操作中语音安全确认的客服。

具体的，预先设置的实时安全评价值与安全操作方式之间的对应关系可以通过多种形式表达，比如，可以通过如下表3的形式进行表达。

表3

表3中，示出了安全操作的名称，具体安全操作的方式和对应的安全评价值范围。

比如，服务器计算得到在某时间的安全评价值是35，则应当采用人工干预操作的方式进行操作，即可以选择发送短信和人工客服电话确认安全的方式进行确认。又比如，服务器计算得到在某时间的安全评价值是60，则应当采用紧急干预操作的方式进行操作，即可以选择箱紧急联系人拨打电话。

不论在司机运载乘客的过程中是否出现的问题，在司机将乘客运送到目的地后(或者是说出行订单完成后)，都可以由司机或乘客对本次出行进行评价，并根据评价的内容确定是否要进行追溯。

进而，本申请所提供的方法还包括：

步骤501，获取第一客户端或被分配出行订单的第二客户端所发送的关于出行订单的出行评价数据；

步骤502，根据出行评价数据确定事故等级；

步骤503，若事故等级超过预定的数值，则执行事故等级所对应的操作机制。

步骤501中，出行评价数据反映的是司机或乘客针对安全方面，对本次出行进行的评价。评价的内容可以包括对出行过程的文字说明，也可以是对司机服务的评价。对出行过程的文字说明如“本次出行较为安全”，“本次出行有一次闯红灯的行为”等。司机服务的评价可以入“司机驾驶平稳”、“司机容易出现急加速或急减速的行为”等内容。

步骤502中，可以依据出行评价数据可以计算出对应的事故等级，通常情况下事故等级至少应当分为两级，分别是不进行主动追溯的级别(出行订单正常完成，没有出现事故，不需要追溯)，和需要进行主动追溯的级别(出行订单非正常完成，可能出现事故，需要追溯)。

当然，需要进行主动追溯的级别还可以根据需要进一步进行细分。比如低级的主动追溯(对应低级事故，如闯红灯)和高级的主动追溯(对应高级事故，如发生撞车情况、发生撞人情况)，当然，不同的级别应当有不同的操作机制。

进而，步骤503中，如果事故等级过高，达到的需要主动追溯的级别，那就需要根据事故等级确定对应的操作机制(追溯机制)，并按照确定的操作机制进行处理。

具体的，事故等级和操作机制的对应关系可以如下表4中的记载：

表4

表4中，将事故等级分为了三级，分别是无事故、轻微事故和重大事故。具体执行的时候，服务器可以根据事故等级所对应的操作机制进行处理。其中，向司机发送警示消息可以理解为，和司机说明司机还需要注意哪些关于行车安全方面的问题。具体而言，还可以将乘客所提供的出行评价数据向司机推送，以使司机清楚的了解到乘客的实际想法，以促使司机对自己的驾驶行为进行改进。

和第三方安全机构进行事故确认可以是指从官方的数据库(交警的事故录像数据库)中调取司机的事故录像，或者是和第三方安全机构确认司机是否发生了严重事故，如发生了严重事故则可以采用更进一步的处理方式来处理。

整体来看本申请所提供的方法，其通过在确定出行订单前，先将规划路线和规划路线的安全信息发送给乘客，以辅助乘客选择采用哪个规划路线出行。在司机按照出行订单运载乘客的过程中，服务器会对出行的状况进行实时的安全监控，并根据安全监控的结果进行相应的处理。在出行订单完成之后，服务器还会与司机、乘客对本次出行的情况进行关于安全方面的确认，使得安全提示、安全监督的过程贯穿了乘客出行前、出行中和出行后，大大提高了乘客出行的安全程度。

如图6所示，示出了是本申请一些实施例的订单生成方法所在的服务系统100的框图。例如，服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统100可以包括服务器110(本申请所提供方法的执行主体)、网络120、服务请求方终端130(第一客户端)、服务提供方终端140(第二客户端)和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器112。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有本申请中图7所示的一个或多个组件的电子设备1000上实现。

网络120可以用于信息和/或数据的交换。在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、无线局域网(Wireless Local Area Networks，WLAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、公共电话交换网(Public Switched TelephoneNetwork，PSTN)、蓝牙网络、ZigBee网络、或近场通信(Near Field Communication,NFC)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换节点，服务系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求方终端130的用户可以是除服务实际需求者之外的其他人。例如，服务请求方终端130的用户A可以使用服务请求方终端130来为服务实际需求者B发起服务请求(比如，用户A可以为自己的朋友B叫车)，或者从服务器110接收服务信息或指令等。在一些实施例中，服务提供方终端140的用户可以是服务实际提供者，也可以是除服务实际提供者之外的其他人。例如，服务提供方终端140的用户C可以使用服务提供方终端140接收由服务实际提供者D提供服务的服务请求(比如用户C可以为自己雇用的司机D接单)，和/或来自服务器110的信息或指令。在一些实施例中，“服务请求方”和“服务请求方终端”可以互换使用，“服务提供方”和“服务提供方终端”可以互换使用。

在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(Personal Digital Assistant，PDA)、游戏设备、导航设备、或销售点(point of sale，POS)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。

在一些实施例中，服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中，服务提供方终端140可以是具有定位技术的设备，用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM)；RAM可以包括动态RAM(Dynamic RandomAccess Memory,DRAM)，双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM)；静态RAM(Static Random-Access Memory,SRAM)，晶闸管RAM(Thyristor-Based Random Access Memory,T-RAM)和零电容器RAM(Zero-RAM)等。作为举例，ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-OnlyMemory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中，数据库150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。

下面以两个个具体的实例，来说明本申请所提供的订单生成方法。

实例1:如图5所示的订单生成方法包括如下步骤：

步骤1，获取乘客所发出的服务请求；

步骤2，根据服务请求中携带的上车地点和下车地点生成规划路线和规划路线的安全评分；

步骤3，向乘客发送生成规划路线和规划路线的安全评分；

步骤4，接收乘客回复的第一确认指令；若第一确认指令为选择指令，则执行步骤5；若第一确认指令为拒绝指令，则执行步骤7；若第一确认指令为中携带有新的服务请求，则根据新的服务请求重新执行步骤2；

步骤5，根据选择指令，从步骤3中所发送的规划路线中选择一个规划路线作为出行路线；

步骤6，根据出行路线生成出行订单；

步骤7，终止流程。

实例2，订单生成方法包括如下步骤：

步骤1，获取乘客所发出的服务请求；

步骤3，向乘客发送生成规划路线和规划路线的安全评分；

步骤4，接收乘客回复的第一确认指令；若第一确认指令为选择指令，则执行步骤5；若第一确认指令为拒绝指令，则执行步骤26；若第一确认指令为中携带有新的服务请求，则根据新的服务请求重新执行步骤2；

步骤6，判断出行路线的安全评分是否高于预设的数值；若高于则执行步骤7，若低于，则执行步骤9；

步骤7，向用户发出风险提示信息；

步骤8，接收用户回复的关于确认风险提示信息的第二确认指令；若第二确认指令表示了解风险，并同意下单，则执行步骤9；若第二确认指令表示了解风险，并不同意下单，则执行步骤26；若第二确认指令表示了解风险，并修改服务请求，则返回执行步骤2；

步骤9，根据出行路线生成出行订单；

步骤10，根据出行路线的安全评分选择对应的目标司机群体；

步骤11，向目标司机群体广播出行订单；

步骤12，接收目标司机群体中的司机所回复的第三确认指令；

步骤13，根据第三确认指令选择目标司机群体中指定的司机作为目标司机；

步骤14，判断出行路线的安全评分是否高于预设的数值；若出行路线的安全评分高于预设的数值，则向目标司机发出风险提示信息；

步骤15，接收目标司机回复的关于确认步骤14的风险提示信息的第四确认指令；若第四确认指令表示了解风险，并同意，则执行步骤16；若第四确认指令表示了解风险，并拒绝同意，则执行步骤26；

步骤16，将出行订单向目标司机分配；

步骤17，获取实际进行路线；实际行进路线是乘客的行进路线或司机的进行路线；

步骤18，计算实际行进路线的安全评价值；

步骤19，判断安全评价值是否高于预设的阈值；若安全评价值高于预设的阈值，则执行步骤20；若安全评价值高于预设的阈值，则执行步骤26；

步骤20，通过人工客户向乘客拨打电话，以确认乘客是否处于危险状态。

步骤21，在接收到订单完成的消息后，向乘客发送获表示取出行评价数据的请求；

步骤22，接收乘客所发送的出行评价数据；

步骤23，根据出行评价数据计算事故等级；

步骤24，判断事故等级是否超过预定的数值；若事故等级超过预定的数值，则执行步骤25；事故等级未超过预定的数值，则执行步骤26；

步骤25，采用与事故等级相对应的紧急安全追溯策略进行处理；

步骤26，终止流程。

上述步骤序号并不代表步骤执行的先后关系，步骤的执行先后关系应当以步骤中具体内容的衔接为准。

与上述方法相对应的，本申请还提供了一种订单生成装置，包括：

第一生成模块，用于根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；所述第一客户端为服务请求方使用的客户端；

第一发送模块，用于将生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端，以获取第一客户端返回的第一确认指令；

优选的，所述装置还包括：

第一分配模块，用于将出行订单分配给目标第二客户端。

优选的，第一分配模块包括：

第一确定单元，用于根据所述第二确认指令，确定是否向所述目标第二客户端分配所述出行订单。

优选的，所述装置还包括：

第三生成模块，用于生成规划路线的拥堵信息；

第一发送模块包括：

第二发送单元，用于将生成的所述规划路线、所述规划路线的安全信息和规划路线的所述拥堵信息发送给所述第一客户端。

优选的，所述安全信息包括以下任意一种或多种信息：

所述规划路线的整体安全评分；规划路线的整体安全提示信息；规划路线中指定路段的安全评分；规划路线中指定路段的安全提示信息。

优选的，第一生成模块包括：

第一生成单元，用于根据服务请求生成至少一个规划路线；

优选的，还包括：

第一判断模块，用于判断生成的所述规划路线的安全信息是否满足预设的要求；在确定生成的所述规划路线的安全信息不满足预设的要求后，执行步骤将生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端；

在确定生成的所述规划路线的安全信息满足预设的要求后，执行步骤根据所述规划路线生成出行订单。

优选的，第二生成模块包括：

识别单元，用于识别第一确认指令；

在确定第一确认指令为订单修改指令后，则识别单元，还用于根据订单修改指令重新生成至少一条规划路线和规划路线的安全信息，并将重新生成的规划路线和规划路线的安全信息发送给第一客户端，以获取第一客户端返回的第一确认指令。

优选的，还包括：

第一计算模块，用于计算实际行进路线的实时安全评价值；

优选的，第一操作模块包括：

第二操作单元，用于根据查找到的安全操作方式进行操作。

优选的，安全操作方式包括：

系统自动干预操作、人工干预操作和紧急干预操作。

优选的，所述系统自动干预操作包括以下的任意一种或多种：

所述人工干预操作包括以下的任意一种或多种：

所述紧急干预操作包括以下的任意一种或多种：

优选的，第一计算模块包括：

优选的，还包括：

第一确定模块，用于根据出行评价数据确定事故等级；

第二操作模块，若事故等级超过预定的数值，则用于执行所述事故等级所对应的操作机制。

与上述方法相对应的，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如订单生成方法的步骤。

如图6所示，为本申请实施例所提供的电子设备示意图，该电子设备1000包括：处理器1001、存储器1002和总线1003，存储器1002存储有执行指令，当电子设备运行时，处理器1001与存储器1002之间通过总线1003通信，处理器1001执行存储器1002中存储的订单生成方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims

1.一种订单生成方法，其特征在于，包括：

根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息；所述第一客户端为服务请求方使用的客户端；

将生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端，以获取第一客户端返回的第一确认指令；

根据第一确认指令所确认使用的规划路线，生成出行订单。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据出行订单中的规划路线的安全信息，选择与安全信息相匹配的第二客户端作为目标第二客户端；所述第二客户端为服务提供方使用的客户端；

将出行订单分配给所述目标第二客户端。

3.根据权利要求2所述的方法，其特征在于，步骤将出行订单分配给目标第二客户端包括：

将所述出行订单中的规划路线和规划路线的安全信息发送给所述目标第二客户端，以获取所述目标第二客户端所返回的第二确认指令；

根据所述第二确认指令，确定是否向所述目标第二客户端分配所述出行订单。

4.根据权利要求1所述的方法，其特征在于，还包括：

生成所述规划路线的拥堵信息；

步骤将生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端包括：

将所述生成的所述规划路线、所述规划路线的安全信息和规划路线的所述拥堵信息发送给所述第一客户端。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述安全信息包括以下任意一种或多种信息：

6.根据权利要求1所述的方法，其特征在于，步骤根据第一客户端所发出的服务请求，生成至少一条规划路线和规划路线的安全信息包括：

根据服务请求生成至少一个规划路线；

7.根据权利要求1所述的方法，其特征在于，还包括：

判断生成的所述规划路线的安全信息是否满足预设的要求；

在确定生成的所述规划路线的安全信息不满足预设的要求后，执行步骤将生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端；

8.根据权利要求1所述的方法，其特征在于，步骤根据第一确认指令所确认使用的规划路线，生成出行订单包括：

识别第一确认指令；

在确定第一确认指令为订单修改指令后，根据所述订单修改指令重新生成至少一条规划路线和规划路线的安全信息，并将重新生成的所述规划路线和所述规划路线的安全信息发送给所述第一客户端，以获取第一客户端返回的第一确认指令。

9.根据权利要求1所述的方法，其特征在于，还包括：

计算实际行进路线的实时安全评价值；

根据实际行进路线的实时安全评价值进行安全操作。

10.根据权利要求9所述的方法，其特征在于，步骤根据实际行进路线的实时安全评价值进行安全操作包括：

判断实时安全评价值是否低于预设的阈值；

11.根据权利要求9所述的方法，其特征在于，步骤根据实际行进路线的实时安全评价值进行安全操作包括：

根据查找到的安全操作方式进行操作。

12.根据权利要求11所述的方法，其特征在于，安全操作方式包括：

系统自动干预操作、人工干预操作和紧急干预操作。

13.根据权利要求12所述的方法，其特征在于，所述系统自动干预操作包括以下的任意一种或多种：

发送在应用程序内播放的语音提示信息、发送在应用程序内显示的提示信息；

所述人工干预操作包括以下的任意一种或多种：

所述紧急干预操作包括以下的任意一种或多种：

14.根据权利要求9所述的方法，其特征在于，步骤计算实际行进路线的实时安全评价值包括：

15.根据权利要求1所述的方法，其特征在于，还包括：

根据出行评价数据确定事故等级；

若事故等级超过预定的数值，则执行所述事故等级所对应的操作机制。

16.一种订单生成装置，其特征在于，包括：

17.根据权利要求16所述的装置，其特征在于，所述装置还包括：

第一分配模块，用于将出行订单分配给目标第二客户端。

18.根据权利要求17所述的装置，其特征在于，第一分配模块包括：

19.根据权利要求16所述的装置，其特征在于，所述装置还包括：

第三生成模块，用于生成规划路线的拥堵信息；

第一发送模块包括：

20.根据权利要求16-19任一项所述的装置，其特征在于，所述安全信息包括以下任意一种或多种信息：

21.根据权利要求16所述的装置，其特征在于，第一生成模块包括：

第一生成单元，用于根据服务请求生成至少一个规划路线；

22.根据权利要求16所述的装置，其特征在于，还包括：

23.根据权利要求16所述的装置，其特征在于，第二生成模块包括：

识别单元，用于识别第一确认指令；

24.根据权利要求16所述的装置，其特征在于，还包括：

第一计算模块，用于计算实际行进路线的实时安全评价值；

25.根据权利要求24所述的装置，其特征在于，第一操作模块包括：

26.根据权利要求24所述的装置，其特征在于，第一操作模块包括：

第二操作单元，用于根据查找到的安全操作方式进行操作。

27.根据权利要求26所述的装置，其特征在于，安全操作方式包括：

系统自动干预操作、人工干预操作和紧急干预操作。

28.根据权利要求27所述的装置，其特征在于，所述系统自动干预操作包括以下的任意一种或多种：

所述人工干预操作包括以下的任意一种或多种：

所述紧急干预操作包括以下的任意一种或多种：

29.根据权利要求24所述的装置，其特征在于，第一计算模块包括：

30.根据权利要求16所述的装置，其特征在于，还包括：

第一确定模块，用于根据出行评价数据确定事故等级；

31.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行时执行如权利要求1至15任一所述的订单生成方法的步骤。

32.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至15任一所述的订单生成方法的步骤。