CN113779741A - 轨道交通系统业务演化模型建模方法 - Google Patents

Abstract

本发明提供一种轨道交通系统业务演化模型建模方法，其包括以下步骤，步骤一：确定轨道交通系统网络信息；步骤二：轨道交通系统演化对象建模；步骤三：轨道交通系统业务演化条件建模；步骤四：轨道交通系统业务演化规则建模；步骤五：轨道交通系统业务故障评估。本发明通过分别对轨道交通系统演化对象、业务演化条件、业务演化规则建模，能够支持对轨道交通系统业务的描述和模型的构建，并可以对轨道交通业务演化仿真数据进行深入分析，从而帮助轨道交通运营公司和研究人员探究轨道交通系统业务运行规律，完成轨道交通业务故障评估。

Description

轨道交通系统业务演化模型建模方法

技术领域

本申请涉及可靠性及安全系统工程领域，具体地涉及一种轨道交通系统业务演化模型建模方法。

背景技术

随着科技的发展，轨道交通系统运输业务从单一链路发展为耦合多链路来满足乘客的复杂出行需求，保证运输业务的高可靠运营是轨道交通运营公司运维管理的目标。业务可靠性研究的核心是业务故障，对于轨道交通系统而言，乘客及轨道交通运营公司最关注的是由于拥塞引发的业务故障，即拥塞导致运输业务无法满足乘客群体准时到达目的节点的出行需求，如何在耦合多业务运行下对轨道交通业务进行建模描述，是分析轨道交通系统业务运行规律、保障轨道交通系统可靠运营的关键技术手段，其可以为轨道交通业务的运维分析提供理论支持。

当前对于复杂系统的建模方法，如排队论模型、信息传播动力学模型、级联失效模型等，其主要关注以构件为基础的网络系统物理层的建模，将业务以简单的流量形式建模于其上，通过流量在构件上的转移描述网络的演化，忽略了更为复杂的业务层面属性特征，如业务流程、业务容量、业务运行间隔等，而业务的设计因素及多业务间的耦合关系是影响轨道交通业务演化的重要因素，如何对轨道交通系统业务的演化过程进行描述和建模是研究轨道交通系统业务故障机理的基础，其可以进一步支持对轨道交通系统业务故障的分析与预测。

因此，需要提供一种轨道交通系统业务演化模型建模方法，解决现有技术存在的问题。

发明内容

为了克服现有技术的不足，本发明的目的是提出一种轨道交通系统业务演化模型建模方法，其首先对于演化对象的建模上既考虑了物理层构件，也考虑了业务层设计因素，基于此对演化条件、演化规则进行了描述，并提出了业务平均留乘时长来对轨道交通系统业务运行状态进行评估，其能够对多业务运行下的轨道交通系统演化进行建模，具有工程上的实际意义。

为实现上述目的，本发明所采用的解决方案为：

一种轨道交通系统业务演化模型建模方法，其包括以下步骤：

步骤1：获取待建模轨道交通系统的网络初始信息，所述网络初始信息包括网络拓扑信息和业务信息；

步骤2：轨道交通系统演化对象建模，所述演化对象建模包括物理层对象建模和业务层对象建模，所述物理层对象建模具体为：

所述待建模轨道交通系统是由物理层和业务层组成的双层网络，所述物理层由网络拓扑组成，所述网络拓扑表示为G(V,E)，其中V是轨道交通系统中的所有节点的集合，V＝{v₁,v₂,…,v_n}，v_n为第n个节点；E是轨道交通系统中节点间所有链路的集合，E＝{e₁,e₂,…,e_m}，e_m为第m个链路；

所述业务层对象建模具体为：业务层以物理层为基础，业务层由业务的源宿节点、业务路径、业务容量、业务负载、业务执行频次、业务执行速度、业务执行位置和业务执行数组成，其中业务容量用数组C_i＝{C₁,C₂,…,C_M}表示，M为某一时刻链路上的业务数量，C_i为第i个业务的业务容量；其中业务负载用数组L_i＝{L₁,L₂,…,L_M}表示，L_i为第i个业务的业务负载；其中业务执行位置用Z_i＝{x₁,x₂,…,x_M}表示，Z_i为第i个业务的业务执行位置；

