每次讨论低空经济或飞行汽车时，大家最容易兴奋的点往往是“车怎么飞起来”；但在做《新型一体化立体交通系统建模与仿真》这个项目时，真正让我们头疼的其实是一个交通规则问题：如果未来的城市道路不再只有地面一层，而是地面与多层低空航道叠在一起，当一辆飞行汽车想在十字路口一边转弯、一边从第 2 层升到第 3 层时，怎么保证它不会和上下层的直行车撞在一起？
换句话说，没有一套能同时管住水平分流和垂直升降的路口调度规则，飞行汽车就只能在固定起降点之间做点对点摆渡，算不上真正的“立体交通网”。在这篇复盘里，我想顺着一辆飞行汽车穿过立体路口的完整旅程，聊聊我们是怎么用基于模型的系统工程（MBSE）和 SysML 把这套规则画清楚的。
English version: An Integrated Multilevel Transport System: Modeling Junction Control and Vertical Transitions
一、先把立体交通拆成三个子系统
在建模初期，我们把整个立体交通系统切成了三大块：飞行汽车本体、地面与低空基础设施、以及故障处理与自我修复系统。 到中期汇报阶段，前两者的结构模型已经搭建完毕，而故障自愈部分则完成了顶层用例与响应框架设计。
1. 飞行汽车：不只是会飞，还要自带空间安全边界
我们在模型里以旋翼式陆空两用飞行汽车作为基准载体，把车端拆成了四个子系统：
- 能源支持子系统：负责给飞控、车载传感器和推进器供电，并在参数图里用功率约束锁死能耗上限；
- 控制与信息通信子系统：接收驾驶员或路口中心的调度指令，内部设计了主控电脑与备份电脑双冗余处理；
- 运动子系统：通过推进器与转向机构完成地面行驶、空中巡航以及跨层垂直升降；
- 空间感知子系统：这是立体通行最关键的一环——用距离传感器实时盯住周边车辆的水平间距，用高度传感器测量离地高度，并在本地存储模块里写入车身尺寸与最小安全距离包络。
2. 基础设施与交通控制：三维路口的指挥官
光靠车端感知还不够，路口本身必须有全局视野。我们在基础设施模型里放进了能源支持、信息通信与数据处理、以及传感与信号三个模块：路侧传感器负责采集各层车流密度，控制中心统筹计算通行次序，再通过三维交通信号灯向每辆车下发“能否进入路口”以及“允许走哪条空间通道”的指令。
3. 故障处理与自我修复：为空中突发失灵留后路
在地面上车坏了可以靠边双闪，但在低空航道里推进器失灵就是致命风险。我们在用例设计里专门推演了“空中单推进器故障”的应急链路：车载传感器触发报警后，一面立刻向周边车辆广播故障代码（撑大安全避让圈），一面请求调度中心清空下方的垂直下降通道并分配最近的应急降落区。在中期阶段，这套机制还停留在逻辑框架与用例层，对应的详细 SysML 块定义图（BDD）是我们留给下一阶段的任务。
二、跟着一辆飞行汽车穿过立体十字路口
为了让抽象的规则能被验证，我们把一次完整的立体路口通行拆成了 6 个标准动作，并用 SysML 活动图把每一步的判断条件画了出来：
- 提前 1 公里发起请求。 当飞行汽车驶近立体十字路口（用例草案以距路口 1 km 为触发点）时，主动向交通控制中心上报当前所在层级与目标方向，申请通行许可。
- 空间间距硬校验（安全门禁）。 收到控制指令后，车辆不会立刻盲目点火变轨，而是先调取高度与距离传感器读数，检查与周边车辆的相对距离是否大于安全阈值。在活动图里我们设了一条硬分支：只要间距校验不通过，系统直接判定为“无效指令”并锁死推进器，直到周围空域安全才放行。
- 按层内负载分配通道。 调度中心根据车辆去向和各层拥堵情况分配路径——直行车留在当前层主干道，需要转弯或跨层升降的车辆则被引导进立体路口的专用分流通道。
- 三维信号灯放行。 传统红绿灯只管平面冲突，而立体路口的绿灯箭头代表一条获准通行的三维空间走廊；当有车辆准备跨层升降时，与之存在空间轨迹交叉的上下层车流必须同步红灯等待。
- 5 毫秒闭环跨层升降。 车辆驶入指定的上行或下行通道后开始改变高度。在我们的跨层活动图模型中，高度传感器以 5 ms 为示例周期持续采样，每采一次就和目标层高度比对一次，一旦抵达目标层高度立刻切断垂直升降、转入平飞。
- 驶离路口并刷新负载。 车辆汇入下一段主航道进入巡航状态，路口控制中心同步更新各层车道占有率，为后车重算配时。
此外，我们还在调度逻辑里加了一条拥堵分流规则：当某一层通道的车道负载超过 90% 时，自动拉长放行周期并引导后续车辆绕行相邻层级。
三、为什么我们用 SysML 而不是直接写仿真代码
刚接触这类复杂系统课题时，很容易一上来就想写 Python 或用交通仿真器画动画。但我们很快发现，如果需求边界、子系统接口和异常分支没对齐，写出来的代码改一处崩一处。因此我们采用了 MagicGrid 方法论（在 MagicDraw 与 3DEXPERIENCE 规划环境下），把问题域、解决域和实现域拆开，用四类 SysML 图各司其职：
- 需求图与用例图：先界定系统到底要防什么风险、飞行汽车与调度中心各自承担什么职责；
- 块定义图（BDD）与内部块图（IBD）：理清车端和路侧各有哪些硬件模块，以及信号、电力和数据流在端口之间怎么走；
- 活动图、状态机图与序列图：把上面提到的“间距校验”、“5 ms 高度闭环”以及车辆在静止、起飞、巡航、降落之间的状态跳转固定下来；
- 参数图（Parametric Diagram）：把层高、车道宽度、车重、速度上限与安全距离写成数学约束方程，作为后续接入物理仿真的输入接口。
四、安全指标与那些尚待验证的参数
在用例说明书里，我们为这套立体路口设定了一组相当严苛的设计目标：比如垂直升降速度不超过 2 米/秒、水平转弯加速度不超过 1g、车辆最小安全包络为水平 5 米 / 垂直 3 米、控制指令延迟低于 50 毫秒、单路口峰值吞吐量不低于 500 辆/分钟，并在恶劣天气下强制锁死跨层升降。
在把这篇项目笔记整理到博客上时，我特别想把**“设计输入”与“已验证结论”区分清楚：上面这组数字（包括 1 km 请求距离、5 ms 采样周期和 90% 负载阈值）目前是我们为了跑通 SysML 逻辑模型而设定的先验设计参数**，而不是已经在风洞或真实交通流仿真里跑出来的实测结果。
五、阶段复盘：我们已经建好了什么、还差什么
回看整个课题的中期交付，我们真正完成的底座是：用一套自洽的 SysML 结构与行为模型，把“飞行汽车如何在立体路口安全申请、校验并完成跨层通行”这件事从自然语言变成了严密的工程图谱。
而接下来要补齐的拼图同样非常明确：一是把故障自愈子系统的 BDD 与跨系统交互序列图画完；二是把参数图里的先验指标放进多智能体交通流仿真器里，去检验“水平 5 米、垂直 3 米、限速 2 m/s”的约束下，单路口到底能不能跑出每分钟 500 辆的吞吐量。先把模型边界立住，再去谈仿真优化，这也是系统工程给我最踏实的一课。
资料来源
本文整理自我们的课题申请书、中期答辩讲稿、用例说明书及 SysML 建模工程文件；文中配图均导出自项目档案原图。