一种基于预约出行的行车组织方案制定方法与流程

本公开的实施例一般涉及轨道交通领域，并且更具体地，涉及一种基于预约出行的行车组织方案制定方法、系统、设备和计算机可读存储介质。

背景技术：

地铁是大城市最繁忙的交通系统之一，受大城市人口的持续增长及潮汐客流特征等因素影响，地铁的拥挤程度已经超过了很多人可以承受的范围，且大量的时间花费在出行途中或者等待乘车的过程中。

由于人们出行没有统一规划性，导致很多乘客在早晚高峰期间部分车站进站速度缓慢，降低了整体乘车出行感受，如果可以通过一个预约机制来合理分配乘客出行时间，预计可以大量减少集中出行带来的很多问题。

目前地铁也在做一些预约出行的尝试，但这种预约出行主要体现在优先进站方面，并没有和行车组织安排结合起来，难以真正做到客流和车流的高效耦合，难以有效提升乘客出行体验。

技术实现要素：

本公开旨在至少解决现有技术或相关技术中存在的技术问题之一。

为此，在本公开的第一方面，提供了一种基于预约出行的行车组织方案制定方法。该方法包括：

获取乘客预约出行信息；

对所述乘客预约出行信息进行分析，确认是否预约成功并反馈给所述乘客；

根据预设时间内预约成功的乘客预约出行信息，制定乘客出行需求运行图。

进一步地，所述乘客预约出行信息包括出行日期、出行始发车站、出行终到车站、乘车时间和乘车时间偏差。

进一步地，

乘客出行方式为预约出行；所述对所述乘客预约出行信息进行分析，确认是否预约成功包括：

基于预设的行车计划及当前预约情况对所述预约出行信息分析，判断列车满载率是否符合预设标准，如是，则预约成功；

如否，则向所述乘客发送是否调整至其他车次进行乘车的提示信息，若所述乘客调整至其他车次，则判断所调整车次的列车满载率是否符合预设标准；如果所述乘客坚持原有预约出行信息，则统计对应乘车时间的预约人数，当预约人数超过预设阈值，则增加该乘车时间的列车数量和/或发车频率。

进一步地，

所述预约出行方式包括在第一预设时间段内预约出行和在第二预设时间段内预约出行；

若乘客在第一预设时间段内预约出行，则基于预设的行车计划及当前预约情况对所述预约出行信息分析，判断选择列车满载率是否符合第一预设标准，若符合，则预约成功；根据第一预设时间段内预约成功的乘客预约出行信息，制定乘客出行需求运行图；

若乘客在第二预设时间段内预约出行，判断列车满载率是否符合第二预设标准，若符合，则预约成功。

进一步地，

乘客出行方式为预约出行和实时出行；

若乘客出行方式为预约出行，则基于预设的行车计划及当前预约情况对所述预约出行信息分析，判断选择列车满载率是否符合第三预设标准，如是，则预约成功，根据预约成功的乘客预约出行信息，制定乘客出行需求运行图；

如否，则向所述乘客发送是否调整至其他车次进行乘车的提示信息，若所述乘客调整至其他车次，则判断所调整车次的列车满载率是否符合第三预设标准；如果所述乘客坚持原有预约出行信息，则统计对应乘车时间的预约人数，当预约人数超过预设阈值，则增加该乘车时间的列车数量和/或发车频率。

若乘客为实时出行，则获取出行车站的客流量实际表现信息、列车预计上下车乘客流量信息和列车到站时间信息；

对所述出行车站的客流量实际表现信息、列车预计上下车乘客流量信息和列车到站时间信息进行分析，根据分析结果进行限流和/或运力调整措施。

进一步地，还包括：

行程结束后，对所述乘客的个人出行信息进行记录；所述个人出行信息包括所述乘客是否按照预约出行信息进行乘车；

基于预设的信用评估机制对所述个人出行信息进行分析，根据分析结果对所述乘客进行奖励或处罚。

进一步地，所述处罚包括：

对所述乘客预约出行的预约时间、预约车次服务进行限制和/或提高所述乘客的预约费用。

在本公开的第二方面，提出了一种基于预约出行的行车组织方案制定系统，包括：

获取模块，用于获取乘客预约出行信息；

分析模块，用于对所述乘客预约出行信息进行分析，确认是否预约成功并反馈给所述乘客；

制定模块，用于根据预设时间内预约成功的乘客预约出行信息，制定列车运行图。

