企业官网建设流程全解析

简介：围绕轨道交通信号系统实验整理的一份doc文档，面向轨道交通、目标检测及车载控制方向的学习者，可用于课程实验报告参考与CBTC车载操作复盘。文档以车载系统与控制模式实验为主线，涵盖实验目的、器材、ATC初始化、RM/CM/AM模式转换、ATS计划接收、运行曲线显示、到站开关门、提前发车与跳停设置，并在实验分析中讨论线路设置、任务下发和驾驶操作要点；描述中还涉及用OpenCV与Anaconda辅助目标检测实验的思路。资源包共1个doc文件，约27.52MB，已有135人学习。读者可据此对照实验流程、整理报告结构、理解模式转换条件与排错方向，适合作为轨道交通信号实验的参考资料。

1. 顺序点错一次，三台机器一起重启：轨道车载控制实验到底在练什么

轨道实验内容里，“目标检测”四个字经常被摆到最显眼的位置，但真正让第一次上机的人手心出汗的，是车载控制模式那串不能颠倒的点击顺序。手里这份《轨道交通信号系统》实验报告，从头到尾记的就是加车、ATC 初始化、RM/CM/AM 切换、ATS 计划下发、到站开关门、跳停这一整条链路。它值钱的地方不在算法多漂亮，而在于把一套 CBTC 车载仿真台架上“哪一步先、哪一步后、错了会怎样”讲透了。这篇适合三类人：要交同类实验报告的学生、想复现这套仿真的自学者、带人上机时被问“为什么 AM 点不亮”问到头疼的助教。我会把报告里的操作顺序、模式转换条件和几个真会翻车的点拆开讲，重点放在判断依据上——做目标检测的读者也能对上号，列车位置、信号开放状态，本质上和检测框、置信度是同一类状态估计问题。

2. 实验台的角色分工：区域控制器和车载软件各管哪一段

很多人一上来就盯着车载界面点，点半天没反应，问题其实出在另一台机器上。这套仿真至少跑三个软件实体：区域控制器 CBTCZC、车载软件、ATS 与驾驶台。它们不是并列关系，而是有明确的上下级和时序。先把边界划清楚，后面的操作才有判断依据，不然你连“现在是软件没起来还是我点错了”都分不清。

2.1 区域控制器 CBTCZC 与车载软件，谁给谁发许可

区域控制器管的是“这列车能不能动、能往哪动”：列车注册、进路开放、移动授权，都从它这里出。车载软件管的是“这列车现在什么状态”：当前模式、牵引制动、目标速度、运行曲线显示。两者的关系是许可与被许可，不是对等通信。

判断依据很直接：车载上点完“ATC 钥匙接通”和“ATC 初始化”之后，区域控制器那边要弹出注册成功的提示，这列车才算真正进了系统。注册没成功，车载界面上的模式按钮要么是灰的，要么点下去毫无反馈，你以为是软件卡了，其实是授权链路没通。

常见的误用是把注册成功当成“车已经能跑了”。注册只说明系统认出了这列车的位置和编号，离发车还差着模式转换和任务下发两关。我一般会这么排：先确认区域控制器侧在线、进路状态正常，再看车载侧注册提示，最后才去碰模式按钮。顺序反了，排查成本翻倍。

2.2 加车之前先把上下行和初始位置定死

列车从哪出发，决定你走哪条初始化路径，这一步选错，后面的运行曲线全是歪的。

如果车从车辆段或者停车场出发，流程是等车辆段/停车场信号开放，然后以 RM 模式把车开到转换轨。如果车不从车辆段走，而是从存车线出发，那就要手动点“列车初始位置”，先选位置再加车。报告里特意标了一句：注意上下行，向右为上行，反之下行。这句话看着像废话，实际是血泪经验——位置选反了，列车在图上朝反方向跑，进路和曲线对不上，你会以为是软件 bug，其实是自己把坐标系搞反了。

这里的判断依据是：加车完成后，车载显示界面上列车图标的位置必须和 ATS 运行图上该车的计划起点一致。不一致就退回重选，别硬着头皮往下点。存车线和转换轨在图上通常有明显区分，先看清再动手，比事后重启三台机器划算得多。

2.3 三台机器的分工与操作时序

报告里提到一个容易被忽略的细节：每台列车的操作至少需要三台计算机设备。一台跑区域控制器，一台跑车载，一台跑 ATS 和驾驶台。分组实验时，不同的人负责不同的机器，靠嘴对齐时序。

正确的冷启动顺序，我按经验排是这样：先起区域控制器 CBTCZC，等它界面稳定、进路数据加载完；再起车载软件，让它连上控制器；最后起 ATS，设计并上传当天的运行线。反过来的话，车载先起会找不到注册对象，ATS 先起会下发不到车，最后都是“看起来都开着，实际谁也不认谁”。

