📚 课程目录第4章 Telegram定义与消息类型

4. Telegram定义与消息类型

在 SAP EWM 与 MFS（Material Flow System，物料流系统）的集成中，Telegram 是 PLC 与 EWM 之间交换控制信息的“最小通信单元”。EWM 不直接驱动输送机、堆垛机或穿梭车，而是把控制意图封装成 Telegram 发给 PLC；PLC 执行后，再把设备状态、位置反馈、故障信息封装成 Telegram 回传给 EWM。因此，理解 Telegram 的结构与消息类型，是排查“任务不下发”“设备不动”“状态不更新”等问题的起点。

一、Telegram 的基本结构

一条 MFS Telegram 在逻辑上由三部分组成：报文头（Header）、业务数据段（Payload）和校验/结束标识（Trailer）。报文头用于标识这条消息“是谁发的、发给谁、属于哪类业务”；业务数据段承载真正的控制参数，例如目标位置、托盘号、速度档位；校验部分用于保证通信完整性。

在 EWM 侧，Telegram 并不是随意拼字符串，而是通过 /SCWM/MFS 通信框架与 Telegram 类型（Telegram Type）来定义。一个 Telegram 类型决定了：字段顺序、字段长度、数据类型、必填/可选、以及对应的处理函数（Function Module 或类方法）。PLC 侧则按相同的字节布局解析，双方必须严格一致，否则会出现“收到报文但解析错位”的问题。

常见的字段包括：

Telegram 类型码：如 TASK、STATUS、ALARM，用于区分消息用途；
设备/资源编号：标识目标输送段、堆垛机或工作站；
任务号/指令号：EWM 下发的唯一任务标识，用于回执匹配；
源位置与目标位置：如输送段编号、货位坐标；
物料/托盘标识：HU 号、物料号或条码；
状态码与故障码：设备当前状态或报警代码；
时间戳：用于超时判断与顺序控制。

下面这张图展示了 EWM 与 PLC 之间 Telegram 的典型信号链与字段归属关系，帮助建立“谁产生、谁消费、哪些字段用于匹配”的整体印象。

二、常用消息类型及其语义

MFS 场景下最常用的 Telegram 消息类型可以归纳为三类：任务下发类、状态反馈类和故障报警类。它们的方向、触发方和典型字段各不相同。

消息类型	方向	触发方	典型字段	用途
TASK（任务下发）	EWM → PLC	EWM 任务引擎	任务号、设备号、源位置、目标位置、HU号、优先级	指示设备把托盘从 A 送到 B
STATUS（状态反馈）	PLC → EWM	PLC 周期或事件触发	任务号、设备号、当前状态、位置、时间戳	告知 EWM 任务已接收/执行中/完成
ALARM（故障报警）	PLC → EWM	PLC 检测到异常	设备号、故障码、故障描述、严重级别、时间戳	通知 EWM 设备异常，触发人工干预

需要特别注意的是：任务号（Task ID）是贯穿三类消息的主键。EWM 下发 TASK 时生成任务号，PLC 在 STATUS 和 ALARM 中必须原样回传该任务号，EWM 才能把反馈关联到具体任务。如果 PLC 回传的任务号为空或错位，EWM 会认为任务“未确认”，进而触发重发或超时告警。

三、Telegram 类型的配置方法

在 EWM 中配置 Telegram 类型，通常通过 SPRO 路径 SCM Extended Warehouse Management → Material Flow System → Define Telegram Types 进入。配置的核心是“字段清单 + 处理逻辑”两部分。

第一步，定义字段结构。每个字段需要指定：字段名称、起始位置、长度、数据类型（CHAR/NUMC/INT 等）、是否必填。例如一个简化的 TASK 报文可以定义为：

字段名          起始  长度  类型   说明
MSG_TYPE        1     4     CHAR   固定值 'TASK'
TASK_ID         5     10    CHAR   任务号
DEVICE_ID       15    6     CHAR   设备编号
SOURCE_LOC      21    8     CHAR   源位置
TARGET_LOC      29    8     CHAR   目标位置
HU_ID           37    20    CHAR   托盘/ Handling Unit 号
PRIORITY        57    2     NUMC   优先级 01-99
TIMESTAMP       59    14    CHAR   YYYYMMDDHHMMSS

第二步，绑定处理逻辑。在 Telegram 类型中指定对应的处理类或函数模块，例如 TASK 类型绑定到任务接收处理逻辑，STATUS 类型绑定到状态更新逻辑，ALARM 类型绑定到报警写入逻辑。处理逻辑负责把报文解析成 EWM 内部结构，并触发后续动作。

第三步，配置通信参数。包括：PLC 连接标识、端口、协议（如 TCP/IP）、心跳间隔、超时时间、重发次数。这些参数决定了 Telegram 在“传输层”是否可靠。例如超时时间设为 5 秒，意味着 EWM 发出 TASK 后 5 秒内未收到对应 STATUS，就判定为超时并触发异常处理。

配置检查要点：字段长度和偏移量必须与 PLC 侧完全一致；任务号字段建议使用固定长度 CHAR，避免前导零丢失；时间戳格式双方必须统一；超时时间应大于设备最长动作时间，否则会误报超时。

四、一个可参考的配置示例

假设某仓库输送线有 3 个设备：CNV01、CNV02、SRM01。EWM 需要把托盘从入库口 IN01 送到货位 A-01-02。可以按如下方式组织 Telegram：

TASK 下发：MSG_TYPE=TASK，TASK_ID=T000001234，DEVICE_ID=CNV01，SOURCE_LOC=IN01，TARGET_LOC=A-01-02，HU_ID=HU0000000001，PRIORITY=05；
STATUS 反馈：PLC 收到后回传 TASK_ID=T000001234，DEVICE_ID=CNV01，STATUS=ACCEPTED；托盘到达 CNV02 后回传 STATUS=IN_PROGRESS；到达 SRM01 并完成入库后回传 STATUS=COMPLETED；
ALARM 报警：若 CNV01 光电传感器持续遮挡超过 10 秒，PLC 回传 TASK_ID=T000001234，DEVICE_ID=CNV01，ALARM_CODE=E102，SEVERITY=HIGH。

EWM 收到 COMPLETED 后，把任务状态置为完成，并更新 HU 的位置信息；收到 ALARM 后，在 EWM 中生成异常消息，并可通过 MFS 监控界面查看。整个闭环中，Telegram 是唯一的信息载体，字段定义一旦错位，后续所有判断都会失效。

常见排障方向：若任务下发后设备无动作，先检查 TASK 是否被 PLC 正确解析（看 PLC 侧接收日志）；若 EWM 一直显示“执行中”，检查 STATUS 的任务号是否匹配；若频繁超时，检查超时时间与设备实际动作时间是否匹配，以及网络是否存在丢包。

掌握 Telegram 的结构与消息类型，本质上是在掌握 EWM 与设备之间的“语言约定”。字段定义、任务号匹配、超时与报警处理，构成了 MFS 集成稳定运行的基础。后续在配置具体设备时，应始终以“双方字段一致、任务号可追溯、异常可感知”为检查标准。