ISO 21423:2026

• Abstract:

  To facilitate interoperability in a shared industrial environment, this document specifies the requirements for communication between two or more of the following: industrial mobile robot (IMR); IMR fleet manager (IMRFM); other machines, equipment, and applications in the shared industrial environment (e.g. machines tended by the IMRs; enterprise resource planning (ERP) tools; and building infrastructure such as lifts, alarm systems, automated doors). For the purposes of this document, “industrial environment” describes a workplace where the people are working-age adults and the public is restricted from access or not reasonably expected to be present. Further, “industrial” pertains to the production of goods and related services (e.g. manufacturing, laboratory, pharmaceutical, warehousing, distribution, logistics and other workplaces). The following applications are excluded from the scope of this document: entertainment, consumer, military, medical and use on public roads. This document is not safety-related; there are no safety requirements. Navigation requirements are excluded from the scope of this document.

• Status: Published
• Publication Date: 13-Oct-2026
• ICS: 25.040.30 - Industrial robots. Manipulators
• ICS: 35.240.50 - IT applications in industry
• Technical Committee: ISO/TC 299 - Robotics
• Drafting Committee: ISO/TC 299 - Robotics
• Current Stage: 6060 - International Standard published
• Start Date: 14-Oct-2026
• Completion Date: 14-Oct-2026

ISO 21423:2026 is an ISO standard for communications and interoperability of industrial mobile robots (IMRs) in shared industrial environments. It specifies how IMRs, IMR fleet managers (IMRFMs), and related machines and building systems exchange identity, capability, location, status, and request data so different vendors and systems can work together. It is aimed at robot vendors, fleet software developers, system integrators, and industrial users who need a common messaging and data model, not a safety or navigation standard.

What does ISO 21423:2026 specify?

ISO 21423:2026 specifies the communication requirements needed to share IMR information in an industrial environment and to exchange requests between two or more entities such as an IMR, an IMRFM, other machines, and building infrastructure. The scope includes manufacturing, laboratory, pharmaceutical, warehousing, distribution, logistics, and similar workplaces where public access is restricted.

ISO 21423:2026 excludes entertainment, consumer, military, medical, and public-road uses. It is explicitly not safety-related, and navigation requirements are outside its scope.

The document is organized into clauses on scope, references, terms, the common coordinate system, IMR identity and capability, IMR location and status, IMRFM identity and capability, IMRFM state, request messages, and messaging protocol and formats. The annexes then define the JSON schema, MQTT topic and message structure, request-message details, and an informative method for calibration to a location point.

Annex	What it covers
Annex A	Normative JSON schema and custom JSON object definitions
Annex B	Normative MQTT topics, topic layout, versioning, QoS guidance, and examples
Annex C	Normative request messages, request handling, and state transitions
Annex D	Informative calibration to location point, including shared-coordinate examples

What are the key requirements of ISO 21423:2026?

Common coordinate system and location data

ISO 21423:2026 requires all IMRFs operating in the same physical space to use the same common coordinate system (CCS) (Clause 4). At least three reference points are needed to establish the CCS, and they must be measured in meters, distributed across the area, and placed on a horizontal plane, with higher-dimensional features projected down into that plane.

In practice, this means different robots and fleet managers can translate their own local maps into one shared facility coordinate frame. Clause 4 also requires local maps to include points matching at least three reference points, and all maps must use the same UUID for each reference point in line with ISO/IEC 9834-8.

Clause 4 and Table 1 to Table 3 also define the data fields used for the CCS, reference points, and location points. Location points include x, y, and z, with z relative to the ground of the referenced CCS, so systems can report floor level and vertical offset in a consistent way.

IMR identity and capability

Clause 5 requires an IMR to publish its identity and capability information on start-up or when the information changes. The required content includes an IMR UUID, timestamp, entity type, manufacturer name, capability object, model, serial number, footprint, working area, maximum height, and software versions.

This matters because integrators need to know what the robot is, what it can do, and how large it is before they can use it safely and consistently in a shared area. Clause 5 also says that if the IMR cannot detect or report changes to footprint, working area, height, speed, or payload, the maximum value shall be communicated.

Clause 5 further defines several recommended and optional items such as priority, rated speed, charger types, support contacts, thumbnail image, rated load, payload types, battery type, and additional properties. These fields help buyers and integrators compare equipment and link it to support data and deployment-specific attributes.

IMR location, status, and IMRFM state

Clause 6 requires IMR location and status information to be published according to the document’s messaging structure. The clause highlights operating mode, operating state, and required status data so receiving systems can visualize robot position and support traffic management.

For an IMRFM, Clause 7 requires identity and capability information to be provided on start-up or change, using the same general pattern as the IMR. Clause 8 then requires the IMRFM state to be shared with other IMRs, IMRFMs, and related systems so receivers know whether the manager is ready, not ready, or offline.

In practice, these messages let other systems decide whether to send requests, whether to expect responses, and how to react if the fleet manager is unavailable. Clause 8 also requires the state message to be sent when the relevant state information changes, not as a periodic broadcast.

Request messages and state handling

Clause 9 requires IMRs and IMRFMs to be able to send and receive request messages and requestStatus messages. IMRs or IMRFMs that can report location must also support move, pauseImr, resumeImr, and cancel messages.

The request flow is state-based: a sender issues a request to an identified receiver, the receiver updates requestStatus when the request state changes, and the final status indicates CANCELED, SUCCEEDED, or ABORTED. This is useful for controlled actions such as moving, docking, pausing, or canceling work without requiring a vendor-specific control interface.

Clause 9 also says requestStatus updates shall be sent only when state changes and shall not be periodic. The protocol shall support non-interruptible delivery quality of service so the status trail remains reliable during execution.

Messaging protocol, JSON, and MQTT

Clause 10 requires all messages to use a standard communication protocol in accordance with ISO/IEC 20922 and JSON in accordance with ISO/IEC 21778. The JSON schema is defined in Annex A, and the message formats are defined in Annex B and Annex C.

This matters because implementers need both transport rules and data structure rules to achieve interoperability. Clause 10 also points implementers to best practices for cybersecurity and authentication in IEC 62443 or IEC 27001.

What terms does ISO 21423:2026 define?

• Industrial mobile robot (IMR) - A mobile platform that can navigate and operate in an industrial environment to reach a specified location or cover a specified area, including any integrated attachments.
• Industrial mobile robot fleet (IMRF) - One or more IMRs that are collectively managed.
• Industrial mobile robot fleet manager (IMRFM) - Software that monitors and directs one or more IMRFs, including functions such as monitoring status, coordinating actions, order management, data synchronization, charging, parking, and traffic management.
• Common coordinate system (CCS) - The shared coordinate system used to communicate locations across robots and fleet managers in the same facility.
• Reference point - A coordinate relative to the CCS origin point that can be used to align local maps with the shared CCS.
• Location point - An IMR origin point expressed relative to the CCS origin point at a moment in time.
• Pose - The combination of position and orientation in space.
• Odometry - The combination of pose, linear velocity, and angular velocity.

Who uses ISO 21423:2026?

ISO 21423:2026 is used by IMR manufacturers, IMRFM developers, robotics integrators, and automation engineers who need different robots or systems to exchange data in a shared facility. It is also relevant to warehouse, logistics, distribution, manufacturing, laboratory, and pharmaceutical operations that run mobile robots alongside other machines and infrastructure.

In practice, users apply it to:

• define a shared CCS for a site
• publish robot identity, dimensions, and capabilities
• exchange location and state data for visualization and traffic management
• implement request handling for actions such as move, pause, resume, cancel, or docking
• connect robots with ERP tools, lifts, doors, alarm systems, and similar equipment

Which standards are used with ISO 21423:2026?

ISO 21423:2026 depends on several standards for its terminology, data representation, and transport:

• ISO 8373 - Provides robotics vocabulary used for terms and definitions.
• ISO 8601-1 - Defines the date and time format used for timestamps.
• ISO/IEC 9834-8 - Covers UUID generation and use, which supports CCS and reference-point identification.
• ISO 16100-1 - Provides the manufacturing software capability profiling framework used for capability-related terminology and structure.
• ISO/IEC 20922 - Defines MQTT, the communication protocol used for message exchange.
• ISO/IEC 21778 - Defines JSON, the message syntax used in the schema and message bodies.
• IEC 27001 - Named in the document as a cybersecurity and authentication reference point for best practice.
• IEC 62443 - Also named in the document as a cybersecurity and authentication reference point for best practice.

What does the ISO 21423:2026 document contain?

ISO 21423:2026 contains tables that define the fields for the CCS, reference points, location points, IMR identity and capability, IMRFM identity and capability, and IMRFM state. It also contains JSON object definitions for items such as Point, SoftwareVersion, Capabilities, SupportVendorContactInformation, BatteryStatus, LocalTrajectory, GlobalPath, GlobalPlan, and AdditionalProperty.

Annex B provides MQTT topic layout, topic overview, entity interaction rules, versioning guidance, retained and streaming topic behavior, session rules, and examples. Annex C provides request-message protocol details, request status handling, concurrency options, state transition diagrams, and message examples, including use cases.

Annex D gives an informative calibration method for mapping local robot coordinates to the CCS, with scenarios and figures showing how multiple local maps can be aligned in one facility.

