Factory Communication Protocol

Author: Ralf Banning, June 2020, updated in November 2021

flecsimo uses the MQTT protocol for public cross-component communication, i.e. all control, status and operation data is send as an MQTT message. This document describes the general message (protocol) architecture. For details on the implementation see the info section at the end of the document. This documentation provides an overview on the architecture and protocol details of communication.

Communication architecture on component level

The flecsimo system use two types of communication:

• a public, message and event driven channel, provided by mqtt
• a "private" (local) data exchange based on shared databases

On each level of the Manufacturing Data Model, at least two components will be active: a controller and an agent. The controller is the interaction point of user or station driven events and interacts with the assigned database or publish messages to a mqqt channel, whereas an agent is a event-driven program (without direct user or station interaction), receiving events from mqtt messages and reacts by publishing new messages or changing the state of the assigned database. This is shown in the following diagram:

In summary, the main difference between controller and agent interaction and communication is:

	controller	agent
Interaction with user
Interaction with station
mqtt publish
mqtt subscribe
Communication via data base

Overview on public communication protocol

The following table describes the messages intention in more detail

Message type	Name	Description	Note
logdta	Logging data	This message type is intended to be used for logging all types of data to a time series database (e, g, KAFKA), This message type is currently neither defined nor the use case.
scmdta	Supply Chain and vertical integration data	This message type is symbolic placeholder for inbound data from B2B communication and internal integration use cases. Both, message tpye(s) and use cases or not defined in deatail

For the messages inside the Area and Cell Operation Control reference fragment and Operation State and Reading reference fragment, see the subsequent section.

Operation control

Operation control is responsible for requesting operation service from next level entities, collect quotes for operations and finally to assign an operation to an area or cell. The protocol structure of site-to-area and area-to-cell is quite similar and differs only in some optional negotiations (which may change in future releases).

The following table describes the messages intention in more detail

Operation state and readings

(New version of 2021-11-19)

The following table describes the messages intention in more detail

Topic and subscription list

In flecsimo, the all topic elements before a message type indicated the sender of message, the part after the message type indicates a dedicated (unicast) receiver. In general, MQTT messages are understood to be multicast messages. Using the "trailing" receiver identifier allows focused subscription and reduces data transfer load. See updated DD_7 MQTT Topic-Structure for details.

Process related messages

In the following table, terms in italic are placeholders for real topic identifiers whereas terms printed in bold letters should be used as they are. Compare the following examples:

• site/opdta/area could be replaced by FUAS/opdata/area-1 or FUAS/opdta/area-2
• site/area/asgmt could be replaced by FUAS/area-1/asgmt or H_DA/area-4/asgmt

Status messages

(New in version of 2011-11-20)

Messages of type status are published by active components of a flecsimo lab and will not be subscribed by the standard agents. These messages are used for monitoring the lab (e. g. with an mqtt-explorer). To be able to distinguish different status messages issued at the same level (site, area, cell) the flecsimo msg library will define topics as shown in the following table: