0 引言
随着轨道交通在公共交通客运总量占比逐年提升,乘客对准点的要求日益提升,在故障发生后,影响区段往往具有列车满载率高、站台拥挤度高等特点,然而,在应急行车指挥中,通常以降低列车延误为目标,导致只有未清客列车上的乘客较为准点,而未上车及清客列车上的乘客需要很长等待时间才能搭乘列车,进而造成了乘客整体出行体验较差。国内外城市轨道交通绩效评价体系主要有国际地铁协会创立的CoMET(Community of Metros)和中国交通运输协会城市轨道专业委员会创立的MOPES(Metro Operational Performance Evaluation System),2套评价体系关于服务可靠度的指标均以列车为主体,缺乏以乘客延误为主体的评价指标。
在应急故障中,乘客延误可以用乘客累计延误时间表示,即所有受影响的乘客旅行时间增晚之和。目前,与乘客延误相关的研究主要集中在非应急情况,缺乏应急情况下的乘客延误研究。张建华等
[1]通过回归算法计算出了正常情况下的乘客平均延误时间;陈明明
[2]通过优化乘务调度减少了城市公共交通的乘客延误。而应急行车组织评估方面主要从列车调整、路径选择、拥挤度传播、乘客容忍度等方面进行研究,缺乏乘客延误方面的研究。 孙妍等
[3]构建了考虑乘客有限理性及选择偏好异质性的路径选择模型;常在斌等
[4]、曾翠峰等
[5]、谢辉
[6]分别从广义费用、拥挤度传播和可达性方面建立了乘客路径选择模型;徐文恺
[7]介绍了突发情况下网络列车调整模型;王璐瑶等
[8]介绍了不同乘客特性对路径选择的影响;Raveau等
[9]通过从时间、换乘等不同方面分析了乘客对于地铁线路的选择行为;王镇波等
[10]介绍了乘客对不同列车延误的容忍度;王恺等
[11]分析了地铁延误对社会经济的损失;王雪鑫
[12]介绍了地铁突发情况下的行车调整方法;马思斯
[13]介绍了延误情况下乘客的心理反应;唐雨昕等
[14]介绍了延误情况下乘客的路径选择;王璞等
[15]分析了高速铁路突发情况下的延误传播。由于缺乏应急情况下的乘客延误评价模型,如需计算只能人工根据故障列车所在时刻的断面数据和行车间隔推算出列车人数,再结合预计动车时间粗略估算出乘客延误情况,人工计算工作量大、时效性差且难以分析故障点对其他区域的影响,难以应用到故障行车指挥中。
针对既有城市轨道交通应急行车组织研究中缺乏乘客延误维度,引入乘客累计延误时间作为应急情况下的评价指标,针对人工计算乘客累计延误时间的不足,构建相关计算模型。因此,构建乘客累计延误时间模型对于完善指标评价体系、评估延误影响、提高应急服务水平等,均具有非常重要的理论意义与实际意义。
1 评价模型
评价乘客累计延误时间,首先应从客流出发,从线网客流中筛选出与故障线路相关的客流。然后结合线路的站点设置、区间构成及配线布置等线路信息,确定应急情况对线路的影响,进而确定应急情况下的行车方案。最后,通过模拟列车在线路上的运行来避免人工计算的不足。因此,模型由客流筛选模型、线路元素模型和列车运行模型3个组成部分构成。
1.1 客流筛选模型
乘客累计延误时间计算可以分为历史复盘和实时评估2种类型。历史复盘采用故障当天OD数据,实时评估使用OD模板(数据库),根据乘客出行规律将OD模板分为周一、周二三四、周五、周六、周日、节假日前1天、节假日第1天、节假日期间和节假日最后1天9种,非节假日模板取最近1个月数据的平均值,节假日模板取最近1年数据的平均值。
以线网客流数据计算乘客累计延误时间需要通过清分模型,清分模型大约需要1~2 h的时间才能完成客流清算,难以满足实时性的要求。为提高计算速度,模型在线网客流中筛选出与故障线路相关的客流数据,即将线网客流分时OD数据转换到相应故障线路上。
假设乘客在
t0 时刻进站,A站至B站的时间为
t1,B站至C站的时间为
t2,C站至D站的时间为
t3,客流可归为以下5类,客流转换模型如
图1所示。
(1)乘客起终点均不在故障线路上,且不经过故障线路。该项客流数据不计入线路OD数据。
(2)乘客起终点均在故障线路上,该情况无需映射。
(3)乘客起点在故障线路上,终点不在故障线路上。假设乘客从B站进站,需要前往D站,C站为故障线路上途经的换乘站。
(4)乘客起点不在故障线路上,终点在故障线路上。
(5)乘客起终点均不在故障线路上,且经过故障线路。假设乘客从A站进站,需要前往D站,B站和C站为故障线路上途经的2个换乘站。
1.2 线路元素模型
线路元素可分为站台元素和非站台元素,假设线路共有n个元素,则线路可以用集合表示,其中线路元素可以表示为
式中:表示元素能够容纳的最大列车数,列;表示需要前往其他各个元素乘客的数量,人,;mVi 表示需要前往其他各个元素乘客的到达速度,人/s,;mti 表示图定停站时间,s;mfi 表示通过能力降低附加时间,s;mli 表示元素类型,可取值范围为{0,1},mli =0表示该元素为站台元素,mli =1表示该元素为非站台元素。
1.3 列车运行模型
列车集合分为,D表示待发列车集合,X表示线上列车集合,A表示到达列车集合。
1.3.1 待发列车集合
假设待发列车中共有nd个发车地点,则待发列车集合可以表示为
式中:di 表示第i个发车地点,。
dji 表示该发车地点最小发车间隔,s,当折返点正常时dji 为列车最小折返时间,当折返点有故障需要人工办理折返时,dji 为人工办理折返的时间;dsi 表示该发车地点待发列车数量,列;dTi 表示该发车地点待发列车集合,。当发车地点di 发车间隔到达dji 时,判断dTi 集合中第一列车是否满足发车条件,如果满足发车条件,则将该列车加入到线上列车集合中,同时将该列车从发车集合中剔除,如果不满足发车条件,则继续等待。
1.3.2 线上列车集合
假设线上列车数量为nx,则线上列车集合,xi 表示线上第i列列车。列车运行过程,可以视为列车按照时刻表依次占用各个线路元素,站台元素占用时间为停站时间,区间元素占用时间为区间运行时间。当列车实际占用某一地图元素的时间不低于计划占用时间,即某一线路元素剩余占用时间为0时,按照时刻表占用下一个地图元素,同时取消该线路元素的占用。列车已经经过的线路元素剩余占用时间为0,正在占用的线路元素剩余占用时间为计划时间减去已经占用的时间,未经过的线路元素剩余占用时间为计划时间,因此列车运行可以表示为线路元素剩余占用时间集合。
假设第i列列车计划交路中需要依次占用xis 个元素,则
式中:xAi,j 表示列车i在计划交路j的行车组织方案,,xli,j,xti,j,zxi,j 分别表示列车i的计划交路j需要占用的线路元素,剩余占用时间和行车调整方式。xzi,j 取值范围为{0,1,2,3},其中0表示正常、1表示越站、2表示清客、3表示清客退出。
列车xi 需要前往各个元素的乘客数为xPi,则,xpi,j 表示列车i需要前往地图元素j的乘客人数,列车到站时按照先下后上的原则计算,当列车人数达到设定上限时不再允许乘客上车。
根据行车组织特点结合列车数据结构将行车组织方式分为以下几类。
(1)更改计划运行时间:多停(含扣车)。多停即让列车在站台增加停站时间;扣车即将列车扣停在站台,待前方列车满足动车条件并开出后再将列车放行。假设列车i在线路元素j多停k秒,则。
(2)列车退出服务:退车(含抽线)。退车即列车在某一站退出服务;抽线即在起点站取消开行计划。假设列车i在线路元素j退车产生清客时间k秒,则。
(3)列车加开:加开(含小交路)。加开为在起点站增加开行1列载客列车;小交路相当于在中间站加开列车。假设列车i在地图元素j加开列车则在加开列车集合中增加相应列车信息,列车占用各个元素的时间按照图定停站/区间运行时间计算。
(4)越站,即列车不停站通过。列车i在线路元素j越站,则。
1.3.3 到达列车集合
到达列车集合用以记录各次列车在各个区间的乘客人数、满载率及实际时刻表数据用于后续数据分析。
2 模型求解
模型采用仿真的方式进行求解,分为列车运行、列车上下客和站台客流增长3个部分,按步长1 s进行计算。
2.1 列车运行
列车集合X按照列车运行方向的反方向排序,即列车xi-1 在列车xi 的前方,因此在列车运行过程中需要满足以下约束条件。
(1)当后方列车xi 与前方列车xi-1同时占用1个线路元素,即xli,j=xli-1,k 时,保证2车间隔大于最小行车间隔,即ti,j>ti-1,k+tmin (tmin 表示列车最小行车间隔)。
(2)当前方列车xi-1 占用线路元素j、后方列车xi 占用线路元素j-1,且线路元素j-1容纳的列车数等于mnj-1时:xti,j-1>tmin。
模型将列车运行视为列车占用线路元素剩余时间的减少,列车运行按照以下步骤计算。
步骤1:对于任意列车判断是否满足上述约束条件,如果满足则执行步骤2,否则执行步骤3。
步骤2:令,执行步骤4。
步骤3:令,执行步骤4。
步骤4:如果等于0,令j=j+1。
步骤5:如果xi 在某一元素占用时间超过计划占用时间时,乘客累计延误时间增加。
2.2 站台客流增长
站台前往其他各站的候乘乘客按照折算后的OD数据进行累加,当列车需要在站台清客时,将需要前往该站之后站点的乘客数量进行累加,假设表示列车i上的乘客数量,正常情况下站台i人数为Zi,故障情况下站台i人数为Gi,Floor表示向下取整,则站台客流增长按照以下步骤进行计算。
步骤1:列车是否在站台清客,如果不清客则执行步骤2,清客则执行步骤3。
步骤2:令msi,j=Floor(mvi,j ×列车间隔),执行步骤4。
步骤3:令msi,j=Floor(mvi,j ×列车间隔)+,执行步骤4。
步骤4:如果Gi -Zi >0,则累加乘客累计延误时间Gi -Zi。
2.3 列车上下客
引入列车上下客速度分别为v1,v2,单位为人/s,根据先下后上的原则,当列车i到达站台元素j时,先执行下客运算,当需要下车的乘客全部下车时,执行上车运算,当站台人数大于列车能够容纳的人数时,按照先到的乘客优先上车的原则进行计算,假设其中列车i在j站需下车乘客为xpi,j,则列车上下客可以按照以下步骤计算。
步骤1:如果列车停站且未下客完毕,则执行步骤2,如果列车停站且下客完毕,则执行步骤3,如果列车不停站则执行步骤4。
步骤2:当xpi,j >0时,xpi,j=xpi,j-min(v2,xpi,j ),执行步骤3。
步骤3:当<pmax时,xpi,k =xpi,k +min(pmax-,v1,msi,k ),k∈[j+1,n] 。
步骤4:乘客选择前一站下车的概率为p=ti,j -1/(ti,j-1+ti,j+1),选择后一站下车的概率为1-p。
2.4 模型计算流程
乘客累计延误时间计算模型具体步骤如下。
步骤0:读取通过客流筛选模型转换后的线网OD数据、故障当天时刻表数据。
步骤1:读取线路车站及区间数据,根据线路模型生成线路元素信息。
步骤2:根据时刻表中列车的发车时间,初始化待发列车矩阵。
步骤3:从线路运营开始时起,按照客流模型及列车模型对场景进行仿真计算,仿真至延误发生时止,记为场景A0。
步骤4:通过复制场景A0中的所有信息,生成正常场景A1。
步骤5:通过复制场景A0中的所有信息,再结合列车及线路元素故障类型、故障影响、行车调整方式生成延误场景A2。
步骤6:按照客流模型分别对A1及A2场景进行乘客人数累加运算和上下客运算,计算步长为1 s。
步骤7:按照列车模型分别对A1及A2场景进行列车运行运算,计算步长为1 s。
步骤8:对比2个场景,如果A1及A2场景所有站台人数均相等,且A2场景行车组织措施执行完毕,即在故障处理完毕、设备恢复正常、行车组织执行完毕、故障情况下所有站台滞留乘客均疏散完毕时,执行步骤9,否则执行步骤6。
步骤9:输出乘客累计延误时间、各站乘客累计延误时间和站台各时刻乘客人数等指标,计算结束。
3 系统设计
为了使模型更好地应用于实际应急处置中,在上述模型的基础上开发了相应的计算系统。系统以高效计算、操作便捷和高度可扩展为目标。为了方便用户输入,系统对故障和行车组织对乘客的影响进行了总结和量化,并以图形和表格的形式输出评价指标,以便用户进行统计和分析。
3.1 系统架构
系统采用了分布性强、兼容性好、维护便捷的B/S模式(浏览器/服务器模式)。使用了C#,JavaScript,HTML等编程语言,在VS2010平台上基于.Net Framework 4进行开发。数据存储方面,系统使用了SQL Server 2008数据库。
系统分为基础数据管理、行车方案编辑与计算结果展示3个模块,基础数据管理模块用于存储客流筛选模型和线路元素模型所需数据,行车方案编辑模块为线路元素模型及列车运行模型输入行车方案及故障影响,计算结果展示模块为用户展示计算方案。首先系统管理员对基础数据管理中的线路、车站、时刻表及客流模板数据进行维护,然后用户通过行车方案编辑模块录入行车调整及故障情况,最后通过计算结果展示模块对行车方案进行评价。系统架构如
图3所示。
3.2 基础数据管理
基础数据管理模型用于管理线路、车站、客流模板及时刻表基础数据。其中:线路数据用于存储线网中所有的线路名称;车站数据用于存储车站及所属线路,每条线路中所有车站均按照从下行至上行的顺序进行存储;客流模板用于存储各个线路的客流情况,系统在线网客流数据的基础上根据3.1的模型计算各条线路的客流数据,并以文件的形式进行存储;时刻表数据用于存储每条线路常用的时刻表信息与时刻表对应的客流模板信息。
3.3 行车方案编辑
行车方案编辑分为故障情况编辑和行车组织编辑2个部分。
3.3.1 故障情况编辑
城市轨道交通故障种类繁多,可以分为车辆故障和线路设备故障2种类型。在故障处置阶段这2种故障均表现为行车中断,行车中断时间为故障处理时间。当故障处置完毕可以动车时,车辆故障表现为旅行速度的降低,线路设备故障表现为通过能力的降低,这2种降低情况可以用百分比来表示。故障分类及所需输入数据如
表1所示。
3.3.2 行车组织编辑
在故障发生后,行车调整是保障乘客服务水平的重要方式,根据调整对象不同行车组织可以分为:对列车的调整和对车站的调整。对列车的调整包括:加开列车、增加停站时间、不停站通过、清客、退出服务、投入运营等措施。对车站的调整包括:小交路和调整发车间隔。行车方案分类及所需输入数据如
表2所示。
3.4 计算结果
计算结果以图形和表格2种形式展示。站台乘客数量曲线图如
图4所示,红色线表示正常情况下的站台乘客数量,蓝色线表示故障情况下的站台乘客数量。各站乘客累计延误时间图如
图5所示,展示了乘客累计延误总时间、各站乘客的累计延误时间、最大候乘时间和最大站台人数。
4 实例分析
为了评价模型的效果,以1条虚拟线路为例,对模型计算效果以及手工计算与模型计算之间的差异进行了分析。
4.1 事件概况
假设某线有16座车站,车站名称由下行至上行分别为A站、B站、……、P站,早高峰期间行车间隔为3 min且上行满载率大于下行满载率。某日上午出现列车故障,线路及列车位置图如
图6所示,故障事件时间节点表如
表3所示。
4.2 行车方案
在该事件背景下,有以下4种行车方案,行车方案及乘客累计延误时间如
表4所示。
从
表4中可以看出,人工计算结果与系统计算结果存在较大差异,原因如下。
(1)人工计算仅能根据当前故障列车人数与预计延误时间对乘客累计延误时间进行估算,但无法推算故障点对后续列车的影响以及行车调整对乘客的影响。也就是说,人工计算只能评估故障列车对乘客的影响,而无法推演故障恢复阶段对乘客的影响。因此,人工计算结果与系统计算结果在数值上存在较大差异。
(2)由于实时站台人数需要根据OD数据和列车容纳人数从运营开始进行推算,计算量很大人工计算难以胜任,导致人工计算无法推演站台乘客延误时间,因此人工计算无法确定空车在哪个站投入更合理,即无法确定方案1和方案2、方案3和方案4哪个方案更优。
因此采用系统计算乘客累计延误时间有以下几方面的优势:①可以推演故障后续列车运行状态;②可以推演车站站台人数;③可以精细分析不同行车方案的优劣以及方案之间的差异。
从系统计算结果可知,方案3优于其他方案。当然,这个决策仅从乘客累计延误时间因素考虑,实际执行还需考虑后方站容纳能力导致的安全风险、后方换乘站因素,换乘机场、火车站等对时间受损低容忍度乘客因素。
4.3 系统应用
目前,该系统已在广州地铁一号线、二号线、八号线投入应用,投入应用的线路图如
图7所示,采用绿色标记。系统平均计算时间为2 s,平均场景编辑时间为20 s,能够满足应急情况对系统实时性的要求,具有推广价值。系统已累计节省乘客累计延误时间超过200万人·min,按照2022年广州人均GDP15.3万元计算,系统累计产生经济效益58.2万元。
5 结论
研究建立了城市轨道交通应急情况下的乘客累计延误时间模型并研发了相关计算系统,解决了人工计算量大、精度低、耗时长等缺陷,同时系统还具有快速计算、实时决策等优势,为应急情况下的行车组织提供了一定的数据支持。
为进一步辅助应急情况下的行车组织,应从以下2个方面进行进一步研究。
(1)应急评价指标:模型可以输出乘客累计延误时间作为评价指标,但应急行车组织需要从多个维度进行评估,包括影响乘客人数、延误列车数、最大中间列车晚点、最大终点列车晚点、最大行车间隔增晚等。因此,系统应进一步建立应急行车组织评价体系,以更全面的方式评估应急行车组织。
(2)应急故障模板:地铁运营企业针对不同故障均有明确的应急预案。为进一步提高系统的实时性和实用性,系统应进一步完善故障模板功能,允许用户编辑常见故障的影响及相应的行车组织方案。这将有助于更好地应对不同类型的故障,提高系统的应急响应能力。