Autonomous system and fleet management system interoperability

This document defines the interfaces required between the fleet management (FMS) and autonomous haulage (AHS) systems for dispatch of haul trucks and coordination of production information, including communication protocols, message structures, telemetry signals, map sharing and task assignments. This document applies to surface mining. It specifies requirements and recommendations to achieve the following: — realtime computer system communication; — message definition and semantic; — mine map sharing; — truck dispatching; — truck production monitoring. This document does not address computer system authentication, authorization and cyber security. These methods and technologies are already covered by best practice IT deployments. The specific requirements for safe operation of machines, including execution of task assignments issued by the FMS to the AHS rely on additional information that is agreed between the FMS and AHS supplier which is outside the scope of this document.

Interopérabilité du système autonome et du système de gestion de la flotte

General Information

Status
Published
Publication Date
05-Aug-2024
Current Stage
6060 - International Standard published
Start Date
06-Aug-2024
Due Date
01-Sep-2024
Completion Date
06-Aug-2024
Ref Project
Standard
ISO 23725:2024 - Autonomous system and fleet management system interoperability Released:6. 08. 2024
English language
87 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


International
Standard
ISO 23725
First edition
Autonomous system and
2024-08
fleet management system
interoperability
Interopérabilité du système autonome et du système de gestion de
la flotte
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviations . 1
3.1 Terms and definitions .2
3.2 Abbreviations .2
4 Computer communication . 3
4.1 Session and transport layer .3
4.1.1 WebSocket client and service behaviour .4
4.2 Presentation layer .4
4.2.1 Container, serialization, and encoding.4
4.2.2 JSON container .4
4.2.3 NULL attribute .4
4.2.4 Units . .4
4.2.5 On machine component arrays .5
5 Messaging . 6
5.1 Overview .6
5.2 Event based messaging .6
5.3 Message header .7
5.3.1 General .7
5.3.2 Header example .7
5.4 Messages during connection outage .8
5.5 Out of standard message .8
5.5.1 General .8
5.5.2 Out of standard examples .8
5.6 Common attribute enumeration .9
5.6.1 General .9
5.6.2 Actor .9
5.6.3 Action request.9
5.6.4 Action response .10
5.6.5 Action status .10
5.6.6 Autonomy mode .10
6 System messaging . 10
6.1 General .10
6.2 Fleet definition message .10
6.2.1 General .10
6.2.2 Fleet ID . 12
6.2.3 Equipment type . 12
6.2.4 Autonomous . 13
6.2.5 Equipment length and width . 13
6.2.6 Fleet definition example . 13
6.3 Machine all-stop . 15
6.3.1 Optional feature . 15
6.3.2 Scope of effect . 15
6.3.3 Machine all-stop status message . 15
6.3.4 Machine all-stop request message .16
6.3.5 Machine all-stop response message .17
6.3.6 Machine all-stop examples .18
7 Generic machine telemetry .20
7.1 Message content . 20
7.2 Data streams . 20

