Table of Contents

• 1. M2X - Interface for communication between mobile robots and peripherals in industrial environments
  • 1.1. Disclaimer
  • 1.2. Background and motivation
  • 1.3. Current status and participating at M2X
• 2. Objective and scope of M2X
  • 2.1. Other applicable documents
• 3. M2X protocol specification
  • 3.1. Symbols of the tables and meaning of formatting
  • 3.2. Permitted characters and field lengths
  • 3.3. Notation of enumerations
  • 3.4. JSON datatypes
• 4. General topic structure
• 5. Load handling interface
  • 5.1. Requirements for a M2X load handling station
  • 5.2. Safety considerations for load handling
  • 5.3. Errors
  • 5.4. Load handling unit
  • 5.5. Load handling sequence diagram
  • 5.6. Topics
  • 5.7. Load handling JSON schemas and subtopics
  • 5.8. Requests
  • 5.9. Load handling station state
  • 5.10. Load handling station factsheet
• 6. Transport order interface
  • 6.1. Requirements for a M2X transport order
  • 6.2. Errors
  • 6.3. Topics
  • 6.4. Transport order JSON schemas and subtopics
  • 6.5. Requests
  • 6.6. Transport order state
• 7. List of abbreviations
• 8. Glossary

1. M2X - Interface for communication between mobile robots and peripherals in industrial environments

Version 0.2.1, June 2025

M2X (Machine to X) is a research project developed by the Chair of Material Handling and Warehousing at TU Dortmund University and the Fraunhofer Institute for Material Flow and Logistics IML (associated partner). The project gets support by the VDMA (German, Verband Deutscher Maschinen- und Anlagenbau e. V.) and various partners from industry. Content is developed jointly between the research partners and the industry and the result is made publicly available in the form of the M2X interface definition. The aim is to design universally applicable interfaces for communication between the fleet management (FM)/mobile robots (MR) (such as automated guided vehicles (AGVs) or autonomous mobile robots (AMRs)) and other participants in an industrial environment like load handling stations, transport orders, peripherals etc. Proposed changes, bug fixes, issues or pull requests to the interface are to be posted in the GitHub repository. The latest official documentation can be found on the GitHub page. They will be jointly evaluated by the working group and, if the decision is positive, adopted in a new version. The project is work in progress.

1.1. Disclaimer

The following explanations serve as a definition of interfaces and execution of communication between MRs, FM and peripherals. Those who use them must ensure that they are applied correctly in specific cases. Responsibilities regarding implementation and adaptation in practice must be documented among the project participants. M2X also requires that the data quality of an implementation is sufficiently good and that there is a consensus among the parties involved on terminology, for example.

If you encounter any inaccuracies in the application of the proposals or the possibility of an incorrect interpretation, please report them in the official issues of the M2X GitHub repository.

1.2. Background and motivation

Warehousing is increasingly relying on MRs. However, the implementation of MR systems is both time-consuming and cost-intensive and is a challenge for both large companies and SMEs (small and medium sized companies). Interface definitions such as VDA 5050 standardize the connection between a FM and MRs and enable the cost-efficient use of heterogeneous fleets through interoperability. The M2X project, aims to reduce integration costs through further standardization in the MR context. Further necessary interfaces are identified and described using easily applicable, generally valid models. M2X enables companies to integrate automation quickly and cost-effectively. This gives companies a sustainable competitive advantage and secures their future on the market. The project and the associated requirements are defined and iteratively adapted in close communication with our partners. The interfaces identified so far for M2X are as follows:

• Load handling,

• Transport orders,

• Peripherals (doors, elevators, (signal) lamps and traffic lights),

• MR to MR or attachment.

The project is funded by the Federal Ministry for Economic Affairs and Climate Protection (BMWK) as part of the Industrial Collective Research (IGF).

1.3. Current status and participating at M2X

The next steps, will deal with the load handling interface. The working group meets at regular intervals to discuss and publish the new content to the M2X project. New content will be pre-released in the private repository. News updates on content or meetings can be found at the LinkedIn page.

The project has the status work in progress. For comments, desired content or bug fixes, an issue or pull request should be submitted to GitHub issues. For a direct contact via mail please refer to sven.franke@tu-dortmund.de and dennis.luensch@iml.fraunhofer.de

2. Objective and scope of M2X

The aim of the interface is to simplify the commissioning of MR systems in an existing industrial environment (peripherals, load handling stations, transport orders, MR to MR or attachment) when used in industry. The interface should enable the seamless operation of different peripherals from different manufacturers and conventional systems (existing systems). Figure 1 shows the idea of the M2X framework. In detail, this is to be achieved through the following points:

• Description of a standardized communication between MRs or FM and existing environment.

• Increased flexibility and autonomy of MR systems in the industrial environment.

• M2X provides communication processes and -content of the participants. Sequence diagrams and JSON schemas are provided for this purpose. The technical implementation is not prescribed and can take place at various levels, such as MR or FM and the environment itself. Implementation examples and best practices are provided.

• The interfaces presented should come as close as possible to plug & play solutions.

• The interfaces are developed from simple to complex contents or use cases.

• M2X will provide no safety considerations in the JSON schemas in a detailed level, but there can be use cases or examples on how to deal with the most occurring safety issues. Safe communication protocols, e.g. via PROFIsafe, are not considered.

• M2X will be fully compatible with the VDA 5050 but it is not a requirement to use M2X.

• The description of the communication is described middleware neutral. Nevertheless, It is assumed that the communication type follows a topic-based publish-subscribe communication.

• FM describes the management, planning, control and monitoring of vehicle fleets. This involves coordinating, evaluating and optimizing vehicle routes, taking into account certain influencing parameters. A FM Service is available for every MR. It can be either centralized or decentralized. Centralized in terms of coordinating the underlying MRs, e.g. VDA 5050. In terms of decentralized planning the MR has an own FM-Service included locally.

• Every M2X interface follows the same structure and is described in the same way:

  • Participants describe themselves with a factsheet.

  • Communication is request-based, meaning that the participant is asked to respond to a request.

  • Requests are communicated with the states: PENDING, RUNNING, PAUSED, COMPLETED, FAILED.

  • There can only be one active request per participant with a peripheral device. This applies to every peripheral device and must be actively monitored by FM. Old requests are deleted by request_cancel. Old open requests can be read from the states after failure.

  • JSON schemas are provided for the factsheets, states and requests.

Figure 1. Overview of the M2X Framework, exemplary interfaces which can be considered.

The scope of M2X is not to operate at the PLC level. Described communication is located on a higher level with logic that manages states of the peripheral and communication processes. Besides that more complex communication protocols with a publish subscribe pattern are used. Hence, M2X assumes that the communication and state management is done by a specialized software, within this document called "Proxy". Depending on the M2X support of the peripheral, several different software solutions for legacy and future peripherals are possible. The following figures show the various solutions for setting up peripheral devices in an MR system with M2X.

