VRt.Universal [UV] (7.17.2697)

用于通用航班规划的软件接口。

• 支持从任意地点提取货物
• 支持在任意地点卸货
• 多种类型的配对申请：PICKUP（装载）、DROP（卸载）
• 多种类型的独立申请：DROP_FROM_BOX（卸载已在车厢内的货物）、PICKUP_TO_BOX（将货物装入车厢且不后续卸载）、WORK（在无货物移动的地点工作）
• 复合订单可包含任意数量和类型的申请
• 运输工具与执行者分为独立实体，规划时自动优化分配执行者到运输工具
• 运输工具拥有多个隔间，每个隔间可容纳货物并具备独立特性
• 根据货物尺寸（长、宽、高及容量参数）验证货物与运输工具的兼容性
• 验证货物与运输隔间的兼容性（隔间特性如冷藏、保温袋、固定装置等）
• 替代申请——可选择基于地理位置和时间窗口的替代申请执行

执行者的限制：

• 起始/结束位置
• 考虑执行者前往运输工具起始点的移动
• 执行者可用时间表——可执行移动或地点工作的时段列表
• 执行者在特定时间段内的最大工作时长

运输工具的限制：

• 起始/结束位置
• 运输工具可用时间表——可执行移动的时段列表
• 路线最大长度
• 多个隔间，每个隔间有独立参数
• 总容量上限（重量、体积、订单数、申请数）

订单的限制：

• 严格时间窗口
• 可指定地点工作窗口与申请执行窗口的不同允许范围
• 路线内申请执行顺序的验证
• 期望执行时间窗口列表（每个窗口对应不同成本）

若一实体的属性列表完全覆盖另一实体的要求列表，则视为兼容（performer_blacklist 相反——列表不得重叠）。

支持的兼容性：

业务规则示例：

分配机制（hardlinks）用于指定订单、执行者和运输工具必须处于同一航班的要求。

分配仅保证实体处于同一航班，不保证实际规划结果。例如，若执行者无法按时完成订单，则不会被规划，但仍会被分配至航班（进入 waitlist）。

分配不覆盖已定义的兼容性（及兼容性违规的惩罚）。例如，若订单无法由执行者完成，则不会被规划，但仍会被分配至航班（进入 waitlist）。

支持以下旋转方式（以 90 度为步长）：

• ALL——可绕任意轴多次旋转
• YAW——可绕垂直轴（自转轴）旋转一次
• PITCH——可绕横向轴（垂直方向）旋转一次
• ROLL——可绕纵向轴（侧放）旋转一次

航班通过执行者状态列表描述，执行者可同时处于多个状态（例如在地点工作窗口内并在同一地点执行订单）。

地理位置标志（可同时多个生效）：

• AROUND_LOCATION——执行者位于地点附近（正在停车或驶离）
• INSIDE_LOCATION——执行者位于地点内

时间窗口标志（可同时多个生效）：

• INSIDE_WORKING_WINDOW——执行者处于工作时段内
• INSIDE_LOCATION_WINDOW——执行者处于地点开放时段内
• INSIDE_EVENT_HARD_WINDOW——执行者处于硬性时间窗口内
• INSIDE_EVENT_SOFT_WINDOW——执行者处于柔性时间窗口内

动作标志（仅一个生效）：

• ON_DEMAND——执行者开始处理申请
• WAITING——执行者开始等待
• RELOCATING——执行者开始移动至下一站点
• BREAK——执行者开始休息
• REST——执行者开始长时间休息
• ARRIVAL——执行者开始停车
• DEPARTURE——执行者完成驶离

逻辑状态标志：

• DURING_ROUNDTRIP——执行者正在执行循环航班

多状态路线示例

航班由一个或多个循环航班组成。

循环航班标志 DURING_ROUNDTRIP 在开始处理申请时激活，并在以下三种情况之一解除：

• 执行者到达某地点以停止使用运输工具
• 执行者到达分割循环航班的地点
• 执行者在非分割点地点完成其他操作后停止使用运输工具

两个循环航班之间不可插入 RELOCATING 状态，但允许插入 WAITING、BREAK、REST。

分割航班循环的地点需满足以下条件之一：

• 地点设置了通行能力限制 timetable.limits（可能有多个分割点）
• 地点同时是所有执行者、运输工具及 PICKUP 类型申请的起止点（仅一个分割点）

示例分割点（根据任务设定）：

• 配送中心（长途运输至商店或仓库）
• 商店或仓库（最后一公里配送至客户）
• 垃圾填埋场（垃圾清运任务）

每个规划任务可指定配置，以定义目标函数、路线质量与计算速度。

规划配置名称通过字段 trips_settings.configuration 传递。

主要配置：

附加配置：

可根据客户业务流程定制目标函数（申请配置）。

开发推荐使用 optimize_cars_then_distance，因该配置无需详细设置费率与订单成本。

输入数据验证包含以下步骤：

1. 模式检查

若请求不符合模式，则规划整体终止，返回 400 错误及 schema_errors。

建议在发送前通过模式（或 YAML 文件）验证请求。

2. 逻辑错误检查（阻止规划继续）

符合模式的数据将检查是否存在使规划无法进行的逻辑错误。

示例错误：引用空实体、所有订单与执行者不兼容等。返回 400 错误及 logical_errors。

3. 实体单独检查

未通过检查的实体将从规划任务中移除。

根据 treat_warnings_as_errors 设置，结果以 400 错误返回至 warnings 或包含在规划结果中。

4. 规划过程中的检查

部分检查仅在规划过程中执行（例如根据费率与交通预测无法到达某地点）。结果返回至 warnings 或规划结果中。

规划——根据订单、表演者和交通数据，制定考虑到所有指定限制的行程。

调度请求可以以同步（用于测试）和异步（用于一般用途）模式执行。

要获取原始任务上的 run-plan-refine 操作的结果，请使用 run-plan-refine。