news 2026/9/23 4:25:37

地铁站疏散仿真实战:用Legion建模与瓶颈识别全流程解析

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
地铁站疏散仿真实战:用Legion建模与瓶颈识别全流程解析

站台层突然冒烟,广播里喊着疏散,几百号人却堵在同一部扶梯口——这种画面真出事的时候没人敢拍下来,但设计院必须在图纸阶段就把答案算出来。我最近刚做完一个地铁站的疏散仿真案例,用的就是人群仿真软件Legion,前后折腾了两周,从CAD底图到最终报告都跑通了。这篇就聊聊这个案例是怎么一步步落地的,顺便把手上踩过的坑一起放出来,给准备接触这类项目的朋友做个参考。

先提醒一句:这里的Legion是Bentley旗下做行人仿真的那款软件,不是联想游戏本里那个Legion Toolkit控制台。搜索资料的时候千万别串台,我最初就犯过这个迷糊,搜了半天全是电脑调风扇转速的教程。

1. 站房疏散为什么不能靠“拍脑袋”:工具定位与选型逻辑

1.1 人流不是水流,手算估算法在关键时刻会失灵

很多初接触疏散评审的人会觉得,算个疏散时间而已,拿总人数除以出口宽度不就完了吗?早期确实有这种简化做法,比如国内规范里常见的“百人宽度指标”,本质上就是单位宽度能通过多少人、需要多宽。这个算法对规则场地、均匀分布的小型场所还能对付,一旦遇到地铁站、火车站、体育馆看台、大型商场中庭这类空间形态复杂的场景,误差就变得非常离谱。

问题在于人不是水。水流听话,哪儿宽往哪儿走、哪儿低往哪儿流,但人有决策、有犹豫、有从众,还有逆流、绕行和局部拥堵。两股人流在一个交叉口对冲时,通行能力会大幅下降;一个自动扶梯入口前排队队伍排到楼扶梯口时,上游地面的人流会开始减速甚至停住。这些现象手算公式根本没法刻画,而实际疏散恰恰就是由这些“局部失效”主导的。想摸清楚到底哪里会堵、堵多久、会不会影响总疏散时间,必须走微观仿真的路。

1.2 Legion到底在算什么(以及它不做什么)

Legion是典型的微观行人仿真软件,它把一个一个行人建模成独立的智能体,每个智能体有自己的期望速度、身体尺寸、路径偏好和反应逻辑。仿真过程中,智能体会根据前方的人群密度、障碍物位置和最短路径不断调整自己的步速和方向,整个系统的拥堵、排队、疏散自然涌现出来。这个思路和宏观流体模型最大的区别是:你能看到“哪个人在哪一秒走到了哪个位置”,而不是只看一堆统计曲线。

但也要说清楚,Legion不是万能的。它不做烟气扩散仿真,不做结构耐火分析,也不自动判断逃生指示标志是否合理。它解决的核心问题是“在给定建筑空间和人员分布条件下,人群如何在里面移动”。火灾的毒性、能见度衰减这类因素,需要在仿真里手动通过降速、绕行等参数去间接表达,或者干脆和CFD烟气结果耦合起来做二次分析。理解这一点,后面才不会对仿真结果产生不合理期待。

1.3 什么项目用Legion,什么项目别硬上

我在选型阶段给自己定了一个判断标准:只要空间形态重复度高、人员流动规律清晰、疏散路径简单明了,就不需要上微观仿真。两条直通道加一个大门的小展厅,手算加个安全系数完全够用。反过来,如果项目同时满足下面几个特征——空间节点多(闸机、安检、检票口)、楼层转换复杂(站台-站厅-地面)、人员组成混合(通勤旅客、拖行李的、带小孩的)、评审方对量化结果有明确要求——那就适合用Legion这类工具。

这次案例选择地铁站就是因为踩中了几乎所有特征。站台层有列车到达和出发的边界条件,站厅层有进出闸机和安检排队区,楼扶梯组成了唯一的垂直通道,一旦站台层发生火灾等紧急工况,所有人员都要逆着日常进站方向向上疏散,路径选择和被堵风险都很高。这个复杂度如果用静态公式硬套,结果根本没法说服评审专家。