Figure 2 illustrates the current status of integrating peripherals into a MR system. Peripherals are typically integrated and controlled by the FM. Hence, the proprietary interface of the peripheral is used and tailored to the costumer.

To overcome this monolithic FM approaches, M2X provides a standardized interface to interact with the peripheral. Thus the FM don’t need to handle and control the peripheral directly. Consequently, the responsibility of the FM is reduced, making the software leaner and more flexible in the event of changes to the system due to the connection of standardized interfaces . Figure 3 shows the implementation for current and legacy systems. Here, logic and the proprietary interface of the peripheral is managed by a proxy. In this case, the proxy must be supplied subsequently, which can be carried out by an integrator, the FM supplier etc. Hereby, the proxy can manage multiple peripherals of the same type from one or different manufacturers. Its also possible to manage different types of peripherals. The complexity is up to the developer and supplier of the proxy.

The aim of standardization should be the direct application of the standard. This means that future peripherals will be directly compatible with the M2X standard. Hence, the manufacturer of the peripheral will implement the M2X standard themselves providing a external proxy for the peripheral or providing an all in one solution (cf. Figure 4). To meet the requirements of Industry 4.0 and its self-management principles, each device will have its own proxy for autonomous communication and management.

Figure 2.

Figure 3.

Figure 4.

2.1. Other applicable documents

document	title
VDA 5050	Interface for the communication between automated guided vehicles (AGV) and a master control
VDI 2510	Automated Guided Vehicle Systems (AGVS)
VDI 2710	Interdisciplinary design of automated guided vehicle systems (AGVS)
VDI 4451	Compatibility of Automated Guide Vehicle Systems (AGVS)
DIN EN ISO 3691-4	Industrial trucks - Safety requirements and verification - Part 4: Driverless industrial trucks and their systems

3. M2X protocol specification

The following section describes the details of the communication protocol. The protocol specifies the communication between the MR/FM and the environment.

The different messages are presented in tables describing the contents of the fields of the JSON that is sent as an request, state, etc.

In addition, JSON schemas are available for validation in the corresponding GitHub repository. The JSON schemas are updated with every release of M2X.

The recommended message protocol is Message Queuing Telemetry Transport (MQTT), which is to be used in conjunction with a JSON structure. MQTT is TCP (Transmission Control Protocol) based and allows the distribution of messages to subchannels, which are called "topics". Participants in the MQTT network subscribe to these topics and receive information that concerns or interests them. Other message protocols can also be used, for example, OPC UA (Open Platform Communications Unified Architecture) or other who are real-time capable over UDP (User Datagram Protocol).

3.1. Symbols of the tables and meaning of formatting

The table contains the name of the identifier, its unit, its data type, and a description, if any.

identification	description
standard	Variable is an elementary data type.
bold	Variable is a non-elementary data type (e.g., JSON object or array) and defined separately.
italic	Variable is optional.
italic and bold	Variable is optional and a non-elementary data type.
arrayName [arrayDataType]	Variable (here arrayName) is an array of the data type included in the square brackets (here the data type is arrayDataType).

All keywords are case sensitive. All field names are in camelCase. All enumerations are in UPPERCASE without underscores.

3.2. Permitted characters and field lengths

All communication is encoded in UTF-8 to enable international adaption of descriptions. The recommendation is that IDs should only use the following characters: A-Z a-z 0-9 _ - . :

A maximum message length is not defined. If an entities memory is insufficient to process an incoming requests, it is to reject the request. The matching of maximum field lengths, string lengths or value ranges is up to the integrator. For ease of integration, vendors must supply a factsheet that is detailed in the corresponfing section.

3.3. Notation of enumerations

Enumerations must be written in upper snake case. This includes keywords such as the states of the actions and requests (RUNNING, COMPLETED, REQUEST_ACCESS, etc…​).

3.4. JSON datatypes

Where possible, JSON data types must be used. A Boolean value is thus encoded by "true / false", NOT with an enumeration (TRUE, FALSE) or magic numbers.

4. General topic structure

Since M2X assumes a publish-subscribe communication, the following topic structure is used:

/interfaceName/majorVersion/uniqueEntityName/topic

Description of the elements:

• interfaceName: Name of the interface (e.g. lhs (load handling station), door, elv (elevator)). The detailed definition of the interface is described in the respective sections.

• majorVersion: Major version of the M2X protocol.

• uniqueEntityName: Unique Name of the Entity (e.g. lhs_dispatch_1, etc.). Besides a human-readable name, a unique identifier like a serial number can also be used.

• topic: The topic of the message (e.g. request, status, factsheet, etc.). Possible topics are defined and described in the respective sections of the entities.

5. Load handling interface

M2X provides communication content and communication processes for the description of load handling/transfer. Communication during load handling can take place between FM and station or MR and station. The MR actively transfers or receives a load to a load handling station. The transfer or receipt of a load is called PICK or DROP, which only refers to the physical process and not an action as in VDA 5050.

Definition of load handling: Load handling refers to the handover of a load at a transfer point or point of interest (PoI). A PoI uses a unique identifier. This includes the entry, the physical handover/manipulation and the exit of an MR at a station. Once the physical load transfer of a MR is in progress, it should not be paused.

Definition load handling station: A load handling station (LHS) serves as a PoI at which the load is transferred or changed/manipulated. The station can have multiple load handling points which are comparable to a VDA 5050 “node”. To avoid confusions regarding the VDA 5050 it is called load handling point. The LHS will provide no traffic management. It is assumed that there is a traffic management that takes care of the coordination of the MRs. Hence, the coordination and deadlock avoidance of the MRs at the different load handling points is managed by the traffic management. Meaning that the station will only manage the interaction areas of the load handling points. The station can decide if a MR can approach a load handling point or not. The LHS factsheet includes the geometry of the physical station (footprint of the station). The area around is managed by the FM.

Definition load handling point: A load handling point (LHP) is a physical point of a LHS where the load is transferred or changed/manipulated. Only one MR can interact with a LHP at the same time. The LHP can be approached from different directions (list of polygons) (cf. Figure 5). A load can be picked up or dropped off by a mobile robot at a LHP. The LHP describes the geometric center of the load for pick-up or delivery. The geometric center of a load is explained in the section Section: Load Handling Unit. The LHP can be considered as reached when the MR is within the interaction area of the LHP. This can be due to the fact that a LHP is physically not reachable by the MR, e.g.

• the load handling device, e.g. fork, of the MR is responsible to hand over the load, meaning that the load reaches the LHP but the MR does not.

• the load is mechanically stripped from the MR to the LHP, meaning that the MR drives through the LHP and the load is stripped off by the movement.

If there are two or more LHPs which share the same interaction area in one station, the interaction area is managed by the corresponding LHS. Maneuvering is only permitted in the interaction area. This area must therefore be planned to be large enough.

