EWM MFS and Robotics Integration: Control Boundaries, Queues and Recovery (Part 3)

In highly automated warehouses, EWM's Material Flow System (MFS) lets SAP communicate directly with the automation control level (programmable logic controllers, or PLCs) without needing a separate third-party warehouse control unit — this direct communication has been possible since EWM 9.4 via the ABAP Push Channel TCP socket layer; earlier releases needed an RFC adapter such as SAP Plant Connectivity (PCo) in between, and some landscapes still run that way.

The architecture centers on communication points — commonly I-points (identification points) or scanner points — each assigned to a PLC. When a handling unit (HU) reaches a communication point, it is identified (scanned) and the PLC sends EWM a telegram with that information. EWM evaluates it (e.g., runs storage bin determination) and returns a telegram instructing the PLC where to move the HU next. This request/response telegram exchange repeats at each communication point until the HU reaches its destination — so a single putaway or pick task is effectively broken into PLC-sized steps rather than handed over once.

At least one communication channel must be defined per PLC, and it governs message length, retry timing/count, and handshake mode — whether and how the PLC confirms receipt of a telegram. Capacity limits can be set on communication points, conveyor segments or resources; EWM holds back further tasks once a limit is exceeded, which is the built-in congestion control mechanism, not something the architecture needs to invent separately.

Ownership must still be explicit at the design level: EWM should not be issuing movement decisions that an independent robot/WCS controller is simultaneously re-optimizing. Stable task/telegram identifiers and clean status handoffs are what make recovery possible — a physically completed movement whose confirmation telegram is lost or malformed will leave EWM's task state out of sync with reality, and recovery must reconcile actual physical location before replaying or reprocessing anything. When a communication point cannot identify an HU, standard design routes it to a Clarification Point for manual resolution rather than letting it stall the automation queue silently — that clarification-point pattern should be part of any recovery design, not treated as an edge case.

Automation also raises the stakes on availability: manual fallback procedures must exist for blocked conveyors, offline robots, or communication-channel outages, since a purely automated design has no human-speed alternative path.

A robot completed a pallet move but the confirmation message was lost, leaving EWM with an open warehouse task. Recovery procedures reconciled physical location before technical reprocessing.

• Letting multiple systems (EWM and an independent robot controller) own the same movement decision.\n• Replaying confirmations blindly without reconciling physical HU location first.\n• Having no manual fallback for automation or communication-channel outages.\n• Treating unidentifiable HUs as an edge case instead of routing them to a defined Clarification Point.\n• Monitoring channel connectivity but not actual telegram/task state, so a lost handshake goes unnoticed.

• Define system ownership explicitly — EWM should not issue movement decisions an independent robot/WCS controller re-optimizes.\n• Use stable telegram/task identifiers and clean status handoffs so lost or out-of-order telegrams can be reconciled.\n• Route unidentifiable HUs to a Clarification Point rather than letting them stall the automation queue.\n• Size communication-channel capacity limits deliberately so EWM holds back tasks before congestion, rather than after.\n• Maintain a documented manual fallback for blocked conveyors, offline robots or communication-channel outages.

Explain the responsibility boundary between EWM, MFS and robotics and how recovery preserves physical/system consistency.