2. 疏散案例拆解:从CAD底图到可运行的仿真模型

2.1 案例背景:一个两层地铁站的疏散目标

这个案例是一个典型的岛式地下二层地铁站,地下一层是站厅层,地下二层是站台层,站台宽度约12米,有效长度约140米,两个端头各有两组楼扶梯通往站厅。日常高峰时段的人流方向是从地面进站、下站台、上车;疏散工况则反过来,列车在区间内不进站时,站台滞留人员要通过楼扶梯上到站厅,再通过出站闸机、通道到达室外出地面。

拿到项目后第一件事不是打开软件,而是把疏散目标定清楚。这里参考的是国内地铁相关设计规范和消防评审要求,疏散场景通常按“一列车满载到站停车后,站台上全部乘客加上候车乘客同时疏散,且至少有一组楼扶梯失效”来考虑。保守一点,还要叠加相邻区间一列车在隧道内停车、乘客通过端门下至轨道区间步行的情形,不过这次案例按常规只做了站台+站厅全员的疏散场景。

2.2 行走空间建模:CAD导入后的第一件麻烦事

Legion支持导入DXF/DWG底图,听起来很方便,但实际导入后不能直接用。建筑专业的底图里往往有无数的尺寸标注、设备符号、填充图案、文字注释,这些东西在仿真软件里全是噪声,会干扰空间识别。我的做法是这样的:先在CAD里把不需要的图层冻结或删除,保留墙线、柱网、楼梯轮廓、闸机线、栏杆线这几类与人员通行直接相关的要素,另存为一份干净的底图,再导入Legion。

导入后要做的最关键操作叫“空间划定”。在Legion里,行人只能在“行走空间(Walkable Space)”里活动,你必须沿着墙线、边界线手工绘制出站台层和站厅层的可通行多边形。这个多边形必须是一个闭合区域,中间如有柱子、售票机、客服中心这类障碍物,要单独画障碍物轮廓把它们扣除掉。画行走空间时我踩过一个典型的坑:楼梯口处的多边形如果不延伸到梯段中心线,仿真时行人走到楼梯口会判定为“无路可走”,直接原地打转。

2.3 障碍物、边界与楼扶梯的定义细节

障碍物处理关系到仿真是否真实。地铁站里最容易被忽略的是那些“半高”障碍物,比如栏杆、闸机、安检机。闸机和栏杆虽然上半部分是通透的,但对成人来说就是不可穿越边界,所以在模型里必须按实体障碍物处理。安检机和柱子这类本身就不透行的,直接建矩形障碍物即可。后勤通道、设备房这类本就不允许乘客进入的区域,在行走空间划定阶段就直接不纳入,避免行人“抄捷径”穿进设备区。

楼扶梯是疏散仿真的咽喉节点,处理方式要特别仔细。楼梯在Legion里需要定义宽度、踏步尺寸、上行或下行方向,自动扶梯还要定义运行速度以及紧急模式下是否切换为楼梯行走。这里有个经验:疏散工况下自动扶梯一般按“停运当普通楼梯用”来建模,速度取人行楼梯的速度,不能再按扶梯运行速度计算。楼梯的通行能力与踏步高度关系比较大,如果底图里有不同踏步规格的楼梯段,最好分开建模,不要图省事做成一个大斜面。

2.4 行人参数:人群不是“均码”的

设置行人参数时最容易犯的错是所有人都设成一样的步速和体型。实际上站内人群构成很复杂:有拖着大件行李的旅客,有老人和儿童,有本地通勤的年轻人,还有行动不便的少数群体。我在这个案例里按高峰客流特征把行人分成了几类:中青年通勤者占比约55%,行李旅客约25%,老年人和儿童约15%,行动受限者约5%。每类人设置不同的期望速度和身体尺寸。