步骤3：轨道交通系统演化条件建模，所述演化条件建模包括客流加载设计和节点状态变化设计；

步骤4：轨道交通系统演化规则建模，所述演化规则建模包括客流加载条件下的业务演化规则建模和节点状态变化条件下的业务演化规则建模，所述客流加载条件下的业务演化规则包括客流加载条件下的业务内运行方法和客流加载条件下的业务间运行方法；所述节点状态变化条件下的业务演化规则包括节点状态变化条件为节点故障发生下的业务演化规则和节点状态变化条件为节点故障恢复下的业务演化规则；

4a、客流加载条件下的业务内运行方法具体包括以下步骤：

步骤4a.1：按照业务执行位置Z_i及业务执行数更新方法进行业务执行位置更新；

步骤4a.2：将所述步骤4a.1更新后的业务执行位置与业务的所有节点V的位置对比，将所述业务的所有节点V的位置中与更新后的业务执行位置相同的节点作为业务的客流运输作用节点；

步骤4a.3：对所述步骤4a.2获得的业务的客流运输作用节点执行客流的上车方法和客流的下车方法；

4b、客流加载条件下的业务间运行方法具体包括以下步骤：

步骤4b.1：按照所述4a中客流加载条件下的业务内运行方法进行业务的作用节点判断，获得业务的客流运输作用节点；

步骤4b.2：判断业务的作用节点的类型，如果所述业务的作用节点是中间站，则进入步骤4b.3，如果所述业务的作用节点是换乘站，则进入步骤4b.4；

步骤4b.3：执行业务的中间站客流的换乘方法；

步骤4b.4：执行业务的换乘站客流的换乘方法；

4c、节点状态变化条件为节点故障发生下的业务演化规则具体包括以下步骤：

步骤4c.1：更新业务层信息，业务执行位置Z_i直接跳过故障节点，物理层信息不变；

步骤4c.2：在所述故障节点上执行业务客流的疏散方法；

步骤4c.3：在非故障节点上执行客流加载条件下的业务演化规则；

4d、节点状态变化条件为节点故障恢复下的业务演化规则具体包括以下步骤：

步骤4d.1：更新业务层信息，业务执行位置Z_i恢复考虑故障节点，物理层信息不变；

步骤4d.2：执行客流加载条件下的业务演化规则；

步骤5：确定业务故障评估指标，对轨道交通系统业务故障进行分析与评估。

可优选的是，所述步骤4中业务执行位置Z_i及业务执行数更新方法具体为：令业务执行速度为S，根据所述业务执行速度S和时间步获得业务执行对应的节点编号信息，更新业务执行位置；根据所述更新后的业务执行位置更新业务执行数，具体为：如果当前最晚加载进来的业务的业务执行位置

则在第一个节点新增所述业务，否则不新增所述业务；如果当前最早加载进来的业务的业务执行位置

总长度，则移除所述业务，否则不移除所述业务，M为某一时刻链路上的业务数量；

所述客流的上车方法具体为：上车业务请求从节点中移除并加载到业务上，所述上车业务请求的数值为实时节点负载的β％，且在车厢剩余容量以内；β％为上车概率；

所述客流的下车方法具体为：下车业务请求从业务中移除，所述下车业务请求的数值为业务负载的α％，α％为下车概率。

进一步，所述步骤4中业务的中间站客流的换乘方法具体为中间站业务请求从业务中移除γ％，且γ％<1-α％，并将中间站业务请求转发到同一节点的反方向业务上，γ％为换乘概率；

所述业务的换乘站客流的换乘方法具体为换乘站业务请求从业务中移除γ％，且γ％<1-α％，其中γ1％的换乘站业务请求平均转发到换乘链路的两个方向的业务上，γ2％的换乘站业务请求转发到同一节点的反方向业务上，γ＝γ1+γ2，γ1％为换乘其他业务的概率；γ2％为换乘反向业务的概率。

可优选的是，所述步骤4中业务客流的疏散方法具体为疏散等待在故障节点a的乘客，所述乘客包括节点故障发生时刻t的等待人数和原本要使用所述故障节点a的乘客，所述疏散包括客流移除和客流转移，所述客流移除为移除k％的客流

所述客流转移按照强业务路径耦合的客流转移变化，具体为剩余客流(1-k％)转移到非故障节点上，所述强业务路径耦合的客流转移变化为客流向同一业务路径上的上下游节点进行转移。