在本公开的第三方面，提出了一种设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如根据本公开的上述方法。

在本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如根据本公开的上述方法。

本申请实施例提供的基于预约出行的行车组织方案制定方法，通过获取乘客预约出行信息；对所述乘客预约出行信息进行分析，确认是否预约成功并反馈给所述乘客；根据预设时间内预约成功的乘客预约出行信息，制定乘客出行需求运行图，解决了现有列车运行图编制运力与运量不匹配问题，减少了低峰时段列车出现空载情况或者高峰时段出现区间断面满载度过高的情况，实现了运力与运量的最优匹配，提升了乘客的出行感受。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1是本申请的一个实施例可以应用于其中的示例性系统架构图；

图2是根据本申请的基于预约出行的行车组织方案制定方法实施例一的流程图；

图3是根据本申请的基于预约出行的行车组织方案制定方法实施例二的流程图；

图4是根据本申请的基于预约出行的行车组织方案制定方法实施例三的流程图；

图5是用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本公开保护的范围。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

图1示出了可以应用本申请的用于生成信息的方法或用于生成信息的装置的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如模型训练类应用、视频识别类应用、网页浏览器应用、社交平台软件等。

终端设备101、102、103可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、mp3播放器(movingpictureexpertsgroupaudiolayeriii，动态影像专家压缩标准音频层面3)、mp4(movingpictureexpertsgroupaudiolayeriv，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中。其可以实现成多个软件或软件模块(例如用来提供分布式服务的多个软件或软件模块)，也可以实现成单个软件或软件模块。在此不做具体限定。

当终端101、102、103为硬件时，其上还可以安装有视频采集设备。视频采集设备可以是各种能实现采集视频功能的设备，如摄像头、传感器等等。用户可以利用终端101、102、103上的视频采集设备来采集视频。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的数据处理的后台服务器。后台服务器可以对接收到的数据进行分析等处理，并可以将处理结果(预约结果)反馈给终端设备。

需要说明的是，服务器可以是硬件，也可以是软件。当服务器为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务的多个软件或软件模块)，也可以实现成单个软件或软件模块。在此不做具体限定。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。特别地，在目标数据不需要从远程获取的情况下，上述系统架构可以不包括网络，而只包括终端设备或服务器。

实施例一

如图2所示，是本申请实施例一种基于预约出行的行车组织方案制定方法的流程图，所述方法适用于所有乘客均在出行前至少一日进行预约出行。从图2中可以看出，本实施例的基于预约出行的行车组织方案制定方法，包括以下步骤：

s210，获取乘客预约出行信息。

在本实施例中，用于基于预约出行的行车组织方案制定方法的执行主体(例如图1所示的服务器)可以通过有线方式或者无线连接的方式获取乘客预约出行信息。

所述预约出行信息包括：选择出行的日期、出行始发车站、出行终到车站、乘车时间和乘车时间偏差等，所述乘车时间偏差为乘客可接受的乘车时间偏差。

通常，乘客在出行前一日对次日的乘车出行进行预约。

s220，对所述乘客预约出行信息进行分析，确认是否预约成功并反馈给所述乘客。

可选地，基于预设的行车计划及当前预约情况对所述预约出行信息分析，判断列车满载率是否符合预设标准。所述列车满载率为乘客选择的出行列车满载率。

其中，所述预设的行车计划基于可配置的资源(包括可用列车数量、服务人员配置等)及设备系统能力(包括供电能力、线路通过能力等)确定。

所述当前预约情况包括在所述乘客进行预约前已进行预约的乘客人数(同一辆列车)。

若所述列车满载率小于预设标准，则预约成功，向乘客发送预约成功信息；

若所述列车满载率大于预设标准，则预约失败，向乘客发送预约失败信息。

可选地，向所述乘客发送预约失败信息时，可同时向所述乘客发送是否调整至其他车次进行乘车的提示信息，如果所述乘客选择调整至其他车次进行乘车，则进一步地判断所述乘客所选择的调整列车的满载率是否符合预设标准(符合则预约成功，不符合可继续选择调整列车)；

如果所述乘客选择不调整至其他车次进行乘车，即，坚持原有预约出行信息，则进入预约等待状态，在此状态下统计在一定时间内的预约人数。若在所述一定时间内预约人数超过一定阈值，则可以增加在该乘车时间内的列车数量和/或发车频率等操作，即预约成功；若不超过预设阈值，则通知该乘客预约失败。

