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
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 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
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
Bibliography .32
iv
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
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
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.
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
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.
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
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.
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.
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.
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
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.
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.
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 communication takes place directly
from endpoint to server, the server no longer needs to forward the message to any other endpoint. For
this reason, the server does not respond using the verb FORWARD. Instead, the server’s response to the
scenario request shall be regarded as confirmation of receipt.
Figure 10 — Detailed schematic representation of scenario with Server
6.3 Addressing
6.3.1 General
This subclause describes the concepts of “Generic protocol” layer of Figure 1. The specific message
definitions are described in Annex B.
In general, every endpoint gets a unique address. With this address, every endpoint can be identified
unambiguously. The addressing is managed by the messaging component. The basic concept is to send
as few messages as possible without prior request so that no information is sent initially by an endpoint.
Messages can be addressed directly to one or more endpoints. They can also be published to send
the message to all subscribed endpoints. It is flagged in the message if the message is directly sent,
published, or if both techniques shall be used. Messages are not delivered to the same endpoint twice.
There are several modes that can be used to send messages:
— DIRECT: for directed communication to a certain endpoint, the desired recipients of this message
shall be specified
— PUBLISH: in this undirected communication the message is delivered to all subscribed endpoints,
no recipients shall be named
— PUBLISH_WITH_DIRECT: it is a combination of the modes DIRECT and PUBLISH, messages will
be delivered to all subscribed endpoints as well as to all desired recipients specified within the
message
6.3.2 Endpoint capabilities
Each endpoint has a series of abilities and skills that are called capabilities hereafter. In order for the
messaging component to know which messages can be sent to and received from endpoints, each
endpoint shall provide its capabilities. The capabilities are also based on the noun and verb concept,
which has been explained in 6.2.2. In summary, the capabilities of an endpoint indicate which scenarios
the endpoint supports. Scenarios that are not supported by the endpoint cannot be received by the
endpoint, nor is the endpoint allowed to send these messages. The messaging component shall not send
messages to an endpoint that the endpoint does not support. In addition, the messaging component
shall not forward messages that the endpoint cannot send according to the endpoint’s capabilities.
When a client wants to announce that it supports a scenario, it shall support the request and the
response defined in the corresponding scenario. Request and response consist of a combination of verb
and noun each. An example is shown in Figure 11. There are two different endpoints: endpoint A and
endpoint B. To be sender of the request and receiver of the response (endpoint A), the client shall be able
to SEND the verb-noun-combination of the request and to RECEIVE the noun-verb-combination of the
response. To be receiver of the request and sender of the response (endpoint B), the client shall be able
to RECEIVE the noun-verb-combination of the request and to SEND the noun-verb-combination of the
response. With this information, a client can determine which clients support which scenarios.
Figure 11 — Necessary capabilities to support a scenario
The capabilities are not sent without prior request. Instead, a message containing the status of the
endpoint is sent. This message is sent when the endpoint is connected to the network and contains
a reference to the endpoint's capabilities. If the messaging component already knows this unique
reference and the capabilities behind it, the messaging component already knows what the endpoint
is capable of. If the messaging component does not yet know this unique reference and the associated
capabilities, it can request them. When an endpoint connects to the network it shall send a status
message indicating that it is online. The endpoint shall always produce the same reference for a certain
set of capabilities. Conversely, this also means that the reference output shall be different when the set
of capabilities of the endpoint is different.
The message with the abilities can be quite voluminous under certain circumstances. All scenarios are
semantically versioned. If an endpoint now supports multiple versions and many scenarios, the message
about the capabilities becomes very large. If this message is always sent when the endpoint connects to
the network without being prompted, it creates a lot of unnecessary traffic.
If an endpoint has connected to the network, it shall report that it is online. If it disconnects from the
network on a regular basis, it shall report that it is expected to be offline. In the case that the endpoint
unintentionally loses the connection to the network, it shall indicate that it will unexpectedly be offline.
6.3.3 Endpoint subscriptions
Subscriptions are used to subscribe to a list of verb and nouns (scenarios). Messages that are published
(mode PUBLISH or PUBLISH_WITH_DIRECT) are forwarded to endpoints that are subscribed to the
verb-noun-combination contained in the message. Subscriptions can be defined for specific nouns and
verbs. Each new subscription list sent by an endpoint deletes old subscriptions. After changing the
capabilities, the endpoint needs to resend its subscriptions. An unsubscription message will delete the
listed subscriptions.
As a sender of a message does not always know the relevant endpoints, it can send the message as a
public message. Every other endpoint can subscribe to any message type that is part of its capabilities.
An endpoint cannot subscribe to scenarios that it does not support according to its capabilities.
6.3.4 Messaging component capabilities
Just as the endpoints have capabilities, the messaging component also has capabilities. However,
these are slightly different from the endpoints. The capabilities of the messaging component are not
only about which scenarios are supported, but more about how long and to what extent the messaging
component can store messages. These are called the minimum capabilities of the messaging component
defined in the message MinimumCapabilities.
The endpoint capabilities contain information about how many messages and how long messages can
be stored. It can also contain the messaging component’s memory size. The messaging component does
not have to reveal all of these statements, but the more information about the messaging component is
known, the more deterministic its behaviour is and the better the endpoints can adapt to it. At least one
of these information shall be provided:
— number of messages;
— time of storage;
— size of storage;
— optionally, the maximum message size and the maximum number of individual messages in a
total message can also be specified. The default capabilities of the messaging component are
MinimumCapabilities;
— ListEndpoints (optional).
StreamingCapabilities (optional). In addition to the minimum capabilities of the messaging component
there are optional capabilities the messaging component can support. Listing of endpoints and the
stream mechanism. If streaming is supported, all verbs mentioned in 6.7 can be exchanged with
the messaging component. If streaming is not part of the capabilities, streaming is not part of the
capabilities, streaming is not possible with this messaging component.
The messaging component capabilities can be requested by every client. The messaging component is
always addressed with mode DIRECT and the list of recipients shall be empty. How to request these
capabilities is explained in the messaging component capabilities scenario flow. The ListEndpoints
message contains an entry with an empty endpoint address for each supported scenario of the
messaging component.
In connected networks (as shown in Figure 3) a server A can connect to a server B. The client of server
A that is connected to server B shall announce that it is part of a network that is not connected to server
B directly. In order to do so, this client shall specify in its capabilities that it supports the scenario
Send List Endpoints. It shall be able to RECEIVE a GET with ListEndpoints and to SEND a SHOW with
ListEndpointsResponse. Additionally, this client can also be able to support other scenarios mentioned
in the Messaging Component Capabilities scenario flow.
6.4 Endpoint architecture
6.4.1 Overview
The architecture of an endpoint aims at receiving and forwarding messages according to a combination
of capabilities, subscriptions, public or direct addressed messaging. How this architecture can be
mapped to a transport protocol is described in Clause 8.
6.4.2 Endpoint’s inbox and outbox
Inside the server there is an inbox and an outbox for each endpoint. The endpoint communicates with
the inbox when messages are sent to the server. To receive messages from the server, the endpoint
communicates with its outbox. If, for instance, the request of a scenario is sent from an endpoint, this
message arrives in the inbox. The response of this scenario is received via the outbox. A schematic
representation of how the design inside the server and how the message flow from the endpoint and to
the endpoint is, can be seen in Figure 12.
Figure 12 — Architecture of endpoints in a network
Figure 13 shows how a message is sent from endpoint A to endpoint B. The message is sent from endpoint
A to its inbox. Within the server this message is forwarded to endpoint B by putting the message in the
outbox of endpoint B. This message can be retrieved from there by endpoint B.
Figure 13 — Message sent from Endpoint A to Endpoint B
This is the minimal possible architecture. Within the server component, there shall be an inbox and an
outbox for each endpoint.
6.4.3 Endpoint’s feed
6.4.3.1 General
Additionally, it is possible that there is a feed for each endpoint within the server component. This feed
is used as a storage for messages. Whether there is a feed for each endpoint can be seen in messaging
component capabilities. The messaging component capabilities can also be used to determine how
large the memory is, how many messages can be stored and for how long. When the maximum storage
capacity of the server is reached – whether the number of stored messages or the size of messages per
endpoint is exceeded – the oldest messages shall be discarded and removed from the endpoint’s feed.
Figure 14 shows how the inbox, outbox and feed of an endpoint can be seen schematically within the
server. The communication still takes place via the in- and outbox with the only difference that it is
possible that outbox data may be stored in the feed.
Figure 14 — Architecture of Endpoint with feed
Clause 8 describes in detail how the communication for querying for feed messages looks like – based
on MQTT.
6.4.3.2 Feed configuration
After the initial connection establishment – the so called onboarding – no messages from other
endpoints will be sent to the onboarded endpoint. The endpoint shall send its capabilities and shall
configure the feed explicitly. After this, messages from other endpoints can be received. An endpoint
only appears in the list of endpoints after performing the onboarding, sending its capabilities and
configuring its feed.
Messages that are exchanged with the messaging component, and are part of a scenario that only happen
with the messaging component, are delivered directly to the endpoint. Also, the ForwardInfo of the
messaging component will be sent directly to the endpoint. The feed is not used for this communication.
The way how to receive messages that are sent by other endpoints shall be configured. On the one hand,
messages can be stored in the feed. In this case, every message shall be requested from the feed. Every
received message from the feed shall be confirmed. The confirmation of reception deletes the message
from the feed. On the other hand, messages can be delivered directly. In this case, all messages will be
delivered directly. If the endpoint is offline, it cannot receive any message and the messages are getting
lost. Therefore, the endpoint has to be online to exchange messages successfully.
Additionally, there is the possibility that the messages will be stored in the endpoint’s feed but will also
be delivered directly. Messages will be delivered directly if the endpoint is online. Furthermore, these
messages will be stored in the feed. When a directly delivered message is confirmed the message will
be automatically removed from the endpoint’s feed. This way, all the messages you can receive from
your feed are those messages, you did not yet receive directly.
There are three configurations of the client’s feed, of which only one can be active at one point in time:
— storage of messages inside the feed;
— direct delivery of messages with storage inside the feed;
— direct delivery of messages without storage inside the feed (default behaviour).
6.4.3.3 Request feed message
Messages stored in the feed shall be explicitly requested by the endpoint. This is illustrated in Figure 15.
Incoming messages are sent by endpoint A and delivered to endpoint B. These messages are stored in the
feed of endpoint B (1). The request for messages from the feed is sent by endpoint B to the server via its
inbox. The requested messages are now taken from the feed and placed in the outbox of endpoint B (2).
From this point the messages can be retrieved from endpoint B (3).
Figure 15 — Visualization of message retrieval from feed
If messages have been discarded and removed from the endpoint’s feed, the number of discarded
messages shall be specified in the response message.
6.5 Connection establishment
The server system shall provide the registration code to the user who wants to onboard the client
system. It is up to the server system how the registration code is provided. It is also up to the server
system to decide in what form the registration code is provided - whether it is numeric, alphanumeric
or anything else that a human can read and enter into a connecting client system. The server system can
also define whether the validity period of the registration code may be limited. In addition, the server
system can also define whether a provided registration code may only be used once
...
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
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
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
Bibliographie .36
iv
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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’extrémité A. La réception de ce message doit être
confirmée par le point d’extrémité B destinataire. La confirmation contient le verbe CONFIRM
sans aucun nom. Le message CONFIRM vise à confirmer la réception d’un message envoyé entre le
serveur et le point d’extrémité A. À la fin, le point d’extrémité A recevra le message verbe-nom du
point d’extrémité B comme réponse.
3) Le point d’extrémité B crée le message de réponse décrit dans la définition du scénario. Ce message
sera envoyé sous forme d’un message de demande 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.
4) Le serveur envoie un message au point d’extrémité A. Ce message contient le verbe et le nom
du message que le serveur a reçu du point d’extrémité B. La réception de ce message doit être
confirmée par le point d’extrémité A destinataire. La confirmation contient le verbe CONFIRM
sans aucun nom. Le message CONFIRM vise à confirmer la réception d’un message envoyé entre le
serveur et le point d’extrémité B.
Toutes ces étapes peuvent être extraites des scénarios, étant donné qu’il s’agit de la communication
dans la couche en-dessous des définitions du scénario. Pour cette raison, les scénarios sont toujours
présentés sous une forme simplifiée, tel qu’illustré à la Figure 7. Mais tous les sous-scénarios mentionnés
sont nécessaires pour assurer le succès de la communication.
Figure 8 — Représentation schématique détaillée du flux de scénarios
Dans un scénario dont la réponse contient le verbe CONFIRM, la réponse ne sera pas transmise au point
d’extrémité qui a envoyé la demande de ce scénario. Dans ce cas, le message avec le verbe FORWARD
doit être considéré comme une confirmation du transfert réussi. Sinon, un message CONFIRM sera
transmis, qui sera CONFIRMÉ, puis ainsi de suite. La Figure 9 illustre les sous-scénarios qui utilisent le
verbe CONFIRM dans la réponse.
Figure 9 — Représentation schématique détaillée du scénario avec réponse CONFIRM
Grâce à une vue des messages échangés entre les points d’extrémité et le serveur, la représentation
détaillée apparaît encore différemment. Dans ce cas, les messages sont envoyés comme ils ont été définis
dans le scénario. Seule la réception du dernier message envoyé par le serveur doit être confirmée par le
point d’extrémité avec le verbe CONFIRM. Cela peut être vu à la Figure 10. Ce processus a été légèrement
modifié par rapport aux scénarios décrits d’un point d’extrémité à un autre point d’extrémité, voir
Figure 9. Si la communication a lieu directement d’un point d’extrémité au serveur, le serveur n’a plus
besoin de transmettre le message à un autre point d’extrémité. Pour cette raison, le serveur ne répond
pas en utilisant le verbe FORWARD. À la place, la réponse du serveur à la demande du scénario doit être
considérée comme une confirmation de la réception.
Figure 10 — Représentation schématique détaillée du scénario avec serveur
6.3 Adressage
6.3.1 Généralités
Le présent paragraphe décrit les concepts de couche “Protocole générique” de la Figure 1. Les définitions
des messages spécifiques sont décrites à l’Annexe B.
En général, tout point d’extrémité obtient une adresse unique. Grâce à cette adresse, tout point
d’extrémité peut être clairement identifié. L’adressage est géré par le composant de messagerie. Le
concept de base est d’envoyer le moins possible de messages sans demande préalable, de manière à ce
qu’aucune information ne soit envoyée initialement par un point d’extrémité.
Les messages peuvent être directement adressés à un ou plusieurs points d’extrémité. Ils peuvent
également être publiés pour envoyer le message à tous les points d’extrémité abonnés. Il est marqué
dans le message si le message est directement envoyé, publié ou si les deux techniques doivent être
utilisées. Les messages ne sont pas acheminés deux fois au même point d’extrémité.
Plusieurs modes peuvent être utilisés pour envoyer des messages:
— DIRECT: pour une communication directe vers un point d’extrémité donné, les destinataires
souhaités de ce message doivent être spécifiés;
— PUBLISH: dans cette communication indirecte, le message est transmis à tous les points d’extrémité
abonnés, aucun destinataire ne doit être nommé;
— PUBLISH_WITH_DIRECT: il s’agit d’une combinaison des modes DIRECT et PUBLISH, les messages
seront transmis à tous les points d’extrémité abonnés, ainsi qu’à tous les destinataires souhaités
spécifiés dans le message.
6.3.2 Capacités des points d’extrémité
Chaque point d’extrémité dispose d’une série d’aptitudes et de compétences appelés ci-après capacités.
Afin que le composant de messagerie puisse savoir quels messages peuvent être envoyés et reçus des
points d’extrémité, chaque point d’extrémité doit fournir ses capacités. Les capacités dépendent aussi
du concept de nom et de verbe, expliqué au point 6.2.2. En résumé, les capacités d’un point d’extrémité
indiquent les scénarios qu’il supporte. Les scénarios non supportés par le point d’extrémité ne peuvent
pas être reçus par ce point d’extrémité, qui, en outre n’est pas autorisé à envoyer ces messages. Le
composant de messagerie ne doit pas envoyer de messages à un point d’extrémité, si ce dernier ne les
supporte pas. En outre, le composant de messagerie ne doit pas transmettre les messages que le point
d’extrémité ne peut pas envoyer, du fait des capacités du point d’extrémité.
Si un client souhaite annoncer qu’il supporte un scénario, il doit supporter la demande et la réponse
définies dans le scénario correspondant. La demande et la réponse se composent d’une combinaison
d’un verbe et d’un nom. Un exemple est illustré à la Figure 11. Il existe deux points d’extrémité différents:
le point d’extrémité A et le point d’extrémité B. Pour être expéditeur de la demande et destinataire
de la réponse (point d’extrémité A), le client doit être en mesure de SEND la combinaison verbe-nom
de la demande et de REIECVE la combinaison nom-verbe de la réponse. Pour être destinataire de la
demande et expéditeur de la réponse (point d’extrémité B), le client doit être en mesure de REIECVE la
combinaison nom-verbe de la demande et de SEND la combinaison nom-verbe de la réponse. À l’aide de
ces informations, un client peut déterminer quels clients supportent quels scénarios.
Figure 11 — Capacités requises pour supporter un scénario
Les capacités ne sont pas envoyées sans demande préalable. À la place, un message contenant l’état du
point d’extrémité est envoyé. Ce message est envoyé lorsque le point d’extrémité est connecté au réseau
et contient une référence aux capacités du point d’extrémité. Si le composant de messagerie connaît déjà
cette référence unique et les capacités qui la sous-tendent, le composant de messagerie connaît déjà les
capacités du point d’extrémité. Si le composant de messagerie ne connaît pas encore cette référence
unique et les capacités associées, il peut les demander. Lorsqu’un point d’extrémité se connecte au
réseau, il doit envoyer un message d’état pour indiquer qu'il est en ligne. Le point d’extrémité doit
toujours produire la même référence pour un ensemble donné de capacités. À l’inverse, cela signifie
également que la sortie de référence doit être différente lorsque l’ensemble de capacités du point
d’extrémité est différent.
Le message avec les aptitudes peut être très volumineux dans certaines circonstances. Tous les scénarios
sont versionnés sur le plan sémantique. Si un point d’extrémité supporte maintenant plusieurs versions
et de nombreux scénarios, le message sur les capacités devient très grand. Si ce message est toujours
envoyé lorsque le point d’extrémité se connecte au réseau sans invite, il crée beaucoup de trafic inutile.
Si un point d’extrémité s’est connecté au réseau, il doit indiquer qu’il est en ligne. S’il se déconnecte
régulièrement du réseau, il indiquera qu'il est considéré comme devant être hors ligne. Dans le cas où le
point d’extrémité perd accidentellement la connexion au réseau, il doit être indiqué qu’il sera hors ligne
d’une manière inattendue.
6.3.3 Abonnements des points d’extrémité
Des abonnements sont utilisés pour s’abonner à une liste de verbes et de noms (scénarios). Les messages
publiés (mode PUBLISH ou PUBLISH_WITH_DIRECT) sont envoyés à des points d’extrémité qui sont
abonnés à la combinaison verbe-nom contenue dans le message. Les abonnements peuvent être définis
pour des noms et des verbes spécifiques. Chaque nouvelle liste d’abonnements envoyée par un point
d’extrémité supprime les anciens abonnements. Après avoir changé les capacités, le point d’extrémité
doit renvoyer ses abonnements. Un message sans abonnement supprimera les abonnements listés.
Comme un expéditeur d’un message ne connaît pas toujours les points d’extrémité pertinents, il peut
envoyer le message comme message public. Tous les deux points d‘extrémité peuvent s’abonner à un
type de message quelconque qui fait partie de ses capacités. Un point d’extrémité ne peut pas s’abonner
à des scénarios qu'il ne supporte pas en fonction de ses capacités.
6.3.4 Capacités des composants de messagerie
Tout comme les points d’extrémité ont des capacités, le composant de messagerie en a également.
Cependant, elles sont légèrement différentes des points d’extrémité. Les capacités du composant de
messagerie concernent non seulement les scénarios supportés, mais plus encore la longueur et la mesure
dans laquelle le composant de messagerie peut stocker des messages. Ces capacités sont appelées les
capacités minimales du composant de messagerie définies dans le message MinimumCapabilities.
Les capacités de points d’extrémité contiennent des informations sur le nombre de messages pouvant
être stockés et leur longueur. Elles peuvent également contenir la taille de la mémoire du composant de
messagerie. Le composant de messagerie n’a pas à révéler toutes ces déclarations, mais plus on connaît
d’informations sur le composant de messagerie, plus son comportement est déterministe et mieux les
points d’extrémité peuvent s’y adapter. Au moins une de ces informations doit être fournie :
— le nombre de messages ;
— le temps de stockage ;
— la taille du stockage ;
— en option, la taille maximale du message et le nombre maximum de messages individuels dans
un message total peuvent être également spécifiés. Les capacités par défaut du composant de
messagerie sont MinimumCapabilities suivantes :
— ListEndpoints (option).
StreamingCapabilities (option).
En plus des capacités minimales du composant de messagerie, il existe une liste extensible de capacités
que le composant de messagerie peut supporter. Liste des points d’extrémité et du mécanisme de
diffusion en continu. Si la diffusion en continu est supportée, tous les verbes mentionnés en 6.7 peuvent
être échangés avec le composant de messagerie. Si la diffusion en continu ne fait partie des capacités,
elle est impossible avec ce composant de messagerie.
Les capacités du composant de messagerie peuvent être demandées par tout client. Le composant de
messagerie est toujours adressé avec un mode DIRECT et la liste des destinataires doit être vide. La
manière de demander ces capacités est expliquée dans le flux de scénarios des capacités du composant
de messagerie. Le message ListEndpoints contient une entrée avec une adresse de point d’extrémité
vide pour chaque scénario pris en charge par le composant de messagerie.
Dans les réseaux connectés (tel qu'illustré à la Figure 3) un serveur A peut se connecter à un serveur
B. Le client du serveur A raccordé au serveur B doit annoncer qu’il fait partie d’un réseau qui n’est
pas connecté directement au serveur B. Pour ce faire, ce client doit spécifier dans ses capacités qu’il
supporte le scénario Send List Endpoints. Il doit être capable de REIECVE un GET avec ListEndpoints
et de SEND un SHOW avec ListEndpointsResponse. De plus, ce client peut également être capable de
supporter d’autres scénarios mentionnés dans le flux de scénarios Messaging Component Capabilities.
6.4 Architecture des points d’extrémité
6.4.1 Présentation générale
L’architecture d’un point d’extrémité vise à recevoir et à envoyer des messages selon une combinaison
de capacités, d’abonnements, de messagerie adressée, directe ou publique. La manière dont cette
architecture peut être mise en correspondance avec un protocole de transport est décrite dans
l’Article 8.
6.4.2 Boîtes d’entrée et de sortie du point d’extrémité
À l’intérieur du serveur se trouvent une boîte d’entrée et une boîte de sortie pour chaque point
d’extrémité. Le point d’extrémité communique avec la boîte d’entrée lorsque des messages sont envoyés
au serveur. Pour recevoir des messages du serveur, le point d’extrémité communique avec sa boîte de
sortie. Si, par exemple, la demande d’un scénario est envoyée par un point d’extrémité, ce message arrive
dans la boîte d’entrée. La réponse de ce scénario est reçue par la boîte de sortie. Une représentation
schématique de la manière dont la conception à l’intérieur du serveur et dont le flux de messages
s’effectue à partir du point d’extrémité peut être vue à la Figure 12.
Figure 12 — Architecture de points d’extrémité dans un réseau
La Figure 13 montre la manière dont un message est envoyé du point d’extrémité A au point
d’extrémité B. Le message est envoyé par le point d’extrémité A à sa boîte d’entrée. À l’intérieur du
serveur, ce message est envoyé au point d’extrémité B en plaçant le message dans la boîte de sortie du
point d’extrémité B. Ce message peut y être récupéré par le point d’extrémité B.
Figure 13 — Message envoyé par le point d’extrémité A au point d’extrémité B
Il s’agit là de l’architecture minimale possible. À l’intérieur du composant du serveur se trouvent une
boîte d’entrée et une boîte de sortie pour chaque point d’extrémité.
6.4.3 Alimentation du point d’extrémité
6.4.3.1 Généralités
De plus, il est possible qu’une alimentation existe pour chaqu
...
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...