可优选的是，所述步骤5中业务故障评估指标

为：

式中：App_i为第i个业务；

为t时刻业务App_i的留乘率；

为t时刻能够登乘业务App_i的乘客人数；

为业务App_i等待服务的乘客的总数，所述乘客的总数包括进站人数和等待人数。

可优选的是，所述步骤1确定待建模轨道交通系统的网络初始信息，所述网络拓扑信息是由网络拓扑和网络资源组成；所述业务信息包括业务起始节点、业务目的节点、业务流程、业务起始时间、业务运行间隔时间和业务容量。

可优选的是，所述步骤2的节点v_n的数据结构包括：节点名称、节点编号、节点状态、节点邻接关系、节点等待人数、节点换乘人数和节点出站人数；所述链路e_m的数据结构包括：链路名称、链路编号、链路源节点、链路宿节点、链路长度。

可优选的是，所述步骤3中客流加载设计为设计任意时刻某一节点客流的加载量分布，所述加载量分布包括正态分布、指数分布和均匀分布；所述节点状态变化设计为采用等价类划分的方法，按照强弱调控耦合对多节点故障模式进行分类，所述强弱调控耦合包括全网分散、局部集中，强弱业务路径耦合和强弱资源竞争耦合。

与现有技术相比，本发明的有益效果在于：

本发明从业务故障机理角度出发，对轨道交通业务及耦合关系进行分析，进一步明确轨道交通系统业务演化的演化对象、演化规则、演化条件的建模。能够支持对轨道交通系统业务的描述与建模，能获取轨道交通业务的仿真数据，对轨道交通系统业务进行深入分析，解决了已有复杂系统建模方法难以对轨道交通系统业务的动态运行进行建模这一问题，从而帮助轨道交通运营公司和研究人员探究轨道交通系统业务运行规律。

附图说明

图1为本发明实施例的轨道交通系统业务演化模型建模方法流程框图；

图2为本发明实施例的多节点故障模式的等价类划分图；

图3为本发明实施例的封站时业务的客流转移规则的分类图；

图4为本发明实施例中成都地铁线网图；

图5为发明本实施例中多节点故障模式下的地铁1业务状态变化图。

具体实施方式

以下，参照附图对本发明的实施方式进行说明。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

本发明实施例提供了一种轨道交通系统业务演化模型建模方法，如图1所示，本发明可以支持对动态运行业务的描述与建模，为轨道交通系统业务监测与分析提供理论支持，以下为一个成都地铁系统的实例，如图4是2019年9月的成都地铁线网图。

首先根据系统运营商需求，确定地铁系统信息。所需要确定的初始地铁系统网络信息包括：网络拓扑信息、地铁业务信息、以及工程应用时所需的其他信息，其中，网络拓扑信息包括：网络拓扑及网络资源,例如节点数即站点数、链路数目即路段数目。地铁运输业务信息包括：地铁业务起始节点、地铁业务目的节点、地铁业务流程、地铁业务起始时间、地铁业务运行间隔时间、地铁业务容量。

明确了工程应用时所要设计的网络信息，包括拓扑信息、业务信息以及工程应用时所需的其他信息。接下来需要明确怎样建立地铁系统业务演化对象、演化条件、演化规则，以及如何评估地铁业务的运行状态，具体包含如下步骤：

步骤1：轨道交通系统演化对象建模；

依据成都地铁的实际拓扑结构和运营信息等进行演化对象建模，如图4是2019年9月的成都地铁线网图。

从线网图中可以获取链路、节点的信息，包括链路数、节点总数、换乘站数等，然后设计业务的物理层、业务层对象。

步骤11：物理层对象建模；

将地铁系统的物理层对象抽象为一个由地铁系统节点及连接节点间的链路所组成的网络拓扑，用无向图来表示G(V,E)。其中V是地铁系统中的所有节点的集合，V＝{v₁,v₂,…,v_n}，v_n为第n个节点。E是地铁系统中节点间所有链路的集合，E＝{e₁,e₂,…,e_m}，e_m为第m个链路。

节点、链路的属性信息如表1、表2所示。

表1节点的数据结构

表2链路的数据结构

属性	描述
		链路名称	路段的名称，用link表示
