Messaging between Layer N and Layer N-1
Detailed description of the message structure between Layer N and Layer N-1, the MFC and the data concentrators.
Data Types
TransportUnit ID (T_TUID)
Alphanumeric case-sensitive string with the length of n characters, where n is defined per project.
Examples: S0000004711
LocationGroup (T_LGRP)
Alphanumeric case-insensitive string with the length of n characters, where n is defined per project. Additional allowed character symbols: _-
Examples: SHIPPING_AREA, errorZone4
Location (T_LOC)
Alphanumeric case-insensitive string with the length of n characters, where n is defined per project. Additional allowed character symbols: _-
Examples: RCV0001003400000000
Error code (T_ERROR)
Numeric value with the length of n digits, where n is defined per project. This numeric value can either express a decimal error code or a binary error bitmap. Depends on the project requirements.
Examples: 0000090
Date with time (T_DATETIME)
Numeric value with the length of 15 digits that follows the format YYYYMMDDHHMISS
Examples: 20150330140159
General Message Structure
A telegram message has always an unique identifiable message type. It always starts with a message header that includes a synchronisation character sequence, the sender and receiver of the message as well as the telegram length and the sequence number, that serves as a tracking number for both communication partners. All telegrams types have the same length defined, that is determined by the project. The length of the payload (without header) is specified in the telegram itself. Fields that are not used at all, or not used completely, must be padded with a padding character (specific to the field: An asterisk '*' or '_').
Message Header
Field | Datatype | Values | Description |
SYNC | 3 digits character | ### | A synchronisation header used to signal the start of a new message |
LEN | Numeric 5-digit value | 02048 | Length of message data in bytes without SYNC, SEND, RECV, SEQ fields |
SEND | Alphanumeric 5-digit value | SUBS1 | An unique identifier of the message sender. |
RECV | Alphanumeric 5-digit value | MFC__ | An unique identifier of the message receiver |
SEQ | Numeric 5-digit value | 00000-99999 | A sequence number of the telegram that is sent. A responding telegram has always the number of the telegram where it responds to. |
Message Payload
Field | Datatype | Values | Description |
TYPE | Alphanumeric 4-digit value | e.g. REQ_ | The telegram type is used to determine the type of telegram. |
TUID | T_TUID | e.g. S0000004711 | The TransportUnit ID is the identifier of the physical bin that is transported through the system. Usually the TUID is a barcode or RFID of that bin. How the TUID looks like is specific to each project. |
LOCATION | T_LOC | Any kind of location used in the telegram to identify a unique location in the subsystem area | |
ERROR | T_ERROR | 00000012 | An error code that is exchanged and well known by both communication partners |
TIMESTAMP | T_DATETIME | e.g. 20150330140159 | Date and time when the telegram was created on the sender side |
LOCGROUP | T_LGRP | INFEED | The unique identifier of an existing LocationGroup |
Message Types Layer N
Between Layer N <-> N-1 the following message types are defined:
TYPE | Description |
REQ_ | Request telegram. Used to request a target Location for a certain TransportUnit with a given TUID. The target Location can be the final target Location or an as-next Location where the TransportUnit should be moved to. |
RES_ | Response telegram. Usually sent as an answer of a preceding REQ_ telegram. A response determines a target Location for a given TransportUnit with the TUID identifier. Important telegram fields on receiver side are TUID and TARGET. |
UPD_ | Update telegram. Is used to update the state of a TransportUnit on receiver side. No response is expected. An update telegram carries at least information about the actual Location for a given TUID. |
UPDX | Update telegram with acknowledgement. In contrast to an UPD_ this telegram has to be acknowledged from the receiving side. |
ACK_ | The ACK_ telegram is used to acknowledge any kind of telegram that requires acknowledgement. The telegram sequence number matches to the sequence number of the telegram that needs to be acknowledged. |
LOCU | Location update is used to update the state of a Location. |
LOCX | Location update telegram that requires an acknowledgement. |
SYSU | A system update telegram is sent to inform the receiver about the logical or physical state of a system. |
REST | A restart (or cold-start) telegram signals a restart of the sending system and usually forces the receiving side to evict any conversation state. |
SYNQ | A time synchronisation request is sent to get the current timestamp from the communication partner. |
SYNC | The time synchronisation telegram is used to send the current time to the communication partner and to force a timestamp update on the opposite. |
ERR_ | An error telegram is used to signal error messages according to the communication protocol, like an unexpected telegram structure. |
Error Telegram (ERR_)
An Error Telegram is sent bidirectionally from one system to the other, in case a previously received telegram is syntactically incorrect or of unknown type. The reason for the error is encoded in the ERROR field. The LocationGroup may be passed as well assign the error to an area respectively context it has occurred.
Field name | Datatype | Optional | Description |
ERR_ | CHAR(4) | Error telegram type | |
LOCGROUP | T_LGRP | The LocationGroup the error occurred | |
ERROR | T_ERROR | An error code to describe the fault. | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An examples how an Error Telegram looks like:
###00160SPS01MFR__00001ERR_SHIPPING_AREA*******0000005020131123225959***************************************
****************************************************
Time Synchronisation Request Telegram (SYNQ)
A time synchronisation can be requested from both communication partners. The sender side requests for the current time. Keeping the time synchronised between systems is often a requirement when it comes to debugging situations or whenever a precise handling of expiration dates or timeouts becomes necessary. Because the usage of this telegram type is more of technical nature, the Information about the requester is taken from the telegram header (sender field) instead of a LocationGroup.
Field name | Datatype | Optional | Description |
SYNQ | CHAR(4) | Telegram type | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00140RAS10MFC__00001SYNQ20131123225959**********************************************
****************************************************************************
Time Synchronisation Response Telegram (SYNC)
A time synchronisation response telegram is the reply to a SYNQ telegram and carries the current time of the requested system. Information about the responder is taken from the telegram header (sender field).
Field name | Datatype | Optional | Description |
SYNC | CHAR(4) | Telegram type | |
CURRTIME | T_DATETIME | The current time of the responding system | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00140MFC__RAS1000002SYNC2013112322595820131123225959********************************
****************************************************************************
Messages from Layer N-1 to Layer N
Messages (telegrams) from layer N-1 to layer N are expected to be of the following type and content. Notice, that all listed message types are uni-directional only.
Request Telegram (REQ_)
A Request Telegram is sent from subsystems to ask for a target Location or target LocationGroup to where to transport the TransportUnit TUID to. The requester may provide a TARGETLOC field that is the current stored target of the TransportUnit to move.
Field name | Datatype | Optional | Description |
REQ_ | CHAR(4) | Telegram type | |
TUID | T_TUID | The TransportUnit ID (e.g. Barcode) | |
ACTLOC | T_LOC | The actual Location of the TransportUnit | |
TARGETLOC | T_LOC | x | The target Location where the TransportUnit should be moved to as next. It may not be the final target. |
ERROR | T_ERROR | x | An error code that signals an error that occurred for the given TUID |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example how a Request Telegram looks like:
###00140RAS10MFC__00001REQ_000000000S0000004711RECV0000000100010001????????????????????0000009020131123225959******************************************************
Explanation: The sender with the ID 'RAS10' requests the receiver the with ID 'MFC__' for a target Location for a given TransportUnit with the ID '000000000S0000004711'. The error code is '00000090', because the TransportUnit didn't pass a contour control station (the TU was just to high. This all happened on the 23nd. Nov. 2013, at 22:59:59 (24HRS).
Update Telegram (UPD_)
An Update Telegram is sent to update the current Location of a specific TransportUnit. It does not require any acknowledgement.
Field name | Datatype | Optional | Description |
UPD_ | CHAR(4) | Telegram type | |
TUID | T_TUID | The TransportUnit ID (e.g. Barcode) | |
ACTLOC | T_LOC | The actual Location of the TransportUnit | |
ERROR | T_ERROR | x | An error code that signals an error that occurred for the given TUID |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00140RAS10MFC__00002UPD_000000000S0000004711RECV0000000100010001********20131123225958
**************************************************************************
Acknowledged Update Telegram (UPDX)
The acknowledged version of the Update Telegram requires the responder on layer N to send an acknowledgement back to the sender on layer N-1 when the telegram has been processed – doesn't matter if processing was successful or not.
Field name | Datatype | Optional | Description |
UPDX | CHAR(4) | Telegram type | |
TUID | T_TUID | The TransportUnit ID (e.g. Barcode) | |
ACTLOC | T_LOC | The actual Location of the TransportUnit | |
ERROR | T_ERROR | x | An error code that signals an error that occurred for the given TUID |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00140RAS10MFC__00002UPDX000000000S0000004711RECV0000000100010001********20131123225958
**************************************************************************
Location Update Telegram (LOCU)
This type of telegram is sent from the subsystem to the upper system to inform the communication partner about the state of a LocationGroup or a certain Location. If both fields (LOCGROUP & LOC) are set, an update of the Location happens only – the LocationGroup is not been updated. The ERROR field is used to express the state of the Location or LocationGroup.
Field name | Datatype | Optional | Description |
LOCU | CHAR(4) | Telegram type | |
LOCGROUP | T_LGRP | x | LOC |
LOC | T_LOC | x | The unique identifier of the location to update |
STATE | T_ERROR | The state of the Location or LocationGroup to set. | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00160RAS10MFC__00002LOCU********************SL__CONV0001000100010000001120131123225958****
*******************************************************************
Acknowledged Location Update Telegram (LOCX)
The acknowledged version of the Location Update telegram (LOCU) requires an acknowledgement from the receiver side. If both fields (LOCGROUP & LOC) are set, an update of the Location happens only, not of the LocationGroup.
Field name | Datatype | Optional | Description |
LOCX | CHAR(4) | Telegram type | |
LOCGROUP | T_LGRP | x | The unique identifier of the LocationGroup to update |
LOC | T_LOC | x | The unique identifier of the location to update |
STATE | T_ERROR | The state of the Location or LocationGroup to set. | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
System Update Telegram (SYSU)
###00160RAS10MFC__00002LOCX********************SL__CONV0001000100010000001120131123225958****
*******************************************************************
Like a Location Update Telegram updates the state of a Location, the System Update Telegram is used to update the state of a system expressed by its LocationGroup name. The sender field in the telegram header does not correspond to the logical LocationGroup name.
Field name | Datatype | Optional | Description |
SYSU | CHAR(4) | Telegram type | |
LOCGROUP | T_LGRP | The unique identifier of the system's LocationGroup that requests a state update | |
STATE | T_ERROR | The current state of the requesting system. | |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on sender side |
An example looks like:
###00140RAS10MFC__00002SYSUSHIPPING_AREA000000002013112322595820131123225959******
******************************************************************************************************
Messages from Layer N to Layer N-1
Response Telegram (RES_)
The Response Telegram is responding to a previously sent Request Telegram (REQ_) to return a target Location or LocationGroup for a requested TransportUnit. The TARGETLOC Location could be interpreted as an as-next Location or as the final target Location. The same is true for the TARGETLOCGROUP field.
Field name | Datatype | Optional | Description |
RES_ | CHAR(4) | Telegram type | |
TUID | T_TUID | The TransportUnit ID (e.g. Barcode) | |
ACTLOC | T_LOC | The actual Location of the TransportUnit | |
TARGETLOC | T_LOC | x | The target Location where the TransportUnit shall be moved to as next. It may not be the final target. |
TARGETLOCGROUP | T_LGRP | x | The target LocationGroup where the TransportUnit shall be moved to. It may or may not be the final target. |
ERROR | T_ERROR | x | An error code that is transferred between both systems. |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on the sender side |
An example looks like:
###00140MFC__RAS1000002RES_000000000S0000004711RECV0000000100010001********************
SHIPPING_AREA********20131123225959*************************************************
Acknowledge Telegram (ACK_)
An acknowledge Telegram is sent as a response to a telegram that requires an acknowledgement before the subsystem can proceed with anything else. This mechanism is used when a subsystem depends on the decision from the system on layer N before it can proceed.
Field name | Datatype | Optional | Description |
ACK_ | CHAR(4) | Telegram type | |
ERROR | T_ERROR | x | An error code that is transferred between both systems. |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on the sender side |
The sequenceNo in the telegram header is the one of the origin request telegram header. The subsystem can map the sequenceNo and set the telegram as acknowledged internally.
An examples how an Error Telegram could looks like:
###00140MFC__RAS1000002ACK_********20131123225958************************************
******************************************************************************
Restart Telegram (REST)
A Restart Telegram is sent from a system on layer N to subsystems to notify about a system's restart. Usually communication partners evict any internal cache and start processing from a defined starting point.
Field name | Datatype | Optional | Description |
REST | CHAR(4) | Telegram type | |
ERROR | T_ERROR | x | Detailed instructions can be sent as error code |
TIMESTAMP | T_DATETIME | Date and time when the telegram was created on the sender side |
An examples how an Error Telegram could looks like:
###00140MFC__RAS1000002REST********20131123225958************************************
******************************************************************************
General Communication Scenarios
tbd. Describe some general flows, sequence of telegrams by example.
Last updated