期望速度的分布可以参考Legion帮助文档里的默认值,也可以结合现场调研视频标定。一般来说,水平通道上的自由行步速在1.2米每秒到1.6米每秒之间,携大件行李的会降到0.8到1.0,老人儿童更低。重点在于速度不是固定值,而是围绕均值呈正态分布,这样仿真出来的拥堵形态更接近真实。行人的初始位置也尽量按实际候车习惯布在站台两侧车门对应区域,而不是均匀撒在站台上。

3. 疏散场景配置:核心参数这样校核才靠谱

3.1 疏散人数怎么确定

疏散人数是整个仿真的输入源头,这个值定错了,后面再精细的运算都白搭。案例里站台层人数按三部分叠加:列车满载乘客数、站台上原有序候车人数、刚下车还没来得及出站的换乘人数。列车定员根据车型和编组查技术参数,我取的定员值约1400人,候车人数按远期高峰断面客流估算,取了一个偏保守的数值。站厅层另计入闸机通道和出入口通道内的人员。

定人数时特别提示一个容易疏忽的问题:同一时刻站厅和站台都在疏散,总人数不是简单相加,还要考虑列车是否同时到达。最不利工况常设定为两列满载列车同时停靠左右两个站台(如果是侧式站台),导致站台瞬间涌入大量乘客。这个案例是岛式站台,只考虑一列车夹带候车乘客,否则人数会过于极端,评审也会认为工况不合理。

3.2 反应时间:最容易拍脑袋也最容易出错的参数

疏散开始不是所有人在警报响起那一秒就同时抬脚走人。人在接到火警信号后会有确认信息、收拾随身物品、犹豫判断等一系列动作,这段时间叫预动作时间,也有人统称为反应时间。预动作时间对总疏散时间的影响非常大,尤其对万人以上的大型站房,差一两分钟就可能从“达标”变成“不达标”。

Legion里可以在行程起点给行人设置一个延迟,也可以把延迟分布到每个人身上。我这次按行业惯例,对站台层人员给了一个30到120秒的正态分布延迟,站厅层及通道内人员给的是15到60秒。有人问为什么要区分层,因为站台层远离出口,人员对警报来源的辨识更慢,而且在站台上等车的人比已经出闸机的人更倾向于“再看看情况”。这个参数完全可以通过查阅同类项目疏散演练文献或做实地演习获得,实在没数据就按保守值取,别拍脑袋定个5秒让所有人都狂奔起来。

3.3 仿跑前的出口流量速算校核

跑仿真之前,我习惯先用手算公式做一轮快速估算。这轮估算的目的不是替代仿真,而是给自己建立一个心理预期,后续仿真结果如果偏离估算太远,说明模型里大概率有设置错误。手算思路很简单:总人数除以各出口有效宽度乘以单位宽度通行能力的总和,得到理想疏散时间。水平通道的通行能力工程上一般取1.3人每米每秒,楼梯段取1.1人每米每秒,扶梯停运时按楼梯算。

这个案例里站台层约1780人需要疏散。两组楼扶梯中,一组按失效处理,剩余一组楼梯有效宽度约2.4米,加上对侧通道内一组约1.8米宽的楼梯,总有效疏散宽度约4.2米。手算理想状态下,1780人除以约4.6人每秒等于387秒,也就是6分多钟,这还没算楼梯下行速度衰减和站厅出口排队。我拿这个数去对照后续仿真输出,结果仿真总疏散时间在7分半左右,偏差在合理范围内,说明模型设置基本可信。

3.4 仿真运行参数与随机种子

模型搭完、参数设完,剩下就是仿真时长和随机种子的问题。仿真时长别抠得太紧,建议设为比预估疏散时间多出20%到30%,否则可能出现“哨响了人还没走完”的截断情况。我在这个案例里设为720秒,保证所有人的疏散过程都能完整跑完。

