根据给定的 DesignShippingNetworkRequest
求解班轮运输网络的设计和调度问题 (LSNDSP)。
LSNDSP 是一个复杂的优化问题,旨在找到班轮运输网络的最佳设计和调度。我们的目标是尽可能降低运营网络的总费用,同时尽可能满足港口之间的货物需求。
LSNDSP 可分为两个主要子问题:网络设计和调度。网络设计子问题决定网络要处理的端口集、要在每条路由上部署的容器数量,以及这些容器将采用的路由。计划子问题根据在港口之间航行所需的时间、装货和卸载货物所需的时间以及港口之间的货物运输需求来确定船舶的航行安排。
简单地说,LSNDSP 的问题在于,需要决定为哪些港口提供服务、使用多少轮船,以及如何调度船只,从而最大限度地降低网络运营成本,同时最大限度地提高满足货物需求的收入。货物路由是 LSNDSP 中具有挑战性的子组件,它决定要满足哪些需求以及将哪些路线分配给货运以最大限度地提高收入。
HTTP 请求
POST https://optimization.googleapis.com/v1/shipping:designShippingNetwork
网址采用 gRPC 转码语法。
请求正文
请求正文中包含结构如下的数据:
JSON 表示法 |
---|
{ "requestId": string, "solverParameters": { object ( |
字段 | |
---|---|
requestId |
问题或请求 ID。 |
solverParameters |
求解器的参数。 |
ports[] |
要在容器服务中调用的可能端口的列表。请求必须仅包含此列表中的充电桩 ID。 |
legCandidates[] |
可添加到血管服务中的潜在候选腿的列表。请求必须只包含此列表中的路段候选 ID。 |
vesselClasses[] |
用于提供船舶服务的船舶类别列表。请注意,同一类中的所有容器完全可互换。请求必须仅包含此列表中的容器类 ID。 |
commodityDemands[] |
列出船舶服务要满足的潜在商品(如集装箱)需求。 |
vesselServices[] |
可以提供有效的船舶服务网络(通常是该网络的当前状态),作为优化的起点。 |
响应正文
该响应包含请求中传递的 LSNDSP 实例的解决方案。它包含有效的船舶服务和商品需求路径网络。经由每一段航程的商品总需求量不得超过承载此航段的船只的承载能力。请注意,没有未满足需求的船舶服务始终是班轮运输网络的设计和调度问题切实可行的解决方案。
如果成功,响应正文将包含结构如下的数据:
JSON 表示法 |
---|
{ "requestId": string, "vesselServices": [ { object ( |
字段 | |
---|---|
requestId |
与此响应关联的请求的 ID。 |
vesselServices[] |
船舶服务网络。对于每个容器类别,使用的容器总数不得超过此类别的可用容器数量。 |
commodityDemandPaths[] |
发货商品正向的所有商品需求路径的列表。请注意,如果未对需求发货,某些商品需求 ID 可能不会被包含在内。或者,商品需求也可以得到部分满足。对于每种商品需求,履单总量不能超过总需求量。最后,commodityDemandPaths 依赖于 vesselServices(请参阅 CommodityDemandPath 定义)。 |
SolverParameters
用于控制 LSNDSP 的单一求解的参数。
JSON 表示法 |
---|
{ "timeLimit": string } |
字段 | |
---|---|
timeLimit |
求解器应该在解题上花费的时间上限。该值不是硬性限制,并且不考虑通信开销。解决此问题的预期延迟时间可能会略微超过此值。 该时长以秒为单位,最多包含九个小数位,以“ |
端口
端口,例如一个端口的一个终端或所有终端。
JSON 表示法 |
---|
{ "id": string, "minimumPortStayDuration": { object ( |
字段 | |
---|---|
id |
为此充电桩分配的唯一 ID。 |
minimumPortStayDuration |
携号转网通话的最短停留时间。大多数研究都假设港口是恒定不变的,因为由于船港占据更多空间,因此移动次数较多的大型船舶通常会分配更多起重机。 |
minimumTransshipmentDuration |
在指定港口转运的最短持续时间,包括卸载集装箱再上载到其他船只所需的时间。 |
transshipmentCost |
运输集装箱的费用。这通常低于装卸总和,因为转运不需要在港口完成海关文书工作。 |
vesselClassCosts |
呼叫此港口时产生的费用(按容器类 ID 映射)。只有当 vessel 类在此地图中有条目时,它才能调用此端口。 包含一系列 |
时长
时长(停靠/转运、需求转运)是以小时为粒度定义的。
JSON 表示法 |
---|
{ "hours": string } |
字段 | |
---|---|
hours |
定义持续时间的小时数。 |
VesselCost
停靠和在此港口停留的船舶费用定义为住宿时长(fixedCost
+ hourlyCost
* 小时)的线性函数。
JSON 表示法 |
---|
{ "fixedCost": number, "hourlyCost": number } |
字段 | |
---|---|
fixedCost |
调用此端口的固定费用。 |
hourlyCost |
在该港口停留的每小时费用。 |
LegCandidate
船只服务航段候选项。相同的两个端口之间可以有多个路程候选项,例如:来表示不同的航线和/或船舶速度。
JSON 表示法 |
---|
{
"id": string,
"departurePortId": string,
"arrivalPortId": string,
"duration": {
object ( |
字段 | |
---|---|
id |
分配给此路段候选人的唯一 ID。 |
departurePortId |
出发港口的 ID。 |
arrivalPortId |
到达港口的 ID。 |
duration |
腿部时长。 |
vesselClassCosts |
将此航段候选航段分配给特定船型的费用。这可能包括船舶运营成本、沉船成本、包租成本。如果 vessel 类在此地图中有条目,则只能通过此航段候选航行。 包含一系列 |
VesselClass
容器类别,即具有相同属性的一组容器。无法区分属于同一类别的两艘容器。
JSON 表示法 |
---|
{ "id": string, "containerCapacity": string, "vesselCount": string } |
字段 | |
---|---|
id |
分配给此容器类别的唯一 ID。 |
containerCapacity |
容器类别容纳人数(以集装箱为单位)。 |
vesselCount |
此容器类别中的容器数量。 |
CommodityDemand
商品需求,即承运商需要满足的潜在需求。
JSON 表示法 |
---|
{
"id": string,
"originPortId": string,
"destinationPortId": string,
"containerCount": string,
"freightRate": number,
"maximumTransitDuration": {
object ( |
字段 | |
---|---|
id |
为此商品需求分配的唯一 ID。 |
originPortId |
源端口的 ID。 |
destinationPortId |
目标端口的 ID。 |
containerCount |
要满足的容器数上限。 |
freightRate |
每个集装箱的运费(可能包含因需求未履单而产生的罚金)。它应该消除了每个容器在出发地和目的地的装卸费。 |
maximumTransitDuration |
最长运送时间(如果已设置,应为正整数)。运送时间是指从提供此需求的首艘船只离开出发港到提供此需求的最后一艘船到达目的地港口之间的时间。 |
VesselService
可用于满足商品需求的船舶服务。重要提示:当前假设服务按每周频率计算,并且充电桩停留时间不得超过 1 周。请考虑以下船舶服务段序列:vesselServiceLegs { legCandidateId: "0->1"originDepartureTime {} destinationArrivalTime { day: 3 hourOfDay: 12 } } vesselServiceLegs { legCandidateId: "1->0"originDeliverureTime { day: 4 } destinationArrivalTime { day: 7 hourOfDay: 12 } } 这些路程定义穿越两个港口的一周服务线路,两个港口停留时间均为 12 小时。
JSON 表示法 |
---|
{
"vesselClassId": string,
"vesselServiceLegs": [
{
object ( |
字段 | |
---|---|
vesselClassId |
执行服务的容器类 ID。 |
vesselServiceLegs[] |
对于有效的船舶服务,应具备以下属性:1.此字段不能为空。2. 连续双腿destinationPortId 和 originPortId 必须匹配(包括最后一站和第一站)。 |
VesselServiceLeg
船只服务的一段航段。
JSON 表示法 |
---|
{ "legCandidateId": string, "originDepartureTime": { object ( |
字段 | |
---|---|
legCandidateId |
分配的路段候选 ID。 |
originDepartureTime |
每周时间表中的出发地港口的出发时间。 |
destinationArrivalTime |
抵达目的地港口的时间(按每周时间表)。 |
ScheduleTime
计划时间(船舶/按需出发/到达)以每周频率在给定时间设定。
JSON 表示法 |
---|
{ "day": string, "hourOfDay": integer } |
字段 | |
---|---|
day |
日程表上的日期。第 0 天为可能的第一天。 |
hourOfDay |
时间表时间的时段应为 0 到 23(含 0 和 23)之间的整数。 |
CommodityDemandPath
部分商品需求所占用的不同服务和港口。下面使用的索引基于响应中的船舶服务顺序以及具体船舶服务中的服务分段的顺序。
JSON 表示法 |
---|
{
"commodityDemandId": string,
"containerCount": string,
"vesselServiceLegIds": [
{
object ( |
字段 | |
---|---|
commodityDemandId |
已满足商品需求 ID。 |
containerCount |
经过此路径的容器数量。对于每种商品需求,履单总量不能超过总需求量。 |
vesselServiceLegIds[] |
通过此路径获取的船舶服务段 ID 的列表。对于有效的商品需求路径,应具备以下属性:1.首个航段的 exitPortId 必须与商品需求的 originPortId 一致。2. 最后一段航段的 destinationPortId 必须与商品需求的 destinationPortId 匹配。3. 连续双腿arrivalPortId 和 departurePortId 必须匹配。4. 如果为此商品需求提供此值,则最长运送时间应大于或等于路径的总时长。 |
VesselServiceLegId
商品需求路径中使用的单船服务段。例如,假设有两项船舶服务。第一个由三条腿(索引为 0、1 和 2)组成,第二个两条腿(索引为 0 和 1)。此外,第一段航程的第一段到达第二航段的出发港口。某商品路径由以下三个以下 vesselService leg 和 vesselService
JSON 表示法 |
---|
{ "vesselServiceIndex": integer, "vesselServiceLegIndex": integer } |
字段 | |
---|---|
vesselServiceIndex |
船舶服务的索引。 |
vesselServiceLegIndex |
船舶服务的航程索引(按 |