International
Standard
ISO 21423
First edition
Robotics — Industrial mobile
2026-10
robots — Communications and
interoperability
Robotique — Robots mobiles industriels — Communications et
interopérabilité
Reference number
© ISO 2026
All rights reserved.
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued by ISO,
an ISO member body, or an authorized third-party distributor.
Except as required for implementation or expressly permitted by a separate licence, no part of this ISO publication may be
reproduced, distributed, modified, used, or made available in any form or by any means – electronic or mechanical, including
photocopying, scanning, recording, or posting on internal or external digital platforms.
Any use beyond the scope of the granted rights is prohibited and may result in legal action.
ISO copyright office
CP 401 • CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms and definitions .2
3.2 Abbreviated terms .5
4 Common coordinate system (CCS) . 6
4.1 General .6
4.2 CCS fields .6
4.3 Reference point fields .6
4.4 Location point fields .7
5 Industrial mobile robot identity and capability . 7
6 Industrial mobile robot location and status . 9
6.1 General .9
6.2 Operating mode and operating state .9
6.3 Required status data .10
7 Industrial mobile robot fleet manager identity and capability .11
8 Industrial mobile robot fleet manager state .12
9 Request messages .12
10 Messaging protocol and message formats .13
10.1 General . 13
10.2 Messaging protocol . 13
10.3 Message format . 13
Annex A (normative) JSON schema . 14
Annex B (normative) Topics and message format.38
Annex C (normative) Request messages .58
Annex D (informative) Calibration to location point .82
Bibliography .85

iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 299, Robotics.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
Introduction
As industrial mobile robots are increasingly used in industrial environments, there is a growing need for
industrial mobile robots (IMRs) from single or multiple vendors to operate in the same area, regardless
of vendor or model. Navigation and safety-related aspects of IMRs and IMR fleet(s) are not covered in this
document. This document can enable different fleets to work more effectively, by sharing information
about the location, speed, direction, condition(s), availability and other characteristics of the IMRs, and by
requesting actions. The communication protocols in this document can also enable IMRs and IMR fleets to
exchange data with other equipment and systems, e.g. alarm systems, lifts and doors.

v
International Standard ISO 21423:2026(en)
Robotics — Industrial mobile robots — Communications and
interoperability
1 Scope
To facilitate interoperability in a shared industrial environment, this document specifies the requirements
for communication between two or more of the following:
— industrial mobile robot (IMR);
— IMR fleet manager (IMRFM);
— other machines, equipment, and applications in the shared industrial environment (e.g. machines tended
by the IMRs; enterprise resource planning (ERP) tools; and building infrastructure such as lifts, alarm
systems, automated doors).
For the purposes of this document, “industrial environment” describes a workplace where the people
are working-age adults and the public is restricted from access or not reasonably expected to be present.
Further, “industrial” pertains to the production of goods and related services (e.g. manufacturing, laboratory,
pharmaceutical, warehousing, distribution, logistics and other workplaces).
The following applications are excluded from the scope of this document: entertainment, consumer, military,
medical and use on public roads.
This document is not safety-related; there are no safety requirements. Navigation requirements are excluded
from the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 8373, Robotics — Vocabulary
ISO 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO/IEC 9834-8, Information technology — Procedures for the operation of object identifier registration
authorities — Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers
ISO 16100-1, Industrial automation systems and integration — Manufacturing software capability profiling for
interoperability — Part 1: Framework
ISO/IEC 20922, Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.1
ISO/IEC 21778, Information technology — The JSON data interchange syntax
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 8373, ISO 16100-1 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 Terms and definitions
3.1.1
industrial mobile robot
IMR
mobile platform capable of navigating and operating through an industrial environment (3.1.12) to reach a
specified location or cover a specified area, together with any integrated attachments (3.1.2)
Note 1 to entry: Navigation of the IMR can be autonomous or guided.
3.1.2
attachment
component, mechanism or equipment to be integrated with a mobile platform
3.1.3
fleet
industrial mobile robot fleet
IMRF
one or more IMRs (3.1.1) that are collectively managed
3.1.4
fleet manager
industrial mobile robot fleet manager
IMRFM
software that monitors and directs one or more IMRF(s) (3.1.3)
Note 1 to entry: Fleet manager functions can include monitoring statuses or poses (3.1.9), or both, of IMRs (3.1.1),
coordinating actions, order management, data synchronization, charging, idle parking and traffic management.
3.1.5
industrial mobile robot origin point
IMR origin point
point within an IMR (3.1.1) that is designated as the (0,0,0) coordinate
Note 1 to entry: The IMR origin point is usually selected by the manufacturer of the IMR and used by the IMR to report
its position.
3.1.6
industrial mobile robot footprint point
IMR footprint point
coordinate measured in meters relative to the IMR origin point (3.1.5)
Note 1 to entry: The IMR footprint point is positive x when measured from IMR origin point in direction of front of
vehicle (north bound), positive y when measured to the left of the IMR (3.1.1) when front of IMR is pointing upwards.
3.1.7
industrial mobile robot footprint
IMR footprint
two-dimensional projection of the physical volume of the IMR (3.1.1) and its payload(s), onto the travel
surface, described as a polygon in the coordinate frame that defines the outer boundaries of the physical
volume of the IMR and its payload(s) relative to the IMR origin point (3.1.5)
Note 1 to entry: The IMR footprint can change dynamically, e.g. due to the motion of an attachment (3.1.2).
Note 2 to entry: Often, IMR "forward" motion is in the positive x axis (+x) direction, but this can vary depending on the
IMR type.
Note 3 to entry: The IMR footprint lists points in clockwise order. It is not necessary to repeat the first coordinate
point to close the polygon, because the last point in the footprint is matched with the first. See Figure 1.
EXAMPLE The footprint depicted in Figure 1 is: [ (8, 0), (6, −4), (−2, −4), (−2, 4), (6, 4)].

Figure 1 — Example of an IMR origin point (0,0) within an IMR footprint and IMR working area, top
view
3.1.8
industrial mobile robot working area
IMR working area
two-dimensional polygon encompassing the IMR footprint (3.1.7) to allow the IMR (3.1.1) to work and
navigate
Note 1 to entry: The IMR working area is reported in the same manner as the IMR footprint.

3.1.9
pose
combination of position and orientation in space
[SOURCE: ISO 8373:2021, 5.5, modified — Note 1 to entry and Note 2 to entry have been deleted.]
3.1.10
odometry
combination of pose (3.1.9), linear velocity and angular velocity
3.1.11
docking
process of reaching or connecting or both reaching and connecting to another object
Note 1 to entry: "Another object" can include, e.g. transfer points, charging stations, other industrial mobile robots
(3.1.1).
3.1.12
industrial environment
workplace where the public is restricted from access or not reasonably expected to be present
3.1.13
enterprise resource planning
ERP
planning function that includes inventory transaction, cost accounting, order fulfilment and resource
tracking
Note 1 to entry: The planning methodology uses material requirements planning and master production schedule to
calculate requirements for materials and to make recommendations to release replenishment orders when due dates
and need dates are not in phase.
Note 2 to entry: An alternative definition of enterprise resources planning can be found in ISO 15531-1.
[SOURCE: ISO 16100-1:2009, 3.11]
3.1.14
common coordinate system
CCS
coordinate system used to communicate locations
Note 1 to entry: The common coordinate system is defined in the Euclidean space (x,y,z).
3.1.15
common coordinate system origin point
CCS origin point
arbitrarily selected point within a facility that is designated as the (0,0,0) coordinate in the common
coordinate system (CCS) (3.1.14)
Note 1 to entry: The CCS origin point is a property of the facility or industrial environment (3.1.12) in which industrial
mobile robots (IMRs) (3.1.1) or IMR fleets (3.1.3) operate, e.g. a point on a wall, column or floor.
Note 2 to entry: The CCS follows the right-hand rule convention.
Note 3 to entry: All locational data shared is a position relative to the CCS origin point, which is stated in meters (m).
3.1.16
reference point
coordinate that is relative to the common coordinate system (CCS) origin point (3.1.15) which can be used as
a reference for all industrial mobile robots (IMRs) (3.1.1) or IMR fleet managers (IMRFMs) (3.1.4) to establish a
transformation from their individual maps to the CCS (3.1.14)
EXAMPLE Centre or edges of fiducials (3.1.18), corners of the rooms.

Note 1 to entry: The CCS origin point can be considered a reference point.
Note 2 to entry: Coordinate transforms can be computed by the IMRFM to which the IMRs belong.
3.1.17
location point
industrial mobile robot origin point (3.1.5) relative to the common coordinate system origin point (3.1.15) at a
moment in time
3.1.18
fiducial
physical marker or object to designate a reference point (3.1.16)
Note 1 to entry: A fiducial can be considered a landmark.
3.1.19
local trajectory
ordered list of industrial mobile robot (IMR) (3.1.1)location points (3.1.17) and timestamps that the IMR uses
for navigation within the range of sensors
3.1.20
global path
geometric representation of the industrial mobile robot (IMR)'s (3.1.1) planned path that the IMR uses for
navigation beyond the range of sensors
Note 1 to entry: This can be a set of interpolation points, e.g. non-uniform rational basis spline (NURBS). See Annex A
for the JSON schema for NURBS.
3.1.21
global plan
ordered list of industrial mobile robot (3.1.1)location points (3.1.17) for future destinations with estimated
times of arrival at each location point
Note 1 to entry: This is intended to be a short list of significant intermediate points (e.g. intersections, working
locations) and not intended to be an extension of local trajectory (3.1.19).
3.2 Abbreviated terms
Term Abbreviated term
common coordinate system CCS
enterprise resource planning ERP
industrial mobile robot IMR
industrial mobile robot fleet IMRF
industrial mobile robot fleet manager IMRFM
JavaScript Object Notation JSON
light detection and ranging LIDAR
message queuing telemetry transport MQTT
non-uniform rational basis spline NURBS
original equipment manufacturer OEM
ping request PINGREQ
quality of service QoS
scalable vector graphics SVG
state of charge SoC
transmission control protocol TCP
universally unique identifier UUID