The figure below shows an exemplary use case in which two LHPs occur. One station has two LHPs. The outer rectangular frame indicates the station footprint. The black frames represent the two physical LHPs in the environment. The black dots indicate the geometric handover point (see LHS Factsheet .loadHandlingPoints.handoverArea). The red interaction area of the MRs, which can approach the station from both sides (indicated by the arrows). The station only manages itself and blocks the interaction area if necessary (state .loadHandlingPointAvailable). Which MR approaches the station and how is determined for example by a traffic management or another management system. The second figure shows a LHS with a shared traffic management area. The station has two LHPs. As already mentioned it only manages its own LHPs with the corresponding interaction areas. All other passable routes of an MR, even within the station footprint, are controlled by Traffic Management. If two different LHSs share the same interaction area, it is recommended to configure them as one and follow the procedure described above.

Figure 5. Exemplary use case of a LHS with two LHPs

Figure 6. Exemplary use case of a LHS with two LHPs and a shared traffic management area

5.1. Requirements for a M2X load handling station

This section describes the requirements for a LHS to use the M2X protocol. It is assumed that a LHS is an active participant that can actively communicate and manage its status. The following points are requirements that a station must fulfill:

• A LHS is at least represented by a physical area and a software that can handle the status of this area and can communicate with other participants.

• The software of the LHS manages the process and states described in Section: Load Handling Sequence Diagram (e.g. requestAccess, requestExit, requestLoadTransfer, requestRelease …​).

• It has an unique ID and can describe itself via a factsheet.

• Is assigned to an unique position and represents an area in the industrial environment.

• The LHS shall be represented in a global map in the factory coordinate system with its position and dimensions. M2X uses a right-handed coordinate system (z-Axis pointing up).

5.2. Safety considerations for load handling

As already mentioned in the Section: Objective and Scope of M2X there will be no further safety considerations in the protocol. The purpose of the interface is to provide a functional plug & play approach. Safety regarding entries and exits can be abstracted/indirectly set via requirements for the accuracy of the position to be taken (see LHS Factsheet .loadHandlingPoints.handoverArea). Considerations in the communication process for mutings at stations are included and can be taken into account.

5.3. Errors

An error should only be reported if it can no longer be solved by the participant (machine or MR) and needs human intervention. If an error occurs the participant reports errors via the errors array. Errors have two levels: WARNING and FATAL. A WARNING is a self-resolving error, e.g., a field violation. A FATAL error needs human intervention. Errors can pass references that help with finding the cause of the error via the errorReferences array. The implementation is described in the relevant JSON schemas. Any error on the station’s side that cannot be resolved results in a "State Failed" report on the request. The decision lies with the station to determine when an error is fatal and must be reported as failed. Errors that can be resolved, and where the station itself possesses this knowledge, require the station to return the "State RUNNING". Every explicit state response to a request with a "Failed State" from an LHS terminates the process. General state messages with an "ERROR" that do not relate to a state response serve merely as information that interaction with the station is not possible. An already triggered response is not affected by this. Only the direct response triggers a termination.

The sequence of an error during load handling is shown in the following diagram:

Failed to generate image: mmdc failed:
Error: Failed to launch the browser process!
[0704/095358.943591:FATAL:zygote_host_impl_linux.cc(128)] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md. Otherwise see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the (older) SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.


TROUBLESHOOTING: https://pptr.dev/troubleshooting

    at Interface.onClose (file:///opt/hostedtoolcache/node/18.20.8/x64/lib/node_modules/@mermaid-js/mermaid-cli/node_modules/@puppeteer/browsers/lib/esm/launch.js:303:24)
    at Interface.emit (node:events:529:35)
    at Interface.close (node:internal/readline/interface:534:10)
    at Socket.onend (node:internal/readline/interface:260:10)
    at Socket.emit (node:events:529:35)
    at endReadableNT (node:internal/streams/readable:1400:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)


flowchart LR
    start((Start)):::start_end

    request[request]:::request



    lhs_err{LHS error?}
    mr_err{MR error?}
    request_revoke{request is requestRelease?}
    ContinueLoadTransfer[requestContinueLoadTransfer]:::request
    manual_interaction[manual Interaction with MR]




    end_error((End)):::start_end


    classDef request fill:#c1121f,color:#fff
    classDef start_end fill:#03071e,color:#fff
    start-->request
    -->lhs_err--No (COMPLETED) -->
    mr_err--No (COMPLETED) --->
    request_revoke--No (COMPLETED) -->request

    mr_err--Yes (FAILED) -->manual_interaction
    manual_interaction-->ContinueLoadTransfer
    ContinueLoadTransfer-->lhs_err

    lhs_err--Yes (FAILED) -->end_error
    request_revoke--Yes (FAILED) -->end_error

In the event of an error, the diagram runs as follows. The first decision point is the LHS. As soon as the error occurs here, human interaction is required or the error correction is not part of M2X. If the error occurs at the MR, human interaction is required. The actual process can then be resumed with the requestContinueLoadTransfer if the states can be saved. If the error then occurs, the system queries whether the error occurs in the requestRelease. The process only ends when this request is reached.

A error message can include the following information:

• headerId,

• Topic,

• requestId if an error was caused by the request,

• List of parameters if error was caused by erroneous request parameters. If an request cannot be completed because of external factors (e.g. no load at expected position), the requestId should be referenced.

5.4. Load handling unit

The load handling unit (LHU) is the object that is transferred between the MR and the LHS. The LHU is described in the JSON schema Load handling unit. The following assumptions are made for the definition of the coordinate system of the LHU:

• M2X uses a right-handed coordinate system (z-Axis pointing up).

• The origin is in the center of the LHU.

• The X-axis points along the longest side of the LHU.

• The orientation of an LHU is described relative to the coordinate system in which it is currently located, e.g. on an MR or an LHP of an LHS.

• The pose of the LHU is always in the local coordinate system, e.g. MR or LHS. With the transfer requestLoadTransfer, the station is informed that the LHU has been transferred to the station with the following orientation in the coordinate system. The FM, MR or another system is responsible for carrying out a transformation to the station’s target coordinate system.

• The load pose should always have X,Y,Z and theta.

The FM or a comparable system is responsible for creating the necessary transformation chain for transferring an LHU from an MR to an LHS or vice versa. Figure 7 shows an exemplary visualisation of different load orientations. In this example a MR is transferring a LHU to a LHS respectively the LHP. The LHU, LHS and MR are oriented in different ways. The handover of the LHU must take place in a different orientation relatively to the LHP. As soon as the orientation has to be taken into account, the transformation must be performed by an appropriate system.

Figure 7. Exemplary visualisation of different load orientations

Load handling unit describes which parameters the individual unit has and which action is carried out with it.

field	data type	description
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
loadHandlingUnit {	object	Describes all properties of the load handling unit (LHU).
loadUnitId	string	ID number of the LHU.
loadHandlingUnitType	string	Describes the handling unit, e.g. small load carrier, pallet, etc. Important for matching of the handling capabilities of the unit, e.g the request requestLoadTransfer in the load handling interface of a station or MR.
weight	number	Weight of the load.
height	number	Height of the LHU (outer dimensions).
width	number	Width of the LHU (outer dimensions).
length	number	Length of the LHU (outer dimensions).
outerPackaging	string	Describes the outer packaging of the LHU, e.g. wrapping, strapping etc.
symmetrical	boolean	Describes if the orientation of the LHU is symmetrical.
}

5.5. Load handling sequence diagram

The sequence diagram is shown below to describe the load handling process. It is assumed that the MR is the “active” part by leading through the communication sequence with request messages. The station answers accordingly by sending status messages. The communication sequence does not consist of a bi-directly request or status exchange. The states and requests are defined in the corresponding section. Below is a short version of the sequence diagram:

Failed to generate image: mmdc failed:
Error: Failed to launch the browser process!
[0704/095359.507011:FATAL:zygote_host_impl_linux.cc(128)] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md. Otherwise see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the (older) SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.


TROUBLESHOOTING: https://pptr.dev/troubleshooting

    at Interface.onClose (file:///opt/hostedtoolcache/node/18.20.8/x64/lib/node_modules/@mermaid-js/mermaid-cli/node_modules/@puppeteer/browsers/lib/esm/launch.js:303:24)
    at Interface.emit (node:events:529:35)
    at Interface.close (node:internal/readline/interface:534:10)
    at Socket.onend (node:internal/readline/interface:260:10)
    at Socket.emit (node:events:529:35)
    at endReadableNT (node:internal/streams/readable:1400:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)


sequenceDiagram
  participant I as FM/MR
  participant S as Load handling station (LHS)
  I->>S: M2X REQUEST[requestAccess]: MR request for access to the station
  S-->>I: [OPTIONAL] M2X STATUS[requestAccess (State: RUNNING)]: If preparation steps are necessary,<br>the station returns running for the request
  S->>S: [OPTIONAL]: Prepare for entry (mute safety light curtains,<br>open machine protection gates etc.)
  S-->>I: M2X STATUS[requestAccess (State: COMPLETED)]: Station is ready to access
  I->>I: Drive to station load handling point
  I->>S: M2X REQUEST[requestLoadTransfer]: MR has entered the station, reached the load handling point and requests to hand over the load
  S-->>I: [OPTIONAL] M2X STATUS[requestLoadTransfer (State: RUNNING)]: If preparation steps are necessary or<br>safety light curtains must be muted etc.,the station returns running for the request
  S->>S: [OPTIONAL]: Complete MR entry (unmute safety light curtains,<br>close machine protection gates etc.)
  S->>S: [OPTIONAL]: Prepare for load transfer (engage conveyor etc.)
  S-->>I: M2X STATUS[requestLoadTransfer (State: COMPLETED)]: Station granted access to load transfer
  I->>I: Carry out load transfer
  I->>S: M2X REQUEST[requestExit]: MR has finished load transfer and requests to exit the station
  S-->>I: [OPTIONAL] M2X STATUS[requestExit (State: RUNNING)]: If control and/or preparation steps are necessary,<br>the station returns running for the request
  S->>S: [OPTIONAL]: Check the load
  S->>S: [OPTIONAL]: Prepare for exit (mute safety light curtains,<br>open machine protection gates etc.)
  S-->>I: M2X STATUS[requestExit (State: COMPLETED)]: Station is ready to exit
  I->>I: Drive out of station
  I->>S: M2X REQUEST[requestRelease]: MR has left the station and requests to revoke access to the station
  S-->>I: M2X STATUS[requestRelease (State: COMPLETED)]: Station acknowledges the request and is ready for the next access request
  S-->>S: [OPTIONAL]: Unmute safety light curtains,<br>close machine protection gates etc.

There is also a detailed version of the diagram in the repository, which can be found here: detailed sequence diagram. This version differs in that alternative loops are displayed for each request, which cover errors and busy.

5.6. Topics

The communication with a LHS is done via the following topics:

Type	Topic schema	Description
Factsheet	lhs/v1.0.0/lhs_example/factsheet	Used for requesting the factsheet of the LHS.
Request	lhs/v1.0.0/lhs_example/request_*	Used for communication of requests for different load transfer stages: requestAccess, requestLoadTransfer, requestExit, requestRelease, requestFactsheet, requestContinueLoadTransfer, requestCancel
State	lhs/v1.0.0/lhs_example/state	Topic for communicating the current state of the LHS and information about received request messages.

5.7. Load handling JSON schemas and subtopics

The M2X load handling protocol uses the following JSON schemas and subtopics for the communication between station and MR/FM.

type	used for	schema (link)
load handling station factsheet	Self-description of the station, the LHPs and the capabilities.	Schema Link
request	Communication of the requests for the load transfer.	Schema Link
load handling station state	Communication of the state of the load handling station itself.	Schema Link

5.8. Requests

The requests that the FM or MR executes for load handling are described below. All requests, associated parameters and their states are predefined in the respective JSON schemas or tables. If actions, requests or parameters are missing, these can be added after discussion (workshop or git issue) in the current or future version of the standard with non-breaking or breaking changes in the standard. There can only be one active request per participant with a peripheral device. This applies to every peripheral device and must be actively monitored by FM. Old requests are deleted by request_cancel. Old open requests can be read from the states after failure. The following requests are required for complete load handling:

• requestAccess,

• requestLoadTransfer,

• requestExit,

• requestRelease,

• requestFactsheet,

• requestContinueLoadTransfer,

• requestCancel.

For a transport order, the following requests are required:

• requestTransportOrder,

• requestCancel.

The requests cannot be executed multiple times in succession (also known as idempotent). The sequence in the sequence diagram must be taken into account. The requests run through the following states:

state	description
PENDING	The request is pending and has not yet been executed.
RUNNING	The request is currently being executed.
PAUSED	The request is paused. This can be either physical (safety light curtains are not yet released) or management-related.
COMPLETED	The request has been successfully completed.
FAILED	The request could not be completed.

The elements of the corresponding JSON schema are explained in the following table, which includes also the blocking types.

field	data type	description
headerID	uint32	Header ID of the message. The headerId is defined per topic and incremented by 1 with each sent (but not necessarily received) message.
timestamp	string	Timestamp in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ).
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
requests [request] {	array	Describes an request that the entity can perform.
requestType	string	Name of the request as described in the first column of Section: Predefined Requests (LHS). Identifies the function of the request. Enum: requestAccess, requestExit, startLoadHandling, requestFactsheet, requestContinueLoadTransfer, requestCancel, requestTransportOrder.
requestId	string	Unique ID to identify the request and map them to the requestState in the state. Suggestion: Use UUIDs.
requestDescription	string	Additional information on the request.
blockingType	string	Regulates if the request is allowed to be executed during movement and/or parallel to other requests. none: request can happen in parallel with others, including movement. soft: request can happen simultaneously with others, but not while moving. hard: no other requests can be performed while this request is running. Enum: NONE, SOFT, HARD.
requestParameters [requestParameter] {	array	Array of requestParameter-objects for the indicated request e. g. deviceId, loadId, external Triggers.
key	string	The key of the request parameter.
value	array, boolean, number, string, object	The value of the request parameter.
}
}

5.8.1. Predefined requests

The next following two tables describe the predefined requests for the load handling in their parameters and states from RUNNING to COMPLETED.

request	description	parameter	blocking type
requestAccess	MR requests the permission to enter the LHP of the station.	loadHandlingSessionId (string), loadHandlingPointId (string), vehicleType (string), loadAction (enum: PICK, DROP), loadHandlingUnit (object)	HARD
requestLoadTransfer	MR requests to exchange (pick or drop) the load with the station.	loadHandlingSessionId (string)	HARD
requestExit	MR requests the permission to exit the LHP.	loadHandlingSessionId (string)	HARD
requestRelease	MR confirms that the station has been left.	loadHandlingSessionId (string)	HARD
requestFactsheet	Request factsheet from a station.	-	NONE
requestContinueLoadTransfer	MR/Station/FM requests to continue the load transfer.	loadHandlingSessionId (string)	NONE
requestCancel	MR/Station/FM requests to cancel the current request.	loadHandlingSessionId (string)	NONE

request	RUNNING	PAUSED	COMPLETED	FAILED	PENDING
requestAccess	MR/FM requests to enter the LHP of the station, e.g. the station has to mute the safety light curtains, station opens machine protection gates etc.	Request is paused e.g., if a safety light curtain is violated. After removing the violation, the process continues.	Station is ready for load transfer and has carried out all the safety relevant preparatory steps. MR is in the correct position and ready for the load transfer.	Entry can not be granted, e.g. failure during the preparation steps. Failed entry requests should correspond with an error.	Request is waiting to get executed.
requestLoadTransfer	MR requests to transfer or receives a load.	-	Load transfer is done. Load has been successfully transferred or received and station reports new load state.	Load transfer can not be done. Failed load transfers should correspond with an error.	-
requestExit	MR/FM requests to exit the station, e.g. the station has to mute the safety light curtains.	Request is paused e.g., if a safety light curtain is violated. After removing the violation, the process continues.	The station authorizes the exit once all load transfer steps have been completed from the station’s perspective.	Exit can not be granted, e.g. failure during load transfer. Failed exit requests should correspond with an error.	-
requestRelease	MR/FM revokes the occupancy of the station. MR has left the station.	-	Station confirms the revoke of the access and is ready for the next access.	Revoke can not be done. Failed revoke requests should correspond with an error.	-
requestFactsheet	-	-	-	-	-
requestContinueLoadTransfer	MR/Station/FM requests to continue the load transfer.	-	Load transfer is continued.	Load transfer can not continued. Failed continues should be repeated until the sequence is at request requestRelease. After that the error is ended.	-
requestCancel	MR/FM requests to cancel the current request.	-	Request can not be canceled.	Request can not be canceled.	-

5.9. Load handling station state

The following section describes the states of the load transfer between the LHS and the MR. The status messages for running, paused, completed and failed are specified here for the requests (requestAccess, requestExit, requestLoadTransfer, requestRelease and requestFactsheet, requestContinueLoadTransfer, requestCancel). For the definitions of the content, see Section: Predefined Requests (LHS). The sequences for the load handling are described in the section load handling sequence diagram. The upcoming table describes the JSON file and its contents. It is assumed that the LHS sends a new state message at least every 30 seconds. A state message has to be sent on every internal state change, e.g. changing an operation state of a request from RUNNING to PAUSED. After sending a new state message, the message timer is reset to 30 seconds. The status depends on the request performed. It can also be queried whether the LHP is available or not.

field	data type	description
timestamp	string	Timestamp in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ).
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
serialNumber	string	Serial number of the LHS.
manufacturer	string	Manufacturer of the LHS.
loadHandlingStationAvailable	boolean	Indicates if the LHS is available for operation.
loadHandlingPointStates [loadHandlingPointState] {	array	Describes upcoming and current requests.
loadHandlingPointId	string	Unique identifier of the LHS.
operatingMode	string	Current operating mode of the LHS. Enum AUTOMATIC, MANUAL, SERVICE.
loadHandlingPointAvailable	boolean	SIndicates if the LHP is available for operation.
loadHandlingSessionId	string	Unique identifier of the complete request session in a process, e.g. the load handling.
requestStates [requestState] {	array	Array of upcoming and current requests.
requestId	string	Unique requestId.
requestType	string	requestType of the request.
requestStatus	string	Status of the request.
requestDescription	string	Description of the result, e.g., the result of a RFID-read. Errors will be transmitted in errors.
}
}
errors [error] {	array	Array of error-objects. All active errors of the LHS should be in the list. An empty array indicates that the LHS has no active errors.
errorType	string	Type of error.
errorReferences [errorReference] {	array	Object that holds the error reference to requests as key-value pairs.
referenceKey	string	References the type of reference (e.g., headerId, requestId, etc.).
referenceValue	string	References the value, which belongs to the reference key.
}
errorDescription	string	Verbose description of error.
errorLevel	string	Description of the error level, which is warning or fatal. WARNING: Station is ready to start (e.g., maintenance cycle expiration warning). FATAL: Station is not in running condition, user intervention required (e.g., laser scanner is contaminated).
}