判断链路是否打通，看两个信号：区域控制器侧能看到列车注册记录，车载侧能收到 ATS 的计划。两个都齐了，再谈模式转换。三台机器由三个人操作时，每次点关键按钮前报一句“我点了 ATC 初始化”，比各点各的靠谱得多。这套台架的容错很低，顺序一乱，轻则模式切不过去，重则全组一起等重启。

3. 四种控制模式的转换条件：RM、CM、AM 到底卡在哪一步

模式转换是整套实验的核心，也是最容易玄学化的部分——同样的按钮，别人点得亮，你点不亮。多数时候不是运气，是前置条件没满足。把每种模式“凭什么能进、凭什么退出”想清楚，比死记点击顺序有用。下面按 RM、CM、AM 逐层拆，最后给一份能照着走的状态机。

3.1 RM 模式：存车线到转换轨的唯一通道

RM 是限制人工模式，通常用在车从存车线或车辆段出来、还没进入正线受控区域的阶段。报告里的操作是：参数选择 RM 点亮，在列车方向按钮里选向前，最后再点一次 RM 让它熄灭——这一亮一灭之间，模式才真正落到 RM 上。

这个“点亮再点熄”的交互，新手最容易漏掉后半段。只点亮不点熄，界面看着像选中了，实际模式没提交，下一步点 CM 自然没反应。判断依据是看车载显示界面上当前模式的标识有没有变成 RM，而不是看按钮高亮。

RM 模式下的速度一般由人工控制，不依赖 ATS 计划，所以它适合把车从存车线挪到转换轨这段“系统还没完全接管”的路程。等车到了转换轨、信号开放、注册正常，才有资格往 CM 走。跳过 RM 直接想上 CM，在车辆段出发的场景里基本走不通。

3.2 CM 模式点不亮的三个前置条件

CM 是受控人工模式，列车已经纳入系统监控，但驾驶操作仍由人来做。它点不亮，九成是这三个条件里缺了一个：

第一，注册没成功。区域控制器侧没有这列车的注册记录，车载侧的模式切换请求就没有对象。回去看注册提示，别在车载界面上反复试。

第二，RM 没有真正落位。上一节说的“点亮再点熄”没做完整，系统认为你还停在初始状态。

第三，列车位置不在允许转换的区域。从存车线出来要先到转换轨，从车辆段出来要等信号开放，位置不对，系统不会给 CM 授权。

判断方法：点 CM 之前，先在车载界面上确认三件事——模式标识是 RM、列车图标在转换轨或允许区域、区域控制器侧注册在线。三件齐了再点，成功率接近百分之百。这份报告里把“先将车载切换到 CM 模式，再将车载切换到 AM 模式”写得很轻，实际每一步都有隐含条件，漏一个就卡住。

3.3 AM 模式与 ATO 发车：先点亮再点熄的门道

AM 是自动模式，列车在 ATO 控制下按计划运行，人只负责监控和开关门。进入 AM 的操作是：先点 ATO 点亮，再点 ATO 发车让它熄灭，和 RM 的交互逻辑一样，都是“选中再提交”。

这里有个反直觉的点：AM 能不能进，不只看模式按钮，还看有没有收到 ATS 计划。没有计划，ATO 发车点了也没用，列车不会动。所以正确的顺序是——ATS 下发计划、车载收到并显示运行曲线、再切 AM、再 ATO 发车。

报告里记录的失败案例很典型：到站开关门后，因为提前到站没到计划时间点，再点 AM 无响应。原因不是模式坏了，是计划时间没到，系统不允许发车。解决办法是在列车处点“提前发车”，重新进 AM 再发车。这个细节说明一件事：AM 的进入条件里包含了时间维度，不是纯按钮操作。

3.4 把顺序写成状态机

把这套流程写成状态机，比背步骤可靠。下面这段伪代码不是要你跑，是帮你在脑子里建立“当前状态 + 前置条件 → 下一状态”的判断框架：

# 车载模式转换的简化状态机（伪代码，用于理解前置条件） state = "IDLE" # 初始：未加车 registered = False # 区域控制器是否注册成功 has_plan = False # 是否收到 ATS 计划 plan_time_ok = False # 是否到达计划发车时间点 def to_rm(): # 前置：已加车、位置在存车线或转换轨 if state in ("IDLE", "POSITIONED") and registered: return "RM" def to_cm(): # 前置：RM 已落位、注册在线、位置允许 if state == "RM" and registered: return "CM" def to_am(): # 前置：CM 已落位、已收到计划、到达发车时间 if state == "CM" and has_plan and plan_time_ok: return "AM" # 转换失败时，先打印这三个变量，比盲点按钮快 print(state, registered, has_plan, plan_time_ok)

