ISO 17532:2007
(Main)Stationary equipment for agriculture — Data communications network for livestock farming
Stationary equipment for agriculture — Data communications network for livestock farming
ISO 17532:2007 specifies a protocol for the automatic and interactive communication and control of computer systems used in livestock production. It supports communication within the livestock production as well as across the Internet.
Matériel fixe pour l'agriculture — Réseau de communication de données pour fermes d'élevage
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 17532
First edition
2007-08-01
Stationary equipment for agriculture —
Data communications network for
livestock farming
Matériel fixe pour l'agriculture — Réseau de communication de
données pour fermes d'élevage
Reference number
©
ISO 2007
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2007 – All rights reserved
Contents Page
Foreword. iv
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Abbreviated terms .4
5 General.6
6 Technical requirements and recommendations.6
6.1 Basic requirements.6
6.2 Connectors .6
6.3 Cables .7
6.4 Transport protocol.7
7 Network livestock farming communication .7
7.1 Farm use .7
7.2 Internet use.7
7.3 Multicast communication.8
7.4 TCP connections.8
7.5 Addressing devices.13
7.6 Configuration of network devices.13
7.7 Network management and monitoring .13
7.8 Communication steps .13
7.9 Communication levels.15
7.10 Communication functions .19
7.11 ADIS extensions.23
7.12 XML/ADED .28
8 Data dictionary (DD) .31
8.1 General.31
8.2 DD elements essential for network livestock farming .31
8.3 CODE SET and lists.32
8.4 Entities for describing communicated data contents.32
9 Electrical specifications.32
10 Mechanical specifications .32
Annex A (normative) Data elements.33
Bibliography .71
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 17532 was prepared by Technical Committee ISO/TC 23, Tractors and machinery for agriculture and
forestry, Subcommittee SC 19, Agricultural electronics.
iv © ISO 2007 – All rights reserved
INTERNATIONAL STANDARD ISO 17532:2007(E)
Stationary equipment for agriculture — Data communications
network for livestock farming
1 Scope
This International Standard specifies a protocol for the automatic and interactive communication and control of
computer systems used in livestock production. It supports communication within the livestock production as
well as across the Internet.
While it defines the basic protocol for data exchange, it uses generic data structures so that the protocol is
extendable regarding future requirements.
The protocol is applicable only to simple and/or clearly defined entities.
This International Standard deals with the networking of those services used for livestock production which
are provided by the devices in systems. It is not applicable to communication within subsystems.
The syntax of the transported data is based on the ADIS and ADED standards as defined in ISO 11787 and
ISO 11788; alternatively, XML/ADED can be used as described in this International Standard. Like the ADIS
standard specified in ISO 11787, it is implicit that the syntax is not intended for real-time data interchange.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 4217, Codes for the representation of currencies and funds
ISO 11787, Machinery for agriculture and forestry — Data interchange between management computer and
process computers — Data interchange syntax
ISO 11788-1, Electronic data interchange between information systems in agriculture — Agricultural data
element dictionary — Part 1: General description
IEC 60204-1, Safety of machinery — Electrical equipment of machines — Part 1: General requirements
IEC 60529, Degrees of protection provided by enclosures (IP Code)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11787 and ISO 11788-1, and the
following, apply.
3.1
bluetooth
industry standard for the wireless cross-linking of devices with small range
3.2
device
any machine or component which is connected to computer systems used for livestock production
3.3
MAC address
hardware address that uniquely identifies each node of a network
NOTE MAC is an acronym for media access control.
3.4
system
data processing or control component at the computer systems used for livestock production
3.5
subsystem
division of a system, which itself has the characteristics of a data communication system
3.6
network
interconnection of three or more communicating components which exchange data via a network
3.7
network management
execution of a set of functions required for controlling, planning, allocating, deploying, coordinating and
monitoring the resources of a network
3.8
datagram
fundamental unit of information carriage in all modern computer networks
NOTE It consists of a header, which contains the information needed to get the datagram from the source to the
destination, and a data area, which contains the data content (messages).
3.9
location
agricultural business and the various subsystems (shed, compartment, bay, place) of a farm
3.10
location address
sequence of sub-addresses separated by dots
NOTE The sequence begins with the farm number (15 N). The farm number starts with the numeric ISO Country
Code (ISO 3166/3 N) and is immediately followed by a unique national farm ID (12 N).
3.11
server
program in a device which provides a socket with which a client can link up to exchange ISO 17532 messages
and services
3.12
client
program in a device that is used to contact and obtain data from a server program on another or the same
device
NOTE An ISO 17532 client is designed to work with ISO 17532 server programs only.
2 © ISO 2007 – All rights reserved
3.13
parameter group
group of related parameters which can be used to configure machine configurations for ISO 17532
communication
3.14
parameter class
contains one or more parameter groups which are classified by a special function or task
3.15
parameter identifier
item type for machine configuration
3.16
DD entity
data element definition from the data dictionary (DD)
3.17
DD entity number
number used to identify a data entity in a data dictionary (DD)
3.18
DD item
data details of the data elements from the data dictionary (DD)
3.19
code set
fixed set of states with defined contents
3.20
multicast
delivery of information to multiple destinations simultaneously, using the most efficient strategy to deliver the
message over each link of the network
NOTE Delivery is performed only once and copies are created only when the links to the destinations split. “Multicast”
is used to refer to an IP multicast, which is a protocol for efficiently sending to multiple receivers at IP networks at the
same time.
3.21
multicast address
address of a multicast connection
3.22
transmission control protocol
TCP
connection-oriented, reliable delivery byte-stream transport layer communication protocol
3.23
user datagram protocol
UDP
minimal message-oriented transport layer protocol
3.24
Internet protocol
IP
data-oriented protocol used by source and destination hosts for communication data across a packet-switched
Internetwork
3.25
virtual private network
VPN
private communication network used within a company or by different companies or organizations
communicating over the Internet
NOTE Secure VPN use cryptographic tunnelling protocols to provide the necessary confidentiality, sender
authentication and message integrity to achieve the privacy intended.
3.26
unity
comparison figure with which the values of defined items are expressed
3.27
handle number
unique number used to identify a transaction or a named query
3.28
device ID
unique device number constructed by the MAC address ID
3.29
port
network port
interface for communicating with a computer program over a network
NOTE Network ports are numbered. UDP and TCP will attach a port number to the data sent, which is used by the
receiving network component to determine to which application on the device data should be sent.
3.30
session
period of communication activity
NOTE Reliable, interactive transfer of data between two devices in ISO 17532 communication is called a “session”.
3.31
transaction
one interaction between client and server
3.32
session end line
termination
end of a session
4 Abbreviated terms
ADIS agriculture data interchange syntax
ADED agriculture data element dictionary
AN alphanumeric
C conditional
DA data authentication
DD data dictionary
DHCP dynamic host configuration protocol
4 © ISO 2007 – All rights reserved
DNS domain name server
DF data line of faulty data + error item + impact item
DN definition line type of status normal (N)
EDI electronic data interchange
FTP file transfer protocol
IAONA international automation open networking alliance
IEEE institute of electrical and electronic engineers
IETF Internet engineering task force
IP Internet protocol
K key data element
LAN local area network
M mandatory
MCC multicast communication
N numeric
NLF network livestock farming
O optional
PIG industrial Ethernet planning and installation guide
PO processing instruction open
PP processing instruction pending
PPP point-to-point protocol
PR processing instruction result line
RJ45 registered jack type 45
SBC session-based communication
SN sequence number
TCP transmission control protocol
TN termination line with status normal (N)
UDP user datagram protocol
URI uniform resource identifier
URL uniform resource locator
UTC universal time (also known as Greenwich mean time)
VA value line for authentication
VE value line error handling information
VF value line faulty data + error code + impact code
VN value line type and status
VPN virtual private network
WLAN wireless local area network
XML extensible markup language
ZN end session
NOTE For descriptions of line type and status character abbreviations, see Figure 8.
5 General
Networks of computer systems are necessary in livestock farming for controlling various processes (e.g.
feeding and climate), environmental balance (field yard balance), and comprehensive environmental and
animal protection, as well as for economic reasons.
In order to use services over a networked infrastructure, information must be transported. For this, the way in
which the information is to be communicated between the communication partners needs to be known in
advance. The purpose of this International Standard is to provide a protocol that serves this need.
IP is used as the basis for ISO 17532 communication and TCP streams are used to ensure reliable
communication. For management and short messages, UDP datagrams are multicasted.
For the notation of the description of the ADIS syntax, see ISO 11787.
As the physical layer for the IP, the Ethernet as defined in IEEE 802.3x is the most commonly used today, and
this International Standard is designed to support it. IP packets can be transported using wired or wireless
communication.
This International Standard defines the requirements for the physical connections and the data communication
in a network used for livestock production. The requirements apply for the devices connected directly to this
network.
6 Technical requirements and recommendations
6.1 Basic requirements
Fast data communication between the components shall be guaranteed by the devices involved.
If real-time communication is needed, logical separated network segments shall be configured for
communication in real time within the important segment.
A structured cabling or wireless connection shall be provided.
6.2 Connectors
The use of RJ45 connectors is recommended. Depending on the environmental conditions (light or heavy
duty), the connections shall comply with protection classes IP 20 or IP 67 in accordance with IEC 60529.
6 © ISO 2007 – All rights reserved
6.3 Cables
The devices of the manufacturers shall be star, bus or ring-shaped connections. A four-wire cable is sufficient
for the data connection.
For the wiring of the stable net, cable types corresponding to the IAONA recommendations (PIG, release 4.0,
2003) should be used. The transmission speed is determined as a minimum of 10 MB/s for copper wire
connections. For the wiring within the barn area, safety class system IP 67 (heavy duty) should be used. In
less susceptible environments (stable office), IP 20 (light duty) is sufficient. As basic requirements for the
physical layer, the recommendations of the IAONA shall at least be met.
6.4 Transport protocol
Both TCP/IP and UDP are used — TCP/IP for reliable connections, UDP for multicast addressing
communication. Components (WLAN, Bluetooth devices) that can be connected to the farm network via
TCP/IP and UDP, and which conform to corresponding IEEE standards, are supported. Figure 1 shows this
architecture graphically.
Figure 1 — ISO 17532 and TCP/IP layers
7 Network livestock farming communication
7.1 Farm use
There are no limitations on ISO 17532 communication within livestock production, i.e. within one physical
network. A local network can be connected via the Internet using VPN technology, whereby the network can
be extended beyond the borders of one farm (physical network).
7.2 Internet use
The coupling of devices using multicast communication over the Internet is not supported. The data exchange
between farm devices and Internet partners shall be organized by special services.
NOTE In Internet connections, only TCP connections are supported in ISO 17532 communication. TCP packets can
be transported using a variety of physical layer protocols, e.g. PPP (modem use) or Ethernet.
7.3 Multicast communication
The multicast address 224.111.234.123 and port numbers 2434 for ADIS/ADED and 2435 for XML/ADED
should be used in local networks. If other multicast addresses are used, they must be configured manually in
all the devices.
Due to limitations in the transport of UDP multicast datagrams via the underlying physical layer (e.g. Ethernet),
the data area of a datagram must not exceed 1 024 B. The sender of a datagram with ADIS lines also needs
to ensure that the datagram length of the transformed XML data does not exceed the length of 1 024 B. Each
UDP multicast datagram starts with 8 B for a header containing information about the ISO 17532 MCC
communication. Bit 0 of the first byte is set when the datagram is transferred by the transformer to the other
MCC address. If bit 1 is set, there is no need to transform the datagram. To keep this sort of message small,
no header lines are sent in the datagram. In multicast communication, no header data with information on the
data dictionary used, etc. can be sent, so the recipients of the data must be able to react flexibly to the data
structure.
In UDP datagrams, a value line (ADIS and XML/ADED) is preceded by a definition line referring to the same
entity.
NOTE 1 Management functions and the distribution of simple messages can be easily conducted using UDP as
multicast messages without knowing the network address of every single device.
NOTE 2 UDP communication does not acknowledge receipt of UDP packets and is not absolutely secure.
NOTE 3 Owing to the nature of multicast, every device connected to an ISO 17532 network receives the messages
sent to the commonly agreed multicast address. It is then the responsibility of the administrator to check bus load and time
behaviour.
7.4 TCP connections
7.4.1 General
TCP connections shall be used when it is necessary to ensure that no information is lost or mixed up. The
initiating device is called the “client” and the answering device, which was listening for a connection, is called
the “server”. Therefore, TCP connections are always point-to-point connections (by default, the
communication partners use port number 2434). If, on one computer, several SBC services are offered by
several programs, it is necessary during publish/subscribe to arrange for alternative ports. This is the purpose
of specifying the port number (item number 901044) in the entities service request (990110) and service
inquiry reply (990109).
For transforming data streams between XML/ADED and ADIS/ADED, conversion software is needed.
NOTE When implementing software that handles TCP connections or network connections in general, it is necessary
to consider using a timeout to close a connection when the communication partner does not send any messages or no
longer responds. However, it has to be kept in mind that a request to search certain data can cause a database system to
require quite some time. So timeouts have to be selected carefully. For very long-lasting orders, asynchronous
transactions are a means of carrying out the order without the need of setting very long timeouts.
7.4.2 Session
Each session is divided into separate transactions and is always carried out using a TCP connection between
two devices (point-to-point communication).
A session starts with information on the authentication of the client. If the authentication stage is left out by the
client, the session starts with the header line. Authentication and header lines are encapsulated in one
transaction each. Whether a login is necessary depends on the demands of the devices. It can be negotiated
during publication of the services in the boot-up stage of a device. The header line supplies basic information
on how the following data in this session has to be interpreted in terms of the DD version that was used to
compile the data of the session.
8 © ISO 2007 – All rights reserved
A session consists of 1.n transactions and ends with a Session End line. Generally, the client sends a
Session End line to the server to make sure the server takes note that the TCP connection is closing.
Otherwise, there could be a lock-up of the used server TCP port for several minutes (depending on the
operating system) before the same TCP port can be used again.
Within a transaction, a variety of functions can be carried out:
⎯ authentication;
⎯ header lines;
⎯ sending or receiving data;
⎯ issuing a search request;
⎯ executing a named query;
⎯ executing a processing instruction.
See Annex A for a detailed list and description of these functions.
Figure 2 shows the flow of the described session.
a
Both these messages are part of the operating system's implementation of the TCP stack.
Figure 2 — Session
7.4.3 Transaction
Each transaction is separate from the next. Figure 3 shows that device A (client) starts the transaction and
device B (server) processes the sent data and sends back either results, error information, comments or
nothing.
The client is shown as initiating a transaction by sending the starting line of one of the functions specified in
7.4.2.
a) Sending a Definition Line starts the function “sending data”.
b) Search Request starts with either a Search or a Request Line.
c) Posting a Named Query is started by sending a Query Line.
d) Processing instructions are started by a Processing Instruction line.
e) Login (Authentication) and Header are handled alike.
f) Header lines are formulated as special transactions.
It is not possible to use this feature by means of multicast messages.
Figure 3 — General handling of transactions
10 © ISO 2007 – All rights reserved
In contrast with the start of a transaction, the end is always marked with the same line, the Transaction End
line. Because the client initiates a transaction, it is up to the client to send the Transaction End line after
issuing all necessary information. The receiver may have to process the transaction. The receiving end
(server) then needs to interact with the client by sending back the requested information or, possibly, any error
codes, comments or the like. After processing the transaction that was sent by the client and sending back
any information (requested or not), the server then sends back the Transaction End line.
Before starting a new transaction, the client (initiator of the connection to the receiving end) has to wait for the
handshake, i.e. the reception of a Transaction End line from the server.
If a transaction cannot be handled correctly for any important reason by one of the communication partners,
the session can be cancelled by one of the partners by sending a Session End line. The current transaction is
then cancelled, too. After cancelling a session, the TCP connection must be shut down immediately. A TCP
connection may not be shut down generally without issuing a Session End line due to technical details of the
IP. In certain circumstances it is not possible to open a connection to the same port for a certain time after
irregularly ending a TCP connection.
On the one hand, the transaction partners can generally decide whether they want to react to the incorrect
transaction end with a rollback or by sending more data. On the other hand, a regular Transaction End
indicates that the services within the transaction have definitely been carried out correctly. An exception, of
course, is the asynchronous transactions because they are carried out while the initial transaction, session
and TCP connection are shut down. Asynchronous transactions (see 7.4.4) are identified by a handle number
for future reference.
7.4.4 Asynchronous transactions
Asynchronous transactions are special in the sense that they are carried out while there is no communication
connection open between the requesting and the executing end of the interaction of two devices. Immediately
in the login, but also in the query or processing instruction, the client can issue a URI to which the server
should transfer asynchronous results. If this URI is not given, a TCP connection is created from the server to
the default port of the client as a reverse channel as soon as the server wants to send back the asynchronous
results.
To refer to the issued function, the asynchronous result carries the same, unique handle number.
The operator finds out whether the data needs to be sent, e.g. as an e-mail by parsing the URI. Within the URI
“e-mail” is one of the predefined URI schemes that also gives information about the access mechanism (how
to send an e-mail).
NOTE RFC 2396 gives details on URI and URI schemes.
The new ADIS status characters presented in 7.11.3 inform the client that data will be sent back
asynchronously. Figure 4 shows in detail how asynchronous transactions are handled.
a
Start of communication, such as authentication, is not shown in this diagram.
b
DN, VN lines that, e.g., describe the entity “mix jab”.
c
Return transaction ID identifying the process.
d
The server can also respond with a PR line (“process result”). This tells the client that the request process is already
finished.
Figure 4 — Asynchronous transactions
12 © ISO 2007 – All rights reserved
7.5 Addressing devices
7.5.1 TCP addressing
A device in the network has to be addressed using its IP number. This is given to the device by the
configuration or by a DHCP server.
7.5.2 Addressing with URI
Transmitted data is often only part of a data complex where partitions of the data are kept in a number of
distributed sources. ADIS already provides a way to include ADIS data stored in external files. The scope of
this reference shall be extended to the extensive concept of URL and URI used in Internet communication.
An URI can be used to define the unity of an entity or as a part of an include line in the communication.
NOTE FTP is not supported because it cannot be assumed that all farm businesses are always accessible in the
Internet under their own domain.
7.6 Configuration of network devices
The device must publish the device description with the device addressing URI. The configuration service
(configurator) then establishes a connection to the device and sends a configuration processing instruction
with all the necessary parameters like device-location linking (990104), machine-location-service linking and
generic machine configuration (990114).
NOTE 1 Configuration of ISO 17532 devices can be handled manually by the technicians who install the devices. This
International Standard offers elements which allow configuration of a device with processing instructions, which include
the setting of parameters for the configuration of the device.
NOTE 2 The device configurator can be a web application, which can be controlled by a browser.
7.7 Network management and monitoring
There is a time limit on subscribing to data. If device A will not update its subscribing, device B stops sending
after 24 h (default). This default can be changed using the item “Time period for delivery” (901011). Because
multicast communication is not safe, a device shall re-send service information (i.e. climate data) after the
“Time period for delivery” even if there is no change in data value. One device has to be the time server. This
must be configured. This device will send the entity “Time synchronization” (990116) every hour by default.
The entity contains the local time and the UTC. Alarm messages contain the source device, a timestamp, an
alarm number and a describing text. A service listening for special alarm messages has to manage the alarms
(e.g. text message to the farmer, triggering an acoustic or visual signal) according to the needs of the farm
requirements. An alarm (entity 990117) is repeated under MCC until an alarm receiver acknowledges
processing of the alarm. The answer is sent back with the status character Result. Monitoring and
visualization tools can require that all devices in the farm network publish the device description, device
location, device-location linking, machine-location-service linking, device-location linking and machine-
location-service linking entity, in order to provide services for network monitoring.
7.8 Communication steps
The following list illustrates the basic steps in ISO 17532 communication. Steps a) to e) can be carried out
using simple multicast messages. The final step, f), completes the list by adding the general possibility of
transferring any data using a session.
NOTE 1 Possible ISO 17532 communication ranges from simple messages that are not guaranteed to be received by
all the listeners (MCC) to session-based communication for reliable transfer of possibly large amounts of data.
a) Publish (MCC)
A device newly registered in the network after starting up publishes its services (Service-Publish-Entity).
b) Request (MCC)
After publishing its own services, a device may look for desired services within the network
(Service-Inquiry-Entity).
c) Publish-On-Request (MCC)
When inquiries about certain services are sent to the network devices by means of multicast messages
[step b)], then any device that offers such a service should answer this request
(Service-Inquiry-Reply-Entity).
d) Event messages (MCC)
Devices send specific messages triggered by events or alarms. Any device should be able allow other
devices on the network to configure when or why it should send these messages. Otherwise, the devices
need to be manually configurable in respect of when and why they send these messages.
e) Subscribing to services (preferably MCC)
Whenever a device needs to rely on the data of a certain service, there is the possibility of requesting a
subscription to the service (Service-Request-Entity). A device can subscribe to the services published
under step c) if the device that offers the service can send the data using a session (i.e. TCP connection).
The data source is required to send the data according to the conditions defined in the
Service-Request-Entity. Apart from the option of using a session, there are other ways to provide the
subscribed information, e.g. by e-mail, which can be specified in the Service-Request.
f) Session-based communication (SBC)
More extensive communication processes such as Named Queries, Processing Instructions and Search
Requests can be handled using a session. Subscriptions to services, steps a) to e), can be handled by
sending the subscribed services via a session. A session is one way of transferring data reliably.
Therefore, the device that requests a subscription of certain services can rely on the fact that it will not
remain unnoticed if the data cannot be transferred to the subscriber for any reason. Apart from using a
session, there are other ways to transfer subscribed data (see above, see Service-Request-Entity: Item
Type-of-provision).
NOTE 2 MCC is generally not possible using the Internet. It is a means of communication that enables devices within
one farm (one local network) to discover each other and the other's services.
Table 1 describes the circumstances under which the above steps are allowed (+) or not permitted (−).
Table 1 — ISO 17532 communication steps
Internet
Step MCC TCP/IP Farm network
a) + − + −
b) + − + −
c)
+ − + −
d) + − + −
e) + + + +
f) − + + +
14 © ISO 2007 – All rights reserved
7.9 Communication levels
Building on the communication steps given in 7.8 are the protocol’s four communication levels, a) to d) below.
NOTE Of course, simple devices only support the ISO 17532 entry level, for example, a temperature sensor that only
sends measurements and is not able to process requests for subscriptions to temperature data.
a) Entry level: MCC via common port and common address
Communication via this mechanism is designed to achieve various purposes, dispatching messages from
manually configured components that send simple messages to the network over time (simple sensors,
etc.).
1) Only multicast messages are used for communication.
2) Sensors and simple devices in general regularly send their data in simplified ADIS or XML/ADED
syntax to the common multicast address (multicast group).
3) Because multicast messages are sent using UDP, no information unit may exceed the maximum size
for a datagram (1 024 B for the data area in a datagram due to Ethernet-specific maximum
transmission unit).
4) An information unit consists of a definition line and a value line. Even if the data is sent at high
frequency, every information unit (multicast message) is required to contain both the definition line
and the value line.
5) The recipients filter out the data relevant to them from the multicast communication using simple filter
mechanisms, e.g. only accepting certain entity numbers.
b) High-level MCC
At a higher level, multicast messages are used to publish the device's services. The publication of
services can be repeated regularly and the devices should be able to answer requests for services
(Service-Inquiry-Entity and Service-Inquiry-Reply-Entity). Data should not be sent autonomously. Devices
are asked to only send data after receiving at least one request for that service. This includes data sent
on a regular basis, such as temperature data.
Figure 5 illustrates a boot-up sequence. The multicast address element shown in the figure should be
considered as a distributor: it distributes messages to all devices that are part of that multicast group (for
the purposes of this International Standard, all devices that are part of ISO 17532 communication in a
local network).
1) Publish services: device A publishes information about the services offered to the multicast group.
Any device interested in that information should take further action.
2) Service inquiry: device A is interested in certain services and sends a request about these services
to the multicast group.
3) Service inquiry reply: at least one device is able to provide the requested service and sends back an
answer to the request.
4) Service data: if data of a service can be sent using multicast messages (which are uncertain to be
received to a certain degree), then devices can send these messages to the multicast channel.
Device A will receive such messages. They can be a mixture of requested and not requested
services.
Figure 5 — Boot-up sequence — Type 1
NOTE No message sent to the multicast group is guaranteed to be received by all possible devices in the
network, for a number of possible reasons: network failure, device is temporarily offline, and so on. To increase the
chance of receiving an answer to a service inquiry, the inquiry should be repeated at least once. To ensure that high
network load does not become a problem, messages should only be repeated after a certain amount of time. The
time between two multicast messages should also be dependent on a random number. Adding a random number to
the waiting time will lower the probability of network congestion.
c) High-level reliable communication using subscriptions
If communication on a high level needs to be reliable, then a session (see above) shall be used. During a
session data is transmitted over a TCP connection. This type of connection is responsible in part for the
reliability of the connection. The concepts of session and transaction are responsible for making the
connection completely reliable.
Figure 6 shows a sequence of a device booting up and subscribing to certain services in which it is
interested. The sequence starts with the first three steps, as in the boot-up sequence shown in Figure 5,
however, device B, omitted from Figure 5 for reasons of simplification, is shown.
Again, a set of the already mentioned communication steps is used:
1) Publish services (MCC): device A offers services [see b)].
2) Service inquiry (MCC): device A is looking for services [see b)].
3) Service inquiry reply (MCC): device B is offering services on request [see b)].
4) Service request (MCC): device A now starts a request to subscribe to the service. Although the
request is posted to the multicast group and all the devices are able to receive it, only device B will
register a subscription of a service to device A.
16 © ISO 2007 – All rights reserved
5) The multicast message to request a service, i.e. to acquire a subscription, carries information about
the device that was asked for a subscription.
6) Service request reply (MCC): upon successful registration of a subscription, device B sends back a
service request reply.
7) Use session to send data: after sending back the acknowledgment of the subscription, the
subscribed data is transmitted, if present. Subsequently, data is only transmitted if it has changed.
Figure 6 — Boot-up sequence — Type 2
d) Receiver-controlled communication
Without using a subscription, a device can inquire whether certain services are available (service inquiry)
and then open a session (TCP connection) to the device that offers that service. There are numerous
functions that can be used within a session like Search Request, Named query and Processing
Instruction (see 7.10). These functions allow the receiver to specify what data should be sent exactly, e.g.
by specifying search criteria. Figure 7 shows the detailed flow of a receiver-controlled communication
and, again, the first three steps are the same as in boot up sequences types 1 and 2, shown in Figures 5
and 6.
The following communication steps are used.
1) Publish services (MCC): device A offers services [see b)].
2) Service inquiry (MCC): device A looks for services [see b)].
3) Service inquiry reply (MCC): device B offers services on request [see b)].
4) Start session using TCP connection: device A wants to receive certain data from device B.
Therefore, a session is used to request and transfer that data immediately (or later, as asynchronous
results).
5) Ask device B to send certain data: device A specifies which data is requested. With a search/request
or a communication function such as Named Query or Processing Instruction, it is possible to specify
the service the data should come from and the search criteria the data should fulfil.
6) Send answer: if possible, device B answers the request for data from a specific service immediately.
As mentioned above, there is an exception: if, for example, a long-lasting processing instruction is
requested, device B can send an answer to device A immediately saying that the results will be
available in the future and that device B will then open a new session to device A to send the results.
(Apart from process
...
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...