5.10. Load handling station factsheet

A factsheet is provided for the self-description of the load handling station. The factsheet provides basic information about the station. Whoever configures and edits the factsheet must be documented within the project. It describes the station overall as well as the different LHPs and their capabilities. This enables self-configuration in the system context. Each LHS has one factsheet. The factsheet includes at least one LHP. The factsheet is intended both as a human-readable document and for machine processing and is therefore specified as a JSON document. The FM or the MR can request the factsheet from the station at any time. The corresponding request is described in the Section: Predefined Requests (LHS).

Topic for the request: lhs/v1/stationId/requestFactsheet Topic for the response: lhs/v1/stationId/factsheet

It is also to be noted that a MR has to request all available factsheets from the stations in order to navigate without colliding or interfere with any station geometry (exclusive managed area of a LHS) of a LHS.

5.10.1. Factsheet JSON structure

The factsheet consists of the JSON-objects listed in the following table.

field	data type	description
timestamp	string	Timestamp in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ).
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
manufacturer	string	Manufacturer of the station.
serialNumber	string	Serial number of the station.
stationGeometry	JSON-object	These parameters generally specify the geometry of the station.
loadHandlingPoints[loadHandlingPoint]	array	These parameters generally specify the class and the capabilities of the load handling points (LHPs) of a load handling station.

