Iso 11783-6-2014
Iso 11783-6-2014
STANDARD 11783-6
Third edition
2014-07-01
Reference number
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
ii
Copyright International Organization for Standardization © ISO 2014 – All rights reserved
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Contents Page
Foreword ..........................................................................................................................................................xiii
Introduction.......................................................................................................................................................xv
1 Scope ......................................................................................................................................................1
2 Normative references............................................................................................................................1
3 Terms and definitions ...........................................................................................................................1
4 Technical requirements ........................................................................................................................5
4.1 Overview.................................................................................................................................................5
4.2 Operator input and control ...................................................................................................................7
4.3 Acoustic alarm .......................................................................................................................................9
4.4 Coordinate system ................................................................................................................................9
4.5 Display areas .........................................................................................................................................9
4.5.1 General ...................................................................................................................................................9
4.5.2 Data Mask ...............................................................................................................................................9
4.5.3 Soft Key Mask area and Soft Key designators ...................................................................................9
4.6 Behaviour .............................................................................................................................................13
4.6.1 Object pools .........................................................................................................................................13
4.6.2 Working Sets........................................................................................................................................13
4.6.3 Multiple Visually Similar Working Sets .............................................................................................15
4.6.4 Displayed Working Set number .........................................................................................................16
4.6.5 Language, formats and measurement units selection ....................................................................16
4.6.6 Initialization ..........................................................................................................................................17
4.6.7 System Shutdown ...............................................................................................................................18
4.6.8 Working Set object and active masks ...............................................................................................20
4.6.9 Connection management....................................................................................................................22
4.6.10 Updating the operator interface .........................................................................................................25
4.6.11 Special objects ....................................................................................................................................25
4.6.12 Relative X/Y positions .........................................................................................................................30
4.6.13 Overlaid objects...................................................................................................................................31
4.6.14 Alarm handling ....................................................................................................................................32
4.6.15 Clipping ................................................................................................................................................33
4.6.16 Scaling ..................................................................................................................................................34
4.6.17 Operator input......................................................................................................................................34
4.6.18 Soft Key and Button activation ..........................................................................................................37
4.6.19 Font rendering .....................................................................................................................................38
4.6.20 Object Rendering Accuracy, Quality and VT Developer Freedom .................................................47
4.6.21 Filling output shape objects...............................................................................................................48
4.6.22 Events ...................................................................................................................................................49
4.6.23 Touch screens and pointing devices ................................................................................................50
4.6.24 Proprietary Means ...............................................................................................................................51
4.6.25 VT Number ...........................................................................................................................................51
4.6.26 Packet Padding ....................................................................................................................................51
4.7 Displaying Data from Multiple Working Sets on One Mask ............................................................51
4.7.1 General .................................................................................................................................................51
4.7.2 User-Layout Data Mask.......................................................................................................................52
4.7.3 Window Mask object ...........................................................................................................................53
4.7.4 Window Mask content.........................................................................................................................53
4.7.5 Window Cell Size and Borders...........................................................................................................55
4.7.6 Window Mask Scaling .........................................................................................................................55
4.7.7 Using Window Masks Outside of User-Layout Data Masks............................................................56
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
4.7.13 Operator Inputs ....................................................................................................................................59
4.7.14 Refreshing On Screen Data ................................................................................................................59
4.7.15 Look and Feel.......................................................................................................................................60
4.7.16 Uploading New Window Mask and Key Group objects ...................................................................61
Annex A (normative) Object, event, colour and command codes ..............................................................63
A.1 Object types .........................................................................................................................................63
A.1.1 General..................................................................................................................................................63
A.1.2 Nomenclature .......................................................................................................................................65
A.1.3 Object relationships ............................................................................................................................66
A.2 Event types...........................................................................................................................................68
A.3 VT standard colour palette .................................................................................................................70
A.4 Command/parameter code summary ................................................................................................72
Annex B (normative) Object definitions ........................................................................................................78
B.1 Working Set object ..............................................................................................................................78
B.2 Data Mask object..................................................................................................................................81
B.3 Alarm Mask object ...............................................................................................................................83
B.4 Container object...................................................................................................................................86
B.5 Soft Key Mask object...........................................................................................................................88
B.6 Key object.............................................................................................................................................89
B.7 Button object........................................................................................................................................91
B.8 Input field objects ................................................................................................................................95
B.8.1 General..................................................................................................................................................95
B.8.2 Input Boolean object ...........................................................................................................................97
B.8.3 Input String object ...............................................................................................................................98
B.8.4 Input Number object ..........................................................................................................................101
B.8.5 Input List object .................................................................................................................................104
B.9 Output field objects ...........................................................................................................................108
B.9.1 General................................................................................................................................................108
B.9.2 Output String object ..........................................................................................................................109
B.9.3 Output Number object .......................................................................................................................110
B.9.4 Output List object ..............................................................................................................................113
B.10 Output shape objects ........................................................................................................................115
B.10.1 General................................................................................................................................................115
B.10.2 Output Line object .............................................................................................................................115
B.10.3 Output Rectangle object ...................................................................................................................118
B.10.4 Output Ellipse object .........................................................................................................................120
B.10.5 Output Polygon object ......................................................................................................................123
B.11 Output graphic objects .....................................................................................................................125
B.11.1 General................................................................................................................................................125
B.11.2 Output Meter object ...........................................................................................................................125
B.11.3 Output Linear Bar Graph object .......................................................................................................129
B.11.4 Output Arched Bar Graph object .....................................................................................................133
B.12 Picture Graphic object ......................................................................................................................137
B.12.1 General................................................................................................................................................137
B.12.2 Picture Graphic object raw data format and compression ...........................................................139
B.13 Variable objects .................................................................................................................................139
B.13.1 General................................................................................................................................................139
B.13.2 Number Variable object.....................................................................................................................140
B.13.3 String Variable object ........................................................................................................................140
B.14 Attribute objects ................................................................................................................................141
B.14.1 General................................................................................................................................................141
B.14.2 Font Attributes object .......................................................................................................................141
B.14.3 Line Attributes object ........................................................................................................................143
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Annex H (normative) Activation messages ................................................................................................248
H.1 General ...............................................................................................................................................248
H.2 Soft Key Activation message ...........................................................................................................248
H.3 Soft Key Activation response ..........................................................................................................248
H.4 Button Activation message ..............................................................................................................249
H.5 Button Activation response..............................................................................................................249
H.6 Pointing Event message ...................................................................................................................250
H.7 Pointing Event response ..................................................................................................................251
H.8 VT Select Input Object message......................................................................................................251
H.9 VT Select Input Object response .....................................................................................................252
H.10 VT ESC message ...............................................................................................................................252
H.11 VT ESC response...............................................................................................................................252
H.12 VT Change Numeric Value message ...............................................................................................253
H.13 VT Change Numeric Value response...............................................................................................253
H.14 VT Change Active Mask message ...................................................................................................253
H.15 VT Change Active Mask response...................................................................................................254
H.16 VT Change Soft Key Mask message................................................................................................254
H.17 VT Change Soft Key Mask response ...............................................................................................255
H.18 VT Change String Value message ...................................................................................................255
H.19 VT Change String Value response...................................................................................................255
H.20 VT On User-Layout Hide/Show message ........................................................................................256
H.21 VT On User-Layout Hide/Show response .......................................................................................256
H.22 VT Control Audio Signal Termination message .............................................................................257
Annex I (normative) Other messages..........................................................................................................258
Annex J (normative) Auxiliary control ........................................................................................................259
J.1 General ...............................................................................................................................................259
J.2 Auxiliary Inputs..................................................................................................................................259
J.3 Auxiliary controls in multiple VT environments.............................................................................260
J.3.1 General rules......................................................................................................................................260
J.3.2 Primary VT and resolving VT function instance zero ....................................................................260
J.4 Defining auxiliary inputs and functions ..........................................................................................261
J.4.1 General ...............................................................................................................................................261
J.4.2 Auxiliary Function Type 1 object .....................................................................................................261
J.4.3 Auxiliary Function Type 2 object .....................................................................................................262
J.4.4 Auxiliary Input Type 1 object............................................................................................................263
J.4.5 Auxiliary Input Type 2 object............................................................................................................264
J.4.6 Auxiliary Function Type 2 types ......................................................................................................265
J.4.7 Auxiliary Control Designator Type 2 Object Pointer .....................................................................269
Table of Tables
Table 1 — VT Response message behavior......................................................................................................15
Table 2 — Working Set state changes (VT Supports only Active Mask) ...........................................................21
Table 3 — Working Set state changes (VT Supports Multiple Working Sets or Window Masks Visible
Simultaneously)...........................................................................................................................................22
Table 4 — VT behaviour on mask transition ......................................................................................................33
Table 5 — VT Reaction to navigation and data input events .............................................................................35
Table 6 — VT Behavior When New Window Mask or Key Group Object is Uploaded......................................62
Table A.1 — Virtual terminal objects ..................................................................................................................63
Table A.2 — Allowed hierarchical relationships of objects.................................................................................67
Table A.3 — Event summary..............................................................................................................................69
Table A.4 — Standard VT RGB colour palette...................................................................................................70
Table A.5 — Command/parameter summary.....................................................................................................73
Table B.1 — Working Set events .......................................................................................................................78
Table B.2 — Working Set attributes and record format .....................................................................................80
Table B.3 — Data Mask events..........................................................................................................................81
Table B.4 — Data mask attributes and record format........................................................................................82
Table B.5 — Alarm Mask events ........................................................................................................................83
Table B.6 — Alarm Mask attributes and record format ......................................................................................85
Table B.7 — Container events ...........................................................................................................................86
Table B.8 — Container attributes and record format .........................................................................................87
Table B.9 — Soft Key Mask events....................................................................................................................88
Table B.10 — Soft Key Mask attributes and record format................................................................................88
Table B.11 — Key events...................................................................................................................................89
Table B.12 — Key attributes and record format .................................................................................................90
Table B.13 — Button events...............................................................................................................................92
Table B.14 — Button attributes and record format.............................................................................................93
Table B.15 — Input events .................................................................................................................................96
Table B.16 — Input Boolean attributes and record format.................................................................................98
Table B.17 — Input String attributes and record format.....................................................................................99
Table B.18 — Input Number attributes and record format ...............................................................................102
Table B.19 — Input List events ........................................................................................................................105
Table B.20 — Input List attributes and record format.......................................................................................107
Table B.21 — Output field events ....................................................................................................................108
Table B.22 — Output String attributes and record format................................................................................109
Table B.23 — Output Number attributes and record format ............................................................................111
Table B.24 — Output List events......................................................................................................................113
Table B.25 — Output List attributes and record format....................................................................................113
Table B.26 — Output Line events ....................................................................................................................116
Table B.27 — Output Line attributes and record format ..................................................................................116
Table B.28 — Output Rectangle Events ..........................................................................................................118
Table B.29 — Output Rectangle attributes and record format .........................................................................119
Table B.30 — Output Ellipse events ................................................................................................................121
Table B.31 — Output Ellipse attributes and record format...............................................................................121
Table B.32 — Output Polygon events ..............................................................................................................124
Table B.33 — Output Polygon attributes and record format ............................................................................124
Table B.34 — Output Meter events ..................................................................................................................127
Table B.35 — Output Meter attributes and record format ................................................................................127
Table B.36 — Output Linear Bar Graph events ...............................................................................................131
Table B.37 — Output Linear Bar Graph attributes and record format..............................................................131
Table B.38 — Output Arched Bar Graph events ..............................................................................................134
Table B.39 — Output Arched Bar Graph attributes and record format ............................................................135
Table B.40 — Picture Graphic events ..............................................................................................................137
Table B.41 — Picture Graphic attributes and record format ............................................................................137
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Table B.49 — Fill Attributes events ................................................................................................................. 146
Table B.50 — Fill Attributes attributes and record format................................................................................ 146
Table B.51 — Input Attributes events .............................................................................................................. 147
Table B.52 — Input Attributes attributes and record format ............................................................................ 148
Table B.53 — Extended Input Attributes attributes and record format............................................................ 150
Table B.54 — Object Pointer events ............................................................................................................... 151
Table B.55 — Object Pointer attributes and record format.............................................................................. 151
Table B.56 — Macro attributes and record format .......................................................................................... 152
Table B.57 — Colour Map attributes and record format.................................................................................. 153
Table B.58 — Graphics Context events .......................................................................................................... 156
Table B.59 — Graphics Context attributes and record format ........................................................................ 157
Table B.60 — Window Mask events................................................................................................................ 159
Table B.61 — Window Mask attributes and record format .............................................................................. 160
Table B.62 — Key Group events ..................................................................................................................... 182
Table B.63 — Key Group attributes and record format ................................................................................... 182
Table B.64 — Object Label Reference List attributes and record format........................................................ 184
Table B.65 — External Object Definition events ............................................................................................. 185
Table B.66 — External Object Definition attributes and record format............................................................ 185
Table B.67 — External Reference NAME events ............................................................................................ 186
Table B.68 — External Reference NAME attributes and record format .......................................................... 186
Table B.69 — External Object Pointer events ................................................................................................. 187
Table B.70 — External Object Pointer attributes and record format ............................................................... 187
Table B.71 — Animation events ...................................................................................................................... 189
Table B.72 — Animation attributes and record format .................................................................................... 190
Table F.1 — Graphic command summary....................................................................................................... 238
Table J.1 — Auxiliary Function Type 1 attributes and record format .............................................................. 261
Table J.2 — Auxiliary Function Type 2 attributes and record format .............................................................. 262
Table J.3 — Auxiliary Input Type 1 attributes and record format .................................................................... 264
Table J.4 — Auxiliary Input Type 2 attributes and record format .................................................................... 265
Table J.5 — Auxiliary Function Type 2 types .................................................................................................. 266
Table J.6 — Auxiliary Control Designator Type 2 Object Pointer attributes and record format ...................... 271
Table J.7 — Auxiliary Control Designator Type 2 Object Pointer examples ................................................... 271
Table J.8 — Set Information ............................................................................................................................ 291
Table L.1 — ISO 8859-1 (Latin 1) character set.............................................................................................. 294
Table L.2 — ISO 8859-15 (Latin 9) character set............................................................................................ 295
Table L.3 — ISO 8859-2 (Latin 2) character set.............................................................................................. 296
Table L.4 — ISO 8859-4 (Latin 4) character set.............................................................................................. 297
Table L.5 — ISO 8859-5 (Cyrillic) character set .............................................................................................. 298
Table L.6 — ISO 8859-7 (Greek) character set............................................................................................... 299
Table L.7 — WideString minimum character set ............................................................................................. 300
Table of Figures
Figure 1 — Virtual terminal — examples..............................................................................................................6
Figure 2 — Operator input and control means – example ...................................................................................8
Figure 3 — Physical Soft Key Orientation Examples showing Key Locations ...................................................11
Figure 4 — VT virtual Soft Key paging ...............................................................................................................12
Figure 5 — Example VT which displays an active and an inactive Working Set simultaneously ......................21
Figure 6 — Initialization, unexpected shutdown, and expected shutdown ........................................................24
Figure 7 — Container reuse ...............................................................................................................................26
Figure 8 — Container used to hide objects — Example ....................................................................................26
Figure 9 — External Object References — VT Example ...................................................................................29
Figure 10 — External Object References — Relationship Example ..................................................................30
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Figure J.5 — Example showing expansion of Auxiliary Inputs on an Auxiliary Function Data Mask .............. 273
Figure J.6 — Typical message sequence to make assignment and later remove assignment ...................... 278
Figure J.7 — Auxiliary control message flow................................................................................................... 281
Figure J.8 — Auxiliary assignment screen – example..................................................................................... 282
Figure J.9 — Permitted remove assignment alternatives................................................................................ 283
Figure J.10 — Preferred assignment example ................................................................................................ 286
xii --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
The committee responsible for this document is 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-6:2010) which has been technically
revised.
ISO 11783 consists of the following parts, under the general title Tractors and machinery for agriculture and
forestry — Serial control and communications data network:
⎯ Part 10: Task controller and management information system data interchange
Introduction
Parts 1 to 14 of ISO 11783 specify a communications system for agricultural equipment based on the
ISO 11898 [5] protocol. SAE J 1939 [1] 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 J 1939 specifications to be used by
agricultural and forestry equipment with minimal changes. The specifications for virtual terminals given in this
part of ISO 11783 are based on DIN 9684-4 [2]. General information on ISO 11783 is to be found in
ISO 11783-1.
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.
All phrases in this document that refer explicitly to a software term for an object or a command shall have the
first letter of each object or command word capitalized (e.g. Output Linear Bar Graph object, Change Numeric
Value command). This aides in the recognition of these terms as a specific item which has a specific definition
in this document.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this part of ISO 11783 may involve the use of a patent concerning the controller area network
(CAN) protocol referred to throughout the document.
ISO takes no position concerning the evidence, validity and scope of this patent.
The holder of this patent has assured ISO that he is willing to negotiate licences under reasonable and non-
discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the
holder of this patent right is registered with ISO. Information may be obtained from:
Attention is drawn to the possibility that some of the elements of this part of ISO 11783 may be the subject of
patent rights other than that those identified above. ISO shall not be held responsible for identifying any or all
such patent rights.
1 Scope
ISO 11783 as a whole specifies a serial data network for control and communications on forestry or
agricultural tractors, mounted, semi-mounted, towed or self propelled implements. Its purpose is to
standardize the method and format of transfer of data between sensor, actuators, control elements,
information storage and display units whether mounted or part of the tractor, or any implements.
This part of ISO 11783 describes a universal virtual terminal that can be used by both tractors and
implements.
Corrections in the second edition were made to Table L.2 — ISO 8859-15 (Latin 9) character set.
Requirements in the second edition were specified for two versions of the VT and Working Sets. Version 3
VTs and Working Sets meet all the requirements of the first edition, the specific requirements for version 3 of
Annex G and the requirements of Annex J and Table L.2 — ISO 8859-15 (Latin 9) character set of the second
edition. Version 4 VTs and Working Sets meet all the requirements of the second edition.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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
ISO 11783-7, Tractors and machinery for agriculture and forestry — Serial control and communications data
network — Part 7: Implement messages application layer
ISO 15077, Tractors and self-propelled machinery for agriculture — Operator controls — Actuating forces,
displacement, location and method of operation
3.1
auxiliary input unit
autonomous control function (CF) providing Auxiliary Controls for common use that may also be physically
located within an electronic control unit (ECU), or on the virtual terminal (VT)
3.2
object pool
collection of objects that completely define the operator interface for an implement or a single Working Set
Note 1 to entry: The complete VT definition will be made up of one or more object pools — one for each Working Set.
3.3
Object ID
numeric value which identifies a specific object within an object pool
Note 1 to entry: Object ID values range from 0 to FFFF16 (6553510), with 65535 as the NULL Object ID.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
3.4
attribute ID
AID
numeric value which references a specific object's attribute
Note 1 to entry: AID values range from 0 to FF16 (25510), with 255 as the NULL_AID.
3.5
char
single character where the size is 1 byte
Note 1 to entry: Commonly used for ISO 8859 characters (e.g. 4116 in ISO 8859-1 represents ’A’) (See Annex L).
3.6
character
single text grapheme or symbol, as in an alphabet
Note 1 to entry: Size is variable based on the encoding scheme (See char and WideChar).
3.7
code plane
group of 65536 possible character codes
Note 1 to entry: Unicode/ISO10464 organizes the characters in 17 code planes numbered 0 to 16.
EXAMPLE
3.8
open input object
state of an input object where the object has focus and it is open for operator input
Note 1 to entry: Open input object is used interchangeably with data input.
3.9
selected input object
state of an input object where the object has focus but it is not open for operator input
Note 1 to entry: Selected input object is used interchangeably with “has focus”.
3.10
surrogate pair
32 bit code for characters composed of a 16 bit high pair and a 16 bit low pair
Note 1 to entry: UTF-16 encoding of characters in code plane 1 to 16 (See Clause 4.6.19.7 String encoding)
3.11
WideChar
single character with a size of 2 bytes encoded in little endian order
EXAMPLE Byte sequence 4116, 0016 represents ’A’. (See Annex L).
Note 1 to entry: Two WideChars can be combined to indicate character codes exceeding 16-bit (See Clause 4.6.19.7
String encoding).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
3.12
WideString
zero or more characters composed of the primitive type “WideChar” always preceded by the byte order mark
FEFF16
EXAMPLE Byte sequence FF16,FE16,4116,0016,4216,0016,4316,0016 represents “ABC”. This WideString has a Length of
8 bytes with the number of characters in the presentation equal to 3.
3.13
8-bit string
zero or more characters composed of the primitive type “char”
3.14
VT Number
number that is used to uniquely identify each connected VT to the operator
3.15
User-Layout Data Mask
special Data Masks (see Clause 4.1) that are controlled by the VT but layed out by the operator
3.16
Window Cell
equally sized cell in a grid on a User-Layout Data Mask
3.17
Window Mask object
supplied by the Working Set for placement by the operator into the area of one or more window cells but not a
partial cell
3.18
User-Layout Soft Key Mask
Soft Key Masks that are controlled by the VT but layed out by the operator
3.19
Key Cell
cell that is the size of a Soft Key designator in a User-Layout Key Mask
3.20
Key Group object
area of one or more Key Cells and contains a grouping of one or more Key objects
3.21
Non-VT Screen
display screen that is not part of the VT application or one in which the layout is controlled by the VT
EXAMPLE A screen that comes from another application within the display. (See Clause 4.7)
3.22
Non-VT Area
visible area outside the normal Data Mask and Soft Key Mask areas
EXAMPLE A display of information related to the vehicle operation. (See Clause 4.7)
3.23
Referenced WS
working set with an object pool containing objects which are shown by another object pool via the External
Object Pointer object
3.24
Referencing WS
A working set with an object pool which shows object(s) from another object pool via the External Object
Pointer object
3.25
Functionally Identical WS
Working Set(s) with a NAME that exactly matches other Working Sets, when the Self Configurable, Instance
fields, and Identity Number are excluded in the comparison
3.26
Line End
“cursor” or text positioning control intended to locate the following displayable character "font height" pixels
downward and at the left-most position in the containing object
4 Technical requirements
4.1 Overview
A virtual terminal (VT) is a control function (CF) within an electronic control unit (ECU), consisting of a
graphical display and input functions, connected to an ISO 11783 network that provides the capability for a
CF, composing an implement or a group of implements to interact with an operator. The VT provides the
capability to display information and to retrieve data from an operator. The CF, as an implement or a group of
implements represented by a Working Set Master acquires storage for objects within the VT and on demand
displays this stored information to an operator. In this part of ISO 11783, the term Working Set will be used for
a CF, as an implement or a group of implements either represented by a single ECU or a group of ECUs
acting as a Working Set. Working Sets on the network can also acquire the use of input methods of the VT to
allow the operator to send signals back to the Working Set.
This part of ISO 11783 describes the VT with the detail and clarity required for VTs built by different
manufacturers to be interchangeable with any implement Working Set that uses its services. The interface
protocol of this part of ISO 11783 also reduces the run-time ISO 11783 communication bus traffic as much as
possible. For these reasons, the requirements of this part of ISO 11783 are organized in an object-oriented
manner with specific attributes and behaviour of each object clearly and fully defined. The required behaviour
of the VT given certain situations is also detailed.
In general, the functions, not the design, of the user interface of the VT are defined in order to avoid
restrictions on possible designs. However, certain limitations are imposed in order to meet the goal of
interchangeability between various manufacturers. Specifications regarding physical layout, components,
processing power and the number of physical elements comprising a VT have been omitted in order to avoid
restricting manufacturer’s designs.
The VT shall have a pixel-addressable (graphical) display. Information from connected Working Sets is shown
to the operator on the graphical display. This information is shown in display areas that are defined by Data
Masks, Alarm Masks and Soft Key Masks. The data for these masks is contained in object definitions that are
loaded into a VT via the ISO 11783 CAN bus, or from non-volatile memory. When the information defined by a
mask is required on the display, the mask can be made visible by a single Change Active Mask command
from the Working Set, and therefore does not require significant additional network traffic.
The physical size, resolution, orientation and methods of implementing the graphical display are at the
discretion of the designer of the VT. Figure 1 — Virtual terminal — examples shows examples of some
possible VT designs and orientations.
Key
1 Data Mask area 4 Soft Key Designator
2 Soft Key Mask area 5 Physical Soft Key
3 Physical Screen
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
The VT shall provide the operator with means for control and input. There are five means associated with a
VT that can be used for the input of data, selection of display data, and the control of connected Working Sets.
a) Soft
is a means, most likely keys on the VT, using software-changeable designators (labels). “Soft Keys” have
their identity changed depending on which Soft Key Mask is visible. The VT shall make the association
between a Soft Key and its designator clearly evident to the operator.
b) Navigation
is a means of selecting an input field or Button within the active Data Mask. If keys are used for
“Navigation”, they do not send key activation information to the Working Set and are proprietary to the VT.
c) Data Input
is a means of entering/editing information in an input field within the active Data Mask. If keys are used for
“Data Input”, they do not send key activation information to the Working Set and are proprietary to the VT.
A means shall be provided for entering any number or character sequence that is valid for the input field.
During the data input operation, the VT Status message will continue to indicate the active Working Set,
and active mask which contains the input object for which the data input operation applies. Data input
operation that originates on a User-Layout Data Mask does not affect the VT Status message.
There are two types of Data Input – “editing” and “real time editing”.
1) Editing
is a means of data input where the new value being entered is composed by the operator using a
proprietary means within the VT. During the composition of the new value, changes to the original
value are not communicated to the Working Set. A means shall also be provided for ESC from or
ENTER of information into a data field.
The ENTER means shall be provided to indicate to the Working Set the completion of data entry and
communication of the new value, and the ESC means shall be provided to indicate that the data
entry was aborted. The ENTER and ESC means may either be a permanent key or may only be
available during data entry. (See Table 5 — VT Reaction to navigation and data input events) The VT
shall send a VT ESC message to a Working Set for an operator-activated ESC means or an ESC
response as a response to receiving an ESC command from a Working Set.
2) Real Time Editing
is a means of data input for an Input Number object and Input List object where the object has focus
and it is open for operator input and changes by the operator to the value are periodically transmitted
to the Working Set while the object is being changed. The VT Change Numeric Value message is
limited to a 5 Hz update rate. Each value change sent to the Working Set is considered a complete
transaction, as if the ENTER means was activated, and cannot be reverted by the ESC means. The
VT is not required to provide steps in uniform increments, however it shall be possible to set any
value (e.g. fast scrolling is allowed to span a wide range of values, with fine adjustment for final
setting). If the ESC means is activated during real time editing, the VT shall ensure that the on-
screen value is equal to the value last sent to the Working Set. The VT may send a final value to the
Working Set prior to sending the VT ESC message, or ESC response message to ensure this
synchronization. Real time editing shall meet the operator controls requirement specified in ISO
15077.
d) Control
is a means of selecting between Working Sets whenever a Data Mask is available and for
acknowledging alarms. Both means are required. Since more than one Working Set can use the
services of the VT, the VT shall provide a means for the operator of selecting between connected
Working Sets. The Working Set selection means should be indicated by three circular arrows or a
similar graphic. Only the ACK means sends key activation information to the Working Set.
e) Auxiliary Input
is a means available to the operator for communicating input commands to the Working Set(s) using
Auxiliary Controls which are assigned to Auxiliary Functions. (See Annex J)
Key
1 control 5 Soft Key 6
2 navigation 6 data input
3 Soft Key 1 7 auxiliary input
4 Soft Key 2
The VT shall provide an acoustic alarm. The alarm may be a simple on/off type buzzer or an acoustic
component capable of either/or variable frequency and audio level. (See Clause D.9 Get Hardware response)
Positions and sizes in this part of ISO 11783 are always given in physical pixels unless otherwise stated. A
two-dimensional coordinate plane (x, y) is used, where x is the number of units wide (x increases from left to
right) and y is the number of units high (y increases from top to bottom). The coordinates are signed values.
The origin (0, 0) for any object's coordinate system is located at the top left-hand corner of the parent object.
4.5.1 General
This section defines standard Data Mask and Soft Key Mask areas of the display. Alternate usage of this area
supports displaying data from multiple working sets. (See Clause 4.7)
The VT shall reserve an area of the display for displaying Data Masks and Alarm Masks. This area is called
the Data Mask area (See Figure 1 — Virtual terminal — examples). Recognizing that the physical orientation
of the VT display could be different, depending on the manufacturer of the VT, a square data mask aspect
ratio is chosen to ensure correct display in either landscape or portrait orientation. The minimum Data Mask
area shall be 200 pixels × 200 pixels. This requirement does not limit the physical resolution or size of the
display, only the useable Data Mask area. Higher resolution mask areas are permitted, but the square aspect
ratio shall be strictly enforced. Examples of Data Mask areas that would meet this requirement are:
⎯ 200 × 200,
⎯ 240 × 240,
⎯ 320 × 320, and
⎯ 480 × 480.
Any other square dimensions would be acceptable.
It is suggested that unused areas of the physical display be used for proprietary information such as vehicle
data, VT statistics or other data.
The VT shall reserve an area of the display for Soft Key labels, separate from the Data Mask area. This area
is called the Soft Key Mask area (See Figure 1 — Virtual terminal — examples). Each Soft Key shall have a
reserved display area, called a Soft Key designator, for displaying a label (See Figure 1 — Virtual terminal —
examples). The minimum size of the designator field is 60 pixels wide × 32 pixels high regardless of screen
orientation. The Soft Key designators may contain text, graphics or both. The Soft Key Mask area may be
adjacent to, or physically separate from, the Data Mask area, but shall not be part of the Data Mask area.
The VT shall provide a clearly visible separation between the individual Soft Key designators (for example by
drawing a one-pixel line). This visible separation shall be drawn outside of the Soft Key designator area. Only
if the minimum size of the designator field cannot be fulfilled due to this requirement, the drawing of a one-
pixel line on the border of the Soft Key designator area is acceptable.
The presentation of the Soft Keys can be further described in three groups, with a defined relationship:
Navigation Soft Keys < Number of Physical Soft Keys <= Number of Virtual Soft Keys.
a) VT Version 3 and prior VTs have no requirement on the number of physical Soft Keys.
b) VT Version 4 and later VTs shall provide at least 6 physical Soft Keys.
c) VT Version 3 and prior shall support a maximum of 64 virtual Soft Keys per Soft Key Mask and
shall support as a minimum the number of reported physical Soft Keys (see Clause 4.5.3.3).
d) VT Version 4 and later shall support exactly 64 virtual Soft Keys per Soft Key Mask (see Clause
4.5.3.3).
e) The VT shall provide a means for the operator to navigate and select all defined Soft Keys. For
example, if there are six physical keys, some type of paging would be required to allow the
operator to navigate to, and select from, any of the 64 virtual Soft Keys using the six physical
keys.
Physical Soft Keys is the count of the number of permanently dedicated keys that the VT makes available to
active Working Sets. The term “physical Soft Key” does not imply that the VT must provide physical buttons
for the Soft Keys. For example on a VT with touch screen, the physical Soft Keys may be located directly on
the touch screen as shown in Figure 1 — Virtual terminal — examples.
For VTs with a vertical arrangement of physical Soft Keys, key number 1 shall be on the right and the top-
most position. Key number 2 shall be adjacent and below Key 1. Key m shall be at the bottom of the first
column. If there are additional physical Soft Keys, the column containing keys m+1 to key n shall be to the left
of the first column. Each additional column of physical Soft Keys shall continue to the left.
For VTs with a horizontal arrangement of physical Soft Keys, Key number 1 shall be on the top row and in the
left-most position. Key number 2 shall be adjacent and to the right of Key 1. Key m shall be at the far right of
the top row. If there are additional physical Soft Keys, the row containing keys m+1 to key n shall be below the
first row. Each additional row of physical Soft Keys shall continue below the previous row. Examples of these
arrangements are shown in Figure 3 — Physical Soft Key Orientation Examples showing Key Locations.
For VTs without a clear horizontal or vertical arrangement of physical Soft Keys (e.g. physical Soft Keys
located in a matrix on the touch screen) the rules for a VT with a vertical arrangement of physical Soft Keys
apply.
Virtual Soft Keys is the count of the number of Soft Keys that the VT supports for each active Working Set’s
Data Mask. If the physical Soft Keys count is less than the virtual Soft Keys count, the VT shall provide a
means for navigation to allow the operator to choose from any of the Working Sets Soft Keys.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Navigation Soft Keys is the count of the number of physical Soft Keys that the VT may allocate for the purpose
of navigation among the Soft Keys. The number of navigation Soft Keys shall be less than the number of
physical Soft Keys. If the VT provides other means of navigation that does not use the physical Soft Keys, this
value shall be zero.
If the Working Set provides a number of Soft Keys on a Soft Key Mask equal to or less than the number of
physical Soft Keys reported by the VT, then all of the Soft Keys on this Soft Key Mask shall be accessible with
the physical Soft Keys. The VT shall not provide any navigation means for this Soft Key Mask.
If the Working Set provides more Soft Keys on a Soft Key Mask than the VT has reported in the number of
physical Soft Keys, the VT shall provide navigation for that Soft Key Mask. This navigation among the Soft
Keys shall be done by paging through the Soft Keys in groups, not by scrolling. Further, a “group” is defined
as the “physical Soft Keys” count minus the “navigation Soft Keys” count. The navigation Soft Keys shall
always occupy the same physical Soft Key positions on all pages, although the VT designer may choose to
disable (but not remove) the navigation keys on certain pages. The last set of virtual Soft Keys (depending on
how many Soft Keys the Working Set provided to the VT) may not completely fill the Soft Key Mask. The
remainder of the Soft Key designators shall not be used.
As described in section B.5 Soft Key Mask object and illustrated in Figure 4 — VT virtual Soft Key paging,
pointers to the NULL Object ID reserve a Soft Key position. Pointers to NULL Object ID that are at the end of
the list of Soft Keys shall not reserve a Soft Key position and shall not be considered for paging or navigation.
EXAMPLE As shown in Figure 4 — VT virtual Soft Key paging (a in figure), a VT is designed with 6 physical Soft
Keys, 64 virtual Soft Keys, and 1 (a in figure) navigation Soft Key. The Working Set provides 18 Soft Keys to the VT,
however there are 3 which are Pointers to the NULL Object ID. To support navigating among the Soft Keys the VT
designer alters Soft Key 6 into a “next Soft Key group” button. A navigation group is calculated as sets of 5 Soft Keys (a in
figure), starting with the first Soft Key. When the navigation key is pressed, the VT shows the next group of Soft Keys.
Another example (b in figure) shows a similar example with 2 navigation Soft Keys. Another example (c in figure) shows
an arrangement with two columns of keys and two navigation keys. If the VT provides dedicated navigation keys, the
number of navigation Soft Keys reported shall be zero (d in figure).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
4.6 Behaviour
4.6.1 Object pools
4.6.1.1 General
The operator interface definition for a device of one or more implements represented by either a single ECU or
a Working Set consists of a set of objects (hereafter referred to as the Working Set’s object pool ). These
objects are defined in detail in Annex B and Annex J. Each object contains all necessary attributes and child
object references for processing the object to completion. The Working Set assigns a unique Object ID to
each object in its object pool so that each object is uniquely addressable. Object IDs shall be unique within a
single Working Set’s object pool but may not be between different Working Sets.
The object pool is transferred to the VT at initialization by using the procedure described in Annex C. The VT
is intended to be capable of storing the object pools in a modifiable memory area. VTs may store multiple
pools of a Working Set, in non-volatile memory, if they have unique version labels. For example, multiple
pools that differ only by language. All objects shall be fully described before they are made active in a mask
on the display.
Object ID FFFF16 (6553510) is reserved for use as the “NULL” Object ID.
Objects listed in parent objects may also list child objects, thereby creating a tree hierarchy in the object pool.
Objects are always processed in the order listed in the parent object in a “depth-first” manner. In other words,
if a reference is made to an object that references other objects, the child references are processed to
completion before returning to the parent to continue processing.
VT version 5 and later VTs shall support a minimum hierarchy depth of 30 objects. For VT version 4 and prior
VTs, the requirement is unspecified.
The hierarchy depth is computed starting with the following objects; Data Mask object, Alarm Mask object, Window
Mask object, Soft Key Mask object, Key Group Objects, and increments by one to reach a child object. For the
child objects that have child objects the depth increments again. This process continues to the last child
object. For computing the hierarchy depth, the object to which a pointer object references is counted as a child
object.
The relationship from the Working Set object to either a Data Mask object or an Alarm Mask object, and the
relationship from those to a Soft Key Mask object are not included in the count.
The Object Pool supplied by a Working Set Master is associated with all members of that Working Set. This
allows object information from one CF or all the CFs that make up a Working Set to be collectively presented
as a common object pool. One CF shall be designated as the Working Set Master for each Working Set. As
coordinator of the communications of a Working Set, the Working Set Master shall secure the use of the VT
and provide the object pool definition. It shall also send Working Set messages that provide the NAMEs of the
members of said Working Set to the VT. This identifies the members of the Working Set and hence those CFs
which can communicate to the VT. Appropriate messages for defining a Working Set are given in ISO 11783-
7.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Once members of the Working Set have been identified and after the object pool has been loaded into the VT,
any member of the Working Set has the ability to provide data for objects and to change attributes in the
object pool during run-time.
The Working Set Master shall provide the initial object pool definition. Any data input by the operator into input
field objects is always transmitted to the Working Set Master.
The VT shall never have Working Set Members and shall not transmit the Working Set Master or Working Set
Member messages (See ISO 11783-7).
The handling of VT Response messages defined herein supersedes part ISO 11783-1 in reference to
responses being directed only to the Working Set Master. See Table 1 for — VT Response message behavior
to Working Set messaging.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
b
VT Version is reported in the Get Memory response message.
In configurations types 1 through 3, the Working Set Member has the responsibility to monitor all [destination
specific] VT to Working Set Master messages in order to pair its commands with responses. The Working Set
Master will receive unsolicited responses from the VT (which were originated by its members), and will not be
able to pair these with messages the master originated. The Working Set Members also will not be able to pair
the messages correctly when originating from another member or from the master.
In configuration type 4, all responses from the VT are directed to the originating nodes. Responses that are
communicated via Transport Protocol are now possible (e.g. Get Supported WideChars response). Further,
the Working Set Master no longer receives unsolicited response messages. Working Set Members no longer
have an obligation to monitor destination specific messages directed to another address.
In order to maintain backward compatibility, Working Sets shall not send higher version messages to a lower
version VT (e.g. a version 4 command sent to a version 2 VT). How a lower version VT would respond in such
a case should be considered unpredictable. For example some VT designs might respond with a NACK
message, others might ignore the message. In extreme cases this could cause a software crash or reset at
the VT.
Conversely, the VT shall not send higher version messages to a lower version Working Set (e.g. a version 4
event sent to a version 2 Working Set). How a lower version Working Set would respond in such a case
should be considered unpredictable. For example some Working Set designs might respond with a NACK
message, others might ignore the message. In extreme cases this could cause a software crash or reset at
the Working Set.
VT version 5 and higher VT’s and Working Sets shall support the VT Unsupported VT Function message, and
Unsupported VT Function message, respectively. With this message the VT and Working Set respond in a
predictable way. VTs and Working Sets, designed for VT version 4 and prior, may implement these
messages.
When more than one visually similar Working Set from the same manufacturer becomes part of a network,
these Working Sets should be uniquely identified to correlate each instance with a location. This shall be
accomplished using an Instance field of the NAME (e.g. 2 sprayers from the same manufacturer, or 2 or more
visually similar Auxiliary Input units).
For consistent system configuration, the Working Sets should be arranged with the lowest to highest instance
from left to right followed by front to rear followed by bottom to top.
The manufacturer shall provide the operator a means to establish a working configuration, using one or more
of the following methods or via some other means not specified here.
The operator can correctly locate the Working Set based on its instance with:
⎯ An indication on the label of the Working Set unit identifying its Instance,
⎯ By physical location, via a wire in the harness of the Working Set that automatically sets its instance in
increasing values left to right followed by front to rear followed by bottom to top.
The operator can set the Instance based on its location with:
When more than one visually similar Working Set exists on a network, the Working Set shall indicate its
working set number on its Working Set object. Additionally, the Working Set should indicate its working set
number on visible masks.
The displayed Working Set number shall be defined by the manufacturer. The Working Set number should be
related to the Function Instance, the Device Class Instance, and/or the ECU Instance, as defined by the
manufacturer (See ISO11783-5). Other factors defined by the manufacturer may also be used to ensure the
Working Set is uniquely identifiable. All visually similar equipment from the same manufacturer shall apply the
same relationship.
The VT(s):
⎯ Shall send the standard language, format and measurement units messages defined in ISO 11783-7,
hereafter “standard setups”. The Working Set object identifies the languages that the Working Set
supports. The VT shall provide a method for the operator to view the list of supported languages and to
select an item from the list. If no language has been entered by the operator (as would be the case in a
factory-new VT), the VT shall attempt to query the default language from the tractor ECU. Once the
operator has set the language, The VT’s language message always takes priority over the tractor ECU’s
language.
⎯ Shall also provide a method for the operator to select formats (Time, Date, etc.) and measurement units.
The VT shall report selected language, formats and measurement units at power up and any time there is
a change. These messages allow the Working Set to modify its object pool to the operator-selected
language (.e.g. by updating string fields, selecting units of measure, changing offsets and scales, etc.).
⎯ Shall store the standard setups in non-volatile storage and restore the values during initialization.
⎯ Shall respond to ISO11783-7 “Language Command” requests sent to the global address
⎯ Shall configure their standard setups according to the VT to which they are publishing the pool(s). This
can cause different standard setups to be published to different VTs. (e.g. auxiliary objects are published
to VT with Function instance 0 and the remainder of the pool to other VTs)
Shall use a proprietary method to select an appropriate (or default) setting if the Working Set does not
support the selected language, formats or units.
4.6.6 Initialization
Upon power-up or reinitialization, a specific sequence of events shall occur in order to ensure proper
initialization of the VT and Working Sets, as follows.
4.6.6.1 VT initialization
1) The VT shall complete the address claim procedure in accordance with ISO 11783-5 and shall also
send an address claim request to the global destination address (255).
2) The VT shall begin transmission of the VT Status message. In the case of a reset or recovery, the
VT shall ensure that greater than 3 seconds have elapsed between this initial VT Status message
and the previous VT Status message.
3) If language selection has not been entered by an operator, the VT shall attempt to request the default
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
4) The VT shall allow Working Sets to initialize and to load their object pools.
1) The Working Set, if equipped with Auxiliary Functions, shall clear any assignments in volatile memory.
2) The Working Set Master (and Working Set Members) shall complete the address claim procedure in
accordance with ISO 11783-5.
3) The Working Set Master shall wait until the VT begins transmission of the VT Status message.
4) The Working Set Master shall identify itself and its members to the VT using messages given in
ISO11783-7.
NOTE 1 The Working Set Master may send these messages for other purposes (e.g. Task controller
initialization).
NOTE 2 If the Working Set Master has a need to reconfigure the list of Working Set Members after the
initialization is complete, the Working Set Master shall send the Working Set Master and Working Set Members
messages. The Working Set Master may use this to add or remove members from the set. No Working Set
initialization is required.
5) The Working Set Master shall transmit the Working Set Maintenance message once with the ‘initiating
flag’ set to 1 (when designed for version 3 and later VTs).
If the VT had previously detected a shutdown and was transmitting the NACK in response to the
Working Set Maintenance message (See Clause 4.6.9 Connection management), there are two cases
where the VT shall stop transmitting the NACK:
I) In the case of a version 3 or later ECU, identified by Working Set Maintenance message;
Byte 3 < 255 and the initiating flag Byte 2 Bit 0 = 1.
II) In the case of a version 2 and prior ECUs, identified by Working Set Maintenance message;
Byte 2 = FF16, and the VT received a Working Set Master message since the prior
maintenance message.
6) The Working Set Master shall begin transmitting the Working Set Maintenance message with the
‘initiating flag’ set to 0 (when designed for version 3 and later VTs).
7) The Working Set Master may request the language and format messages from the VT (See ISO
11783-7) if it has not already received this message from the VT and the Working Set has
presentation that is language or unit specific.
8) The Working Set Master may query the VT as necessary to determine its capabilities. Based on the
VT’s responses, the Working Set Master shall adjust its object pool for scaling, available fonts,
supported colours, etc.
9) The Working Set Master may query the VT to determine if its object pool already exists in non-volatile
memory.
10) Object pool transfer shall commence and be completed. This can be done either by asking for the
object pool to be transferred from non-volatile memory (See Annex E) or by using the protocols
detailed in Annex C.
A Working Set Master shall have a means to perform a “Move to another VT” function on networks with
multiple VTs. This function shall allow movement of the Working Set to each of the available VTs in
sequence. For example, this function could be accomplished with a “Next VT” Soft Key or Button in the
user interface and/or in combination with the Identify VT message. The function behaves as follows:
1) “Move to another VT” is enabled if the Working Set Master detects more than one VT on the network.
I) Puts itself in a safe state, or prevents activation of this feature unless it is in a safe state.
II) Shall send the Delete Object Pool command to the VT and wait for the response.
III) Shall stop sending the Working Set Maintenance message to the VT.
V) The Working Set Master shall save the new VT as the preferred VT for a next power cycle. If
the preferred VT is not available within a certain time period after startup, the Working Set
Master may initialize connection to any other VT on the network. The Working Set may
provide a means for the operator to set the maximum wait time period or it may be obtained
from the boot time specification in the "Get Hardware response" message of the preferred VT.
4.6.7.1 General
In this context “System Shutdown“ is defined as the period of time when the Key Switch state indicates the
key is off and yet ECU Power remains on. Actuator Power may or may not remain on concurrent with ECU
Power (see ISO 11783-7).
18 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
When the Key Switch state indicates the key has been turned off, and while ECU Power has not been
terminated, it is expected that systems may transition to a shutdown state that is appropriate for that system.
In some devices, this may cause immediate termination of all network communications, where other devices
may request power to remain on for a more orderly shutdown. Others still may ignore the Key Switch state
and continue normal operation until power is interrupted.
The relevant PGNs defined in ISO 11783-7 for determining the Key Switch state is the Wheel-based speed
and distance (PGN 65096) and for requesting power maintenance is the Maintain power (PGN 65095).
4.6.7.2 VT behavior
The VT can expect that applications on the network may terminate communications without warning.
A recommended behavior of the VT is to monitor the Key Switch state and take the following actions as a
result of the transition from "Key switch not Off“ to "Key switch Off“.
1) The VT should disable unexpected shutdown detection logic to avoid unnecessary notification to the
operator as a result of one application shutting down immediately while another maintains the ECU
Power beyond the normal 3 second timeout (see Clause 4.6.9).
2) The VT should maintain services while "Key Switch Off“ and for a minimum of 2 seconds following
the last "Maintain ECU Power“ request from those ECUs which have object pools in the VT volatile
memory.
3) The VT should continue to monitor the Key Switch state and reinitialize if turned from "Key switch
Off“ to "Key switch not Off“, ensuring that if the VT Status message was discontinued, the standard
Initialization process is performed (see Clause 4.6.6).
NOTE VT version 3 and prior did not specify shutdown behavior, therefore, these VTs may
discontinue all communications with the network, including discontinuing the VT Status message.
Working Set behavior may vary significantly depending on the design of the specific set.
One variation of a Working Set design may not monitor the Key Switch state and may continue as normal until
power is lost.
A recommended behavior of a Working Set is to monitor the Key Switch state and take the following actions
as a result of the transition from "Key switch not Off“ to "Key switch Off“:
1) The Working Set may send a “Maintain Power“ message (see ISO11783-7) to inform the system of
the state of the Working Set, and optionally as the means to request power be maintained.
2) The Working Set may monitor the “Maximum time of tractor power“ parameter (see Wheel-based
speed and distance message in ISO11783-7) and use this information during any power
management processes it may execute.
3) The Working Set may send a Delete Object Pool command to the VT to eliminate the possibility of an
unexpected shutdown indication (see Clause 4.6.9).
4) The Working Set should not consider the lack of the VT Status message or other VT to ECU
messages as an unexpected shutdown of the VT, and therefore should not attempt a connection to
any other VT as may be available.
5) The Working Set should continue to monitor the Key Switch state and reinitialize if turned from "Key
switch Off“ to "Key switch not Off“. (See Clause 4.6.6).
In the initial object pool definition, each Working Set Master shall provide one, and only one, Working Set
object in order to define a descriptor, active mask and supported languages for the Working Set. The
descriptor may be graphical; text or both but shall fit inside the area defined by the VT for a Soft Key
designator. Any object or part of an object located outside of the Working Set descriptor shall be clipped. The
descriptor may be used by the VT any time the Working Set needs to be represented to the operator.
When a Working Set is “active”, it has exclusive input focus and is displayed on the VT display. When the
Working Set is "inactive", it may also be visible on the VT display but does not have input focus. The VT shall
provide some means to allow the operator to select the Working Set that is to be active. Only one Working Set
is active at any given time. The Working Set cannot force any of its masks to be visible when the Working Set
is not visible, and it cannot force its Working Set to be active when another Working Set is active. However, in
some cases, setting the active mask to an Alarm mask may make the Working Set visible, but that is not
guaranteed.
For VT version 4 and later, a VT may also display one or more Working Sets which are not active in addition
to the Active Working set. (See Figure 5 — Example VT which displays an active and an inactive Working Set
simultaneously). The VT uses the VT On User-Layout Hide/Show message to inform the inactive Working Set
to update its Data Mask and or Soft Key Mask when it is visible. If a Working Set responds with a NACK or
with a hidden state for the corresponding Data Mask or Soft Key Mask then the VT knows that the Working
Set does not support this feature. If the Working Set does not support this feature, the VT shall inform the
operator that the displayed information may not be updated. The VT may still display the inactive Working Set,
because the inactive Working Set may update its data. (See Clause 4.6.10 Updating the operator interface)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 Data Mask area of active Working Set 6 Data Mask area of inactive Working Set
2 Soft Key Mask area of active Working Set 7 Soft Key Mask area of inactive Working Set
3 Physical Screen 8 Soft Key Designator of inactive Working Set
4 Soft Key Designator of active Working Set 9 Physical Soft Key of inactive Working Set
5 Physical Soft Key of active Working Set
Figure 5 — Example VT which displays an active and an inactive Working Set simultaneously
Table 2 — Working Set state changes (VT Supports only Active Mask)
Working Set
VT Behavior
state change
1. Hide the Working Set’s currently active Data/Alarm Mask and associated Soft Key
Mask.
Active to Inactive
2. Send the VT Status message to the global address (255) to inform Working Sets
1
of the change.
1. Display the Working Set’s currently active Data/Alarm Mask and display the
associated Soft Key Mask.
Inactive to Active
2. Send the VT Status message to the global address (255) to inform Working Sets
1
of the change
1
When the state of a Working Set changes from inactive to active and this causes the state of another Working
Set to go from active to inactive, there shall be only one VT Status message (not two), which shall specify the
new active Working Set.
Table 3 — Working Set state changes (VT Supports Multiple Working Sets or Window Masks Visible
Simultaneously)
Working Set
VT behavior
state change
1. Remove visual indication that the Working Set is the active Working Set.
2. Send the VT Status message to the global address (255) to inform Working Sets
Active to Inactive and 1
of the change.
Visible
3. Send the VT On User-Layout Hide/Show message (state: Shown) to the Working
Set.
1. Display the Working Set’s currently active Data/Alarm Mask and display the
associated Soft Key Mask.
Hidden to Active 2. Visually indicate to the operator that the Working Set is the active Working Set.
3. Send the VT Status message to the global address (255) to inform Working Sets
1
of the change.
1. Hide the Working Set’s currently active Data/Alarm Mask and associated Soft Key
Mask.
Active to Hidden
2. Send the VT Status message to the global address (255) to inform Working Sets
1
of the change.
Inactive and Visible to 1. Send the VT On User-Layout Hide/Show message (state: Hidden) to the Working
Hidden Set.
Hidden to Inactive 1. Send the VT On User-Layout Hide/Show message (state: Shown) to the Working
and Visible Set.
1
When the state of a Working Set changes from inactive to active and this causes the state of another Working
Set to go from active to inactive, there shall be only one VT Status message (not two), which shall specify the
new active Working Set.
The Working Set can select different Data Masks or activate Alarm Masks by changing the active mask
attribute of the Working Set object with the Change Active Mask command. The Working Set can change the
active mask even if the Working Set is inactive. This allows the appropriate mask to be displayed when the
Working Set becomes visible. When a Working Set is inactive, its active mask may not be visible, but still
remains as the active mask for that Working Set.
The VT transmits the VT Status message once per second. The Working Set uses the message to ensure the
VT is present and to determine the current status of the VT. If a Working Set does not receive this message
for a period of 3 s it is determined to be a shutdown of the VT. When this happens the Working Set shall enter
a safe state. The safe state is defined as the state in which all functions dependant on the VT operator
interface are put into a known state that will not put the operator or machine at risk. The Working Set may re-
establish connection to the VT by restarting the initialization procedure.
22 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Each Working Set Master sends the Working Set Maintenance message once per second. The VT uses this
message to ensure that each Working Set is still present. If the VT does not receive this message for a period
of 3 s it is determined to be an unexpected shutdown of the Working Set Master (See Figure 6 — Initialization,
unexpected shutdown, and expected shutdown) and the following rules apply.
⎯ If the Working Set has commanded the VT to delete the object pool, and the Working Set then stops
sending Working Set Maintenance messages. This allows the Working Set to silently remove itself from
the VT.
⎯ If the VT can detect the ignition key state and the ignition key is reported as off.
⎯ If there is no pool loaded by the Working Set into the VT volatile memory.
⎯ If the pool has not been commanded to be deleted and the ignition key is not detected as off and the
Working Set’s object pool is present in the VT. This is detected as an unexpected shutdown of the
Working Set and the VT shall alert the operator to this condition after which the VT shall delete the
Working Set’s object pool from volatile memory to free the memory for other uses. The means to alert the
operator is proprietary to the VT. If the Working Set is visible to the operator, the display is cleared and
the VT may give control to another connected Working Set and send the VT Status message to the global
address. If there is an active alarm for the failed Working Set the VT deselects the Alarm Mask
automatically.
When a Working Set’s object pool has been deleted and there exists auxiliary assignments mapped to this
Working Set, the VT shall remove them.
When the VT receives a Working Set Maintenance message from a Working Set which has unexpectedly
shutdown, it shall NACK the message (See ISO 11783-3). The NACK message is sent to the Working Set
Master. The Working Set may re-establish connection to the VT by restarting the initialization procedure (See
Clause 4.6.6 Initialization).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
Solid arrows indicate destination specific messaging, dashed arrows indicate global message.
4.6.10.1 General
CAN has finite bandwidth available in support of all services (e.g. ISO 11783 part 3 through part 14). Further,
the VT has finite bandwidth that is shared by all Working Sets using its services. In order to best manage the
system bandwidth, it is recommended that:
⎯ Active Working Sets, or those that are inactive but visible, should issue commands to the VT only when
the data has changed in a way which is visible to the operator (e.g. only update objects actively
displayed).
⎯ Inactive Working Sets, which have no active Data Mask and Soft Key Mask displayed should reduce the
frequency of, or eliminate, updates to the VT.
Attributes of objects can be changed during operation by Working Set Masters and Working Set Members
using the defined change attribute messages. Certain attributes in each object are assigned an attribute ID.
The Change Attribute command allows any attribute with an AID to be changed if not designated as a read-
only attribute. In addition, attributes are sometimes grouped together into a single “change” command for
efficiency purposes. (e.g. Change Font Attributes command F.28)
Even when the associated Data Mask is not visible, the Working Set may continue to change the attributes
(including value) so that when the mask is made active and visible, the necessary output data is current and
ready to display.
Working Sets can replace objects at run-time; however the replaced objects shall be of the same type. New
objects can be added by initiating a transport protocol session to send one or more objects to the VT. When
the VT receives an object with an existing Object ID, the existing object is replaced (the VT can determine the
owner from the source address of the message). Resizing objects is permitted but can cause the VT to run out
of memory. (See Annex C)
The entire object pool can be deleted from the volatile memory in the VT by the Working Set sending a Delete
Object Pool command.
Figure 7 — Container reuse shows an example of container reuse. Mask 1 and Mask 2 both need the
information displayed in Container 1. The Working Set first creates the container, and then inserts the
container into Mask 1 and Mask 2 using the Object ID of the container.
Figure 8 — Container used to hide objects — Example a) shows an example of using a container to hide a
group of objects. In the example, Text 1 and Text 2 should be visible at all times. Text 3 and Text 4 should be
visible only if a particular feature of an implement is available. Therefore, the Working Set creates a container
containing Text 3 and Text 4 to be inserted in the mask. At run-time, the Working Set determines whether or
not the particular feature is available. If not, the Working Set hides the container (See b in Figure 8 —
Container used to hide objects — Example).
Key
a) Particular feature available b) Feature not available: container hidden
There are five types of attribute objects: font, line, fill, input, and extended input. Attribute objects are
referenced by other objects. This allows one set of attributes to be shared with many objects to create and
maintain a common look across those objects. All objects using a given attribute object are updated when the
attribute object is changed.
Variable objects can be used to share data between two or more other objects. Changing the value in only
one object can reduce bus traffic. For example, it could be desirable to draw a Meter object and also to show
its current value as a numeric under the meter. In this case, a Number Variable object could be referenced by
26 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
both the Meter object and the output field object. By doing this, a change in the value of the variable will be
reflected in both the meter and output field at the same time and the change will require only a single Change
Numeric Value command.
4.6.11.4 Macros
Macro objects are used to improve the performance of the operator interface.Macro objects have the following
properties:
b) If a Macro triggers an event that causes another Macro, the current Macro is completed first before
another is started.
d) Macros triggered by the execution of a command shall be completed before the next bus command is
started.
e) Macro Object IDs shall be in the range 0 to 255 for VT version 4 and prior. Macro Object IDs may be in
the range of 0 to 65534 for VT version 5 and later.
f) Macros do not trigger response messages. When executing the command messages in a macro, the VT
shall not send response messages on the CAN bus for the messages contained in the macro. Therefore
macros reduce CAN traffic. For example, a Macro that executes a Change Active Mask command will
trigger a VT Status message, but will not trigger a Change Active Mask response.
CAUTION: Objects that are altered by both a Working Set and a Macro may be susceptible to a race
condition and should be evaluated for predictable behavior.
EXAMPLE 1 An
Input String object of length greater than 3 characters causes the VT to send the data using Transport Protocol (TP) to the
Working Set (WS). The operator quickly navigates away from the
Input String object. "On Input Field Deselection" causes the VT to notify the WS with a VT Select Input Object message
(Deselect). An On Input Field Deselection Macro alters the
Input String object value. The WS receives the TP data asynchronous to the VT Select Input Object message (Deselect).
The outcome is based on the asynchronous processes in the VT, the message processing methods in the VT, including
TP processing and potential latencies, and the WS implementation.
EXAMPLE 2 An On Key Press Macro associated with a Button object changes the active Data Mask. An On Show
Macro attached to the new Data Mask changes the numeric value in an Input List object on this new Data Mask to initialize
it to a known setting. The operator presses the Button, which causes a Button Activation message to be sent to the WS.
The WS sends a Change Numeric Value command to the Input List object. The Input List object may end up with either
value, due to the asynchronous processes.
Circular references are not permitted since they create infinite Macro loops inside the VT and could render the
VT inoperable for all Working Sets.
EXAMPLE When a Macro triggers an event that references the same Macro, a circular reference is created.
The Object Pointer object allows run-time modification of included objects. By changing the value of the
Object Pointer object, a different object can be drawn at the same location. The type of object that the Object
Pointer is allowed to reference is limited and depends on the parent object. Refer to valid parent objects of the
Object Pointer for a list of objects that can be referenced. An Object Pointer can always point to another
Object Pointer. An Object Pointer can point to the NULL Object ID and in this case nothing shall be drawn.
When an Object Pointer is modified at run-time, resulting in an invalid object reference, the VT is not required
to detect this object pool error immediately but may delay error detection until the Data Mask object or Alarm
Mask object which contains the Object Pointer is activated. At activation of a data or Alarm Mask containing
the invalid object reference the VT sends the F.35 “Change Active Mask response” or H.14 “VT Change
Active Mask message” to inform the Working Set and may delete the object pool.
The VT may also detect the error immediately upon Object Pointer value modification, and in this case shall
send an F.23 Change Numeric Value response with “invalid value” indicated in the error codes. The VT may
also delete the object pool.
The External Object Pointer object allows a WS to display objects from an object pool of another WS.
To ensure that the external references are valid even after software updates of the participating WS, the
referenced WS and the referencing WS shall exchange information about the referenced objects before
enabling the external references. The information exchange shall be repeated every time either the
referencing WS or the referenced WS is restarted. As a minimum the object identifiers shall be transferred
from the referenced WS to the referencing WS.
Note: Some devices (e.g. the SCC/SCM – ISO11783-14) have a standardized method for exchanging object
information. If a standardized method does not exist, then a proprietary method shall be agreed between the
manufacturers of the referencing and the referenced WS.
To protect against unsolicited references the referenced WS shall use the External Object Definition object to
list the objects which are allowed to be referenced by another WS. The External Object Definition object is
assigned to one and only one referencing WS. If a referenced WS will allow multiple WS to reference objects
it shall have multiple External Object Definition objects.
The referencing WS shall use the External Reference NAME object to identify the WS it plans to reference.
The attribute values of the External Object Definition object, the External Object Pointer object and the
External Reference NAME object shall all be valid before the external object can be displayed. Some of the
information in the objects depends on the exchange of object information and therefore the objects shall be in
the reset state until the object information is complete.
⎯ External Object Pointer object : External Object Id attribute is the NULL object id
⎯ External Object Definition object : Enable bit in the Options attribute is cleared
⎯ External Reference NAME object : Enable bit in the Options attribute is cleared
When the object pool is loaded from non-volatile storage in the VT there is no guarantee that the attribute
values are valid, and therefore the VT shall set all occurrences of the External Object Pointer, the External
Object Definition and the External Reference NAME to the reset state.
28--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
When the object pool is uploaded from the WS master, the VT shall not set the objects to the reset state. If the
information exchange between the referenced and the referencing WS is not completed before the object pool
is uploaded, the WS master shall set the objects to the reset state before uploading the pool.
Before displaying an external object the VT shall check the validity of the external reference. The external
reference is considered to be valid when all of the following are fulfilled:
⎯ The External Reference NAME ID attribute of the External Object Pointer object identifies an enabled
External Reference NAME object.
⎯ The referenced WS has an object pool in volatile memory on the VT (referenced object pool).
⎯ The referenced object pool contains an enabled External Object Definition object where the NAME
attributes identifies the referencing WS.
⎯ External Object Id is listed in the object list in the above mentioned External Object Definition object.
If the referenced object is NULL or not valid the VT shall draw the object identified in the Default Object ID
attribute of the External Object Pointer object.
Note There can be multiple instances of the External Object Definition object in an object pool. If multiple
External Object Definition objects are assigned to the same NAME, then an external reference shall be
considered valid if made valid by one or more External Object Definition objects.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 VT presentation from Working Set 1
2 VT presentation from Working Set 2
3 External Object Pointer with reference to object in Working Set 2 Object Pool
4 Referenced object in Working Set 2 (container that contains several objects), all of which are valid
5 Number Variable on Working Set 2 object pool
6 External Object Pointer with reference to object in Working Set 2 Object Pool
7 Default Object to be shown when External Objects are invalid
8 VT presentation from Working Set 1 after references are established, enabled and resolved
Key
1 VT Object Pool volatile memory 3 Referenced Working Set ECU (ECU 3)
2 Referencing Working Set ECU (ECU 2) 31 Referenced Working Set in VT memory
21 Referencing Working Set in VT memory 32 External Object Definition object
22 External Reference NAME Object, including 33 Object Pool Object that can be referenced from an
NAME attribute that references ECU 2s external Working Set
23 External Object Pointer Object 34 Reference to the Object Pool object that can be
24 Reference to the External Reference NAME object referenced.
25 Virtual reference established by External Object Pointer 35 Virtual reference established that allows ECU 2 to
object that informs VT to the Working Set containing the reference ECU 3 objects
referenced objects
26 Virtual reference established to the External Object of
interest.
Example 1 Two External Object Definition objects have the same value in the NAME attributes. Both objects
are enabled, only one of the objects includes 1234 in the Object ID list. Object Id 1234 can be referenced.
Example 2 Two External Object Definition objects have the same value in the NAME attributes. Both objects
include 1234 in the Object ID list, only one of the objects is enabled. Object Id 1234 can be referenced.
The X, Y position attribute determines where an object is drawn on the display. This position is always relative
to the upper left corner of the parent object. The X,Y position is always found in the parent object. Figure 11 —
Relative and absolute location of objects shows an example Data Mask with the relative locations of several
objects.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 Data Mask 3 Input Field
a
2 Container Absolute
A mask can be built such that two objects will occupy the same or overlapping space on the display. This can
require extra processing in the VT, but could be necessary in some cases and shall be supported by the VT.
For this reason, the hierarchy or layering of objects shall be understood. Some objects have a list of contained
objects. Objects listed first are considered to be lower in the hierarchy than objects listed later. In this case,
the objects shall by drawn such that objects listed later appear to overlay objects listed earlier, so that the
entire image of the object listed last is visible, while only those areas of the object listed earlier that do not
coincide with areas of the object listed last will be visible. When an object is changed, all objects that overlay it
and which have been corrupted shall be redrawn (this is called a refresh event). All objects defined by this part
of ISO 11783 have a rectangular size either defined or implied to simplify the VT’s task of finding overlaid
objects.
When an object is changed or hidden, the VT shall update the display accordingly.
EXAMPLE Referring to Figure 12 — Object changed or hidden — Display update, where (a) shows the initial
presentation before any command is received. The Working Set then commands object 1 to be hidden. As an intermediate
step shown in (b), the VT deletes object 1 and all child objects by filling the object’s area with the background colour of the
parent mask. The VT then redraws the object along with all child objects. The VT then refreshes any other object (e.g.
object 2) that could have been visually altered in the deletion process as shown in (c). The VT may implement this refresh
in a manner where the intermediate display is never seen by the operator.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved 31
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Key
a) Initial presentation c) Final presentation
b) Intermediate operation
Alarms allow a Working Set to display alarm information at any time. If several Working Sets have an Alarm
Mask activated, the VT shall display the masks in order of priority. Priority is determined, first, by the priority
attribute defined in the Alarm Mask object and, second, by chronological order of activation. The highest
priority alarm is always displayed until the owner Working Set changes the active mask. When more than one
Working Set has asserted an Alarm Mask with the same priority attribute, the first of these, as processed by
the VT, shall become the active mask. When the active Working Set changes to a lower priority alarm or Data
Mask, the next in turn highest priority Alarm Mask is processed.
Operator input disturbed by the activation of an Alarm Mask may be left intact for resumption once all Alarm
Masks have been acknowledged. A Soft Key Mask is associated with the Alarm Mask via an attribute in the
Alarm Mask object. Whenever the alarm is displayed, the associated Soft Key Mask is also displayed. The
following describes the protocol requirements between the VT and the Working Set raising the alarm.
a) The Working Set Master activates an Alarm Mask by using the Change Active Mask command on the
Working Set object. Only one Alarm Mask can be active per Working Set.
c) Based on priorities, at some point, the VT displays the Alarm Mask and the Soft Key Mask associated with
the Alarm Mask. When a mask change occurs that causes an Alarm Mask to appear or reappear, the
acoustic signal associated with the Alarm Mask shall be activated. The VT shall terminate any acoustic
signal from a lower priority Alarm Mask that can be in process. The VT shall terminate any acoustic signal
from a control audio command that can be in process (version 4 and later VTs shall send the VT Control
Audio Signal Termination message to indicate the termination). If the Alarm Mask acoustic signal
completes, or if it is set to none for silent signal, then control audio commands from ECUs shall be
accepted as defined in the Control Audio Signal command. (See Table 2 — Working Set state changes
(VT Supports only Active Mask) and Table 3 — Working Set state changes (VT Supports Multiple Working
Sets or Window Masks Visible Simultaneously))
d) The VT notifies the Working Set with a VT Status message sent to the global address.
e) At some point the operator may acknowledge the alarm with the proprietary ACK means on the VT. The
VT sends a Soft Key Activation message to the Working Set with key code set to zero (0) based on the
32
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
operator action (See Clause 4.6.18). Alternately, the Working Set may deassert the Alarm Mask based on
its internal logic.
f) The Working Set may choose to ignore the ACK means if the ACK is not allowed or the Working Set may
change the active mask to either an Alarm Mask or a Data Mask by using the Change Active Mask
command on the Working Set.
Working Set’s
active mask Is requester the
attribute Current active VT behaviour
Working Set?
From/To
Data to data Yes Hide current Data Mask, show new Data Mask.
Data to data No If the VT design supports only one visible Data Mask, then no visual change.
If the VT design supports multiple visible Data Masks and this Working Set is
currently visible, then hide the current Data Mask, show new Data Mask.
Data to alarm Yes Hide Data Mask, show Alarm Mask.
Data to alarm No If this is the highest priority alarm, deactivate the current Working Set and
activate this Working Set.
Alarm to alarm Yes If this is the highest priority alarm, hide current Alarm Mask, show new Alarm
Mask.
Otherwise, deactivate this Working Set and activate the Working Set of the
highest priority alarm.
Alarm to alarm No If this is the highest priority alarm, deactivate the current Working Set and
activate this Working Set.
Alarm to data Yes If an alarm exists in another Working Set, deactivate this Working Set and
activate the Working Set with the highest priority alarm.
Otherwise, if this Working Set had the last visible Data Mask, hide the Alarm
Mask and show the Data Mask.
Otherwise, deactivate this Working Set and activate the Working Set which
had the last visible Data Mask.
Alarm to data No No visual change.
4.6.15 Clipping
Most objects defined in this part of ISO 11783 have a given or implied size. The VT shall clip anything drawn
outside the defined size of the object. Clipping is always done on a graphical (i.e. pixel) basis.
These clipping rules also apply to text and numeric objects. When the text does not completely fit inside the
defined object area, in both wrapping and non-wrapping cases, the graphical clipping rules apply and the
presentation is clipped on a graphical (i.e. pixel) basis. (See Figure 13)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
4.6.16 Scaling
4.6.16.1 General
The Working Set shall determine the size of the VT’s Data Mask area and Soft Key designator and make
appropriate adjustments to its object definitions. These adjustments may be applied either before or after
transmission of its object pool to the VT, as long as the transmitted pool is not invalid for the VT (e.g. cannot
transmit colour objects to a black and white VT and then change object to black and white). This gives
complete control of the appearance of the masks to the Working Set.
The Working Set shall scale positions and object sizes to adapt to the VT’s Data Mask area and Soft Key
designator(s).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
4.6.16.3 Fonts
The Working Set shall apply a best-fit algorithm to determine and select the best font for the defined area. The
Working Set shall also ensure that the VT supports the selected fonts and font styles. The smallest font size is
6 × 8. If the scaled height and width of the original font is less than 6 × 8, the 6 × 8 font shall be used. This
could result in clipping if the text is near the edge of the field object, or in text overlap if two occurrences of text
are too close together after scaling the object size independently of the font size. Working Set designers shall
be aware of this limitation and shall take the necessary steps. (See Clauses 4.6.19.3 Non-proportional fonts,
and 4.6.19.4 Proportional fonts)
Bitmap graphics are automatically scaled by the VT according to the width attribute in the Picture Graphic
object.
Whenever the VT displays a Data Mask that contains one or more enabled visible input objects or Buttons, it
can be in one of the following states:
a) Navigating
b) Data input
When determining the visibility of an input object, the object shall be considered visible even under the
following conditions:
⎯ the object is wholly outside the clipping limits of the parent object hierarchy as defined by the width and
height attributes of all the parents in the hierarchy
Objects with width or height of zero, and objects that are wholly outside the clipping limits of the parent object
hierarchy are discouraged as activation may not be possible (e.g. touch screen). The Working Set designer
may consider enabling and disabling these objects as needed so the Working Set navigation is more
predictable in operation.
When a new active data-mask is selected the state is reset to ‘Navigating’. If an Alarm Mask is selected then
the VT may remember the state and if the Working Set returns to the same data-mask after showing the
alarms then the state can be restored. If this approach is implemented and the ECU returns to a different Data
Mask after showing alarms, the VT shall consider it as a normal Data Mask change and send the appropriate
messages. (See Table 5 — VT Reaction to navigation and data input events)
The initial focus point, if any, and the tab order for navigating to the various input fields or buttons is VT
proprietary, but the ECU shall be aware that the tab order may be defined by the definition order of the input
objects in the parent object.
The VT may choose not to send the VT Select Input Object message for every object that the operator passes
through while navigating. E.g. if the navigation means is a rotary control, the focus will change rapidly while
the operator is spinning the control. In such a case the VT may choose only to send the VT Select Input
Object message to the input object which loses focus and the one which eventually gets focus.
In the ‘Navigating’ state the VT shall indicate to the operator which (if any) input is selected (has focus). The
method of indication is proprietary to the VT. The VT may open an input object for data input as soon as the
object gets focus, and it may remove focus when input is done. This is common, but not required, behaviour
for touch screens.
Examples of focus-indicators include (but is not limited to) adding a frame around the input field, changing the
background colour of the input field, or momentarily highlighting the input field on a touch screen VT.
The VT designer should be aware that the use of the Select Input Object command by the Working Set can be
a means by which the Working Set designer intends to focus the operator attention to an input field (e.g. a
setup wizard where the recommended action is highlighted).
The VT shall indicate the disabled input objects. The means to represent disabled input objects is VT
proprietary. Visual changes to disabled objects to indicate the disabled state shall not extend beyond the
width/height of the object and the object shall remain legible.
Working Sets may apply a frame around, or distinct background colour to, input objects as an aid to the
operator in identifying input fields.
In the ‘data input’ state the VT behaviour is proprietary, and the VT may cover part or all of the Data Mask
while the object is open for data input. Changes to the attributes of an input object during the data input
process shall not affect the value currently being input (e.g. changes to an Input Number Scale shall not alter
the apparent value being input ).
The VT reacts to navigation related events. (See Table 5 — VT Reaction to navigation and data input events)
35
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
36 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Whenever a Key object or Button object or ACK key is pressed, released, or latched, the VT sends a Soft Key
Activation message or Button Activation message to the working Set Master. If a Macro is associated with the
key press, the VT executes it. Performance of the operator interface can be improved by associating a Macro
with the key press event to cause another event, such as activating a different mask. See Table B.11 — Key
events and Table B.13 — Button events.
Note For VT version 5 and later, the ACK key shall send messages (pressed, held, released) consistent with Key
and Button objects. In VT version 4 and prior, this was not well defined and led to variations in implementation.
If a Key object or non latchable Button object is erased from the screen (e.g. due to a Change Active Mask
command, Change Soft Key Mask command, Hide/Show Object command, etc) while it is activated, the VT
shall send a Soft Key Activation message or Button Activation message indicating released to the erased
object on its parent Data Mask. The VT shall then ignore the physical key until the operator has released it. If
a Button object is moved to a new location on the active mask, while it is still pressed, the behavior depends
on the method of activation. If the Button object was activated by a physical key, then the Button object stays
pressed. If the Button object was activated by touch screen, pointing device or similar, and the object is
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
moved to a location that is no longer under the touch point, the VT shall send a Button Activation message
indicating released and shall then ignore the touch until the operator physically releases.
For example, when changing the visible Data Mask, the VT shall send the Soft Key Activation message
indicating released for the activated object for the previous mask. It shall not send a Soft Key Activation
message for the new mask.
When the “VT supports simultaneous activation of all combinations of Physical Soft Keys” bit (See Clause D.9
Get Hardware response) is zero, the VT shall only support the activation of a single Soft Key at a time and
only in the prescribed sequence of <no Keys pressed> : <Key pressed> : [<Key held>] : <Key released> : <no
Keys pressed>. If a second Soft Key is pressed while a first Soft Key has already been detected as
pressed/held, it shall be ignored. When simultaneous activation is supported, the VT sends overlapping
messages (e.g. <no Keys pressed> : <Key 1 pressed> : [<Key 1 held>] : <Key 2 pressed> : <Key 1 released>
: <Key 2 released> : <no Keys pressed>).
When the “VT supports simultaneous activation of all combinations of Buttons” bit (See Clause D.9 Get
Hardware response) is zero, the VT shall only support the activation of a single Button at a time and only in
the prescribed sequence of <no Buttons pressed> : <Button pressed> : [<Button held>] : <Button released> :
<no Button pressed>. If a second Button is pressed while a first Button has already been detected as
pressed/held, it shall be ignored. When simultaneous activation is supported, the VT sends overlapping
messages (e.g. <no Buttons pressed> : <Button 1 pressed> : [<Button 1 held>] : <Button 2 pressed> :
<Button 1 released> : <Button 2 released> : <no Buttons pressed>).
If a Key or Button is found to be pressed at power on, it shall not be reported as held; however this can be
cause for VT to report a diagnostic message to the operator.
4.6.19.1 General
Text based objects have a justification attribute. Field justification indicates how a text string is positioned
horizontally and vertically within the field defined by the width and height attributes. In version 3 and prior VTs,
text justification was done on a character basis but was not precisely defined. In version 4 and later VTs, text
justification is always done on a graphical (i.e. pixel) basis.
The extents of a text character (See Figure 14) shall be graphically justified as described in the following
sections but some white space is permissible if the VT’s font rendering engine reserves space for ascenders
and descenders or for the character itself.
38 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Key
1 Graphical extents of the character.
2 Ascender area may create white space depending on VT design
3 Character rendering itself may create white space depending on VT design
4 Descender area may create white space depending on VT design
During data input of a text based object, the VT designer may choose to suppress justification until the field is
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
NOTE These modifications shall be done for visual justification – the stored value is not modified.
When left justified, the VT shall not remove any leading spaces and the first character in the string is
positioned and visible at the left side of the text field area. If auto-wrapping is enabled, the rules of auto-
wrapping overrule and leading spaces on subsequent lines are trimmed before justification. If the string does
not fit in the defined text field area, and auto-wrapping is not enabled, the string shall be graphically clipped on
the right side. If auto-wrapping, justification rules apply to each new line. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area.
EXAMPLE 2 Left justification, no auto-wrap, one leading space, " Left Justified"
EXAMPLE 3 Left justification, no auto-wrap, clipping on the right, "Left Justified Text"
When middle justified, the VT shall remove all leading and trailing spaces before justifying the string. The
string shall be centered in the text field on a pixel basis. If the string does not fit in the defined text field area,
and auto-wrapping is not enabled, the string shall be graphically clipped on the left and right sides. If auto-
wrapping, justification rules apply to each new line. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area.
EXAMPLE 2 Middle justification, no auto-wrap, five leading and one trailing space (leading and trailing spaces are
removed) , " Middle Justified "
EXAMPLE 3 Middle justification, no auto-wrap, clipping on the left and right, "Middle Justified"
EXAMPLE 4 Middle justification, auto-wrap, no leading or trailing spaces, "This is middle justified, wrapped text!"
EXAMPLE 5 Middle justification, auto-wrap, one leading and one trailing space (leading and trailing spaces are
removed), " This is middle justified, wrapped text! "
When right justified, the VT shall remove any trailing spaces before justification and the last character in the
string is positioned and visible at the right side of the text field area. If the string does not fit in the defined text
field area, and auto-wrapping is not enabled, the string shall be graphically clipped on the left side. If auto-
wrapping, justification rules apply to each new line. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area.
EXAMPLE 2 Right justification, no auto-wrap, one trailing space (space is removed) , "Right Justified "
EXAMPLE 3 Right justification, no auto-wrap, clipping on the left, "Right Justified Text"
EXAMPLE 4 Right justification, auto-wrap, no trailing spaces, "This is right justified, wrapped text"
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
EXAMPLE 5 Right justification, auto-wrap, one trailing space (space is removed) , "This is right justified, wrapped text
"
Vertical top justification is available in VT version 4 and later. When vertical top justification is enabled, the VT
shall display the text string starting at the extreme top of the defined text field area. This rule applies
regardless of the auto-wrapping attribute. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area and in all examples the
text is also left justified.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
EXAMPLE 3 Top justification, auto-wrap, "Vertically<CR><CR>Top Justified Text"
Vertical middle justification is available in VT version 4 and later. When vertical middle justification is enabled,
the VT shall display the text string graphically centered vertically in the defined text field area. This rule applies
regardless of the auto-wrapping attribute. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area and in all examples the
text is also left justified.
Vertical bottom justification is available in VT version 4 and later. When vertical bottom justification is enabled,
the VT shall display the text string with the bottom edge of the text block along the bottom edge of the defined
text field area. This rule applies regardless of the auto-wrapping attribute. Blank lines are not removed.
In the examples below, the box represents the extents of the defined text field area and in all examples the
text is also left justified.
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
The VT shall support non-proportional block fonts. Sizes are always given in X-Y pairs. For example, 8 × 10
indicates a character size of 8 pixels wide by 10 pixels high. Characters shall not exceed the size of the box
defined by the font size, regardless of style. For example, an 8 × 10 font set to bold and italics shall still fit
inside the 8 × 10 pixel area. It is suggested that space be left on the bottom and right sides on the inside of the
box to accommodate characters placed side by side or row by row. (See Figure 15 — 8 × 10 fonts —
Example)
Dimensions in pixels
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 bold 3 bold italic
2 normal (upright)
The VT designer may choose the font sizes and styles to be made available but the default 6 × 8 font, normal
(upright) style, is a minimum requirement. The Get Text Font Data message can be used by a Working Set to
determine the VT’s font capabilities. Characters can be rendered transparent (background shows through) or
opaque (solid background colour) depending on the options attribute of the applicable object.
In version 4 and later VTs, as an option, the VT design may allow for proportional font rendering. In this case
the width of each character is variable and the height attribute is fully scalable in the range from 8 pixels up to
and including the largest supported font height as identified in D.7 Get Text Font Data response. As a result,
only the height attribute of the font size applies and the width attribute is ignored. Therefore, the rendered
characters shall not exceed the height of the chosen font size.
For example, if the VT responds to a Get Text Font Data message with Byte 6 = 1016, and Byte 7 = 0216, then
the largest reported non-proportional font size is 48 pixels wide by 64 pixels in height. If the VT has indicated
support for proportional font rendering (Byte 8 bit 7 = 1), then the VT supports a proportional font height from 8
up to and including the value 64, in 1 pixel resolution. Due to characteristics of the implemented font rendering
engine, and the shape of the characters, 1 pixel resolution may not be detectable for every character, even
though it is supported.
Normal clipping rules still apply and Working Set designers have to be aware of the variable nature of the font
width and therefore assign sufficient width to the text field. Implements can query the VT’s font capabilities,
including the support of proportional font rendering, via the Get Text Font Data message and may choose the
proportional rendering option in the font style attribute of the Font Attributes object. If the implement requests
a proportional font rendering and the VT does not support this option, the VT shall respond in one of two
ways:
⎯ if a Font Attributes object indicates proportional font during the validation of an object pool, the object pool
shall be rejected
⎯ if a Change Font Attributes command is received with invalid size and/or font type, a Change Font
Attributes response shall be sent indicating an error in the size and/or type
The following general rules apply for the support of Proportional font rendering:
⎯ a VT that indicates support for proportional fonts shall support the full height scaling range of 8 to the
largest supported font size as identified in Get Text Font Data response. Character width is recognized to
be variable.
Before using proportional fonts, Working Sets shall query the VT to determine if proportional font rendering is
supported by the VT. If not supported, only non-proportional fonts shall be used in the pool upload and
subsequent Change Font Attributes commands.
4.6.19.5 Auto-wrap
If the amount of text to display is longer than the width of the text object, and auto-wrap is enabled, then
regardless of non-proportional or proportional rendering, the VT shall format and wrap the text into the next
line(s). The text shall not exceed the boundaries defined by the width of the text object. Wrapping shall occur
under these conditions:
VT version 3 and prior allowed CR, LF, and BS control characters in strings. The rendered presentation was
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
⎯ BS (Back Space) is ignored as are other characters denoted with scissors in Annex L.
⎯ Single CR (Carriage Return) is interpreted as a line end
⎯ Single LF (Line Feed) is interpreted as a line end
Other non-displayable characters shall not advance the cursor during drawing or alignment decision making.
The VT can remove these characters from the string to facilitate more efficient processing.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
VT Presentation
String Data
Left Alignment Middle Alignment Right Alignment
String 1:
ABCDEFCRGHIJKL ABCDEF ABCDEF ABCDEF
or GHIJKL GHIJKL GHIJKL
ABCDEFLFGHIJKL
or
ABCDEFCRLFGHIJKL
NOTE: “¶” shown for examples and would not be visible on the VT
Text strings can be encoded with either 8-bit characters (chars) or Unicode/ISO10646 characters
(WideChars).
VT Version 3 and prior supported Font types are shown in “Table L.1 — ISO 8859-1 (Latin 1) character set”
and “Table L.2 — ISO 8859-15 (Latin 9) character set”.
VT Version 4 and later supported Font types are shown in “Table L.1 — ISO 8859-1 (Latin 1) character set”
through “Table L.6 — ISO 8859-7 (Greek) character set” and “Table L.7 — WideString minimum character
set”.
The character set is indicated by the Font type attribute of the Font Attributes object.
WideStrings shall be encoded according to UTF-16 (Unicode Transformation Format - 16 bit) and therefore
they always start with the Byte Order Mark (BOM) character FEFF16. BOM is not a displayable character and
is not considered part of the text string.
UTF-16 allows both big- and little-endian encoding, but WideStrings in ISO11783-6 shall always be encoded
as little-endian.
If the first two bytes are FF16, FE16 it is a WideString, otherwise it is an 8-bit string.
The length attribute of an object or message always indicates the number of bytes in the text string, therefore
the number of characters in a WideString shall be found as:
If the length attribute does not indicate an even number of bytes the last byte is ignored.
The VT may support any character defined by Unicode/ISO10646, but as a minimum it shall support the
characters listed in Table L.7 — WideString minimum character set.
The Font type attribute of the Font Attributes object is ignored for WideStrings.
The VT shall display WideStrings even if the WideStrings contain characters which are not supported by the
VT.
The VT shall substitute unsupported characters by a displayable character. The displayable character may be
VT proprietary (e.g. ‘□’).
The encoding of
Input String object values shall not be changed by the VT, i.e. if an
Input String object contains (or references) a WideString, the VT Change String Value message sent by the
VT shall also contain a WideString.
Characters above FFFF16 are represented by a 32 bit ‘surrogate pair’, which consists of a high surrogate
followed by a low surrogate.
a) S = character - 1000016
The highest character defined by Unicode and ISO10646 is 10FFFF16, corresponding to the surrogate pair
DBFF16, DFFF16.
It is in the intent of this standard to enable interoperability among equipment from different manufacturers, and
to do so in a manner that successfully conveys the original design accurately enough for proper interpretation
by the operator.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Many of the VT objects in this standard do not have all elements of their presentation explicitly defined. The
implementation chosen by the developer may be one that favors computing performance, visual style, or other
factors that are outside the definitions in this standard. The Output Meter object is an example where the
developer defines some elements of the presentation. For example, even though the bounding width, height,
and values are clearly defined, the developer can define the size and shape of the needle. Other examples
include the Output Linear Bar Graph object (e.g. fill, set point mark, tic mark size and position), and Output
Line objects not conforming to a strict 0, 45, or 90-degree orientation. Drawing algorithms as may be used to
render these types of objects can produce similar but varying results (e.g. two diagonal lines drawn with
slightly different line drawing algorithms). Pixel level accuracy in this case may not be possible. Where pixel
level accuracy is required, the designer should consider a Picture Graphic object, while also ensuring that the
VT does not scale this object (e.g. the Width attribute is equal to the Actual width attribute).
When solid-filling output shape objects on the VT, flood-fill or boundary-fill type algorithms are not suitable,
since objects can be overlaid and interrupt the fill. There are also performance problems with this type of
approach. Scan-line type fills shall be implemented. In addition, only the interior area of the object, not
including any pixel that is/would be part of the border, shall be included in the fill. Incorrect filling would be
particularly visible when line art is used on the border or when the border is completely or partially suppressed
(i.e. rectangles).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
NOTE All rectangles width = 10, height = 8, line width = 2, filltype = solid grey
a
rectangle width = 10, height = 8, line width = 2, filltype = solid grey, line art 1010 ..
b
rectangle width = 10, height = 8, line width = 1, filltype = solid grey, line art 1010 ..
Pattern fills of Output Shape objects shall be done according to the following rules:
⎯ The pattern shall be a Picture Graphic object whose width is integer divisible by 8. The raw data is used
for the pattern and the object is not scaled regardless of the attributes of the object.
⎯ The upper left corner of the pattern buffer is anchored to the upper left corner of the VT’s physical Data
Mask, individual designator, or user-layout window mask and repeats across and also down. This rule
ensures that the pattern matches between objects in the Data Mask Area and that the pattern fill looks the
same on all VT designs.
⎯ Transparency and flashing option attributes shall be ignored for fill patterns.
Filling and line suppression examples are shown in Figure 17 — Rectangle line suppression and filling
examples to Figure 19 — Polygon filling examples (Without and with border line art).
Figure 18 — Ellipse filling examples (Without and with border line art)
Figure 19 — Polygon filling examples (Without and with border line art)
4.6.22 Events
4.6.22.1 General
Manipulation of objects in an object pool by a Working Set or by the VT causes certain events to occur.
Events can be caused by commands or by VT actions in response to a command or by other events. Many
objects defined by this part of ISO 11783 have an optional list of event and Macro groupings.
If the occurring event has one or more Macros associated with it, the Macro or set of Macros is executed by
the VT when the command has been accepted by the VT as a valid command. Macros are executed in the
order they are encountered in the event/Macro list. Using events and Macros can make the VT operator
interface more responsive, since the Working Set Master does not need to be directly involved in responding
to the event.
EXAMPLE 1 A Soft Key press event could cause an appropriate Data Mask to be made active.
EXAMPLE 2 A Soft Key press event could cause two separate Macros to execute, one to make a new Data Mask
active and one to control the audio signal.
EXAMPLE 3 A Change Numeric Value command with an invalid value causes rejection of the command and an
associated Macro is not executed. A Change Numeric Value command with a valid value, even if the value is the same as
already in the value field, will cause the associated Macro to execute.
EXAMPLE 4 A container with an On Hide Macro is already hidden. A Hide Show command with the parameter set to
hide the container is valid and will cause the associated Macro to execute.
NOTE The same event id may be listed more than once in the event/Macro list of any given object.
Version 4 and prior VTs provide 2 bytes for each event and Macro grouping within the object definition. This
means one byte for the Event ID and one byte for the Macro ID, limiting the Object IDs for Macro objects to
the range of 0 to 255.
Version 5 and later VTs, in addition to the 8-bit Macro Object IDs, shall support Macros with an Object ID in
the range of 0 to 65534, requiring the use of 16-bit Object IDs for Macros. To maintain backwards
compatibility, Macro references within objects are based on the same structure with 2 bytes per grouping, but
two of these groupings are used to reference a macro with 16-bit Object ID. An Event ID of 255 in the first byte
of the Macro reference indicates that two groupings shall be concatenated to a single grouping with a 16-bit
Macro Object ID reference.
EXAMPLE A Container object references a Macro with 8-bit Object ID 710 (0716) that shall be executed when the
container is hidden. The event and Macro grouping within the definition of the Container object is as follows:
EXAMPLE A Container object references a Macro with 16-bit Object ID 700010 (1B5816) that shall be executed when
the container is hidden. The event and Macro grouping within the definition of the Container object is as follows:
The VT design can optionally support a touch screen or a pointing method such as a mouse or joystick. The
Working Set can determine the VT’s capabilities in this regard by using a Get Hardware message and then
make necessary adjustments to its object pool. A Button object is defined to allow touchable or clickable
buttons to be included in a Data Mask. A Pointing Event message is defined to allow the VT to notify the
active Working Set that an area of the Data Mask (or Alarm Mask) not associated with a button or other input
object has been touched or clicked on.
There are various proprietary means supported by the VT (Proprietary Objects, Proprietary Events,
Proprietary Colours, Proprietary Commands, and Proprietary Fonts). Use of these proprietary means where
the Working Set is provided by a different manufacturer than that which provides the VT is not recommended
in order to provide maximum ISO compatibility. As these items are proprietary, the Working Set or VT
manufacturer may change their proprietary means without disclosure.
Further, and in the context of the Proprietary Objects, it is not possible to parse an object for which the
definition is not known, and attempting to do so may cause the VT to reject the pool.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Additionally, Working Sets and VTs may exchange, and support, higher version messages and objects without
violating this standard as long as those features do not contradict the requirements defined for the lower
version (e.g. a version 2 VT may support Font type 5 – Cyrillic, even though not part of the standard until
version 4). Even as this mechanism leverages the standard, it shall be considered a proprietary means as it is
not defined in the lower version. Therefore, a proprietary means is required to determine if the connected VT
or Working Set supports the newer features, and the ECU should not assume that the new features are
supported to avoid undefined behavior.
4.6.25 VT Number
By default, VT’s shall be factory set to function instance zero (0), but will retain the function instance as
configured by the operator. A mechanism is required in order to conveniently resolve conflicts in the case
where there are multiple VT’s with the same function instance and in the case where there is no VT with
function instance zero. The VT shall be responsible for providing a proprietary means for setting the function
instance from the display itself. This means shall ensure that duplicate function instances between VT’s are
not created. The new function instance shall not be used until a re-initialization of the VT is performed (see
clause 4.6.6). The VT with function instance zero (0) is defined as the “primary VT”.
The proprietary means to set the function instance shall represent to the operator a VT Number (See Clause 3
Terms and definitions). In this way, VTs from all manufacturers will present a consistent numbering scheme
for the operator to choose the primary (and secondary) VT(s). To facilitate easy VT identification, the Identify
VT message may be used.
All VT to ECU and ECU to VT messages that are not explicitly defined to contain exactly 8 data bytes shall be
padded to the 8 byte boundary with FF16.
4.7.1 General
Clause 4.7 and all subordinate clauses apply to VT version 4 and later.
The VT may provide a means where data from multiple Working Sets can be made available on one screen.
Depending upon the VT design, it is also possible that data from multiple Working Sets can be made available
simultaneous to the VTs standard Data Mask and Soft Key Mask. See example in Figure 20.
Key
1 Key Group Objects in non-VT area (shaded regions indicate independent Key Groups)
2 Window Mask Objects in non-VT area
3 VT area (presenting standard VT screen or User-Layout Data Mask and User-Layout Soft Key Mask)
This is an optional feature. However, as a minimum, the VT shall be required to parse the Window Mask and
Key Group objects even if not supported. This allows Working Sets to upload these objects to all version 4
and later VTs without modification of the object pool. If this feature is supported, the VT shall support the 'free
form' (type 0) window mask type of the Window Mask object as a minimum. Any number of the other non-zero
window mask types may also be supported as desired. Working Set designs may desire the use of any of the
window mask types so implementation, by the VT design, of all window mask types is encouraged. If the
Working Set uploads a Window Mask object with an unsupported window mask type, the VT shall parse, but
ignore, this object and no errors shall be raised. Unsupported window mask types would not be presented to
an operator for selection.
If the Working Set chooses to participate in this feature, it shall upload Window Mask and Key Group objects
as part of the object pool. Since the VT shall parse but ignore any Window Mask objects with unsupported
window mask type, no modification of the object pool is necessary.
The VT may support any number of User-Layout Data Masks. User-Layout Data Masks are special Data Mask
objects that are owned by the VT. The VT shall provide a mechanism to allow the operator to access the
available User-Layout Data Masks.
Each User-Layout Data Mask is the same size as a standard Data Mask object but is divided into a grid of
Window Cells with exactly two columns and six rows (See Figure 21).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 User-Layout Data Mask showing 12 Window Cells
Window Mask objects, optionally supplied in the object pools of Working Sets, are placed into a specific User-
Layout Data Mask grid as desired by the operator of the VT. An individual Window Mask object may take up
more than one Window Cell, and may take up the entire 2x6 grid. 1x1 Window Masks are recommended
where possible to allow the operator to select from a wide range of Window Mask objects to display in each
User-Layout Data Mask. (See example in Figure 22).
NOTE Window Mask objects are not limited to the sizes shown in Figure 22.
4.7.4.1 Presentations
A Window Mask object can display content using two different types of presentations. This is controlled by the
Working Set, using a Window Type attribute. More details are available in Clause 4.7.16 Uploading New
Window Mask and Key Group objects.
If the Window Mask object has a Window Type of zero, the Window Mask object behaves very similar to a
Data Mask object (other than the “size” of the Window Mask object). As with a Data Mask object, all content
and presentation is defined by the Working Set.
If the Window Mask object has a Window Type in the allowed set of non-zero values, the Working Set
provides references to a specific set of objects, and the VT then controls the presentation of those objects.
The VT is free to ignore any visual formatting attributes in the referenced objects. This capability allows
information from different manufacturers to have a consistent look and feel and interaction with the operator
when combined into the VT.
Key
1 Window Mask (2 x 1) 4 Window Mask (1 x 2)
2 Window Mask (2 x 2) 5 Window Mask (1 x 3)
3 Window Mask (1 x 1)
If User-Layout Data Masks are supported, the VT shall provide a proprietary mapping mechanism to allow the
operator to select which Window Mask objects are placed in which Window Cells in each of the User-Layout
Data Masks. The VT shall prevent the operator from choosing a Window Mask object that does not fit in the
selected Window Cell(s). When a Window Cell is selected in the mapping screen by the operator, the VT shall
present the list of all Window Mask objects that can fit in the cell(s), provided the Window Mask object is
available (see options attribute in the Window Mask object). The VT shall store the operator selected layout of
each of the User-Layout Data Masks in non-volatile memory for recall on next power up. If the Working Set
that provided the Window Cell is not present, the Window Cell shall be blanked (i.e. filled with the background
colour).
If a Window Mask object’s options attribute indicates that the mask is not available, the VT shall blank (i.e. fill
with the background colour) the associated Window Cell so that the Window Mask is not visible. A change in
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
If the VT is Version 4 or later but does not support User-Layout Data Masks, the Working Set may still include
these objects in the object pool transfer. The VT shall parse the Window Mask object and may then discard it.
The Window Mask object width shall be equal to the width of the Window Cell(s) that it occupies. The Window
Mask object height shall be equal to the height of the Window Cell(s) that it occupies.
NOTE: Working Set designs are encouraged to participate in the User-Layout Data Mask by uploading Window Mask
objects since this can be a feature requested by users.
The size of a single Window Cell is based on the 2x6 grid in the User-Layout Data Mask. The size of each
Window Cell shall be rounded down. Therefore, the size of a Window Cell is defined as follows:
The VT may draw a border around each Window Mask object. Whether the borders or any particular part of
the borders are actually drawn or not, is proprietary to the VT design. Border drawing is recommended but
may be based on an operator choice. The border area shall occupy the outside 1 pixel around the entire
Window Mask object and shall be drawn inside the Window Mask object’s region. Working Set designs shall
be aware of this and therefore it is recommended that no child object be placed on or touching the border area
when the free form (type 0) window type is used. See Clause B.19.2 Window Mask Window Type. See Figure
23 for an example of the border.
EXAMPLE:
Key
1 Window Mask Region
2 1-pixel border drawn around inside perimeter of Window Mask
The VT shall clip any pixel in the Window Mask object (and its children) that falls outside the Window Mask
region.
Depending on the type of Window Mask, the VT and the Working Set shall cooperate in terms of scaling. If the
window type is type 0 (free form), then as with other objects in the object pool, scaling of the Window Mask
object and its children is solely the responsibility of the Working Set. Regardless of the resolution of the VT in
use, the aspect ratio is known since the User-Layout Data Mask always has a 2x6 grid and the Data Mask
area is always square. Object pool designers should design the Window Mask object to an appropriate aspect
ratio which makes the scaling easier.
EXAMPLE 1 If the object pool is designed for a default 200x200 Data Mask Area, using the equations in Clause
4.7.5, the size of each Window Cell would be:
EXAMPLE 2 Using the Window Cell sizes above when using a VT with a default 200x200 Data Mask Area, a 2x2
Window Mask would use:
The VT controls most of the layout, formatting and scaling of objects when the Window Mask type is not the
Free Form Window (0). The exception to this rule is the Window Icon and Button attributes that are pre-scaled
by the Working Set. The VT may further scale the Window Icon and Buttons if necessary. More information is
contained in the sections that describe the window types greater than type zero (See Clause B.19.2 Window
Mask Window Type).
The VT may optionally use Window Mask objects in Non-VT Screens and Non-VT Areas, if supported by the
manufacturer’s design (see Figure 20). Soft Keys may or may not be supported when used in non-VT screens
and non-VT areas. Working Sets shall be aware that Window Mask object may be used outside of User-
Layout Data Mask and therefore shall monitor the VT On User-Layout Hide/Show message and refresh
Window Mask objects and keys that are visible regardless of the source address specified in the VT Status
message.
If the VT supports User-Layout Data Masks, it shall also support one and only one User-Layout Soft Key Mask
per User-Layout Data Mask. User-Layout Soft Key Masks are special Soft Key Mask objects that are owned
by the VT. Each User-Layout Soft Key Mask is divided into Key Cells (one cell per physical key if Physical Soft
Keys are used). The number of Key Cells supported by the User-Layout Data Mask is proprietary to the VT
design. Each Key Cell is sized to a normal Soft Key designator. The User-Layout Soft Key Mask is divided into
Key Cells as shown in Figure 24.
The VT designer shall decide how many keys per User-Layout Soft Key Mask are supported up to a maximum
of 64. If the number of keys supported exceeds the number of physical Soft Keys, the VT shall provide a
paging mechanism (identical to the Soft Key Mask object) to allow for proper mapping and operation.
Key
1 Key Cells (same size as Soft Key designator)
2 User-Layout Soft Key Mask
56
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Key Group objects (see Clause B.20), optionally supplied in the object pools of Working Sets, are placed into
a User-Layout Soft Key Mask by the operator of the VT. A Key Group object may contain one to four Key
objects (although one is typical) and therefore may occupy one or more Key Cells. If User-Layout Data Masks
and User-Layout Soft Key Masks are supported, the VT shall provide a proprietary mapping mechanism to
allow the operator to select which Key Group objects are placed in which Key Cells in each of the User-Layout
Soft Key Masks. When Key Cell(s) are selected in the mapping screen by the operator, the VT shall present
the list of all Key Group objects from all Working Sets that provide them, provided the Key Group is available
(see options attribute in the Key Group object). The VT shall store the operator selected layout of each of the
User-Layout Soft Key Masks, in non-volatile memory, for recall on the next power up. If the Working Set that
provided the Key Group Objects is not present, the assigned Key Cell(s) shall be blanked (i.e. filled with the
background colour).
If a Key Group object’s options attribute indicates that the Key Group is not available, the VT shall blank (i.e.
fill with the background colour) the associated Key Cells so that the Key objects are not visible and cannot be
activated by the operator. A change in state of the availability option may occur at runtime.
Working Set designers shall be aware that Keys may or may not be available and since the operator is in
control of what is mapped on each User-Layout Data Mask, Window Mask objects shall not depend on the
presence of a particular, or set of particular, Key Groups.
Key
1 Key Group containing 1 Key
2 Key Group containing 2 Keys
3 Key Group containing 3 Keys
Working Set designers should ensure that Keys can be recognized to be part of a specific Working Set (e.g.
displaying just a text string "STOP" on a Key might lead to confusion by the operator if a particular
configuration uses 3 "STOP" Keys in the same User-Layout Soft Key Mask). To create a consistent look and
feel, the key layout shown in Figure 26 — Key object in a Key Group indicating Working Set - Example is
recommended.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 Implement identifier (sized to 60% of the height of a standard Soft Key designator (rounded down) and width equal to
height) and anchored in the bottom left corner of the designator area.
2 Key object in a Key Group is the size of a Soft Key designator (uses all remaining pixels in the standard designator
area)
The same drawing rules that apply to Soft Key Mask objects also apply to User-Layout Soft Key Mask objects.
A Key Cell size is the same size as a normal Soft Key designator.
Similar to other objects in the Object Pool, scaling of the Key Group object’s children is the responsibility of
the Working Set.
4.7.12 Using Key Group Objects outside of User-Layout Soft Key Masks
The VT may optionally use Key Group objects outside of User-Layout Soft Key Mask, if supported by the
manufacturer’s VT display design. Working Sets shall be aware that Key Group objects can be used outside
of User-Layout Soft Key Mask and therefore shall monitor the VT On User-Layout Hide/Show message and
refresh keys that are visible regardless of the source address specified in the VT Status message.
Key
1 3 Key Group Objects outside of User-Layout Soft Key Masks
It is possible that input objects from several Working Sets can be on screen at the same time. The usual
navigation and data input rules apply with the following exceptions:
a) Select Input Object commands from any Working Set are not acted upon when a User-Layout Data Mask
is displayed because the VT is the owner of the Data Mask. In this case, the VT shall send a Select Input
Object response with an error indicated.
c) Macros associated with input object events shall be executed but Working Set designers must be aware
that there may be no visible effect since the Working Set is not the active Working Set. For example,
objects acted upon or made visible by the macro may not be on screen and Change Active Mask
commands selecting a Data Mask will have no effect because the Working Set is not the active Working
Set.
d) When an input object in a Window Mask is activated by the operator, the VT becomes the active Working
Set in the VT Status message. If Working Set Data Mask(s) are also visible, the indicator of the active
Data Mask shall be removed since the VT is now the active Working Set. Whether or not an “active
working set” indicator is displayed around the Window Mask is proprietary to the VT design. The VT shall
also use the VT On user-Layout Hide/Show message to inform the Working Set about this change. See
4.6.8 Working Set object and active masks.
Whenever a Window Mask object or Key Group object is on screen, it shall be the responsibility of the
Working Set to refresh values and objects as required. If a Working Set times out, the connection
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
management rules apply and the VT shall remove from the screen, any Window Mask objects and Key Group
objects that belong to the affected Working Set.
In order to refresh on screen objects, the Working Sets need to be made aware of what Window Mask objects
and Key Group objects are visible. This is accomplished by the VT On User-Layout Hide/Show message (see
Clause H.20). This message shall be sent by the VT for each Window Mask and Key Group object that has
been displayed or removed from the display.
NOTE The VT Status message is not used to determine when to update Window Mask or Key Group objects.
When mixing Window Mask objects from several Working Sets, general look and feel can quickly become a
problem for the operator since objects may not line up vertically and horizontally and may use different colour
schemes and fonts. Therefore restrictions are required for the design of the windows represented by the
Window Mask objects and their children. In addition, the VT controls the look and feel on its User-Layout Data
Masks. The strategy is that the Working Set supplies the superset of attributes that the VT may need to render
the Window Mask objects but the VT decides what is displayed and where it is displayed in the Window Mask
object assuming the window type is greater than zero. The following rules and guidelines shall apply:
a) When the Window Type is not the Free Form Window, the VT determines the background color and
transparency of the window. If required the Working Set designer can query the VT’s background
colour with the Get Window Mask Data message.
c) The VT may ignore any visual formatting attributes in the Working Set’s supplied object references
where the Window Type is not the Free Form Window.
The VT may optionally use this string for a title inside the Window Mask. Formatting is proprietary to the VT
designer. The VT shall always display either or both of the Window Title and Window Icon as these elements
are considered to be functionally equivalent and describe the contents of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
The VT may optionally use the Window Icon attribute inside the Window Mask. The Window Icon attribute in
the Window Mask object shall reference a Picture Graphic object. Positioning is proprietary to the VT
designer, subject to the rules below. The Window Icon Area shall be square and shall be 90% of the height of
a single Window Cell, rounded down.
EXAMPLE In a 200x200 Data Mask Area, the Window Cell size is 100 pixels wide by 33 pixels high. The standard
Window Icon Area is then:
This provides for room for a window border and some white space outside the Window Icon Area. Using the
above information, Working Set designers may pre-scale the Window Mask Icon Picture Graphic object at
design time or set the scale, via the width attribute, at run-time. It is permissible for the Working Set to supply
an icon that is smaller or larger than the Window Icon Area. It is also permissible to provide an icon in an
aspect ratio different from the square aspect ratio of the Window Icon Area. The VT may position the icon as
desired if the icon dimension (X or Y) is smaller than the Window Icon Area. The VT shall center and clip the
icon if the icon dimension (X or Y) is larger than the Window Icon Area. These rules apply independently to
the X and Y dimensions.
Working Set designers should supply an icon that clearly represents not only the specific function being
displayed but also a representation of the Working Set so that the source of the data is evident to the
operator.
4.7.15.4 Formatting
For window types greater than zero, the VT look and feel design shall ensure that at least the minimum
number of characters are displayed for numeric and string value fields and shall obey the numeric scaling and
numeric formatting attributes supplied by the Working Set. Specifically, this includes the options (bits 1, 2 and
3), variable reference, value, offset, scale, number of decimals and format attributes. Look and feel attributes
such as justification, colour and other formatting attributes may be ignored by the VT to achieve its desired
look and feel. More information on field lengths is given in the section on Window Mask Window Type (See
Clause B.19.2).
Uploading completely new objects (as long as the object type does not change) at run-time is permitted by
Annex C of this standard. In terms of Window Mask and Key Group objects, there are several cases that shall
be considered and managed properly by the VT design as identified in Table 6 — VT Behavior When New
Window Mask or Key Group Object is Uploaded.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Table 6 — VT Behavior When New Window Mask or Key Group Object is Uploaded
Event VT Behavior
A new Window Mask or Window Mask child is uploaded If the object is visible, the VT shall refresh it.
that creates a simple change in appearance (background
colour, option change, child change etc.).
A new Window Mask is uploaded that changes its If the object is visible, the VT shall blank (i.e. fill with the
availability from available to not available background colour) the area occupied by the object so
that is it removed from the screen.
A new Window Mask is uploaded that changes its size If the size decreases and the Window Mask is visible, the
VT shall refresh the object and all window cells that it
originally occupied. It shall also blank (i.e. fill with the
background colour), all window cells that are no longer
used by this object. The VT shall adjust the stored
mapping to reflect the new unused window cells.
If the size increases, the VT shall determine if the object
still fits on screen in its current position in the grid and
whether or not empty window cells are available in the
extended positions to accommodate the new object. If
yes, the VT shall refresh the object and adjust the stored
mapping (for occupied window cells). If no, the VT shall
automatically remove the window from the stored
mapping and, if visible, shall blank (i.e. fill with the
background colour) the window cells that it originally
occupied.
A new Window Mask is uploaded that changes its If the object is visible, the VT shall refresh it.
window type
A new Key Group object is uploaded that creates a If the object is visible, the VT shall refresh it.
simple change in appearance (option change, child
change etc.)
A new Key Group object is uploaded that changes its If the object is visible, the VT shall blank (i.e. fill with the
availability from available to not available background colour) the area occupied by the object so
that is it removed from the screen. The positions of other
mapped Key Group objects shall not be effected.
A new Key Group object is uploaded that changes the If the number of keys in the group decreases, and the
number of keys in the group object is visible, the VT shall refresh the object and blank
(i.e. fill with the background colour) and key positions
that are no longer used. The VT shall adjust the stored
mapping to reflect the new unused key positions. The
positions of other mapped Key Group objects shall not
be effected.
If the number of keys in the group increases, the VT shall
determine if there are enough empty key positions on the
same page to accommodate the new object, without
changing the position of the Key Group object. If yes,
the VT shall extend the mapping of the object (for
occupied key positions) and refresh the Key Group
object if visible. If no, the VT shall automatically remove
the Key Group from the mapping and, if the object is
visible, shall blank (i.e. fill with the background colour)
the key positions that it originally occupied. The
positions of other mapped Key Group objects shall not
be effected.
--```,`,`,,``,,````,,,,,``,`,,-`-`,
Annex A
(normative)
A.1.1 General
This part of ISO 11783 takes an object-oriented approach. The VT shall be capable of managing the set of
objects given in Table A.1 — Virtual terminal objects, which includes the requirement to parse the objects,
even if the object is not functionally supported. Each Working Set using the services of the VT defines an
object pool that is a collection of the objects given. Each object has a specific, well-defined behaviour and a
specific set of attributes.
Working Set object 010 Top level object that describes an implement’s ECU or group of ECUs
(Working Set). Each Working Set is required to define one, and only one,
Working Set object.
Data Mask object 110 Top level object that contains other objects. A Data Mask is activated by a
Working Set to become the active set of objects on the VT display.
Alarm Mask object 210 Top level object that contains other objects. Describes an alarm display.
Container object 310 Used to group objects.
e
Window Mask object 3410 Top level object that contains other objects. The Window Mask is activated
by the VT.
Key objects
Soft Key Mask object 410 Top level object that contains Key objects.
Key object 510 Used to describe a Soft Key.
Button object 610 Used to describe a Button control.
e
Key Group object 3510 Top level object that contains Key objects.
Input field objects
Number Variable object 2110 Used to store a 32-bit unsigned integer value.
String Variable object 2210 Used to store a fixed length string value.
Attribute Objects
Font Attributes object 2310 Used to group font based attributes. Can only be referenced by other
objects.
Line Attributes object 2410 Used to group line based attributes. Can only be referenced by other
objects.
Fill Attributes object 2510 Used to group fill based attributes. Can only be referenced by other objects.
Input Attributes object 2610 Used to specify a list of valid characters. Can only be referenced by input
field objects.
a
Extended Input Attributes object 3810 Used to specify a list of valid WideChars. Can only be referenced by Input
Field Objects.
e
Colour Map object 3910 Used to specify a colour table object.
a
Object Label Reference List object 4010 Used to specify an object label.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Pointer object
Macro object 2810 Special object that contains a list of commands that can be executed in
response to an event. Macros can be referenced by other objects.
Version 4 and later Working Sets may use the Execute Macro command.
Version 5 and later works Sets may use the Execute Extended Macro
command.
Auxiliary control
Auxiliary Function Type 1 object 2910 The Auxiliary Function Type 1 object defines the designator and function
c
(ignored) type for an Auxiliary Function. The object is used strictly in the Auxiliary
Control screen which is proprietary to the VT.
Auxiliary Input Type 1 object 3010 The Auxiliary Input Type 1 object defines the designator, key number, and
c
(ignored) function type for an auxiliary input. The object is used strictly in the Auxiliary
Control screen which is proprietary to the VT.
b
Auxiliary Function Type 2 object 3110 The Auxiliary Function Type 2 object defines the designator and function
type for an Auxiliary Function.
b
Auxiliary Input Type 2 object 3210 The Auxiliary Input Type 2 object defines the designator, key number, and
function type for an Auxiliary Input.
Auxiliary Control Designator Type 2 3310 Used to reference Auxiliary Input Type 2 object or Auxiliary Function Type 2
b
Object Pointer object.
Proprietary Objects
d
Manufacturer Defined Objects 24010 - Manufacturer defined objects should not be sent to any other Vendors VT.
25410 (See Clause 4.6.24 Proprietary Means)
Reserved Objects
Reserved 25510 Reserved for future use. (See Clause D.14 Get Supported Objects
message)
a
Version 4 and later VTs support these objects.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
b
Version 3 and later VTs support these objects.
c
Version 3 and later VTs parse these objects for compatibility, but they are not functionally supported.
d
Version 4 and later VTs support proprietary objects that should not be used between ECUs and VTs with different
manufacturer codes.
e
Version 4 and later VTs parse these objects for compatibility because they are optional and may not be functionally
supported. (See Clause D.14 Get Supported Objects message)
f
Version 5 and later VTs support these objects.
A.1.2 Nomenclature
The following data types and nomenclature are used in the object definitions in Annex B.
[] When surrounding an AID number this indicates that it is a read-only attribute and is
accessible with the Get Attribute Value message. AIDs that are explicitly defined without
square brackets are writable with the Change Attribute command.
Bitmask A set of logical bit values. Size is 1 byte. Bitmasks always have Bit 0 defined as the least
significant bit. (See Figure A.1 — Bit positions in a bitmask)
Byte Signed or unsigned integer numeric value with a size of exactly 1 byte.
Float IEEE 754-1985 standard 32-bit floating point numeric value. Size is 4 bytes.
Integer Signed or unsigned integer numeric value. Possible sizes are 1, 2 or 4 bytes.
String Zero or more characters composed of either the primitive type “Char“ or the primitive type
WideChar. String length is variable.
Length The size of an object, always expressed as a count of the Bytes required to hold the object.
Key
1 most significant
2 least significant
The visible objects of an object pool are arranged in a hierarchy, where parent objects contain child objects.
Some of the child objects can also contain objects, and then they can become parent objects to their own
child-objects. Table A.2 — Allowed hierarchical relationships of objects shows the containment rules of
objects within the object pool hierarchy.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Parent Object
Animation object
Container object
Parent Object
Animation object
Container object
NOTE: The numbers in the table above denote Child Objects that can be contained within a Parent Object in the indicated
VT version including later versions.
NOTE: Containment rules of the parent override containment rules of the child
NOTE: Object pointed to by Object Pointer cannot violate the containment rules of the parent hierarchy
to each so that events can be uniquely associated with a Macro object to execute when the event occurs. VT
behaviour specific to each object is defined in event tables given with each object.
Event ID
Event name 8-bit Macro or Event occurs when:
c
16-bit Macro
Event ID
Event name 8-bit Macro or Event occurs when:
c
16-bit Macro
c
Use Extended 25510 This is not an event. When value is found in the event list of an object, it indicates
Macro Reference that a 16-bit Macro Object ID reference is used (See Clause 4.6.22.3 Macro
references – VT version 5 and later)
a If two or more input objects reference the same variable object and one of the input objects is modified (thereby changing the value of
the variable object), the OnEntryOfANewValue and/or OnEntryOfAValue Macros are executed for the modified input object only.
b VT version 4 and prior
c VT version 5 and later
Index R,G,B value Index R,G,B value Index R,G,B value Index R,G,B value
Index R,G,B value Index R,G,B value Index R,G,B value Index R,G,B value
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
29 00,66,33 93 66,00,FF 157 99,FF,99 221 FF,CC,33
30 00,66,66 94 66,33,00 158 99,FF,CC 222 FF,CC,66
31 00,66,99 95 66,33,33 159 99,FF,FF 223 FF,CC,99
32 00,66,CC 96 66,33,66 160 CC,00,00 224 FF,CC,CC
33 00,66,FF 97 66,33,99 161 CC,00,33 225 FF,CC,FF
34 00,99,00 98 66,33,CC 162 CC,00,66 226 FF,FF,00
35 00,99,33 99 66,33,FF 163 CC,00,99 227 FF,FF,33
36 00,99,66 100 66,66,00 164 CC,00,CC 228 FF,FF,66
37 00,99,99 101 66,66,33 165 CC,00,FF 229 FF,FF,99
38 00,99,CC 102 66,66,66 166 CC,33,00 230 FF,FF,CC
39 00,99,FF 103 66,66,99 167 CC,33,33 231 FF,FF,FF
40 00,CC,00 104 66,66,CC 168 CC,33,66 232 Proprietary
41 00,CC,33 105 66,66,FF 169 CC,33,99 233 Proprietary
42 00,CC,66 106 66,99,00 170 CC,33,CC 234 Proprietary
43 00,CC,99 107 66,99,33 171 CC,33,FF 235 Proprietary
44 00,CC,CC 108 66,99,66 172 CC,66,00 236 Proprietary
45 00,CC,FF 109 66,99,99 173 CC,66,33 237 Proprietary
46 00,FF,00 110 66,99,CC 174 CC,66,66 238 Proprietary
47 00,FF,33 111 66,99,FF 175 CC,66,99 239 Proprietary
48 00,FF,66 112 66,CC,00 176 CC,66,CC 240 Proprietary
Index R,G,B value Index R,G,B value Index R,G,B value Index R,G,B value
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
58 33,33,00 122 66,FF,CC 186 CC,CC,66 250 Proprietary
59 33,33,33 123 66,FF,FF 187 CC,CC,99 251 Proprietary
60 33,33,66 124 99,00,00 188 CC,CC,CC 252 Proprietary
61 33,33,99 125 99,00,33 189 CC,CC,FF 253 Proprietary
62 33,33,CC 126 99,00,66 190 CC,FF,00 254 Proprietary
63 33,33,FF 127 99,00,99 191 CC,FF,33 255 Proprietary
a Monochrome (0 and 1).
b 16-colour mode (0 to 15).
The VT colour palette is based on the standard 216 colour “web browser safe” palette used by Internet
browsers. Hexadecimal RGB values of 00, 33, 66, 99, CC and FF are used giving a 6 × 6 × 6 = 216 colour
cube. The colour palette is organized as follows. The first two colours at indices 0 and 1 are used in
monochrome mode. The first 16 colours are used in 16 colour mode. In order to reduce search time during
palette mapping on an object development tool, colours 16 to 231 are organized in sorted, ascending order.
Colours 232 to 255 are proprietary to the VT design to extend the colour palette. VT designers choosing a
grey-scale implementation can map the 16 or 256 colour modes to shades of grey.
NOTE 256 colour mode does not actually give 256 unique colours because the first 16 colours are repeated
elsewhere in the palette.
Colour and pixel values given in object attributes and bitmap data are an index into this palette table.
There are three defined colour modes. VT designs supporting higher modes shall also support lower modes,
as follows:
a) monochrome only (black and some other colour, usually white) (valid colour codes 0 to 1);
b) 16-colour mode (VT shall support 16 colour and monochrome) (valid colour codes 0 to 15);
c) 256-colour mode (VT shall support all colours of the palette) (valid colour codes 0 to 255).
Allowed
Clause/ Function Function VT
Message Direction in
subclause (Decimal) (Hex) version C
Macro
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
E.3 Get Versions response VT to ECU 22410 E016 No 2
E.4 Store Version command ECU to VT 20810 D016 No 2
E.5 Store Version response VT to ECU 20810 D016 No 2
E.6 Load Version command ECU to VT 20910 D116 No 2
E.7 Load Version response VT to ECU 20910 D116 No 2
E.8 Delete Version command ECU to VT 21010 D216 No 2
E.9 Delete Version response VT to ECU 21010 D216 No 2
E.10 Extended Get Versions message ECU to VT 21110 D316 No 5
E.11 Extended Get Versions response VT to ECU 21110 D316 No 5
E.12 Extended Store Version command ECU to VT 21210 D416 No 5
E.13 Extended Store Version response VT to ECU 21210 D416 No 5
E.14 Extended Load Version command ECU to VT 21310 D516 No 5
E.15 Extended Load Version response VT to ECU 21310 D516 No 5
E.16 Extended Delete Version command ECU to VT 21410 D616 No 5
E.17 Extended Delete Version response VT to ECU 21410 D616 No 5
F.2 Hide/Show Object command ECU to VT 16010 A016 Yes 2
F.3 Hide/Show Object response VT to ECU 16010 A016 No 2
Allowed
Clause/ Function Function VT
Message Direction in
subclause (Decimal) (Hex) version C
Macro
Allowed
Clause/ Function Function VT
Message Direction in
subclause (Decimal) (Hex) version C
Macro
Allowed
Clause/ Function Function VT
Message Direction in
subclause (Decimal) (Hex) version C
Macro
Allowed
Clause/ Function Function VT
Message Direction in
subclause (Decimal) (Hex) version C
Macro
response
J.7.13 Auxiliary Capabilities request ECU to VT 3910 2716 No 5
J.7.14 Auxiliary Capabilities response VT to ECU 3910 2716 No 5
Special Functions
a
Reserved Any 1110 – 1610 0B16 – 1016
a
Reserved Any 1910 – 3110 1316 – 1F16
a
Reserved Any 4010 – 9510 2816 – 5F16
a
Reserved 12810 –
Any 8016 – 9116
14510
a
Reserved 14710 –
Any 9316 – 9F16
15910
a
Reserved Any 19110 BF16
a
Reserved Any 19810 C616
a
Reserved 20010 –
Any C816 – CF16
20710
a
Reserved 21110 –
Any D316 – DE16
22210
a
Reserved 22510 –
Any E116 – FC16
25210
b
Proprietary Command 9610 –
Any 6016 – 7F16
12710
a
Reserved for future use
b
Proprietary commands should not be used between ECUs and VT with different manufacturer codes.
C
Identifies the VT version at which the command was introduced, however some messages have been revised with later
versions.
Annex B
(normative)
Object definitions
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
of a different Set.
Working Set via the
VT
On Change Change Active Change the active mask attribute. If this Working Change Active Mask response.
Active Mask Mask command Set is active, then perform a hide event on the VT Status message if the Active
current active mask and a show event on the Mask changed.
new active mask.
On Change Change If the Working Set designator is visible, fill area Change Background Colour
Background Background Colour with background colour and draw child objects in response
Colour command the order they are listed.
On Change Change Child If the Working Set designator is visible, draw Change Child Location response
Child Location Location command child object at current location in background
colour to erase it. Refresh Working Set
designator (to redraw child object or objects).
On Change Change Child If the Working Set designator is visible, draw Change Child Position response
Child Position Position command child object at current location in background
80 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
{Macro ID} Integer 1 0-255 12+ (No. 8-bit Macro Object ID reference: Macro ID of
objects the Macro to execute.
*6)… 16-bit Macro Object ID reference (only for VT
version 5 and later): Low byte or high byte of
Macro ID of the Macro to execute (see Clause
4.6.22.3)
Repeat: String 2 Record (List these after all objects and macros have
{Language Position been listed.)
Code} Depends Two-letter code of a supported language. For
on above language codes, See ISO 639, however all
combinations of a-z and A-Z shall be accepted
to guard against changes to ISO 639.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Allowed commands:
Allowed commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
b) If this Alarm Mask is not visible and it
becomes the highest priority alarm then
deactivate the current Working Set and activate
this WS.
On Change Soft Change Soft Key If the Alarm Mask is visible, hide event on the Change Soft Key Mask response.
Key Mask Mask command current Soft Key Mask and a show event on the If this mask is visible, VT Status
new Soft Key Mask. message.
On Change Change Attribute For behaviour see other change commands Change Attribute response. If
Attribute command above. change affects visible masks, VT
Status message.
On Pointing Operator touch data Pointing Event message
—
Event press mask
On Pointing Operator touch is Pointing Event message
—
Event release released
Allowed Commands:
hide on a child, —
grandchild etc
object.
On Change Change Child Draw child object at current location in Change Child Location response
Child Location Location command background colour to erase it. Refresh container
(to redraw child object or objects).
On Change Change Child Draw child object at current location in Change Child Position response
Child Position Position command background colour to erase it. Refresh container
(to redraw child object or objects).
On Change Size Change Size Draw child objects at current location in Change Size response
command background colour to erase them. Refresh
container (to redraw child object or objects).
A common implementation, which was not clearly defined until VT version 4 and later, is that pointers to the
NULL Object ID reserve a Soft Key position (the remaining Soft Keys do not move up and the trailing Soft
Keys can be navigated to). Pointers to NULL that are at the end of the list of Soft Keys shall not be displayed.
They should not be considered for paging. The paging requirements may be dynamic at run-time based if
pointer values are changed to and from NULL. (See Clause 4.5.3.5 Navigation among Soft Keys)
Allowed Commands:
88 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
version 5 and later): Event ID of event type that
causes this Macro to execute or 0xFF (see
Clause 4.6.22.3)
{Macro ID} Integer 1 0-255 8+ (No. 8-bit Macro Object ID reference: Macro ID of the
objects Macro to execute.
*2)… 16-bit Macro Object ID reference (only for VT
version 5 and later): Low byte or high byte of
Macro ID of the Macro to execute (see Clause
4.6.22.3)
Allowed Commands:
90 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
The VT shall indicate when a Button is selected (has focus), pressed or latched depending on the options
attribute.
The Button consists of the Button Area, the Button Face, and the Button Border.
⎯ The Button Area is the area which is defined by the Button object width and height attributes.
⎯ The Button Face is the area which contains the Background colour and into which the designer may
implement child objects. Child objects are clipped to the width and height of the Button Face (see
Figure B.1 — Button examples with border (Options – Bit 5 = FALSE)). The Button Face is 8 pixels
smaller (in both width and height) than the Button Area, unless the Options - No border bit is set to TRUE,
in which case the Button Face is extended to be equal to the Button Area.
⎯ The Button Border is the area which contains the border colour. Presentation of the border is VT
proprietary (see Figure B.1 — Button examples with border (Options – Bit 5 = FALSE)). As a result, the
position of the button face is VT proprietary. The Button Border may hidden by setting the Options –
Suppress border bit to TRUE. The Button Border may be eliminated by setting the Options – No border bit
to TRUE. See Table B.13 — Button events and Table B.14 — Button attributes and record format.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Figure B.2 — Button examples no border (Options – Bit 5 = TRUE)
Allowed commands:
94 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
B.8.1 General
There are four types of input field: Boolean, String, Number, and List. No border shall be drawn around any
input field by the VT.
Input Boolean,
Input String object, Input Number and Input List objects have similar relationships, commands and events and
they are listed here. The attributes for each object differ.
Input field objects do not have a show/hide attribute. In order to hide an input field object, it can be contained
by a Container object or Object Pointer object. See Table B.15 — Input events to Table B.20 — Input List
attributes and record format.
Allowed Commands (See Clause B.8.5 for Input List object allowed commands):
⎯ ESC command;
The Input Boolean object is used to input a TRUE/FALSE type indication from the operator. This is a graphical
object and the appearance of the indicator when the value is > 0 is left to the VT, but it shall fit in the square
area specified by the width attribute. An example of a Boolean input is a checkbox.
When the value is > 0, the VT draws the indicator using the foreground colour on the background colour.
NOTE VT Version 3 and prior have a Value range in the set {0, 1} but do not clarify the presentation when the value
is not in the set {0, 1}, which is possible when using a variable reference. In VT version 4 and later, the TRUE indication is
shown for any value > 0, and the FALSE indication for the value = 0. When the Input Boolean value is changed, the VT
shall indicate the state of the Input Boolean to the Working Set with a value in the set {0, 1}.
Value 0 Value 1
This object is used to input a character string from the operator. Displayable characters are shown in
Table L.1 — ISO 8859-1 (Latin 1) character set to Table L.7 — WideString minimum character set. Several
special formatting characters are permitted in the
--```,`,`,,``,,````,,,,,``,`,,
Input String object value and shall be properly interpreted by the VT, as specified. (See Clause 4.6.19.6 Non-
printing characters in strings)
a
Justification 8 Integer 1 0-2 16 Field justification. Indicates how the text string is
positioned within the field defined by width and
0-15
b height. See Clause 4.6.19.1 General
Text justification.
Horizontal Justification Value of Bits 0 – 1
0 = Position Left
1 = Position Middle
2 = Position Right
3 = Reserved
b
Vertical Justification Value of Bits 2 – 3
0 = Position Top
1 = Position Middle
2 = Position Bottom
3 = Reserved
This object is used to format, display and change a numeric value based on a supplied integer value. The VT
shall use the following equation to format the displayed value:
Depending on the ‘Options‘ attribute in Table B.18 — Input Number attributes and record format, displayed
values are either truncated or rounded to the number of decimals specified in the ‘Number of decimals‘
attribute.
NOTE: The displayed value shall be formatted according to the above equation even if the value is outside the min/max
value range.
NOTE: The VT should implement double precision operations to minimize rounding errors.
When the operator presses the Enter means, to close the input object after data input, the VT shall only
accept the new value if the following equations are true:
Scaled min value <= new value <= Scaled max value
If the above equations are not true the VT shall ignore the Enter means and keep the input object open for
data input.
If the above equations are true the VT sets the value attribute of the input number object or the referenced
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
NOTE While the operator is not allowed to enter values outside the min/max range, the ECU is allowed to set any
value either by pool upload or by the Change Numeric Value command.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
bc
number of decimals.
NOTE: Designer should account for a unary minus
sign with respect to leading zeros and the field
width.
Variable 6 Integer 2 0-65534, 12-13 Object ID of a Number Variable object in which to
reference 65535 store or retrieve the object’s raw unscaled value. If
this attribute is set to NULL, the value is stored
directly in the value attribute instead. VT transmits
the raw unscaled value to the Working Set.
Value [14] Integer 4 0 14-17 Raw unsigned value of the input field before
to scaling (unsigned 32-bit integer). Used only if
2^32-1 variable reference attribute is NULL. VT transmits
the raw unscaled value to the Working Set.
Min value 7 Integer 4 0 18-21 Raw minimum value for the input before scaling.
to Offset and scaling shall be applied to determine the
2^32-1 actual minimum value.
Max value 8 Integer 4 0 22-25 Raw maximum value for the input. Offset and
to scaling shall be applied to determine the actual
The Input List object is used to show one object out of a set of objects, and to allow operator selection of one
object from the set. The object to show is determined by the Value attribute or a Variable reference.
The exact implementation and appearance of the Input List object is proprietary to the VT. For example, a
simple implementation of the Input List object could be to display values as the operator moves through the
list using +/− keys. A more complex implementation could be to draw a graphical pop-up list box with a scroll
bar for moving through the allowable values. In either case, only the current value shall be displayed when this
object is not open for edit. The width and height attributes define the width and height of the displayed value
only.
This object is used to select an item from a list of objects. The value transmitted to the Working Set Master is
the list index chosen (range 0-254).
NOTE In VT version 3 and prior, the behavior with the value 255 was not defined. The value 255 is used to indicate
that no item is chosen. The CF may set the value to 255 for this purpose. The operator, in the process of selecting a list
item, shall not be allowed to set the value to 255.
The operator also shall not be allowed to set the value to an invalid index (an index which is greater than the
number of items in the list minus 1). However, if the list references a number variable, then it is possible for
that number variable to be set by the Working Set or by the operator (by using a different input object) to a
value which is not a valid index for the list.
When a list item is an Object Pointer with a value of NULL or is a Container, and the Container is in the hidden
state, it is considered an empty object. It will still occupy a position in the displayed list, so it can still be
selected by the operator, even though its contents will not be visible.
When a list item has an Object ID of NULL it is considered an invisible object. It does not occupy a position in
the displayed list and cannot be selected by the operator. However, it is still counted when determining list
indexes and maintains its position in the list even though it is not visible to the operator.
The VT shall not display anything for the selected item in the following cases:
⎯ index value is invalid (greater than the number of items in the list minus 1)
⎯ selected list item is a Container, and the container is in the hidden state
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
⎯ ESC command;
B.9.1 General
There are three types of output field: string, number, and list. They have similar relationships and behaviour,
but have different attributes. See Table B.21 — Output field events to Table B.25 — Output List attributes and
record format.
Allowed Commands (See Clause B.9.4 for Output List object allowed commands):
This object is used to output a string of text. Displayable characters are given in Table L.1 — ISO 8859-1
(Latin 1) character set to Table L.7 — WideString minimum character set. Several special formatting
characters are permitted in the Output String value and shall be properly interpreted by the VT as specified in
Clause 4.6.19.6 Non-printing characters in strings.
b
Justification 7 Integer 1 0-2 14 Field justification. Indicates how the text string is
positioned within the field defined by width and
0-15
a height. See Clause 4.6.19.2 Text justification.
Justification is always done on a graphical (i.e.
pixel) basis. (See Table B.23 — Output Number
attributes and record format)
Horizontal Justification Value of Bits 0 – 1
0 = Position Left
1 = Position Middle
This object is used to format and output a numeric value based on a supplied integer value. The VT shall use
the following equation to format the displayed value:
Depending on the ‘Options’ attribute presented in Table B.23 — Output Number attributes and record format,
displayed values are either truncated or rounded to the number of decimals specified in the ‘Number of
decimals’ attribute.
NOTE The VT should implement double precision operations to minimize rounding errors.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Bit 1 = Display leading zeros. If TRUE, fill left to
width of field with zeros; justification is applied
after filling to the width of the field with zeros.
Bit 2 = Display zero value as blank if this bit is
TRUE. When this option bit is set, a blank field
is displayed if and only if the value of the object
is exactly zero.
NOTE: Except when the field is blank, the VT
shall always display at least one digit before
the decimal point. (examples: 2.2, 0.2)
Bit 3 = Truncate. If TRUE the value shall be
truncated to the specified number of decimals.
Otherwise it shall be rounded off to the
bc
specified number of decimals.
Variable 6 Integer 2 0-65534, 12-13 Object ID of an integer variable object in which
reference 65535 to retrieve the object’s raw unscaled value. If
this attribute is set to NULL, the value is
retrieved directly from the value attribute
instead. VT shall scale the value for display.
Value [12] Integer 4 0 14-17 Raw unsigned value of the output field before
to scaling (unsigned 32-bit integer). Used only if
2^32-1 variable reference attribute is NULL. VT shall
scale this value for display.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
decimals the decimal point.
Format 10 Boolean 1 0 or 1 27 0 = use fixed format decimal display (####.nn)
1 = use exponential format ([−]###.nnE[+/−]##
where n is set by the number of decimals
attribute).
a
Justification 11 Integer 1 0-2 28 Field justification. Indicates how the number is
positioned within the field defined by width and
0-15
c height. See Clause 4.6.19.2 Text justification.
Justification is always done on a graphical (i.e.
pixel) basis.
Horizontal Justification Value of Bits 0 – 1
0 = Position Left
1 = Position Middle
2 = Position Right
3 = Reserved
bc
Vertical Justification Value of Bits 2 – 3
0 = Position Top
1 = Position Middle
2 = Position Bottom
3 = Reserved
Number of Integer 1 0-255 29 Number of Macro references included even if
macros to zero. Each Macro reference consists of 2 bytes:
follow one for event ID and one for Macro ID.
Whenever the indicated event occurs, the
associated Macro is executed.
VT version 5 and later: A reference to a Macro
with 16-bit Object ID shall count as 2 macro
references within the context of this attribute.
Repeat: Integer 1 0-255 30… (List these after all objects have been listed.)
{Event ID} 8-bit Macro Object ID reference: Event ID of
event type that causes this Macro to execute.
16-bit Macro Object ID reference (only for VT
version 5 and later): Event ID of event type that
causes this Macro to execute or 0xFF (see
Clause 4.6.22.3)
{Macro ID} Integer 1 0-255 31… 8-bit Macro Object ID reference: Macro ID of
the Macro to execute.
16-bit Macro Object ID reference (only for VT
version 5 and later): Low byte or high byte of
Macro ID of the Macro to execute (see Clause
4.6.22.3)
a
VT Version 3 and prior.
b
VT Version 4 and later.
c
Prior to VT version 4, the behaviour was undefined.
The Output List object, available in VT version 4 and later, is used to show one object out of a set of objects.
The object to shown is determined by the Value attribute or a Variable reference.
The VT shall not display anything for the selected item in the following cases:
⎯ index value is invalid (greater than the number of items in the list minus 1)
⎯ selected list item is a Container, and the container is in the hidden state
⎯ the object is enabled and the numeric relationships shown below have been violated
Allowed Commands:
Object ID Integer 2 0-65534 1-2 Object identifier. Shall be unique within the
object pool.
Type [0] Integer 1 =37 3 Object Type = Output List
Width 1 Integer 2 0-65535 4-5 Maximum width of the output field in pixels.
Objects or portions of objects outside the
defined area are clipped.
Height 2 Integer 2 0-65535 6-7 Maximum height of the output field in pixels.
Objects or portions of objects outside the
defined area are clipped.
Variable 3 Integer 2 0-65534, 8-9 Object ID of a Number Variable object from
reference 65535 which to retrieve the object’s value. If this
attribute is set to NULL, the value is found
directly in the value attribute instead.
Value [4] Integer 1 0-254, 255 10 Selected list index of this object. Used only if
variable reference attribute is NULL. The
current list item chosen or 255 to indicate no
item is chosen. The first item is at index zero
(0).
Number of Integer 1 0-255 11 Number of object references to follow. The
list items size of the list can never exceed this number
and this attribute cannot be changed.
Number of Integer 1 0-255 12 Number of Macro references included even if
macros to zero. Each Macro reference consists of
follow 2 bytes: one for event ID and one for Macro
ID. Whenever the indicated event occurs, the
associated Macro is executed.
VT version 5 and later: A reference to a
Macro with 16-bit Object ID shall count as 2
macro references within the context of this
attribute.
Repeat: Integer 2 0-65534, 13+ These objects make up the list. NULL is a
{Object ID} 65535 object* no-item placeholder (invisible object). (See
2 Clause A.1.3 Object relationships)
The Change List Item command allows
objects to be replaced or removed.
Repeat: Integer 1 0-255 13+ (No. (List these after all objects have been listed.)
{Event ID} List Items 8-bit Macro Object ID reference: Event ID of
* 2)… event type that causes this Macro to execute.
16-bit Macro Object ID reference (only for VT
version 5 and later): Event ID of event type
that causes this Macro to execute or 0xFF
(see Clause 4.6.22.3)
{Macro ID} Integer 1 0-255 14+ (No. 8-bit Macro Object ID reference: Macro ID of
List Items the Macro to execute.
* 2)… 16-bit Macro Object ID reference (only for VT
version 5 and later): Low byte or high byte of
Macro ID of the Macro to execute (see
Clause 4.6.22.3)
114 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
B.10.1 General
There are four types of output shape object: line, rectangle, ellipse, and polygon. They have similar
relationships and behaviour, but different attributes. Points contained by these objects are always drawn using
a square “paintbrush”, with the actual point being in the upper left corner of the paintbrush. The width of the
paintbrush is given by the line width attribute. The endpoint is relative to the X-Y start location attributes in the
parent object. See Figure B.4 — Output Line object showing start and end points using different brush sizes to
Figure B.8 — Output Polygon types and Table B.26 — Output Line events to Table B.32 — Output Polygon
events
This object outputs a line shape. The starting point for the line is found in the parent object.
Allowed Commands:
Key
Symbol Width Height Direction Attribute: Line Width
a 8 8 0 1
b 9 9 0 2
c 9 9 1 2
d 2 9 0 2
e 1 10 0 3
f 1 1 Any >= 1
g 2 2 Any >= 2
h 9 2 0 2
i 10 2 0 3
Figure B.4 — Output Line object showing start and end points using different brush sizes
116 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
This object outputs a rectangle shape. See Figure B.5 — Output Rectangle object showing end points using
different brush sizes.
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Figure B.5 — Output Rectangle object showing end points using different brush sizes
This object outputs an ellipse or circle shape. Several options are available for modifying the appearance (See
Figure B.6 — Output Ellipse object).
Key
1 start angle
2 end angle
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
1 1
1
2
2 2
a) Correct b) Correct c) Incorrect
Key
1 44°
2 314°
Special care should be used when drawing an ellipse which is not a circle. The drawn angle between the start
and end angles shall be measured to be accurate. For example, in Figure B.7 — Output Ellipse object –
correct and incorrect rendering, the attributes start angle, end angle, and width of all three ellipses are the
same. The ellipse on the left is a circle with the height equal to the width, and the ellipses in the centre and on
the right both have the height equal to half the width. The angle of the opening should be 90° on all three
ellipses. However, the ellipse on the right, was drawn incorrectly using a popular ellipse rendering algorithm
that simply scales the full circle to half height. The result is that the angle of the opening is less than 90°.
NOTE Commonly available displays may not have a square aspect ratio for the pixels. The drawing method
is not required to compensate for the physical display characteristics.
122 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
This object outputs a polygon. Four types of polygon are possible: convex, non-convex, complex and open. If
the type is not open, the Working Set shall specify the type of polygon as this could affect the efficiency of the
fill algorithm. If the type is not known, the type should be set to complex since fill algorithms on complex
polygons will work on all three fillable types. The VT designer may also choose to implement only the complex
fill algorithm and ignore the polygon type attribute. The VT shall use the "even-odd" fill rule. The "non-zero
winding" fill rule is not supported.
The start point for the polygon is the first point listed. Polygon is drawn using the points in the list in the order
given. At least three points are required for a polygon. The point positions are relative to the upper left-hand
corner of the Output Polygon object and the upper left-hand corner of the Output Polygon object is relative to
the parent object.
If the polygon type is not “OPEN” and the Working Set does not close the polygon, the VT shall automatically
close the polygon by joining the first and last points given.
Allowed Commands:
B.11.1 General
There are three types of output graphic object: Output Meter object, Output Linear Bar Graph object and
Output Arched Bar Graph object.
In VT Version 4 and later, if the minimum value is not less than the maximum value, then the object shall be
drawn as if the value (or target value) is equal to the minimum value and without regard to the maximum
value. Additionally, if the value (or target value) is less than the minimum, the object shall be drawn as if the
value (or target value) is equal to the minimum. Likewise, if the value (or target value) is greater than the
maximum, the object shall be drawn as if the value (or target value) is equal to the maximum.
In VT Version 3 and prior, the constraints of minimum, value, target, and maximum were not defined.
This object is a meter. General appearance is left to the VT but the meter is drawn about a circle enclosed
within a defined square. The indicated angle attributes are computed from the positive X axis in a
mathematically positive direction (anticlockwise). As with all objects, the VT shall take appropriate action when
objects are overlaid so that moving the needle does not corrupt other objects underneath the meter. The
position attribute of the meter (in the parent object) always refers to the upper left corner of the enclosing
square regardless of orientation. This object is drawn transparent so that objects can be placed underneath to
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
enhance the appearance. See Figure B.9 — Output Meter object and Figure B.10 — Output Meter object —
examples and Table B.34 — Output Meter events and Table B.35 — Output Meter attributes and record
format.
NOTE It is recommended that the length of any visible tick marks are 10% of the width of the meter, with a minimum
of 1 pixel (e.g. if the meter is less than 10 pixels in width).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 start angle
2 end angle
3 needle
4 arc
5 ticks (only 2 ticks are shown for what would be equally spaced from the start angle to the end angle)
a Meter object cannot exceed boundaries of enclosing square.
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
causes this Macro to execute or 0xFF (see
Clause 4.6.22.3)
{Macro ID} Integer 1 0-255 23… 8-bit Macro Object ID reference: Macro ID of the
Macro to execute.
16-bit Macro Object ID reference (only for VT
version 5 and later): Low byte or high byte of
Macro ID of the Macro to execute (see Clause
4.6.22.3)
Key
a Needle only.
This object is a linear bar graph or thermometer. Linear bar graphs are defined by an enclosing rectangle in
any one of four orientations. A target value can be optionally marked on the bar graph. The position attribute
of the bar graph (in the parent object) always refers to the upper left corner of the enclosing rectangle
regardless of orientation.
Key
1 value
2 target value
3 minimum value
4 maximum value
This object is drawn transparent so that objects can be placed underneath to enhance the appearance. See
Figure B.11 — Output Linear Bar Graph — examples and Table B.36 — Output Linear Bar Graph events and
Table B.37 — Output Linear Bar Graph attributes and record format.
Allowed Commands:
130 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Table B.37 — Output Linear Bar Graph attributes and record format
This object is similar in concept to a linear bar graph but appears arched. Arched bar graphs are drawn about
an Output Ellipse object enclosed within a defined rectangle. The indicated angles are computed from the
positive X axis in a mathematically positive direction (anticlockwise). The position attribute of the bar graph (in
the parent object) always refers to the upper left-hand corner of the enclosing rectangle regardless of
orientation. This object is drawn transparent so that objects can be placed underneath to enhance the
appearance.
A Change Size command can cause the “bar graph width” attribute to equal or exceed one half the width or
height of the object, however this shall not be cause for pool rejection. The VT may reduce the “bar graph
width” value for the purpose of drawing this object. The reduced value is only to supporting drawing the object
and shall not be stored in the object.
See Figure B.12 — Output Arched Bar Graph object — example and Table B.38 — Output Arched Bar Graph
events and Table B.39 — Output Arched Bar Graph attributes and record format.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 start angle 6 border
2 end angle 7 bar graph width
3 value a Enclosing rectangle. Bar graph cannot exceed
4 maximum value boundaries of this rectangle.
5 minimum value b In this example, bar graph deflection is clockwise
c Visual elements outside the range of start angle to end
angle are shown for clarity, but would not be drawn
Allowed Commands:
134
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Table B.39 — Output Arched Bar Graph attributes and record format
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Target line 4 Integer 1 0-255 9 Target line colour (if drawn).
colour
Options 5 Bitmask 1 0-31 10 Logical bits to indicate which parts to draw.
1 = TRUE.
Bit 0 = Draw border
Bit 1 = Draw a target line
Bit 2 = Undefined, set to 0 recommended
Bit 3 = bar graph type. If this bit is FALSE (0),
bar graph is filled. If this bit is TRUE (1), the bar
graph is not filled but rather shows the current
value as a single line at the proper position
within the bar graph.
Bit 4 = Deflection of the bar graph around the
arc. 0 = anticlockwise and 1 = clockwise
Start angle 6 Integer 1 0-180 11 Start angle/2 (in degrees) from positive X axis
anticlockwise (90° is straight up). Start and end
angles define the arc. If the start and end
angles are the same, the bar graph’s arc is
closed (360°).
End angle 7 Integer 1 0-180 12 End angle/2 (in degrees) from positive X axis
anticlockwise (90° is straight up). Start and end
angles define the arc. If the start and end
angles are the same, the bar graph’s arc is
closed (360°).
Bar graph width 8 Integer 2 0-65535 13-14 Bar graph width in pixels. Bar graph width
should be less than half the total width, or less
than half the total height, whichever is least.
(See Figure B.12 — Output Arched Bar Graph
object — example)
Min value 9 Integer 2 0-65535 15-16 Minimum value.
136
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
B.12.1 General
This object displays a picture graphic (bitmap). The VT shall scale the picture graphic from the actual width
and height to the target width and calculated target height. See Table B.40 — Picture Graphic events and
Table B.41 — Picture Graphic attributes and record format.
Allowed Command:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Attribute command. (Any change will be ignored
by the VT.)
Transparency 3 Integer 1 0-255 12 Pixels in the bitmap that have this colour index
colour are transparent (background shows through).
Number of bytes Integer 4 0 to 13-16 Number of bytes in the raw data.
in raw data 2^32-1
Number of Integer 1 0-255 17 Number of Macro references included even if
macros to follow zero. Each Macro reference consists of 2 bytes:
one for event ID and one for Macro ID.
Whenever the indicated event occurs, the
associated Macro is executed.
VT version 5 and later: A reference to a Macro
with 16-bit Object ID shall count as 2 macro
references within the context of this attribute.
Repeat: Integer 1 0-255 18… Raw bytes of graphic data. Bytes shall be
{raw data} interpreted according to the format and options
attributes. For an explanation of raw data
format, (See Clause B.12.2 Picture Graphic
object raw data format and compression)
If monochrome bitmap, each byte contains the
colour indices for 8 pixels beginning at the left
with the most significant bit.
If 4-bit colour bitmap, each byte contains the
colour indices for two pixels beginning at the left
with the most significant nibble.
If 8-bit colour bitmap, each byte contains the
colour index for one pixel.
Bitmap data is always interpreted left to right,
top to bottom of the display. Unused bits at the
end of a line are ignored.
Repeat: Integer 1 0-255 Depends (List these after all objects have been listed.)
{Event ID} on size of 8-bit Macro Object ID reference: Event ID of
bitmap event type that causes this Macro to execute.
data 16-bit Macro Object ID reference (only for VT
version 5 and later): Event ID of event type that
causes this Macro to execute or 0xFF (see
The raw data attribute of the Picture Graphic object contains pixel information line by line, left to right and
downwards. If the width of the object is such that the data does not end evenly at the end of a byte, the
unused portion of the byte at the end of each line is filled with pixel values equal to zero (0). The VT ignores
unused parts of a byte at the end of a line.
Example If the size of the object is 10 pixels wide by two lines high, the format is monochrome and each line is
filled with white coloured pixels. The unused 6 bits in the second byte of each line would be filled with zero and the raw
data would be FF16,C016,FF16,C016. Similar logic is applied for four-bit colour graphics where, if the width is odd, the least
significant nibble of the last byte on each line is set to zero.
If the data is longer than expected after all of the rows and columns of pixels have been defined, then the VT
shall ignore all extra data bytes. However, if the data is shorter than expected leaving some pixels undefined,
then the VT shall report an error to the Working Set. This error shall be reported with either the End of Object
Pool response (See Clause C.2.5) or the VT Change Active Mask message (See Clause H.14).
In order to reduce the amount of data transmitted by the Working Set and maintained by the VT it is
recommended that the smallest version of a picture graphic be transmitted. Therefore, a run-length encoding
scheme may be used to compress the picture graphic data. Care should be taken by Working Set designers
as this algorithm can actually increase the size of the picture graphic data when the object is complex. In this
case, it is recommended that raw data be transmitted instead and Bit 2 of the options attribute should be
cleared.
The compression algorithm is simple and works as follows. Data is transmitted in two-byte pairs with the first
byte representing the number of times the value byte repeats and the second byte representing the value to
repeat. For example, for a raw data sequence of 0,0,0,0,0,0,3,3,3,1,1,2, the compressed data would be
transmitted as 6,0,3,3,2,1,1,2. This example gives a compression of 33 %. If the first byte in a pair has the
value zero, the second byte is ignored.
The run-length algorithm is chosen because picture graphic data can be easily compressed and
uncompressed in real time without the need for a buffer in the VT.
B.13.1 General
Variables are used to store a value that can be referenced and used by other objects. There are two types of
variable object: number and string. Variables are referenced only, never directly included as a child in a parent
object. See Table B.42 — Variable events.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved 139
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
A number variable holds a 32-bit unsigned integer value. See Table B.43 — Number Variable attributes and
record format.
Allowed Commands:
A String Variable holds a fixed length string. Strings shorter than the length attribute should be padded with
space characters. The maximum length attribute cannot be changed once the variable has been defined. See
Table B.44 — String Variable attributes and record format.
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
B.14.1 General
Attribute objects are used to hold common attributes for other objects. Attribute objects are referenced only,
never directly included as a child in a parent object. There are four types of attribute object: font, line, fill and
input. See Table B.45 — Font Attributes events and Table B.46 — Font Attributes attributes and record
format.
The Working Set designer can change the Font Attributes using either the Change Font Attributes command,
the Change Attribute command, or by transferring a new object. The designer should be aware that some
uses of the Change Attribute command may cause the object pool to become invalid (e.g. if the Font size and
Font style attributes are changed to a combination that the VT does not support). The Change Font Attributes
command may be used to achieve the desired results without the invalid pool condition.
Allowed Commands:
b
7 = ISO8859-7 (Greek)
8 – 239 Reserved
b
240 – 254 = Proprietary
255 = Proprietary
If the Font Attributes object applies to a
WideString the Font type is ignored (See Clause
4.6.19.7 String encoding)
a
Font style 4 Bitmask 1 0-127 7 Font style. These may be combined.
0 = Normal Text (default)
0-255
c Bit 0 = 1 = Bold
Bit 1 = 1 = Crossed Out
Bit 2 = 1 = Underlined
a
VT Version 3 and Prior
b
For version 3 and prior VTs, these font types were undefined
c
For version 4 and later VTs
d
Inverting is to exchange background and pen colours. The rules for background transparency shall be applied.
This object holds Line Attributes related to output shape objects. See Table B.47 — Line Attributes events and
Table B.48 — Line Attributes attributes and record format and Figure B.14 — Effect of Line Attribute —
example pattern: 1010….
NOTE The end point of a line can be calculated, but may not be drawn when the Line Attribute is applied.
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Line art 3 Bitmask 2 0-65535 6-7 Bit pattern art for line. Each bit represents a
paintbrush spot. Zero (0) bits are skipped
(background colour) and one (1) bits are drawn
in the line colour. Each bit is the size of the
current paintbrush. For example, 00110011
would represent two skipped paintbrush spots
followed by two paintbrush spots drawn and so
on. See Figure B.14 — Effect of Line Attribute
— example pattern: 1010…
Key:
a Output Line object (width=16, height=1, line attribute: line width=1, line attribute: line art=DC5316)
b Line Attribute binary value superimposed above the rendered Output Line object to show relationship
c Most significant bit of line attribute
d Least significant bit of line attribute
e Output Line object (width=32, height =2, line attribute: line width=2, line attribute: line art=DC5316)
Figure B.13 — Effect of Line Attribute - example of same line art with different width
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
This object holds attributes related to filling output shape objects. See Table B.49 — Fill Attributes events and
Table B.50 — Fill Attributes attributes and record format.
Allowed Commands:
Input String object. The VT shall check this object for valid characters and not permit operator entry of invalid
characters into the input field. This object is referenced by an
Input String object. See Table B.51 — Input Attributes events and Table B.52 — Input Attributes attributes and
record format.
If the
Input String object which references this object does not contain an 8-bit string, or the
Input String object references a String Variable that does not contain an 8-bit string, then no validation shall be
performed.
Allowed Commands:
The Extended Input Attributes object, available in VT version 4 and later, defines the valid or invalid
characters for an
Input String object. The VT shall check this object for valid characters and not permit operator entry of invalid
characters into the input field. This object is referenced by an
Input String object. See Table B.53 — Extended Input Attributes attributes and record format.
If the
Input String object which references this object does not contain a WideString, or the
Input String object references a String Variable object that does not contain a WideString, then no validation
shall be performed.
The character ranges defined in this object may include characters which are not supported by the VT. The
VT shall ignore the unsupported characters but still validate against the remaining characters.
Allowed Command:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Example An Extended Input Attribute object (object id 123416) limiting the input characters to the following ranges:
Allowed Commands:
It is the Working Set responsibility to ensure that the macros, prior to execution, are consistent with the object
pool (e.g. cannot reference missing objects).
NOTE Command packets are defined in Annex F but not all commands are allowed in a Macro.
Allowed Commands:
The object pool may contain more than one Colour Map object. After the pool is loaded the VT uses the
default Colour Map. Upon receipt of a valid Select Colour Map command the VT changes the active palette for
this Working Set. Every object of a Working Set's pool shall be displayed with that Working Set's Colour Map.
The Colour Map object contains the definitions for each of the valid colour index values. Upon selection of a
Colour Map, the resulting Colour Map values shall be valid for the VTs capabilities or the VT will indicate the
failure in the Select Colour Map response message. Therefore, a monochrome VT maintains two entries in the
Colour Map object, where a 256 colour VT maintains 256 entries in the Colour Map object. The Colour Map
object may have capabilities beyond the VT (e.g. a 256 entry Colour Map object may be uploaded for a 2-
colour VT, which will only access indices 0 and 1), but the Colour Map object shall not have fewer colour
indices than the VT capabilities.
A typical VT implementation defines the default palette as shown in Table A.4 — Standard VT RGB colour
palette. The subscript into this array of values is the colour index. The Colour Map object provides one level of
indirection to the RGB table. Figure B.15 — Colour Map object reverses colours – example shows a sample
presentation before and after colours 0 and 1 have been reversed by selecting a Colour Map object with the
values [1, 0, …].
Allowed Command:
Key
1 VT colour index 4 R,G,B value
2 Colour map 5 Example graphic
3 Palette index
contained within a Macro to permit even more efficient updates. Most commands can be carried by one CAN
packet.
The current drawing Context, or attributes of the Graphics Context object are always remembered. Therefore
it is only necessary to set an attribute once when it is intended to be used more than once (refer to example
below). A graphics cursor is defined to indicate the next X/Y location at which to start drawing. Graphics
commands can move the graphics cursor to a new location. Therefore drawing can be thought of as a set of
procedural commands as shown in Figure B.16 — Example drawing with Graphics Context object.
The Graphics Context object has a transparency option, similar to the Picture Graphic object. Therefore it is
possible to create graphics ‘layers” by overlaying two or more Graphics Context Objects. This allows easy
removal or erasure of certain groups of pixels in the object(s). For example, swath lines could be reset without
affected the underlying map image. However, Working Set designers should be cautioned that the Graphics
Context object will likely allocate significant memory in the VT (Canvas Width times Canvas Height or more
bytes on a 256 colour VT) and should therefore be used sparingly and kept small to avoid rejection of the pool
due to memory constraints.
Key
1 Picture graphic object
2 Viewport
3 Graphics context object (entire graphics context referred to as the ‘canvas’)
Figure B.17 — Example application of the Graphics Context object and viewport
Allowed Commands
156 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
B.19.1 General
The Window Mask object, available in VT version 4 and later, is a parent and special mask object that is used
by the VT only in its User-Layout Data Masks. For details, refer to Clause 4.7.1.2 User-Layout Data Mask.
If the Window Mask Window Type is free form (type 0), the Working Set shall scale this object, just as any
other object, to the dimensions of the VT’s Window Cell. The aspect ratio of a Window Cell is predictable
since there are always 12 window cells (2 columns by 6 rows) on each of the VT’s User-Layout Data Masks
which, in turn, are always full mask resolution and square. Therefore, the window Cell Size can be calculated
from the Data Mask size reported by the VT in the Get Hardware response.
Working Sets can participate in the VT’s User-Layout Data Masks, if supported, by placing Window Mask
objects in the object pool.
Allowed Commands:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
7 = 1x1 Horizontal Linear Bar Graph
8 = 1x1 Single Button
9 = 1x1 Double Button
10 = 2x1 Numeric Output Value with units
11 = 2x1 Numeric Output Value, no units
12 = 2x1 String Output Value
13 = 2x1 Numeric Input Value with units
14 = 2x1 Numeric Input Value, no units
15 = 2x1 String Input Value
16 = 2x1 Horizontal Linear Bar Graph
17 = 2x1 Single Button
18 = 2x1 Double Button
Background 1 Integer 1 0-255 7 Background colour.
Colour
Options 2 Integer 1 0-3 8 Option bits:
Bit 0 = Available. If 0 (FALSE) this window is
not available for use at the present time, even
though defined. The VT shall not allow the
operator to map it and if already mapped,
shall blank out the window cell(s) that it
occupies.
Bit 1 = Transparent. If this bit is 1, the
background colour attribute shall not be used
and the Window shall be transparent.
Bits 2-7 = Reserved, set to 0.
Name 3 Integer 2 0-65534 9-10 Object ID of an Output String object or an
Object Pointer object that points to an Output
String object that contains the string that
gives a proper name to this object. The VT
may choose to ignore colour and font
162 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
The Window Mask Type attribute in the Window Mask, along with the object component references in the
object allow the VT to create a uniform look and feel for standardized windows from all Working Sets. In
addition, when the attribute is zero (0 = Free Form) the Working Set may create completely custom
presentation.
When the attribute is 0, the Working Set supplies and positions all child objects contained inside the window.
In this case the Working Set has complete control over the look and feel of the window and the VT shall
render the Window Mask exactly as specified by the child objects, position, size, and transparency attributes
of the Window Mask object and all other formatting attributes.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 1
Description This window displays a single numeric output with units of measure in a single
window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 2
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,
Window Type 2
Description This window displays a single numeric output with no units of measure in a
single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 3
Description This window displays a single string output in a single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced object. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 4
Description This window displays a single numeric input with units of measure in a single
window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 2
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
Window Type 5
Description This window displays a single numeric input with no units of measure in a single
window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
Window Type 6
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Description This window displays a single string input in a single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
Object #1 –
Reference
Input String object (for the string value)
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
Window Type 7
Description This window displays a single horizontal linear bargraph in a single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall supply a Output Linear Bar Graph object in the horizontal position. The bar
graph should increase from left to right but may increase in either direction.
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 8
Description This window displays a single Button object in a single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 1
Object
References
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Object #1 – Button
Reference
VT The VT design is free to format the window as desired, and may ignore colour
Formatting and Font Attributes in the referenced Button object. Field length requirements
and Scaling above shall be met. The VT is free to scale objects, excluding the Window Icon,
if needed or desired but in the case of the Button object shall only maintain or
increase it’s size to avoid clipping child objects.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall also scale the Button object and its children according to these equations:
Child objects shall be similarly scaled. Due to these requirements, the same
Button object in a Data Mask cannot be used in a Window Mask since the scale
factors are different.
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
Window Type 9
Description This window displays two Button objects in a single window cell.
Window Window Icon, Window Title. While both are optional, at least one of these items
Designator shall be displayed by the VT.
Number of 2
Object
References
VT The VT design is free to format the window as desired, and may ignore colour
Formatting and Font Attributes in the referenced Button objects. Field length requirements
and Scaling above shall be met. The VT is free to scale objects, excluding the Window Icon,
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
if needed or desired but in the case of the Button objects shall only maintain or
increase their size to avoid clipping child objects.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall also scale the Button objects and their children according to these
equations:
Child objects shall also be similarly scaled. Due to these requirements, the
same Button object in a Data Mask cannot be used in a Window Mask since the
scale factors are different.
Example
Layout
This figure is an example that shows all components of the window. VT designs
control the formatting and layout of this window.
Window Type 10
Description This window displays a single numeric output with units of measure in two
horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 2
Object
References
Lengths
Window Value: 10 characters (including decimal place if needed)
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 11
Description This window displays a single numeric output with no units of measure in two
horizontal window cells.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 12
Description This window displays a single string output in two horizontal window cells.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 13
Description This window displays a single numeric input with units of measure in two
horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 2
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 14
Description This window displays a single numeric input with no units of measure in two
horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 15
Description This window displays a single string input in two horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Window
Value Type
Input String object
Number of 1
Object
References
Object #1 –
Reference
Input String object (for the string value)
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3.
and Scaling
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 16
Description This window displays a single horizontal linear bargraph in two horizontal
window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 1
Object
References
VT The VT may format the window as desired, and may ignore colour and Font
Formatting Attributes in the referenced objects. Field length shall conform to the above
and Scaling requirements. The VT may scale objects, excluding the Window Icon, if required
or desired.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall supply a linear bargraph object in the horizontal position. Bargraph may
grow in either direction but left to right is recommended.
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Window Type 17
Description This window displays a single Button object in two horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 1
Object
References
Object #1 – Button
Reference
VT The VT design is free to format the window as desired, and may ignore colour
Formatting and Font Attributes in the referenced Button object. Field length requirements
and Scaling above shall be met. The VT is free to scale objects, excluding the Window Icon,
if needed or desired but in the case of the Button object shall only maintain or
increase its size to avoid clipping child objects.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall also scale the Button object and its children according to these equations:
Child objects shall also be scaled accordingly. Due to these rules, it is likely not
possible to use the same Button object in a Data Mask and a Window Mask
since the scale factors are different.
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
Window Type 18
Description This window displays two Button objects in two horizontal window cells.
Window Window Icon, Window Title. While both together are optional, at least one of
Designator these items shall be displayed by the VT.
Number of 2
Object
References
VT The VT design is free to format the window as desired, and may ignore colour
Formatting and Font Attributes in the referenced Button objects. Field length requirements
and Scaling above shall be met. The VT is free to scale objects, excluding the Window Icon,
if needed or desired but in the case of the Button objects shall only maintain or
increase their size to avoid clipping child objects.
Working Set The Working Set has no control over formatting or layout. The Working Set shall
Formatting scale the Window Icon object according to Clause 4.7.15.3. The Working Set
and Scaling shall also scale the Button objects and their children according to these
equations:
Child objects shall also be scaled accordingly. Due to these rules, it is likely not
possible to use the same Button object in a Data Mask and a Window Mask
since the scale factors are different.
Example
Layout
This figure is provided for example only and shows all components of the
window. VT designs control the formatting and layout of this window.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
The Key objects contained in this object shall be a grouping of Key objects, or Object Pointers to Key objects.
The VT shall not allow the operator to break up, even across visible Soft Key page boundaries, this grouping
when mapping the Key layouts and shall require the operator to map the entire group together. This also
means that several Key Cells can be required to represent this object.
Working Sets can participate in the VT’s User-Layout Soft Key Mask, if supported, by placing Key Group
objects in the object pool.
Working Set designers should make the Key Group object transparent. This allows the VT to set the
background colour of each child Key object so that all Keys have the same background colour. If required, the
Working Set can determine the VT’s background colour using the Get Window Mask Data message.
Object Pointer objects pointing to the NULL Object ID reserve a Key object position (the remaining Key
objects do not move up and the trailing Key object can be navigated to.
Allowed Commands:
182 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
An object label is only intended for use by the VT in various proprietary screens and popup messages or
editors, and recommended for use in new Working Set designs. Object Labels are useful in two specific
cases, though not limited to these two:
⎯ It is recommended that Working Set designs provide an object label with a text name for the Working Set
object. This text may be used by the VT to identify the Working Set in proprietary screens and alarms
(e.g. “Planter” could be used to differentiate one Working Set from others).
⎯ It is recommended that Working Set designs provide an Object Label for all input objects. Since popup
editor windows in the VT may cover the focused input object, it is also recommended that VT designs
display the Object Label in the popup editor window so that the operator can recall what is being edited.
An example of such a label could be “Section 1 Width (meters)” and/or an appropriate designator graphic.
Strings in excess of 32 characters may be clipped to 32 characters by the VT. Referenced designator graphics
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
shall fit within a Soft Key designator area (See Clause 4.5.3 Soft Key Mask area and Soft Key designators).
The referenced designator object may contain objects as listed in Object Label graphic representation (See
Table A.2 — Allowed hierarchical relationships of objects). It is not possible to assign more than one label to
an object. When an Object ID, of an object to label, appears more than one time in the Object Label
Reference List, the Object Pool shall be rejected. When an object is used as a label, and this object also has a
label, this latter label shall not be displayed.
To permit disabling an Object Label, both the String Variable reference and the Graphical Reference could be
set to NULL and the VT should be designed to not show an Object Label.
Allowed Commands:
Table B.64 — Object Label Reference List attributes and record format
When an object pool is loaded from non-volatile memory the VT shall clear the Enable bit in the Options
attribute of all External Object Definition objects. See Clause 4.6.11.6. Table B.65 — External Object
Definition events and Table B.66 — External Object Definition attributes and record format.
Allowed Commands:
When an object pool is loaded from non-volatile memory the VT shall clear the Enable bit in the Options
attribute of all External Reference NAME objects.
See Table B.67 — External Reference NAME events and Table B.68 — External Reference NAME attributes
and record format.
Allowed Commands:
⎯ The External Object Pointer, or any directly followed Object Pointer, points to the NULL Object ID,
⎯ If any child object of the External Object Pointer is invalid based on the object hierarchy (See Table A.2 —
Allowed hierarchical relationships of objects).
When an object pool is loaded from non-volatile memory the VT shall set the External Object Id attribute of all
External Object Pointer objects to the NULL object id. This forces the WS to renew the External Object ID.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
See Table B.69 — External Object Pointer events and Table B.70 — External Object Pointer attributes and
record format.
Allowed Commands:
Working Set designers should be aware that the performance of the VT cannot be predicted, so the size of the
individual objects should be small and the refresh rate kept reasonable (200 ms or slower is recommended).
The refresh rate attribute is a suggestion only and cannot be guaranteed by the VT design. The VT may limit
or modify the refresh interval.
The VT shall increment the index Value when this object is enabled and the refresh interval is non-zero and is
a visible member of an active mask and the specified Refresh Interval has expired. When not visible, the
animation timer is suspended, so the index Value shall not be incremented. If multiple instances of this object
are visible, the same referenced object shall be visible in each instance. Further, the Refresh Interval is based
on the object, and shall not be affected by the number of visible instances.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
When the VT prepares to increment the index Value, it shall be range checked against the ‘First Child Index’
and the ‘Last Child Index’. If the index Value < First Child index, it shall be set to the value of the First Child
Index and then incremented (in this case, the object referenced by the First Child Index is not shown). If the
index Value > Last Child Index, it shall be set to Last Child Index and then the behavior is controlled by the
Animation Sequence value in the Options attribute.
The VT shall not display anything for the selected item in the following cases:
⎯ index value is invalid (greater than the number of items in the list minus 1)
⎯ selected list item is a Container, and the Container is in the hidden state
⎯ the object is enabled and any of the following numeric relationships are not true:
Note that this object can contain more child objects than are defined by the range 'First Child Index' to 'Last
Child Index'. This allows the working set to change the animation by changing the values of the 'First Child
Index' and 'Last Child Index' attributes without the need to upload a new child object list.
The Animation object animation sequence may be configured in either Single Shot or Loop modes.
⎯ Single Shot mode: In Single Shot mode, the animation sequence is played only once starting with the List
Index being initialized to the 'First Child Index' value, and ending with the List Index being equal to the
'Last Child Index' value. Once complete, the animation stops and the last child object remains displayed
as long as the object is enabled. The single-shot animation sequence can be altered or replayed by
changing the index Value or by disabling and then re-enabling the object which resets the index Value to
the 'First Child Index'. If this object is initially enabled in the object pool, then the animation is played
starting with the child referenced by the Index value the first time this object is displayed.
⎯ Loop mode: In Loop mode, the animation is repeated as long as the object is enabled. After the child
object at the 'Last Child Index' is displayed, the index Value is reset to the 'First Child Index' attribute
value and the child object at that index is displayed. This cycle repeats until the object is disabled.
If the Working Set changes the index Value at runtime, the current refresh interval is restarted and the
selected object is drawn.
When the Animation object is disabled, the presentation is defined by one of four modes.
⎯ Pause mode: The index Value is unchanged and the child at this index is shown. This mode allows
animations to be enabled and disabled without skipping child objects in the animation.
⎯ Reset to First mode: The index Value is reset to the ‘First Child Index’ when disabled, and the child at this
index is drawn.
⎯ Default Object mode: The index Value is unchanged, however the child at the ‘Default Child Index’ is
drawn.
Allowed Commands:
Annex C
(normative)
⎯ VT to ECU
⎯ ECU to VT
Before a Working Set Master builds an object pool in a VT, it may obtain information about the VT’s
capabilities by using the Get Technical Data messages. Annex D defines messages using the above PGNs to
obtain information about the VT’s characteristics and thus allow each Working Set Master to configure its
object pool to meet the VT’s capabilities.
All VT to ECU and ECU to VT messages where the computed data length is less than 8 bytes shall be padded
to 8 bytes with FF16.
The VT to ECU and the ECU to VT PGN’s are Group Function messages. If a CF receives one of those
PGN’s but with an unknown or reserved command / parameter defined in the first byte it shall respond with a
NACK by using the message Unsupported VT Function message (see Clause F.66) or VT Unsupported VT
Function message (see Clause F.67).
C.2.1 General
This clause specifies the transfer of the object pool via an ISO 11783 network. The PGNs listed above are
used to transfer the object pool to the VT utilizing single packets (not recommended), the transport and
extended transport protocol specified in ISO 11783-3. Destination specific messages shall be used and
Connection Management shall be implemented.
The object pool is considered as one large block of data with each object and its attributes making up a single
192 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
variable length record, as shown in Figure C.1 — Object pool variable length record format. If the total size of
this transfer exceeds the 1 785 byte limit of normal transport protocol, the extended transport protocol
specified in ISO 11783-3 shall be used. The VT design shall be able to support all the transport protocol
functions.
The VT shall receive, parse and store the received objects. If, during parsing, the VT encounters a new object
with an ID matching a previously parsed object (regardless of the object’s type), the new object will be
considered a replacement for the old object. The VT designer determines the method of storage. The format
of the object records was detailed earlier.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Data items and attributes of size greater than 1 byte shall always be transmitted in little endian order (least
significant byte first).
The Working Set Master shall transfer a “clean” object pool, adjusted accordingly for the VT hardware
connected and also adapted to the VT version being reported. Sending an invalid pool with objects or macros
that do not parse properly (e.g. invalid colours) and then altering those objects later with change commands is
not permitted, since this can cause parsing errors and error displays at the VT and could cause the VT to
ignore those objects or macros with errors or to delete the object pool from volatile storage and suspend the
Working Set.
The VT shall identify invalid pools and shall notify the operator about the issue within the object pool.
Error Codes in the End of Object Pool response or errors in the VT Change Active Mask message indicate
that the VT has identified an invalid object pool.
Even if the VT decides to continue with an invalid object pool, the Working Set Master may decide to go to a
safe state when it receives the error indication from the VT.
a) The Working Set Master shall determine if the VT has available memory by transmitting a Get Memory
message (See Clause D.2). The VT shall acknowledge this message with a Get Memory response (See
Clause D.3). VTs which are designed to do so may use this request to allocate memory for the pool. The
Working Set Master shall check the error codes returned. If no error is reported, the Working Set Master
may proceed.
b) The Working Set Master uses single packet (not recommended), transport protocol, or extended
transport protocol (specified in ISO 11783-3), or combinations of these, to move the object pool to the VT
using the object pool transfer message. (See Clause C.2.3 Object pool transfer message). Normal
handshaking, error checking and re-transmission, in accordance with ISO 11783-3, shall be implemented.
Working Set designers should recognize that the VT can send CTS with number of packets set to zero (0)
while other object pools are being loaded and that this could continue for a significant amount of time.
1) The Working Set Master may send several single packet, TP or ETP sessions or a combination of
any of these to transfer the entire pool. This can be required depending on the size of buffers
designed into the Working Set Master. Any number of sessions may be sent before the End of Object
Pool message is sent. Multiple TP and/or ETP sessions can also be required if scaling or pool
adjustments or both have to be made before sending the object pool to the VT.
2) Object records in each session shall be complete and shall not be “split” between sessions of TP or
ETP. Single packet transfers shall contain a complete object.
d) Upon completion, the Working Set Master shall transmit an End of Object Pool message (See Clause
C.2.4) to the VT to indicate that the object pool is now complete and ready for use.
e) When the VT receives the End of Object Pool message, it shall set the "parsing" bit in the VT Status
message to 1 until it has finished parsing the object pool and sends the End of Object Pool response.
f) After sending the End of Object Pool message, the Working Set Master shall wait for an End of Object
Pool response. The Working Set Master shall wait for the End of Object Pool response message until
three consecutive VT Status messages have been received where the "parsing" bit is set to 0. Three
messages are waited for to avoid race conditions created by a VT Status message that may already be in
a transmit queue, which does not correctly identify the parsing state. If the End of Object Pool response is
not received by the Working Set Master, then it shall assume that the End of Object Pool message was
not received by the VT. Under these conditions the Working Set Master may retry the End of Object Pool
message up to three times before it assumes an unexpected shutdown of the VT after which the Working
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Set Master shall obey the requirements of Clause 4.6.9 (Connection management) (Updating pools at
runtime).
g) Commands are sent from a Working Set to the VT using the PGNs given in Annex C. Only Working Set
Masters (not Members) are allowed to send any of the commands in this annex. The originating master
shall wait for a response before sending another command from this Annex.
The following message is sent by a Working Set Master to transfer part of an object pool to the VT.
NOTE Since there is no response to this message, it is recommended to not send single objects that fit within a
single packet.
The following message is sent by a Working Set Master to indicate that the object pool is complete and ready
for use. It is sent after the initial object pool definition and also after any object is redefined or added to the
pool during operation.
This message is sent by the VT to a Working Set Master to acknowledge the End of Object Pool message.
When the VT replies with an error of any type, the VT should delete the object pool from volatile memory
storage and inform the operator by an alarm type method of the suspension of the Working Set and indicate
the reason for the deletion. On reception of this message, the responsible ECU(s) should enter a fail-safe
operation mode providing a safe shutdown procedure of the whole device.
NOTE A VT can take a long time to parse a pool. The End of Object Pool response shall be delayed until this activity
completes. The VT Status message shall reflect the current state of the VT (is busy parsing a pool).
If the Working Set needs to modify or add one or more objects, then the Working Set may update its pool at
runtime. For example, if the Working Set needs to change the size of an object (e.g. increase the length of a
string object) it may send the replacement object with the revised record format. (See Clause 4.6.10.3) This is
accomplished by using the same messages and procedures used to upload the pool at initialization as follows.
a) The Working Set Master shall determine if the VT has available memory by transmitting a Get Memory
message (See Clause D.2 Get Memory message). The Memory Required parameter shall be based on
the size of this update to the pool, and not based on the size of the original pool plus the update. The VT
acknowledges this message with a Get Memory response (See Clause D.3). The Working Set Master
shall check the error codes returned. If no error is reported, the Working Set Master may proceed.
b) The Working Set Master uses single packet transfer (not recommended), extended transport protocol, or
transport protocol, to move the object or objects to the VT. Normal handshaking, error checking and
retransmission, in accordance with ISO 11783-3, shall be implemented. (See Clause C.2.2.b Object pool
transfer procedure)
c) Upon completion, the Working Set Master shall transmit an End of Object Pool message (See Clause
C.2.4) to the VT to indicate that the update is now complete and ready for use.
d) The VT responds with the End of Object Pool response (See Clause C.2.5)
Only those objects that need to be changed should be transmitted during the update; all other objects will
remain in VT memory following the update.
In the case of errors in the update to the object pool, the VT indicates the errors with the End of Object Pool
response. The VT deletes the entire object pool from volatile memory, (including the object pool as it existed
prior to the object pool update) and informs the operator by an alarm type method of the suspension of the
Working Set and indicates the reason for the deletion. On reception of this message, the responsible ECU(s)
shall behave as described (See Clause C.2.5 End of Object Pool response) when an End of Object Pool
response is received indicating errors in the object pool.
The VT shall handle commands and macros from a Working Set even while that Working Set is updating its
object pool.
Example: The operator presses a Soft Key while the pool is being updated by the Working Set. The VT
shall immediately execute the macros triggered and commands sent from that Working Set without waiting for
the completion of the pool update.
The VT shall keep the new/updated objects separate from the original pool, until reception of the End of
Object Pool message. The objects shall be merged into the original pool before the VT sends the End of
Object Pool response. Working Set designers shall be aware that behavior is unpredictable for commands
acting on the new/updated objects if these commands are sent after the End of Object Pool message and
before reception of End of Object Pool response. Such commands will be applied to either the original pool or
the updated pool. Changes to objects shall take effect immediately.
It is recommended that Working Sets do not transmit commands which act upon these new objects until the
End of Object Pool response is received from the VT.
NOTE Changes to objects should utilise Annex F commands when possible rather than performing a pool update
due to the processing time of the pool update process (e.g. Change Size command performs faster than reloading an
object with a new size).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Annex D
(normative)
D.1 General
The technical data messages are used to request the characteristics of the VT. They consist of the request for
data by the Working Set and the response by the VT. The following messages are not allowed in macros.
Working Set masters or members may send any command in this Annex.
The VT shall respond to these commands even if the requesting ECU is not part of a Working Set, thus
permitting ECUs to acquire the VT metrics before connecting.
In version 3 and prior VTs, the “Memory Required” parameter represents the number of bytes in the object
pool (see Clause C.2.1) to be transferred. In version 4 and later VTs, the “memory required” parameter is the
sum of the number of bytes in the object pool to be transferred and the estimated storage of all Graphics
Context objects that are defined in the object pool to be transferred. The Working Set may send less than the
amount communicated in the Memory Required parameter.
The storage space required for a single Object Pool object (OPO) can be determined from the definition of the
specific object.
The storage space required for a single Graphics Context object (GCO) shall be estimated as follows:
Size of a GCO =
where RoundUp is a function that will round the value up to the nearest integer, width and height are
measured in pixels, and the VT.PixelsPerByte is based on the VT capabilities and is defined as
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
follows:
Memory Required =
⎛ size of ( OPO[i ]) ⎟⎞ + ⎜⎛ size of ( GCO[ j]) ⎟⎞
∑ i=1 ∑ j=1
Number of OPO Number of GCO
⎜
⎝ ⎠ ⎝ ⎠
where the second parenthesized term is only used for VT version 4 and later.
For more details on the use of the Memory Required parameter, see Clause C.2.2 for Object pool transfer
procedure and Clause C.2.6 for Updating pools at runtime.
The Working Set should send the Get Memory message with the Memory Required set to zero in order to
receive the response indicating the VT version number. This information may be used to calculate the actual
Memory Required parameter. If the VT design allocates memory based on this message, it should not allocate
any storage for this special case request.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
0010 0000 Flash between inverted and
styles set by bits 0-3
0100 0000 Flash both the background
and
the foreground between
Hidden and styles set by
bits 0-4
1
1000 0000 Proportional font rendering
1
VT version 4 and later
The Get Supported Widechars message is used by the Working Set to determine the WideChars supported
by the VT.
The message only requests characters from a single code plane. If the ECU requires information about
multiple code planes multiple messages shall be sent.
The request contains First WideChar and Last WideChar as a range, where First WideChar <= Last
WideChar.
The ECU can reduce the size of the response frame by sending multiple requests with small inquiry ranges
instead of one request with a large inquiry range.
NOTE The ECU does not have to request this message because the VT shall display WideStrings even if they
contain unsupported characters (See Clause 4.6.19.7 String encoding). The VT shall include the characters from the
WideChar minimum character set when responding to a Code Plane 0 request (See Table L.7 — WideString minimum
character set).
Example Response from a VT supporting only the WideChar Minimum Character Set. The ECU has
requested information about characters 000016 to 3FFF16 in code plane 0.
C116, ; Command
202 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
The Working Set sends the Get Window Mask Data message to request the background colour of User-
Layout Data Mask and the background colour of the Key Cells on a User-Layout Soft Key Mask.
The VT shall return a list of all supported object types including (see Table A.1 — Virtual terminal objects)
⎯ Proprietary object types that the VT supports, which may vary depending on the connected WS, or may
not be listed at all.
The VT and WS may decide by another means which proprietary objects may be supported.
In either case whether the VT lists the proprietary objects in this message or not, the VT may still decide to
reject the object pool from the WS because it included proprietary objects.
The WS may also decide by another means that it does not want to include the proprietary objects listed by
the VT in its object pool.
VTs shall not list Auxiliary Input Type 1 and Auxiliary Function Type 1 objects in the list of supported objects.
Non-proprietary objects that are not listed as supported by the VT shall still be parsed, but they shall not be
functionally supported by the VT. In this way, some Working Sets may choose to use the same object pool in
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
both cases.
Annex E
(normative)
E.1 General
E.1.1 Introduction
The VT provides functions to store and to restore a complete Working Set-specific object pool. When
connecting to the VT, the Working Set can send a message to get its object pool copied from non-volatile
storage into volatile storage. The availability and organization of the non-volatile storage area is VT-specific.
Storing and restoring an object pool includes all object definitions. There shall be a method inside the VT to
assign a stored object pool uniquely to a specific Working Set. Dependant on the VT design, either only a
single object pool or an arbitrary number of pools can be managed for each Working Set. Each pool should be
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
identified by a version label.
Version labels may be displayed to an operator and may be used as a file name. As such the Working Set
shall apply the following rules. Version labels shall be constructed of visible characters from font type zero
(See Table L.1 — ISO 8859-1 (Latin 1) character set). Version labels shall be padded with trailing blanks to
the defined version label size. In addition, the following characters shall not be used in a version label string:
In order to maintain different versions of object pools in the non-volatile storage of the VT, the Working Set
needs to detect those versions currently stored by the VT. It shall also determine if any of the available
versions are suitable for the Working Sets current software version before an object pool is copied into the
object buffer of the VT.
The Working Set should acquire the VT technical data to ensure the stored version is compatible with the
current characteristics. This allows the Working Set to account for changes in the VT characterstics from one
power cycle to another.
The Working Set shall be identified by the entire ISO NAME of the Working Set Master. Each Working Set
Master shall only be allowed to manipulate its own versions of object pools and shall not perform any of the
commands in this Annex on versions of object pools created by other Working Sets. Only Working Set
Masters (not Members) are allowed to send any of the commands in this annex.
NOTE Because non-volatile operations may take an indefinite amount of time to complete, the response message
may be delayed accordingly. Therefore the VT Status message shall reflect the current state of the VT (i.e. is busy). Only
when the VT has completed the non-volatile operations shall it send the response message.
Version labels are defined as a seven character 8-bit string. The permissible messages do not include the
extended versions of the messages in this annex.
Version labels are defined as either a seven character 8-bit string, or a thirty-two character 8-bit string, and the
appropriate messages in this annex shall be used accordingly.
Bytes 2 – 8 Version label 7 character version string, unused bytes filled with spaces. Only
8-bit Strings are allowed.
When the VT receives the Load Version command, it shall set the "parsing" bit in the VT Status message to 1
until it has finished parsing the object pool and sends the Load Version Response message.
The Working Set Master shall wait for the Load Version response until three consecutive VT Status messages
have been received where the "parsing" bit is set to 0. At that time, if the Load Version response has not been
received by the Working Set Master, then it shall assume that the Load Version command was not received
by the VT. Three messages are waited for to avoid race conditions created by a VT Status message that may
already be in a transmit queue, which does not correctly identify the parsing state.
The Delete Version command allows a Working Set to delete a version of an object pool in the non-volatile
storage of the VT. If a copy of this version is in the volatile memory at the same time it is preserved there —
this message affects non-volatile storage only. If the version label contains no string (all blanks) the last stored
version in non-volatile storage is to be deleted.
NOTE To delete the object pool from volatile memory, see Clause F.44 Delete Object Pool command.
When the VT receives the Extended Load Version command, it shall set the "parsing" bit in the VT Status
message to 1 until it has finished parsing the object pool and sends the Extended Load Version Response
message.
The Working Set Master shall wait for the Extended Load Version response until three consecutive VT Status
messages have been received where the "parsing" bit is set to 0. At that time, if the Extended Load Version
response has not been received by the Working Set Master, then it shall assume that the Extended Load
Version command was not received by the VT. Three messages are waited for to avoid race conditions
created by a VT Status message that may already be in a transmit queue, which does not correctly identify the
parsing state.
NOTE To delete the object pool from volatile memory, see Clause F.44 Delete Object Pool command.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved 211
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Annex F
(normative)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
F.1 General
Commands are sent from a Working Set to the VT using the PGNs given in Annex C. Working Set Masters or
members may send any command in this Annex. Additionally, the Identify VT message may be sent from one
VT to other VTs. The originator shall wait for a response up to a maximum of 1,5 s before sending another
command, unless stated otherwise. Each of the commands in the present annex can also be used in a Macro
unless otherwise noted. Working Set designers should recognize that the VT can take a significant amount of
time to respond to a command, especially if the command causes a display refresh (refer to the busy codes in
the VT Status message, in Clause G.2).
Unless otherwise noted any attribute in a response message which also exists in the command message shall
be set to the same value as in the command message, i.e. the response frame reflects the command but not
necessarily the state of the object.
Example: An Enable/Disable Object command is sent with Object Id = 11000 and Byte 4 = 0 (disable). The object is
currently in a state where it cannot be disabled, and therefore it stays enabled. The response frame is sent with Object Id
= 11000 and Byte 4 = 0 (disable) and Error Code indicating the cause of the error.
It is allowed to enable already enabled objects and to disable already disabled objects. If this happens the
response frame shall indicate ‘no errors’ and macros shall be executed.
returned. Depending on byte 4, the object is either selected (has focus) or opened for input (not valid for
Button objects or Key objects).
If the object to be selected is included multiple times on the same mask, it is proprietary to the VT which of the
object instances will be selected (has focus).
NOTE Even if the input field is activated for data input, the value shall not be changed by this command (e.g. Input
Boolean is not toggled).
NOTE This command originates in the Working Set and is a command to the VT. In the situation where the change
originates with the operator, the VT indicates the selected input object with the VT Select Input Object message (see
Clause H.8).
NOTE VT version 3 and prior do not support selection of a Button object or a Key object.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Allowed in a Macro: No
Continuous tones are not recommended, however it is recognized that 255 activations of 65,535 ms each
produces 278 minutes of continuous tone. If this is insufficient, the originating ECU may issue an additional
Control Audio Signal command to the VT prior to the expiration of the tone.
If the VT is capable of supporting the Control Audio Signal command for only a single ECU at a time, then the
Control Audio Signal response shall indicate that the Audio Device is busy. The audio produced by a control
audio command shall never be queued or delayed beyond normal VT message processing. See Figure F.1 —
Acoustic signal termination
Key
1 Working Set 1 sends Control Audio Device command with a total time of 10 seconds.
2 Working Set 2 alarm becomes visible and has acoustic signal other than “none”. VT terminates Working Set 1 audio
and informs Working Set 1. VT proprietary acoustic requires 4 seconds.
If the VT is capable of supporting the Control Audio Signal command for more than a single ECU at a time,
then the audio for each Working Set is not interrupted. See Figure F.2 — Acoustic signal with multisound
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 Working Set 1 sends Control Audio Device command with a total time of 10 seconds.
2 Working Set 2 alarm becomes visible and has acoustic signal other than “none”. VT proprietary acoustic requires 4
seconds.
NOTE The Control Audio Signal command is independent of the currently active Working Set, therefore audio tones
can be commanded whether the originating ECU is the active Working Set, or not. (See Clause 4.6.14 Alarm handling)
This command applies to subsequent Control Audio Signal commands (See Clause F.10) of the issuing
Working Set. This command should also affect the currently playing tone, if any. VTs that are not able to
modify the volume of the currently playing tone shall set the Audio device is busy bit in the response. This
command should not affect in any way the volume settings of other Working Sets and shall not affect the
volume of Alarm Masks.
In VT version 5 and later, the default audio volume is 100% of maximum volume set by the operator.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
The Change Size command is used to change the size of an object. A value of 0 for width or height or both
means that the object size is 0 and the object is not drawn.
NOTE Version 4 and later VTs may support a means to transform the colour table into alternate mapping. (See
Clause B.17 Colour Map object)
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Bytes 5-8 New value for value attribute. Size depends on object type.
Objects of size 1 byte are found in byte 5. Objects of size
2 bytes are found in bytes 5 - 6. Values greater than 1 byte
are transmitted little endian (LSB first). Unused bytes shall be
filled with zero.
Input Boolean object: 1 byte for TRUE/FALSE
Input Number object: 4 bytes for integer input
Input List object: 1 byte for list index
Output Number object: 4 bytes for integer output
1
Output List object : 1 byte for list index
Output Meter object: 2 bytes for integer value
Output Linear Bar Graph object: 2 bytes for integer value
Output Arched Bar Graph object: 2 bytes for integer value
Number Variable object: 4 bytes for integer value
Object Pointer object: 2 bytes for Object ID
2
External Object Pointer object : Bytes 5-6:
External Reference NAME
object ID
Bytes 7-8:
Referenced Object ID
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
2
Animation object : 1 byte for list index
1
VT version 4 and later.
2
VT version 5 and later.
The frequency of update is at the discretion the Working Set designer; however the designer should consider
the limited bandwidth available (see Clause 4.6.10.1).
Bytes 5-8 Value. Size depends on object type. Objects of size 1 byte are
found in byte 5. Objects of size 2 bytes are found in bytes 5 -
6. Values greater than 1 byte are transmitted little endian
(LSB first):
Input Boolean object: 1 byte for TRUE/FALSE
Input Number object: 4 bytes for integer input
Input List object: 1 byte for list index
Output Number object: 4 bytes for integer output
1
Output List object : 1 byte for list index
Output Meter object: 2 bytes for integer value
Output Linear Bar Graph object: 2 bytes for integer value
Output Arched Bar Graph object: 2 bytes for integer value
Number Variable object: 4 bytes for integer value
Object Pointer object: 2 bytes for Object ID
2
External Object Pointer object : Bytes 5-6:
External Reference NAME
object ID
Bytes 7-8:
Referenced Object ID
2
Animation object : 1 byte for list index
1
VT version 4 and later.
2
VT version 5 and later.
3
This bit is only set when the Change Numeric Value command is used to change a pointer value to an
invalid object.
This command is used to change the value of an object. It applies only to objects that have a string “value”
attribute. The size of the object shall not be changed by this command. Only the object indicated in the
command is to be changed, variables referenced by the object are not changed.
If the message contents fit in a single packet, transport protocol shall not be used. If the transferred string has
a length of 3 bytes or less, the remaining bytes in the single packet message shall be set to FF16.
The transferred string is allowed to be smaller than the length of the value attribute of the target object and in
this case the VT shall pad the value attribute with space characters. The number of bytes in the transfer string
(Bytes 4,5) shall be less than or equal to the length attribute of the target object (i.e. string length shall not be
increased).
NOTE Version 4 and later VTs may support a means to transform the colour table into alternate mapping. (See
Clause B.17 Colour Map object)
The VT uses this message to respond to the Change Fill Attributes command.
228 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Bytes 5-8 New value for attribute. Size depends on attribute data type.
Values greater than 1 byte are transmitted little endian (LSB
first). Unused bytes should be set to zero:
Boolean: 1 byte for TRUE/FALSE
Integer: 1, 2 or 4 bytes as defined in
object tables
Float: 4 bytes
Bitmask: 1 byte
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Byte 1 VT function = 17610
Bits 7 - 4 1011 Command Command
Bits 3 - 0 0000 Parameter Change Priority
Bytes 2,3 Object ID of Alarm Mask
Byte 4 New priority
Byte 5 Error Codes (0=no error)
Bit 0 = 1 = Invalid Object ID
Bit 1 = 1 = Invalid priority
Bits 2-3 = Undefined, set to 0 recommended
Bit 4 = 1 = Any other error
Bytes 6-8 Reserved, set to FF16
231
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
⎯ An Unlock command is received and the visible mask has been refreshed
⎯ A timeout occurs based on the timeout attribute of the Lock message
⎯ Navigation to, or activation of input objects or Buttons on the Data Mask
⎯ A change from visible to hidden mask occurs
⎯ The pool is deleted
⎯ A proprietary reason (e.g. an input dialog closes)
When a mask is locked, the on screen presentation of the mask is not updated for any reason. This includes
flashing objects and any animation object that is on the mask. If the Animation object is a timed animation, the
timer will continue to run normally in the background, the animation object will be updated on the non-visible
copy of the mask, but the on screen presentation is not updated until the mask is unlocked.
While locked, CAN messages/commands, key and button presses, events and macros are still processed
normally. When one of the unlock mechanisms occurs, a response message is sent and normal periodic
screen refreshes resume. The lock state does not apply to Soft Key Masks and Alarm Masks which shall be
displayed regardless.
If an Alarm Mask from any Working Set is active when the lock command is received, the lock command is
rejected if the active Alarm Mask is in the same display area.
The VT shall respond as soon as possible to a Lock Mask command. The VT’s response to the Unlock
command depends on whether or not a Data Mask or User-Layout Data Mask is visible. If a Data Mask or
User-Layout Data Mask is hidden (e.g. VT is displaying a home page, setup screen etc), the VT shall respond
to the Unlock command immediately and indicate that the command was ignored. However, if a Data Mask or
User-Layout Data Mask is visible, the VT shall not respond to the Unlock Mask command until the Data Mask
or User-Layout Data Mask has been completely refreshed (all changes during lock made visible to the
operator). If a timeout occurs or a change causing the current Data Mask or User-Layout Data Mask to be
hidden, the VT shall send an unsolicited Lock/Unlock Mask Response message with appropriate error codes
set.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Typically the Working Set would lock the mask, send any necessary change commands, unlock the mask and
then wait for the Lock/Unlock Mask Response message. This will allow mask changes to be synchronized
and made visually atomic. To avoid operator interface lags, navigation problems and timing fluctuations in
flashing objects, it is recommended that locks be applied for very short periods of time, likely measured in (but
not limited to) milliseconds.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Bytes 4-8 Reserved, set to FF16
NOTE To avoid repetitive polygon draws in the case where several points need to be changed, Working Sets could
use the Lock/Unlock Mask command before changing the points.
It is similar to the Change Size command except that is also causes the VT to rescale the polygon points.
When the VT receives this message, it shall change the enclosing area of the polygon (i.e. width and height
attributes) and shall adjust all polygon point positions using the following 32 bit signed integer algorithm:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
new_y = ((old_y * new_height) + (old_height / 2)) / old_height
endif
For drawing, the foreground colour specified is either the foreground colour attribute of the Graphics Context
Object, or the Line Colour specified in the Line Attributes object. Which one is used is determined by the state
of Options bit 1.
For drawing, the background colour specified is either the background colour attribute of the Graphics Context
Object, or the Fill Colour specified in the Fill Attributes object. Which one is used is determined by the state
of Options bit 1.
For drawing text, the foreground colour specified is either the foreground colour attribute of the Graphics
Context Object, or the Font colour specified in the Font Attributes object. Which one is used is determined by
the state of Options bit 1.
For zooming, a zoom value of 1.0 means no magnification or a 1:1 mapping of pixels of the viewport to the
canvas. A zoom value of 2.0 means 2:1 magnification (or zoom in), 3.0 means 3:1 magnification etc. A zoom
value of 0.5 means 1:2 demagnification (or zoom out), 0.25 means 1:4 demagnification etc.
When zooming in, for example, a zoom value of 3.0 for 3:1 magnification, each pixel of the canvas is
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
displayed in the viewport as 3 pixels wide and 3 pixels high.
When zooming out, for example, a zoom value of 0.25 for 1:4 demagnification, each block of 4 pixels wide by
4 pixels high of the canvas are displayed in the viewport as a single pixel. The exact zooming algorithm is VT
proprietary. A closest colour match may be used by the VT when merging or stretching pixels.
Only the viewport is zoomed – not the canvas. The Viewport X and Viewport Y positions are in reference to
the unzoomed canvas. This means that the zoom anchor point is the upper left corner of the viewport.
Zooming without moving the Viewport X and Viewport Y positions, gives the appearance of stretching the
image from the top left towards the bottom right.
238--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved 239
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
17 Change Viewport Size: Bytes 5 - 6 = New 0 to 65535
This command changes the size of the viewport and width
can be compared to the normal Change Size Bytes 7 - 8 = New 0 to 65535
command. The graphics cursor is not moved. height
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
NOTE This message is available in VT version 4 and later.
NOTE If the selected Colour Map object is modified the changes shall take effect immediately.
NOTE A VT can take a long time to process this command. The response message shall be delayed until this activity
completes. The VT Status message shall reflect the current state of the VT (is busy executing a command).
The presentation of the VT Number is considered VT proprietary and the VT designer may choose to present
other information indicating the purpose of the VT Number (See Clause 4.6.25 VT Number).
The VT Number shall be in the range of 1 to 32, corresponding to Function Instances 0 to 31. VTs may then
be referenced as VT Number 1, VT Number 2, etc.
NOTE The offset of 1 is in support of operators, which may not be familiar with a zero-based numbering system.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
NOTE This message is available in Working Sets designed to support VT version 5 and later.
Annex G
(normative)
Status Messages
G.1 General
The status messages allow the Working Set to determine the health of the VT and to monitor the progress of
tasks in the VT. They also allow the VT to monitor the health of Working Sets. These messages are not part of
object pools and are not allowed in macros.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
For VT version 4 and later, a Working Set Master shall listen to this message in conjunction with the VT On
User-Layout Hide/Show message (See Clause H.20) to determine if it is displayed by the VT.
Data traffic with the VT shall not proceed after initialization until the VT Status message is sent from the VT.
(See Clause 4.6.9 Connection management for more information on connection management.) The VT Status
message is sent on change of any of Bytes 2 to 6, or Byte 7 bit 6, and once per second, up to a maximum of
five per second.
Transmission repetition rate: On change of any of Bytes 2 to 6, or Byte 7 bit 6, and once per
second up to 5 messages per second
Data length: 8 bytes
Parameter group number: VT to Global Address
As there are no means for a Working Set member to report its own version number, all members of the
Working Set shall comply to the same version number as reported by the master. For example, a Working Set
Master may report a Version Number that matches the lowest compliant device in the Working Set. The
master and members may use proprietary messages to determine their compliance.
NOTE The Version Number reported in this message determines how the VT responds to commands and messages.
See Clause 4.6.2 Working Sets.
NOTE The Version Number parameter reported by the Working Set Master shall reflect the version of this standard
to which the Working Set (master and members) is designed. It shall not change at runtime due to adaptations to different
VTs. For example, a version 4 Working Set Master would still report version 4 in this parameter, even if the Working Set
falls back to version 3 behavior to upload an object pool to a version 3 VT. The VT may choose to report this or provide it
for diagnostics, but shall not reject communication or the object pool based on the reported Version Number.
Annex H
(normative)
Activation messages
H.1 General
Unsolicited messages are sent from the VT to the Working Set Master using the PGNs given in Annex C. The
Working Set Master may send a response message. All response messages in this annex are optional unless
specifically stated otherwise.
Transmission repetition rate: On key press/release and every 200 ms when key is held.
Data length: 8 bytes
Parameter group number: VT to ECU, Destination-Specific
1
Applies to VT version 4 and later.
1
Applies to VT version 4 and later.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
ECU should process as if the Button was released. (See Clause 4.6.18 Soft Key and Button activation). If the
VT has a means to abort the Button press, it shall send the Button press aborted activation code instead of
the Button press released activation code. (e.g. Press button on touch screen, slide finger off side of button,
abort is sent).
Transmission repetition rate: On button press/release and every 200 ms when button is held.
Latchable buttons do not repeat.
Data length: 8 bytes
Parameter group number: VT to ECU, Destination-Specific
⎯ This message is not used when a button or input object is touched or clicked on. In this case, the Button
Activation message or VT Select Input Object message is sent.
⎯ If held and the interval between messages exceeds 300 ms, then the ECU should process as if released.
⎯ If the VT has a means to support dragging (detect changing coordinates while held) and if the first press
is not on a button or input field and the drag operation subsequently crosses a button or input field this
message shall continue to be sent. It shall not activate the button or input field.
⎯ If the VT has a means to support dragging then the X, Y position shall update to reflect the current
coordinates. (See Clause D.9 Byte 4 bit 1 and bit 5 are set to 1)
⎯ If the VT does not have a means to support dragging but the VT can detect individual press and release
coordinates then the X, Y position while held shall repeat the coordinates at the press position. (See
Clause D.9 Byte 4 bit 1 is set to 1 and bit 5 is cleared to 0)
⎯ If the VT can only detect the press coordinates then the X, Y position in all states is the coordinates at the
press position. (See Clause D.9 Byte 4 bit 1 and bit 5 are cleared to 0)
deselected (loses focus), opened for edit or closed after edit by the operator or an ESC command.
This message may not be sent if the input object that was activated had a complete transaction applied to it as
an atomic operation (e.g. an Input Boolean where the activation simply toggles the value, or an Input Number
where the VT has dedicated increment by 1 and decrement by 1 capability).
NOTE This command originates in the VT as a result of operator interaction. This message is not sent if the Working
Set requested the change in focus with the Select Input Object command (See Clause F.6).
NOTE When a Button or Key Object is the target of selection, it shall not be reported as open for input.
NOTE VT version 3 and prior do not support selection of a Button object or a Key object.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
This message is sent by the VT any time the operator presses the ESC means, and when the VT closes an
open input field due to a Change Active Mask command.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Input Boolean: 1 byte for TRUE/FALSE
Input Number: 4 bytes for integer input
Input List: 1 byte for list index
Number variable: 4 bytes for integer value
NOTE For VT version 4 and prior, byte 4 was not defined
If the error results in object pool deletion, the VT will react to this Working Set as if the VT had detected an
unexpected shutdown of this Working Set. (See Clause 4.6.9)
Note The Change Active Mask response message, also sent by the VT, only acknowledges that the Change Active
Mask command was received and processed and while it has a similar name, it is for a different purpose.
254 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Transmission repetition rate: Optionally, in response to the VT Change Soft Key Mask
message
Data length: 8 bytes
Parameter group number: ECU to VT, Destination-Specific
Input String object or referenced String Variable object. The VT shall not remove leading spaces but it may
pad the string with spaces to the size defined in the object pool. If the
Input String object references a String Variable object, the Object ID of the String Variable object is used in
this message instead of the object id of the
If the message contents fit in a single packet, transport protocol shall not be used. If the transferred string has
a length of 3 bytes or less, the remaining bytes in the single packet message shall be set to FF16.
NOTE When transport protocol is used to communicate the new value, the Working Set may receive other messages
(e.g. the VT Select Input Object message indicating closure of data input, or Soft Key Activation message) prior to the
completion of the transport protocol transaction.
If a VT is ready to make an inactive and visible Working Set active, it shall send first a VT On User-Layout
Hide/Show message to hide the visible Data and Soft Key Mask of the inactive Working Set before the
Working Set is made active as indicated by the VT Status message. In this way the VT communicates to the
WS that the Data and Soft Key Masks are visible. They are visible because the WS is active (indicated by the
VT Status message) and not because it is inactive and visible (indicated by the VT On User-Layout Hide/Show
message).
Transmission repetition rate: On change of any of Bytes 2 to 7 and up to 5 messages per second per mask
annex and is not optional. It shall always be sent in response to a VT On User-Layout Hide/Show message.
Annex I
(normative)
Other messages
The VT shall also support and generate other pertinent messages, as defined in ISO 11783-7. These shall
include, but not be limited to, Language command (PGN 65039), which contains parameters for Units of
Operation and Date and Time formats.
The VT and Working Sets may use Wheel-based speed and distance (PGN 65096) and Maintain power (PGN
65095) in order to monitor the Key switch state, Maximum time of tractor power and to manage shutdown.
(See Clause 4.6.7 System Shutdown)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Annex J
(normative)
Auxiliary control
J.1 General
Auxiliary control allows the operator to control specific functions independent of the VT interface, as long as
the Auxiliary Inputs and Auxiliary Functions maintain the connection between them and with the VT. The VT
Version 2 Auxiliary Control protocol has been superseded in favor of the protocol and algorithms described in
this Annex. The Auxiliary Control protocol and algorithms in VT Version 3 and later are not compatible with the
Auxiliary Control protocol and algorithms in VT Version 2 Working Sets. Auxiliary Inputs (keys, switches, dials,
knobs, sliders), provided by one or more Working Sets (or the VT), are active at all times after being assigned
to an Auxiliary Function - independent of active visible Data Mask and visible Soft Key Mask of the VT. These
inputs are assigned to Auxiliary Functions (i.e. raise/lower, start/stop, set position) and are also provided by
one or more Working Sets (or the VT). The operator may assign the inputs to the functions using a proprietary
auxiliary assignment screen provided by the VT. Once an Auxiliary Input has been assigned to an Auxiliary
Function by the VT, the operator is then able to control the function independent of the active Working Set on
the VT.
VT Version 3 and later use a revised Auxiliary control method and set of messages. To maintain maximum
system compatibility while meeting the objectives of the revised method, both the version 2 and the version 3
Auxiliary control objects and messages are defined in this document. To facilitate easy identification, those
Auxiliary control items specific to VT version 2 have a “Type 1” designation, and those Auxiliary control items
specific to VT version 3 and later have a “Type 2” designation.
When a system of assignments has been made, the Working Sets providing the Type 2 Auxiliary Functions
will store their assignments as their new preferred assignments. Since the preferred assignments are provided
by the Working Sets providing the Auxiliary Functions, factory default assignments may facilitate easy
integration of known Auxiliary Inputs and Auxiliary Functions. A Working Set design may be implemented in a
manner to recognize more than one combination of auxiliary input units and store or provide unique sets of
preferred assignments based on the system of auxiliary inputs available. On later power cycles and as a result
of other specific events, a set of preferred assignments is communicated to the VT for validation across the
complete system.
EXAMPLE An operator prefers to raise and lower a particular implement (a Working Set) at any time, regardless of the
visible masks of the VT. The implement provides a “raise/lower implement” Auxiliary Function. There is an auxiliary input
available, a two position momentary toggle switch, located on the armrest of the tractor of a type that is compatible with
the Auxiliary Function. The operator, using a screen provided by the VT, assigns this switch to the “raise/lower implement”
function. The operator is then able to then raise and lower the implement using the switch on the armrest. From that
moment until power is removed, the function of the switch does not change unless changed by the operator.
Boolean inputs have two states: enabled and disabled (on/off, TRUE/FALSE etc). There are two types of
Boolean inputs, latched and non-latched. Non-latched or momentary Boolean inputs are on or TRUE only
when activated by an operator, i.e. when a button or key is pushed and held.
259
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
Analog inputs are always reported in terms of percentage of maximum value, as follows:
When specifically enabled by the VT, an Auxiliary Input unit sends an Auxiliary Input status message once per
second per input that reports the status of an individual Auxiliary Input. The unit also sends a status message
immediately whenever the value of an Auxiliary Input changes, although at least 50 ms shall elapse between
status messages for a particular input (maximum transmit rate for a particular input is 20 Hz). When held, a
non-latched Boolean input sends its status every 200 ms. The message is broadcast to all Working Sets, and
is not acknowledged.
In some conditions, it is possible that a transition is not communicated to a Auxiliary Function Working Set
(either because the value of a particular input is changing faster than its input unit is able to transmit a status
message, or because a status message has been lost by the Working Set). In these conditions, the Auxiliary
Function Working Set is responsible for determining that one or more transitions have been missed using the
Number of Transitions parameter as is available for some of the auxiliary types.
In order to accommodate Auxiliary Controls in a multiple VT environment, the following general rules apply.
These rules apply even when there is only one VT on the network to avoid VT boot-up time issues:
⎯ Auxiliary assignments shall only be performed at VT function instance zero (0) since this is the VT that
will have all of the Auxiliary Inputs and Auxiliary Function designators. If the operator tries to access
auxiliary assignment screen on a VT that is not function instance zero (0), the VT shall notify the operator
that it is not allowed to perform auxiliary assignments.
⎯ Auxiliary assignment validation shall be performed only at VT function instance zero (0).
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
⎯ VTs with function instance other than zero (0) may receive object pools containing Auxiliary Input and/or
Auxiliary Function objects. These objects will be parsed, but not used in making or validating
assignments. This implies that an object pool could have to be split into two pools. For example, to have
a Working Set display and function on VT function instance one (1) the entire pool (all objects, including
the Auxiliary Inputs and Functions) could be uploaded to VT function instance one (1). In order to control
and make Auxiliary assignments, a pool containing the Auxiliary Inputs and Functions shall be uploaded
to VT function instance zero (0).
⎯ Working Sets using two VT’s on the network shall transmit their Working Set Maintenance message to
both VT’s at the regular interval. The usual connection management rules apply.
The rules of Annex J imply that there shall always be a VT with function instance zero on the network. The
means to configure the primary VT and resolve the function instance zero VT is defined in Clause 4.6.25 VT
Number.
J.4.1 General
Auxiliary Inputs and Auxiliary Functions are defined in the object pools of the Working Sets that provide them.
Auxiliary Inputs are defined using Auxiliary Input objects, and Auxiliary Functions are defined using Auxiliary
Function objects. An Auxiliary Input or Auxiliary Function is uniquely identified to the operator by a
combination of its designator or label representing its type and the designator of its Working Set. In cases
where a unit is used exclusively to provide Auxiliary Inputs (e.g. a switch box), it would use a minimal object
pool, consisting of a Working Set object and one or more Auxiliary Input objects. Transport protocol is used to
transmit the object pool (See Annex C).
Auxiliary control object types 29 and 30 specified in “Table J.1 — Auxiliary Function Type 1 attributes and
record format“ and “Table J.3 — Auxiliary Input Type 1 attributes and record format“ are made obsolete by
version 3 or later of ISO 11783-6. For compatibility to prior versions of ISO 11783-6 compatible Working Sets,
object types 29 and 30 shall be parsed and validated but not utilised in Auxiliary Control Assignments by
version 3 or later VTs (See Clause D.3 Get Memory response). Version 3 and later Working Sets shall not use
object types 29 and 30.
The Auxiliary Function Type 1 object defines the function attributes and designator of an Auxiliary Function.
The VT shall use the attributes of the Auxiliary Function Type 1 object to enforce the rules of assigning an
Auxiliary Input to an Auxiliary Function. For example, a Boolean Auxiliary Function shall only be assigned to a
compatible Boolean Auxiliary Input. Auxiliary Function Designators sent to a VT shall fit within a Soft Key
designator area (See Clause 4.5.3 Soft Key Mask area and Soft Key designatorsSoft Key Mask area and Soft
Key designators
). Any object defining the Auxiliary Function designator located outside the designator area is clipped.
Allowed commands:
⎯ None
Number of Integer 1 1-255 6 The objects that follow are used as the Auxiliary
objects to follow Function designator. Although the use of the
identifier is proprietary to the VT, the set of
objects shall fit inside a Soft Key designator. The
VT clips any object or part of an object located
outside the area of a Soft Key designator.
Repeat: Integer 2 0-65534 7+ Object ID of a picture graphic, output shape, or
{Object ID} object*6 output field used to define the designator of the
Auxiliary Function.
{X Location} Signed 2 -32768 9+ Relative X location of the top left-hand corner of
integer to object*6 the object in VT pixels (relative to the top left
+32767 corner of an Auxiliary Function designator).
{Y Location} Signed 2 -32768 11+ Relative Y location of the top left-hand corner of
integer to object*6 the object in VT pixels (relative to the top left
+32767 corner of an Auxiliary Function designator).
NOTE Object 29 shall be parsed and validated but not utilized by version 3 or later VTs in making Auxiliary Control
Assignments.
Allowed commands:
⎯ None
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
See Table J.5 — Auxiliary Function Type 2
types
{Y Location} Integer 2 -32768 11+ Relative Y location of the top left-hand corner of
to object*6 the object in VT pixels (relative to the top left
+32767 corner of an Auxiliary Function designator).
The Auxiliary Input Type 1 object defines the designator, the key, switch or dial number and the function type
for an Auxiliary Input.
Allowed commands:
⎯ none.
Allowed commands:
⎯ none.
{Y Location} Signed 2 -32768 11+ Relative Y location of the top left corner of the
integer to object*6 object in VT pixels (relative to the top left corner
+32767 of an Auxiliary Input designator).
Each function and input object shall conform to a type specified in Table J.5 — Auxiliary Function Type 2
types. When a function is assigned to an input, their types shall match according to the requirements listed in
Table J.5 — Auxiliary Function Type 2 types. The values shown in the table are transmitted in the status
message. (See Clause J.7.9 Auxiliary Input Type 2 Status message). The VT shall ensure that the input type
of the assigned Auxiliary Input exactly matches the function type of the Auxiliary Function, regardless of
whether the assignment was made by an operator or by a Working Set. The Auxiliary Inputs shall meet the
operator controls requirements specified in ISO 15077.
Value 1:
Value 1:
Boolean – 0 = Off = backward, down, left, or not pressed
0, 1, 2
Non-Latching 1 = Momentary = forward, up, right, or pressed
2
(momentary) 2 = held
Value 2:
Increase value
0 – FFFF16
Value 2:
Number of transitions from Off to not Off since power up
(Momentary to held is not counted). Overflows from
FFFF16 to 0.
Two way analog (return to centre position)
Value 1:
Value 1:
Analog – 0 – 100%
0% = backward, down, left, counter-clockwise
3 return to 50%
100%(FAFF16) = forward, up, right, clockwise
Left/ Right Value 2:
Value 2:
FFFF16
Reserved, set to FFFF16
One way analog input (return to 0%)
Value 1:
Value 1:
Analog – 0 – 100%
0% = backward, down, left, counter-clockwise
4 return to 0%
100%(FAFF16) = forward, up, right, clockwise
Increase value Value 2:
Value 2:
FFFF16
Reserved, set to FFFF16
Three-Position Switch (latching in all positions) (Single Pole,
Three Position, Centre Off)
Dual Boolean - Value 1: Value 1:
Both Latching 0, 1, 4 0 = Off = centre
5 (Maintain 1 = On = forward, up or right
positions) On/ Value 2: 4 = On = backward, down or left
Off/ On 0 – FFFF16 Value 2:
Number of transitions from Off to On since power up.
Overflows from FFFF16 to 0.
266
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
268 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
NOTE Numbers in parenthesis indicate the held-state while the numbers not in parenthesis represent the reported
values for the transition from one state of the switches to the next state.
EXAMPLE Moving the input control from the centre position to the right position is reported as a value of 16.
Holding the control in the right position is reported as a value of 32. Then moving the control from the right position to the
lower right position is reported as a value of 36. Holding the control in the lower right position is reported as a value of 40.
J.4.7.1 Behaviour
Auxiliary Control Designator Type 2 Object Pointers allow the Working Set to place Auxiliary Input Type 2 and
Auxiliary Function Type 2 designators in the Data Mask at Working Set defined coordinates. An Auxiliary
Control Designator Type 2 Object Pointer can point to the NULL Object ID and in this case nothing shall be
drawn unless the pointer type is 2.
This pointer allows an object pool to visually display the currently assigned relationship between its Auxiliary
Inputs and the Auxiliary Functions they control, as well as any Auxiliary Functions and the Auxiliary Input that
controls it. This object has an implied size that is equal to the VT Soft Key designator. (See Clause 4.5.3 Soft
Key Mask area and Soft Key designators) This is a special pointer that allows the VT to combine objects from
different Working Sets into one presentation.
The object behaves similar to an Input List object (See Clause 4.6.17 Operator input) with the following
exceptions:
The VT shall provide a means to expand this object in order to present associated set(s) of Working Set
designator and the auxiliary object designator. The expanded view is VT proprietary. (See Figure J.3 —
Example showing expansion of a single assignment designator and Figure J.4 — Example showing expansion
of a multiple assignment designator)
If the Auxiliary Control designator Object Pointer is of pointer type 0 or 2, then the pointer points to an auxiliary
object or the Working Set object defined within this object pool, and the VT shall display that auxiliary object
designator (pointer type 0) or Working Set designator (pointer type 2).
If the Auxiliary Control designator Object Pointer is of pointer type 1 or 3, then this pointer references Auxiliary
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Object(s) that have an assignment relationship to the object referenced by the auxiliary object attribute within
this object pool. The VT shall display the assigned auxiliary object designator (pointer type 1) or its Working
Set designator (pointer type 3).
Any VT with function instance greater than zero shall not cause auxiliary assignments and cannot have
access to the defined assignments. In this case, when the Object Pointer is of pointer type 1 or 3, the VT shall
use a proprietary means to indicate that there could be assignments associated with this auxiliary object, and
that this VT cannot display the assignments. As the presentation of the designator would be on the Data Mask
of the Working Set, the Working Set may choose to hide this object in order to avoid displaying the proprietary
indicator. (See Figure J.2 — Examples of Auxiliary Function references on Auxiliary Input unit Data Mask)
When there is no assigned object the VT shall indicate no assignment using a VT proprietary method.
Where the Object Pointer is of pointer type 1 or 3, the VT shall display the designator of the referenced object.
When the Object Pointer is of pointer type 1 or pointer type 3, and there are multiple Auxiliary Function
assignments to an Auxiliary Input, then the VT shall use a proprietary means, while in the non-expanded view,
to indicate that a plurality of functions is assigned (See Figure J.2 — Examples of Auxiliary Function
references on Auxiliary Input unit Data Mask). Upon selection of this control these assignments shall be
displayed in an expanded view. (See Figure J.2 — Examples of Auxiliary Function references on Auxiliary
Input unit Data Mask and Figure J.4 — Example showing expansion of a multiple assignment designator)
If the pointer type is 1 with multiple assignments, the VT shall display, in the expanded view, both the
assigned Working Set designators and the assigned Auxiliary Function Type 2 designators via its proprietary
method (see Figure J.4 — Example showing expansion of a multiple assignment designator). If the pointer is
type 3 with multiple assignments, the VT shall display only the assigned Working Set designator via its
proprietary method, even if the same designator appears several times.
Allowed commands:
⎯ none.
Table J.6 — Auxiliary Control Designator Type 2 Object Pointer attributes and record format
Table J.7 — Auxiliary Control Designator Type 2 Object Pointer examples shows examples for usage of
pointer types 0-3, and what information the VT shall display in place of the Auxiliary Control Designator Type 2
Object Pointer when the pointer is not extended. For these examples, a valid assignment of Auxiliary Input AI1
to Auxiliary Function AF1 is assumed.
Key
1 indicating single assignment 5 Auxiliary Input 1
2 VT Proprietary indicating multiple assignments 6 Auxiliary Input 2
3 VT Proprietary indicating no assignments 7 Auxiliary Input 3
4 VT Proprietary indicating assignments unknown 8 Auxiliary Input 4
(for VT with Function Instance > 0) 9 Auxiliary Input 5
Figure J.2 — Examples of Auxiliary Function references on Auxiliary Input unit Data Mask
Key
1 indicating single assignment 5 Auxiliary Input 1
2 VT Proprietary indicating multiple assignments 6 Auxiliary Input 2
3 VT Proprietary indicating no assignments 7 Auxiliary Input 3
4 VT Proprietary indicating assignments unknown 8 Auxiliary Input 4
(for VT with Function Instance > 0) 9 Auxiliary Input 5
10 VT Proprietary for single assignment
Key
1 indicating single assignment 5 Auxiliary Input 1
2 VT Proprietary indicating multiple assignments 6 Auxiliary Input 2
3 VT Proprietary indicating no assignments 7 Auxiliary Input 3
4 VT Proprietary indicating assignments unknown 8 Auxiliary Input 4
(for VT with Function Instance > 0) 9 Auxiliary Input 5
10 VT Proprietary list of assignments for Auxiliary Input 2
Key
1 Auxiliary Function pickup up/down
2 Auxiliary Function back door open/close
3 Auxiliary Control Designators Type 2 Object Pointer where Pointer Type = 2
Figure J.5 — Example showing expansion of Auxiliary Inputs on an Auxiliary Function Data Mask
--```,`,`,,``,,````,,,,,``,`,
⎯ Any additional end of object pool message that changes an Auxiliary Input or Auxiliary Function object
involved in an assignment in a way which would invalidate the assignment, or
⎯ A valid Preferred Assignment command message is received that changes the assignment of Auxiliary
Input or Auxiliary Function objects, or
⎯ On the removal of any object pool that changes the assignment of Auxiliary Input or Auxiliary Function
objects (by intentional deletion or communication loss)
The VT shall validate each Preferred Assignment command. If there exists any error, the entire Preferred
Assignment command shall be ignored and a Preferred Assignment response shall be sent with an
appropriate error code. The assignment process shall not be performed in that case. Examples of errors could
be invalid parameters (incorrect NAME of the Auxiliary Input unit, incorrect object id’s, …).
1) The VT determines which Working Sets provide Auxiliary Inputs. (A Working Set provides an
Auxiliary Input if one or more Auxiliary Input objects are defined in its object pool.)
2) The VT determines the function type (See Table J.5 — Auxiliary Function Type 2 types) and
designator for each Auxiliary Input (as defined in its Auxiliary Input object), and the designator of its
Working Set (as defined in the Working Set object). If the VT provides Auxiliary Inputs, it shall define
a designator for itself and for each of its inputs (proprietary to the VT).
3) The VT determines which Working Sets provide Auxiliary Functions. (A Working Set provides an
Auxiliary Function if one or more Auxiliary Function objects are defined in its object pool.)
4) The VT determines the function type (See Table J.5 — Auxiliary Function Type 2 types) and
designator for each Auxiliary Function (as defined in its Auxiliary Function Type 2 object), and the
designator of the Auxiliary Function Working Set (as defined in the Working Set object). If the VT
provides Auxiliary Functions, it shall define a designator for itself and for each of its functions
(proprietary to the VT).
i) For each Auxiliary Function with an assignment specified within the Preferred Assignment
command, the VT shall interpret this to be an assignment command for this Auxiliary Function.
ii) For each Auxiliary Function without an assignment specified within the Preferred Assignment
command, the VT shall interpret this to be a remove assignment command for this Auxiliary
Function (see J.7.7 Preferred Assignment).
6) The VT shall verify the preferred assignments and already existing assignments of Auxiliary
Functions and Auxiliary Inputs to detect whether there are any conflicts with these assignments. The
VT may inform the Operator about the proposed assignments and may require confirmation (See
ISO 15077). A conflict shall be detected in the following situations:
ii) The ‘Single Assignment’ bit for a function is set to 1 (single assignment) but the associated
Auxiliary Input is or would be mapped to more than one function if the current assignment is
allowed to complete (See Table J.2 — Auxiliary Function Type 2 attributes and record format).
iii) The ‘Single Assignment’ bit for an input is set to 1 (single assignment) but the Auxiliary Input is
or would be mapped to more than one function if the current assignment is allowed to complete
(See Table J.4 — Auxiliary Input Type 2 attributes and record format).
iv) The ‘Assignment Lock’ bit for a function is set to 1, but the associated Auxiliary Input is not the
preferred assignment (See Table J.2 — Auxiliary Function Type 2 attributes and record format).
v) The ‘Critical Control’ bit for an input is set to 0, but the associated Auxiliary Functions ‘Critical
Control’ bit is set to 1 (See Table J.2 — Auxiliary Function Type 2 attributes and record format
and Table J.4 — Auxiliary Input Type 2 attributes and record format).
vi) An attempt is made to assign an Auxiliary Function to more than one Auxiliary Input.
vii) An object pool containing an assigned Auxiliary Input or Function has been removed (by
intentional deletion or communication loss).
i) Send an Auxiliary Assignment Type 2 command with “remove assignment” (set to NULL) to the
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
ii) Alert the operator that the assignment has been removed and that the operator has to re-assign
the function in the VT’s proprietary Auxiliary Control assignment screen
i) Send an Auxiliary Input Status Type 2 Enable command to the Auxiliary Input Working Set
Master to enable the specific Auxiliary Input status message, unless this input status message
has already been enabled.
ii) Send an Auxiliary Assignment Type 2 command to the Auxiliary Function Working Set Master,
unless it has already been assigned.
9) For each Auxiliary Function with no assignments, the VT shall send an Auxiliary Assignment Type 2
command with “remove assignment” (set to NULL) to the Auxiliary Function Working Set Master.
10) For each Auxiliary Input with no assignments, the VT shall send an Auxiliary Input Status Type 2
Enable command to the Auxiliary Input Working Set Master to disable the specific Auxiliary Input
status message, unless this input status message has already been disabled.
The Auxiliary Function Working Set Master shall monitor the assignment status of its Auxiliary Functions.
When the Working Set comes into the “Working State”, but not all Auxiliary Functions which are needed for
proper operation have been assigned to Auxiliary Inputs, the Working Set shall take appropriate action (e.g.
Auxiliary Function Working Set Master may alert the operator that he will have to assign the respective
functions in the VT’s proprietary Auxiliary Control assignment screen).
a) The VT shall not allow manual assignments to an Auxiliary Function until receiving a valid Preferred
Assignment command from the Working Set which provides the function.
b) An Auxiliary Input can be assigned to one or more Auxiliary Functions (one-to-many relationship), except
in the case of Auxiliary Function objects or Auxiliary Input objects that have the ‘Single Assignment’ bit
set. In this case, a one-to-one relationship is enforced.
d) Auxiliary functions can be assigned to any compatible input, except where the Auxiliary Function
"Assignment Lock' bit is set. (See Table J.2 — Auxiliary Function Type 2 attributes and record format)
e) Auxiliary functions can be assigned to any compatible input, except where the Auxiliary Function "Critical
Control” bit is set. (See Table J.2 — Auxiliary Function Type 2 attributes and record format)
f) Auxiliary Inputs shall be assigned only to Auxiliary Functions of the same type. (See Table J.5 — Auxiliary
Function Type 2 types)
g) When the operator has chosen to have an Auxiliary Input assigned to an Auxiliary Function:
i) Send an Auxiliary Input Status Type 2 Enable command to the Auxiliary Input to enable the
specific Auxiliary Input status message. Each Message shall be acknowledged by the Working
Set of the Auxiliary Input.
ii) For each Auxiliary Function assigned (non-conflicting) to this specific Auxiliary Input, the VT shall
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
transmit an Auxiliary Assignment Type 2 command to the Auxiliary Function Working Set
Master, unless it has already been assigned. Each message shall be acknowledged by the
Working Set of the Auxiliary Function.
h) The Auxiliary Function Working Set Master shall store the assignment as the new preferred assignment.
Additionally, it may allocate additional storage to preferred assignments as a means to adapt to various
configurations of Auxiliary Input controls.
i) It is the Working Set responsibility to determine when to commit the current assignments as the
preferred assignments (e.g. upon receipt of assignment command, key off, power fail,
proprietary screen button, or other means).
ii) The Working Set may store its preferred assignment on an available file server as a means to
transfer identical preferred assignments from one Working Set to another "Functionally Identical
WS". Application of this method can improve the consistency of operation from one system to
another.
iii) The Working Set may adapt the Preferred Assignment command to an alternate Auxiliary Input
unit that is a “Functionally Identical WS” to a previously assigned Auxiliary Input unit where the
Model Identification Code is also identical. (See Clause J.7.7 Preferred Assignment command)
i) A particular assignment can be cancelled using one of three methods. A different input can be assigned to
the function (overwriting the assignment), a “NULL” can be assigned to the function (leaving the function
not assigned), or the Working Set can be powered down. In the first two cases:
i) The VT shall send an Auxiliary Assignment Type 2 command to the Auxiliary Function Working
Set to cause the assignment change (overwrite with new Auxiliary Input) or removal (set to
NULL).
Each message shall be acknowledged by the Working Set of the Auxiliary Function.
ii) If there are no other Auxiliary Functions assigned to the same Auxiliary Input, the VT shall send
the Auxiliary Input Status Type 2 Enable command to the Working Set Master of the Auxiliary
Input. The command will disable the specific auxiliary status message. Each message shall be
acknowledged by the Working Set of the Auxiliary Input.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Key
1 Indicates that the status message is terminated
Figure J.6 — Typical message sequence to make assignment and later remove assignment
J.7.1 General
Messages used with Auxiliary Control (See Figure J.7 — Auxiliary control message flow) are:
This command is reserved to maintain visibility to VT version 2 Auxiliary Assignment messages and is not
transmitted by a version 3 or later VT.
This response is reserved to maintain visibility to VT version 2 Auxiliary Assignment messages and is not
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
utilized by a version 3 or later VT. It shall not be sent by version 3 or later Working Sets.
This response is reserved to maintain visibility to VT version 2 Auxiliary Assignment messages and is not
utilized by a version 3 or later VT. It shall not be sent by version 3 or later Working Sets.
Transmission repetition rate: Once per second and on change to a maximum of five messages
per second.
Data length: 8 bytes
Parameter group number: ECU broadcast (VT transmit PGN is used with address set to the
global address)
The VT uses the Auxiliary Assignment Type 2 command to assign or to remove assignment of an Auxiliary
Input to an Auxiliary Function. Once the VT has transmitted an Auxiliary Assignment Type 2 command, it shall
wait for an acknowledgement from that ECU before it assigns another Auxiliary Input to that ECU. If an
acknowledgement is not received after 2 seconds, the VT shall send the command again. After three
unsuccessful attempts, the VT shall alert the operator that the Auxiliary Function is not available.
The operator assigns the inputs to the functions using a proprietary auxiliary assignment screen provided by
the VT. This assignment screen shall enforce the rule that the type of Auxiliary Input can be assigned only to
the same type of Auxiliary Function. Figure J.8 — Auxiliary assignment screen – example illustrates a possible
implementation of an auxiliary assignment screen. Once an Auxiliary Input has been assigned to an Auxiliary
Function, the operator is then able to control the function independent of the operations of the VT.
When the operator has chosen to have an Auxiliary Input Type 2 object assigned to an Auxiliary Function
Type 2 object the store as preferred assignment bit shall be set to 0. Now this assignment shall be stored as
the preferred assignment. In all the other situations it shall be set to 1.
NOTE This figure depicts the logical communication, where a physical implementation may combine Auxiliary Inputs
and functions with the VT.
NOTE Icons may also be used in the designators. Operator interface is proprietary to the VT design.
Permitted remove assignment alternatives are listed below. These alternatives are shown in Figure J.9 —
Permitted remove assignment alternatives.
a) Remove assignment of auxiliary Function that was assigned to a specific Working Set specific Auxiliary
Input (See Figure J.9 — Permitted remove assignment alternatives - 9)
b) Remove assignment of all Auxiliary Inputs from a Working Set (See Figure J.9 — Permitted remove
assignment alternatives - 10)
Key
1 Auxiliary Input 1 6
Assignment
2 Auxiliary Input 2 7
Auxiliary Input 1 Object ID 1
3 Auxiliary Function 2 8
Auxiliary Input 2 Object ID 1
4 Auxiliary Function 2 Object ID 1 9
Permitted remove assignment of a single Auxiliary
5 Auxiliary Function 2 Object ID 2 Input
10 Permitted remove assignment of a Working Sets
Auxiliary Inputs
NOTE This figure depicts the logical communication, where a physical implementation may combine Auxiliary Inputs
and functions with the VT on the VT’s proprietary auxiliary assignment screen.
The ECU shall send the auxiliary assignment response to acknowledge an Auxiliary Assignment Type 2
command. It shall send an acknowledgement within 1 second after receiving a command. If the Working Set
rejects the assignment, the VT shall alert the operator and may disable the Auxiliary Input status message if
this Auxiliary Input is not assigned to other Auxiliary Functions (See Clause J.5.g.ii)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
The preferred assignment command specifies a pre-defined assignment of an Auxiliary Input to an Auxiliary
Function. The Preferred Assignment command message shall not contain references to Auxiliary Input units
that are not on the network. This command shall only be sent by Working Sets that provide Auxiliary
Functions.
A Model Identification Code, as defined by the manufacturer, is a proprietary code that defines a unique model
and version of an Auxiliary Input unit. When a newer and incompatible version of an input unit is created, it
shall be assigned a unique model identification code by the manufacturer.
The Auxiliary Function Working Set shall determine its preferred Auxiliary Input units. Factors that may be
considered are: Model Identification Code and 64-bit NAME (including Function Instance and Manufacturer
Code, excluding Identity Number). This allows an Auxiliary Function to accept another Auxiliary Input unit
which is "Functionally Identical" (example: a planter is connected to a different tractor which has a joystick that
has the same function instance, manufacturer code and model identification code as the original assignment).
NOTE: The Preferred Assignment command indicates the complete set of Auxiliary Function assignments for that Working
Set. Auxiliary functions that are not specifically included in the Preferred Assignment command are, or shall be,
unassigned.
After loading the object pool into the VT, the Preferred Assignment command shall be sent once as a result of
one of these conditions, since no manual assignments can be created until the VT receives the Preferred
Assignment message:
⎯ If the Auxiliary Function Working Set detects a preferred Auxiliary Input unit on the network. The Auxiliary
Function unit shall delay until it receives the Auxiliary Input Type 2 Maintenance message with Status
equal to Ready. Not doing so may result in an Input Object ID(s) not valid error code in the Preferred
Assignment response. The Auxiliary Function Working Set may delay further to allow detection of other
preferred Auxiliary Input units.
⎯ If no preferred Auxiliary Input unit is detected. The Auxiliary Function unit may delay to allow detection of
Auxiliary Input units.
After the initial Preferred Assignment command is sent, only the following trigger conditions may cause the
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
⎯ If the Auxiliary Function Working Set detects a preferred Auxiliary Input unit on the network that was not
previously detected or has reinitialized. The Auxiliary Function Working Set shall delay until it receives the
Auxiliary Input Type 2 Maintenance message with Status equal to Ready. Not waiting for the Ready status
may result in an Input Object ID(s) not valid error code in the Preferred Assignment response.
⎯ When an Auxiliary Input unit for which active assignments exist is removed from the network and/or
reconfiguration with existing (or alternate) Auxiliary Input units is desired.
⎯ Optionally, as a result of operator selection of a different set of preferred assignments via the operator
interface of the Working Set providing the Auxiliary Functions.
⎯ If the Auxiliary Function Working Set has modified its object pool in a manner that can affect the
assignments.
The Preferred Assignment command shall only be sent once per trigger condition.
Upon receipt of the Preferred Assignment command, the VT shall act in accordance with J.5 Automatic
Auxiliary Control assignment.
It is the Working Set responsibility to ensure that each Auxiliary Function Type 2 object ID occurs only once
within this message.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Bytes 16-17 [2 bytes] Object ID of Auxiliary Input
}
}
Example of a Preferred Assignment command (See Figure J.10 — Preferred assignment example)
a) Command [3410]
Key
1 Auxiliary Input 1 6 Auxiliary Input 2 Object ID 1
2 Auxiliary Input 2 7 Auxiliary Function 2 Object ID 1
3 Auxiliary Function 2 8 Auxiliary Function 2 Object ID 2
4 Auxiliary Input 1 Object ID 1 9 Auxiliary Function 2 Object ID 3
5 Auxiliary Input 1 Object ID 7
On initialization and until enabled by the VT, Auxiliary Input units shall not automatically send an Auxiliary
Input status message.
When enabled or in learn mode, the input unit sends a message once per second and immediately whenever
the value of an Auxiliary Input control changes. At least 50 ms shall pass between status messages for a
particular input (maximum transmit rate for a particular input is 20 Hz). The Working Set designer should be
aware that multiple inputs in transition, each transmitting at 20 Hz, may contribute to an already heavily loaded
CAN bus, and should limit the frequency where possible. For example, noise on an analogue input may cause
its value to flutter for a long period of time even though its average value is not changing. When held, a non-
latched Boolean Auxiliary Input control sends its status every 200 ms. If a non-latched Boolean Auxiliary Input
control is held and the interval between messages exceeds 300ms, then the Auxiliary Function Working Set
shall process as if the non-latched Boolean Auxiliary Input control was released.
If an Auxiliary Input is determined to be in an invalid state (e.g. stuck switch or broken wire) at system startup
or during operation, it shall communicate the condition using the Error Range value. It may additionally display
an Alarm Mask on the connected VT.
When not in learn mode, the message shall be sent to the global address to be available to all Working Sets,
and the message is not acknowledged. When in learn mode, the message shall be sent to the VT whose
NAME indicates it is Function Instance zero, and the message is not acknowledged.
NOTE In learn mode, the messages are directed to the VT only to minimize the possibility that an implement would
interpret the message as a command. This may also improve the implementation of this feature in the VT, since it directly
receives this message.
NOTE This message is recommended to be sent at priority 3. This is consistent with the standard recommendations
for a message for control purposes, and prevents this message from being blocked by transport protocol and extended
transport protocol messages.
Transmission repetition rate: Once per second and on change to a maximum of twenty
messages per second. At least 50 ms shall pass between status
messages for a particular input. Every 200 ms, when a non-
latched Boolean input is held.
Data length: 8 bytes
Parameter group number: When not in learn mode: VT to ECU, sent to global address by
the Auxiliary Input unit when enabled.
When in learn mode: ECU to VT, sent to the VT where the
NAME indicates Function Instance zero.
Priority: 3
If Analog Value:
Resolution: 0.00155629 / bit
Offset: 0
Units: %
Valid Range: 000016 - FAFF16
Res. Range: FB0016 - FDFF16
Error Range: FE0016 - FEFF16
N/A Range: FF0016 - FFFF16
If Digital Count:
Valid Range: 000016 – FFFF16
Bytes 6, 7 Value 2 (refer to Table J.5 — Auxiliary Function Type 2 types)
If Analog Value:
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Resolution: 0.00155629 / bit
Offset: 0
Units: %
Valid Range: 000016 - FAFF16
Res. Range: FB0016 - FDFF16
Error Range: FE0016 - FEFF16
N/A Range: FF0016 - FFFF16
If Digital Count:
Valid Range: 000016 – FFFF16
Byte 8 Operating State
Bit 0 = 1 = Learn mode active
Bit 1 = 1 = Input activated in learn mode, bit 0 must be 1
Bits 2-7 = Reserved, set to 0
An Auxiliary Input Working Set (not the individual input controls) shall send an Auxiliary Input Type 2
Maintenance message 10 times per second. The message is broadcast to all Working Sets (global address),
and is not acknowledged. This message shall be monitored by the VT and any Auxiliary Function Working Set
that has been assigned to input controls of that Auxiliary Input Working Set.
If the message is not detected by the Auxiliary Function Working Set for 300 ms, the Auxiliary Function
Working Set shall assume a possible unexpected shutdown of the Auxiliary Input Working Set and shall take
appropriate action, which shall include removing the assignment of all functions from that Auxiliary Input
Working Set.
The VT shall alert the operator if the Working Set for the Auxiliary Functions is present but the associated
Working Set for one or more Auxiliary Inputs is no longer present and an assignment to this Working Set has
previously (in this power cycle) been made. In this case the VT shall send an Auxiliary Assignment Type 2
command to the Auxiliary Function Working Set Master to remove any assignments to this Auxiliary Input that
were previously assigned. According to Clause J.7.5, Byte 10, Bit 7 of the Auxiliary Assignment Type 2
command shall be set to “1”, indicating that the Auxiliary Function Working Set Master shall not store this as
the new preferred assignment.
The Auxiliary Input Working Set shall conform to the connection management requirements defined in Clause
4.6.9. Therefore it shall send a Working Set Maintenance message once per second, in addition to the
Auxiliary Input Type 2 Maintenance message.
A Model Identification code, as defined by the manufacturer, is a proprietary code that defines a unique model
and version of an Auxiliary Input Unit. When a newer and incompatible version of an Auxiliary Input Unit is
created, it shall be assigned a unique Model Identification code by the manufacturer. The Model Identification
code shall not change at runtime.
The Status value indicates the readiness of the Auxiliary Inputs for assignment operations. This Status value
shall be initialized to “Initializing” when this message is started, and it shall be set to indicate “Ready” upon
receipt of an End of Object Pool response where there are no errors or upon receipt of a Load Version
response / Extended Load Version response with no errors indicated. Auxiliary Functions shall use the Ready
indication as a means to trigger the Preferred Assignment command. The Auxiliary Input unit can make run-
time changes to the available Auxiliary Inputs for the following reasons, in which case the Status shall indicate
“Initializing”.
⎯ Auxiliary Input makes available additional inputs in its pool (new input enabled)
Note If an Auxiliary Input device needs to changes its Object Pool because of changes to or the deletion of an
existing assigned Auxiliary Input object in its pool it shall stop transmitting the Auxiliary Input Type 2 Maintenance
message for greater than 500 ms and then re-establish transmission of the message with the status byte set to Initializing,
until after the pool transfer and an End of Object Pool response with no errors is received from the VT. This provides
Working Sets in the system with a means to safely disconnect and connect Auxiliary functions to Auxiliary Inputs. For all
changes made to Auxiliary Input objects that are NOT assigned to a function in the system, a transition of the status byte
from Ready to Initializing shall be used.
NOTE This message is recommended to be sent at priority 3. This is consistent with the standard recommendations
for a message for control purposes, and prevents this message from being blocked by transport protocol and extended
transport protocol messages.
The VT uses the Auxiliary Input Status Type 2 Enable command to enable or disable the Auxiliary Input status
message. This has the dual purpose of reducing unnecessary network messaging, and reducing the
possibility of an Auxiliary Function responding to an unassigned Auxiliary Input.
Once the VT has transmitted an Auxiliary Input Status Type 2 Enable command, it shall wait for an
acknowledgement from the Auxiliary Input before a function will be assigned to this input. If an
acknowledgement is not received after 2 seconds, the VT shall send the command again. After 3
unsuccessful attempts, the VT shall alert the operator that the Auxiliary Input is not available.
The ECU shall send this message to acknowledge an Auxiliary Input Status Type 2 Enable command.
Transmission repetition rate: In response to an Auxiliary Input Status Type 2 Enable command
Data length: 8 bytes
Parameter group number: ECU to VT, Destination-Specific
The Auxiliary Capabilities request permits any ECU to query the VT for the capabilities of Working sets which
support Auxiliary Inputs or Auxiliary Functions, as specified in Byte 2. This request is sent to the VT with
function instance zero only.
A Working Set with Auxiliary Functions may use this request to identify the capabilities of the Auxiliary Input
units as a method to provide Auxiliary Functions that will best support the current system.
The ECU may choose to monitor each instance of the Auxiliary Input Type 2 Maintenance message for the
“Ready” status, prior to sending this request.
The VT shall send this message in response to the Auxiliary Capabilities request. This message provides the
Auxiliary Input and Auxiliary Function capabilities, of the Auxiliary devices that have successfully sent their
object pools to the VT.
Contained in this response is a complete listing of the known auxiliary units (input or function), and Set
Information (see Table J.8 — Set Information) within each unit. This information may be used to enable the
auxiliary functions according to the available auxiliary inputs. This information may also be used for diagnostic
purposes.
As long as “learn mode” is enabled, the VT shall indicate this in its VT Status message (see Clause G.2).
⎯ Any Auxiliary Input shall send the Auxiliary Input status message (see Clause J.7.9 Auxiliary Input Type 2
Status message) at the normal rate even if not enabled by the VT. The PGN used to send this message is
defined in Clause J.7.9.
⎯ The VT shall monitor the Auxiliary Input status message(s) and assign the actual selected Auxiliary
Function to the respective Auxiliary Input (it is proprietary to the VT how to display/select Auxiliary
Functions for assignment).
⎯ The Auxiliary Function Working Sets shall not perform any Auxiliary Function caused by Auxiliary Input
Status messages if the VT Status message indicates learn mode.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Annex K
(normative)
K.1 General
The VT shall use the transport protocol and extended transport protocol messages defined in ISO 11783-3 for
the transfer of data messages longer than 8 bytes.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
Annex L
(normative)
Character sets
The following tables are for reference only. Refer to the individual ISO documents for the most accurate
representation of the character sets.
The table horizontal boldface characters are the single hexadecimal digit representing the lower nibble of the
code for the character. Vertical boldface characters are the hexadecimal digits representing the upper
nibble(s) of the code for the character (e.g. @ = 4016 = 0100 00002).
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ - ® ¯
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
B ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
C À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
D Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
E à á â ã ä å æ ç è é ê ë ì í î ï
F ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 Non-printing characters in strings for processing rules
0016 Causes termination of the string presentation
0 1 2 3 4 5 6 7 8 9 A B C D E F
0
LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP ¡ ¢ £ € ¥ Š § š © ª « ¬ - ® ¯
B ° ± ² ³ Ž µ ¶ · ž ¹ º » Œ œ Ÿ ¿
C À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
D Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
E à á â ã ä å æ ç è é ê ë ì í î ï
F ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 Non-printing characters in strings for processing rules
0016 Causes termination of the string presentation
NOTE Version 2 and prior VTs had 4 errors in the ISO 8859-15 table that are corrected in Version 3:
A616 Version 2: Ŝ, Version 3: Š
A816 Version 2: ŝ, Version 3: š
B416 Version 2: Ẑ , Version 3: Ž
B816 Version 2: ẑ , Version 3: ž
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m N o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP Ą ˘ Ł ¤ Ľ Ś § ¨ Š Ş Ť Ź - Ž Ż
B ° ą ˛ ł ´ ľ ś ˇ ¸ š ş ť ź ˝ Ž ż
C Ŕ Á Â Ă Ä Ĺ Ć Ç Č É Ę Ë Ě Í Î Ď
D Đ Ń Ň Ó Ô Ő Ö × Ř Ů Ú Ű Ü Ý Ţ ß
E ŕ á â ă ä ĺ ć ç č é ę ë ě í Î ď
F đ ń ň ó ô ő ö ÷ ř ů ú ű ü ý Ţ ˙
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 for processing rules
0016 Causes termination of the string presentation
NOTE: This character set is required in VT version 4 and later.
296 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP Ą ĸ Ŗ ¤ Ĩ Ļ § ¨ Š Ē Ģ Ŧ - Ž ¯
B ° ą ˛ ŗ ´ ĩ ļ ˇ ¸ š ē ģ ŧ Ŋ ž ŋ
C Ā Á Â Ã Ä Å Æ Į Č É Ę Ë Ė Í Î Ī
D Ð Ņ Ō Ķ Ô Õ Ö × Ø Ų Ú Û Ü Ũ Ū ß
E ā á â ã ä å æ į č é ę ë ė í î ī
F đ ņ ō ķ ô õ ö ÷ ø ų ú û ü ũ ū ˙
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 for processing rules
0016 Causes termination of the string presentation
NOTE: This character set is required in VT version 4 and later.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m N o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP Ё Ђ Ѓ Є Ѕ І Ї Ј Љ Њ Ћ Ќ - Ў Џ
B А Б В Г Д Е Ж З И Й К Л М Н О П
C Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
D а б в г д е ж з и й к л м н О п
E р с т у ф х ц ч ш щ ъ ы ь э Ю я
F № ё ђ ѓ є ѕ і ї ј љ њ ћ ќ § Ў Џ
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 for processing rules
0016 Causes termination of the string presentation
NOTE: This character set is required in VT version 4 and later.
298 --```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
© ISO 2014 – All rights reserved
Copyright International Organization for Standardization
Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=ahmadi, rozita
No reproduction or networking permitted without license from IHS Not for Resale, 01/26/2015 09:54:37 MST
ISO 11783-6:2014(E)
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 LF CR
1
2 space ! " # $ % & ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
4 @ A B C D E F G H I J K L M N O
5 P Q R S T U V W X Y Z [ \ ] ^ _
6 ` a b c d e f g h i j k l m n o
7 p q r s t u v w x y z { | } ~
8
9
A NBSP ‘ ’ £ € ₯ ¦ § ¨ © ͺ « ¬ - ―
B ° ± ² ³ ΄ ΅ Ά · Έ Ή Ί » Ό ½ Ύ Ώ
C ΐ Α Β Γ ∆ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο
D Π Ρ Σ Τ Υ Φ Χ Ψ Ω Ϊ Ϋ ά έ ή ί
E ΰ α β γ δ ε ζ η θ ι κ λ µ ν ξ ο
F π ρ ς σ τ υ φ χ ψ ω ϊ ϋ ό ύ ώ
Indicates control codes and shall not be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 for processing rules
0016 Causes termination of the string presentation
NOTE: This character set is required in VT version 4 and later.
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---
0 1 2 3 4 5 6 7 8 9 A B C D E F
000 LF CR
001
002 space ! " # $ % & ' ( ) * + , - . /
003 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
004 @ A B C D E F G H I J K L M N O
005 P Q R S T U V W X Y Z [ \ ] ^ _
006 ` a b c d e F g h i j k l m N o
007 p q r s t u V w x y z { | } ~
008
009
00A NBSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ - ® ¯
00B ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
00C À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
00D Ð Ñ Ò Ó Ô Õ ö × Ø Ù Ú Û Ü Ý Þ ß
00E à á â ã ä å æ ç è é ê ë ì í î ï
00F ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý Þ ÿ
0 1 2 3 4 5 6 7 8 9 A B C D E F
010 Ā ā Ă ă Ą ą Ć ć Ĉ ĉ Ċ ċ Č č Ď ď
011 Đ đ Ē ē Ĕ ĕ Ė ė Ę ę Ě ě Ĝ ĝ Ğ ğ
012 Ġ ġ Ģ ģ Ĥ ĥ Ħ ħ Ĩ ĩ Ī ī Ĭ ĭ Į į
013 İ ı IJ ij Ĵ ĵ Ķ ķ ĸ Ĺ ĺ Ļ ļ Ľ Ľ Ŀ
014 ŀ Ł ł Ń ń Ņ ņ Ň ň ʼn Ŋ ŋ Ō ō Ŏ ŏ
015 Ő ő Œ œ Ŕ ŕ Ŗ ŗ Ř ř Ś ś Ŝ ŝ Ş ş
016 Š š Ţ ţ Ť ť Ŧ ŧ Ũ ũ Ū ū Ŭ ŭ Ů ů
017 Ű ű Ų ų Ŵ ŵ Ŷ ŷ Ÿ Ź ź Ż ż Ž Ž
0 1 2 3 4 5 6 7 8 9 A B C D E F
02C ˆ ˇ ¯
02D ˘ ˙ ˚ ˛ ˜ ˝
0 1 2 3 4 5 6 7 8 9 A B C D E F
037 ;
038 ΄ ΅ Ά · Έ Ή Ί Ό Ύ Ώ
039 ΐ Α Β Γ ∆ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο
03A Π Ρ Σ Τ Υ Φ Χ Ψ Ω Ϊ Ϋ ά έ ή ί
03B ΰ α β γ δ ε ζ η θ ι κ λ µ ν ξ ο
03C π ρ ς σ τ υ φ χ ψ ω ϊ ϋ ό ύ ώ
0 1 2 3 4 5 6 7 8 9 A B C D E F
040 Ё Ђ Ѓ Є Ѕ І Ї Ј Љ Њ Ћ Ќ Ў Џ
041 А Б В Г Д Е Ж З И Й К Л М Н О П
042 Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
043 а б в г д е ж з и й к л м н о п
044 р с т у ф х ц ч ш щ ъ ы ь э ю я
0 1 2 3 4 5 6 7 8 9 A B C D E F
045 ё ђ ѓ є ѕ і ї ј љ њ ћ ќ ў Џ
20A €
Indicates character codes which shall not be displayed.
Blank Indicates character codes which are not compulsory but may be displayed.
NBSP Non-breaking space (word-wrap rules do not apply)
CR,LF See Clause 4.6.19.6 for processing rules
000016 Causes termination of the string presentation
NOTE: This character set is required in VT version 4 and later.
Bibliography
[1] SAE1) J 1939/72, Recommended Practice for Serial Control and Communications Data Network —
Part 72: Virtual Terminal
[2] DIN2) 9684-4, Agricultural tractors and machinery — Interfaces for signal transfer — Part 4: User terminal
[3] ISO 7498, Information processing systems — Open Systems Interconnection — Basic Reference Model
[4] ISO 11519-1, Road vehicles — Low-speed serial data communication — Part 1: General and definitions
[5] ISO 11898, Road vehicles — Interchange of digital information — Controller area network (CAN) for high-
speed communication
[6] ISO 639 (all parts), Codes for the representation of names of languages
[7] ABRASH, M. Zen of Graphics Programming. Scottsdale, AZ: The Coriolis Group Inc. 1996
[8] FOLEY, J., et al. Computer Graphics: Principals and Practise, Second Edition in C Reading MA: Addison-
Wesley, 1996
[9] MURPHY N. GUI Development: Embedding Graphics, Part I. Embedded Systems Magazine, July, 1999
[10] MURPHY N. GUI Development: Embedding Graphics, Part II. Embedded Systems Magazine, August, 1999
[11] ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1:
Latin alphabet No. 1
[12] ISO/IEC 8859-15:1999, Information technology — 8-bit single-byte coded graphic character sets —
Part 15: Latin alphabet No. 9
[13] ISO/IEC 10646:2012, Information technology — Universal Coded Character Set (UCS)
--```,`,`,,``,,````,,,,,``,`,,-`-`,,`,,`,`,,`---