Legion这类微观软件背后是随机模型,同样参数跑十次,每次结果都略有差异,因为行人的速度采样和路径选择带随机性。这就要求在正式出报告时不能只跑一次就下结论。我通常的做法是固定随机种子把结果跑稳定,然后换几个不同的种子各跑一遍,对比总疏散时间的波动范围。如果波动超过5%,说明模型里某个瓶颈区域对初始分布过于敏感,需要进一步检查参数设置,而不是选一次“最好看”的结果写进报告。

4. 仿真运行与结果判读:热力图背后的疏散真相

4.1 输出指标:不是只有一个“疏散时间”

仿真跑完,很多人第一反应就是看右上角那个总疏散时间,觉得数字越小越好。但疏散性能评估远不止这一个指标,至少还要看三项:人员密度分布、单位宽度流量、关键节点通过时间序列。总疏散时间只是最终结果,它没法告诉你拥堵发生在哪一刻、哪一处、持续了多久,而这些信息才是改造设计的依据。

我在出结果时重点关注的是“最后一批人的疏散时间”,也就是最后一个行人离开建筑边界的时刻。这个值直接对表规范。同时还要看单个人从出发到离开的平均时间,这个值反映整体疏散效率,如果偏高,说明路径上存在普遍性拥堵。第三个常用输出是“某断面的流量-时间曲线”,比如楼梯口和闸机组各自每分钟通过多少人,这个指标能精确暴露瓶颈断面到底卡住了多少通行能力。

4.2 瓶颈识别:密度热力图和速度图怎么看

Legion最直观的输出是动态密度热力图,用颜色表示单位面积人数。热力图在中文资料里常常被叫“负荷图”,看到红色区域先别急着定性为“堵死了”,要用数据校核一下密度是否真的到了行人无法前进的程度。按照工程上常用的服务水平分级,密度小于0.7人每平米还算自由行走,超过2人每平米行人开始频繁调整步伐,超过3.5人每平米基本处于顶挤前进状态,大于5人每平米几乎无法移动。

这个案例里最明显的红色区域出现在站台层中间那一组楼扶梯的入口:热力图显示扶梯口前方一大片区域的密度持续稳定在3到4人每平米,形成典型的扇形拥堵区。再看速度图,该区域平均速度低于0.3米每秒,几乎停滞。对比两侧端头的楼扶梯,发现它们的利用率并不均衡——中部的扶梯承担了约一半的疏散人流,而端头楼梯相对闲置。这说明问题不只是总宽度不够,而是路径吸引力差异导致的空间分配不均,光加宽度不如调整引导或优化扶梯位置。

4.3 达标判定:疏散时间与规范要求的对表

拿到仿真总疏散时间后,要回到设计规范和安全目标来做判定。国内地铁项目通常按“站台层人员疏散至安全区域的时间不超过6分钟”这类要求来执行,有的地方会严格到“在最不利工况下,最后一个乘客离开站台层的时间”。注意,站台层疏散时间和全站疏散时间不是一个概念,评审专家经常拿这个说事。前者只要求人员从站台层上到站厅层就算到达安全区,后者要求离开车站建筑本体,两者差出两三分钟很正常。

我在案例里分别输出并记录了这两个时间:站台层清空时间约为4分50秒,满足6分钟要求;但全站完全清空时间约7分40秒,如果评审要求“全站疏散至室外”,这个就不达标。这时候需要做的是回溯模型,看延误发生在哪里,然后提出改进措施,比如增加一组出站闸机的常开模式、调整站厅到地面的通道宽度,或者优化站台层的引导标志。否则单靠一个“不达标”的结论,报告是交不了差的。

4.4 多方案比选:怎么用仿真结果说服评审

疏散仿真的高级用法是做方案比选。评审会上空口说“我觉得扩宽楼梯有用”没有说服力,但如果摆出三组仿真对比,基准方案总疏散时间多少、优化方案多少、代价多少,专家很快就心里有数。我在这次案例里做了两个改进方案:方案A是增大消防救援人员对中部扶梯的引导,让更多人流向端头楼梯;方案B是临时打开一处平时关闭的消防通道作为辅助出口。