stationGeometry

This JSON-object describes the geometry of the station.

field	data type	description
position {	object	Position of the station in the factory-coordinate system.
x	number	The x-position in factory-coordinate system.
y	number	The y-position in factory-coordinate system.
z	number	Z-position in factory-coordinate system.
}
stationFootprint {	object	Describes the footprint and orientation of the station in the factory-coordinate system.
x-left	number	x-left offset of the door.
x-right	number	x-right offset of the door.
y-left	number	y-left offset of the door.
y-right	number	y-right offset of the door.
theta	number	Orientation of the door in the factory coordinate system.
}
numberLoadHandlingPoints	number	Total number of LHPs at the station.

loadHandlingPoint

This JSON-object describes the individual load handling point (LHP) with all its capabilities.

field	data type	description
loadHandlingPointId	string	ID number of the LHP.
stationClass	string	Simplified description of station class.
isLoadHandlingActive	boolean	True: LHP can actively (independently) pick and drop goods from or to the MR.
doubleCycleAbility	boolean	True: It may be necessary to carry out double cycles at the LHP.
loadUnitTypes [loadUnitType] {	array	List of all loading units that can be handled at the LHP, for example europallet, industrypallet, GMA-pallet, mesh_box, small_load_carrier, barrel, special_load_carrier. If this parameter does not exist or is empty, the LHP is valid for all load unit types on this station.
unitType	string	List of all load units.
handlingAcceleration	number	Maximum allowed acceleration for this load-type and –weight.
parallelSequence	string	Describes if the LHP can manage more than on load in the ongoing load transfer.
}
maxLoadDimensions [maxLoadDimension] {	array	Maximum dimensions that can be processed by the LHP.
length	number	Maximum loadable length of the good.
width	number	Maximum loadable width of the good.
height	number	Maximum loadable height of the good.
mass	number	Maximum loadable mass of the good.
}
positioningAids [positioningAid]	array	Simplified description of localization type.
pose {	JSON-object	Pose of the load handling point (LHP) for load handling.
x	number	X-position in factory-coordinate system.
y	number	Y-position in factory-coordinate system.
z	number	Z-position in factory-coordinate system.
theta	number	Angle for handover pose.
}
tolerance {	object	Acceptable tolerance for the load handling.
x-left	number	x-left offset of the door.
x-right	number	x-right offset of the door.
y-left	number	y-left offset of the door.
y-right	number	y-right offset of the door.
theta	number	Orientation of the door in the factory coordinate system.
}
}
loadHandlingRequests [loadHandlingRequest]	array	Simplified description of possible load handling actions.
physicalParameters {	JSON-object	These parameters specify the basic physical properties of the LHP.
speedMin	number	Minimal controlled continuous speed of the LHP.
speedMax	number	Maximal controlled continuous speed of the LHP.
accelerationMax	number	Maximum possible acceleration for this LHP.
decelerationLimit	number	Maximum possible deceleration for this LHP.
height	number	Height of the LHP.
width	number	Width of the LHP.
length	number	Length of the LHP.
requiredHandoverHeight	number	Required height for handing over the load from MR to LHP.
pickTime	number	Approx. time for picking up the load.
dropTime	number	Approx. time for dropping the load.
}
restrictedInteractions [restrictedInteraction] {	array	These parameters specify the restricted interactions with the LHP.
restrictedVehicles [restrictedVehicle]	array	List of all MRs that are not allowed to interact at the LHP. If this parameter does not exist or is empty, the LHP is valid for all MRs on this station.
restrictedLoads[restrictedLoad]	array	List of all loads that are not allowed to interact at the LHP. If this parameter does not exist or is empty, the LHP is valid for all MRs on this station.
}

6. Transport order interface

M2X provides communication content and communication processes for the description of transport orders (TOs).

Definition transport order: The TO enables a MR to move goods from a designated source location to a specified destination location. With the TO a MR can perform the following actions: PICK, DROP, VIA. PICK and DROP is the physical transfer of goods. VIA is a PoI that the MR passes through to reach a desired PoI location or to wait there. The TO contains of a collection of objectives that can be extend during the execution of a TO. An objective is a description of an atomic transport step (WHAT and WHERE), e.g. PICK 'Pallet 1' and DROP it at 'storage location 5'. A TO shall contain at least one objective. The example above shows a transport order with two objectives. Orders are defined with the JSON schemas request transport order. State changes to the transport order are communicated via the JSON schema transport order state. A TO has a unique transportOrderId and can be updated using the transportOrderUpdateId of the transport order messages. With isObjectiveListComplete, the end of the TO can be marked.

The following figure shows the context in which layer the M2X protocol is used: The M2X TO interface communicates with the upper layer system. This can be an ERP, a WMS, a manual order generation (for example with a button push at a station) etc.

Failed to generate image: mmdc failed:
Error: Failed to launch the browser process!
[0704/095400.007869:FATAL:zygote_host_impl_linux.cc(128)] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md. Otherwise see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the (older) SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.