可选地，所述预约人数可以为在所述一定时间内进行预约的人数，即，预约失败进入等待状态的人数；也可以为预约成功的乘客(相同车次)加预约失败进入等待状态的人数。

可选地，所述一定时间可根据实际应用场景进行设定。例如，若乘客预约乘车时间为乘车高峰期，则所述一定时间可设定为1小时；若乘客预约乘车时间为乘车低峰期，则所述一定时间可设定为3小时或当日系统终止预约时间(如晚21点)，对此不作具体限定。

可选地，若在所述一定时间内预约人数超过一定阈值，则可以增加在该乘车时间内的列车数量和/或发车频率。

例如，a型车4辆编组可共载客1240人，6辆编组可载客1860人，8辆编组可载客2480人；b型车4辆编组可共载客950人，5辆编组可载客1195人，6辆编组可载客1440人。

若，所述乘客在一定时间段内预约人数为1500人(阈值为1500)，则可在所述乘客预约乘车时间增加6辆编组a型车；所述1500人为预约失败进入等待状态的人数；

若，所述乘客在一定时间段内预约人数为1500人，所述1500人中包括预约成功的乘客1000人和预约失败进入等待状态的500人，则将原先的4辆编组a类车(载客1240人)调整为6辆编组a型车。

进一步地，所述阈值可根据历史预约信息、预约乘车时间可增派的列车型号和编组进行设定。

下面进行举例说明：

乘客在中午12点时，预约次日下午15点的列车，经过对选择列车的满载率分析后，发现满载率已超过预设标准，向该乘客发送是否调整至其他车次进行乘车的提示信息，该乘客接收到所述信息后选择不调整至其他车次进行乘车，此时进入预约等待状态，在当日下午3点时(一定时间设定为3小时)统计预约选择上述列车出行的预约人数(均为预约失败进入等待状态)，所述预约人数超过1500人(1500为预设阈值)，增加该乘车时间的列车数量，向所述乘客发送预约成功信息。

可选地，所述预设标准为100％，即，当列车满载率小于100％时，预约成功，大于等于100％时预约失败。

进一步地，所述预设标准可根据实际情况进行设定，例如，在乘车高峰期时段，预设标准可以设定为120％，在乘车低峰时段设定为80％。

s230，根据预设时间内预约成功的乘客预约出行信息，制定乘客出行需求运行图。

可选地，汇总预约日所有预约成功的乘客预约出行信息。例如，乘客在1.1日对1.2日的出行进行预约，则在1.1日终止乘客预约后汇总1.1日当天所有预约成功的乘客预约出行信息。

通过运行图自动编制系统对汇总的预约成功的乘客预约出行信息进行数据处理，编制符合乘客出行需求的运行图，并发送至ats系统(自动列车监控系统)。

出行日乘客可根据预约出行信息快速进站乘车。例如，出行日乘客按照既定时间(预约时间)到达车站后，刷二维码快速进站乘车。

进一步地，还包括：

行程结束后，即乘客选择的列车完成当前批次的运行后或检测到乘客的出站记录后，对所述乘客的个人出行信息进行记录。

可选地，所述个人出行信息包括所述乘客是否按照预约出行信息进行乘车。

可选地，基于预设的信用评估机制对所述个人出行信息进行分析，根据分析结果对所述乘客进行奖励或处罚。

具体地，所述预设的信用评估机制主要从出行守约、出行变更、费用支付等方面进行建设，各项按照一定的规则进行累计积分，并基于一定的权重计算综合信用得分，出现违约等行为时需要按照一定的规则进行扣分，信用持续表现良好的用户根据一定的规则适当给予积分奖励。如果综合信用得分或者特定的单项(出行守约、出行变更、费用支付等)得分低于一定的分值，则在后续预约过程中进行预约限制或采取其它惩罚机制。

可选地，以出行守约为例，积分满分为100分，若乘客按照预约进行乘车出行，则奖励10分(110分)，若所述乘客未按约定进行乘车，即，已预约成功但未乘车，则扣除积分5分(95分)。

当乘客的当前积分小于预设积分大于严惩积分时，即，违约情况不严重时，则对所述乘客进行相应的惩罚包括：对乘客预约出行的预约时间、预约车次服务进行限制和/或提高所述乘客的预约费用等。