4 Common coordinate system (CCS)
4.1 General
All industrial mobile robot fleets (IMRFs) operating in the same physical space (e.g. floor, mezzanine,
building) shall use the same common coordinate system (CCS). At least three reference points per CCS, one
of which can be the CCS origin point, shall be identified to establish a CCS for different IMRs or IMRFMs
operating in the same facility. These reference points shall be:
— on a horizontal plane, with three-dimensional data (e.g. ramps) projected down into the horizontal plane;
— measured in meters (m);
— spaced out over the area being used, as far as is practicable, to reduce the effects of measurement errors.
NOTE 1 CCS enables transformation of independent and individual coordinate systems into a common coordinate
system. See Annex D for an explanation of how to implement this, with examples.
The local map(s) used by each IMRFM or IMR shall include points that correspond to at least three reference
points. When multiple maps are used, all maps shall use the same universally unique identifier (UUID) for
each reference point. All UUIDs shall conform with ISO/IEC 9834-8.
NOTE 2 By knowing these reference points, maps can be transformed back and forth among multiple coordinate
systems.
4.2 CCS fields
A CCS shall have the following fields as shown in Table 1.
Table 1 — Common Coordinate System (CCS) fields
Required, recom-
Field name Type Description
mended or optional?
A string representation of a universally unique identi-
id string fier (UUID) that defines this CCS. This is the identifier Required
when referencing this CCS.
A label for display purposes, which should not be used
name string Required
for referencing purposes.
A list of at least three reference point IDs, that are
referencePointIds array of strings spaced out over the area being used to reduce the Required
effects of measurement errors.
4.3 Reference point fields
Reference points shall have the following fields as shown in Table 2.

Table 2 — Reference point fields
Required, recom-
Field name Type Description
mended or optional?
A string representation of a universally unique iden-
id string tifier (UUID) that defines this reference point. This is Required
the identifier for referencing this point.
A label for display purposes, which should not be used
name string Required
for referencing purposes.
The x-coordinate of the position of the reference point
x float32 Required
relative to the CCS origin point, measured in meters (m).
The y-coordinate of the position of the reference point
y float32 Required
relative to the CCS origin point, measured in meters (m).
4.4 Location point fields
Location points shall have the following fields as shown in Table 3. The field name “z” shall be relative to
ground of the referenced CCS, where a negative value is a location below the ground plane.
Table 3 — Location point fields
Required, recom-
Field name Type Description
mended or optional?
A string representation of a universally unique identifier
(UUID) that defines the CCS within which the location
ccsId string Required
point is referenced. This is the identifier used when
internally referencing this CCS.
The x-coordinate of the position of the IMR's location
x float32 point relative to the CCS origin point, measured in Required
meters (m).
The y-coordinate of the position of the IMR's location
y float32 point relative to the CCS origin point, measured in Required
meters (m).
The z-coordinate of the position of the IMR's location
point relative to the CCS origin point, measured in
z float32 Required
meters (m), where a negative value is a location below
the CCS origin point.
5 Industrial mobile robot identity and capability
Upon start-up or change, the IMR information stated in this document shall be provided in accordance with
Table 4. In the context of this document, the following shall apply:
— "Required" information shall be provided;
— "Recommended" information should be provided;
— "Optional" information may be provided.
The maximum value shall be communicated if the IMR does not have the means to detect or report a change
to IMR footprint, IMR working area, height, speed or payload.

Table 4 — IMR identity and capability Information
Required, rec-
Child field name
Field name
Type Description ommended or
(parent)
(if any)
optional?
A string representation of the IMR's
id string Required
universally unique identifier (UUID)
The timestamp of the message when
Y Y Y Y -M M -DD T h h :
timestamp this identity and capability is valid, in Required
m m: s s . f f f Z
accordance with ISO 8601-1
An entity is the sender or receiver of
JSON messages defined in this docu-
entityType string Required
ment. For an IMR the value of this field
shall be IMR
The company name of the IMR manufac-
manufacturerName string Required
turer
ISO 21423 protocol version used by this
iso21423Version string Optional
IMR, starting with version 1.0
The capabilities of the IMR according to
capabilities Capabilities object Required
B.5.2.3; see Table A.3
details { Required
imrModel string The IMR model Required
imrSerialNumber string IMR serial number Required
array of Point An array of coordinates of the IMR foot-
imrFootprint Required
objects print points in meters (m); see Table A.1
An array of coordinates of the IMR
array of Point
imrWorkingArea working area, in meters (m); see Required
objects
Table A.1
The maximum height of the working
imrHeight float32 Required
space, in meters (m)
The current version of software, provid-
array of Software-
softwareVersions ed as an array of tuples with component Required
Version objects
and version; see Table A.2
IMR priority for resolving conflicts,
priority uint32 Recommended
where zero (0) is the highest priority
The IMR's rated speed in the primary
ratedSpeed float32 Recommended
direction of travel, measured in m/s
supportedChar- The type(s) of charger which can be
array of strings Recommended
gerTypes used by the IMR
The company name of the technical
support supplier
supportVendor-
string Recommended
Name
NOTE This can be the manufacturer of
the IMR, or a different company
SupportVendor-
The contact information for the techni-
ContactInforma- string Recommended
cal support supplier, see Table A.4
tion object
visualThumbnail- A visual thumbnail image of the IMR, as
string(base64) Recommended
Image a base64-encoded SVG
The IMR's rated load, expressed as mass
(kg), corresponding to the maximum
ratedLoad float32 Recommended
load under standard gravitational accel-
eration
supportURL string URL to support web user interface Optional
imrDocumenta- A link to more detailed IMR documen-
string Optional
tion tation
TTabablele 4 4 ((ccoonnttiinnueuedd))
Required, rec-
Child field name
Field name
Type Description ommended or
(parent)
(if any)
optional?
payloadTypes array of strings The types of payload the IMR can handle Optional
batteryType string The type of battery used by the IMR Optional
Additional properties of the IMR as
additionalProp- array of Addition-
appropriate for specific IMR types and Optional
erties alProperty objects
applications see Table A.12
}
6 Industrial mobile robot location and status
6.1 General
IMR location and status information shall be published in accordance with 6.3.
NOTE This information regarding current location and operating mode and state can facilitate location
visualization, traffic management and more.
6.2 Operating mode and operating state
The operating mode and operating state shall be reported as an array of strings that provide the active
operating mode and a list of all current states of the IMR. The list can be empty if the IMR is not in any of
these states. State strings are ordered in the list according to the IMR implied priority with the operating
mode first, followed by the highest priority operating state. The mode and state names as described in
Table 5 shall be used. The list can be expanded by defining or redefining new strings only if it is for a purpose
not listed in Table 5.
The applicable operating states shall be communicated as specified in Table 5.
If the state MODE_MANUAL, MODE_TELEOP or MODE_MAINTENANCE is active, and any or all of STOP_
CATEGORY_0, STOP_CATEGORY_1 and STOP_CATEGORY_2 are present, then communication of the stop
category operating states shall be provided. If the active state is either MODE_AUTO or MODE_SEMIAUTO,
then the following states are optional or required as stated in Table 5.
Table 5 — Operating state descriptions and requirements when in autonomous or semiautonomous
mode
Required, recom-
Name of operating state Description mended or optional, if
presently active
Uncontrolled stop by immediately removing power to
a
STOP_CATEGORY_0 Required
the machine actuators
Controlled stop with power to the machine actuators
a
STOP_CATEGORY_1 available to achieve the stop then remove power when Required
the stop is achieved
Controlled stop with power left available to the machine
a
STOP_CATEGORY_2 Required
actuators
PAUSED IMR is paused temporarily, while retaining its objective Recommended
IMR is waiting for a human intervention (e.g. reset)
WAIT_FOR_RESET Optional
before it can operate
MAPPING IMR is creating a new map Optional
LOST IMR lost localization and does not know where it is Required
a
Stop categories are defined in IEC 60204-1.

TTabablele 5 5 ((ccoonnttiinnueuedd))
Required, recom-
Name of operating state Description mended or optional, if
presently active
Attachment on the IMR is active; the mobile platform
WAIT_FOR_ATTACHMENT Optional
does not move
WAIT_FOR_EVENT IMR is waiting for an external event or input Optional
IMR is prevented from making progress along its cur-
BLOCKED Recommended
rent objective; includes deadlock situations
ATTACHMENT_ACTIVE Attachment on the IMR is active Optional
STOPPED The IMR is stopped Optional
IMR is docking with another object, e.g. a transfer point,
DOCKING Required
charging station or another IMR
SLOWING Decelerating ("braking") Optional
ACCELERATING Accelerating Optional
LEFT_TURN Approaching or in a left turn based on direction of travel Optional
Approaching or in a right turn based on direction of
RIGHT_TURN Optional
travel
IMR is traveling mainly in its reverse direction (long-
REVERSE Optional
term reverse)
IMR is traveling mainly in its forward direction (long-
FORWARD Optional
term forward)
IMR is actively following a physical or virtual line, and is
LINE_FOLLOWING Optional
unable to leave it
CHARGING IMR is charging and cannot move Required
LOW_BATTERY Battery low condition Recommended
IMR is not currently engaged in an order, mission, task
IDLE Required
or assignment
PARKED IMR is parked Required
OFFLINE IMR is offline Optional
MODE_AUTO Autonomous mode
MODE_SEMIAUTO Semi-autonomous or assisted manual mode
Teleoperation mode; mode that allows for direct control Exactly one of these
MODE_TELEOP
by a remote operator or a tele-operator modes is Required
MODE_MANUAL Manual mode
MODE_MAINTENANCE Maintenance mode
a
Stop categories are defined in IEC 60204-1.
6.3 Required status data
The message containing this information shall be sent when the information described in Table 6 changes.
The minimum and maximum frequency shall be set. Message formats shall comply with Annex B.
NOTE Information about IMR location and status is likely to be updated with greater frequency than is information
about IMR identity and capability.