TROUBLESHOOTING: https://pptr.dev/troubleshooting

    at Interface.onClose (file:///opt/hostedtoolcache/node/18.20.8/x64/lib/node_modules/@mermaid-js/mermaid-cli/node_modules/@puppeteer/browsers/lib/esm/launch.js:303:24)
    at Interface.emit (node:events:529:35)
    at Interface.close (node:internal/readline/interface:534:10)
    at Socket.onend (node:internal/readline/interface:260:10)
    at Socket.emit (node:events:529:35)
    at endReadableNT (node:internal/streams/readable:1400:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)


flowchart TD
    id1[ERP]
    id2[WMS]
    id3[Manual order generation]
    id4{{Order assignment to FM or MR}}
    id1-- M2X transport order -->id4
    id2-- M2X transport order -->id4
    id3-- M2X transport order -->id4
    id5[FM]
    id6[1-n MR]
    id4-->id5
    id4-->id6
    id7[MR 1]
    id8[MR 2]
    id9[MR X]
    id5-->id7
    id5-->id8
    id5-->id9

6.1. Requirements for a M2X transport order

This section describes the requirements for the TO interface in the M2X protocol:

• The TO shall be composed of objectives.

• The TO shall have at least one objective.

• The TO shall only support single carrier transportation.

• An objective shall be a combination of WHAT and WHERE.

• The WHERE shall be uniquely identifiable.

• The WHERE identifier shall be a string identifier.

• The FM shall allow for the WHERE to be a PoI or group of PoIs.

• The WHERE identifiers shall be agreed on by the upper layer system and FM.

• The WHERE shall be resolved to the corresponding resource by the FM.

• The objective shall support the WHATs PICK, DROP and VIA.

• The TO shall support delayed decisions (VIA point) for PICK and DROP.

• The TO shall be closed by the upper layer system, indicated by parameter isObjectiveListComplete in TO update.

• The FM shall determine when an objective is finished.

• The upper layer system shall be allowed to attempt to modify the WHAT and WHERE of an objective by TO updates.

• The upper layer system shall be allowed to attempt to cancel an objective.

• The FM shall be allowed to reject updates or cancellations to objectives.

• The upper layer system shall be able to cancel a TO.

• A cancelled TO shall be marked as isCancelled in the transport order state.

• The request pattern shall be used for the interaction between upper layer system and FM.

• The FM shall decide whether to accept or decline a request.

• The LHU shall be defined for the WHAT when PICK action has to be performed.

• The order shall be marked as finished if the WHAT is transported to the WHERE or an alternative process in the TO receiving system was executed successfully. In case an alternative process was used, a WARNING can be added in the error array, e.g. referencing/reporting the alternative WHERE.

• Every objective shall have a unique sequenceId that defines the order of execution of all objectives. The sequenceId shall be strictly sequential increasing.

6.2. Errors

If an error occurs within the TO it shall be reported via the errors array. Errors have two levels: WARNING and FATAL. A WARNING is a self-resolving error during TO execution, e.g., a field violation at the load handling. A FATAL error needs human intervention. Errors can pass references that help with finding the cause of the error via the errorReferences array. For TO errors, the predefined enums should be used for the errors types.

6.2.1. Predefined Errors

error type	error level	description	parameter
OBJECTIVE_ALREADY_COMPLETED	WARNING	The objective is already completed. The objectiveId was already used beforehand and is not valid for updates anymore.	objectiveId (string)
OBJECTIVE_IN_EXECUTION	WARNING	The objective is already in execution and cannot be updated anymore.	objectiveId (string)
SEQUENCE_ID_NON_CONTIGUOUS	WARNING	The sequenceId is non-contiguous. A sequenceId shall be used which links directly to the previous objective or updates an already used sequenceId.	sequenceId (integer)
ERROR_DURING_EXECUTION	WARNING or FATAL	The objective is not executed correctly. The error can be a WARNING or FATAL. The error can be caused e.g. by the MR or the LHS. It can be caused by an external factor (e.g. no load at expected position). The error can also be caused by an error on FM site e.g. given WHAT and WHERE are unknown. In this case, its up to the FM that these changes are not allowed which results in throwing an error. The selection of the error type is up to the system and can e.g. be forwarded from previous errors.	action (string), objectiveId (string)
ERROR_IN_VALIDATION	WARNING or FATAL	When validating the data in the TO, inconsistent information can cause an error. The validation of information is not part of M2X, so the decision on the logic throwing an error lies with the FM. The error can e.g. be used to indicate changing resourceIds / priorities during transport order updates or different LHU Ids between a PICK and DROP action. In case this error occurs its recommended to cancel the TO with a requestCancel.	action (string), objectiveId (string)

6.3. Topics

The communication for TOs is done via the following topics:

type	topic schema	description
Transport order	order/v1.0.0/fm_or_mr_example/request_transport_order	Used for describing the order.
Transport order state	order/v1.0.0/fm_or_mr_example/request_transport_order_state	Topic for communicating the current state of the order and information about received order messages.

6.4. Transport order JSON schemas and subtopics

The M2X TO interface uses the following JSON schemas and subtopics for the communication.

type	used for	schema (link)
transport_order	JSON Schema for transport order description.	Schema Link
transport_order_state	JSON Schema for state of a transport order.	Schema Link

6.5. Requests

The requests that upper layer system executes for creating transport orders are described below. All requests, associated parameters and their states are predefined in the respective JSON schemas or tables. There can only be one active request per participant with a peripheral device. This applies to every peripheral device and must be actively monitored by FM. Old requests are deleted by request_cancel. Old open requests can be read from the states after failure.

The following request are required for creating and updating transport orders:

• requestTransportOrder,

• requestCancel.

6.5.1. Predefined requests

The next following two tables describe the predefined requests for the load handling in their parameters and states from RUNNING to COMPLETED.

request	description	parameter	blocking type
requestTransportOrder	Upper layer system creates or updates a transport order.		NONE
requestCancel	MR/Station/FM requests to cancel the current request. A request is cancelled if isCancelled (in transport_order_state.schema) is set to true.	transportOrderId (string), isCancelled (boolean)	NONE

request	RUNNING	PAUSED	COMPLETED	FAILED	PENDING
requestTransportOrder	Upper layer system requests a transport order.	-	Transport order is completely and successfully executed.	Transport order can not be executed.	-
requestCancel	MR/FM requests to cancel the current request.	-	Request can not be canceled.	Request can not be canceled.	-

requestTransportOrder JSON structure

The TO contains of a collection of objectives that can be extend during the execution of a TO. A TO shall contain at least one objective. An objective is a description of an atomic transport step (WHAT and WHERE), e.g. transport 'Pallet 1' to 'storage location 5'.

Example of the transport order schema:

field	data type	description
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
timestamp	string	Timestamp in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ). The timestamp defines the point in time at which the message was sent.
transportOrderId	string	Transport order (TO) identification. This is to be used to identify multiple transport order messages that belong to the same transport order. The orderId is kept until a new order is received.
transportOrderUpdateId	integer	transportOrderUpdate identification. Is unique per transportOrderId. If an transport order update is rejected, this field is to be passed in the rejection message. '0' is the initial transport order. The transportOrderUpdateId is increased by one for each transport order update for the same transportOrderId. If a gap is identified by the TO receiving system in the sequence of transportOrderUpdateIds, the transport order update with the highest id shall be considered as the valid and. In case an transport order update with a lower or equal transportOrderUpdateId is received from the TO receiving system, the transport order update shall be reject. minimum: 0.
isObjectiveListComplete	boolean	Indicates if the list of objectives is complete. If set to true, the list of objectives is complete and no further objectives or updates will be added to the transport order. default: false.
resourceId	string	Unique identifier of the resource, e.g. ID of the mobile robot, that shall execute the transport order. In case the resourceId is set, the transport order is only valid for the specified resource. If the resourceId is unknown the order receiving system shall decline the transport order. If the resourceId is not set, the transport order is valid for all resources.
priority	string	Priority of the TO. Enum: VERY_LOW, LOW, MEDIUM, HIGH, VERY_HIGH.
objectives [objective] {	array	Defines a location where an action is to be performed by the transporting MR. The array has to contain at least one objective.
objectiveId	string	Unique objective identification.
sequenceId	integer	Number to track the sequence of objectives in an transport order and to simplify order updates. The main purpose is to distinguish between an objective which is passed more than once within one TO (same transportOrderId). The variable sequenceId runs across all objectives of the same transport order and is reset when a new transportOrderId is issued. To update an objective, the sequenceId of the objective to be updated has to be provided. The objective update replaces all following objectives starting from the sequenceId. The sequenceId shall be strictly sequential increasing. minimum: 0.
destination	string	Defines the position (WHERE) a defined action is to be performed. Uniquely point of interest (POI) id (e.g. of an LHP or a LHS).
action	string	Action to be performed at the destination (WHAT). Enum: PICK, DROP, VIA.
displayName	string	Human readable name of the objective.
loadHandlingUnit	object	Description of the load, e.g. id, dimensions, weight etc. For further information see load_handling_unit.schema
earliestCompletionTime	string	Earliest completion time of the objective in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ). Describes when the objective can be completed at the earliest.
latestCompletionTime	string	Latest completion time of the objective in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ). Describes when the objective has to be completed at the latest.
}

