through opera-tor inputSCM_B: operator Input: “Master OFF SCM_L: Normal sequence end SCM_C: operator input: “Start Recording” SCM_M: any SCC sent SCClientAbort messageSCM_D: operator inp
General
ISO 11783 specifies a control system that enables agricultural machines to perform automatic functions such as headland turns and waterway traverse control in the field This system allows operators to automate a series of tractor and implement operations, enhancing efficiency and reducing manual effort By automating functions typically activated manually, it streamlines fieldwork, improves precision, and increases productivity during farming tasks.
The sequence control system is comprised of a master controller and multiple client units that communicate via the ISO 11783 network, ensuring efficient coordination ISO 11783 specifies the data formats, requirements, and communication services necessary for seamless interaction among cascade functions (CFs) within the sequence control system This standardized communication protocol enables reliable data exchange and synchronized operations across all connected components.
During the recording phase of the Smart Control (SC), the operator activates all client functions sequentially using the SCC operator interface, capturing manual operations for automation The SCM receives information about these activated client functions via client commands from the CFs communicating over the ISO 11783 network It then stores the sequence of client functions along with trigger information for playback These stored sequences can be replayed multiple times upon operator command, with the SCM transmitting client commands to the SCCs once specific trigger points are reached during playback Each SCC executes the commanded functions as if they were manually activated, maintaining independent operation without requiring direct communication between SCCs.
Each sequence has a unique identifier within the SC, but it is up to the SCM implementation to determine how operators can differentiate between multiple sequences, such as associating proprietary names with each one The SCM can group multiple sequences, like approaching and leaving the headland, under a single descriptor like “Seeding.” On the user interface, recorded sequences are indicated with icons or text designators representing their respective functions or actions Operators may have the ability to manually define or edit sequences by adjusting trigger points or other function parameters, depending on the SCM implementation Additionally, the SCM might allow operators to store and reload sequences for future use on the same machine configuration, such as a specific tractor-implement setup.
The SCM offers a user-friendly interface for setting up sequences, including options to record or edit them, ensuring seamless customization It also enables operators to activate the playback of selected sequences efficiently Additionally, the SCM provides configurable options to facilitate system setup and adjustments, enhancing overall operational flexibility and ease of use.
The SCM facilitates the display of identified SCCs, along with their automated and recordable functions, actions, and preferred trigger options for operator review It enables operators to activate or deactivate specific SCCs on the network, helping to simplify system configuration during recording and editing processes while reducing bus load Importantly, the SCM includes only the enabled SCCs in sequence management, ensuring efficient and streamlined operation.
The support of a sequence control system may be implemented by any CF connected to the ISO 11783 network.
Sequence control user interface
The SCM will feature a user interface designed for warnings and operator interactions, connecting seamlessly to the VT It will enable the upload of the main screen layout (object pool), ensuring efficient monitoring and control This integration enhances overall system usability and responsiveness, aligning with best practices for user-centric design and SEO optimization.
VT and object pools are defined in ISO 11783-6).
To enable optional SCM features such as viewing sequence details, SCCs must provide both graphical and textual representations of their sequence control functions Offering both a textual designator and a graphic for each SCD object allows the SCM implementation the flexibility to display SCC objects using text only, graphics only, or a combination of both, enhancing clarity and user experience.
This communication concept leverages the External Object Pointer introduced in VT version 5 (per ISO 11783-6) to eliminate the need for the SCM to manage large graphic objects or language updates for individual SCCs Individual SCCs or their working set master load their graphic and text objects into the same VT used by the SCM, referencing them through the SCCOP The SCM then incorporates External Object Pointer references within its data masks, enabling the VT to display specific information on the SCM's screen by linking to objects in the referenced SCCOP.
The SCM and the working set master of the SCCWS must connect and upload their object pool to the VT using function instance 0 to minimize synchronization overhead, enabling seamless data sharing between the SCM and SCCs However, this setup may require an SCCWS to maintain two parallel VT connections if main operator interactions are handled through an additional VT with a function instance greater than zero This approach adheres to the Auxiliary Control definitions in ISO 11783-6, allowing SCCWS to merge and share objects across functionalities within a single SCCOP Additionally, it supports the use of different languages and character sets, such as Unicode, for textual representations directly between the SCC and VT, enhancing flexibility without requiring SCM intervention.
SCC UI object pool Objects for main user interface of SCC
SCMOP SCM user interface including references to text & graphic objects in individual SCOPs
SCD With reference information to text & graphic objects
Figure 1 — User interface communication concept
During initialization, the SCM uploads a new or reactivates its previous loaded object pool to the VT.
The SCM can utilize external object pointer references to text and graphic objects within the SCCOP of its clients to display information such as sequence details These external reference objects are defined according to ISO 11783-6, ensuring standardized communication and compatibility.
The external object pointer concept is NAME-based, ensuring proper identification of SCCOP and SCCWS in object references The SCMOP incorporates External Reference NAME Objects, as detailed in ISO 11783-6, to minimize the need for transmitting the full NAME with each reference change Instead, communication between the SCM and VT utilizes a two-byte object ID of the External Reference NAME Object, enhancing communication efficiency.
The SCM cannot verify the object type in individual object references within the SCD, as it only knows the object IDs Consequently, it is the SCC's responsibility to ensure that appropriate objects are used for accurate graphical and textual representation Additionally, SCMs must include provisions to handle object references rejected by the VT, maintaining data integrity and proper visualization.
Despite involving multiple SCCs within a single SC, this example focuses on an SC with one SCC referencing two objects to illustrate the core concept, applicable to all related graphics and textual objects within a true system, highlighting how each SCC provides specific references within the overall structure.
During the initial upload of the SCM object pool to the VT, External Reference NAME objects must be disabled, and the External Object Pointer object attributes should be set to the NULL Object ID, as specified in ISO 11783-6 for proper configuration and compliance.
Figure 2 illustrates the object hierarchy within the Object Pools loaded into the Virtual Terminal (VT) for a simple Supervisory Control and Data Acquisition (SCADA) system Key 31 identifies the SCC Object Pool, which includes one text object (key 33) and one graphic object (key 34) stored in the VT’s memory The SCC loads its System Control Database (SCD) with key 36 into the SCM memory, while the SCM transfers its default object pool (key 21) into the VT memory Additionally, the SCM's screen layout contains two external reference pointers—one graphic (key 23) and one text (key 24)—both of which are disabled after startup, optimizing system performance.
External Ref NAME ID = FFFF 16
External Ref NAME ID = FFFF 16
Num of Ref objects = 2 Ref Obj ID = 3C 16
Figure 2 — Initial status of external object pointer — Example
NOTE 2 The keys for Figures 2 and 3 are listed under Figure 3.
The SCCWS validates the NAME of the active SCM and updates the NAME field in its External Object Definition object (key 32) using the Change Attribute command Enabling the External Object Definition (Option = enabled; key 32) allows the VT to establish references from the SCMOP to the referenced objects (keys 37 and 38) within SCCOP (key 31) Key 39 in Figure 2 illustrates the established reference to the SCMOP, ensuring proper linkage and data integrity.
The SCM verifies the NAME of referenced SCCs and updates the corresponding NAME field in the External Reference NAME object to ensure accurate linkage Activating the External Reference NAME object through the Change Attribute command establishes a connection to the SCCOP Key 26 in Figure 2 indicates the established reference to the SCCOP, confirming successful integration within the system.
The SCM configures External Object Pointer objects (keys 23 and 24) using reference data received in the SCD (key 36) Typically, two Change Attribute commands are required for each External Object Pointer: one to set the External Reference NAME object ID (key 25) to link to the correct WSOP, and another to assign the External Object ID (keys 27 and 28) of the target object This process ensures accurate connection and reference within the system.
Figure 2 illustrates how references to graphic objects, such as working set designator icons, and text objects, like working set designators, are established within the SCCOP of the connected SCC The VT uses keys 25 and 26 to locate the referenced SCCOP for each External Object Pointer in the screen layout of the SCM, while key 39 verifies whether the SCC permits the SCM to reference its objects Once a reference to the SCCOP is established, External Object IDs are uniquely linked to their corresponding objects, with keys 27, 37, 28, and 38 representing this connection through the External Object Definition.
``,,`````,,```,,,```,````,`,-`-`,,`,,`,`,,` - object (key 32) reflects the additional checking for access permission; only objects listed in the External Object Definition object may be referenced.
External Object Deinition object Object ID = 3A 16
Num of Ref objects = 2 Ref Obj ID = 3C 16
Figure 3 — Status of External Object Pointers after initialization — Example
Keys for Figure 2 and Figure 3:
1 VT Object Pool volatile memory 3 SCC
20 SCM volatile memory 32 External Object Definition object defining the objects which may be referenced by the SCM speci- fied in the NAME 0&1 attributes
21 SCM Object Pool 33 Working Set Designator of SCCWS
22 External Reference NAME object including NAME of referenced SCCWS; one object per referenced SCCWS needed
34 Working Set Icon of SCCWS
23 External Object Pointer object to reference a graphic object (placeholder in the data mask) 35 NAME of SCC received through Address Arbitration
24 External Object Pointer object to reference a text object (placeholder in the data mask) 36 SCD of connected SCCWS
Keys for Figure 2 and Figure 3:
25 Virtual reference to External Reference NAME object to identify referenced Object Pool to VT 37 Virtual reference to Working Set Icon that may be referenced by the SCM
26 Virtual reference to the SCCOP established by the enabled External Object Pointer object in the SCMOP
38 Virtual reference to Working Set Designator that may be referenced by the SCM
27 Virtual reference to e.g the Working Set Icon of
SCCWS in SCCOP established by the enabled Exter- nal Reference NAME and External Object Pointer
39 Virtual reference to the SCMOP established by the enabled External Object Pointer object in the SCCOP
28 Virtual reference to e.g the working set Designa- tor of SCCWS in SCCOP established by the enabled External Reference NAME and External Object Pointer
4 SCM-VT communication including SCMOP upload and attribute updates
5 SCCWS-VT communication including SCCOP upload and attribute update
6 SCC-SCM communication including addresses arbitration for NAME identifi- cation and SCD upload to SCM
Working sets with master/member configuration
In ISO 11783-6 system configurations, the connections from the SCC to the VT and from the SCC to the SCM must be managed separately, as each has distinct responsibilities within the network Proper segregation of these connections ensures reliable communication between the working set master and its members Understanding these separate roles is essential for optimal system design and compliance with ISO standards.
4.3.1 SCC as working set master
In cases where an SCC is the working set master, the SCC is responsible for managing the VT connection as well as the connection to the SCM.
The SCCWS Master NAME field in the SCD basic object (defined in A.3) shall be set to the NAME of the SCC itself.
4.3.2 SCC as working set member
When the SCC functions as a working set member, its working set master manages the VT connection, utilizing the SCCOP object pool that includes both graphical and textual objects referenced by the SCC in its SCD Additionally, the SCC is responsible for establishing and maintaining the connection to the SCM, including uploading the SCD.
The SCC must obtain the object IDs of graphical and textual representation objects from the working set master's object pool to accurately reference them within its SCD However, the transmission of this information is not covered in this section of ISO 11783.
The SCCWS Master NAME field in the SCD basic object (defined in A.3) shall be set to the NAME of the working set master.
Sequence management functionality
Sequence management functionality is described as logic entity of software residing in any CF connected to the ISO 11783 network.
The Supply Chain Management (SCM) may restrict access and sequencing control data definition uploads for SCCs due to memory limitations or other constraints Typically, the SCM stores only one SCD per SCC in non-volatile memory, ensuring efficient data management and system stability.
Each SCM (Storage Control Module) independently stores and manages its recorded sequences, ensuring autonomous operation However, ISO 11783 does not specify a standardized method for transferring these sequences between different SCMs or to a desktop computer.
4.4.1 Sequence control system operating states
This article outlines the key states reported by the active SCM and SCCs, along with the transitions between these states Figures 3 and 4 visually depict the various state transitions within the SCM and SCC systems, providing a clear understanding of their dynamic behaviors Understanding these state changes is essential for effective system management and optimization.
Inactive: This SCM state indicates that the SCM is not participating in the overall SC com- munication This is the default state of an SCM after start-up.
Ready: ready for “Recording” or “Play Back”
In the "Completion" state, if at least one client function fails to finish before the operator stops the "Recording," the process is considered incomplete During this state, any reports of additional function starts are not permitted and will be ignored by the SCM, ensuring proper recording procedures.
Play Back: actively executing a sequence
Abort: state entered and transmitted to all CFs to halt a “Play Back” phase (see defini- tions in 4.4.3).
The states “Ready”, “Recording”, “Recording Completion”, “Play Back” and “Abort” are considered the active states, where the active SCM controls the SC communication.
The relationships between the different states are illustrated in Figure 4.
*One Time Send * SCMasterStatus message (F.2) SCM state “Inactive“
SC M R eady sequence state “ Ready “
SCM _ D OR SCM _ I OR SCM _ E * OR SCM _ F *
SCM _ H OR SCM _ I OR SCM _ E * OR SCM _ F *
SCM _ M OR SCM _ N OR SCM _ R OR SCM _ P * OR SCM _ F *
SC MasterStatus message (F.2) SCM state “Initialization“
SCM Recording Completion sequence state
SCM Play Back sequence state
SCMaster Status message (F.2) SCM state “Active“
Figure 4 — SCM state diagram © ISO 2013 – All rights reserved ``,,`````,,```,,,```,````,`,-`-`,,`,,`,`,,` - 11
SCM_A: operator Input: “Master ON SCM_K: “Start Play Back” (e.g through opera- tor input) SCM_B: operator Input: “Master OFF SCM_L: Normal sequence end
The process begins when the operator inputs the command "Start Recording," signaling the SCM_C to initiate the recording session During this phase, the SCM_M system sends any SCC messages, ensuring continuous communication Recording continues until the operator issues the "Stop Recording" command, at which point all recorded client functions are evaluated The system confirms that each function has reached a completion state, indicated by execution statuses of [10] for successful completion or [11] in case of an error during execution This systematic process ensures accurate capture and monitoring of client function operations within the SCM environment.
SCM_N operator input: “Abort Play Back”
SCM_E *: operator input: “Cancel Record SCM_P *: E.7 SCClientExecutionStatus: function execution state == 11 (error during execution)
SCM_F *: E.4 SCExecutionIndication: function execution state == 11 (error during execution)
SCM_R *: internal SCM abort condition (e.g
An SCC message or SCC timeout unexpectedly falls back to disabled, indicating a disruption in communication This issue may be triggered when the operator inputs "Stop Recording" while at least one recorded client function fails to send its execution state, either [10 (function execution completed)] or [11 (error during execution)] Such failures can compromise system stability and require further investigation to ensure consistent operation.
SCM_T: All enabled SCCs reflect “Abort” state to SCM
SCM_H: all included client functions sent func- tion execution state as [10 (function execution completed) OR 11 (error dur- ing execution)]
SCM_I: internal SCM cancel condition (e.g
Timeout of any SCC message or SCC unexpectedly falls back to disabled)
The SCC may be disabled either because it is not ready to execute client commands due to internal conditions or settings, or because it has been commanded by the active SCM to reduce system complexity and bus load The active SCM can disable an SCC if it is not part of the selected SCS or if the operator determines that the SCC is not required during a recording phase.
This is the default state of an SCC after start-up
The SCC is prepared to follow the active SCM state or execute incoming client commands Upon receiving a client command, the SCC transitions its state to "Play Back," ensuring seamless playback control This readiness facilitates efficient management of media playback in accordance with client requests and active SCM status.
Recording: The SCC is ready to send client commands during the recording phase.
Play Back: The SCC is ready to execute client commands received from the active SCM. Abort: The actual play back phase shall be halted (see definitions in 4.4.3).
The enabled SCC states—“Ready,” “Recording,” “Play Back,” and “Abort”—indicate when the SCC actively participates in SC communication Specifically, the states “Ready,” “Recording,” and “Play Back” are essential for maintaining communication, ensuring smooth operation across the system.
The article explains that entering the “Abort” state is permitted only through commands from the active Supply Chain Manager (SCM), as defined in sections F.2 and F.3 This can be achieved via the global SCClientAbort, outlined in E.3, either from another Supply Chain Controller (SCC) or directly by the SCC itself All rights are reserved under ISO 2013, and the instructions are applicable exclusively within the context of active SCM commands for maintaining system integrity.
In the recording process, SCM communicates the transition to the “Recording Completion” state, while SCCs that have finished their functions revert to the “Ready” state SCCs that are still performing a function remain in the “Recording” state until completion Importantly, SCCs do not indicate new function activations during the “Recording Completion” phase The state transitions and relationships are visually depicted in Figure 5, providing clarity on the process flow.
SCC _ C OR SCC _ D OR SCC _ E * OR SCC _ F * OR SCC _ G
*Cont Send * SCC lientStatus message (F.3) SCC state “Disabled“
SCC _ R OR SCC _ S OR SCC _ T *
*Cont Send * SCC lientStatus message (F.3) SCC state “Enabled“
SCC lientStatus message (F.3) SCC state “Initialization“
SCC Play Back sequence state
Figure 5 — SCC state diagram © ISO 2013 – All rights reserved 13
SCC_A: received SCM state “active” SCC_L: SCM state “Ready”
SCC_B: SCM sends SCStateCommand “enabled” SCC_M: SCM state “Recording Completion
AND all function execution of this SCC completed
SCC_C: SCM sends SCStateCommand “disabled” SCC_N: SCM state “Play Back”
SCC_D: Timeout for SCMasterStatus message SCC_O: receiving SCMasterExecutionCom- mand SCC_E Operator set SCC to not take part in SC system communication SCC_R: SCM state “Abort”
SCC_F *: Critical internal SCC conditions SCC_S: any SCC send SCClientAbort
SCC_G: SCM sends NACK for any SCC message SCC_T *: internal condition to abort SCS
At start-up of the system, the SCMs and SCCs identify themselves as independent units and participants on the ISO 11783 network (see definitions of ISO 11783-5 for address claiming process).
By default, all SCMs (System Communication Modules) start inactive, and all SCCs (System Control Components) begin disabled Both components indicate their startup process by sending a status message set to "initialization," enabling other participants to detect unexpected resets For comprehensive details on SC initialization, refer to Figures 6, 7, and 8.
SCM initialization begins with the SCM identifying itself to the VT using function instance 0 and uploading its object pool, with all external object pointers inactive by default (parameters set to FFFF 16) All SCMs remain inactive until the operator activates one via its user interface, with the flexibility to change the active SCM at any time Once activated, the selected SCM announces its status by continuously sending the SCMasterStatus message, indicating its active state and sequence status After startup, the active SCM clears all loaded SCD information from volatile memory and NACKs all incoming SCClientStatus messages except for the startup indication until an SCC confirms its startup.
The SCM initially receives SCClientStatus messages immediately after startup, provided a quick reset occurred within the interval of the SCMasterStatus message Upon receiving the SCDActivationCommand, the SCM begins parsing the SCD, with its parsing activity reflected in subsequent SCMasterStatus messages.
After receiving an SCMasterStatus message from an active SCM, SCCs must start continuously sending SCClientStatus messages with the state set to disabled An SCC can only enable its state when explicitly commanded by the active SCM The initial SCClientStatus message should indicate client initialization, ensuring proper synchronization with the SCM.