ISO 11783-13:2022
(Main)Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 13: File server
Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 13: File server
The message set specified in this document is designed to support the needs of tractors and implements in using the services of a file server (FS). An FS is a distinct control function (CF) on the mobile implement control system that enables all CFs to store or retrieve data from a file-based storage device.
Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication de données en série — Partie 13: Serveur de fichiers
L'ensemble de messages spécifié dans le présent document est conçu pour répondre aux besoins des tracteurs et des outils en utilisant les services d'un serveur de fichiers (SF). Un SF est une fonction de commande (FC) distincte du système de commande de l'outil mobile qui permet à toutes les FC de stocker ou d'extraire des données d'un dispositif de stockage basé sur des fichiers.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 11783-13
Third edition
2022-05
Tractors and machinery for
agriculture and forestry — Serial
control and communications data
network —
Part 13:
File server
Tracteurs et matériels agricoles et forestiers — Réseaux de
commande et de communication de données en série —
Partie 13: Serveur de fichiers
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 .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Requirements . 2
4.1 General message format . 2
4.2 File data format . 3
4.2.1 Data . 3
4.2.2 Bit groups . 3
4.2.3 Integer . 3
4.2.4 Character string . 3
4.3 Data transmission control . 3
4.3.1 General . 3
4.3.2 Strategy . 3
4.3.3 Timeout . 4
4.4 Date and time support . 4
4.5 Multi-client support . 4
4.6 File Handles . 5
4.7 Volumes . 5
4.8 Primary volume . 6
4.9 Commands . 7
4.10 Connection/Disconnection of a client . 7
Annex A (normative) Character set .9
Annex B (normative) Parameter definitions .15
Annex C (normative) File server message definitions .27
Annex D (informative) Common file system examples .58
Annex E (informative) Why path names end with a backslash .59
Bibliography .60
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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.
This third edition cancels and replaces the second edition (ISO 11783-13:2011), which has been
technically revised.
The main changes are as follows:
— removal of support for short, 8.3 format, path and file names;
— addition of support for Unicode characters in path and file names;
— addition of clarifications to improve the implementation and testability of the file server protocol.
A list of all parts in the ISO 11783 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
ISO 11783 specifies a communications system for agricultural equipment based on the ISO 11898-2
1)
protocol. SAE J1939 documents , on which parts of ISO 11783 are based, were developed jointly for use
in truck and bus applications and for construction and agriculture applications. Joint documents were
completed to allow electronic units that meet the truck and bus SAE J1939 specifications to be used by
agricultural and forestry equipment with minimal changes. General information on ISO 11783 can be
found in this document.
The purpose of ISO 11783 is to provide an open, interconnected system for on-board electronic systems.
It is intended to enable electronic control units (ECUs) to communicate with each other, providing a
standardized system.
1) Society of Automotive Engineers, Warrendale, PA, USA.
v
INTERNATIONAL STANDARD ISO 11783-13:2022(E)
Tractors and machinery for agriculture and forestry —
Serial control and communications data network —
Part 13:
File server
1 Scope
The message set specified in this document is designed to support the needs of tractors and implements
in using the services of a file server (FS).
An FS is a distinct control function (CF) on the mobile implement control system that enables all CFs to
store or retrieve data from a file-based storage device.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 11783-1, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 1: General standard for mobile data communication
ISO 11783-3, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 3: Data link layer
ISO 11783-5, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 5: Network management
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11783-1 and the following
apply.
ISO and IEC maintain terminological 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
client
control function (CF) on the mobile implement bus that uses the services of the file server (3.5)
3.2
directory
file which stores administrative information about other files (3.3)
3.3
file
data object that stores data on a storage device
3.4
file attribute
bit-coded information that defines the type and features of a file (3.3)
3.5
file server
FS
control function (CF) on the mobile implement bus that provides storage for files (3.3) and uses a set of
commands for the handling of, and access to, these files
3.6
filename
name conforming to requirements of a character set, which identifies a file or directory (3.2)
Note 1 to entry: See Annex A for the character set.
3.7
Handle
data object used for accessing files (3.3) and directories (3.2)
3.8
hidden attribute
file attribute (3.4) indicating that the file should not appear in a directory listing
Note 1 to entry: A client (3.1) sets this attribute by using the file server (FS) commands.
3.9
path
specification of a filename (3.6) that may also include the directory name
3.10
read-only attribute
file attribute (3.4) used to prevent writing to, or deletion of, a file
Note 1 to entry: A client (3.1) sets this attribute by using the file server (FS) commands.
3.11
volume
directory (3.2) that refers to a specific logical or physical storage unit or space
Note 1 to entry: The primary volume is the volume used as current volume when the file server (FS) is started.
4 Requirements
4.1 General message format
The general message format uses the parameter group number as the label for a group of parameters in
accordance with Annex C. Each of the parameters within the group can be expressed as characters, as
scaled data defined by the ranges given in 4.2, or as one or more bits. Characters shall be transmitted
with the left-most character first. Numerical parameters consisting of two or more data bytes shall
be transmitted least significant byte (LSB) first. Individual parameters shall be in accordance with
Annex B. When variable-length messages have eight or less data bytes, these messages shall be
transmitted in a single controller area network (CAN) frame. When variable length messages have nine
or more data bytes, the transport protocol (TP) or the extended transport protocol (ETP), in accordance
with ISO 11783-3, is required. When a message has less than eight data bytes, the unused bytes shall be
filled with FF values.
4.2 File data format
4.2.1 Data
Data consists of a block of bytes (unsigned eight-bit values). All values in the range of 0 … 255 are
10 10
allowed. There is no special handling of individual characters (control characters, end-of-line markers,
end-of-file markers or similar characters).
4.2.2 Bit groups
Groups of one to eight bits are packed into one byte as bit 7 … bit 0. Groups of nine to 16 bits are
packed into two bytes in the order of LSB as bit 7 … bit 0, followed by most significant byte (MSB)
as bit 15 … bit 8. Unused bits in a bit group default to a value of 0 (zero).
4.2.3 Integer
Integer values are formatted as follows:
Unsigned 8 bit 1 byte 0 … 2 −1 0 … 255
10 10
Unsigned 16 bit 2 bytes, LSB first 0 … 2 −1 0 … 65535
10 10
Unsigned 32 bit 4 bytes, LSB first 0 … 2 −1 0 … 4294967295
10 10
31 31
Signed 32 bit 4 bytes, LSB first, two's compliment −2 … 2 −1 − 2 1 4 7 48 3 6 48
1 0 …
+2147483647
4.2.4 Character string
A string contains characters represented by one or more bytes (unsigned eight-bit values). The length
of a string is specified by a string length data item. The characters in a string used as a filename or a
path name shall be as specified in Annex A. The support for Unicode characters is added in file server
version 4, see B.5 Version Number. Prior to version 4, a character is by a single byte.
4.3 Data transmission control
4.3.1 General
Each communication transaction between a client and the FS is initiated by a request from the client and
terminated by a response from the FS. In order to provide fail-safe communications, it is important that
the client assigns the received response to a corresponding request and repeat an erroneous request
without triggering the complete execution again.
4.3.2 Strategy
The client can issue a request and receive no response because of transient communication problems.
The failure can happen during the request message, i.e. the FS does not receive the request, or during the
response message, i.e. the client does not receive the response. The client cannot distinguish between
these two cases and shall repeat the request to obtain the requested data.
If there is no transaction strategy, the problem of the FS not receiving the request is resolved by the
client sending a second request and the FS responding with the requested data. However, if the client
does not receive the correct response data message and sends a second request, the FS then sends the
next data from the file; this is because a data request automatically advances to the next data in the file.
A transaction strategy is therefore required to prevent such errors. Each client on the network
maintains its own transaction number (TAN) counter, which should start at 0 after a power cycle.
Each client generates a TAN for each request, that it sends to the FS. Each TAN shall be different from
the previous. This can be done by incrementing the last TAN used, for the next request. The client is
responsible for checking that a received response contains the same TAN that was used in the request
during the communication session, thus ensuring that there are no lost commands. The FS shall
remember the last command processed and response message sent for each client. The FS compares
each new request with the previous request from the same client. If the TAN is not the same, the request
is implemented, and the response is sent. If the TAN is the same as the previously received request,
the request is not implemented, and the previous response is sent. Thus, if the client sends a second
request, in the case where the FS never received the first request, the FS receives the TAN for the first
time, implements the request and sends the correct data response. If the FS receives a request with the
same TAN that it has already received, it does not implement the request, but the previous response is
retransmitted.
4.3.3 Timeout
The execution time of all FS commands (the time between request and response) is maintained within
reasonable limits. The client shall monitor the time while waiting for a response.
The timeouts specified in ISO 11783-3 for the transport protocol and the extended transport protocol
shall be met for the execution of commands.
If a timeout expires, the request is assumed to have failed and the client shall repeat the request using
the same TAN.
If a request response takes longer than 200 ms after the completion of the request, the FS shall send the
status message to indicate busy state to the client. This provides a request timeout of 600 ms if the FS
status message does not show a busy status.
4.4 Date and time support
2)
Several FS commands require a file date and time. UTC is used for this time. The file server's
implementation of real time support can be either by maintaining its own real time information
or by requesting the time and date information using the Time/Date parameter group specified in
ISO 11783-7.
If a client requests the date and time for the root of a volume, or the volume list itself, the file server
response shall include the error “Access denied”.
The file server shall respond with the most recent time where the folder/file was accessed if the
operating system provides this information. Otherwise, the file server shall respond with the
information that is available.
Due to possible date and time changes (by the operator or other means) there is no guarantee, that the
date and time associated with files and folders indicates the actual chronological order, in which the
files/folders were accessed.
4.5 Multi-client support
The file server shall support multiple clients. If more than one client has a connection simultaneously,
the file server shall function with each client as if it is the only one on the network. There shall be no
interference between the commands processed for different clients.
The file server shall accept connections from all clients on the network. If the file server has limited
resources, it may limit the number of open file handles. Prior to file server version 4 the requirement to
support all connections was not clearly defined.
Upon connection of a client, the file server initiates the current directory for that client as the root
directory of the primary volume of the file server file system. If there are no volumes, then the current
2) Coordinated universal time, or universal time, formerly known as Greenwich mean time (GMT).
directory is set to the list of volumes “\\”. The client is required to use the appropriate Change Current
Directory or Open File commands to access files that need to be unique for that client. In the case where
multiple clients require access to common files, these clients are responsible for synchronizing their
directory and file naming conventions to enable access to these common files. To prevent unintentional
access to manufacturer proprietary files, a reserved directory name is specified. The naming convention
of the manufacturer-specific directory is:
MCMC0000
where 0000 contains the four-digit manufacturer code (defined in accordance with ISO 11783-5 and
listed in ISO 11783-1) in decimal representation, formatted with leading zeroes. A client shall not use
this manufacturer-coded directory name using a manufacturer code other than the manufacturer code
in its NAME field. When the client attempts to open a file in a manufacturer-specific directory where
the manufacturer code in the NAME of that client is not that of the manufacturer-specific directory
name, the FS shall prevent access and return an “access denied” error code.
The complete value range from 0000 to 9999 shall be handled as manufacturer code, even though the
manufacturer code is defined as an 11-bit value in ISO 11783-5, which limits the possible value range to
0 to 2047.
When a file server supports multiple volumes, manufacturer-specific directories can be created on
each volume. Creation of a manufacturer-specific directory is the responsibility of the client. The
manufacturer-specific directory shall only be placed at the root of each volume. If a folder with the
same naming convention (MCMC0000) is found in a subfolder, it shall be treated like any other folder,
i.e. it is not manufacturer specific.
4.6 File Handles
An FS may support multiple file Handles. Many of the commands available for the FS create and/or use
file Handles. However, there are some commands that only use folder or filenames. Internally, if the
FS creates a file Handle to process these commands, the number of open files shall be incremented to
reflect the internal status of the FS.
4.7 Volumes
Different types of media (Flash memory, removable media, ruggedized disk drives, etc.) can be assigned
to different volumes.
An FS can support multiple volumes. It is also possible for an FS to list no volumes — for example, with
uninitialized media or no device found.
The root of a removable media is the root of the volume provided by the file server to the clients. For
non-removable volumes, like display memory, a folder on that volume can be the root of the volume
provided to the clients, in order to protect critical areas of this memory.
The list of volumes, specified by “\\”, is the highest layer (or base) of a directory structure.
Executing a change current directory command with “.\” based on the root of a volume, would set the
current directory to the volume list. Executing the command based on the volume list itself, will keep
the current directory in the volume list.
If the current directory is the volume list, the client can use relative paths starting with the volume
name.
EXAMPLE Relative path Vol1\ results in absolute path \\Vol1 if \\ is current directory.
It is recommended to use only media with a file system that supports long file names. The behaviour
with other file systems is not defined and can result in unexpected behaviour when changing such
volumes between file server systems.
The names of the volumes are determined by the FS; however, the manufacturer of a FS may allow a
proprietary service tool to name volumes using the Initialize Volume Request message (see C.5.2.2).
NOTE This document does not specify how the service tool selects the media or volumes to initialize if they
are not named and listed in the list of volumes “\\”.
4.8 Primary volume
The primary volume shall be a removable media. If no primary volume is available when a client
connects to the file server, Get Current Directory Response shall report an empty path and error code 4.
Any file operations with a relative path shall return error code 4. When a removable media becomes
available, and the current directory is still an empty string, the primary volume is being set to this
removable media and current directory points automatically to the root of the removable media.
Servers shall use removable volumes as primary volume to be compatible with legacy clients which
expect a removable media as the primary volume.
Clients should always read the volume list and select a volume suitable for their task.
See Figure 1.
Figure 1 — Selecting initial directory
4.9 Commands
To help identify communication issues, the FS shall respond to all destination specific commands.
The FS shall respond with a NACK (ISO 11783-3), when receiving:
— unspecified commands;
— empty request message (0 data byte).
The file server shall respond with Error Code 47 Malformed Request, if it receives a message, which is
shorter than expected.
4.10 Connection/Disconnection of a client
Clients shall establish connection to the file server by sending the Client Connection Maintenance
message (CCM) (C.1.3). The connection shall be established before the client sends any messages
containing a TAN to the file server. The CCM shall be repeated at 2-second intervals, to maintain the
connection.
NOTE For version 3 and prior, the requirement for CCM was not clearly specified, therefore those clients
might not be sending CCM as specified above.
The file server shall accept a client as connected when the file server receives the CCM or any Client
to Server message containing a TAN. After 6 seconds without receiving CCM or any Client to Server
message containing a TAN, the file server shall consider the client as disconnected.
When a client is disconnected, the file server shall close all files, which are open by the disconnected
client, and all Handles associated with that client become invalid. The client's Current Directory shall
be reset to the default.
See Figure 2.
Figure 2 — Client connection and disconnection
Annex A
(normative)
Character set
A.1 Valid characters
The file server uses filenames and path names. Every character used for filenames and path names is
validated by the FS using the filename and path definitions given in A.2. Only printable characters are
visible when presenting the filename or path name to a user.
The support for short, 8.3 format, file names, has been deprecated in file server version 4. An FS server
implemented according to version 4 is required to support filename and path names per the definitions
provided in A.2.
A.2 Filename and path definitions
A.2.1 Nomenclature
Definitions:
[ ] any of the characters in the set, including none from the set (optional);
[A-B] defines an inclusive range from the first through the last;
( ) group;
< > character class;
\ escapes the following character, as in “\[”, which indicates a single left bracket,
not the containment of a set;
A | B sequence “A” or “B”;
A + B sequence of A followed by B;
{m} exactly m of the preceding set;
{m,n} from m up to and including n of the preceding set;
\xXX character code in hexadecimal notation where XX are two hexadecimal digits (\x20,
for example, indicates character code 32, which is the space character).
A.2.2 Name definitions
A.2.2.1 Names
Names are from one to 255 bytes in length, using the character set given below. The commonly used file
systems given in Annex D were used to determine name restrictions that allow these names to be used
with minimal feature loss.
Note that the length of names is specified in bytes. The number of bytes required for a name depends on
the Unicode characters and Unicode encoding method used in that name.
To avoid incompatibility between different operating systems, the client shall not create folder/files
with names, which only differs in case, and names shall not end with a '.' or include ‘<’, ‘>’, ‘|’ (the latter
three can cause issues on FAT32).
LongNameChar ::= any single character defined by Unicode/ISO/IEC 10646, except 0x00 to 0x1F,
0x7F to 0x9F, ‘\’, ‘*’, ‘?’, ‘/’.
WildCardChar ::= [ *? ] {1}
ManufacturerSpecificDirectoryChar ::= [ ~ ] {1}
PathSeparatorChar ::= [ \\ ] {1}
VolumeListIndicator ::= [ \\ ] {2}
ParentFolderIndicator ::= [ . ] {2}
CurrentFolderIndicator ::= [ . ] {1}
MfgSpecificFolderIndicator ::= [ ] {1}
LongWildCardNameChar::= [ | ] {1}
LongName ::= [ ] {1,254}
LongWildCardName ::= [ ] {1,254}
A.2.2.2 Filenames
Filenames use the names defined in A.2.2.1.
LongFileName ::=
EXAMPLE Test, Test.txt, Test Filename.long.name (specifically a LongName).
A.2.2.3 Volumes
Volumes use the names defined in A.2.2.1.
VolumeName ::=
EXAMPLE VOL_B, Flash Volume
A.2.3 Path definitions
A.2.3.1 General
A path definition is similar to a filename definition but has additional prefix definitions and delimiters
between path segments.
When a directory listing from path “\\” (two backslashes) is requested, the FS shall return a list of
volumes. All file servers shall support “\\” so that the clients can query the volumes (including removable
media), even if the FS has only one volume.
The two predefined special directory names, “.” and “.”, refer to the current (“.”) and parent (“.”)
directories. These predefined directory names shall not be reported in a directory listing but may be
used in a path name to specify reference to a current or parent directory.
In case they are used in a path name, the file server shall normalize the path to remove “.” and “.” before
the path is checked or used by any command.
EXAMPLE 1
Assumption: Current directory is \\Vol1\SomeDirectory\
Relative path: .\File.txt → Absolute path: \\Vol1\SomeDirectory\File.txt
Relative path: .\File.txt → Absolute path: \\Vol1\File.txt
Absolute path:\\Vol1\SomeDirectory\.\.\File.txt → Absolute path: \\Vol1\File.txt
If the path is at the list of volumes (“\\”) then “.” will be ignored, also if it happens before the end of the
path. Consider this absolute path:
\\Vol1\SomeDirectory\.\.\.\.\.\File.txt
After the first two “.” the path is “\\”, therefore the next three “.” are ignored, and the final path
becomes:
\\File.txt
If the current directory is the volume list or the volume of the current directory is no longer available,
and the client changes the current directory to "\", then the current directory shall be set to the root of
the primary volume.
If there are no volumes, and the client changes the current directory to "\", then the file server shall
return Error Code 10 "Media not present" , because the primary volume is not present.
The “~” character (tilde) may be used as a placeholder for the manufacturer-specific directory of a
client. This character shall only be specified at the beginning of a path or after a volume name and shall
be replaced by the FS with the manufacturer-specific directory name on the current volume. If there is
no current volume, then the server primary volume shall be used.
The “~” may be used anywhere in a name, and shall only be interpreted as the manufacturer-specific
directory in the following two cases:
— ~\
— \\VolumeName\~\
In the following EXAMPLES the ‘ ~ ‘ shall be interpreted as name:
— .\~\ (adresses the directory with the name '~' in the current directory)
— ~name (adresses the file with the name '~name' in the current directory)
— \\VolumeName\Folder\~
(adresses the file with the name '~' in the directory 'Folder')
— \~\ (adresses the directory with the name '~' in the root directory of the current volume)
— \\~\ (adresses the Volume with name '~')
This rule enables to handle folders and files with the name ‘~’ created outside of the file server on a
removable media.
LongFolderName ::= [ | | ] {1}
LongPathName ::= [
[ ] |
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} ] |
[ [ ] {0,1} + [ + ] {0,n} ] |
[ [ + ] {0,1} + [ +
] {0,n} ]
] {1}
Notice that a path always ends with a . Annex E describes the reason for this.
EXAMPLE 1 Path relative to current directory:
.\
..\path\
..\Long path name\
Path\
Level1\Level2\
Path.dir\
Long path name\
EXAMPLE 2 Path relative to root of current volume:
\Path\
\Level1\Level2\
\Path.dir\
\Long path name\ Path including volume:
\\VOL_B\path\
\\VOL_B\Level1\Level2\
\\Flash Volume\Long path name\ (specifically a LongName)
EXAMPLE 3 Path using manufacturer-specific folder indicator:
~\
~\Path\
~\Level1\Level2\
\\VOL_B\~\path\
\\VOL_B\~\Level1\Level2\
A.2.3.2 Path and filename
This path name includes as much path information as needed to produce an unambiguous specification
of the path to the file:
LongPathAndFileName ::= [
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} + [
] ] |
[ [ ] {0,1} + [ + ] {0,n} + [
] ] |
[ [ + ] {0,1} + [ +
] {0,n} + [ ] ]
] {1}
EXAMPLE 1 Path relative to current directory:
Test.txt
path\Test.txt
Long path name\Test Filename.long.name
EXAMPLE 2 Path relative to root of current volume:
\path\Test
~\path\Test
~\Level1\Level2\Test
EXAMPLE 3 Path including volume:
\\VOL_B\path\Test
\\VOL_B\~\path\Test
\\VOL_B\path\Test.txt
\\VOL_B\Level1\Level2\Test
\\Flash Volume\Long path name\Test Filename.long.name
A.2.3.3 Search definitions
The wildcards “*” and “?” may be used:
— “*” is a wildcard for 0 or more characters of a filename or folder name;
— “?” is a wildcard for a single character in a filename or folder name.
Wildcards shall only be used for directory listings, and only after the last path separator.
LongPathAndWildCardName ::= [
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} +
] |
[ [ ] {0,1} + [ + ] {0,n} +
] |
[ [ + ] {0,1} + [ +
] {0,n} + ]
] {1}
EXAMPLE 1 Path relative to current directory:
*
?ath
?a*
~\*
~\?ath
EXAMPLE 2 Path relative to root of current volume:
\*
\?ath
~\path\*
EXAMPLE 3 Path including volume:
\\VOL_B\*
\\VOL_B\?ath
\\VOL_B\path\Test*
\\VOL_B\path\Test*.txt
\\VOL_B\Level1\Level2\Test.*
\\VOL_B\Level1\Level2\T?st.txt
\\Flash Volume\Long path name\Test ???? Name.long.name
\\Flash Volume\Long path name\Test * Name.*.name
\\Flash Volume\Long path name\T?st Filename.long.name
Annex B
(normative)
Parameter definitions
B.1 Command groups
File server commands are divided into groups; four bits specify the group of the commands.
Data length: 4 bit
Value Meaning
0000 Connection management
0001 Directory handling
0010 File access
0011 File handling
0100 Volume handling
0101.1111 Reserved
B.2 Command functions
Each FS command group has a number of functions. The lower four bits of a command byte specify the
function of the command.
Data length: 4 bit
Value Meaning
0 … F Defined in each command message
16 16
B.3 File Server Status
The current status of the FS.
Data length: 1 byte
Bit Value Meaning
7 … 2 000000 Reserved, send as 000000
1 1 Busy writing
0 1 Busy reading
B.4 Number of Open Files
The number of files that are currently open at the FS.
Data length: 1 byte
Resolution: 1 bit
Data Range: 0 … 255 (unsigned 8 bit)
10 10
B.5 Version Number
This indicates the edition of ISO 11783-13 with which the FS server or client conforms with.
The version number parameter reported by the client shall reflect the edition of the International
Standard (i.e. ISO 11783-13) to which the client is designed. It shall not change at runtime due to
adaptations to different file servers. For example, a Version 3 client would still report Version 3
behaviour in this parameter, even if the client falls back to Version 2 behaviour to communicate to a
Version 2 file server. The FS may choose to report this or provide it for diagnostics, but shall not reject
communication or the request based on the reported Version Number.
Data length: 1 byte
Value Meaning
0 Draft edition of the International Standard
1 Final draft edition of the International Standard
2 First published edition of the International Standard
3 Second published edition of the International Standard
4 Third published edition of the International Standard
5 … 254 Reserved
10 10
255 Compliant with Version 2 and prior (client only)
B.6 Maximum Number of Simultaneously Open Files
The maximum number of files that can be opened simultaneously at the FS.
Data length: 1 byte
Resolution: 1 bit
Data Range: 2 … 255 (unsigned 8 bit)
10 10
B.7 File Server Capabilities
Data length: 1 byte
Bit Value Meaning
7 … 2 000000 Reserved, send as 000000.
1 1 File server supports removable volumes.
0 1 File server supports multiple volumes.
B.8 Transaction Number
A number (TAN) assigned to a request so that the corresponding response can be identified.
Data length: 1 byte
Resolution: 1 bit
Data Range: 0 to 255
B.9 Error Code
Error codes defined here, are valid for all commands, they are referenced in.
If a response contains an error code other than 0 (Success) or 45 (File pointer at end of file), all other
data beside the Command and TAN in the response shall be disregarded, unless it is otherwise specified.
Data length: 1 byte
Value Meaning Possible reason
0 Success.
1 Access denied. Client tries to access a path including a
manufacturer-specific folder, which doesn’t
match the client’s manufacturer code.
File server has no access to a given path.
The given handle is not assigned to the
requester.
In general, if the file server has no access
rights to a given path.
2 Invalid access. In all cases where the path shall point to a
directory, but the existing item is a file, or
vice versa.
3 Too many files open. Maximum number of handles that can be
managed by the file server is reached. No
new handles can be generated. Numbers
reported by status message.
4 File, path or volume not found. The specified path is not found on the given
volume (maybe folder or file was deleted
before), or the specified volume is unknown
to the system.
5 Invalid Handle. The command request includes a client
handle, which is not known at all to the
file server.
6 Invalid given source name. The given source folder or file name doesn’t
fulfil the naming requirements defined in
A.2. Or is longer than what the OS can handle.
Or doesn’t fulfil the file system limitations.
7 Invalid given destination name. The given destination folder or file name
doesn’t fulfil the naming requirements de-
fined in A.2. Or is longer than what the OS
can handle. Or doesn’t fulfil the file system
limitations.
8 Volume out of free space
9 Failure during a write operation An error in the file system occurs.
10 Media is not present. The media referenced by the given volume
name, is no longer present.
For example, the removable media was re-
moved, but the volume name is still provided
within in the volume list.
11 Failure during a read operation. An error in the file system occurs.
12 Function not supported. Is reported by the file server for all func-
tions, which are not provided by the file
server, and which are marked optional in
this document.
13 Volume is possibly not initialized.Volume is physically available but cannot
be used by the file server (e.g. no supported
File System, or not mounted, or no access).
14 … 41 Reserved.
10 10
42 Invalid request length The file pointer hits the start of the file.
On invalid space request of the volume.
43 Out of memory. file server is out of resources and cannot
complete request, e.g. no memory to store
request or response data.
44 Any other error
45 File pointer at end of file.
46 TAN Error Same TAN, but different request compared to
the previous one (change in content or size).
47 Malformed Request. Message is shorter than expected. If the
message is too short to provide a TAN (less
than 2 data bytes), the TAN shall be set to
0xFF in the response message.
48 … 255 Reserved.
10 10
B.10 Handle
The data object assigned by the FS and used by the FS and client to reference a file or directory for
requested actions.
Data length: 1 byte
Value Meaning
0 … 254 Value of the Handle assigned by the FS for further access to a file
10 10
255 Error when assigning a Handle for a file
B.11 Space
Indication of, e.g., total or free volume space.
Data length: 4 bytes
Resolution: 512
...
NORME ISO
INTERNATIONALE 11783-13
Troisième édition
2022-05
Tracteurs et matériels agricoles et
forestiers — Réseaux de commande
et de communication de données en
série —
Partie 13:
Serveur de fichiers
Tractors and machinery for agriculture and forestry — Serial control
and communications data network —
Part 13: File server
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 .iv
Introduction .v
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 1
4 Exigences . 2
4.1 Format général des messages. 2
4.2 Format des données de fichier . . 3
4.2.1 Données . 3
4.2.2 Groupes de bits . 3
4.2.3 Nombre entier . 3
4.2.4 Chaîne de caractères . 3
4.3 Commande de transmission de données . 3
4.3.1 Généralités . 3
4.3.2 Stratégie . 3
4.3.3 Temporisation . 4
4.4 Horodatage. 4
4.5 Prise en charge de clients multiples . 5
4.6 Indicateurs de fichiers . 5
4.7 Volumes . 5
4.8 Volume primaire . 6
4.9 Commandes . 7
4.10 Connexion/Déconnexion d'un client . 8
Annexe A (normative) Ensemble de caractères .10
Annexe B (normative) Définitions des paramètres .16
Annexe C (normative) Définitions des messages du serveur de fichiers .28
Annexe D (informative) Exemples de systèmes de fichiers communs .62
Annexe E (informative) Pourquoi les noms de chemin se terminent par une barre oblique .63
Bibliographie .64
iii
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a
été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir
www.iso.org/directives).
L'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.
Cette troisième édition annule et remplace la deuxième édition (ISO 11783-13:2011), qui a fait l'objet
d'une révision technique.
Les principales modifications sont les suivantes:
— suppression de la prise en charge des noms de chemin et de fichier courts au format 8.3;
— ajout de la prise en charge des caractères Unicode dans les noms de chemins et de fichiers;
— ajout de clarifications visant à améliorer l'implémentation et la testabilité du protocole de serveur
de fichiers.
Une liste de toutes les parties de la série ISO 11783 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www.iso.org/fr/members.html.
iv
Introduction
L'ISO 11783 spécifie un système de communication destiné aux matériels agricoles basé sur le protocole
1)
ISO 11898-2. Les documents SAE J1939 , sur lesquels certaines parties de l'ISO 11783 se fondent, ont
été élaborés conjointement pour une utilisation dans des applications de camions et de bus, ainsi que
pour des applications de construction et d'agriculture. Des documents communs ont été finalisés pour
permettre l'utilisation d'unités électroniques conformes aux spécifications SAE J1939 sur des matériels
agricoles et forestiers avec un minimum de modifications. Les informations d'ordre général concernant
l'ISO 11783 figurent dans le présent document.
L'objectif de l'ISO 11783 est de proposer un système ouvert pour les systèmes électroniques embarqués
interconnectés. Elle vise à permettre la communication entre unités de commande électroniques (UCE),
en proposant un système normalisé.
1) Society of Automotive Engineers, Warrendale, PA, États-Unis.
v
NORME INTERNATIONALE ISO 11783-13:2022(F)
Tracteurs et matériels agricoles et forestiers — Réseaux de
commande et de communication de données en série —
Partie 13:
Serveur de fichiers
1 Domaine d'application
L'ensemble de messages spécifié dans le présent document est conçu pour répondre aux besoins des
tracteurs et des outils en utilisant les services d'un serveur de fichiers (SF).
Un SF est une fonction de commande (FC) distincte du système de commande de l'outil mobile qui
permet à toutes les FC de stocker ou d'extraire des données d'un dispositif de stockage basé sur des
fichiers.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 11783-1, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 1: Système normalisé général pour les communications de données avec les
équipements mobiles
ISO 11783-3, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 3: Couche liaison de données
ISO 11783-5, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 5: Gestion du réseau
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO 11783-1 ainsi que les
suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
client
fonction de commande (FC) installée sur le bus de l'outil mobile et qui utilise les services du serveur de
fichiers (3.5)
3.2
répertoire
fichier qui stocke des informations administratives concernant d'autres fichiers (3.3)
3.3
fichier
objet de données qui stocke des données sur un dispositif de stockage
3.4
attribut de fichier
information codée en bits qui définit le type et les caractéristiques d'un fichier (3.3)
3.5
serveur de fichiers
SF
fonction de commande (FC) installée sur le bus de l'outil mobile qui assure le stockage des fichiers (3.3)
et qui utilise un ensemble de commandes pour la prise en charge et l'accès aux fichiers considérés
3.6
nom de fichier
nom, conforme aux exigences d'un ensemble de caractères, qui identifie un fichier ou un répertoire (3.2)
Note 1 à l'article: Voir l'Annexe A concernant l'ensemble de caractères.
3.7
indicateur
objet de données utilisé pour accéder aux fichiers (3.3) et aux répertoires (3.2)
3.8
attribut «caché»
attribut de fichier (3.4) qui indique que le fichier ne doit pas apparaître dans une liste de répertoire
Note 1 à l'article: Un client (3.1) établit cet attribut au moyen des commandes du serveur de fichiers (SF).
3.9
chemin
spécification d'un nom de fichier (3.6) qui peut également comprendre le nom du répertoire
3.10
attribut «lecture seule»
attribut de fichier (3.4) utilisé pour éviter toute écriture sur un fichier ou sa suppression
Note 1 à l'article: Un client (3.1) établit cet attribut au moyen des commandes du serveur de fichiers (SF).
3.11
volume
répertoire (3.2) qui fait référence à une unité ou à un espace de stockage logique ou physique spécifique
Note 1 à l'article: Le volume primaire est celui utilisé comme volume courant au démarrage du serveur de fichiers
(SF).
4 Exigences
4.1 Format général des messages
Le format général des messages utilise le numéro de groupe de paramètres comme étiquette pour un
groupe de paramètres conformément à l'Annexe C. Chacun des paramètres du groupe peut être exprimé
sous forme de caractères, sous forme de données à l'échelle définies par les plages données en 4.2, ou
sous forme d'états de fonction se composant d'un ou de plusieurs bits. Les caractères doivent être
transmis en commençant par le caractère le plus à gauche. Les paramètres numériques se composant
de 2 octets de données ou plus doivent être transmis en commençant par l'octet de poids faible (LSB).
Les paramètres individuels doivent être conformes à l'Annexe B. Lorsque les messages de longueur
variable ont 8 octets de données ou moins, ils doivent être transmis dans une trame CAN (controller
area network) simple. Lorsque les messages de longueur variable ont 9 octets de données ou plus, le
protocole de transport (TP) ou le protocole de transport étendu (ETP), conformément à l'ISO 11783-3,
est exigé. Lorsqu'un message a moins de 8 octets de données, les octets non utilisés doivent être remplis
avec les valeurs FF .
4.2 Format des données de fichier
4.2.1 Données
Les données sont composées d'un bloc d'octets (entier non signé de 8 bits). Toutes les valeurs comprises
dans la plage de 0 … 255 sont autorisées. Il n'y a pas de prise en charge spéciale des caractères
10 10
individuels (caractères de commande, marqueurs de fin de ligne, marqueurs de fin de fichier ou
caractères similaires).
4.2.2 Groupes de bits
Les groupes de 1 bit à 8 bits sont mis en paquet d'un octet comme bit 7 … bit 0. Les groupes de 9 bits à
16 bits sont mis en paquet de deux octets, le premier étant un octet de poids faible (LSB, least significant
byte), comme bit 7 … bit 0, suivi de l'octet de poids fort (MSB, most significant byte), comme bit 15 …
bit 8. Les bits non utilisés dans un groupe de bits ont par défaut une valeur de 0 (zéro).
4.2.3 Nombre entier
Les valeurs entières sont formatées comme suit:
Entier non signé 1 octet 0 … 2 −1 0 … 255
10 10
de 8 bits
Entier non signé 2 octets, LSB en premier 0 … 2 −1 0 … 65535
10 10
de 16 bits
Entier non signé 4 octets, LSB en premier 0 … 2 −1 0 … 4294967295
10 10
de 32 bits
31 31
Entier signé de 4 octets, LSB en premier, −2 … 2 −1 −2147483648 …
32 bits complément à deux +2147483647
4.2.4 Chaîne de caractères
Une chaîne contient des caractères représentés par un ou plusieurs octets (entier non signé de 8 bits).
La longueur d'une chaîne est spécifiée par un élément de données de longueur de chaîne. Les caractères
autorisés dans une chaîne utilisée comme nom de fichier ou nom de chemin doivent être comme spécifié
dans l'Annexe A. La prise en charge des caractères Unicode est ajoutée dans la version 4 du serveur de
fichiers, voir B.5 Numéro de version. Avant la version 4, un caractère est dénoté par un seul octet.
4.3 Commande de transmission de données
4.3.1 Généralités
Chaque transaction de communication entre un client et le SF est initiée par une demande du client
et se termine par une réponse du SF. Pour assurer une communication en sécurité intrinsèque, il est
important que le client attribue la réponse reçue à une demande correspondante et répète une demande
erronée sans déclencher de nouveau l'exécution de la transaction complète.
4.3.2 Stratégie
Le client peut émettre une demande et ne pas recevoir de réponse du fait de perturbations transitoires
de communication. La défaillance peut survenir soit lors de l'envoi du message de demande, c'est-à-dire
que le SF ne reçoit pas la demande, ou lors du retour du message de réponse, c'est-à-dire que le client
ne reçoit pas la réponse. Le client ne peut différencier ces deux cas et doit renvoyer la demande pour
obtenir les données demandées.
En l'absence de stratégie de transaction, le cas du SF ne recevant pas la demande est résolu par
la transmission par le client d'une seconde demande et par la réponse du SF contenant les données
demandées. Cependant, si le client ne reçoit pas le message de données de réponse correct et transmet
une seconde demande, le SF transmet alors les données suivantes à partir du fichier, car une demande
de données passe automatiquement aux données suivantes dans le fichier.
Il est par conséquent nécessaire d'appliquer une stratégie de transaction pour éviter les erreurs décrites
ci-dessus. Chaque client sur le réseau conserve son propre compteur de numéros de transaction (TAN,
transaction number); il convient qu'il commence à 0 après un cycle d'alimentation.
Chaque client génère un TAN pour chaque demande qu'il transmet au SF. Chaque numéro TAN doit être
différent du précédent. Cela peut être réalisé en incrémentant le dernier numéro TAN utilisé pour la
demande suivante. Le client est chargé de vérifier qu'une réponse reçue contient le même TAN que
celui qui a été utilisé dans la demande au cours de la session de communication, permettant ainsi de
s'assurer qu'il n'y a aucune perte de commandes. Le SF doit mémoriser la dernière commande traitée
et le message de réponse transmis pour chaque client. Le SF compare chaque nouvelle demande à la
précédente demande transmise par le même client. Si le numéro TAN n'est pas le même, la demande
est mise en œuvre et la réponse est envoyée. Si le numéro TAN est le même que celui de la demande
précédemment reçue, la demande n'est pas mise en œuvre et la réponse précédente est envoyée. Ainsi,
si le client transmet une seconde demande lorsque le SF n'a jamais reçu la première, le SF reçoit le
numéro TAN pour la première fois et met en œuvre la demande en envoyant la réponse de données
correcte. Si le SF reçoit une demande ayant le même numéro TAN que celui de la demande déjà reçue, il
ne met pas en œuvre la demande, mais retransmet la réponse précédente.
4.3.3 Temporisation
Le temps d'exécution de toutes les commandes du SF (le temps écoulé entre une demande et une
réponse) est compris dans des limites raisonnables. Le client doit surveiller le temps d'attente d'une
réponse.
Les temporisations spécifiées dans l'ISO 11783-3 pour le protocole de transport et pour le protocole de
transport étendu doivent être satisfaites pour l'exécution des commandes.
Si une temporisation est écoulée, la demande est supposée avoir échoué et le client doit réitérer la
demande en utilisant le même numéro TAN.
Si une réponse à une demande dure plus de 200 ms après réalisation de la demande, le SF doit
transmettre le message d'état pour indiquer l'état occupé au client. Cela assure une temporisation de
demande de 600 ms si le message d'état du SF n'indique pas un état occupé.
4.4 Horodatage
2)
Plusieurs commandes du SF nécessitent un horodatage de fichier. Le temps UTC est utilisé à cet effet.
Le SF peut mettre en œuvre la prise en charge en temps réel soit en maintenant ses propres informations
en temps réel, soit en demandant les informations d'horodatage au moyen du groupe de paramètres
Heure/Date spécifié dans l'ISO 11783-7.
Si un client demande l'horodatage pour la racine d'un volume ou la liste de volumes elle-même, la
réponse du serveur de fichiers doit contenir l'erreur «Accès refusé».
Le serveur de fichiers doit renvoyer en réponse la dernière heure d'accès au répertoire/fichier, si le
système d'exploitation fournit cette information. Sinon, le serveur de fichiers doit répondre avec les
informations disponibles.
2) Temps universel coordonné (UTC, universal time coordinated) ou temps universel, initialement connu sous
l'appellation temps moyen de Greenwich (GMT).
En raison des possibilités de modification de l'horodatage (par l'opérateur ou par d'autres moyens), il n'y
a aucune garantie que l'horodatage associé à des fichiers et répertoires indique l'ordre chronologique
réel d'accès aux fichiers/répertoires.
4.5 Prise en charge de clients multiples
Le serveur de fichiers doit prendre en charge plusieurs clients. Lorsque plusieurs clients sont connectés
simultanément, le serveur de fichiers doit fonctionner avec chaque client comme s'il n'y en avait qu'un
seul sur le réseau. Aucune interférence ne doit se produire entre les commandes gérées pour différents
clients.
Le serveur de fichiers doit accepter les connexions de tous les clients sur le réseau. Si le serveur de
fichiers dispose de ressources limitées, il peut restreindre les indicateurs de nombre de fichiers ouverts.
Avant la version 4 du serveur de fichiers, l'exigence relative à la prise en charge de toutes les connexions
n'était pas clairement définie.
Lorsqu'un client se connecte, le serveur de fichiers initie le répertoire courant du client concerné
comme répertoire racine du volume primaire du système de fichiers du serveur de fichiers. En l'absence
de volumes, le répertoire courant est alors réglé sur la liste de volumes «\\». Il est demandé au client
d'utiliser les commandes de Modification de répertoire courant ou d'Ouverture de fichier pour accéder
aux fichiers qui lui sont spécifiques. Lorsque plusieurs clients demandent l'accès à des fichiers communs,
ils doivent synchroniser leur répertoire et les règles d'affectation des noms de fichiers pour avoir accès
à ces fichiers communs. Pour éviter tout accès accidentel aux fichiers propriétaires du fabricant, un
nom de répertoire réservé est spécifié. Les règles d'affectation des noms du répertoire spécifique au
fabricant sont:
MCMC0000
où 0000 représente le code du fabricant à 4 chiffres (définit conformément à l'ISO 11783-5 et énuméré
dans l'ISO 11783-1), à notation décimale et commençant par des zéros. Les clients ne doivent pas utiliser
ce nom de répertoire du code du fabricant avec un code du fabricant différent de celui figurant dans leur
champ NOM. Lorsque le client tente d'ouvrir un fichier dans un répertoire spécifique au fabricant et que
le code du fabricant dans le champ NOM du client ne correspond pas au nom de répertoire spécifique au
fabricant, le SF doit refuser l'accès et renvoyer un code d'erreur «accès refusé».
La plage de valeurs complète allant de 0000 à 9999 doit être traitée en tant que code du fabricant, bien
que le code du fabricant défini dans l'ISO 11783-5 corresponde à une valeur à 11 bits, ce qui limite la
plage de valeurs possible à une plage comprise entre 0 et 2047.
Lorsqu'un serveur de fichiers prend en charge plusieurs volumes, des répertoires spécifiques au
fabricant peuvent être créés sur chaque volume. Le client est responsable de la création d'un répertoire
spécifique au fabricant. Le répertoire spécifique au fabricant ne doit être placé qu'à la racine de chaque
volume. Un répertoire qui se trouve dans un sous-répertoire et qui utilise la même convention de
dénomination (MCMC0000) doit être traité comme n'importe quel autre répertoire, c'est-à-dire qu'il
n'est pas spécifique au fabricant.
4.6 Indicateurs de fichiers
Un SF peut prendre en charge plusieurs indicateurs de fichiers. Bon nombre des commandes disponibles
pour le SF créent et/ou utilisent des indicateurs de fichiers. Cependant, certaines commandes n'utilisent
que des noms de répertoire ou de fichier. En interne, si le SF crée un indicateur de fichiers pour gérer
ces commandes, le nombre de fichiers ouverts doit être incrémenté pour refléter l'état interne du SF.
4.7 Volumes
Différents types de mémoire (mémoire Flash, support amovible, lecteurs de disque renforcés, etc.)
peuvent être attribués à différents volumes.
Un SF peut prendre en charge plusieurs volumes. Il est également possible qu'un SF ne répertorie aucun
volume — par exemple avec un support non initialisé ou en l'absence de dispositif.
La racine d'un support amovible correspond à la racine du volume fourni par le serveur de fichiers
aux clients. Dans le cas de volumes non amovibles, tels qu'une mémoire d'un module d'affichage, un
répertoire situé sur ce volume peut correspondre à la racine du volume fourni aux clients afin de
protéger les zones critiques de la mémoire en question.
La liste de volumes, spécifiée avec «\\», est la couche supérieure (ou base) d'une structure de répertoire.
L'exécution d'une commande de modification de répertoire courant en utilisant «.\» à la racine d'un
volume a pour effet de définir le répertoire courant sur la liste des volumes. L'exécution de la commande
à partir de la liste des volumes proprement dite conserve le répertoire courant dans la liste des volumes.
Si le répertoire courant correspond à la liste des volumes, le client peut utiliser des chemins relatifs
commençant par le nom de volume.
EXEMPLE Le chemin relatif Vol1\ donne le chemin absolu \\Vol1 si \\ est le répertoire courant.
Il est recommandé d'utiliser uniquement des supports utilisant un système de fichiers qui prend en
charge des noms de fichier longs. Le comportement avec d'autres systèmes de fichiers n'est pas défini et
un comportement inattendu peut se produire lorsque ces volumes basculent entre différents systèmes
de serveur de fichiers.
Les noms des volumes sont déterminés par le SF, cependant le fabricant d'un SF peut permettre à un
outil de service propriétaire de nommer les volumes en utilisant le message de demande d'initialisation
de volume (voir C.5.2.2).
NOTE Le présent document ne spécifie pas la manière dont l'outil de service sélectionne les mémoires ou les
volumes à initialiser lorsqu'ils ne sont pas nommés ni répertoriés dans la liste de volumes «\\».
4.8 Volume primaire
Le volume primaire doit être un support amovible. Si aucun volume primaire n'est disponible quand
un client se connecte au serveur de fichiers, la Réponse d'obtention de répertoire courant doit signaler
un chemin vide et un code d'erreur 4. Toutes les opérations de fichier avec un chemin relatif doivent
retourner un code d'erreur 4. Lorsqu'un support amovible est disponible et si le répertoire courant est
toujours une chaîne vide, le volume primaire est défini sur ce support amovible et le répertoire courant
pointe automatiquement à la racine du support amovible.
Les serveurs doivent utiliser des volumes amovibles comme volume primaire pour être compatibles
avec les clients existants qui attendent que le volume primaire soit un support amovible.
Il convient que les clients lisent systématiquement la liste des volumes et qu'ils choisissent un volume
adapté à leur tâche.
Voir Figure 1.
Figure 1 — Choix du répertoire initial
4.9 Commandes
Pour faciliter l'identification des problèmes de communication, le SF doit répondre à toutes les
commandes propres à la destination.
Le SF doit répondre par un NACK (ISO 11783-3) lorsqu'il reçoit:
— des commandes non spécifiées;
— un message de demande vide (0 octet de données).
Le serveur de fichiers doit répondre avec un code d'erreur 47 Demande mal formée s'il reçoit un
message plus court que prévu.
4.10 Connexion/Déconnexion d'un client
Les clients doivent établir une connexion au serveur de fichiers en envoyant le message de maintenance
de la connexion client (CCM) (C.1.3). La connexion doit être établie avant que le client n'envoie au serveur
de fichiers un message contenant un numéro TAN. Le message CCM doit être répété à deux secondes
d'intervalles afin de maintenir la connexion.
NOTE Dans les versions 3 et antérieures, l'exigence relative à la CCM n'était pas clairement définie; ces
clients pourraient donc ne pas envoyer de message CCM dans les conditions spécifiées ci-dessus.
Le serveur de fichiers doit accepter qu'un client est connecté lorsque le serveur de fichiers reçoit le
message CCM ou n'importe quel message client à serveur contenant un numéro TAN. Passé un délai de
6 secondes sans recevoir de message CCM ou de message client à serveur contenant un numéro TAN, le
serveur de fichiers doit considérer le client comme déconnecté.
Lorsqu'un client est déconnecté, le serveur de fichiers doit fermer tous les fichiers qui sont ouverts
par le client déconnecté, auquel cas tous les indicateurs associés à ce client deviennent non valides. Le
répertoire courant du client doit être restauré aux paramètres par défaut.
Voir Figure 2.
Figure 2 — Connexion et déconnexion d'un client
Annexe A
(normative)
Ensemble de caractères
A.1 Caractères valides
Le SF utilise des noms de fichier (filename) et des noms de chemin (pathname). Chaque caractère utilisé
pour les noms de fichier et les noms de chemin est validé par le SF à l'aide des définitions de nom de
fichier et de chemin données en A.2. Seuls les caractères imprimables sont visibles lors de l'affichage du
«nom de fichier» ou du «nom de chemin» à un utilisateur.
La prise en charge des noms de fichier courts au format 8.3 a été supprimée dans la version 4 du serveur
de fichiers. Un serveur de fichiers mis en œuvre conformément à la version 4 doit prendre en charge les
noms de fichier et de chemin conformément aux définitions données en A.2.
A.2 Définition de nom de fichier et de chemin
A.2.1 Nomenclature
Définitions:
[ ] tout caractère de l'ensemble, y compris les caractères non visibles de l'ensemble (option);
[A-B] définit une plage complète (inclusive) du premier caractère au dernier;
( ) groupe;
< > classe de caractère;
\ caractère d'échappement du caractère suivant, comme dans «\[» qui indique un seul cro-
chet de gauche et non le confinement d'un ensemble;
A | B séquence «A» ou «B»;
A + B séquence de A suivie de celle de B;
{m} exactement m de l'ensemble précédent;
{m,n} de m jusqu'à et y compris n de l'ensemble précédent;
\xXX code de caractères en notation hexadécimale où XX sont les deux chiffres hexadécimaux
(par exemple: \x20 indique le code de caractères 32 qui correspond au caractère d'espa-
cement).
A.2.2 Définition de nom
A.2.2.1 Noms
Les noms ont une longueur comprise entre un octet et 255 octets, utilisant l'ensemble de caractères
donné ci-dessous. Les systèmes de fichiers communément utilisés, donnés dans l'Annexe D, ont été
utilisés pour déterminer les restrictions de nom qui permettraient d'utiliser ces noms avec une perte
minimale de caractères.
Noter que la longueur des noms est spécifiée en octets. Le nombre d'octets exigé pour un nom dépend
des caractères Unicode et de la méthode de codage Unicode utilisée dans ce nom.
Pour éviter toute incompatibilité entre différents systèmes d'exploitation, le client ne doit pas créer de
répertoires/fichiers dont les noms ne diffèrent que par la casse, et les noms ne doivent ni se terminer par
un «.» ni contenir les symboles «<», «>» ou «|» (ces derniers peuvent poser problème sur les systèmes de
fichiers FAT32).
LongNameChar ::= tout caractère simple défini par Unicode/ISO/IEC 10646, sauf 0x00 à 0x1F, 0x7F
à 0x9F, «\», «*», «?» et «/».
WildCardChar ::= [ *? ] {1}
ManufacturerSpecificDirectoryChar ::= [ ~ ] {1}
PathSeparatorChar ::= [ \\ ] {1}
VolumeListIndicator ::= [ \\ ] {2}
ParentFolderIndicator ::= [ . ] {2}
CurrentFolderIndicator ::= [ . ] {1}
MfgSpecificFolderIndicator ::= [ ] {1}
LongWildCardNameChar ::= [ | ] {1}
LongName ::= [ ] {1,254}
LongWildCardName ::= [ ] {1,254}
A.2.2.2 Noms de fichier
Les noms de fichier utilisent les noms définis en A.2.2.1.
LongFileName ::=
EXEMPLE Test, Test.txt, Test Filename.long.name (spécifiquement un LongName).
A.2.2.3 Volumes
Les volumes utilisent les noms définis en A.2.2.1.
NomVolume ::=
EXEMPLE VOL_B, volume Flash
A.2.3 Définitions de chemin
A.2.3.1 Généralités
Une définition de chemin est similaire à une définition de nom de fichier, mais comporte des définitions
de préfixe et des délimiteurs supplémentaires entre les segments du chemin.
Lorsqu'une liste de répertoire du chemin «\\» (deux barres obliques) est demandée, le SF doit renvoyer
une liste de volumes. Tous les serveurs de fichiers doivent prendre en charge le «\\» pour permettre
aux clients de demander les volumes (y compris les supports amovibles), même si le SF n'a qu'un seul
volume.
Les deux noms de répertoire spéciaux prédéfinis «.» et «.» font référence au répertoire courant («.») et
au répertoire parent («.»). Ces noms de répertoire prédéfinis ne doivent pas être pris en compte dans
une liste de répertoire, mais peuvent être utilisés dans un nom de chemin pour faire référence à un
répertoire courant ou parent.
S'ils sont utilisés dans un nom de chemin, le serveur de fichiers doit normaliser le chemin pour
supprimer «.» et «.» avant que le chemin ne soit vérifié ou utilisé par une quelconque commande.
EXEMPLE 1
Hypothèse: Le répertoire courant est \\Vol1\RépertoireQuelconque\
Chemin relatif: .\Fichier.txt → Chemin absolu: \\Vol1\RépertoireQuelconque\Fichier.txt
Chemin relatif: .\Fichier.txt → Chemin absolu: \\Vol1\Fichier.txt
Chemin absolu:\\Vol1\RépertoireQuelconque\.\.\Fichier.txt → Chemin absolu: \\Vol1\Fichier.txt
Si le chemin se trouve sur la liste de volumes («\\»), alors «.» est ignoré, même s'il se trouve avant la fin
du chemin. Soit l'exemple de chemin absolu ci-dessous:
\\Vol1\RépertoireQuelconque\.\.\.\.\.\Fichier.txt
Après les deux premiers «.», le chemin est «\\»; alors les trois occurrences suivantes de «.» sont donc
ignorées et le chemin final devient:
\\Fichier.txt
Si le répertoire courant est la liste de volumes ou si le volume du répertoire courant n'est plus disponible
et que le client modifie le répertoire courant pour le définir sur «\», le répertoire courant doit être défini
sur la racine du volume primaire.
En l'absence de volumes, et si le client définit le répertoire courant sur «\», le serveur de fichiers doit
retourner le code d'erreur 10 «Mémoire non présente», étant donné que le volume primaire n'est pas
présent.
Le caractère «~» (tilde) peut être utilisé comme un paramètre fictif pour le répertoire spécifique au
fabricant d'un client. Ce caractère ne doit être spécifié qu'au début d'un chemin ou après un nom de
volume et doit être remplacé par le SF par le nom du répertoire spécifique au fabricant sur le volume
courant. En l'absence de volume courant, le volume primaire du serveur doit être utilisé.
Le symbole «~» peut être utilisé n'importe où dans un nom et doit être interprété comme étant le
répertoire spécifique au fabricant uniquement dans les deux cas suivants:
— ~\
— \\NomVolume\~\
Dans les EXEMPLES suivants, le «~» doit être interprété en tant que nom:
— .\~\ (adresse le répertoire nommé «~» dans le répertoire courant)
— ~nom (adresse le fichier nommé «~nom» dans le répertoire courant)
— \\NomVolume\Répertoire\~
(adresse le fichier nommé «~nom» dans le répertoire «Répertoire»)
— \~\ (adresse le répertoire nommé «~» dans le répertoire racine du volume courant)
— \\~\ (adresse le volume nommé «~»)
Cette règle permet de prendre en charge les répertoires et fichiers nommés «~» qui ont été créés en
dehors du serveur de fichiers sur un support amovible.
LongFolderName ::= [ | | ] {1}
LongPathName ::= [
[ ] |
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} ] |
[ [ ] {0,1} + [ + ] {0,n} ] |
[ [ + ] {0,1} + [ +
] {0,n} ]
] {1}
On remarque qu'un chemin d'accès se termine toujours par un . L'Annexe E en
décrit la raison.
EXEMPLE 1 Chemin relatif au répertoire courant:
.\
..\path\
..\Long path name\
Path\
Level1\Level2\
Path.dir\
Long path name\
EXEMPLE 2 Chemin relatif à la racine du volume courant:
\Path\
\Level1\Level2\
\Path.dir\
\Long path name\ Chemin comprenant un volume:
\\VOL_B\path\
\\VOL_B\Level1\Level2\
\\Flash Volume\Long path name\ (spécifiquement un LongName)
EXEMPLE 3 Chemin utilisant un indicateur de répertoire spécifique au fabricant:
~\
~\Path\
~\Level1\Level2\
\\VOL_B\~\path\
\\VOL_B\~\Level1\Level2\
A.2.3.2 Chemin et nom de fichier
Ce nom de chemin comprend autant d'informations de chemin qu'il est nécessaire pour produire une
spécification non ambiguë du chemin d'accès au fichier:
LongPathAndFileName ::= [
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} + [
] ] |
[ [ ] {0,1} + [ + ] {0,n} +
[ ] ] |
[ [ + ] {0,1} + [ +
] {0,n} + [ ] ]
] {1}
EXEMPLE 1 Chemin relatif au répertoire courant:
Test.txt
path\Test.txt
Long path name\Test Filename.long.name
EXEMPLE 2 Chemin relatif à la racine du volume courant:
\path\Test
~\path\Test
~\Level1\Level2\Test
EXEMPLE 3 Chemin comprenant un volume:
\\VOL_B\path\Test
\\VOL_B\~\path\Test
\\VOL_B\path\Test.txt
\\VOL_B\Level1\Level2\Test
\\Flash Volume\Long path name\Test Filename.long.name
A.2.3.3 Définitions de recherche
Les caractères de remplacement «*» et «?» peuvent être utilisés:
— «*» est un caractère de remplacement utilisé pour représenter aucun ou plusieurs caractères d'un
nom de fichier ou d'un nom de répertoire;
— «?» est un caractère de remplacement utilisé pour un caractère simple dans un nom de fichier ou un
nom de répertoire.
Les caractères de remplacement ne doivent être utilisés que pour les listes de répertoires, et uniquement
après le dernier séparateur de chemin.
LongPathAndWildCardName ::= [
[ [ ] + + + [
+ ] {0,1} + [ + ] {0,n} +
] |
[ [ ] {0,1} + [ + ] {0,n} +
] |
[ [ + ] {0,1} + [ +
] {0,n} + ]
] {1}
EXEMPLE 1 Chemin relatif au répertoire courant:
*
?ath
?a*
~\*
~\?ath
EXEMPLE 2 Chemin relatif à la racine du volume courant:
\*
\?ath
~\path\*
EXEMPLE 3 Chemin comprenant un volume:
\\VOL_B\*
\\VOL_B\?ath
\\VOL_B\path\Test*
\\VOL_B\path\Test*.txt
\\VOL_B\Level1\Level2\Test.*
\\VOL_B\Level1\Level2\T?st.txt
\\Flash Volume\Long path name\Test???? Name.long.name
\\Flash Volume\Long path name\Test * Name.*.name
\\Flash Volume\Long path name\T?st Filename.long.name
Annexe B
(normative)
Définitions des paramètres
B.1 Groupes de commandes
Les commandes du SF sont divisées en groupes; un entier à 4 bits spécifie le groupe de commandes.
Longueur de données: 4 bits
Valeur Signification
0000 Gestion de la connexion
0001 Prise en charge du répertoire
0010 Accès au fichier
0011 Prise en charge de fichier
0100 Prise en charge du volume
0101.1111 Réservé
B.2 Fonctions de commandes
Chaque groupe de commandes du SF a un certain nombre de fonctions. L'entier inférieur de 4 bits d'un
octet de commande spécifie la fonction de la commande.
Longueur de données: 4 bits
Valeur Signification
0 … F Définie dans chaque message de commande
16 16
B.3 État du serveur de fichiers
L'état actuel du SF.
Longueur de données: 1 octet
Bit Valeur Signification
7 … 2 000000 Réservé, à envoyer comme 000000
1 1 Occupé en écriture
0 1 Occupé en lecture
B.4 Nombre de fichiers ouverts
Le nombre de fichiers actuellement ouverts au niveau du SF.
Longueur de données: 1 octet
Résolution: 1 bit
Plage de données: 0 … 255 (entier non signé de 8 bits)
10 10
B.5 Numéro de version
Il indique l'édition de l'ISO 11783-13 à laquelle se conforme le serveur SF ou le client.
Le paramètre de numéro de version indiqué par le client doit refléter l'édition de la Norme internationale
(c'est-à-dire l'ISO 11783-13) à laquelle le client est destiné. Il ne doit pas changer en cours d'exécution
du fait d'adaptat
...
2022-03
ISO 11783--13:2022(EF)
Third edition
Troisième édition
ISO/TC 23/SC 19
Secretariat2022-05-10
Secrétariat: DIN
Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 13: File server
Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de
communication de données en série — Partie 13: Serveur de fichiers
Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 13: File server
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-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: copyright@iso.org
Email: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland.
ii © ISO 2022 – All rights reserved
ContentsSommaire Page
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 2
5 Requirements . 2
5.1 General message format . 2
5.2 File data format . 3
5.2.1 Data . 3
5.2.2 Bit groups . 3
5.2.3 Integer . 3
5.2.4 Character string . 3
5.3 Data transmission control . 3
5.3.1 General . 3
5.3.2 Strategy . 3
5.3.3 Timeout . 4
5.4 Date and time support . 4
5.5 Multi-client support . 4
5.6 File Handles . 5
5.7 Volumes . 5
5.8 Primary volume . 6
5.9 Commands . 7
5.10 Connection/Disconnection of a client . 8
Annex A (normative) Character set . 10
Annex B (normative) Parameter definitions . 17
Annex C (normative) File server message definitions . 28
Annex D (informative) Common file system examples . 58
Annex E (informative) Why path names must end with a backslash . 59
iv © ISO 2022 – All rights reserved
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
Avant-propos . iv
Introduction . v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Exigences . 4
4.1 Format général des messages . 4
4.2 Format des données de fichier . 4
4.2.1 Données . 4
4.2.2 Groupes de bits . 5
4.2.3 Nombre entier . 5
4.2.4 Chaîne de caractères . 5
4.3 Commande de transmission de données . 5
4.3.1 Généralités . 6
4.3.2 Stratégie . 6
4.3.3 Temporisation . 7
4.4 Horodatage . 8
4.5 Prise en charge de clients multiples . 8
4.6 Indicateurs de fichiers . 10
4.7 Volumes . 10
4.8 Volume primaire . 11
4.9 Commandes . 13
4.10 Connexion/Déconnexion d'un client . 14
Annexe A (normative) Ensemble de caractères . 17
Annexe B (normative) Définitions des paramètres . 26
Annexe C (normative) Définitions des messages du serveur de fichiers . 44
Annexe D (informative) Exemples de systèmes de fichiers communs . 102
Annexe E (informative) Pourquoi les noms de chemin se terminent par une barre oblique
............................................................................................................................................................ 104
Bibliographie . 107
vi © ISO 2022 – All rights reserved
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 was prepared by Technical Committeea été élaboré par le comité technique
ISO/TC 23, Tractors and machinery forTracteurs et matériels agricoles et forestiers, sous-comité SC 19,
Électronique en agriculture and forestry, Subcommittee SC 19, Agricultural electronics.
This third edition cancels and replaces the second editionCette troisième édition annule et remplace la
deuxième édition (ISO 11783-13:2011), which has been technically revisedqui a fait l'objet d'une révision
technique.
The main changes are as follows:
— removal of support for short, 8.3 format, path and file names;
— addition of support for Unicode characters in path and file names;
— addition of clarifications to improve the implementation and testability of the file server protocol.
A list of all parts in the ISO 11783 series can be found on the ISO website.
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.
Les principales modifications sont les suivantes:
— suppression de la prise en charge des noms de chemin et de fichier courts au format 8.3;
— ajout de la prise en charge des caractères Unicode dans les noms de chemins et de fichiers;
— ajout de clarifications visant à améliorer l'implémentation et la testabilité du protocole de serveur de
fichiers.
Une liste de toutes les parties de la série ISO 11783 se trouve sur le site web de l’ISO.
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.
viii © ISO 2022 – All rights reserved
Introduction
ISOL'ISO 11783 specifies a communications system for agricultural equipment based on thespécifie un
système de communication destiné aux matériels agricoles basé sur le protocole ISO 11898-2 protocol.
1 2
SAE J1939Les documents , on which parts of ISO SAE J1939 , sur lesquels certaines parties de
l'ISO 11783 are based, were developed jointly for use in truck and busse fondent, ont été élaborés
conjointement pour une utilisation dans des applications and forde camions et de bus, ainsi que pour des
applications de construction and agriculture applications. Jointet d'agriculture. Des documents were
completed to allow electronic units that meet the truck and buscommuns ont été finalisés pour permettre
l'utilisation d'unités électroniques conformes aux spécifications SAE J1939 specifications to be used by
agricultural and forestry equipment with minimal changes. General information on ISO sur des matériels
agricoles et forestiers avec un minimum de modifications. Les informations d'ordre général concernant
l'ISO 11783 can be found in thisfigurent dans le présent document.
The purpose of ISO 11783 is to provide an open, interconnected system for on-board electronic systems.
It is intended to enable electronic control units (ECUs) to communicate with each other, providing a
standardized system.
Society of Automotive Engineers, Warrendale, PA, USA.
Society of Automotive Engineers, Warrendale, PA, États-Unis.
Tractors and machinery for agriculture and forestry — Serial control and communications data
network — L'objectif de l'ISO 11783 est de proposer un système ouvert pour les systèmes électroniques
embarqués interconnectés. Elle vise à permettre la communication entre unités de commande
électroniques (UCE), en proposant un système normalisé.
x © ISO 2022 – All rights reservedTous droits réservés
INTERNATIONAL STANDARDNORME ISO 11783-13:2022(EF)
INTERNATIONALE
Tracteurs et matériels agricoles et forestiers — Réseaux de
commande et de communication de données en série —
Part 13: File serverPartie 13: Serveur de fichiers
1 Scope
The message set specified in this document is designed to support the needs of tractors and implements
in using the services of a file server (FS).
An FS is a distinct control function (CF) on the mobile implement control system that enables all CFs to
store or retrieve data from a file-based storage device.
4 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 11783-1, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 1: General standard for mobile data communication
ISO 11783-3, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 3: Data link layer
ISO 11783-5, Tractors and machinery for agriculture and forestry — Serial control and communications
data network — Part 5: Network management
6 Terms and definitions
1 For the purposes of thisDomaine d'application
L'ensemble de messages spécifié dans le présent document est conçu pour répondre aux besoins des
tracteurs et des outils en utilisant les services d'un serveur de fichiers (SF).
Un SF est une fonction de commande (FC) distincte du système de commande de l'outil mobile qui permet
à toutes les FC de stocker ou d'extraire des données d'un dispositif de stockage basé sur des fichiers.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 11783-1, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 1: Système normalisé général pour les communications de données avec les
équipements mobiles
ISO 11783-3, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 3: Couche liaison de données
ISO 11783-5, Tracteurs et matériels agricoles et forestiers — Réseaux de commande et de communication
de données en série — Partie 5: Gestion du réseau
3 Termes et définitions
Pour les besoins du présent document, the terms and definitions given in ISOles termes et les définitions
de l'ISO 11783--1 and the following applyainsi que les suivants s’appliquent.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
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: available atdisponible à l’adresse
https://www.iso.org/obphttps://www.iso.org/obp
— IEC Electropedia: available atdisponible à l’adresse
https://www.electropedia.org/https://www.electropedia.org/
3.1
client
control function (CF) on thefonction de commande (FC) installée sur le bus de l'outil mobile implement
bus that uses theet qui utilise les services of the file serverdu serveur de fichiers (3.5)
3.2
directory
file which stores administrative information about other files (3.3)
répertoire
fichier qui stocke des informations administratives concernant d'autres fichiers (3.3)
3.3
file
data object that stores data on a storage device
fichier
objet de données qui stocke des données sur un dispositif de stockage
3.4
file attribute
bit-coded attribut de fichier
information that defines thecodée en bits qui définit le type and features of a fileet les caractéristiques
d'un fichier (3.3)
3.5
file server
FS
control function (CF) on the mobile implement bus that provides storage for files (3.3) and uses a set of
commands for the handling of, and access to, these files
serveur de fichiers
2 © ISO 2022 – All rights reservedTous droits réservés
SF
fonction de commande (FC) installée sur le bus de l'outil mobile qui assure le stockage des fichiers (3.3)
et qui utilise un ensemble de commandes pour la prise en charge et l'accès aux fichiers considérés
3.6
filename
name conforming to requirements of a character set, which identifies a file or directory (3.2)
nom de fichier
nom, conforme aux exigences d'un ensemble de caractères, qui identifie un fichier ou un répertoire (3.2)
Note 1 to entry: See Annexà l'article: Voir l'Annexe A for the character setconcernant l'ensemble de caractères.
3.7
Handle
data object used for accessing filesindicateur
objet de données utilisé pour accéder aux fichiers (3.3) and directorieset aux répertoires (3.2)
3.8
hidden attribute
file attribute (3.4) indicating that the file should not appear in a directory listing
attribut «caché»
attribut de fichier (3.4) qui indique que le fichier ne doit pas apparaître dans une liste de répertoire
Note 1 to entry: Aà l'article: Un client (3.1) sets this attribute by using the file server (FS) commands.établit cet
attribut au moyen des commandes du serveur de fichiers (SF).
3.9
path
specification of a filename (3.6) that may also include the directory name
chemin
spécification d'un nom de fichier (3.6) qui peut également comprendre le nom du répertoire
3.10
read-only attribute
file attribute (3.4) used to prevent writing to, or deletion of, a file
attribut «lecture seule»
attribut de fichier (3.4) utilisé pour éviter toute écriture sur un fichier ou sa suppression
Note 1 to entry: Aà l'article: Un client (3.1) sets this attribute by using the file server (FS) commands.établit cet
attribut au moyen des commandes du serveur de fichiers (SF).
3.11
volume
directory (3.2) that refers to a specific logical or physical storage unit or space
répertoire (3.2)qui fait référence à une unité ou à un espace de stockage logique ou physique spécifique
Note 1 to entry: The primaryà l'article: Le volume is theprimaire est celui utilisé comme volume used as current
volume when the file server (FS) is started.courant au démarrage du serveur de fichiers (SF).
7 Requirements
8.0 General message format
The general message format uses the parameter group number as the label for a group of parameters in
accordance with Annex C. Each of the parameters within the group can be expressed as characters, as
scaled data defined by the ranges given in 4.2, or as one or more bits. Characters shall be transmitted with
the left-most character first. Numerical parameters consisting of two or more data bytes shall be
transmitted least significant byte (LSB) first. Individual parameters shall be in accordance with Annex B.
When variable-length messages have eight or less data bytes, these messages shall be transmitted in a
single controller area network (CAN) frame. When variable length messages have nine or more data
bytes, the transport protocol (TP) or the extended transport protocol (ETP), in accordance with
ISO 11783-3, is required. When a message has less than eight data bytes, the unused bytes shall be filled
with FF16 values.
9.0 File data format
10.0.0 Data
Data consists of a block of bytes (unsigned eight-bit values). All values in the range of 0 … 255 are
10 10
allowed. There is no special handling of individual characters (control characters, end-of-line markers,
end-of-file markers or similar characters).
11.0.0 Bit groups
Groups of one to eight bits are packed into one byte as bit 7 … bit 0. Groups of nine to 16 bits are packed
into two bytes in the order of LSB as bit 7 … bit 0, followed by most significant byte (MSB)
as bit 15 … bit 8. Unused bits in a bit group default to a value of 0 (zero).
13.0.0 Integer
Integer values are formatted as follows:
4 Exigences
4.1 Format général des messages
Le format général des messages utilise le numéro de groupe de paramètres comme étiquette pour un
groupe de paramètres conformément à l'Annexe C. Chacun des paramètres du groupe peut être exprimé
sous forme de caractères, sous forme de données à l'échelle définies par les plages données en 4.2, ou
sous forme d'états de fonction se composant d'un ou de plusieurs bits. Les caractères doivent être
transmis en commençant par le caractère le plus à gauche. Les paramètres numériques se composant de
2 octets de données ou plus doivent être transmis en commençant par l'octet de poids faible (LSB). Les
paramètres individuels doivent être conformes à l'Annexe B. Lorsque les messages de longueur variable
ont 8 octets de données ou moins, ils doivent être transmis dans une trame CAN (controller area network)
simple. Lorsque les messages de longueur variable ont 9 octets de données ou plus, le protocole de
transport (TP) ou le protocole de transport étendu (ETP), conformément à l'ISO 11783-3, est exigé.
Lorsqu'un message a moins de 8 octets de données, les octets non utilisés doivent être remplis avec les
valeurs FF16.
4.2 Format des données de fichier
4.2.1 Données
Les données sont composées d'un bloc d'octets (entier non signé de 8 bits). Toutes les valeurs comprises
dans la plage de 010 … 25510 sont autorisées. Il n'y a pas de prise en charge spéciale des caractères
individuels (caractères de commande, marqueurs de fin de ligne, marqueurs de fin de fichier ou
caractères similaires).
4 © ISO 2022 – All rights reservedTous droits réservés
4.2.2 Groupes de bits
Les groupes de 1 bit à 8 bits sont mis en paquet d'un octet comme Bit 7 … Bit 0. Les groupes de 9 bits à
16 bits sont mis en paquet de deux octets, le premier étant un octet de poids faible (LSB, least significant
byte), comme Bit 7 … Bit 0, suivi de l'octet de poids fort (MSB, most significant byte), comme Bit 15 …
Bit 8. Les bits non utilisés dans un groupe de bits ont par défaut une valeur de 0 (zéro).
4.2.3 Nombre entier
Les valeurs entières sont formatées comme suit:
Unsigned 1 byteoctet 0 … 2 −1 0 … 255 Deleted Cells
10 10
8 bitEntier non
signé
de 8 bits
UnsignedEntier non 2 bytesoctets, LSB firsten premier 0 … 2 −1 0 … 65535
10 10
signé
de 16 bitbits
UnsignedEntier non 4 bytesoctets, LSB firsten premier 0 … 2 −1 0 … 4294967295
10 10
signé
de 32 bitbits
31 31
Signed Entier signé 4 bytesoctets, LSB first, two's −2 … 2 −1 −2147483648 …
de complimenten premier, +214748364710
32 bitbits complément à deux
14.1.1 Character string
A string contains characters represented by one or more bytes (unsigned eight-bit values). The length of
a string is specified by a string length data item. The characters in a string used as a filename or a path
name shall be as specified in Annex A. The support for Unicode characters is added in file server version
4, see B.5 Version Number. Prior to version 4, a character is by a single byte.
4.2.4 DataChaîne de caractères
Une chaîne contient des caractères représentés par un ou plusieurs octets (entier non signé de 8 bits). La
longueur d'une chaîne est spécifiée par un élément de données de longueur de chaîne. Les caractères
autorisés dans une chaîne utilisée comme nom de fichier ou nom de chemin doivent être comme spécifié
dans l'Annexe A. La prise en charge des caractères Unicode est ajoutée dans la version 4 du serveur de
fichiers, voir B.5 Numéro de version. Avant la version 4, un caractère est dénoté par un seul octet.
14.24.3 Commande de transmission controlde données
14.2.1 General
Each communication transaction between a client and the FS is initiated by a request from the client and
terminated by a response from the FS. In order to provide fail-safe communications, it is important that
the client assigns the received response to a corresponding request and repeat an erroneous request
without triggering the complete execution again.
14.2.3 Strategy
The client can issue a request and receive no response because of transient communication problems.
The failure can happen during the request message, i.e. the FS does not receive the request, or during the
response message, i.e. the client does not receive the response. The client cannot distinguish between
these two cases and shall repeat the request to obtain the requested data.
If there is no transaction strategy, the problem of the FS not receiving the request is resolved by the client
sending a second request and the FS responding with the requested data. However, if the client does not
receive the correct response data message and sends a second request, the FS then sends the next data
from the file; this is because a data request automatically advances to the next data in the file.
A transaction strategy is therefore required to prevent such errors. Each client on the network maintains
its own transaction number (TAN) counter, which should start at 0 after a power cycle.
Each client generates a TAN for each request, that it sends to the FS. Each TAN shall be different from the
previous. This can be done by incrementing the last TAN used, for the next request. The client is
responsible for checking that a received response contains the same TAN that was used in the request
during the communication session, thus ensuring that there are no lost commands. The FS shall
remember the last command processed and response message sent for each client. The FS compares each
new request with the previous request from the same client. If the TAN is not the same, the request is
implemented, and the response is sent. If the TAN is the same as the previously received request, the
request is not implemented, and the previous response is sent. Thus, if the client sends a second request,
in the case where the FS never received the first request, the FS receives the TAN for the first time,
implements the request and sends the correct data response. If the FS receives a request with the same
TAN that it has already received, it does not implement the request, but the previous response is
retransmitted.
14.2.8 Timeout
The execution time of all FS commands (the time between request and response) is maintained within
reasonable limits. The client shall monitor the time while waiting for a response.
4.3.1 The timeouts specified in ISOGénéralités
Chaque transaction de communication entre un client et le SF est initiée par une demande du client et se
termine par une réponse du SF. Pour assurer une communication en sécurité intrinsèque, il est important
que le client attribue la réponse reçue à une demande correspondante et répète une demande erronée
sans déclencher de nouveau l'exécution de la transaction complète.
4.3.2 Stratégie
Le client peut émettre une demande et ne pas recevoir de réponse du fait de perturbations transitoires
de communication. La défaillance peut survenir soit lors de l'envoi du message de demande, c'est-à-dire
que le SF ne reçoit pas la demande, ou lors du retour du message de réponse, c'est-à-dire que le client ne
reçoit pas la réponse. Le client ne peut différencier ces deux cas et doit renvoyer la demande pour obtenir
les données demandées.
En l'absence de stratégie de transaction, le cas du SF ne recevant pas la demande est résolu par la
transmission par le client d'une seconde demande et par la réponse du SF contenant les données
demandées. Cependant, si le client ne reçoit pas le message de données de réponse correct et transmet
une seconde demande, le SF transmet alors les données suivantes à partir du fichier, car une demande de
données passe automatiquement aux données suivantes dans le fichier.
6 © ISO 2022 – All rights reservedTous droits réservés
Il est par conséquent nécessaire d'appliquer une stratégie de transaction pour éviter les erreurs décrites
ci-dessus. Chaque client sur le réseau conserve son propre compteur de numéros de transaction (TAN,
transaction number); il convient qu'il commence à 0 après un cycle d'alimentation.
Chaque client génère un TAN pour chaque demande qu'il transmet au SF. Chaque numéro TAN doit être
différent du précédent. Cela peut être réalisé en incrémentant le dernier numéro TAN utilisé pour la
demande suivante. Le client est chargé de vérifier qu'une réponse reçue contient le même TAN que celui
qui a été utilisé dans la demande au cours de la session de communication, permettant ainsi de s'assurer
qu'il n'y a aucune perte de commandes. Le SF doit mémoriser la dernière commande traitée et le message
de réponse transmis pour chaque client. Le SF compare chaque nouvelle demande à la précédente
demande transmise par le même client. Si le numéro TAN n'est pas le même, la demande est mise en
œuvre et la réponse est envoyée. Si le numéro TAN est le même que celui de la demande précédemment
reçue, la demande n'est pas mise en œuvre et la réponse précédente est envoyée. Ainsi, si le client
transmet une seconde demande lorsque le SF n'a jamais reçu la première, le SF reçoit le numéro TAN pour
la première fois et met en œuvre la demande en envoyant la réponse de données correcte. Si le SF reçoit
une demande ayant le même numéro TAN que celui de la demande déjà reçue, il ne met pas en œuvre la
demande, mais retransmet la réponse précédente.
4.3.3 Temporisation
Le temps d'exécution de toutes les commandes du SF (le temps écoulé entre une demande et une réponse)
est compris dans des limites raisonnables. Le client doit surveiller le temps d'attente d'une réponse.
Les temporisations spécifiées dans l'ISO 11783--3 for thepour le protocole de transport protocol and the
extendedet pour le protocole de transport protocol shall be met for the execution of commandsétendu
doivent être satisfaites pour l'exécution des commandes.
If a timeout expires, the request is assumed to have failed and the client shall repeat the request using the
same TAN.
If a request response takes longer thanSi une temporisation est écoulée, la demande est supposée avoir
échoué et le client doit réitérer la demande en utilisant le même numéro TAN.
Si une réponse à une demande dure plus de 200 ms after the completion of the request, the FS shall send
the statusaprès réalisation de la demande, le SF doit transmettre le message to indicate busy state to
thed'état pour indiquer l'état occupé au client. This provides a request timeout ofCela assure une
temporisation de demande de 600 ms if the FS statussi le message does not show a busy statusd'état du
SF n'indique pas un état occupé.
14.3 Date and time support
Several FS commands require a file date and time. UTC is used for this time. The file server's
implementation of real time support can be either by maintaining its own real time information or by
requesting the time and date information using the Time/Date parameter group specified in ISO 11783-7.
If a client requests the date and time for the root of a volume, or the volume list itself, the file server
response shall include the error “Access denied”.
The file server shall respond with the most recent time where the folder/file was accessed if the operating
system provides this information. Otherwise, the file server shall respond with the information that is
available.
Coordinated universal time, or universal time, formerly known as Greenwich mean time (GMT).
Due to possible date and time changes (by the operator or other means) there is no guarantee, that the
date and time associated with files and folders indicates the actual chronological order, in which the
files/folders were accessed.
14.7 Multi-client support
The file server shall support multiple clients. If more than one client has a connection simultaneously, the
file server shall function with each client as if it is the only one on the network. There shall be no
interference between the commands processed for different clients.
The file server shall accept connections from all clients on the network. If the file server has limited
resources, it may limit the number of open file handles. Prior to file server version 4 the requirement to
support all connections was not clearly defined.
Upon connection of a client, the file server initiates the current directory for that client as the root
directory of the primary volume of the file server file system. If there are no volumes, then the current
directory is set to the list of volumes “\\”. The client is required to use the appropriate Change Current
Directory or Open File commands to access files that need to be unique for that client. In the case where
multiple clients require access to common files, these clients are responsible for synchronizing their
directory and file naming conventions to enable access to these common files. To prevent unintentional
access to manufacturer proprietary files, a reserved directory name is specified. The naming convention
of the manufacturer-specific directory is:
4.4 Horodatage
Plusieurs commandes du SF nécessitent un horodatage de fichier. Le temps UTC est utilisé à cet effet. Le
SF peut mettre en œuvre la prise en charge en temps réel soit en maintenant ses propres informations en
temps réel, soit en demandant les informations d'horodatage au moyen du groupe de paramètres
Heure/Date spécifié dans l'ISO 11783-7.
Si un client demande l'horodatage pour la racine d'un volume ou la liste de volumes elle-même, la réponse
du serveur de fichiers doit contenir l'erreur «Accès refusé».
Le serveur de fichiers doit renvoyer en réponse la dernière heure d'accès au répertoire/fichier, si le
système d'exploitation fournit cette information. Sinon, le serveur de fichiers doit répondre avec les
informations disponibles.
En raison des possibilités de modification de l'horodatage (par l'opérateur ou par d'autres moyens), il n'y
a aucune garantie que l'horodatage associé à des fichiers et répertoires indique l'ordre chronologique
réel d'accès aux fichiers/répertoires.
4.5 Prise en charge de clients multiples
Le serveur de fichiers doit prendre en charge plusieurs clients. Lorsque plusieurs clients sont connectés
simultanément, le serveur de fichiers doit fonctionner avec chaque client comme s'il n'y en avait qu'un
seul sur le réseau. Aucune interférence ne doit se produire entre les commandes gérées pour différents
clients.
Le serveur de fichiers doit accepter les connexions de tous les clients sur le réseau. Si le serveur de fichiers
dispose de ressources limitées, il peut restreindre les indicateurs de nombre de fichiers ouverts. Avant la
Temps universel coordonné (UTC, universal time coordinated) ou temps universel, initialement connu sous l'appellation temps
moyen de Greenwich (GMT).
8 © ISO 2022 – All rights reservedTous droits réservés
version 4 du serveur de fichiers, l'exigence relative à la prise en charge de toutes les connexions n'était
pas clairement définie.
Lorsqu'un client se connecte, le serveur de fichiers initie le répertoire courant du client concerné comme
répertoire racine du volume primaire du système de fichiers du serveur de fichiers. En l'absence de
volumes, le répertoire courant est alors réglé sur la liste de volumes «\\». Il est demandé au client
d'utiliser les commandes de Modification de répertoire courant ou d'Ouverture de fichier pour accéder
aux fichiers qui lui sont spécifiques. Lorsque plusieurs clients demandent l'accès à des fichiers communs,
ils doivent synchroniser leur répertoire et les règles d'affectation des noms de fichiers pour avoir accès à
ces fichiers communs. Pour éviter tout accès accidentel aux fichiers propriétaires du fabricant, un nom
de répertoire réservé est spécifié. Les règles d'affectation des noms du répertoire spécifique au fabricant
sont:
MCMC0000
where 0000 contains the four-digit manufacturer code (defined in accordance with ISO 11783-5 and
listed in ISO 11783-1) in decimal representation, formatted with leading zeroes. A client shall not use this
manufacturer-coded directory name using a manufacturer code other than the manufacturer code in its
NAME field. When the client attempts to open a file in a manufacturer-specific directory where the
manufacturer code in the NAME of that client is not that of the manufacturer-specific directory name, the
FS shall prevent access and return an “access denied” error code.
The complete value range fromoù 0000 représente le code du fabricant à 4 chiffres (définit conformément
à l'ISO 11783-5 et énuméré dans l'ISO 11783-1), à notation décimale et commençant par des zéros. Les
clients ne doivent pas utiliser ce nom de répertoire du code du fabricant avec un code du fabricant
différent de celui figurant dans leur champ NOM. Lorsque le client tente d'ouvrir un fichier dans un
répertoire spécifique au fabricant et que le code du fabricant dans le champ NOM du client ne correspond
pas au nom de répertoire spécifique au fabricant, le SF doit refuser l'accès et renvoyer un code d'erreur
«accès refusé».
La plage de valeurs complète allant de 0000 toà 9999 shall be handled as manufacturerdoit être traitée
en tant que code, even though the manufacturer du fabricant, bien que le code is defined as an 11-bit
value in ISO du fa
...
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...