6.6. Transport order state

The following section describes the states of the TO. It defines the status messages for the transportOrder, their updates and the end of the TO.

6.6.1. Transport order state JSON structure

The TO state consists of the JSON-objects listed in the following table.

field	data type	description
version	string	Version of the M2X protocol [Major].[Minor].[Patch] (e.g. 1.3.2).
timestamp	string	Timestamp in ISO8601 Format (YYYY-MM-DDTHH:mm:ss.sssZ). The timestamp defines the point in time at which the message was sent.
transportOrderId	string	Unique transport order identification of the current transport order or the previous finished transport order. The transportOrderId is kept until a new transport order is received. Empty string (\"\") if no previous transportOrderId is available.
transportOrderUpdateId	integer	Transport order update identification to identify that an transport order update has been accepted by the FM or MR. \"0\" if no previous transportOrderUpdateId is available.
lastObjectiveId	string	lastObjectiveId of last reached objective or, if MR is currently on an objective, current objective (e.g., \"objective\"). Empty string (\"\") if no lastObjectiveId is available.
resourceId	string	Unique identifier of the resource, e.g. ID of the mobile robot, that shall execute the transport order. In case the resourceId is set, the transport order is only valid for the specified resource. If the resourceId is unknown the order receiving system shall decline the transport order. If the resourceId is not set, the transport order is valid for all resources.
priority	string	Priority of the TO. Enum: VERY_LOW, LOW, MEDIUM, HIGH, VERY_HIGH.
isCancelled	boolean	Indicates whether the transport order is cancelled or not. If true, the transport order is cancelled and no further objectives are to be executed.
objectiveStates [objectiveState] {	array	Array of objectiveStates, that need to be traversed for fulfilling the TO. Empty list if idle.
objectiveId	string	Unique objective identification.
sequenceId	integer	Number to track the sequence of objectives in an transport order and to simplify order updates. The main purpose is to distinguish between an objective which is passed more than once within one TO (same transportOrderId). The variable sequenceId runs across all objectives of the same transport order and is reset when a new transportOrderId is issued. To update an objective, the sequenceId of the objective to be updated has to be provided. The objective update replaces all following objectives starting from the sequenceId. The sequenceId shall be strictly sequential increasing.
destination	string	Defines the position (WHERE) a defined action is to be performed. Uniquely point of interest (POI) id (e.g. of an LHP or a LHS).
action	string	Action to be performed at the destination (WHAT). Enum: PICK, DROP, VIA.
displayName	string	Human readable name of the objective.
loadHandlingUnit	object	Description of the load, e.g. id, dimensions, weight etc. For further information see load_handling_unit.schema
estimatedCompletionTime	string	Estimated completion time of the objective in ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ).
}
errors [error] {	array	Array of error-objects. All active errors of the order should be in the list. An empty array indicates that the LHS has no active errors.
errorType	string	Type of error. Enum: OBJECTIVE_ALREADY_COMPLETED, OBJECTIVE_IN_EXECUTION, SEQUENCE_ID_NON_CONTIGUOUS, ERROR_DURING_EXECUTION.
errorReferences [errorReference] {	array	Object that holds the error reference to requests as key-value pairs.
referenceKey	string	References cause of the error (e.g. objectiveId and sequenceId of the TO).
referenceValue	string	References the value, which belongs to the reference key.
}
errorDescription	string	Verbose description of error.
errorLevel	string	Description of the error level, which is WARNING or FATAL.
}

7. List of abbreviations

abbreviation	description
AGV	Automated guided vehicle
AMR	Autonomous mobile robot
FM	Fleet management
LHP	Load handling point
LHS	Load handling station
LHU	Load handling unit
M2X	Machine to X
MC	Master control
MR	Mobile robot
PoI	Point of interest
TO	Transport order
VDA	Verband der Automobilindustrie (Association of the Automotive Industry)
VDI	Verein Deutscher Ingenieure (Association of German Engineers)
VDMA	Verband Deutscher Maschinen- und Anlagenbau e. V. (German Association of Mechanical and Plant Engineering e. V.)

8. Glossary

term	description
Fleet management (FM)	Also known as master control (MC). FM describes the management, planning, control and monitoring of vehicle fleets. This involves coordinating, evaluating and optimizing vehicle routes, taking into account certain influencing parameters. A FM Service is available for every MR. It can be either centralized or decentralized. Centralized in terms of coordinating the underlying MRs, e.g. VDA 5050. In terms of decentralized planning the MR has an own FM-Service included locally.
Load handling	Load handling refers to the handover of a load at a transfer point or point of interest. This includes the entry, the physical handover/manipulation and the exit of an MR at a station. Once the physical load transfer of a MR is in progress, it should not be paused.
Load handling point (LHP)	A load handling point is a physical point of a LHS where the load is transferred or changed/manipulated. Only one MR can interact with a LHP at the same time. The LHP can be approached from different directions.
Load handling station (LHS)	A load handling station serves as a point of interest at which the load is transferred or changed/manipulated. The station can have multiple LHPs which are comparable to a VDA 5050 “node”. To avoid confusions regarding the VDA 5050 it is called LHP. The LHS will provide no traffic management. The station will only manage itself. The LHS factsheet includes the geometry of the physical station (footprint of the station). The area around is managed by the FM or traffic management.
Load handling unit (LHU)	The load handling unit (LHU) is the object that is transferred between the MR and the LHS.
Mobile robot (MR)	Uniform collective term in the context of M2X for all types of vehicles/robots that use the protocol. This includes for example automated guided vehicles (AGVs) or autonomous mobile robots (AMRs).
Point of interest (PoI)	A point of interest is a virtual or physical space in the environment. A unique identifier is used. At the PoI, the MR can perform actions such as PICK, DROP or VIA. A PoI can also be used to provide coordinates of the location, for example. A LHS or LHP can also be a PoI. A PoI can also be a group of PoIs.
Transport order (TO)	The TO contains of a collection of objectives that can be extend during the execution of a TO. A TO shall contain at least one objective. An objective is a description of an atomic transport step (WHAT and WHERE), e.g. transport 'Pallet 1' to 'storage location 5'.
Upper layer system	The upper layer system is the next higher system to M2X in communication. This can be an ERP, a WMS, a manual order generation (for example with a button push at a station) etc.