例如，预设积分为100分，乘客当前积分为95分，预设严惩积分为80分，则对当前乘客的预约乘车时间进行限制，即，仅对所述乘客开放平峰和/或低峰预约出行服务。

当乘客的当前积分小于严惩积分时，即，违约情况严重时，则对所述乘客进行相应的惩罚包括：限制所述乘客一定时期内不能享受预约服务、一定时期内预约出行需支付的费用按照一定比例增加和/或注销账户等。

例如，预设积分为100分，乘客当前积分为70分，预设严惩积分为80分，则对当前乘客的预约乘车时间进行限制，在30天内关闭对所述乘客的所有预约出行服务。

当乘客的当前积分大于预设积分时，即，该乘车信用表现良好有一定的奖励积分，则对所述乘客进行相应的奖励。

例如，预设积分为100分，乘客当前积分为110分，则所述乘客在支付预约费用时(购票费用)，按照10积分折价一毛钱的换算原则进行费用减免，即，原价3元的预约费用仅需支付2.9元。同时清空所述乘客的兑换积分(由110分变为100分)。

可选地，不对所述乘客的积分进行清除，采用阶梯式折扣原则，即，用户当前积分为100-199分时，在支付预约费用时不进行费用减免，当用户积分为200-300分时，在支付预约费用时进行折扣支付，例如9.5折，即原价3元该乘客仅需支付2.85元，以此类推，不再赘述。

所述积分在一定周期内进行清空，例如，所述一个周期为三个月(一个季度)，则对三个月内乘客获取的积分进行累加，三个月后对所述积分进行清空从新计算。

本实施例，提前获取乘客的出行需求根据乘客不同的出行时间和出行距离来核算合理的列车运力配置方案，实现运力与运量的最优匹配，增强了乘客的出行感受。

实施例二

如图3所示，是本申请实施例一种基于预约出行的行车组织方案制定方法的流程图，所述方法适用于一部分乘客在出行前至少一日进行预约出行，另一部分乘客在乘车当天进行预约出行，即在第一预设时间段内预约出行和在第二预设时间段内预约出行。从图3中可以看出，本实施例的基于预约出行的行车组织方案制定方法，包括以下步骤：

s310，获取乘客在第一预设时间段内预约出行信息和在第二预设时间段内预约出行信息。

在本实施例中，用于基于预约出行的行车组织方案制定方法的执行主体(例如图1所示的服务器)可以通过有线方式或者无线连接的方式获取乘客在第一预设时间段内预约出行信息和在第二预设时间段内预约出行信息。

所述预约出行信息包括：选择出行的日期、出行始发车站、出行终到车站、乘车时间和乘车时间偏差等，所述乘车时间偏差为乘客可接受的乘车时间偏差。

可选地，所述第一预设时间段包括：

乘客在出行前至少一日对出行日的乘车出行进行预约；

所示第二预设时间段内预约出行包括：

乘客在出行日当天对乘车出行进行预约，通常至少在列车发车前5分钟内进行预约。(乘客可在系统中自行查看列车的发车运行时间等信息)

s320，对所述乘客在第一预设时间段内预约出行信息和在第二预设时间段内预约出行信息进行分析，确认是否预约成功并反馈给所述乘客。

所述对所述乘客在第一预设时间段内预约出行信息进行分析，可参考实施例一中的相应步骤，在此不再赘述。

需要说明的是，在本实施例中，当乘客在第一预设时间段内选择的列车满载率大于预设提醒标准时，向该乘客发送是否调整至其他车次进行乘车提示。例如，预设提醒标准为80％，即，选择的列车满载率次日预计会超过80％以上时，向乘客发送是否调整至其他车次进行乘车提示。

可选地，所述对所述乘客在第二预设时间段内预约出行信息进行分析包括：

根据所述乘客预约出行信息判断预约列车当前的列车满载率是否符合第二预设标准，若符合，则预约成功，向所述用户发送预约成功信息；若不符合，向所述用户发送预约失败信息。

可选地，向所述乘客发送预约失败信息时，可同时向所述乘客发送是否调整至其他车次进行乘车的提示信息，如果所述乘客选择调整至其他车次进行乘车，则进一步地判断所述乘客所选择的调整列车的满载率是否符合第二预设标准(符合则预约成功，不符合可继续选择调整列车)；