这段代码的价值在最后一行：转换失败时，把当前状态、注册标志、计划标志、时间标志四个量打出来，哪个是 False 一目了然。台架上没法真打印，但你可以用同样的思路在纸上列这四项，逐项核对。多数“玄学”卡顿，核对完就变成确定性问题了。

参数上要留意：registered对应区域控制器的注册提示，has_plan对应车载收到运行曲线，plan_time_ok对应 ATS 计划里的发车时刻。三者分属三台机器，任何一台没同步，AM 都进不去。这也是为什么分组实验要有人专门盯 ATS——模式切换从来不是车载一台机器的事。

4. ATS 计划与运行曲线：绿线黄线背后的两套逻辑

模式切对了，车还是可能不动，因为缺计划和任务。这一章讲 ATS 侧的设计与下发，以及车载上那两条颜色不同的曲线到底在说什么。理解了曲线，你才知道列车“该跑多快、能跑多快、为什么停”。

4.1 运行线设计与任务下发：没任务就没有速度

报告里第一步就是设计列车运行线并上传当天运行路线。在运行图上拖拽两点之间的横坐标距离，代表两站之间的预计运行时间——拖得越长，计划给的时间越宽裕，列车跑得越慢；拖得越短，计划越紧。

设计完之后是“运行任务，等待发车”。这一步不能省。报告里写得很明确：若没有下发任务直接操作驾驶，列车是没有运行速度的。也就是说，驾驶台推了牵引，车也不动。新手常以为是自己操作驾驶台的手法不对，实际是任务没下发。

判断依据：任务下发成功后，车载界面右上角的运行曲线区域会显示计划曲线，右下角重要信息区会显示当前任务和下一站信息。看不到曲线，就回到 ATS 查任务状态，别在驾驶台上反复推拉。

4.2 绿线跟黄线分别由什么生成

车载收到计划后，运行曲线上会出现两条线：绿色和黄色。报告给的定义很清楚——绿色是依据计划生成的站间曲线，黄色是依据进路开放情况生成的运行曲线。

翻译成判断语言：绿线告诉你“按计划你应该怎么跑”，黄线告诉你“当前进路允许你跑到哪”。两条线一致时，列车按计划走；黄线低于绿线，说明前方进路没完全开放，列车会被压速度。红色线段表示列车当前位置，随运行实时移动。

这套“计划曲线 + 授权曲线 + 当前位置”的三元结构，做目标检测的人看着应该眼熟：计划是先验预测，授权是当前约束，位置是观测值，三者一比对就知道系统状态是否正常。列车跑得比黄线快、或者位置偏离红线预期，都是异常信号。

实操上的用法：发车前扫一眼黄线是否覆盖到下一站，覆盖不到就别急着 ATO 发车，先查进路。运行中绿黄贴合、红线沿曲线走，说明一切正常；红线突然停住不动，先看是不是到站了或者任务被撤了。

4.3 到站开关门之后，AM 为什么没反应

到站后的流程是：列车停稳，点“打开左边车门”或“打开右边车门”，乘客乘降完，点对应的“关闭车门”，然后重新以 AM 模式发车。报告里记录了一次失败：到站开关门后操作 AM 无响应。

原因在 3.3 节提过——提前到站，没到计划时间点，系统不允许发车。这不是 bug，是 ATS 计划的时间约束在起作用。解决办法是点“提前发车”，绕过时间点限制，再进 AM。

这里的判断顺序值得记下来：AM 无响应时，先看当前时间是否早于计划发车时刻，再看车门状态是否全部关闭，最后看任务是否还在。三个里任何一个不满足，AM 都不会亮。多数人第一反应是重启车载，其实重启完还是同一个结果，因为问题在 ATS 侧的时间约束。

车门开关本身也有讲究：左右门要对应站台侧，开错边在仿真里可能不报错，但报告里要求按实际站台方向操作，养成习惯。关好门再发车，门没关严就点 ATO，部分仿真会直接拒绝。

4.4 跳停与 80km/h：怎么在仿真里把速度拉满

报告里为了观察列车能达到 80km/h，做了跳停设置。跳停的意思是让列车跳过某些站的停站作业，减少停车次数，从而在长距离区间内把速度拉起来。

操作是在列车处设置跳停，设置完成后驾驶台会显示跳停状态，列车运行速度很快接近 80km/h。报告的分析里写了一句关键判断：距离够长，列车行驶时间才够。也就是说，能不能跑到目标速度，取决于区间长度和加速时间，不是设了跳停就一定满速。

