AnyLogic中行人流与复杂离散事件流结合的最优方案咨询

方案可行性与实现难度对比 #

方案1：PedService作为触发容器 #

• 可行性：完全可行。将PedService的服务延迟设为极大值（如Double.MAX_VALUE），行人进入后会一直停留；利用on begin service事件触发自定义子流程，子流程完成后通过代码将PedService的剩余延迟设为0，即可让行人正常离开并继续后续流程。这种方式能把复杂逻辑（多延迟、决策、条件占用/释放等）全部封装在子流程中。
• 实现难度：偏易。只需在PedService的事件中绑定子流程，再在子流程结束节点添加修改延迟的代码即可，核心是确保子流程与当前行人实例关联。

方案2：PedService作队列+独立子流程+资源管理 #

• 可行性：可行。用PedService仅处理行人排队逻辑，行人离开队列后，通过Seize模块占用预先定义的工作站资源（ResourcePool），随后执行完整子流程，最后用Release模块释放资源。这种方式将排队与业务逻辑解耦，符合离散事件模块的常规使用逻辑。
• 实现难度：略高于方案1。需要额外配置ResourcePool管理工作站数量，还要确保行人从PedService到Seize、子流程、Release的链路衔接正确，逻辑链条更长，但结构更清晰。

更简便的替代方案 #

直接采用**PedGoTo + ResourcePool + 自定义流程块**的组合：

• 用PedGoTo引导行人前往工作站区域；
• 到达后通过Seize占用ResourcePool中的工作站资源；
• 在该位置执行包含多延迟、决策、条件占用/释放的子流程（可使用流程建模库的各类模块或自定义代码实现）；
• 子流程完成后用Release释放资源，再继续后续行人操作。
  这种方式完全脱离PedService的限制，将行人移动与离散事件逻辑彻底拆分，逻辑更直观，也更灵活。

内容的提问来源于stack exchange，提问作者Jess C