如果所述乘客选择不调整至其他车次进行乘车，即，坚持原有预约出行信息，则进入预约等待状态，在此状态下统计在一定时间内的预约人数。若在所述一定时间内预约人数超过一定阈值，则可以增加在该乘车时间内的列车数量和/或发车频率等操作，即预约成功；若不超过预设阈值，则通知该乘客预约失败。

可选地，所述一定时间可根据实际应用场景进行设定。例如，若乘客预约乘车时间为乘车高峰期，则所述一定时间可设定为1小时；若乘客预约乘车时间为乘车低峰期，则所述一定时间可设定为3小时，对此不作具体限定。

可选地，所述预约人数可以为在所述一定时间内进行预约的人数，即，预约失败进入等待状态的人数；也可以为预约成功的乘客(相同车次)加预约失败进入等待状态的人数。

可选地，若在所述一定时间内预约人数超过一定阈值，则可以增加在该乘车时间内的列车数量和/或发车频率。

例如，a型车4辆编组可共载客1240人，6辆编组可载客1860人，8辆编组可载客2480人；b型车4辆编组可共载客950人，5辆编组可载客1195人，6辆编组可载客1440人。

若，所述乘客在一定时间段内预约人数为1500人(阈值为1500)，则可在所述乘客预约乘车时间增加6辆编组a型车；所述1500人为预约失败进入等待状态的人数；

若，所述乘客在一定时间段内预约人数为1500人，所述1500人中包括预约成功的乘客1000人和预约失败进入等待状态的500人，则将原先的4辆编组a类车(载客1240人)调整为6辆编组a型车。

进一步地，所述阈值可根据历史预约信息、预约乘车时间可增派的列车型号和编组进行设定。

例如，乘客在中午12点时，预约当日下午15点的列车，经过对选择列车的满载率分析后，发现满载率已超过第二预设标准，向该乘客发送是否调整至其他车次进行乘车的提示信息，该乘客接收到所述信息后选择不调整至其他车次进行乘车，此时进入预约等待状态，在当日下午13点时(1小时统计一次预约人数，即一定时间为1小时)统计预约选择上述列车出行的预约人数(均为预约失败进入等待状态)，所述预约人数超过1500人(1500为预设阈值)，增加该乘车时间的列车数量，向所述乘客发送预约成功信息。

可选地，所述预约列车当前的列车满载率包括所述乘客可接受的偏差范围内的列车满载率。

可选地，所述第二预设标准为100％，即，当列车满载率小于100％时，预约成功，大于等于100％时预约失败。

进一步地，所述第二预设标准可根据实际情况进行设定，例如，在乘车高峰期时段，所述第二预设标准可以设定为120％，在乘车低峰时段设定为80％。

进一步地，还包括：

行程结束后，即乘客选择的列车完成当前批次的运行后或检测到乘客的刷卡出站记录后，对所述乘客的个人出行信息进行记录。基于预设的信用评估机制对所述个人出行信息进行分析，根据分析结果对所述乘客进行奖励或处罚。具体流程参考实施例一，在此不再赘述。

本实施例，进一步地考虑了乘客在乘车日进行预约出行的情况，增强了乘客的出行感受。

实施例三

如图4所示，是本申请实施例一种基于预约出行的行车组织方案制定方法的流程图，所述方法适用于一部分乘客进行预约出行，另一部分乘客实时出行，即乘客在第三预设时间段内预约出行和实时出行。从图3中可以看出，本实施例的基于预约出行的行车组织方案制定方法，包括以下步骤：

s410，获取乘客在第三预设时间段内预约出行信息和乘客选择的实时出行车站信息。

在本实施例中，用于基于预约出行的行车组织方案制定方法的执行主体(例如图1所示的服务器)可以通过有线方式或者无线连接的方式获取乘客在第三预设时间段内预约出行信息和实时出行的车站信息。

所述预约出行信息包括：选择出行的日期、出行始发车站、出行终到车站、乘车时间和乘车时间偏差等，所述乘车时间偏差为乘客可接受的乘车时间偏差。

所述第三预设时间段可以为上述实施例中的第一预设时间段和/或第二预设时间段，即，可以为提前至少一日预约；可以为乘车当日至少在列车发车前5分钟内进行预约；也可以为部分提前至少一日预约，部分至少在列车发车前5分钟内进行预约，对比不做具体限定，参考实施例一、二中对应的具体流程，在此不再赘述。

可选地，所述实时出行车站信息包括：

车站的客流量实际表现信息、列车预计上下车乘客流量信息和列车到站时间信息等。

