ISO 5231:2022
(Main)Extended farm management information systems data interface (EFDI) — Concept and guidelines
Extended farm management information systems data interface (EFDI) — Concept and guidelines
This document specifies an extensible communication system concept and defines rules for adding new functionalities to cover specific use cases.
Interface de données des systèmes d'information de gestion d'exploitation agricole étendue (EFDI) — Concept et lignes directrices
Le présent document spécifie un concept de système de communication extensible et définit les règles d’ajout de nouvelles fonctionnalités afin de couvrir les cas d’utilisation spécifiques.
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 5231
First edition
2022-10
Extended farm management
information systems data interface
(EFDI) — Concept and guidelines
Reference number
ISO 5231:2022(E)
© ISO 2022
---------------------- Page: 1 ----------------------
ISO 5231:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
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
© ISO 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 5231:2022(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Architectural overview . 3
5 Network . 4
5.1 Overview . 4
5.2 Onboarding service . 5
5.3 Connected networks . 5
6 Messaging . 5
6.1 Overview . 5
6.2 Hierarchical structure of scenario sets, scenario flows and scenarios . 5
6.2.1 General . 5
6.2.2 Scenario . 6
6.2.3 Scenario flow . 8
6.2.4 Scenario set . 8
6.2.5 Detailed view on a scenario . 8
6.3 Addressing . . 11
6.3.1 General . 11
6.3.2 Endpoint capabilities .12
6.3.3 Endpoint subscriptions. 13
6.3.4 Messaging component capabilities . 13
6.4 Endpoint architecture . 14
6.4.1 Overview . 14
6.4.2 Endpoint’s inbox and outbox . 14
6.4.3 Endpoint’s feed . 15
6.5 Connection establishment . 16
6.6 Authorization . 17
6.7 Streaming . 17
6.8 Chunking . 18
6.9 Error handling . 18
7 Formal and semantic description .18
7.1 General . 18
7.2 Noun . 19
7.3 Scenario . 19
7.4 Scenario flow . 20
7.5 Scenario set . 21
7.6 Documentation structure . 21
7.7 Structure of protobuf files. 21
7.7.1 General structure . 21
7.7.2 Error code structure .22
8 Transport layer mapping .23
8.1 General .23
8.2 Service discovery . 24
8.2.1 General . 24
8.2.2 Internet based . 24
8.2.3 Local Area Network .25
Annex A (informative) OAGIS Verbs .26
Annex B (informative) Transition of ISO 11783-10 elements to Protobuf .27
iii
© ISO 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 5231:2022(E)
Bibliography .32
iv
© ISO 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 5231:2022(E)
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
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 23, Tractors and machinery for agriculture
and forestry, Subcommittee SC 19, Agricultural electronics.
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.
v
© ISO 2022 – All rights reserved
---------------------- Page: 5 ----------------------
ISO 5231:2022(E)
Introduction
Participants in the agricultural environment are dealing with the necessity of exchanging data with
various systems and interfaces. With increasing demand for process monitoring and control, and just-
in-time information on task execution state, and at the same time integration of mobile devices into
farm work processes, the need of a standardized way for data exchange arises.
vi
© ISO 2022 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 5231:2022(E)
Extended farm management information systems data
interface (EFDI) — Concept and guidelines
1 Scope
This document specifies an extensible communication system concept and defines rules for adding new
functionalities to cover specific use cases.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
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
network
group of two or more participants connected to each other via a server
3.2
endpoint
uniquely addressable instance within a network
Note 1 to entry: An endpoint can be a farm management information system (FMIS), a telemetry unit, a terminal
or a complete machine.
Note 2 to entry: The server is also an endpoint.
3.3
client
C
endpoint that communicates with the server
3.4
server
S
central component for communication in a network
Note 1 to entry: All communication is done via the server.
3.5
messaging component
MC
part of the server and network management
Note 1 to entry: The messaging component (MC) keeps track of logged-in endpoints and their capabilities and is
also responsible for the delivery and forwarding of messages.
1
© ISO 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 5231:2022(E)
3.6
noun
type of a message
3.7
verb
action which is executed with a specific noun
3.8
scenario
order in which the request and response messages shall be performed
Note 1 to entry: Every request and response consists of a verb and a noun.
3.9
scenario flow
sequence of scenarios
Note 1 to entry: Scenario Flows define how scenarios are related to each other and how they are to be executed
in dependence on each other.
3.10
scenario set
group of scenario flows
3.11
A-Step
request that is sent from client A to client B
3.12
B-Step
request that is sent from client B to client A
3.13
streaming
subscription to specific types of messages and subsequently reception of unsolicited information
3.14
onboarding
initial access or registration of an endpoint
3.15
onboarding service
service enabling clients to access a network
3.16
protocol buffers
protobuf
data structures that can be serialized in compact binary representation
Note 1 to entry: In this document protocol buffers version 3 (proto3) applies to all definitions. See also https://
developers .google .com/ protocol -buffers/ docs/ proto3
3.17
message queue telemetry transport
MQTT
standardized transport protocol with publish-subscribe paradigm
Note 1 to entry: In this document MQTT 3.1.1 applies to all definitions. See also http:// docs .oasis -open .org/ mqtt/
mqtt/ v3 .1 .1/ os/ mqtt -v3 .1 .1 -os .html
2
© ISO 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 5231:2022(E)
3.18
hypertext transport protocol secure
HTTPS
set of rules for secure transferring data over the internet or a local network
Note 1 to entry: See also https:// datatracker .ietf .org/ doc/ html/ rfc2818
3.19
semantic versioning
concept for defining version numbers to software.
Note 1 to entry: Semantic versioning allows to imply compatibility information to a version number, see also
https:// semver .org/ .
3.20
VDMA Database
contains all ISO5231 definitions for scenario sets, scenario flows, scenarios and message.
Note 1 to entry: Database can be accessed at https:// isobus .net/ isobus/ efdi
3.21
transport layer security
TLS
protocol for secure communication over the internet
3.22
transport layer security certificates
TLS-CERTS
certificates providing information for encryption of communication
3.23
extensible messaging and presence protocol
XMPP
application profile for data exchange
3.24
fully qualified domain name
FQDN
location with all its domain levels
4 Architectural overview
The extended farm management data interface consists of a set of layers packaged on top of the network
application layer as illustrated in Figure 1.
3
© ISO 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 5231:2022(E)
Figure 1 — Layer model
The selected message transport protocol to show how to implement EFDI is based on the MQTT protocol
as the message transport layer. However, the application layers (see Figure 1) are not bound to it.
Messages are partitioned into a header and a payload. The header shall contain addressing information
and may contain additional data for setting up a stateful, persistent session. Depending upon lower-
layer transport protocol functionalities, the additional data may be omitted and instead be covered
by the transport protocol layer. It is theoretically possible to transport any payload within the EFDI
protocol. However, transfer of ISO 11783-10 data is explicitly described within Annex B. There is also
a generic file transfer handling described by the basic file functionality scenario set. Apart from the
use case specific layer sitting on the top-most position of the stack, EFDI provides a semantic layer to
indicate to message receivers what to do with the data (execute task, replace element within task, etc.).
The definition of generic protocol layer is described in Clause 6. The rules for semantics are defined in
Clause 7 and the transport layer mapping is described In Clause 8.
5 Network
5.1 Overview
This clause gives an overview about the different components that are part of the network as shown in
Figure 2.
Figure 2 — Components in a network
4
© ISO 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 5231:2022(E)
Clients can establish a connection to the server. All endpoints in the network can communicate to each
other.
5.2 Onboarding service
The onboarding service (OS) is part of the server component of the network. It is a service with which an
endpoint can connect to the network. Individual IDs and certificates are generated, which are necessary
for subsequent communication. The onboarding is part of the registration process of an endpoint.
5.3 Connected networks
Interconnecting multiple networks can be achieved by implementing a server containing both a
messaging component and a client.
In Figure 3, server A handles the directly connected clients via its messaging component. Additionally,
server A connects as a client to server B. Through this connection server A indirectly connects to clients
through server B. Depending on the provided capabilities of server A’s client, server B may also be able
to indirectly connect to server A’s clients.
Figure 3 — Components in connected networks
6 Messaging
6.1 Overview
This clause presents various basic concepts of how communication takes place. It includes description
of the construction of messages, architectural structures, addressing and streaming.
6.2 Hierarchical structure of scenario sets, scenario flows and scenarios
6.2.1 General
The hierarchical structure of scenario sets, scenario flows and scenarios are depicted in Figure 4.
Generally, the scenario set is the topmost item, which contains at least one scenario flow. Each scenario
flow contains at least one scenario. A scenario consists of a request and a response. Both a request and
a response consist of a combination of a verb and a noun.
5
© ISO 2022 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 5231:2022(E)
Figure 4 — Hierarchical structure of scenario sets, scenario flows and scenarios
All of the described messaging follows a common process. This common process is described in 6.2.2 to
6.2.5.
6.2.2 Scenario
A sequence of request and response messages is called a scenario. All of the scenarios have a request-
response messaging pattern. That means that there is a defined response for a specific request. The
request is sent by an endpoint and the response is sent back by another endpoint.
The requests and responses are defined as a combination of verb and noun. This verb-and-noun concept
is based on the Business Object Document specified by the Open Applications Group Integration
Specification (OAGIS), see Annex A for additional information. The verb defines the action or actions
that are desired for the included business information. The business information itself is contained in
the other sub-section called a noun.
An example is a scenario for requesting the list of endpoints that are connected to the server shown
in Figure 5. The request contains the verb GET and the noun ListEndpoints. Translated this means
that the list of connected endpoints is requested. The response contains the verb SHOW and the noun
ListEndpointsResponse. Translated, this means that the list of connected endpoints is returned.
6
© ISO 2022 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 5231:2022(E)
Figure 5 — ListEndpoints scenario
The schematic representation can be seen in Figure 6. Additional information and how scenarios shall
be described formally can be found in 8.2.
Figure 6 — Schematic representation of scenario
The list of available verbs based on the OAGIS standard has been extended in order to cover new use
cases. The following verbs have been added:
— FORWARD: shall only be used by the server, indicates that a message was received and will be
forwarded to other endpoints. A more detailed explanation and when this verb is used can be found
in 6.2.5;
— STREAM_START: to request streaming data, indicates that the endpoint would like to receive
streamed data from now on;
— STREAM_STOP: indicates that the endpoint no longer wishes to receive streamed data;
— STREAM_DATA: necessary to mark streamed data.
More detailed information about the new verbs for streamed data can be found in 7.6.
7
© ISO 2022 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 5231:2022(E)
6.2.3 Scenario flow
A scenario flow consists of at least one scenario. The order of the scenarios is described within the flow.
Scenarios in a scenario flow can be optional. If scenarios are declared as optional, they do not need to
be executed.
The sender of the first request in a scenario flow is called endpoint A, the other endpoint is called
endpoint B for the whole addressed communication in a scenario flow. When A sends the request to
B, this is called an A-Step. When B sends the request to A, this is called a B-Step. This is visualized in
Figure 7. Additional information and how scenario flows shall be described formally can be found in 7.4.
Figure 7 — Schematic representation of a scenario flow
6.2.4 Scenario set
A scenario set consists of at least one scenario flow. A scenario set is a grouping that can be used, e.g. for
certification, if necessary. Additional information and how scenario flows shall be described formally
can be found in 7.5.
Currently, there is only one scenario set defined. This scenario set is called basic and contains all
scenario flows necessary for basic communication.
6.2.5 Detailed view on a scenario
From an application point of view, an example scenario is shown in Figure 7. A request is sent by one
endpoint and the response is sent back by another endpoint. If we take a more detailed look at it, we
get a different result. Endpoints do not communicate directly with each other like it is shown in 5.1.
Instead, endpoints exchange messages between each other using the server/messaging component. The
simplified representation, which only consists of one request and response pair, is actually split into
8
© ISO 2022 – All rights reserved
---------------------- Page: 14 ----------------------
ISO 5231:2022(E)
four sub-scenarios. Figure 8 shows sub-scenarios that are implicitly being executed in scenarios where
information is exchanged between two endpoints via the server/messaging component.
The four sub-scenarios are the following which can also be seen in Figure 8:
— Sub-Scenario Endpoint Request (Sub_1)
— Request (Endpoint A to Server): VERB [Noun]
— Response (Server to Endpoint A): FORWARD [ForwardInfo]
— Sub-Scenario Forward Endpoint Request (Sub_2)
— Request (Server to Endpoint B): VERB [Noun]
— Response (Endpoint B to Server): CONFIRM [ ]
— Sub-Scenario Endpoint Response (Sub_3)
— Request (Endpoint B to Server): VERB [Noun]
— Response (Server to Endpoint B): FORWARD [ForwardInfo]
— Sub-Scenario Forward Endpoint (Sub_4)
— Request (Server to Endpoint A): VERB [Noun]
— Response (Endpoint A to Server): CONFIRM [ ]
The contents of Figure 8 are described in detail.
1) Endpoint A sends the request of the scenario that is described within the scenario definition.
This request is sent to the server. The server directly sends a ForwardInfo message as response.
The server’s response contains, among other things, the information that the message has been
forwarded.
2) The server sends a message to endpoint B. This message contains the verb and noun of the message
the server received from endpoint A. The reception of this message shall be confirmed by the
recipient endpoint B. The confirmation contains the verb CONFIRM without a noun. The CONFIRM
message is intended to confirm the reception of a message sent between the server and endpoint A.
In the end, endpoint A will receive the verb-noun message of endpoint B as response.
3) Endpoint B creates the response message described in the scenario definition. This message will
be sent as a request message to the server. The server directly sends a ForwardInfo message as
response. The server’s response contains, among other things, the information that the message
has been forwarded.
4) The server sends a message to endpoint A. This message contains the verb and noun of the message
the server received from endpoint B. The reception of this message shall be confirmed by the
recipient endpoint A. The confirmation contains the verb CONFIRM without a noun. The CONFIRM
message is intended to confirm the reception of a message sent between the server and endpoint B.
All these steps can be abstracted from the scenarios, since it is the communication in the layer below the
scenario definitions. For this reason, the scenarios are always presented in a simplified form – as it can
be seen in Figure 7. But all the mentioned sub-scenarios are necessary for successful communication.
9
© ISO 2022 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 5231:2022(E)
Figure 8 — Detailed schematic representation of scenario flow
In a scenario where the response contains the verb CONFIRM the response will not be forwarded to the
endpoint that sent the request of this scenario. In this case the message with the verb FORWARD shall
be considered as confirmation of successful transfer. Otherwise a CONFIRM would be forwarded that
would be CONFIRMed and so on. Figure 9 shows the sub-scenarios that use the verb CONFIRM in the
response.
10
© ISO 2022 – All rights reserved
---------------------- Page: 16 ----------------------
ISO 5231:2022(E)
Figure 9 — Detailed schematic representation of scenario with CONFIRM Response
With a view to messages exchanged between endpoints and the server, the detailed representation is
a different story again. In this case, the messages are sent as they were defined in the scenario. Only
the reception of the last message sent by the server shall be confirmed by the endpoint with the verb
CONFIRM. This can be seen in Figure 10. This process has been slightly modified compared to the
scenarios described from endpoint to endpoint, see Figure 9. If the communicatio
...
NORME ISO
INTERNATIONALE 5231
Première édition
2022-10
Interface de données des
systèmes d'information de gestion
d'exploitation agricole étendue
(EFDI) — Concept et lignes directrices
Extended farm management information systems data interface
(EFDI) — Concept and guidelines
Numéro de référence
ISO 5231:2022(F)
© ISO 2022
---------------------- Page: 1 ----------------------
ISO 5231:2022(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2022
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
© ISO 2022 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 5231:2022(F)
Sommaire Page
Avant-propos .v
Introduction . vi
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 1
4 Vue d’ensemble de l’architecture .3
5 Réseau . 4
5.1 Présentation générale . 4
5.2 Service d’intégration . 5
5.3 Réseaux connectés . 5
6 Messagerie . 6
6.1 Présentation générale . 6
6.2 Structure hiérarchique des ensembles de scénarios, flux de scénarios et scénarios . 6
6.2.1 Généralités . 6
6.2.2 Scénario . 7
6.2.3 Flux de scénarios . 9
6.2.4 Ensemble de scénarios . 9
6.2.5 Vue détaillée d’un scénario . 10
6.3 Adressage . 14
6.3.1 Généralités . 14
6.3.2 Capacités des points d’extrémité . 15
6.3.3 Abonnements des points d’extrémité . 16
6.3.4 Capacités des composants de messagerie . . 16
6.4 Architecture des points d’extrémité . 17
6.4.1 Présentation générale . 17
6.4.2 Boîtes d’entrée et de sortie du point d’extrémité . 17
6.4.3 Alimentation du point d’extrémité . 18
6.5 Établissement de la connexion . 19
6.6 Autorisation . 20
6.7 Diffusion en continu. 20
6.8 Segmentation . 21
6.9 Traitement des erreurs . 22
7 Description formelle et sémantique .22
7.1 Généralités . 22
7.2 Nom . .22
7.3 Scénario . 23
7.4 Flux de scénarios . 24
7.5 Ensemble de scénarios . 25
7.6 Structure de la documentation . 25
7.7 Structure des fichiers Protobuf .25
7.7.1 Structure générale .25
7.7.2 Structure du code d’erreur . 26
8 Mise en correspondance de la couche de transport .27
8.1 Généralités . 27
8.2 Découverte de service . 27
8.2.1 Généralités . 27
8.2.2 Service Internet . 27
8.2.3 Réseau local .28
Annexe A (informative) Verbes OAGIS .29
Annexe B (informative) Transition des éléments de l’ISO 11783-10 à Protobuf .31
iii
© ISO 2022 – Tous droits réservés
---------------------- Page: 3 ----------------------
ISO 5231:2022(F)
Bibliographie .36
iv
© ISO 2022 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 5231:2022(F)
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'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www.iso.org/brevets).
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 www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 23, Tracteurs et matériels agricoles et
forestiers, sous-comité SC 19, Électronique en agriculture.
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.
v
© ISO 2022 – Tous droits réservés
---------------------- Page: 5 ----------------------
ISO 5231:2022(F)
Introduction
Les acteurs du secteur agricole sont confrontés à la nécessité d’échanger des données avec divers
systèmes et interfaces. Du fait de la demande croissante en matière de surveillance et de contrôle de
processus et d’informations en temps réel sur l’état d’avancement des tâches et, simultanément, de
l’intégration de dispositifs mobiles dans les processus de travail agricole, la nécessité d’un processus
normalisé pour l’échange de données se fait sentir.
vi
© ISO 2022 – Tous droits réservés
---------------------- Page: 6 ----------------------
NORME INTERNATIONALE ISO 5231:2022(F)
Interface de données des systèmes d'information de
gestion d'exploitation agricole étendue (EFDI) — Concept
et lignes directrices
1 Domaine d'application
Le présent document spécifie un concept de système de communication extensible et définit les règles
d’ajout de nouvelles fonctionnalités afin de couvrir les cas d’utilisation spécifiques.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions 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
réseau
groupe de deux ou plusieurs participants connectés les uns aux autres via un serveur
3.2
point d’extrémité
instance adressable de manière unique au sein d’un réseau
Note 1 à l'article: Un point d’extrémité peut être un système de gestion des informations agricoles (FMIS), un
dispositif de télémesure, un terminal ou une machine complète.
Note 2 à l'article: Le serveur est également un point d’extrémité.
3.3
client
C
tout point d’extrémité qui communique avec le serveur
3.4
serveur
S
élément central pour la communication au sein du réseau
Note 1 à l'article: Toutes les communications s’effectuent par le serveur.
1
© ISO 2022 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 5231:2022(F)
3.5
composant de messagerie
CM
partie qui gère le serveur et le réseau
Note 1 à l'article: Le composant de messagerie (CM) conserve la trace des points d’extrémité identifiés et leurs
capacités et est aussi responsable de l’acheminement et de la transmission des messages.
3.6
nom
type de message
3.7
verbe
action qui est exécutée avec un nom spécifique
3.8
scénario
ordre dans lequel les messages de demande et de réponse doivent être exécutés
Note 1 à l'article: Toute demande et réponse se compose d’un verbe et d’un nom.
3.9
flux de scénarios
séquence de scénarios
Note 1 à l'article: Le flux de scénarios définit comment les scénarios sont liés les uns aux autres, et comment ils
doivent être exécutés dans une dépendance réciproque.
3.10
ensemble de scénarios
groupe de flux de scénarios
3.11
étape A
demande envoyée d’un client A à un client B
3.12
étape B
demande envoyée d’un client B à un client A
3.13
diffusion en continu
abonnement à des types de messages spécifiques et la réception ultérieure d’informations non sollicitées
3.14
intégration
accès ou enregistrement initial sur un point d’extrémité
3.15
service d’intégration
service permettant aux clients d’accéder au réseau
3.16
tampon de protocole
protobuf
structures de données qui peuvent être sérialisées en représentation binaire compacte
Note 1 à l'article: Dans le présent document, les tampons de protocole de version 3 (proto3) s’appliquent à toutes
les définitions. Voir également https:// developers .google .com/ protocol -buffers/ docs/ proto3.
2
© ISO 2022 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 5231:2022(F)
3.17
Message Queue Telemetry Transport
MQTT
protocole de transport standardisé avec service de publication-abonnement
Note 1 à l'article: Dans le présent document, MQTT 3.1.1 s’applique à toutes les définitions. Voir également http://
docs .oasis -open .org/ mqtt/ mqtt/ v3 .1 .1/ os/ mqtt -v3 .1 .1 -os .html.
3.18
hypertext transport protocol secure
HTTPS
protocole permettant de sécuriser la communication sur le réseau internet ou local
Note 1 à l'article: Voir également https:// datatracker .ietf .org/ doc/ html/ rfc2818.
3.19
versionnage sémantique
concept permettant de définir les numéros de version des logiciels
Note 1 à l'article: Le versionnage sémantique permet d'associer des informations de compatibilité à un numéro de
version, voir également https:// semver .org/ .
3.20
base de données VDMA
contient toutes les définitions des ensembles de scénarios, flux de scénarios, scénarios et message de
l’ISO 5231
Note 1 à l'article: La base de données est accessible à l'adresse suivante https:// isobus .net/ isobus/ efdi.
3.21
sécurité de la couche transport
TLS
protocole permettant de sécuriser les communications sur internet
3.22
certificats de sécurité de la couche de transport
TLS-CERTS
certificats fournissant des informations pour le cryptage des communications
3.23
protocole extensible de messagerie et de présence
XMPP
profil d'application pour l'échange de données
3.24
nom de domaine entièrement qualifié
FQDN
emplacement avec tous ses niveaux de domaine
4 Vue d’ensemble de l’architecture
L’interface de données des systèmes d’information de gestion agricole étendue consiste en un ensemble
de couches situées au-dessus de la couche d’application réseau, tel qu’illustré à la Figure 1.
3
© ISO 2022 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 5231:2022(F)
Figure 1 — Modèle de couche
Le protocole de transport de message sélectionné pour illustrer la mise en œuvre de l’EFDI se base sur
le protocole MQTT comme la couche de transport du message. Cependant, les couches d’application (voir
Figure 1) n’y sont pas liées. Les messages sont segmentés en un en-tête et une charge utile. L’entête doit
contenir des informations d’adressage et peuvent contenir des données supplémentaires afin d’établir
une session d’état, persistante. Selon les fonctionnalités du protocole de transport de couche inférieure,
les données supplémentaires peuvent être omises et plutôt couvertes par la couche de protocole de
transport. Il est théoriquement possible de transporter toute charge utile dans le protocole EFDI.
Cependant, le transfert des données ISO 11783-10 est explicitement décrit dans l’Annexe B. Une méthode
de manipulation de transfert de fichier générique est également décrite par un ensemble de scénarios
de la fonctionnalité de base des fichiers. Hormis la couche spécifique au cas d’utilisation placée en
position la plus haute de la pile, l’EFDI fournit une couche sémantique pour indiquer aux destinataires
de message ce qu’il convient de faire avec les données (exécution d’une tâche, remplacement d’un
élément dans une tâche, etc.).
La définition d’une couche de protocole générique est indiquée dans l’Article 6. Les règles de sémantique
sont définies dans l’Article 7 et la mise en correspondance de couche de transport est décrite dans
l’Article 8.
5 Réseau
5.1 Présentation générale
Cet article donne un aperçu des différents éléments constituant le réseau, comme indiqué dans la
Figure 2.
4
© ISO 2022 – Tous droits réservés
---------------------- Page: 10 ----------------------
ISO 5231:2022(F)
Figure 2 — Éléments dans un réseau
Les clients peuvent établir une connexion avec le serveur. Tous les points d’extrémité du réseau peuvent
communiquer entre eux.
5.2 Service d’intégration
Le service d’intégration (SI) fait partie des éléments du serveur du réseau. Il s’agit d’un service avec
lequel un point d’extrémité peut se connecter au réseau. Les ID individuels et certificats, nécessaires à
la communication ultérieure, sont générés. L’intégration fait partie du processus d’enregistrement d’un
point d’extrémité.
5.3 Réseaux connectés
L’interconnexion de réseaux multiples peut être réalisée en mettant en place un serveur contenant un
composant de messagerie et un client.
Dans la Figure 3, un serveur A traite les clients directement connectés via son composant de messagerie.
En outre, le serveur A se connecte comme un client au serveur B. Grâce à cette connexion, le serveur A se
connecte indirectement aux clients par le serveur B. Selon les capacités fournies par le client du serveur
A, le serveur B peut également être en mesure de se connecter indirectement aux clients du serveur A.
5
© ISO 2022 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 5231:2022(F)
Figure 3 — Éléments dans les réseaux connectés
6 Messagerie
6.1 Présentation générale
Cet article présente divers concepts de base permettant de comprendre le principe de la communication.
Il comprend une description de la construction des messages, des structures architecturales, de
l’adressage et de la diffusion en continu.
6.2 Structure hiérarchique des ensembles de scénarios, flux de scénarios et scénarios
6.2.1 Généralités
La structure hiérarchique des ensembles de scénarios, flux de scénarios et scénarios est illustrée à la
Figure 4. En général, l’ensemble de scénarios est l’élément le plus haut, qui contient au moins un flux de
scénarios. Chaque flux de scénarios contient au moins un scénario. Un scénario comprend une demande
et une réponse. La demande et la réponse se composent d’une combinaison d’un verbe et d’un nom.
6
© ISO 2022 – Tous droits réservés
---------------------- Page: 12 ----------------------
ISO 5231:2022(F)
Figure 4 — Structure hiérarchique des ensembles de scénarios, flux de scénarios et scénarios
Toutes les messageries décrites suivent un processus commun. Ce processus commun est décrit en
6.2.2 à 6.2.5.
6.2.2 Scénario
Une séquence de messages de demandes et de réponses est appelée scénario. Tous les scénarios
disposent d’un modèle de messagerie demande-réponse. Cela signifie qu’une réponse définie existe pour
une demande spécifique. La demande est envoyée par un point d’extrémité et la réponse est renvoyée
par un autre point d’extrémité.
Les demandes et réponses sont définies comme une combinaison d’un verbe et d’un nom. Ce concept de
verbe et nom se base sur le Business Object Document spécifié par Open Applications Group Integration
Specification (OAGIS), voir l’Annexe A pour des informations supplémentaires. Le verbe définit l’action
ou les actions souhaitée(s) pour les informations commerciales incluses. Les informations commerciales
elles-mêmes sont contenues dans l’autre paragraphe appelé nom.
Un scénario de demande de la liste des points d’extrémité connectés au serveur, tel qu’illustré à la
Figure 5, en est un exemple. La demande contient le verbe GET et le nom ListEndpoints. En d’autres
termes, cela signifie que la liste des points d’extrémité connectés est demandée. La réponse contient le
verbe SHOW et le nom ListEndpointsResponse. En d’autres termes, cela signifie que la liste des points
d’extrémité connectés est retournée.
7
© ISO 2022 – Tous droits réservés
---------------------- Page: 13 ----------------------
ISO 5231:2022(F)
Figure 5 — Scénario de la liste des points d’extrémité
La représentation schématique peut être vue à la Figure 6. Des informations supplémentaires et la
méthode de description formelle des scénarios peuvent être trouvées en 8.2.
Figure 6 — Représentation schématique du scénario
La liste des verbes disponibles établie sur la norme OAGIS a été étendue afin de couvrir de nouveaux cas
d'utilisation. Les verbes suivants ont été ajoutés :
— FORWARD: doit uniquement être utilisé par le serveur, et indique qu’un message a été reçu et qu’il
sera transmis aux autres points d’extrémité. Une explication plus détaillée et des cas d’utilisation de
ce verbe peuvent se trouver en 6.2.5 ;
— STREAM_START: permet de demander des données en continu, indique que le point d’extrémité
souhaite désormais recevoir des données en continu ;
— STREAM_STOP: indique que le point d’extrémité ne souhaite plus recevoir de données en continu ;
— STREAM_DATA: nécessaire pour marquer des données en continu.
Plus d’informations détaillées sur les nouveaux verbes applicables aux données en continu peuvent être
trouvées en 7.6.
8
© ISO 2022 – Tous droits réservés
---------------------- Page: 14 ----------------------
ISO 5231:2022(F)
6.2.3 Flux de scénarios
Un flux de scénarios se compose d’au moins un scénario. L’ordre des scénarios est décrit au sein du
flux. Des scénarios d’un flux de scénarios peuvent être facultatifs. Si des scénarios sont déclarés comme
facultatifs, il n’est pas nécessaire de les exécuter.
L’expéditeur de la première demande dans un flux de scénarios est appelé point d’extrémité A, l’autre
point d’extrémité est appelé point d’extrémité B pour l’ensemble de la communication adressée dans
un flux de scénarios. Lorsque A envoie la demande à B, cela est appelé une étape A. Lorsque B envoie la
demande A, cela est appelé une étape B. Cela est illustré à la Figure 7. Des informations supplémentaires
et la méthode de description formelle des flux de scénarios peuvent être trouvées en 7.4.
Figure 7 — Représentation schématique d’un flux de scénarios
6.2.4 Ensemble de scénarios
Un ensemble de scénarios se compose d’au moins un flux de scénarios. Un ensemble de scénarios est un
regroupement qui peut être utilisé, par exemple, pour une certification, si nécessaire. Des informations
supplémentaires et la méthode de description formelle des flux de scénarios peuvent être trouvées
en 7.5.
9
© ISO 2022 – Tous droits réservés
---------------------- Page: 15 ----------------------
ISO 5231:2022(F)
Actuellement, il n’y a qu’un seul ensemble de scénarios défini. Cet ensemble de scénarios est appelé
basique, et contient tous les flux de scénarios nécessaires à la communication de base.
6.2.5 Vue détaillée d’un scénario
Du point de vue d’une application, un exemple de scénario est illustré à la Figure 7. Une demande est
envoyée par un point d’extrémité et la réponse est renvoyée par un autre point d’extrémité. Si nous
examinons de manière plus détaillée, nous obtenons un résultat différent. Les points d’extrémité ne
communiquent pas directement les uns avec les autres, comme représenté en 5.1. Les points d’extrémité
échangent plutôt des messages entre eux à l’aide du serveur/composant de messagerie. La représentation
simplifiée, qui n’est uniquement constituée que d’une paire de demande-réponse, se répartit en fait en
quatre sous-scénarios. La Figure 8 représente des sous-scénarios qui sont implicitement exécutés dans
des scénarios au sein desquels des informations sont échangées entre deux points d’extrémité via le
serveur/composant de messagerie.
Les quatre sous-scénarios, qui sont aussi illustrés à la Figure 8, sont les suivants:
— Sous-scénario demande point d’extrémité (Sub_1)
— Demande (point d’extrémité A vers serveur): VERB [Nom]
— Réponse (serveur vers point d’extrémité A): FORWARD [ForwardInfo]
— Sous-scénario demande point d’extrémité transmission (Sub_2)
— Demande (serveur vers point d’extrémité B): VERB [Nom]
— Réponse (point d’extrémité B vers serveur): CONFIRM [ ]
— Sous-scénario réponse point d’extrémité (Sub_3)
— Réponse (point d’extrémité B vers serveur): VERB [Nom]
— Réponse (serveur vers point d’extrémité B): FORWARD [ForwardInfo]
— Sous-scénario point d’extrémité transmission (Sub_4)
— Demande (serveur vers point d’extrémité A): VERB [Nom]
— Réponse (point d’extrémité A vers serveur): CONFIRM [ ]
Les contenus de la Figure 8 sont détaillés.
1) Le point d’extrémité A envoie la demande du scénario qui est décrit dans la définition du scénario.
Cette demande est envoyée au serveur. Le serveur envoie directement un message ForwardInfo
comme réponse. La réponse du serveur contient, entre autres, l’information que le message a été
transmis.
2) Le serveur envoie un message au point d’extrémité B. Ce message contient le verbe et le nom
du message que le serveur a reçu du point d’
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.