iii
7.3 Machine position . 20
7.3.1 Machine coordinate system and frame of reference . 20
7.4 Machine position message .21
7.4.1 Machine position examples . 23
7.5 Basic machine health message . 25
7.5.1 Basic machine health message example .27
8 Generic machine messaging .27
8.1 Message content .27
8.2 Machine autonomy mode message .27
8.3 Machine dispatch availability . 28
8.3.1 General . 28
8.3.2 Purpose . 29
8.3.3 Machine Dispatch Availability message . 29
8.3.4 Trigger the FMS to re-send an assignment . 29
8.3.5 Impending custodian change . 30
8.3.6 Machine dispatch availability example . 30
8.4 Machine diagnostic message .32
8.4.1 General .32
8.4.2 Purpose .32
8.4.3 Component identification number .32
8.4.4 Fault Code number . 33
8.4.5 AHS documentation . 33
8.4.6 Connection time . 33
8.4.7 When the last fault clears . 33
8.4.8 Machine diagnostic message examples . 34
9 Routing .35
9.1 Map connectivity . 36
9.1.1 Purpose . 36
9.1.2 Map Connectivity message . 36
9.1.3 Clarification of unidirectionality of connections .37
9.1.4 Understanding the specification by example .37
10 Map service .44
10.1 Map object concepts . . 44
10.2 Map object identification number rules and restrictions . 44
10.2.1 Restrictions on object identification numbers . 44
10.2.2 Identification numbers rules for ways and nodes .45
10.3 Map format .45
10.3.1 Map document encoding .45
10.3.2 Splitting a large map into chunks . 46
10.3.3 Point – node element . 46
10.3.4 Line – way element .47
10.3.5 Road . 48
10.3.6 Lane . 48
10.3.7 Area . 49
10.4 Adding context to objects .51
10.4.1 Tag Element Attribute Encoding .51
10.4.2 Standard tags .52
10.4.3 Tag with Attribute k = ’name’ .52
10.4.4 Tag with Attribute k = ’default task’ . 53
10.4.5 Tag with Attribute k = ’autonomy’ . 53
10.4.6 Tag with Attribute k = ’autonomy:area’. 54
10.4.7 Tag with Attribute k = ’oneway’ . 54
10.5 Map building . 55
10.5.1 Connecting map objects . 55
10.5.2 Building a purely structured road model . 55
10.5.3 Purely structured rules . . 55
10.6 Map service messaging . 56

iv
10.6.1 Map service identification . 56
10.6.2 Map Service Identification V1 . 56
10.6.3 Map summary . 56
10.6.4 Map command – get summary . 58
10.6.5 Map command – get all .59
10.6.6 Map document message .59
11 Interface diagnostic .60
11.1 Interface diagnostic information . 60
11.1.1 Diagnostic measurement information . 60
11.1.2 Diagnostic message information.61
12 Haul truck production.63
12.1 Message content . 63
12.2 Production cycle message . 63
12.3 Production cycle definition . 63
12.3.1 Definition of a haul truck cycle . 64
12.3.2 Proposed state decision tree . 64
12.4 Haul truck production state message . 65
12.4.1 Haul truck production state V2 . 66
12.5 Haul truck production state sensor V1 . 66
12.5.1 Haul truck production state sensor V1 .67
12.6 Haul truck payload message . 68
12.7 Operational context. 69
12.8 Haul truck dump message . 69
13 Haul truck assignment.70
13.1 Message content .70
13.2 Haul truck task assignment types .71
13.3 Haul truck assignment message .71
13.3.1 Precondition and behaviour .71
13.3.2 Current assignment .71
13.3.3 Future assignment .71
13.3.4 Responsibility of safe execution .71
13.3.5 Haul truck assignment request message .71
13.3.6 Haul truck assignment response message . 73
13.3.7 Haul truck assignment rejection . 75
13.3.8 Haul truck assignment reset message .76
13.3.9 Haul truck assignment message . 77
Annex A (informative) Example of message exchange .79
Annex B (informative) External IT infrastructure .86
Bibliography .87

v
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 document 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 82, Mining, SC 8, Advanced automated mining
systems.
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.