链路ID	链路编号，链路的唯一标识，用数字表示
		链路源节点	起始节点名称及编号
链路宿节点	终止节点名称及编号
		链路长度	路段的长度

本案例中，物理层对象组成的网络拓扑即为成都地铁拓扑，成都地铁共6条业务链路，本专利将6条线所有节点都进行唯一编号，得到如下的6个表格。

表3成都地铁1号线

表4成都地铁2号线

表5成都地铁3号线

表6成都地铁4号线

表7成都地铁7号线

表8成都地铁10号线

79	142	143	144	145	146
						太平园	簇锦	华兴	金花	双流机场1航站楼	双流机场2航站楼

上述6个表格已给出物理层对象包括节点和链路的绝大部分信息，包括146个节点、155条链路，146个节点中有13个换乘节点，并设置所有链路长度l＝1。

步骤12：业务层对象建模，业务层以物理层为基础，业务层对象属性的具体描述如下：

①业务的源宿节点，业务在链路上运行有始发站和终止站，因此链路级子业务有其流程的起始和终止；

②业务路径，业务在链路上运行是按照固定的路径行驶的，按顺序经过链路上的所有节点，因此链路级子业务的执行按其流程进行；

③业务容量，某时刻业务路径上的业务定员信息C，用一个数组C_i＝{C₁,C₂,…,C_M}表示，C_i为第i个业务的业务容量；同一链路上的业务型号一样，因此业务定员C₁＝C₂＝…＝C_M，M为该时刻链路上的业务数量；

④业务负载，某时刻业务路径上的所有业务内的客流数，用一个数组L_i＝{L₁,L₂,…,L_M}表示，L_i为第i个业务的业务负载。

⑤业务执行频次，即发车间隔，业务的执行具体是通过一个业务对乘客的运输实现的，比如轨道交通系统运营公司按照时刻表和轨道交通系统的实时客流情况设定发车间隔；

⑥业务执行速度，即业务行驶速度，也即列车在链路上的运行速度S，即需要花费多少个时间步才从一个节点走到下一个节点；

⑦业务执行位置，即业务实时位置Z_i＝{x₁,x₂,…,x_M}，Z_i为第i个业务的业务执行位置；业务位置在链路上的节点上也可能在链路中。

⑧业务执行数，即在一个链路级业务上实时的业务总数。

本案例中，每条地铁业务链路往返都可以看作是独立的链路，因此成都地铁业务中共6条链路，两个方向共12个业务，如表9所示。

表9成都地铁链路业务信息

业务	链路	方向	业务	链路	方向
						1	Line_1	韦家碾-五根松	7	Line_1	五根松-韦家碾
2	Line_2	犀浦-龙泉驿	8	Line_2	龙泉驿-犀浦
						3	Line_3	成都医学院-双流西站	9	Line_3	双流西站-成都医学院
4	Line_4	西河站-万盛站	10	Line_4	万盛站-西河站
						5	Line_7	崔家店站-双店路站-崔家店站	11	Line_7	崔家店站-理工大学站-崔家店站
6	Line_10	太平园-双流机场2航站楼	12	Line_10	双流机场2航站楼-太平园

从以上的业务信息中可获取仿真中业务层对象相关的业务源宿节点、业务路径、业务耦合节点，仿真需要的业务层对象信息还有：①业务执行容量：同一链路上的业务型号一样，仿真中设置所有链路业务定员，即最大容量C＝40；②业务执行频次：固定不变T＝2，即每两个时间步发一次车；③业务执行速度：固定不变S＝0.5，即每2个时间步改变一次业务执行的节点ID信息。

步骤2：轨道交通系统演化条件建模

步骤21：客流加载设计

简化客流加载的设计，认为某一节点客流的加载量一直服从同一分布，如正态分布、指数分布、均匀分布。由于正态分布的要求过分严苛，仿真中很难将所有节点的客流情况分析清楚，指数分布只适用于平峰和高峰时期，在两个时期的中间时段、地铁在一天中刚运营和邻近结束的时段都不适用。因此为提高本专利研究的普适性，在案例中所有节点的客流加载量始终服从(0，R)的均匀分布，R＝40。

步骤22：节点状态变化设计