对当日的运行图和预约成功的乘客信息进行分析，获取所述列车预计上下车乘客流量信息和列车到站时间信息。需要说明的是，所述预约成功的乘客信息为预约成功且已进行乘车的乘客信息。

所述客流量实际表现信息可通过车站的监测设备进行获取。所述监测设备包括视频监测设备、红外监测设备和/或热感应监测设备等。

s420，对所述乘客在第三预设时间段内预约出行信息和乘客选择的实时出行车站信息进行分析，确认是否能够成功乘车并反馈给所述乘客。

所述对所述乘客在第三预设时间段内预约出行信息进行分析，确认是否预约成功并反馈给所述乘客的具体步骤，参考实施例一、实施例二中对所述乘客在第一、第二预设时间段内预约出行信息进行分析，确认是否预约成功并反馈给所述乘客的步骤，在此不再赘述。

所述对实时出行车站信息行分析包括：

对客流量实际表现信息进行分析，根据分析结果采取必要的限流或运力调整措施。即，根据该车站的历史人流量信息和/或设定的人流量阈值对当前获取的客流量实际表现信息进行分析，判断该车站当前的客流量情况，若所述客流量较大时(如超出设定的人流量阈值)，则采取必要的限流或运力调整措施；和/或

对列车预计上下车乘客流量信息和列车到站时间信息进行分析，根据分析结果采取必要的限流或运力调整措施。即，根据该车站站台的历史人流量信息和/或设定的站台人流量阈值对列车预计上下车乘客流量信息和列车到站时间信息进行分析，判断该车站站台的客流量情况，若所述客流量较大时(如超出设定的站台人流量阈值)，则采取必要的限流或运力调整措施。所述站台的客流量包括当前和预计的客流量，即，当前未上车乘客和预约到站下车的乘客。

可选地，所述运力调整措施包括加开列车数量、加开列车地点和/或加开列车时间等措施。

进一步地，还包括：

行程结束后，即乘客选择的列车完成当前批次的运行后或检测到乘客的刷卡出站记录后，对所述乘客的个人出行信息进行记录。基于预设的信用评估机制对所述个人出行信息进行分析，根据分析结果对所述乘客进行奖励或处罚。具体流程可参考实施例一，在此不再赘述。

需要说明的是，对于实时乘车的乘客不进行奖励或处罚，即，不适用于所述信用评估机制。

本实施例，进一步地考虑了部分乘客未进行预约，通过实时购票方式进行出行的情况，增强了乘客的出行感受。

本申请实施例还提出了一种基于预约出行的行车组织方案制定系统，包括：

获取模块，用于获取乘客预约出行信息；

分析模块，用于对所述乘客预约出行信息进行分析，确认是否预约成功并反馈给所述乘客；

制定模块，用于根据预设时间内预约成功的乘客预约出行信息，制定列车运行图。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的系统的具体工作过程，可以参考前述一种基于预约出行的行车组织方案制定方法实施例中的对应过程，在此不再赘述。

本申请实施例还提出了一种设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述的一种基于预约出行的行车组织方案制定方法。

此外，本申请实施例还提出了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述的一种基于预约出行的行车组织方案制定方法。

图5示出了可以用来实施本公开的实施例的电子设备500的示意性框图。如图所示，设备500包括中央处理单元(cpu)501，其可以根据存储在只读存储器(rom)502中的计算机程序指令或者从存储单元508加载到随机访问存储器(ram)503中的计算机程序指令，来执行各种适当的动作和处理。在ram503中，还可以存储设备500操作所需的各种程序和数据。cpu501、rom502以及ram503通过总线504彼此相连。输入/输出(i/o)接口505也连接至总线504。

设备500中的多个部件连接至i/o接口505，包括：输入单元506，例如键盘、鼠标等；输出单元507，例如各种类型的显示器、扬声器等；存储单元508，例如磁盘、光盘等；以及通信单元509，例如网卡、调制解调器、无线通信收发机等。通信单元509允许设备500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理单元501执行上文所描述的各个方法和处理。例如，在一些实施例中，方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元508。在一些实施例中，计算机程序的部分或者全部可以经由rom502和/或通信单元509而被载入和/或安装到设备500上。当计算机程序加载到ram503并由cpu501执行时，可以执行上文描述的方法的一个或多个步骤。备选地，在其他实施例中，cpu501可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。