vi
Introduction
A strategic objective for the global mining industry is to develop standards to support holistic, integrated and
interoperable mine operating automation that will improve mining operations efficiency. Interoperability
enables many benefits; optimal interaction of mine operating equipment and processes, integration of
upstream process information (e.g. exploration, resource modelling and planning), minerals extraction
and downstream processes (e.g. refining, smelting and transportation) to increase levels of operational
efficiency. This document progresses interoperability in the global mining industry.
The purpose of this document is to define a reproducible integration of an autonomous haulage system
(AHS) and a fleet management system (FMS) to avoid customized implementations at every site. It allows a
supplier with a narrow product coverage but highly valuable core mining competencies to participate and
deliver open-autonomy components in the overall autonomy technology stack.
This document defines a software API, an open-autonomy interface, that allows independent vendors
to supply an FMS to dispatch an AHS autonomous fleet. The API allows for future innovations and a wide
variety of implementations without requiring a modification to the protocol.
This document interface aims to create an API that will deliver:
— system wide source of truth digital map and machine positions on this map
— dispatch functionality of autonomous trucks to support material movement, fuelling, and parking.
— generate autonomous equipment production monitoring.
The scope for viable interoperability between the AHS and FMS is the API and that is the focus of this
document.
vii
International Standard ISO 23725:2024(en)
Autonomous system and fleet management system
interoperability
1 Scope
This document defines the interfaces required between the fleet management (FMS) and autonomous
haulage (AHS) systems for dispatch of haul trucks and coordination of production information, including
communication protocols, message structures, telemetry signals, map sharing and task assignments.
This document applies to surface mining. It specifies requirements and recommendations to achieve the
following:
— realtime computer system communication;
— message definition and semantic;
— mine map sharing;
— truck dispatching;
— truck production monitoring.
This document does not address computer system authentication, authorization and cyber security. These
methods and technologies are already covered by best practice IT deployments.
The specific requirements for safe operation of machines, including execution of task assignments issued by
the FMS to the AHS rely on additional information that is agreed between the FMS and AHS supplier which is
outside the scope of this document.
2 Normative references
The following documents are referred in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, on the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 8601 (all parts), Date and time — Representations for information interchange
ISO 11992-2, Road vehicles — Interchange of digital information on electrical connections between towing and
towed vehicles — Part 2: Application layer for brakes and running gear
3 Terms, definitions and abbreviations
For the purposes of this document, the following terms and definitions 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
all-stop function
function that brings all autonomous machines under the operator’s supervision to a halted state when
initiated
[SOURCE: ISO 17757:2019, 3.1.18, modified — The word "system" was replaced by "function".]
3.1.2
actor
software involved in communication over a connection, either providing a service or using a service
3.1.3
attribute
term attribute referencing to a key as opposed to an “object”
3.1.4
operator
person having control and responsibility for operating a machine or the autonomous haulage system
3.1.5
manual mode
mode of operation in which a machine is controlled by an operator (3.1.4) who is responsible for monitoring
the surroundings and for safe operation of all machine controls
[SOURCE: ISO 17757:2019, 3.1.13]
3.1.6
pose
machine position and orientation (heading)
Note 1 to entry: The pose needs a standard frame of reference {0,0,0} for each machine so they are properly placed in
space for any coordinate systems.
3.1.7
tray
that portion of a dumper which carries material
3.1.8
risk assessment
overall process comprising a risk analysis and a risk evaluation
[SOURCE: ISO 12100:2010, 3.17]
3.2 Abbreviations
AOZ autonomous operating zone
API application program interface
AHS Autonomous Haulage System
FMS fleet management system
GNSS global navigation satellite system
GUID globally unique identifier
IANA Internet Assigned Numbers Authority