采用等价类划分的方法，按照全网分散、局部集中，强弱业务路径耦合，强弱资源竞争耦合，强弱调控耦合对多节点故障模式进行分类，如图2所示，在考虑全网分散、局部集中，强弱业务路径耦合，强弱资源竞争耦合这4个因素下所有的等价分类数：与全网分散故障相关的有a1d1和a1d2共2类；与局部集中故障相关的有a2b1c1d1、a2b1c1d2等共2*2*2＝8类，一共10类。

在仿真第60个时间步封站，在第90个时间步节点故障修复，恢复运行。此外，还需明确节点故障个数问题。考虑到换乘节点客流量大，节点物理设备的使用频率高，易发生节点故障，因此本专利采用蓄意使几个换乘站立即封站的方式，具体来说，在案例中采用的多节点故障模式是局部的、同一业务上的、不是紧密相连的几个换乘节点，即局部集中、强业务路径耦合、弱资源竞争耦合、强调控耦合的几个节点，即a2b1c2d1。

为找到合适的故障节点数，本发明根据实际的仿真结果来评价，图5分别是同时使2、3个节点故障的业务状态变化情况。

图5中粗线条是同时使2个节点故障的1业务平均留乘时长随时间的变化，细线条是同时使3个节点故障的1业务平均留乘时长随时间的变化，可以看出，若假定平均留乘时长超过1.5为业务故障，则在此多节点故障模式下同时使2或3个节点故障都导致了业务故障的发生。只是3个节点故障的状态变化速度比较快，从60个时间步业务演化条件改变开始，在70个时间步左右就已经发生业务故障，业务在较短时间内迅速故障，难以收集到充足的相关参数数据以支持后面的标志物识别和业务故障预测；而2个节点故障下在80个时间步左右发生业务故障，状态变化相对较缓慢，可收集的相关参数数据相对充足。因此，选择在本案例多节点故障模式下同时使2个节点故障来研究业务故障比较合适，具体故障模式是：针对成都地铁1号线下行方向，即1业务，选择使1业务上编号为6、10的节点，即骡马市站和省体育馆站封站。

步骤3：轨道交通系统演化规则建模

步骤31：首先确定客流加载条件下的业务演化规则或演化方法，包括业务内运行方法和业务间运行方法，其中业务内运行方法包括以下三部分：

1)业务执行位置更新，按照如下方法1.1进行；

方法1.1：业务执行位置及业务执行数更新方法

业务执行位置更新：设业务执行速度固定为S，则业务执行对应的节点ID信息每个时间步的改变量为S。

业务执行数更新：依据业务执行位置调整变化，业务有移动、新增和移除，具体考虑当前链路上的最早出发的业务和最晚出发的业务，即：

如果当前最晚出发的业务的位置

则在第一个节点新增业务，否则，暂不新增。

如果当前最早出发的业务的位置

总长度，则移除该业务，否则，暂不移除。

根据上述两个判断计算此时的业务执行数。

业务的耦合关系可以指导客流加载条件下的业务内运行方法中的客流的上车和下车方法设计。

2)将业务执行位置与业务的所有节点位置对比，相吻合的节点即业务的客流运输作用节点；

3)业务的作用节点执行客流的上车和下车方法，客流的上车方法见方法1.2，客流的下车方法见方法1.3。

方法1.2：客流的上车方法；

业务请求从节点中移除并加载到业务上，数值为实时节点负载的β％，且要求最大不超过车厢剩余容量，β％为上车概率。

上下游的所有区段级子业务竞争业务的容量资源，对这样的业务间的资源竞争耦合的考虑在本专利建模仿真中简化为耦合关系对上车规则的影响。同时，这里体现了“车厢剩余容量—上车人数—等待人数”之间的耦合关系，在某一节点中，业务执行加载的乘客数量即上车人数与此时业务节点的等待人数有关，等待人数增多，上车人数增多，但不能超过车厢剩余容量。

方法1.3：客流的下车方法；

业务请求从业务中移除，数值为该业务执行实时负载的α％，α％为下车概率。

所有的节点都与同一链路级子业务的上下游节点之间有业务路径耦合关系，本发明简化为耦合关系对业务具体节点的客流下车方法的影响，即下车的乘客都与此时车厢内乘客数有关。同时，这里体现了“下车人数—车厢人数”的参数间的耦合关系，对于某一区段级子业务，下车人数与此时的车厢人数有关，车厢人数增加，下车人数增加。

