Requested与Planned同值，为何仍不是Actual：读DCSA靠泊时间消息

DCSA Port Call 2.0.0的《Purpose & Scope》给Planned留下一条明确关系：计划时间始终等于一个请求时间。[1] 这个相等并没有让Requested与Planned合成同一种消息。Requested表达接收方希望服务在何时发生，Planned则表达提供服务的一方确认了该请求。同一个时间值，因而可以先出现在请求里，再出现在确认里；两条记录所表达的联系有所不同。

Estimated又从另一处开始。该页把它定义为某个主体对到达、离开、服务开始或完成时刻的估计。在到泊例子中，承运人向码头运营方提供预计抵达泊位的时间。这里的对象是Arrival at Berth；后文另列Arrival at Pilot Boarding Place以及货物作业开始、完成等事件。都使用时间字段，并不意味着它们描述船舶抵达同一个位置或同一个环节。

码头在例子中回应的是Requested Time of Arrival at Berth，即希望船抵达泊位的时刻。原文以码头延误需要调整到达时间为例，说明接收方为何可能提出不同于承运人预估的请求。这个字段不是把承运人的Estimated换一个英文名称，也不是码头对已经发生的到泊作一次测量；它位于双方交换希望与估计的过程中。

如果船不能满足请求，文档说会先有新的Estimated，随后有新的Requested，直到船同意请求，并以与Requested相同的Planned Time of Arrival确认。于是，E-R-P-A不必表现为四条消息各出现一次。原页明确允许Estimated、Requested与Planned有多个实例；一个时间交涉中，可以保留先前估计、对方请求、后续修订与最终确认各自的身份。计划值与请求值相等，说明的是确认哪一个请求，而非另作一次独立的时间猜测。

Actual的定义转向事件本身：它记录计划事件的实际执行。到泊示例在船抵达之后，才由承运人分享Actual Time of Arrival at Berth。因此，反复更新的预估或已经确认的计划，在这份定义中都没有替代实际到泊记录。Requested与Planned的同值关系属于消息交涉；Actual所联系的是已发生的事件。把这一差别保留在资料文字里，就能说明为什么相同或接近的时间不能仅靠数值被归成同一阶段。

但该页也没有把所有港口事件统一压进四步。它另列一些仅提供实际情况的信息事件，以vessel readiness for cargo operations举例，说这些事件不需要遵循E-R-P-A模式。这里采用的是文档对消息类型的例外说明：报告一种实际情况，与经历预估、请求及确认后再报告执行，并非同一套记录结构。本文不由这个名称判断任何真实船舶是否已安全就绪。

消息还有参与者层次。Actors & Roles列出Carrier、Port、Terminal和Service Provider；承运人一组又包含承运人本身、当地代理及船舶等角色。页面说明，不同组织和港口的内部安排有别，代表某一actor的不同party可能代其收发消息。因此，到泊例子中的承运人和码头是解释时间关系的角色，不能只从一个消息发送实体的名称，补出它独自完成了全部港口服务。

本篇范围限于这份2.0.0文档的时间语言和到泊示例。原页在Scope中把operational vessel schedules与货物作业通信列为并行的另外过程，并指向Industry Blueprint；这些外链内容没有被本文展开。上述预估、请求、确认、实到及例外对象，为港口服务资料提供的是具体的信息含义，不是实际船期安排、接口实施或航行装卸操作。