ISOBUS Conformance Guide

This section describes requirements to be able to pass AEF software conformance tests.

This guide is focused on application design requirements and limitations. It does not describe AEF procedures in detail.

General requirements

The following is required to be able to create conformance tested products:

• AEF membership

• AEF ISOBUS database account with at least standard level license

  • It is not possible to create end-user products with basic level license

  • Requires registration to the database

• SAE J1939 manufacturer code

  • Manufacturer code is used in address claiming name

Development environment

The software development requires the following versions or newer:

• SDK 3.1

• MultiTool 5.9 or MultiTool Creator

• Python and code template components from SDK 3.1 or later

• CODESYS 2.3 common libraries:

  • ISOBUS.lib 1.1.2

  • ISOBUS_VT.lib 1.2.4

  • ISOBUS_TC.lib 1.2.2

  • ExtraBins.lib 1.1.0

  • J1939.lib 1.2.7

  • AddressClaiming.lib 1.0.0

• CODESYS 2.3 platform specific libraries:

  • 3000ext.lib 1.3.0

  • 3000CANVXD.lib 1.5.1

Additionally, ISOBUS AUX-N Functionality requires the following versions or newer:

• SDK 4.1

• MultiTool 6.9 or MultiTool Creator

• Python and code template components from SDK 4.1 or later

• CODESYS 2.3 common libraries:

  • ISOBUS.lib 1.2.1

  • ISOBUS_VT.lib 1.4.9

  • J1939.lib 1.3.5

  • AddressClaiming.lib 1.1.1

See also How to use AUX Functions for AUX-N implementation guide.

ISOBUS compatible hardware

The used hardware variant needs to be ISOBUS hardware tested.

MultiTool 5.9 or later, or MultiTool Creator automatically includes hardware identifier default values in the diagnostic message when a new control unit is created.

The following firmware version is required:

• 3000 series: 1.172 or later

ISOBUS standard requires CAN sample point to be 80% (+/- 3% tolerance).

The CAN sample point is configured by code template when MultiTool 5.9 or later, or MultiTool Creator is used.

SUT configuration file

AEF software conformance test is configured by SUT (System Under Test) file.

This can be created with SUT editor which is available from the AEF ISOBUS database.

For more information, see also ISOBUS SUT configuration.

AEF ISOBUS Functionalities

The following functionalities have been pre-tested:

• Minimum Control Function

  • This functionality is always required for SW conformance

  • Mandatory requirements are fulfilled when ISOBUS diagnostics are selected in use in MultiTool

  • AEF test revisions:

    • 2018 / R2

    • 2020 / R3

• Universal Terminal client

  • UT2.0 - VT version 3

  • AEF test revisions:

    • 2018 / R2

    • 2020 / R3

• Task Controller client

  • TC1.0 - TC version 3

    • TC-BAS

    • TC-GEO

    • TC-SC

  • AEF test revisions:

    • 2018 / R2

• AUX-N Function 1.0

  • AEF test revisions:

    • 2020 / R3

Common application requirements

1. Saving address claiming current address to non-volatile memory and restoring on bootup shall be implemented (ISO 11783-5: 2011 chapter 4.3.3.4).

• By default application uses the source address set in MultiTool Creator.

Example codeExample code

2. It is recommended to set 500ms monitoring time delay for address claim server.

When AUX-N Functions are used this is mandatory.

Delay is used to detect if address claim device has disappeared from ISOBUS when new address claim request is sent and previously present device does not respond anymore.

Example codeExample code

VT application requirements

There are no VT specific requirements for the conformance test that the application needs to implement.

To maintain compatibility, the VT client library needs to adjust the application's object pool to the VT terminal's capabilities.

The following are examples of what the VT client library will adjust before loading object pool to terminal:

• Object X / Y - coordinates when terminal resolution differs from object pool

• Object dimensions (width, height) when terminal resolution differs from object pool

• Remove attribute options (e.g. font attributes) which are not supported by terminal

• Change font size if selected size is not supported by terminal

• Reduce amount of keys in softkey mask if terminal does not support enough virtual keys

  • In this case application can change to different softkey mask during runtime if necessary

  • All key objects remain in the object pool even if displayed key amount in softkey mask is lowered

• AUX-N Function related objects are not loaded if VT server is not version 3 or higher

AUX-N Function application requirements

The application will be conformance capable if it's implemented following the How to use AUX Functions guide.

TC application requirements

1. Object pool xml file shall reference to each variable in only one element (one DOR for each variable's object ID).

• If same DDI is needed multiple times (e.g. DDI 141 actual work state), then own variable (DPT or DPD) with unique object ID is created for each reference.

ExampleExample

2. Application shall check TC metrics for how many booms, sections and control channels the server supports.

• Application shall re-configure its object pool elements to meet server limits when necessary

• Use ISOBUS_TC_ConfigurePool (FUN) to disable elements if needed

• When e.g. section amount is lowered, application needs to adjust its dimensions and offsets (combine multiple elements into one)

3. If application implements TC-GEO, it shall also implement TC-BAS (ISO 11783-10:2015 chapter F.2.2). In this case TC-BAS is automatically selected by MultiTool Creator.

• TC client library includes total counter function blocks for most common types

See also

• ISOBUS SUT configuration

• ISOBUS_TC_ConfigurePool (FUN)

• How to use AUX Functions

• How to set VT preferred instance and move to another VT