业务间运行方法包括以下四部分：

1)业务的作用节点判断，与业务内运行方法类似，不赘述，得到此刻业务的起客流运输的作用的节点；

2)业务的作用节点的类型判断，业务上某一节点如果是中间站，则进入3)，反之，如果是换乘站，则进入4)；

3)执行业务的中间站客流的换乘方法，详见方法2.1；

方法2.1：中间站客流的换乘方法

业务请求从业务中移除γ％比例流量，且γ％<1-α％，并转发到的同一节点的反方向业务上，γ％为换乘概率。

根据前述分析，中间站上两个平行的区段级子业务之间存在资源竞争耦合关系。同时，这里体现了“换乘人数—车厢人数”的参数间的耦合关系，对于某一区段级子业务，换乘人数与此时的车厢人数即业务执行上的人数有关，车厢人数增多，换乘人数增多。

4)执行业务的换乘站客流的换乘方法，详见方法2.2。

方法2.2：换乘站客流的换乘方法；

业务请求从业务执行中移除γ％比例流量，且γ％<1-α％，其中γ1％的流量均匀转发到的换乘链路的两个方向的业务上，γ2％的流量转发到的同一节点的反方向业务上，γ＝γ1+γ2，γ1％为换乘其他业务的概率，γ2％为换乘反向业务的概率。

其中，业务的耦合关系可以指导中间站和换乘站客流的转发方法设计：

步骤32：其次确定节点状态变化条件下的业务演化规则，包括节点故障发生和节点故障恢复，其中节点故障发生包括以下三部分：

1)业务层信息更新，业务执行位置即业务位置直接跳过故障节点。物理层信息不变，因为节点还在，而且本发明仿真中考虑节点恢复。

2)执行业务客流的疏散方法，具体在故障节点上，见方法3.1；

方法3.1：业务客流的疏散方法；

等待在该节点a的乘客，即节点故障发生那个时刻的等待人数或者原本要使用该节点的乘客即节点故障发生后任一时刻的加载人数被疏散，包括客流移除和客流转移，具体是移除k％的客流L_a ^t，剩余客流(1-k％)转移到其他节点上。

此时就存在客流具体如何转移的问题，本发明考虑业务耦合关系进行客流的转移方法分类。客流转移方法是指客流从轨道交通系统中暂时脱离，通过步行或者其他的交通工具进行短时间附近节点的转移，在建模仿真分析中可以认为轨道交通系统的客流并无增减而是进行了转移。考虑封闭节点滞留乘客以及本需要进出该节点的乘客转移到附近其他的节点。客流的转移方法可以依据业务路径耦合关系的强弱简单的分为两类，如图2所示：

图3中黑色区域节点故障，客流需要往附近节点转移，存在两种客流转移变化：①强业务路径耦合的客流转移变化：客流向同一业务路径上的上下游节点进行转移或以这类转移为主，如图3中的强业务路径耦合所指向的箭头；②弱业务路径耦合的客流转移变化：客流向不同业务路径上的较近节点进行转移或以这类转移为主，如图3中的弱业务路径耦合所指向的箭头。在本发明仿真中客流转移只选取该模式下最近的节点，选取了强业务路径耦合的客流转移变化模式，客流向同一业务路径上的前后两个节点进行转移，且不存在同时向同一业务路径上的前后两个节点和不同业务路径上的最近的一个节点转移的情况。

3)执行客流加载条件下的业务演化规则，具体在非故障节点上，包括业务内和业务间的运行方法。

本发明考虑了故障节点的恢复，也是节点状态变化的一种情况，在故障节点恢复后，对应的节点状态变化条件下的业务演化规则中的节点故障恢复包括以下两部分：

1)业务层信息更新，业务执行位置即业务位置恢复考虑故障节点，物理层信息不变。

2)执行客流加载条件下的业务演化规则，包括业务内和业务间的运行方法，详见步骤31中的介绍。

本案例中，以下给出仿真中业务演化规则相关的参数设置：

业务运行过程中上车比例：β，服从(0,1)的均匀分布；

业务运行过程中下车比例：α，服从(0,1)的均匀分布；

