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