Table 6 — IMR location and status information
Required, recom-
Field name Type Description
mended or optional?
A string representation of the IMR's universally
id string Required
unique identifier (UUID)
YYYY- MM- DDThh:m m: The timestamp of the message, in accordance
timestamp Required
s s . f ff Z with ISO 8601-1
The current location of the IMR, provided in a
a
locationPoint LocationPoint object location point object in accordance with 4.4; Required
see Table 3
The operating mode and the list of all currently
operatingStates array of strings Required
active operating states, in accordance with Table 5
a
linearVelocity float32 Current linear velocity in m/sec Recommended
a
angularVelocity float32 Current angular velocity in radians/sec Recommended
Information about the IMR's battery status, e.g.
batteryStatus BatteryStatus object Recommended
percentage charge remaining; see Table A.5
localTrajectory LocalTrajectory object The IMR's local trajectory; see Table A.6 Recommended
globalPath GlobalPath object The IMR's global path; see Table A.8 Recommended
globalPlan GlobalPlan object The IMR's global plan; see Table A.11 Optional
b
loadPercentageUsed float32 Percentage of the maximum load used Optional
a
locationPoint, linearVelocity and angularVelocity are published as part of odometry; see B.5.7 for an example.
b
This is an IMR-specific property that represents how much of the carrying capacity of the IMR is used, where 100 %
represents fully loaded. This can be any combination of volume, area and weight, as specified in the information for use.
7 Industrial mobile robot fleet manager identity and capability
Upon start-up or change, the IMRFM information stated in Table 7 shall be provided.
Table 7 — IMRFM identity and capability information
Required, rec-
Field name Child field name
Type Description ommended or
(parent) (if any)
optional?
A string representation of the IMRFM's
id string Required
universally unique identifier (UUID)
The timestamp of the message when this
Y Y Y Y -M M -D D T h h :
timestamp identity and capability is valid, in accord- Required
m m: s s . f f f Z
ance with ISO 8601-1
An entity is the sender or receiver of JSON
messages defined in this document. For
entityType string Required
an IMRFM the value of this field shall be
IMRFM
The company name of the IMRFM man-
manufacturerName string Required
ufacturer
ISO 21423 protocol version used by this
iso21423Version string Optional
IMRFM, starting with version 1.0
The capabilities of the IMRFM according
capabilities Capabilities object Required
to B.5.2.3; see Table A.3
details {
The current version of software, provided
array of Software-
softwareVersions as an array of objects with component and Required
Version objects
version; see Table A.2
imrfmModel string The IMRFM model Recommended

TTabablele 7 7 ((ccoonnttiinnueuedd))
Required, rec-
Field name Child field name
Type Description ommended or
(parent) (if any)
optional?
supportVendorCon- SupportVendorCon-
The contact information for the technical
tactInf tactInformation ob- Recommended
support supplier; see Table A.4
ject
supportURL string URL to support web user interface Optional
imrfmDocumenta- A link to more detailed IMRFM documen-
string Optional
tion tation
}
8 Industrial mobile robot fleet manager state
IMRFM status information shall be provided to other IMRs, IMRFMs and related systems, in accordance
with Table 8 and Table 9, to facilitate interoperability by allowing all entities receiving the information to
know information about the IMRFM state.
The IMRFM state message, as detailed in Table 8, shall be sent when the information described in Table 9
changes. The minimum and maximum frequency shall be set. Messages shall be in accordance with Annex B.
Table 8 — IMRFM status information
Required, recom-
Field name Type Description
mended or optional?
A string representation of the IMRFM's universally
id string Required
unique identifier (UUID)
Y Y Y Y -M M
The timestamp of the message when this identity and
timestamp -DD T h h: m m: s s Required
capability is valid, in accordance with ISO 8601-1
.fffZ
states array of strings The IMRFM's current state Required
IMRFMs shall report its state from the list of available states in Table 9.
Table 9 — IMRFM operating state descriptions and requirements
Name of operating state Description Required, recommended, optional
READY Ready to send and receive messages
NOT_READY Not ready to send or receive messages Exactly one of these states is Required
OFFLINE IMRFM not connected
9 Request messages
The IMR or IMRFM shall be capable of sending and receiving request messages and requestStatus messages.
Messages shall follow the format described in Annex C. IMRs or IMRFMs that can report their location shall
be capable of sending and receiving the move, pauseImr, resumeImr and cancel messages as described in
Annex C.
The sender and the receiver shall interact through the following sequence:
a) Sender issues a request message to an identified receiver.
b) Receiver responds with a requestStatus message upon any state change for that request message; the
changes of the state are dependent on the content of the request message as shown in Figure C.3 and
Figure C.4.
c) When the request is complete, the last requestStatus message indicates that the message is CANCELED,
SUCCEEDED or ABORTED.
NOTE At their most basic, the messages are used by a sender to request a receiver to perform an action or a
sequence of actions. The messages are designed to be extensible by a vendor or integrator in order to extend longevity
of the mechanism.
Status updates shall be sent only if state changes; they shall not be sent periodically. To accomplish this, the
message protocol shall offer a non-interruptible delivery quality of service.
10 Messaging protocol and message formats
10.1 General
The messaging protocol and message format shall be consistent. The messaging protocol should follow best
practices related to cyber-security and authentication according to the IEC 62443 series or IEC 27001.
10.2 Messaging protocol
All messages shall be exchanged over a standard communication protocol in accordance with ISO/IEC 20922.
10.3 Message format
Messages shall utilize JSON in accordance with ISO/IEC 21778. Message formats shall be in accordance with
Annex B and Annex C. The JSON schema shall be in accordance with Annex A.

Annex A
(normative)
JSON schema
A.1 JSON object descriptions
All custom JSON object data types used in messages specified by this document shall comply with Clause A.1.
In each table in Clause A.1, the "Required, recommended or optional?" column specifies the requirement
level of each field within the object, when the object is present.
Table A.1 — Point
Required, recommend-
Field name Type Description
ed or optional?
The x-coordinate of the position of the point relative
x float32 Required
to the CCS origin point, measured in meters (m)
The y-coordinate of the position of the point relative
y float32 Required
to the CCS origin point, measured in meters (m)
Table A.2 — SoftwareVersion
Required, recommend-
Field name Type Description
ed or optional?
moduleName string Name of the software module Required
moduleVersion string Version of the software module Required
Table A.3 — Capabilities
Child field
Field name Required, recom-
name
Type Description
(parent) mended or optional?
(if any)
List of resources that are provided by this
provides array of strings entity; the name of each matches the topic Required
name in the entity’s namespace
accepts { Messages accepted by this entity Required
List of requestDetail action types that are
requests array of strings Required
supported by this entity
}
List of entity UUIDs that are managed
by this entity; an IMRFM may manage
a
manages array of strings Optional
a number of IMRs, and the UUID of each
IMR shall be provided here
If this entity is managed by another entity,
a
managedBy string then the managing entity UUID shall be Optional
provided here
a
“manages” and “managedBy” are not mutually exclusive; both are specified to create a hierarchy, e.g. IMRFM may manage
multiple IMRFMs, which in turn each may manage multiple IMRs.