业务运行过程中换乘比例：γ，服从(0,1-α)的均匀分布，且γ1＝γ2＝0.5*γ；

故障节点的客流移除比例：k％＝10％；

故障节点的客流转移比例：1-k％＝90％。

业务初始频次：2个时间步；

业务执行初始负载：0人；

业务执行初始速度：0.5；

业务上初始节点等待人数：0人；

业务上初始节点换乘人数：0人；

仿真总时长：200个时间步

相应的仿真算法伪代码如下：

步骤4：轨道交通系统业务故障评估指标为：

其中，

为t时刻第i个业务的平均留乘时长，

是t时刻业务APP_i的留乘率，

为t时刻能够登乘业务APP_i的乘客人数，

表示业务APP_i等待服务的乘客的总数，包含进站人数和等待人数的总和。

与现有技术相比，本发明提出的轨道交通系统业务演化模型建模方法通过对轨道交通系统的业务进行分析，从演化对象、演化条件、演化规则三个方面进行建模，演化对象建模考虑了基础设施层及业务层，基于此对演化条件、演化规则进行了描述，并提出了业务平均留乘时长来对轨道交通系统业务运行状态进行评估，其能够对多业务运行下的轨道交通系统演化进行建模。

以上所述的实施例仅是对本发明的优选实施方式进行描述，并非对本发明的范围进行限定，在不脱离本发明设计精神的前提下，本领域普通技术人员对本发明的技术方案做出的各种变形和改进，均应落入本发明权利要求书确定的保护范围内。

Claims (8)

1.一种轨道交通系统业务演化模型建模方法，其特征在于，其包括以下步骤：

步骤1：获取待建模轨道交通系统的网络初始信息，所述网络初始信息包括网络拓扑信息和业务信息；

步骤2：轨道交通系统演化对象建模，所述演化对象建模包括物理层对象建模和业务层对象建模，所述物理层对象建模具体为：

所述待建模轨道交通系统是由物理层和业务层组成的双层网络，所述物理层由网络拓扑组成，所述网络拓扑表示为G(V,E)，其中V是轨道交通系统中的所有节点的集合，V＝{v₁,v₂,…,v_n}，v_n为第n个节点；E是轨道交通系统中节点间所有链路的集合，E＝{e₁,e₂,…,e_m}，e_m为第m个链路；

所述业务层对象建模具体为：业务层以物理层为基础，业务层由业务的源宿节点、业务路径、业务容量、业务负载、业务执行频次、业务执行速度、业务执行位置和业务执行数组成，其中业务容量用数组C_i＝{C₁,C₂,…,C_M}表示，M为某一时刻链路上的业务数量，C_i为第i个业务的业务容量；其中业务负载用数组L_i＝{L₁,L₂,…,L_M}表示，L_i为第i个业务的业务负载；其中业务执行位置用Z_i＝{x₁,x₂,…,x_M}表示，Z_i为第i个业务的业务执行位置；

步骤3：轨道交通系统演化条件建模，所述演化条件建模包括客流加载设计和节点状态变化设计；

步骤4：轨道交通系统演化规则建模，所述演化规则建模包括客流加载条件下的业务演化规则建模和节点状态变化条件下的业务演化规则建模，所述客流加载条件下的业务演化规则包括客流加载条件下的业务内运行方法和客流加载条件下的业务间运行方法；所述节点状态变化条件下的业务演化规则包括节点状态变化条件为节点故障发生下的业务演化规则和节点状态变化条件为节点故障恢复下的业务演化规则；

4a、客流加载条件下的业务内运行方法具体包括以下步骤：

步骤4a.1：按照业务执行位置Z_i及业务执行数更新方法进行业务执行位置更新；

步骤4a.2：将所述步骤4a.1更新后的业务执行位置与业务的所有节点V的位置对比，将所述业务的所有节点V的位置中与更新后的业务执行位置相同的节点作为业务的客流运输作用节点；

步骤4a.3：对所述步骤4a.2获得的业务的客流运输作用节点执行客流的上车方法和客流的下车方法；

4b、客流加载条件下的业务间运行方法具体包括以下步骤：

步骤4b.1：按照所述4a中客流加载条件下的业务内运行方法进行业务的作用节点判断，获得业务的客流运输作用节点；