JSON Java Script Object Notation
LV light vehicle
UID unique identification
TLS transport layer security
SOP Standard Operating Procedure
SSL secure socket layer. Synonymous with TLS. TLS is the newer version of SSL
TUM time usage model
wss:// web socket secure
4 Computer communication
The goals of the protocol design shall be
a) event based (no polling),
b) bi-directional,
c) cloud friendly  (leverage web technologies),
d) rapid disconnection detection, and
e) events are sent immediately,
Standard IT infrastructure is not the primary focus of this document. This document does not specify:
— security,
— authentication,
— redundancy,
— scaling,
— encryption, and
— certificates.
These functions should be implemented to support the demand of each specific deployment. See Annex B for
more details.
4.1 Session and transport layer
The client system shall use a TCP/IP websocket secure (wss://) to connect to services defined in this
document.
Once the connection is established, then the state of each data models shall be shared (not necessarily
synchronized) between the client and the server.
Once the data models are shared, then each system shall update the other system through the wss://
connection as events and states change.

4.1.1 WebSocket client and service behaviour
The following should be behaviours of the WebSocket client and server:
— WebSocket clients should implement an automatic re-connection to the WebSocket server if the
connection is lost.
— WebSocket servers (listeners) should implement a configurable Ping in accordance to RFC6455,
Section 5.5.2.
— WebSocket clients may implement a configurable Ping in accordance to RFC6455, Section 5.5.2.
NOTE Some WebSocket implementations will close the connection if there is no frame transferred for a certain
amount of time. RFC 6455, Section 5.5.2 provides a Ping-Pong function to prevent premature closure.
4.2 Presentation layer
The presentation layer is defined by OSI, presentation layer - ISO/IEC 7498-1 (basic model).
4.2.1 Container, serialization, and encoding
The following specifications shall apply to container, serialization, and encoding (see Table 1):
Table 1 — Container, serialization and encoding
Layer Specifications
Container JSON ECMA-404
Serialization English text
Encoding UTF-8
4.2.2 JSON container
The JSON notation shall be used in English human readable form to represent serialized object.
4.2.3 NULL attribute
If an attribute is required in a message (see 7.5) but is un-instrumented on the machine (i.e., it does not exist
physically) from the sender, then the attribute shall be set to ‘null’.
NOTE Null has a different semantic than 0 and different from an empty array. NULL means it is absent. An empty
array means that at the moment the list is empty, but the array may grow beyond empty in the future. Semantically, a
zero value does not imply unknown, broken or invalid unless otherwise stated in the specification.
4.2.4 Units
The exchanged attributes shall use a common set of units for the different measurements. The following
units shall be used for value transmission (see Table 2):
Table 2 — Measurement units
Measurement Unit
UTC Date time stamp ISO 8601 (all parts)
Time seconds
Distance meter
Speed km/h
Angle degree
Temperature Celsius
TTaabblle 2 e 2 ((ccoonnttiinnueuedd))
Measurement Unit
Pressure kPa
Mass kg
Heading degree
4.2.5 On machine component arrays
ISO 11992-2 shall be used to identify a particular tire/wheel and axle position. For consistency, the same
numbering method shall be used to identify a particular machine component when there are multiple
component instances on a machine.
Machine components shall be numbered according to their position on the machine. Represented as a 2D
coordinate in the form {ROW, COLUMN}. Rows are starting from the front to the back of the machine in
accordance to their position.
Row numbering shall start at 1.x, and increasing in increments of 1 (i.e. 1.x, 2.x, etc.). Objects to the left of
the middle should count down from .7 and objects to the right of the middle should count up from .9. An odd
cardinality of components (a middle component) shall be assigned ROW#.8 (ROW# corresponding to the
specific row number).
The following examples clarify when and how to use ROW#.8 for odd and even number of items; Figure 1
and Figure 2 a) and b) provide examples of component numberings.

a
Forward driving direction.
Figure 1 — Example of tire number on 9-wheel rig (adapted from ISO 11992-2:2014)

a) b)
Figure 2 — Example of tire and strut numbering on a rigid dump truck
Figure 2 a) is numbering the tires of a rigid dump truck. The procedure is
— to orient the machine’s front pointing upwards.
— All tires of the first row start with a “1.”, the one to the left is “1.7” and the one on the right is “1.9”. There
is no “1.8” because there is no tire in the middle.
— All tires of the second row start with a “2.”, the one to the most left is “2.6”, then its right neighbour is
“2.7”. The 2 tires to the right of the middle are “2.9” and “2.10” is the right most.
Figure 2 b) is simpler as we’re numbering the truck struts, use the same approach, the machine is oriented
forward then follow the algorithm.
5 Messaging
5.1 Overview
The interface shall use asynchronous messaging and be compliant to the rule set in Clause 4, which defines
the transport, container, encoding and behaviour.
Annex A contains a set of sequence diagram as examples of how the messages are expected to be used
between the systems. Annex A should be consulted to understand how they are intended to be used under
typical circumstances.
5.2 Event based messaging
— A message shall be sent when a state or measurement is changed within the monitored system.
Continuously changing measurements shall be limited to a maximum message sending frequency.
— The maximum frequency shall be configurable on a per message type basis on the sending application
during commissioning.
— Unchanged state messages shall not be sent periodically based on a timer.

5.3 Message header
5.3.1 General
All messages in conformity with to this document shall contain the message header as described in Table 3.
Table 3 — Message header
Req.
Attribute Type Exactly Description
Level
A unique human readable string used to identify
Protocol shall UKey ISO23725 that this message object is compliant with th
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...