仿真结果很有意思:方案A几乎不改变总疏散时间,因为人流转向受制于空间可见性和引导效率,单纯“引导”无法弥补宽度缺口;方案B把全站清空时间从7分40秒压到了6分20秒左右,效果明显。后来和建筑专业的人一聊,才知道方案B其实利用了原本就存在的消防设施,只是消防预案里没有把它列为疏散出口。这个结论就直接写进报告,成了说服业主调整应急预案的关键论据。

5. 实战避坑:Legion疏散仿真常见问题与排查技巧

5.1 模型崩了或卡住,先查这三处

用Legion跑大模型,最让人头疼的就是运行到一半进度条不动了,或者直接崩溃退出。遇到这种情况先别重跑,按顺序查三处:第一,行走空间多边形是否闭合,这是最容易被忽略的,画的时候看着封闭,放大后可能有个头发丝粗细的缝隙,行人代理走到那里就“迷路”了;第二,障碍物是否和行走空间边界重叠,柱子或墙线如果和空间边界贴得太紧,软件在算碰撞检测时会出现数值异常;第三,行人出发位置是否合理,如果初始分布点放在了障碍物内部,仿真一开始就可能报错。把这三处检查完,大部分卡死问题都能解决。

另外养成一个好习惯:模型保存后先跑一个短时长的“检查跑”,比如30秒,把行人数量改少一点,看人群能不能顺畅走完一段路。确认没有明显异常后再跑全量,这样能省下大量反复调试的时间。

5.2 行人穿墙和异常堆叠怎么排查

跑着跑着发现行人直接穿过了墙壁或者两个人在同一个位置叠成一团,别急着骂软件bug,绝大多数时候是建模阶段的几何问题。穿过墙壁,十有八九是墙壁线没完全封闭,行人检测到墙上有断点,就把那个位置识别成了可通行区域。方法很简单:把障碍物轮廓线显示打开,放大检查有问题的区域,补上断点就可以。

异常堆叠则更可能是行人初始位置重叠,尤其当你用“批处理”方式快速生成大量行人时,位置随机分配有可能发生重叠。Legion里可以设置行人间的最小间距,把它调整到合理范围能明显改善这个问题。还有一类堆叠发生在楼梯口或闸机口,原因是通道通行能力设置过窄,行人在同一时间挤向同一个点,这时候要回到几何尺寸检查,确认是否是建模时对门宽的取值过于保守。

5.3 结果太乐观:小心默认参数的“陷阱”

仿真软件拿回来直接跑默认参数,结果往往比现实乐观。Legion的默认行人模型代表的是健康的、没有行李的、熟悉路径的成年人,这在真实疏散里几乎是理想状态。我做疏散仿真时总会刻意把参数往保守方向调一档:步速均值下调0.1到0.2米每秒,行人身体投影面积稍微放大,预动作时间分布加宽。实践证明,调完这些参数后仿真结果和实际疏散演练的数据更接近。

还有一个容易导致结果偏乐观的点是路径选择逻辑。默认情况下行人会倾向于选最短路径,但人在紧急状况下对路径的认知并不完全理性,可能在烟雾中避开某个走廊,也可能因为从众全部挤向主出口。Legion里有路径选择权重参数,可以设置某个出口或通道的吸引力不同。我建议至少跑两种路径策略:一种是最短路径,一种是绕开某失效区域后的重新规划路径,把两种情况都写进报告中,留给评审做判断。

5.4 现场验证:拿历史数据校核模型

写完仿真报告不代表万事大吉,有条件的情况下一定要做模型校核。地铁站是最容易拿到现场数据的场所,早晚高峰拍一段视频,统计站台和站厅的实际人群密度、楼扶梯通过流量,然后把这些数据导入Legion里跑一个完全相同的日常场景,对比仿真输出的断面流量和实际视频计数。偏差在15%以内,说明模型参数基本可信;偏差太大,就要回头细查行走空间划分、行人速度分布和路径选择参数。