步骤4b.2：判断业务的作用节点的类型，如果所述业务的作用节点是中间站，则进入步骤4b.3，如果所述业务的作用节点是换乘站，则进入步骤4b.4；

步骤4b.3：执行业务的中间站客流的换乘方法；

步骤4b.4：执行业务的换乘站客流的换乘方法；

4c、节点状态变化条件为节点故障发生下的业务演化规则具体包括以下步骤：

步骤4c.1：更新业务层信息，业务执行位置Z_i直接跳过故障节点，物理层信息不变；

步骤4c.2：在所述故障节点上执行业务客流的疏散方法；

步骤4c.3：在非故障节点上执行客流加载条件下的业务演化规则；

4d、节点状态变化条件为节点故障恢复下的业务演化规则具体包括以下步骤：

步骤4d.1：更新业务层信息，业务执行位置Z_i恢复考虑故障节点，物理层信息不变；

步骤4d.2：执行客流加载条件下的业务演化规则；

步骤5：确定业务故障评估指标，对轨道交通系统业务故障进行分析与评估。

2.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤4中业务执行位置Z_i及业务执行数更新方法具体为：令业务执行速度为S，根据所述业务执行速度S和时间步获得业务执行对应的节点编号信息，更新业务执行位置；根据所述更新后的业务执行位置更新业务执行数，具体为：如果当前最晚加载进来的业务的业务执行位置

则在第一个节点新增所述业务，否则不新增所述业务；如果当前最早加载进来的业务的业务执行位置

则移除所述业务，否则不移除所述业务，M为某一时刻链路上的业务数量；

所述客流的上车方法具体为：上车业务请求从节点中移除并加载到业务上，所述上车业务请求的数值为实时节点负载的β％，且在车厢剩余容量以内；β％为上车概率；

所述客流的下车方法具体为：下车业务请求从业务中移除，所述下车业务请求的数值为业务负载的α％，α％为下车概率。

3.根据权利要求2所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤4中业务的中间站客流的换乘方法具体为中间站业务请求从业务中移除γ％，且γ％<1-α％，并将中间站业务请求转发到同一节点的反方向业务上，γ％为换乘概率；

所述业务的换乘站客流的换乘方法具体为换乘站业务请求从业务中移除γ％，且γ％<1-α％，其中γ1％的换乘站业务请求平均转发到换乘链路的两个方向的业务上，γ2％的换乘站业务请求转发到同一节点的反方向业务上，γ＝γ1+γ2，γ1％为换乘其他业务的概率；γ2％为换乘反向业务的概率。

4.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤4中业务客流的疏散方法具体为疏散等待在故障节点a的乘客，所述乘客包括节点故障发生时刻t的等待人数和原本要使用所述故障节点a的乘客，所述疏散包括客流移除和客流转移，所述客流移除为移除k％的客流L_a ^t；所述客流转移按照强业务路径耦合的客流转移变化，具体为剩余客流(1-k％)转移到非故障节点上，所述强业务路径耦合的客流转移变化为客流向同一业务路径上的上下游节点进行转移。

5.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤5中业务故障评估指标

为：

式中：App_i为第i个业务；

为t时刻业务App_i的留乘率；

为t时刻能够登乘业务App_i的乘客人数；

为业务App_i等待服务的乘客的总数，所述乘客的总数包括进站人数和等待人数。

6.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤1确定待建模轨道交通系统的网络初始信息，所述网络拓扑信息是由网络拓扑和网络资源组成；所述业务信息包括业务起始节点、业务目的节点、业务流程、业务起始时间、业务运行间隔时间和业务容量。

7.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤2的节点v_n的数据结构包括：节点名称、节点编号、节点状态、节点邻接关系、节点等待人数、节点换乘人数和节点出站人数；所述链路e_m的数据结构包括：链路名称、链路编号、链路源节点、链路宿节点、链路长度。

8.根据权利要求1所述的轨道交通系统业务演化模型建模方法，其特征在于，所述步骤3中客流加载设计为设计任意时刻某一节点客流的加载量分布，所述加载量分布包括正态分布、指数分布和均匀分布；所述节点状态变化设计为采用等价类划分的方法，按照强弱调控耦合对多节点故障模式进行分类，所述强弱调控耦合包括全网分散、局部集中，强弱业务路径耦合和强弱资源竞争耦合。

Images