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.