这个案例里我拿一段早高峰视频做校核,发现端头楼梯处仿真流量比实测偏高约15%。原因是建模时给端头楼梯接了一个很宽的前置通道,行人能更快到达楼梯口。实际现场这个通道被一个临时票亭挡了一部分,人员必须绕行。把这个临时票亭作为障碍物加进去后,仿真流量明显下降,和实测基本吻合。这种校核过程虽然费时间,但价值非常大——它让整个疏散仿真从“纸上谈兵”变成了有实测数据支撑的可靠性分析。

最后再分享一个心得:做疏散仿真的人,最忌讳的是把自己当成软件操作员。Legion只是一台精密的计算器,关键还是你喂给它的参数和工况是否合理。每次跑完仿真,我都习惯问自己三个问题:疏散人数是不是最不利的?反应时间有没有过分乐观?瓶颈位置的拥堵是不是源于真实的建筑条件?这套自问流程帮我在多轮评审里避开了很多坑。如果你正在研究类似的人群仿真项目,重新看一遍建模细节和参数来源,多半能找到报告里还没有暴露的风险点。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/23 4:25:25

3步手写RFB协议:告别文档迷宫,搞定远程桌面核心

3步手写RFB协议:告别文档迷宫,搞定远程桌面核心 官方文档翻了几百页还是云里雾里?别急,今天咱们不背概念,直接上手 手写实现 一个最小可用的RFB(Remote Framebuffer)客户端。你只需要Python标准库,30分钟就能跑通一个能截图、能发键鼠事件的远程桌面原型。…

作者头像 李华
网站建设 2026/9/23 4:25:05

图解原理:中国航天纪念币预约代码跑不通?3步调通避坑

图解原理:中国航天纪念币预约代码跑不通?3步调通避坑 复制来的预约脚本一跑就报错,日志里全是 403 Forbidden 或者 Request Timeout ,盯着屏幕发呆,心里只有一句话: 复制来的代码跑不通不知道怎么调 。别急,这不是你代码写得烂,而是你没搞懂银行接口背后的 图解原理 。…

作者头像 李华
网站建设 2026/9/23 4:24:42

淘宝会员打折逻辑拆解:新手避坑指南

淘宝会员打折逻辑拆解:新手避坑指南 面试被问“会员打折怎么算”,你支支吾吾答不上来?别慌,很多新手都会在这里栽跟头,尤其是当系统涉及多层优惠叠加时。 新手避坑 的核心,不在于背公式,而在于理清计算顺序。 今天不讲虚的,直接拆解淘宝会员打折的底层逻辑。 1. 一句话原理:折扣是乘法,满减是减法…

作者头像 李华
网站建设 2026/9/23 4:24:15

2026最新锥螺纹实战:3个坑让你代码跑通

2026最新锥螺纹实战:3个坑让你代码跑通 看了一堆教程还是不会写项目?这种挫败感我太懂了。别怪自己,很多文章只讲概念,不讲落地。2026最新的开发环境对精度要求更高,尤其是涉及几何计算和数据结构时, 锥螺纹 这种看似简单的几何体,在代码里全是坑。…

作者头像 李华
网站建设 2026/9/23 4:23:57

3步搞定大屏幕工程,图解原理让小白也能跑通项目

3步搞定大屏幕工程,图解原理让小白也能跑通项目 看了一堆教程还是不会写项目?别急,今天用图解原理带你拆解大屏幕工程实战。很多水利新人卡在“看得懂代码,写不出系统”,其实不是代码难,是缺一个能落地的框架。 概念速懂:别被名词吓住…

作者头像 李华
网站建设 2026/9/23 4:23:43

3个坑:cf魔笛高频面试题,手写实现避坑指南

3个坑:cf魔笛高频面试题,手写实现避坑指南 版本升级后 API 全变了,是不是让你抓狂?很多 高频面试题 直接考的就是这种底层机制,稍不留神就掉坑里。今天不聊虚的,直接拆解 cf魔笛 的核心逻辑,带你从手写实现中看清本质,彻底搞懂那些让人头秃的细节。 1. 各自定位:谁在解决什么问题…

作者头像 李华