这一节的实用价值在于：它是验证“计划 - 授权 - 速度”链路是否正常的压力测试。如果跳停后速度上不去，回去查黄线是不是被进路压住了、任务是不是还在、牵引制动选择对不对。速度是结果，不是原因，盯着速度表排查往往南辕北辙，盯着曲线和任务状态才有效。

5. 避坑与排查：实验台上最常见的五个翻车点

这套台架的容错很低，很多操作错一次就得全组重启。下面五条是报告里出现过、我自己也反复见过的坑，按“现象 → 原因 → 解决”写，照着核对能省不少时间。

5.1 上车与初始化阶段：注册成功不等于加车成功

现象：车载界面显示注册成功，但列车图标不在预期位置，或者模式按钮全是灰的。

原因：注册只完成了“系统认车”，加车位置和上下行方向是另一步。报告里区分了从车辆段/停车场出发和从存车线出发两条路径，后者必须手动点“列车初始位置”，且要看清向右为上行、反之为下行。位置选反，图标朝反方向跑，后续进路和曲线全部对不上。

解决：加车后先核对车载图标位置与 ATS 计划起点是否一致，不一致就退回重选初始位置，别在错误位置上继续点 ATC 初始化。上下行判断用运行图方向做参照，别凭感觉。

5.2 模式转换与发车阶段：顺序错了就得重启

现象：点 ATC 钥匙接通或 ATC 初始化之后，软件卡死，最后三台机器一起重启。

原因：这两个按钮有严格先后顺序，报告里特意强调顺序不能搞错。钥匙接通是给车载上电授权，初始化是让车载和区域控制器建立注册关系，反过来点，控制器侧收到的是无效请求，部分仿真版本会直接卡住。

解决：固定顺序——先 ATC 钥匙接通，等界面反馈，再 ATC 初始化。每次点之前报一句，确认区域控制器侧在线。真卡住了别反复点，直接按流程重启，反复点只会让状态更乱。

5.3 运行与到站阶段：曲线不动、车门不开、速度上不去

现象一：驾驶台推了牵引，列车速度始终为零。原因：ATS 任务没下发。解决：回 ATS 确认运行线已上传、任务已下达，车载收到运行曲线后再操作驾驶台。

现象二：到站后点 AM 无响应。原因：提前到站，未到计划发车时间点。解决：点“提前发车”，重新进 AM 再发车，别重启车载。

现象三：设了跳停速度还是上不去。原因：区间距离不够，或黄线被未开放进路压住。解决：先看黄线是否覆盖目标区间，再看区间长度是否够加速，速度是结果不是原因。

这三条放在一起，是因为它们共享一个排查原则：先看 ATS 和进路，再看车载操作，最后才怀疑软件。多数“车不动”的问题，根子不在驾驶台。

6. 把顺序变成肌肉记忆：这套实验真正留下的东西

回过头看，这套实验教的最有用的东西，不是某个按钮在哪，而是一种排查习惯：任何一步没反应，先问“前置条件满足了没有”，而不是“软件是不是坏了”。注册、模式、计划、时间点，这四样构成了一条链，链上任何一环断了，表现都是“点了没反应”，但原因分散在三台机器上。

我自己的教训是第一次上机时，AM 点不亮就反复点，越点越乱，最后全组重启。后来养成一个笨办法：每次模式转换前，在纸上写四行——注册是否在线、当前模式是什么、有没有收到计划、到没到发车时间。四行里哪行是空的，就去对应那台机器上找，基本五分钟内能定位。这个习惯后来做别的事也用得上，排查问题先列前置条件，比盲目试错快得多。

报告里那次跳停跑到 80km/h 的观察，其实是个很好的验证技巧：想确认整条链路通不通，就用一个极端场景去压它。跳停减少停站、拉长区间，如果速度能顺利爬到目标值，说明计划、授权、牵引三条线都正常；爬不上去，问题一定在黄线或任务上。这比在正常运营场景里一点点试要快。

还有一点值得说：这份报告的评分维度分实验任务与内容、实验分析、实验报告三块，各分 A/B/C。真正拉开差距的是分析部分——同样跑通流程，能写清楚“为什么这一步必须先做、失败时看哪个变量”的人，拿到的评价完全不一样。操作是手熟，分析是脑熟，后者才是带得走的东西。

那份《轨道交通信号系统》实验报告我留着，主要留它的分析框架和那几个失败案例的记录方式。要复现这套 CBTC 车载仿真，照着第 3 章的状态机和第 5 章的排查表走一遍，比从头摸索省很多时间；报告里对绿线黄线、跳停、提前发车的判断依据，直接可以搬进你自己的实验分析里。从那以后我每次上机，模式转换前都强制走一遍那四行核对，再没让全组陪我等过重启。希望帮到你。

本文还有配套的精品资源，点击获取