Table A.4 — SupportVendorContactInformation
Required, recom-
Field name Type Description
mended or optional?
name string The name of the vendor for this entity Required
phone string The telephone number of the vendor for this entity Recommended
address string The address of the vendor for this entity Recommended
email string The email address of the vendor for this entity Recommended
Table A.5 — BatteryStatus
Required, recom-
Field name Type Description
mended or optional?
Y Y Y Y -M M -DD T h h : The timestamp of the message, in accordance
timestamp Required
m m: s s . f f f Z with ISO 8601-1
The battery state of charge as a fractional value
batterySoc float32 Required
where 1 equals 100 %
The battery’s overall health status with the
enumeration values: {"UNKNOWN",
batteryHealth string Optional
"HEALTHY", "OVERHEAT", "DEAD", "OVER-
VOLTAGE", "FAILURE", "COLD"}
The battery pack temperature; measured in
batteryTemperature float32 Optional
degrees Celsius
batteryVoltage float32 Overall battery pack voltage; measured in Volts Optional
The instantaneous battery current; measured
batteryCurrent float32 Optional
in Amps
Describes the charging state of the battery
with the enumeration values: {"UNKNOWN",
batteryChargingState string Recommended
"CHARGING", "DISCHARGING", "NOT_CHARG-
ING", "FULL"}
Table A.6 — LocalTrajectory
Required, recommend-
Field name Type Description
ed or optional?
Y Y Y Y -M M -DD T h h : The timestamp of the message, in accordance
timestamp Required
m m: s s . f f f Z with ISO 8601-1
array of Location-
Array of location points, each with a corre-
localTrajectory PointStamped Required
sponding timestamp; see Table A.7
objects
Table A.7 — LocationPointStamped
Required, recommend-
Field name Type Description
ed or optional?
Y Y Y Y -M M -DD T h h : The timestamp of the message, in accordance
timestamp Required
m m: s s . f f f Z with ISO 8601-1
LocationPoint The location point relative to the CCS origin
locationPoint Required
object point; see Table 3
Table A.8 — GlobalPath
Required, recommend-
Field name Type Description
ed or optional?
Y Y Y Y -M M -DD T h h : The timestamp of the message, in accordance
timestamp Required
m m: s s . f f f Z with ISO 8601-1
Geometric representation of a curve using
globalPath NurbsCurve object Required
NURBS; see Table A.9
Table A.9 — NurbsCurve
Required, recommend-
Field name Type Description
ed or optional?
The degree of the NURBS curve, with a mini-
degree uint32 Required
mum value of 1
array of Nurb-
List of points used to determine the shape of a
controlPoints sControlPoiont Required
NURBS curve; see Table A.10
objects
knots array of int32 The knot vector for the NURBS curve Required
Table A.10 — NurbsControlPoint
Required, recommend-
Field name Type Description
ed or optional?
LocationPoint The location point relative to the CCS origin
locationPoint Required
object point for this NURBS control point; see Table 3
Numerical value associated with this NURBS
weight float32 control point that determines how strongly the Optio
...

Norme
internationale
ISO 21423
Première édition
Robotique — Robots mobiles
2026-10
industriels — Communications et
interopérabilité
Robotics — Industrial mobile robots — Communications and
interoperability
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2026
Tous droits réservés.
La présente publication de l’ISO est protégée par le droit d’auteur et demeure la propriété de l’ISO et/ou de ses concédants de
licence.
Le contenu de la présente publication de l’ISO est fourni sous licence, et n’est pas vendu. Son utilisation est soumise aux conditions
de licence applicables définies par l’ISO, un organisme membre de l’ISO, ou un distributeur tiers agréé.
Sous réserve des besoins liés à sa mise en œuvre ou d’une autorisation expresse prévue aux termes d’une licence distincte, aucune
partie de la présente publication de l’ISO ne peut être reproduite, distribuée, modifiée, utilisée ou mise à disposition sous quelque
forme ou par quelque moyen que ce soit – électronique ou mécanique, y compris la photocopie, la numérisation, l’enregistrement
ou la publication sur des plateformes numériques internes ou externes.
Toute utilisation hors du champ d’application des droits accordés est interdite et peut donner lieu à des poursuites judiciaires.
ISO copyright office
Case postale 401 • CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
3.1 Termes et définitions .2
3.2 Termes abrégés .6
4 Système de coordonnées commun (CCS) . 7
4.1 Généralités .7
4.2 Champs de CSS .7
4.3 Points de référence .7
4.4 Points de localisation .8
5 Identité et capacités des robots mobiles industriels . 8
6 Localisation et statut des robots mobiles industriels .10
6.1 Généralités .10
6.2 Mode de fonctionnement et état de fonctionnement .10
6.3 Données de statut obligatoire .11
7 Identité et capacités du gestionnaire de flotte de robots mobiles industriels .12
8 État du gestionnaire de flotte de robots mobiles industriels .13
9 Messages de requêtes . 14
10 Protocole de messagerie et format de message . 14
10.1 Généralités .14
10.2 Protocole de messagerie . 15
10.3 Format de message . 15
Annexe A (normative) Schéma JSON . 16
Annexe B (normative) Sujets et format de message . 41
Annexe C (normative) Messages de requêtes .60
Annexe D (informative) Étalonnage au point de localisation .84
Bibliographie .87

iii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes nationaux
de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l’ISO participent également aux travaux. L’ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a
été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir
www.iso.org/directives).
L’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité de
tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait pas
reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois,
il y a lieu d’avertir les responsables de la mise en application du présent document que des informations
plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à l’adresse
www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de
tels droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l’ISO liés à l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de
l’ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir le lien suivant: www.iso.org/iso/fr/avant-propos.html.
Le présent document a été élaboré par le comité technique ISO/TC 299, Robotique.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/fr/members.html.

iv
Introduction
À mesure que les robots mobiles industriels sont de plus en plus utilisés pour une utilisation dans des
environnements industriels, il y a un besoin croissant pour que les robots mobiles industriels (IMR) de
fournisseurs uniques ou multiples opèrent dans la même zone, indépendamment du fournisseur ou du modèle.
Les aspects relatifs à la navigation et à la sécurité des IMR et flotte d’IMR (IMRF) ne sont pas couverts par le
présent document. Le présent document permet aux différentes flottes de fonctionner plus efficacement, en
partageant des informations sur l’emplacement, la vitesse, la direction, la ou les conditions, la disponibilité
et d’autres caractéristiques des IMR et en demandant des actions. Les protocoles de communication indiqués
dans le présent document peuvent également permettre aux IMR et IMRF d’échanger des données avec
d'autres équipements et systèmes, par exemple les systèmes d’alarme, les ascenseurs et les portes.

v
Norme internationale ISO 21423:2026(fr)
Robotique — Robots mobiles industriels — Communications
et interopérabilité
1 Domaine d’application
Pour faciliter l’interopérabilité dans un environnement industriel partagé, le présent document spécifie les
exigences pour la communication entre un ou plusieurs des éléments suivants:
— robot mobile industriel (IMR);
— gestionnaire de flotte d’IMR (IMRFM);
— d’autres machines, équipements et applications dans l’environnement industriel partagé (par exemple,
les machines entretenues par les IMR; les outils de planification des ressources de l’entreprise (ERP);
l’infrastructure du bâtiment, telle que les ascenseurs, les systèmes d’alarme, les portes automatisées).
Pour les besoins du présent document, «environnement industriel» décrit un lieu de travail où les personnes
sont des adultes en âge de travailler, et où l’accès au public est restreint ou celui-ci n’est pas raisonnablement
censé être présent. De plus, « industriel » se rapporte à la production de biens et aux services associés,
(par exemple, la fabrication, les laboratoires, le domaine pharmaceutique, les entrepôts, la distribution, la
logistique et d’autres lieux de travail).
Les applications suivantes sont exclues du domaine d’application du présent document: divertissement,
consommation, militaire, médical et utilisation sur les voies publiques.
Le présent document n’est pas lié à la sécurité; il n’y a pas d’exigences de sécurité. Les exigences relatives à la
navigation sont exclues du domaine d'application du présent document.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour
les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 8373, Robotique — Vocabulaire
ISO 8601-1, Date et heure — Représentations pour l'échange d'information — Partie 1: Règles de base
ISO/IEC 9834-8, Technologies de l'information — Procédures opérationnelles pour les organismes
d'enregistrement d'identificateur d'objet — Partie 8: Génération des identificateurs uniques universels (UUID) et
utilisation de ces identificateurs dans les composants d'identificateurs d'objets
ISO 16100-1, Systèmes d'automatisation industrielle et intégration — Profil d'aptitude du logiciel de fabrication
pour interopérabilité — Partie 1: Cadre
ISO/IEC 20922, Technologies de l'information — Transport par télémesure des messages en file d’attente
(MQTT) v3.1.1
ISO/IEC 21778, Technologies de l'information — Syntaxe d'échange de données JSON

3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l’ISO 8373, l’ISO 16100-1 ainsi
que les suivants, s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1 Termes et définitions
3.1.1
robot mobile industriel
IMR
plateforme mobile capable de naviguer et d’opérer dans un environnement industriel (3.1.12) afin d’atteindre
un emplacement spécifié ou couvrir une zone spécifiée, avec tout accessoire (3.1.2) intégré
Note 1 à l'article: La navigation de l’IMR peut être autonome ou guidée.
3.1.2
accessoire
composant, mécanisme ou équipement à intégrer à une plateforme mobile
3.1.3
flotte
flotte de robots mobiles industriels
IMRF
un ou plusieurs IMR (3.1.1) qui sont gérés collectivement
3.1.4
gestionnaire de flotte
gestionnaire de flotte de robots mobiles industriels
IMRFM
logiciel qui surveille et dirige une ou plusieurs IMRF (3.1.3)
Note 1 à l'article: Les fonctions de l’IMRFM peuvent inclure la surveillance des statuts et/ou des poses (3.1.9), ou les
deux, des IMR (3.1.1), la coordination des actions, la gestion des commandes, la synchronisation des données, la charge,
le stationnement au repos et la gestion du trafic.
3.1.5
point d’origine du robot mobile industriel
point d’origine de l’IMR
point arbitrairement sélectionné dans un IMR, qui est désigné comme le point de coordonnées (0,0,0)
Note 1 à l'article: Le point d'origine de l'IMR est habituellement sélectionné par le fabricant de l'IMR et utilisé par l'IMR
pour reporter sa position.
3.1.6
point d’empreinte du robot mobile industriel
point d’empreinte de l’IMR
coordonnée mesurée en mètres par rapport au point d’origine de l’IMR (3.1.5)
Note 1 à l'article: Le point d'empreinte de l'IMR est x positif lorsqu’il est mesuré depuis le point d’origine de l’IMR en
direction de l’avant du véhicule (vers le nord), y positif lorsqu’il est mesuré vers la gauche de l'IMR (3.1.1) lorsque
l’avant de l'IMR pointe vers le haut.

3.1.7
empreinte du robot mobile industriel
empreinte de l’IMR
projection bidimensionnelle du volume physique de l’IMR (3.1.1) et de son ou ses type(s) de charge, sur la
surface de déplacement, décrite comme un polygone dans le système de coordonnées qui définit les limites
extérieures du volume physique de l’IMR et de son ou ses type(s) de charge par rapport au point d’origine de
l’IMR (3.1.5)
Note 1 à l'article: L’empreinte de l’IMR peut évoluer de façon dynamique, par exemple, du fait du mouvement d'un
accessoire (3.1.2).
Note 2 à l'article: Souvent, le mouvement «vers l’avant» de l’IMR est dans la direction de l’axe x positif (+x), mais cela
peut varier selon le type d’IMR.
Note 3 à l'article: L’empreinte de l’IMR énumère les points dans l’ordre des aiguilles d’une montre. Il n’est pas nécessaire
de répéter le premier point de coordonnées pour fermer le polygone, car le dernier point de l’empreinte est associé au
premier. Voir la Figure 1.
EXEMPLE L’empreinte représentée à la Figure 1 est: [ (8, 0), (6, −4), (−2, −4), (−2, 4), (6, 4)].

Figure 1 — Exemple de point d’origine d’un IMR (0,0) dans une empreinte d’IMR, et espace de travail
de l'IMR, vue de dessus
3.1.8
espace de travail du robot mobile industriel
espace de travail de l'IMR
polygône bidimensionnel comprenant l'empreinte de l'IMR (3.1.7) pour permettre à l'IMR (3.1.1) de travailler
et naviguer
Note 1 à l'article: L'espace de travail de l'IMR est reporté de la même manière que l'empreinte de l'IMR.
3.1.9
pose
position et orientation combinées dans l’espace
[SOURCE: ISO 8373:2021, 5.5, modifiée — Les Note 1 à l'article et Note 2 à l'article ont été supprimées.]
3.1.10
odométrie
pose (3.1.9), vitesse linéaire et vitesse angulaire combinées

3.1.11
amarrage
processus consistant à atteindre ou à se connecter ou à atteindre et se connecter à la fois à un autre objet
Note 1 à l'article: «Un autre objet» peut inclure, par exemple, des points de transfert, des stations de recharge, d’autres
robots mobiles industriels (3.1.1).
3.1.12
environnement industriel
lieu de travail dont l’accès est interdit au public ou dans lequel la présence du public n’est pas raisonnablement
attendue
3.1.13
planification des ressources de l’entreprise
ERP
fonction de planification incluant la gestion des transactions d’inventaire, la comptabilité analytique,
l’exécution des commandes et le suivi des ressources
Note 1 à l'article: La méthodologie de planification utilise la planification des besoins en matériaux et le programme
directeur de production pour calculer les besoins en matériaux et formuler des recommandations de lancement des
ordres de réapprovisionnement lorsque les dates d’échéance et les dates de besoin ne coïncident pas.
Note 2 à l'article: Une définition alternative de la planification des ressources de l’entreprise peut être trouvée dans
l’ISO 15531-1.
[SOURCE: ISO 16100-1:2009, 3.11]
3.1.14
système de coordonnées commun
CCS
système de coordonnées utilisé pour communiquer des emplacements
Note 1 à l'article: Le système de coordonnées commun est défini dans l’espace euclidien (x,y,z).
3.1.15
point d’origine du système de coordonnées commun
point d’origine du CCS
point arbitrairement sélectionné dans une installation, qui est désigné comme le point de coordonnées
(0,0,0) dans le système de coordonnées commun (CCS) (3.1.14)
Note 1 à l'article: Le point d’origine du CCS est une propriété de l’installation ou de l’environnement industriel (3.1.12)
dans lesquels les robots mobiles industriels(IMR) (3.1.1) ou les flottes d'IMR (3.1.3) opèrent, par exemple, un point sur
un mur, une colonne ou le sol.
Note 2 à l'article: Le CCS suit la convention de la règle de la main droite.
Note 3 à l'article: Toutes les données de localisation communiquées correspondent à une position par rapport au point
d'origine du CCS, exprimée en mètres (m).
3.1.16
point de référence
coordonnée relative au point d'origine du système de coordonnées commun (CCS) (3.1.15), qui peut être utilisée
comme référence pour tous les robots mobiles industriels (IMR) (3.1.1) ou gestionnaire de flotte d'IMR (IMRFM)
(3.1.4) pour établir une transformation à partir de leurs cartes individuelles vers le CCS (3.1.14)
EXEMPLE Centre ou bords de fiducial (3.1.18), coins des pièces.
Note 1 à l'article: Le point d'origine du CSS peut être considéré comme un point de référence.
Note 2 à l'article: Les transformations de coordonnées peuvent être calculées par l’IMRFM auquel appartiennent les
IMR.
3.1.17
point de localisation
point d’origine du robot mobile industriel (3.1.5) relatif au système de coordonnées commun (3.1.15) à tout
moment
3.1.18
fiducial
marqueur physique ou objet pour désigner un point de référence (3.1.16)
Note 1 à l'article: Un fiducial peut être considéré comme un repère.
3.1.19
trajectoire locale
liste ordonnée des points de localisation (3.1.17) du robot mobile industriel (IMR) (3.1.1) et des horodatages
que l’IMR utilise pour une navigation dans la portée de ses capteurs
3.1.20
chemin global
représentation géométrique du chemin prévu du robot mobile industriel (3.1.1), que celui-ci utilise pour sa
navigation au-delà de la portée de ses capteurs
Note 1 à l'article: Il peut s’agir d’un ensemble de points d’interpolation, par exemple spline rationnelle non uniforme
(NURBS). Voir l’Annexe A pour le schéma JSON pour une NURBS.
3.1.21
plan global
liste ordonnée des points de localisation (3.1.17) du robot mobile industriel (3.1.1) pour les destinations
futures avec les heures estimées d’arrivée à chaque point de localisation
Note 1 à l'article: Il doit s’agir d’une liste courte de points intermédiaires significatifs (par exemple, des intersections,
des lieux de travail), et non d’une extension de la trajectoire locale (3.1.19).
3.2 Termes abrégés
Terme Terme abrégé
common coordinate system (système de coordonnées
CCS
commun)
enterprise resource planning (planification des res-
ERP
sources de l’entreprise)
industrial mobile robot (robot mobile industriel) IMR
industrial mobile robot fleet (flotte de robots mobiles
IMRF
industriels)
industrial mobile robot fleet manager (gestionnaire de
IMRFM
flotte de robots mobiles industriels)
javascript object notation (notation d’objets javascript) JSON
light detection and ranging (télédétection par la lumière) LIDAR
message queuing telemetry transport (transport par
MQTT
télémesure des messages en file d’attente)
non-uniform rational basis spline (b-spline rationnelle
NURBS
non uniforme)
original equipment manufacturer (fabricant d’origine) OEM
ping request (requête ping) PINGREQ
quality of service (qualité de service) QoS
scalable vector graphics (graphiques vectoriels adapta-
SVG
tifs)
Terme Terme abrégé
state of charge (état de charge) SoC
transmission control protocol (protocole de contrôle de
TCP
transmission)
universally unique identifier (identifiant unique univer-
UUID
sel)
4 Système de coordonnées commun (CCS)
4.1 Généralités
Toutes les flottes de robots mobiles industriels (IMRF) opérant dans le même espace physique (par exemple,
étage, mezzanine, bâtiment) doivent utiliser le même système de coordonnées commun (CCS). Au moins
trois points de référence par CCS, dont l’un peut être le point d’origine du CCS, doivent être identifiés pour
établir un CCS pour différents IMR ou IMRFM opérant dans la même installation. Ces points de référence
doivent être:
— dans un plan horizontal, avec des données tridimentionnelles (par exemple, des rampes) projetées dans
le plan horizontal;
— mesurés en mètres (m);
— répartis sur la zone concernée, dans la mesure du possible, afin de réduire les effets des erreurs de
mesure.
NOTE 1 Le CCS permet la transformation des systèmes de coordonnées indépendants et individuels en un système
de coordonnées commun. Voir l'Annexe D pour une explication concernant la mise en œuvre, avec des exemples.
La ou les carte(s) locale(s) utilisée(s) par l’IMRFM ou l’IMR doit inclure des points qui correspondent au
moins à trois points de référence. Lorsque plusieurs cartes sont utilisées, toutes les cartes doivent utiliser
le même identifiant universel unique (UUID) pour chaque point de référence. Tous les UUID doivent être
conformes à l'ISO/IEC 9834-8.
NOTE 2 En connaissant ces points de référence, les cartes peuvent passer d’un système de coordonnées à un autre.
4.2 Champs de CSS
Un CCS doit comporter les champs suivants, comme indiqué dans le Tableau 1:
Tableau 1 — Champs du système de coordonnées commun (CCS)
Obligatoire, recom-
Nom du champ Type Description
mandé ou facultatif ?
Une représentation sous forme de chaîne de ca-
ractères d'un identifiant unique universel (UUID),
id chaîne de caractères Obligatoire
qui définit ce CCS. Il s’agit de l’identifiant lors du
référencement de ce CCS.
Un libellé à des fins d’affichage qu'il convient de
name chaîne de caractères Obligatoire
ne pas utiliser à des fins de référencement.
Une liste d’au moins trois points de référence, qui
ensemble de chaîne de
referencePointIds sont espacés sur la zone utilisée pour réduire les Obligatoire
caractères
effets des erreurs de mesure.
4.3 Points de référence
Les points de référence doivent comporter les champs suivants, comme indiqué dans le Tableau 2:

Tableau 2 — Champs des points de référence
Obligatoire, recom-
Nom du champ Type Description
mandé ou facultatif ?
Une représentation sous forme de chaîne de carac-
chaîne de carac- tères d'un identifiant unique universel (UUID) qui
id Obligatoire
tères définit ce point de référence. Il s’agit de l’identifiant
lors du référencement de ce point.
chaîne de carac- Un libellé à des fins d’affichage qu'il convient de ne
name Obligatoire
tères pas utiliser à des fins de référencement.
La coordonnée x de la position du point de référence
x float32 par rapport au point d’origine du CCS, mesurée en Obligatoire
mètres (m).
La coordonnée y de la position du point de référence
y float32 par rapport au point d’origine du CCS, mesurée en Obligatoire
mètres (m).
4.4 Points de localisation
Les points de localisation doivent comporter les champs suivants, comme indiqué dans le Tableau 3. Le nom
de champ “z” doit être exprimé par rapport au sol du CCS de référence, où une valeur négative correspond à
une position située en dessous du plan.
Tableau 3 — Champs des points de localisation
Obligatoire, recom-
Nom du champ Type Description mandé, ou faculta-
tif ?
Une représentation sous forme de chaîne de carac-
tères d'un identifiant unique universel (UUID) qui
chaîne de carac-
ccsId définit le CCS dans lequel le point de localisation Obligatoire
tères
est référencé. Il s’agit de l’identifiant utilisé lors du
référencement interne de ce CCS.
La coordonnée x de la position du point de localisa-
x float32 tion de l’IMR par rapport au point d’origine du CCS, Obligatoire
mesurée en mètres (m).
La coordonnée y de la position du point de localisa-
y float32 tion de l’IMR par rapport au point d’origine du CCS, Obligatoire
mesurée en mètres (m).
La coordonnée z de la position du point de locali-
sation de l’IMR par rapport au point d’origine du
z float32 CCS, mesurée en mètres (m où une valeur négative Obligatoire
indique un emplacement sous le point d'origine du
CCS.
5 Identité et capacités des robots mobiles industriels
Lors d'un démarrage ou d'un changement, les informations de l'IMR indiquées dans le présent document
doivent être fournies, conformément au Tableau 4. Dans le contexte du présent document, ce qui suit doit
s'appliquer:
— les informations “Obligatoire” doivent être fournies;
— les informations “Recommandé” doivent être fournies;
— les informations “Facultatif” peuvent être fournies.

La valeur maximale doit être communiquée si Lorsque l’IMR n’a pas les moyens de détecter ou de consigner
dans un rapport un changement de l’empreinte de l’IMR ou de la hauteur de la zone de travail, de la vitesse
ou du type de charge de l’IMR.
Tableau 4 — Informations sur l’identité et les capacités de l’IMR
Nom du Champ fils (le Obligatoire, recommandé
Type Description
champ cas échéant) ou facultatif ?
chaîne de carac- Une représentation sous forme de chaîne de caractères de
id Obligatoire
tères l'identifiant unique universel (UUID) de l'IMR
YYYY - M M
L'horodatage du message lorsque ces identité et capacité
timestamp -DDThh: mm: ss Obligatoire
sont valides, conformément à l'ISO 8601-1
.fffZ
Une entité est l'émetteur ou le destinataire des messages
chaîne de carac-
entityType JSON définis dans le présent document. Pour un IMR, la Obligatoire
tères
valeur de ce champ doit être IMR
chaîne de carac-
manufacturerName Le nom de l’entreprise du fabricant de l’IMR Obligatoire
tères
chaîne de carac- La version du protocole de l'ISO 21423 utilisé par cet IMR, à
iso21423Version Facultatif
tères partir de la version 1.0
Les capacités des IMRFM conforment à 0; voir le
capabilities Capacité d'objet Obligatoire
Tableau A.3
details { Obligatoire
chaîne de carac-
imrModel Le modèle de l’IMR Obligatoire
tères
imrSerialNum- chaîne de carac-
Numéro de série de l’IMR Obligatoire
ber tères
Tableau Points Un ensemble de coordonnées des points de l’empreinte de
imrFootprint Obligatoire
d'objets l’IMR, en mètres (m); voir le Tableau A.1
imrWorkingA- taleau de Points Un ensemble de coordonnées de l'espace de travail de l'IMR,
Obligatoire
rea d'objets en mètres (m); voir le Tableau A.1
imrHeight float32 La hauteur maximale de l’espace de travail, en mètres (m) Obligatoire
ensemble
La version actuelle du logiciel, fournie sous forme
softwareVer- d'objects de
d'ensemble de tuples avec composant et version; voir le Obligatoire
sions SoftwareVersions
Tableau A.2
versions
priorité de L'IMR pour résoudre les conflits, oùzéro (0) est
priority uint32 Recommandé
la priorité la plus élevée
La vitesse nominale de l’IMR dans la première direction du
ratedSpeed float32 Recommandé
déplacement, mesurée en m/s
supportedChar- chaîne de carac- Le(s) type(s) de chargeur(s) qui peuvent être utilisés par
Recommandé
gerType tères l’IMR
Le nom de l’entreprise du fournisseur de support technique
supportVendor- chaîne de carac-
Recommandé
NOTE Il peut s’agir du fabricant de l’IMR ou d’une entre-
Name tères
prise différente.
SupportVendor-
chaîne de carac- Les informations de contact pour le fournisseur de support
ContactInfor- Recommandé
tères technique, voir Tableau 4
mation object
visualThumb- chaîne de Une image miniature visuelle de l’IMR comme SVG encodé
Recommandé
nailImage caractères(base64) base64
La charge nominale de l'IMR, exprimée en masse (kg),
ratedLoad float32 correspondant à la charge maximale sous une accélération Recommandé
gravitationnelle standard
chaîne de carac-
supportURL URL pour l'interface utilisateur Web Facultatif
tères
imrDocumen- chaîne de carac-
Un lien vers une documentation plus détaillée sur l’IMR Facultatif
tation tères
tableau de chaînes
payloadTypes Les types de charges utiles que l’IMR peut gérer Facultatif
de caractères
TTabableleaauu 4 4 ((ssuuiitte)e)
Nom du Champ fils (le Obligatoire, recommandé
Type Description
champ cas échéant) ou facultatif ?
chaîne de carac-
batteryType Le type de batterie utilisé par l’IMR Facultatif
tères
ensemble de
additionalPro- Propriétés supplémentaires de l'IMR, en fonction des types
propriétés supplé- Facultatif
perties et des applications spécifiques de l'IMR, voir le tableau A.12
mentaires
}
6 Localisation et statut des robots mobiles industriels
6.1 Généralités
Les informations de localisation et de statut de l’IMR doivent être conformes à 6.3.
NOTE Cette information concernant l’emplacement actuel, le mode de fonctionnement et l’état peut faciliter, par
exemple, la visualisation de l’emplacement, la gestion du trafic, entre autres
6.2 Mode de fonctionnement et état de fonctionnement
Les disponibilité, mode de fonctionnement et état de fonctionnement doivent être consignés dans un rapport
sous la forme d’un tableau de chaînes de caractères qui fournit une liste de tous les modes de fonctionnement
actifs et une liste de tous les états actuels de l’IMR. La liste peut être vide si l’IMR n’est dans aucun de ces
états. Les chaînes représentant les états sont ordonnées dans la liste selon la priorité implicite définie par
l’IMR, le mode de fonctionnement apparaissant en premier, suivi de l’état de fonctionnement ayant la priorité
la plus élevée. Les noms de modes et d’états décrits dans le Tableau 5 doivent être utilisés. La liste peut
être étendue en définissant ou redéfinissant de nouvelles chaînes de caractères si c’est pour un objectif non
répertorié dans le Tableau 5.
Les états de fonctionnement applicables doivent être communiqués comme spécifié dans le Tableau 5.
Si l’état MODE_MANUAL, MODE_TELEOP ou MODE_MAINTENANCE est actif, et que l’une ou toutes les
catégories d’arrêt STOP_CATEGORY_0, STOP_CATEGORY_1 et STOP_CATEGORY_2 sont présentes, alors la
communication des états de fonctionnement de la catégorie d’arrêt doit être fournies. Si l’état actif est soit
MODE_AUTO soit MODE_SEMIAUTO, alors les états suivants sont facultatifs ou obligatoires comme indiqué
dans le Tableau 5.
Tableau 5 — Descriptions et exigences concernant l’état de fonctionnement en mode autonome ou
semi-autonome
Obligatoire, recom-
Nom de l’état de fonctionne-
Description mandé ou facultatif, si
ment
acutellement actif
Arrêt non contrôlé en coupant immédiatement l’alimen-
a
STOP_CATEGORY_0 Obligatoire
tation des actionneurs de la machine
Arrêt contrôlé avec alimentation des actionneurs de la
a
STOP_CATEGORY_1 machine disponible pour réaliser l’arrêt, puis coupure de Obligatoire
l’alimentation lorsque l’arrêt est réalisé
Arrêt contrôlé en maintenant l’alimentation des action-
a
STOP_CATEGORY_2 Obligatoire
neurs de la machine
L’IMR est temporairement mis en pause, tout en conser-
PAUSED Recommandé
vant son objectif
L’IMR attend une intervention humaine (par exemple,
WAIT_FOR_RESET Facultatif
réinitialisation) avant de pouvoir fonctionner
MAPPING L’IMR est en train de générer une nouvelle carte Facultatif
a
Les catégories d’arrêt sont définies dans l’IEC 60204-1.

TTabableleaauu 5 5 ((ssuuiitte)e)
Obligatoire, recom-
Nom de l’état de fonctionne-
Description mandé ou facultatif, si
ment
acutellement actif
LOST L’IMR a perdu sa localisation et ne sait pas où il se trouve Obligatoire
L’accessoire sur l’IMR est actif e; la plateforme mobile ne
WAIT_FOR_ATTACHMENT Facultatif
bouge pas
L’IMR est en attente d’un événement externe ou d’une
WAIT_FOR_EVENT Recommandé
saisie
L’IMR est empêché de progresser selon son objectif
BLOCKED Facultatif
actuel; cela inclut les situations de blocage
ATTACHMENT_ACTIVE L’accessoire sur l’IMR est actif Facultatif
STOPPED L’IMR est arrêté Facultatif
L’IMR est en cours d’amarrage avec un autre objet, par
DOCKING exemple un point de transfert, une station de recharge Obligatoire
ou un autre IMR
SLOWING Décélération (« freinage ») Facultatif
ACCELERATING Accélération Facultatif
En approche ou en cours de virage à gauche selon la
LEFT_TURN Facultatif
direction de déplacement
En approche ou en cours de virage à droite selon la
RIGHT_TURN Facultatif
direction de déplacement
L’IMR se déplace principalement en marche arrière
REVERSE Facultatif
(marche arrière prolongée)
L’IMR se déplace principalement en marche avant
FORWARD Facultatif
(marche avant prolongée)
L’IRM suit activement une ligne physique ou virtuelle, et
LINE_FOLLOWING Facultatif
est dans l’incapacité de la quitter
CHARGING L’IMR est en charge et ne peut pas se déplacer Obligatoire
LOW_BATTERY Condition de batterie faible Recommandé
L’IMR n’est actuellement pas engagé dans une com-
IDLE Obligatoire
mande, une mission, une tâche ou une affectation
PARKED L’IMR est garé Obligatoire
OFFLINE L’IMR est hors ligne Facultatif
MODE_AUTO Mode autonome
MODE_SEMIAUTO Mode semi-autonome ou mode manuel assisté
Mode de téléopération; mode qui permet le contrôle
MODE_TELEOP
direct par un opérateur à distance ou un télé-opérateur
MODE_MANUAL Mode manuel
MODE_MAINTENANCE Mode de maintenance
a
Les catégories d’arrêt sont définies dans l’IEC 60204-1.
6.3 Données de statut obligatoire
Le message contenant ces informations doit être envoyé lorsque les informations décrites dans le Tableau 6
changent. Les fréquence minimale et fréquence maximale doivent être définies. Les formats de message
doivent être conformes à l'Annexe B.
NOTE Les informations à propos du statut et de l'emplacement de l'IMR et sont susceptibles d'être mises à jour à
une fréquence plus élevées que ne le sont les informations à propos de l'identité et de la capacité de l'IMR.

Tableau 6 — Informations sur l’identité et les capacités de l’IMRFM
Obligatoire, recom-
Nom du champ Type Description
mandé ou facultatif ?
chaîne de Une représentation sous forme de chaîne de carac-
id Obligatoire
caractères tères de l'identifiant unique universel (UUID)de l'IMR
AAAA -M M
timestamp -JJThh: mm: ss L’horodatage du message conformément à l’ISO 8601 Obligatoire
.fffZ
L'emplacementactuel de l'IMR,, fournie sous forme
softwareVersions- objet de Point
d'objet de point d'emplacement conformément au 4.4; Obligatoire
a
locationPoint d'emplacement
voir le Tableau 3.
Le mode de fonctionnement et la liste de tous les
chaîne de
operatingStates modes de fonctionnement actuellement actifs, confor- Obligatoire
caractères
mément au Tableau 5
a
linearVelocity float32 Vitesse linéaire actuelle en m/s Recommandé
angularVelocity a float32 Vitesse angulaire actuelle en radians/s Recommandé
Information concernant le statut de la batterie de
objet de statut
batteryStatus l'IMR, par exemple, le pourcentage de charge restant, Recommandé
de batterie
voir le Tableau A.5
objet de la
localTrajectory trajectoire de La trajectoire locale de l'IMR; voir le Tableau A.6 Recommandé
l'objet
objetChemin
globalPath Le chemin global de l'IMR; voir le Tableau A.8 Recommandé
global
globalPlan objetPlanglobal Le plan global de l'IMR; voir le Tableau A.11 Facultatif
loadPercenta-
float32 Pourcentage de la charge maximale utilisée Facultatif
b
geUsed
a
locationPoint, linearVelocity et angularVelocity sont publiés dans le cadre de l'odométrie; voir B.5.7 pour un exemple.
b
Il s'agit d'une propriété spécifique à l'IMR qui indique combien la capacité de charge de l'IMR est utilisée, où 100 %
correspond à une charge maximale. Cette valeur peut correspondre à n'importe quelle combinaison de volume, de
surface et de poids, comme spécifié dans les instructions d'utilisation.
7 Identité et capacités du gestionnaire de flotte de robots mobiles industriels
Lors d'un démarrage ou d'un changement, les informations de l'IMRF indiquées au Tableau 7 doivent être
fournies.
Tableau 7 — Information sur l'identité et les capactités de l'IMRFM
Nom du Obligatoire,
Champ fils (le
champ Type Description recommandé ou
cas échéant)
(parent) facultatif?
Une représentation sous forme de
chaîne de carac-
id chaîne de caractères de l'identifiant Obligatoire
tères
unique universel (UUID)de l'IMRF
L’horodatage du message lorsque cette
YYYY -MM -DDThh:
timestamp identité et capacité est valide conformé- Obligatoire
m m: s s . f f f Z
ment à l’ISO 8601-1
Une entité est l'émetteur ou le destina-
chaîne de carac- taire des message JSON définis dans le
entityType Obligatoire
tères présent document. Pour un IMRFM, la
valeur de ce champ doit être IMRFM
chaîne de carac- Le nom de l'entreprise du fabricant de
manufacturerName Obligatoire
tères l'IMRFM
version du protocole de l'ISO 21423 uti-
chaîne de carac-
iso21423Version lisé par l'IMRFM, à partir de la version Optional
tères
1.0
Les capacités de l'IMRFM conformément
capabilities Capabilities object Obligatoire
à B.5.2.3; voir le Tableau A.3
details {
La version actuelle du logiciel fournie
ensemble d'objets
sous forme d'ensemble d'objets avec
softwareVersions SoftwareVersion Obligatoire
un composant et une version; voir le
objects
Tableau A.2
imrfmModel chaîne de carac-
Le modèle de l' IMRFM Recommandé
tères
supportVendor- Objet SupportVen- Les informations de contact pour le
ContactInf dorContactInfor- fournisseur de support technique; voir Recommandé
mation le Tableau A.4
supportURL chaîne de carac-
URL pour l'interface utilisateur Web Facultatif
tères
imrfmDocumen- chaîne de carac- Un lien vers une documentation de
Facultatif
tation tères l'IMRFM plus détaillée
}
8 État du gestionnaire de flotte de robots mobiles industriels
Les informations sur le statut de l’IMRFM doivent être fournies à d’autres IMR, IMRFM et systèmes associés,
conformément au Tableau 8 et Tableau 9, pour faciliter l’interopérabilité en permettant à toutes les entités
recevant l’information de connaître des détails sur l’état de l’IMRFM.
Le message concernant le statut de l'IMRFM, tel que détaillé au Tableau 8, doit être envoyé lorsque les
informations décrites au Tableau 9 changent. Les fréquences minimale et maximale doivent être définies.

Tableau 8 — Descriptions du statut de l'IMRFM
Obligatoire, recom-
Nom du champ Type Description
mandé ou facultatif?
Une représentation sous forme de chaîne de carac-
chaîne de
id tères de l'identifiant unique universel (UUID)de Obligatoire
caractères
l'IMRFM
Y Y Y Y -M M
L’horodatage du message lorsque cette identité et
timestamp -DDThh: mm: ss Obligatoire
capacité est valide conformément à l’ISO 8601-1
.fffZ
ensemble de
states chaînes de statut actuel de l' IMRFM Obligatoire
caractères
L'IMRFM doit reporter son état à partir de la liste d'états disponible dans le Tableau 9.
Tableau 9 — Descriptions et exigences concernant l’état de fonctionnement de l'IMRFM
Nom de l'état de fonction- Obligatoire, recommandé, facultatif
Description
nement
READY Prêt à envoyer et recevoir des messages
NOT_READY Non prêt à envoyer ou recevoir des mes- L'un de ces états est précisément Obliga-
sages toire
OFFLINE IMRFM non connecté
9 Messages de requêtes
L’IMR ou l’IMRFM doit être capable d’envoyer et de recevoir des messages de requête et requestStatus. Les
messages doivent suivre le format décrit dans l’Annexe C. Les IMR ou IMRFM qui peuvent consigner leur
emplacement dans un rapport doivent être capables d’envoyer et de recevoir les messages move, pauseImr,
resumeImr et cancel tels que décrits dans l’Annexe B.
L'émetteur et le récepteur doivent interagir à travers la séquence ci-dessous:
a) L'émetteur envoie un message de requête à un récepteur identifié.
b) Le récepteur répond par un message requestStatus dès qu'un changement d'état survient pour ce
message de requête; les changements d'état dépendent du contenu du message de requête, comme le
montrent les Figure C.3 et Figure C.4.
c) Lorsque la requête est terminée, le dernier message requestStatus indiquera que le message est annulé
(CANCELED), réussi (SUCCEEDED) ou abandonné (ABORTED).
NOTE À la base, les messages sont utilisés par un émetteur pour demander à un récepteur d'effectuer une action
ou une séquence d'actions.
...