Next Generation Task Controller for agricultural Machinery using OPC Unified architecture

.


Introduction
Precision farming is the use of information technologies to gather and analyze data to make decisions related to crop production (National Research Council, 1997); defined by Zhang et al. (2002) as "the spatial and temporal variability of soil and crop factors within a field" it is an important topic in agriculture and as such is widely researched.
In general, the above methods are used to produce management zones which describe the properties of a field in spatial terms, normally in relation to its potential crop yield or nutrient content (Farid et al., 2016;Khosla et al., 2008;Piotrowska-Długosz et al., 2011).Tummers et al. (2019) describe fertilization management and data acquisition as two of the key features present in modern Farm Management Information Systems.
These management zones can be used to create prescription maps, maps that determine how product should be applied to the field spatially.This is achieved with variable-rate application (sometimes referred to as site-specific application), a technology where a product's application rate is varied depending on either online data from sensors or GNSS position and a predetermined prescription map (Grisso et al., 2011).
To enable agricultural machinery made by different manufacturers to utilize these technologies when connected together, there has to be an international agreement on how to exchange data related to site-specific application and section control.The ISO 11783 standard series defines a communication protocol and communication network for tractors and implements (ISO, 2017).The Task Controller (TC) is a component of ISO 11783 networks used for controlling implements based on planned tasks received from a Farm Management Information System, or FMIS (ISO, 2015a).
The ISOBUS Task Controller enables easy treatment of management zones by defining TC-GEO functionality to plan for product application that varies spatially.Automatic section control is a technology where boom sections consisting of nozzles or rows are automatically turned off when entering an area that has already been treated to avoid applying overlap treatment (Larson et al., 2015).
Implements expose their structure to the TC with Device Descriptor Object Pool (DDOP) XML files that are transferred from implements to the TC via CAN bus (ISO 11898) using the CAN 2.0B extended frame message format.Although there are guidelines on how implements should be modelled with the DDOP format, they allow different modelling approaches to be used, which in turn leads to similar implements sometimes having vastly different DDOPs.This means that it's possible that the TC won't be able to control an implement properly, if at all, because it fails to process the DDOP.Furthermore, the authors posit that the DDOP format provides insufficient means for modelling booms explicitly, and additionally that it does not provide any means for modelling many-to-many relationships between bins (defined in ISO 11783 as the tank of a sprayer or the bin of a seeder) and booms.For instance, under the current ISO DDOP design model it is not possible to model an implement that has two booms which share the same bin.
The first objective of this article is to identify how the DDOP format could be enhanced to enable new modelling features that would be beneficial to future devices, and how this enhanced DDOP format could be used to guarantee that similar implements are also modelled similarly.An Ethernet-based network shall replace the use of CAN in the future high-speed network (Smart & Brill, 2019), however, the higherlevel protocols have not been decided (Piirainen, 2014).Smart & Brill (2019, 2022) state that "The current HSI requirements do not require deterministic behaviour in the communications.However, in researching the potential impact if or when a deterministic link needs to be developed (other than that used by PT07), such as Time Sensitive Networking (TSN), the basic HSI architecture could evolve to support this, or other potential deterministic protocols.In this scenario, the known HSI needs are delivered best-effort, and since the 1 Gb/s network is sufficiently over-provisioned, the real-time requirements can still be met.This transition would require a change in the network switch hardware, and hardware/software at the end-points that require the deterministic behaviour.Due to the projected cost and complexity, and in the absence of requirements for this capability, this is presently out of scope for HSI.".Oksanen et al. (2015) studied the use of OPC UA for remote access of machinery process data such as GNSS position or process data extracted from ISO 11783-compatible implements.In the 2015 work OPC UA was not used for tractor-implement in-vehicle communication and control, rather it was used to broadcast existing information from the ISO 11783 network (based on CAN-bus) to a remote client system.To further study the viability of using OPC UA in ISO 11783 networks, the second objective of this article is to design and evaluate an OPC UA information model for data exchange between the TC and implements using the aforementioned enhanced DDOP format.This information model shall be called "OPC UA for the Next Generation ISO 11783 Task Controller" (OPC UA TC) and it shall be evaluated with OPC UA applications acting as an implement and a TC as illustrated in Fig. 1.
This article addresses the following questions: a) What new modelling features could be added to enhance the current DDOP format?b) How could this enhanced DDOP format be implemented in the OPC UA TC information model?c) How should OPC UA TC be used to guarantee that implements that are alike are modelled in the same way?d) Is OPC UA TC suitable as a higher-layer protocol for communication between a TC and an implement?
The necessity of information modelling in this way is that it enables inter-manufacturer, plug-and-play connection between a TC and an implement, as is possible today, but with much faster data rates (by using Ethernet).Additionally, this opens up the potential for improving upon the application layer by replacing the underlying CAN messages of today with UPC UP messages.The need for standardized information modelling stems from the fact that for a TC to accurately control an implement, it must have information about certain characteristics such as geometry, actuation delays, controllable sections et cetera.

Tractor-implement network
ISO 11783 is a communication protocol for agricultural and forestry Fig. 1.An OPC UA Client acting as the TC and an OPC UA Server acting as an implement communicating using OPC UA TC.The green shape on the left is the tractor and the orange on the right is an implement.
tractors and machinery (ISO, 2017).The standard series specifies a network for control and communication between tractors and implements (ISO, 2011a).The entities on an ISO 11783 network are electronic control units (ECU) connected with a single linear, 250 kbit/s, twisted, non-shielded, quad-cable (ISO, 2019a) which communicate with one another using the CAN 2.0B extended frame format with 29-bit identifiers and up to 8 bytes of data per frame (ISO, 2018a).The functionalities performed by an ECU are called control functions (CF) and they include spray rate control, section on/off control, product loss monitoring and so on.A collection of CFs that work together to perform as a group of CFs is called a working set with one of the CFs acting as the working set master.The working set master communicates with the common user interface, the Virtual Terminal (ISO, 2018b) and also with the Task Controller (ISO, 2015a).The basic process data communication with the tractor is based on separate messaging defined in ISO11783-7 Implement Messages Application Layer (ISO, 2015b).Each CF in an ISO 11783 network must have a unique 64-bit NAME that both identifies and describes it (ISO, 2019b).The bits that compose a NAME can be split into ten separate bit fields that each describe a different aspect of the CF such as manufacturer, device class, function and so on.NAMEs are sufficient for uniquely identifying CFs on a global level.

Compliance
ISO 11783 leaves some room for interpretation, which could potentially lead to various incompatible implementations of the standard.To avoid this, the Agricultural Industry Electronics Foundation (AEF) was founded in 2008 by implement and tractor manufacturers with the aim of promoting the use of ISOBUS, their implementation of ISO 11783, in order to enhance compatibility between tractors and implements made by different manufacturers.The AEF has defined guidelines on how ISO 11783 should be interpreted to guarantee compatibility between ISOBUS products (AEF, 2012d).To market a product as ISOBUS compatible, the product must pass one or more of the AEF's conformance tests.The products that have been certified by the AEF are given the AEF Certified Label and added to AEF ISOBUS database.

Task controller
The purpose of the Task Controller (TC) is to automate some aspects of farmwork such as controlling the (variable) product application rate, turning sections on/off, and recording data.On a technical level the TC is a CF that manages a connection between itself and the implements, and communicates with them using process data messages (ISO, 2015a).The TC receives tasks from an FMIS in the form of an XML file.In addition to commands related to site-specific application, the TC can also support section control by keeping a map of treated areas and commanding boom sections on and off to avoid applying a product multiple times to a treated area.The results of an executed task are saved in XML format and sent to the FMIS.
Compatible implements for planned tasks are identified by comparing their NAME to the full or partial NAME preselected at the FMIS.The NAME provides sufficient means for describing single operation implements with its industry group, device class, and function fields, however, no identifiers have been defined for identifying multioperation implements using these fields.In practice, the FMIS has to specify the manufacturer and the model of a multi-operation implement in a planned task, which means that the task will not be compatible with similar multi-operation implements made by different manufacturers.Therefore, when a task is planned in an FMIS, the use of NAME (industry group, device class, and function fields) is not adequate for identifying all compatible implements and hinders the TC's ability to utilize implements that would be suitable for the planned task.
The DDOP is a standardized way for device manufacturers to describe their devices (ISO, 2015a).It is imported/exported to the TC in XML format and transferred in a binary format if it is transmitted on the bus (from the implement to the TC).A DDOP file shall contain all information necessary to plan tasks using the device.A DDOP consists of exactly-one device (DVC) object, at least one device element (DET) object and any number of device process data variable (DPD), device property (DPT) and data value presentation (DVP) objects.The DVC object acts as the root object of the DDOP and provides general attributes of the modelled device such as its NAME.The DET objects have different device element types, such as connector, bin, section and so on, and form a tree hierarchy of the modelled device's components and subsystems.The DPD and DPT objects expose process data variables and properties related to a DET object that are referenced using device object reference (DOR) objects.DVP objects allow defining unit conversions for values of DPD and DPT objects that are presented with 32-bit signed integers.An implement's DDOP is transferred via CAN bus after a handshaking process where the implement queries if the current version of the DDOP has already been transferred to the TC as well as if the TC has enough memory to receive it.

Data dictionary
The ISOBUS data dictionary contains a record of DDEs (data dictionary entities) that are used to describe DPD and DPT objects present in DDOPs (ISO, 2011b;VDMA, 2020).Each DDE has a unique data dictionary identifier (DDI) number, definition of the data, unit, bit resolution and ranges.DDEs may also contain comments and attachments.There are currently over 500 DDEs defined such as "Setpoint Mass Per Area Application Rate", "Actual Seeding Depth", "Total Area" and so on.DDIs are referenced by DPD and DPT objects to define the data they represent and by planned tasks to define which DPD objects are to be monitored and/or controlled by the TC.The DPD objects to be controlled are typically setpoints of application rates, work states, working depths and so on.DVP objects can be used to convert the unit of a DPD or a DPT object specified by a DDI to custom units such as converting millimeters to meters, inches or feet.
DDE number 179 "Actual Cultural Practice" is used by function and bin DET objects to specify which current cultural practice is being performed.This enumerated list includes: fertilizing (#1), sowing and planting (#2), crop protection (#3), harvesting (#8), and so on.Cultural practice identifiers are used by multi-operation implements to allow the TC to control the correct subsystem of the implement when both subsystems have the same DPDs.An FMIS may reference a cultural practice and optionally an operation technique which further describes the cultural practice, e.g., operation techniques for fertilizing would be liquid fertilizing, organic fertilizing and gaseous fertilizing.
The AEF has defined guidelines for implementing three separate levels of TC functionality: "basic" for logging task totals, "geo" for sitespecific application, and "section control" for turning sections on and off based on treated areas (AEF, 2012a; AEF, 2012b; AEF, 2012c).These three TC functionalities and a fourth functionality for data loggers were added to the second edition of ISO 11783-10 published in 2015(ISO, 2015a).ISO also defines recommended DDIs for each device class and TC functionality, as well as providing example DDOPs.
However, the guidelines in the ISO standard leave a lot of room for interpretation, which allows similar implements to be modelled differently.In the end, whether or not a TC made by one manufacturer and an ISOBUS-certified implement made by another manufacturer are fully compatible can't be known for certain until they are connected to one another and tested.Testing all possible combinations in advance isn't feasible, which means that it falls upon the end users to do the tests.The compatibility issues between the TC and implements could be avoided by defining and enforcing stricter modelling rules that would leave no room for interpretation.However, this could make all currently available devices incompatible with future devices conforming to the new modelling rules.On the other hand, replacing the CAN bus and CAN 2.0B extended frame format with another communication protocol would also make current devices incompatible with future devices, which would make such a transition a logical point for defining stricter modelling rules and adding new modelling features.

Key properties of ISO 11783
At the time the current network for tractor-implement systems was developed, in the late 1980 s, it was considered that a 250 kbit/s network would fulfill all requirements far into the future (Oksanen & Auernhammer, 2021).The network was based on the latest technology at that time, CAN bus, which was a good choice for the standardization group as the technology is still valid and mainstream in vehicle networks.The fundamentals of the ISO 11783 network have been based on a maximum CAN backbone length of 40 m and data rate of 250 kbit/s (Smart & Brill, 2019).

Use cases
The agricultural industry has prepared for the future demands of a next-generation communication system by studying use cases which need a fast network.These include: "more precise command and control for prescription", "more precise data logging of as-applied and yield information" and "higher featured and more responsive display of information" (Smart & Brill, 2019).For instance, a TC would be able to control the seed-rate of each row of a planter and manage target seed spacing far more consistently (Smart & Brill, 2019).The specific use cases related to Task Controller are primary drivers for a faster network (Smart & Brill, 2019).It has been identified that command and control timing accuracy should be "well below 10 ms" (Smart & Brill, 2019); while the current rate with CAN bus is limited to 100 ms.
The other use cases of a faster network are related to digital camera systems, in-field vehicle-to-vehicle communication, plus HMI and electric drives in the plug-and-play system (Smart & Brill, 2019).These use cases are beyond the scope of this article.

Physical layer
In this article, the requirements of the agricultural industry are considered when assessing technological viability such as modularity, hot plug-and-play and intercompatibility between different machine manufacturers (Oksanen & Auernhammer, 2021).
Earlier studies have compared the various communication technologies available to the agricultural industry.These include CAN Flexible Data Rate (CAN-FD), FlexRay, wireless radio technologies and Ethernet.Out of these options, Ethernet was found to be the clear best option, with automotive cabling, one pair Ethernet.The preferred option out of many Ethernet technologies is IEEE 1000BASE-T1 (Smart & Brill, 2019).
As an industry requirement, the architecture should be similar to the current ISO 11783 network.This would allow for parallel networks during the transition, having the existing ISO 11783 and the new faster backbone cables next to each other in the wire harness.Easy hot plugand-play of implements and tractor is a mandatory requirement and the system cannot be pre-programmed due to the plug-and-play nature.(Smart & Brill, 2019).
The key difference to a CAN-based network is related to physical topology: Ethernet requires switches between physical links.

OPC Unified architecture
OPC UA is a platform-independent communication standard for industrial systems and devices (OPC Foundation, 2017a).The main purpose of OPC UA is the modelling and communicating of data (Mahnke et al., 2009).OPC UA allows the modelling of information with objectoriented techniques, such as type hierarchies and inheritance (OPC Foundation, 2017c;OPC Foundation, 2019).OPC UA supports communicating data between OPC UA applications by defining mappings between the security model, service sets, data structures and compatible network protocols (OPC Foundation, 2017f.).
In an OPC UA Client-Server communication model, Client and Server applications form a Session to exchange Service request and response Messages via OPC UA Communication Stack (OPC Foundation, 2017a).OPC UA defines ten Service Sets that provide Services for discovering Servers, managing Nodes, reading and writing Attributes, calling Methods and so on (OPC Foundation, 2017g).OPC UA also supports the OPC UA PubSub communication model (OPC Foundation, 2018a), though this article is focused on the OPC UA Client-Server model for the following reasons: 1.The current ISO 11783 Task Controller is defined in such a way that the TC server and TC client maintain a one-to-one connection.The OPC UA Sessions in the Client-Server model are largely the same.To replicate the setpoint rate-actual rate design of ISO 11783 with PubSub, each tractor and implement would need to act as both publisher and subscriber simultaneously.2. Broadcast messaging (as enabled by PubSub) is already a feature of ISO 11783 but broadcast messages do not form a part of the TC operation (with the exception of initialization, which can be handled differently in OPC UA). 3. PubSub was not mature at the time this work began.Although the protocol was defined, there were no suitable SDKs/implementations.
The information exposed by an OPC UA Server is called its AddressSpace and it consists of Nodes connected by References (OPC Foundation 2017a).A Node consists of Attributes that identify and name the Node and References that connect the Nodes to each other.Nodes are used for both defining types and creating instances of the defined types (OPC Foundation 2017a).Types are defined with ObjectType, Varia-bleType, DataType and ReferenceType Nodes, which are collectively called TypeDefinitionNodes, while instances are created with Object, Variable and Method Nodes.Subsets of the AddressSpace can be defined with View Nodes.An OPC UA information model defines a standardized configuration of Nodes and References for Servers using the information model.The base OPC UA information model is used as a basis for defining new information models (OPC Foundation 2017b).Standardized information models have been defined for Data Access (OPC Foundation 2017d) Alarms & Conditions (OPC Foundation 2017i.),Programs (OPC Foundation 2017e), Historical Access (OPC Foundation 2018c), Aggregates (OPC Foundation 2017j.) and Devices (OPC Foundation 2013).In addition to the base and standardized information models, OPC UA also allows users to define their own information models that best suit their needs.These information models are called companion specifications and they can be created internally by the OPC Foundation, jointly with the OPC Foundation and another organization or externally without the OPC Foundation's involvement.Joint companion specifications include IEC61131-3 Client Function Blocks for OPC UA (OPC Foundation and PLCopen, 2016), OPC UA for AutomationML (OPC Foundation and AutomationML, 2016), OPC UA for Robotics (OPC Foundation and VDMA, 2019), OPC UA for Commercial Kitchen Equipment (OPC Foundation and HKI, 2019) and many more.The use of OPC UA in various applications has been studied thoroughly in recent years.OPC UA for Smart Grids has been demonstrated by Lehnhoff et al. by mapping the Common Information Model (CIM) and IEC 61850 to OPC UA (Lehnhoff et al., 2012).Kožár and Kadera have developed IEC 61,499 function blocks representing OPC UA Clients for data exchange with remote OPC UA Servers and an automated process for creating the AddressSpace for an OPC UA Server based on the structure of an IEC 61,499 application (Kožár and Kadera, 2016).OPC UA was applied to cyber-physical production systems of Industry 4.0 by Schleipen et al. in four different application scenarios, which were quality defect tracking, visualization of process information, management information board and orchestration of cyber-physical production systems (Schleipen et al., 2016).Pauker et al. have presented a systematic approach to designing OPC UA information models in the manufacturing domain with modeldriven architecture and unified modelling language (Pauker et al., 2016).The feasibility of using OPC UA in field devices has been analyzed by Veichtlbauer et al. and the authors found advantages such as seamless integration of field devices and semantic interoperability in multivendor automation systems but also disadvantages such as poor resource utilization and communication latencies, which the authors suggest will become less significant as embedded devices become more powerful (Veichtlbauer et al., 2017).Kim and Sung have evaluated the use of the PLCopen OPC UA companion specification with an experimental robot system where OPC UA was used to exchange data between an OPC UA Client-Server hybrid application acting as a motion controller and an OPC UA Server application acting as a supervisory machine (Kim and Sung, 2017).Lee et al. have defined a bi-directional transformation between OPC UA and UML and demonstrated their approach with power grid, building automation and smart device domain use cases (Lee et al., 2017).An OPC UA information model has been designed by Wally et al. for modelling variability information in automated production systems that can be used in parallel with other information models (Wally et al., 2018).Ye and Hong have developed a four-layer architecture for a manufacturing system referencing the Reference Architecture Model for Industry 4.0 (RAMI 4.0) model using AutomationML and OPC UA (Ye and Hong, 2018).Cavalieri et al. have provided a solution for integration of OPC UA and Open Connectivity Foundation (OCF) Resource Model with OCF OPC UA Information Model that provides ObjectTypes for mapping the OCF Resource Model to the OPC UA AddressSpace (Cavalieri et al., 2019).Tantik and Anderl have validated their concept of applying representational state transfer to OPC UA with a use-case involving an OPC UA Client that measures and sets the position of a pattern on a gripper of a robot arm represented by an OPC UA Server utilizing the OPC UA for Robotics companion specification to model the robot (Tantik and Anderl, 2019).The problem of the convergence of information technology and operation technology has been addressed by Tian and Hu with their OPC UA information model for time-sensitive networking (Tian and Hu, 2019).Beňo et al. have demonstrated transferring data from an OPC UA Server to the cloud with a Raspberry Pi 3 acting as an IoT edge device and discussed the benefits of using this architecture including modular deployment and safe data storage (Beňo et al., 2019).The scalability of OPC UA has been demonstrated by Pribiš et al. by implementing an OPC UA Server on an ARM 32-bit microcontroller connected via Ethernet switch to another similar microcontroller running a UaExpert OPC UA Client (Pribiš et al., 2019).
The transfer of data on ISO 11783 communication networks with OPC UA was studied by Piirainen in their article (Piirainen, 2014).An information model for representing DDOPs with OPC UA Objects and Variables was designed and tested.This information model was based on the device model defined in the OPC UA for Devices companion specification and it defined ObjectTypes and VariableTypes for representing device descriptor objects.The OPC UA TC information model designed for this article is inspired by the information model designed by Piirainen.
The performance of OPC UA in an agricultural (tractor-implement) configuration would depend on several factors.One factor is how the industry decides to standardize the physical layer, which as discussed, will very likely be IEEE 1000BASE-T1 (Smart & Brill, 2019).Profanter et al. (2019) studied the performance of several Industry 4.0 protocols and concluded that "OPC UA has its strength in the semantic modeling of information.[…] The performance comparison of the protocol implementations shows that open62541 for OPC UA and eProsima FastRTPS for DDS deliver high performance, whereas the MQTT and ROS implementations show a significant slowdown in the RTT of packages sent to the server".
There is a range of literature which establishes that the specific implementation (i.e.SDK/library) of the OPC UA protocol affects the performance of the system.Haskamp et al. ( 2017) performed benchmarking of twenty-one different OPC UA implementations and found that only three satisfied all of the evaluation criteria defined.Morato et al. ( 2021) tested four different OPC UA implementations.The results showed that the task execution time (latency) and CPU usage are affected by the implementation, with the best performing being the open source implementation open62541 which has a mean task execution time of 312.83 μs when using 100 Mbit/s Ethernet, and significantly degraded performance when using WiFi.Zunino et al. (2021) found similar discrepancies between different implementations when testing PubSub, while Cavalieri and Chiacchio (2013) evaluate the performance impact of various OPC UA features such as publish interval and security which are both shown to impact performance.This paper focuses on information modelling as the specific hardware/software/security requirements of the agricultural industry are yet to be adequately defined.

Requirements of OPC UA for the next Generation ISO 11783 Task Controller
OPC UA TC is required to expose an implement's DDOP as Object and Variable Nodes in an OPC UA Server's AddressSpace.In addition to exposing an implement's DDOP, OPC UA TC should provide a means for controlling the implement by allowing Clients to either: write values to settable DPD objects represented by Variable Nodes, or, call functions represented by Method Nodes to perform more complex control operations.A standardized information model for modelling devices has been defined in the OPC UA for Devices companion specification and OPC UA TC shall use this device model as its base.
In addition to implementing the data modelling requirements for the DDOP format defined by ISO 11783-10, new requirements to enhance OPC UA TC with new modelling features have been identified for this paper.These new modelling features are: a) grouping process data variables and properties b) modelling many-to-many relationships of device elements c) creation of new device element type for modelling booms d) creation of new cultural practice identifiers To unify how implements of a common type are modelled with OPC UA TC, stricter modelling rules must be defined for different device element types.These modelling rules include defining the allowed relationships between DET objects of the same or different device element types and defining required process data variables and properties for each device element type.
OPC UA TC is evaluated with an OPC UA Server acting as a simulated implement and an OPC UA Client acting as a simplified TC in simulated scenarios relating to the control of product-applying implements.The TC has tasks involving data logging, site-specific application and section control.

Grouping process data variables and properties
In the current the ISO 11783 standard both DPD and DPT objects reference DDIs to identify the definition, unit, value range and other metadata of the process data variable or property (ISO, 2015a).This approach requires the TC to process all the DPD and DPT objects one by one with different handlers based on their DDIs.It would be beneficial if DPD and DPT objects could be organized into groups of related DPD and DPT objects e.g., DPD objects representing "Setpoint Mass Per Area Application Rate" and "Actual Mass Per Area Application Rate" could be grouped together.Therefore, a new device descriptor object was designed for grouping DPD and DPT objects.To make these groups more efficient to process, objects organizing DPD and DPT objects should be able to identify their contents based on an identifier instead of presenting a list of DDIs.This identifier is required to be applicable to all currently defined DDEs.

Modelling many-to-many relationships of device elements
As defined currently, the parent-child relationships of DET objects in a DDOP form a tree structure.Modelling many-to-many relationships is not possible when using parent-child relationships.However, the authors find that modelling many-to-many relationships would be beneficial in future use cases, such as modelling more complicated relationships of booms and bins that are not expressible with only parent-child or sibling relationships.Therefore, a new type of device descriptor object has been designed for modelling these types of relationships.

New device element type for modelling booms
The first edition of ISO 11783-10 was released in 2009 and featured site-specific application and data logging, but it did not include the concept of section control.Section control is included in the second edition of ISO 11783-10 released in 2015, which also includes guidance on how booms should be modeled.The standard suggests (but does not explicitly require) that booms be modelled as DET objects of either device or function type depending on the modelled device (ISO, 2015a).While these modelling approaches are backward compatible with older DDOPs, it also means that a function DET object could represent either a boom or something entirely different.For this article, it was decided that a new boom device element type is needed for modeling booms accurately.Thus, a new device element type for booms was defined that would allow booms to be modeled more explicitly in the DDOP and modelling rules for this device element type were defined in OPC UA TC.

New cultural practice identifiers
Currently, eighteen cultural practice identifiers are defined in the ISOBUS data dictionary.They are used by the TC to find the correct subsystem to control when controlling multi-operation implements, but cultural practice identifiers could also be used to match a planned task received from the FMIS with a compatible implement.Because cultural practices by themselves are abstract, defining concrete cultural practices (such as granular fertilizing, liquid crop protection, disk tillage and so on) would allow the operations of an implement to be identified more specifically.Therefore, new cultural practice identifiers shall be defined and the use of cultural practices in matching process between a planned task and an implement shall be tested.Additionally, instead of providing just one cultural practice, implement subsystems could provide a list of cultural practices they are capable of performing, e.g., a bin applying liquid could specify liquid fertilizing, liquid crop protection and irrigation as its compatible cultural practices.OPC UA allows the value rank of a Variable Node to be defined as scalar or one-dimensional array, which is sufficient for representing lists of values.

Modeling principles
In this article, the aforementioned requirements of a high speed replacement of the current ISO 11783 network are fulfilled with a twostep approach: in the first step the current DDOP modeling principle (ISO, 2015a) is extended to cover the requirements for modeling the boom and many-to-many relationships.In the second step this extended-DDOP is mapped to OPC UA modeling.All figures in this section use the notation defined by the OPC Foundation (2017c, Annex C).

Overview, definitions, modeling of variables and objects
OPC UA TC consists of ObjectTypes and VariableTypes that correspond to device descriptor objects from the ISO 11783 DDOP format as listed in Table 1.The grouping of DPD and DPT objects is done with data container (DTC) objects and the modelling of many-to-many relationships between DET objects is done with resource connector (RSC) objects.Defining a new VariableType for DPT objects was not necessary because the base OPC UA Information model provides one -Proper-tyType -which fulfils the requirements of the DPT object without requiring any further modification.

DVC objects
DVC objects are represented with instances of DVCobjectType as illustrated in Fig. 2.

DET objects
DET objects are represented with instances of DETobjectType as illustrated in Fig. 3.

DTC objects
A DTC object groups related DPD and DPT objects and identifies its contents with a three-part identifier which consists of: Definition, Unit and Structure Configuration.Definition defines the meaning of the grouped objects, e.g., application rate or work state.Unit defines the SI unit of the grouped objects, e.g., volume per area (m 3 /m 2 ) or time (s).Structure Configuration defines the Roles of grouped DPD and DPT objects in presenting the data, e.g., a configuration consisting of actual value, setpoint value or default value and another configuration consisting of readable state and setpoint state.The use of DTC objects makes processing DDOPs more efficient by allowing the TC to ignore DTC objects with irrelevant contents.all DDEs of ISOBUS data dictionary are able to be remapped to Definitions, Units and Roles.A selection of these mappings are presented in Table 2.
DTC objects are represented with instances of DTCvariableType, which is illustrated in Fig. 4 along with an instance of DTCvariableType that demonstrates how DPD and DPT objects are grouped with DTC objects.

Table 1
Device descriptor objects and their corresponding ObjectTypes and Varia-bleTypes both as currently standardized and from the proposed extension to the DDOP model.M. Siponen et al.

DPD objects
DPD objects are represented with instances of DPDvariableType, which is illustrated in Fig. 5. DPT objects are represented by an instance of PropertyType, which is defined in the OPC UA specification.Neither DPD or DPT objects continue to use DDIs to define the data they model.

RSC objects
An RSC object connects a boom DET object to a bin DET object.This allows modelling complex relationships between booms and bins that were impossible to model in a tree hierarchy.Additionally, RSC objects allow modelling implements that allow application rates from a bin to booms to be controlled separately for each boom by placing a DTC object that groups DPD and DPT objects related to application rate control under the RSC objects that connect the booms to the bin.While modelling an implement like this is possible by placing the DPD and DPT objects related to application rate control under a function DET object acting as boom, this modelling approach is usable only when no boom is connected to more than one bin, while the use of RSC objects places no limitations on how many bins a boom may be connected to nor how many booms may be connected to a bin.
RSC objects are represented with instances of RSCobjectType, which is illustrated in Fig. 6.

Modelling rules for DDOP in OPC UA TC
Where the DDOP contains DVC, DET, and RSC objects (in OPC UA TC), the attributes of such objects are modelled as Variables belonging to the ParameterSet Objects of instances of DVCobjectType, DETobjectType and RSCobjectType respectively.DTC objects belonging to DET and RSC objects are also placed into these ParameterSet Objects.In addition to device element types defined in ISO 11783-10, the value of the DeviceElementType attribute of a DET object may be set to 8 to signify that the DET object is a boom DET object.The modelling rules for this and other device element types are defined in the next subsection.
In DDOP format, the hierarchy of DET objects is expressed with their DeviceElementObjectId and ParentObjectId attributes and DET objects were connected to DPD and DPT objects with DOR objects.In OPC UA TC, these relationships are modelled with HasComponent References between Nodes representing these device descriptor objects.OPC UA TC uses SI units and it is assumed that the TC can handle necessary unit conversions.Therefore, DVP objects are no longer needed for providing unit-conversion formulae.The names and descriptions of Nodes can be defined in multiple languages with the LocalizedText data type, which means that the TC would no longer need to configure the language of an implement.
In addition to exposing process data variables and properties with DTC objects, DET and RSC objects may also provide Methods that allow  controlling these variables with predetermined functions.The use of Methods allows the TC to issue more complex control commands than simply writing to values of settable process data variables.For example, a Method for controlling all sections of a boom with a Boolean input array with length equal to the number of sections in the boom would allow the TC to control boom sections either one-by-one or all at once.Methods could also be used to set all total values of a DET object to zero or to set the setpoint application rate to its default, maximum or minimum value.

Modelling rules for OPC UA for the next Generation ISO 11783 Task Controller
Modelling rules for using OPC UA TC to model implements were defined with focus on implements which apply products, such as seed or fertilizer.These modelling rules define the allowed relationships between different device descriptor objects and between different types of DET objects and required DTC objects for each type of DET object.The modelling rules have been chosen such that implements modelled with these modelling rules will be compatible with the TC-BAS, TC-GEO and TC-SC functionalities defined in ISO 11783-10.
The allowed relationships between different device descriptor objects are illustrated in Fig. 7.
The allowed relationships between different types of DET objects are illustrated in Fig. 8 and information about the various data types is give in Table 3.
Function DET objects are no longer used to represent booms.Instead, booms are represented with boom DET objects.A boom DET object is required to expose its work state, its offset from the center of the device coordinate system, its working width, total area it has treated, total effective and ineffective distance it has travelled, total effective and ineffective time it has spent, its prescription control state, its section control state and its section control turn on and turn off times.Each boom DET object must be parent to at least one section DET object and connected to at least one bin DET object with an RSC object.
To enable modelling booms that allow application rates to be controlled at a section level, the application rate from a bin to such boom should be modelled as a one-dimensional array with length equal to the number of sections in the modelled boom.The DTC object for these application rate controls is placed either under the RSC object that connects the boom and bin DET objects or the bin DET object depending on whether or not the bin DET object is connected to other boom DET objects.

OPC UA applications
To test OPC UA TC in practice, an OPC UA Implement Server and OPC UA Task Controller were created.The OPC UA Implement Server utilized the information model built on top of a simulated implement subprogram.Both were designed and developed with Microsoft's Visual Studio 2013 Ultimate (Microsoft, Redmond, USA) and Unified Automation's.NET Based OPC UA Client/Server SDK version 2.6.1.422(Unified Automation, Kalchreuth, Germany).The code for OPC UA TC was generated with Unified Automation's UaModeler version 1.6.2(Unified Automation, Kalchreuth, Germany).

OPC UA implement Server
The OPC UA Implement Server is an OPC UA Server that utilizes OPC UA TC.It consists of three layers that provide values for variables and properties of a simulated implement, an object-based DDOP that models the implement, and an AddressSpace based on the DDOP.These layers are illustrated in Fig. 9.
The OPC UA Implement Server was used with multiple different simulated implements to test OPC UA TC in different use cases.The simulated implements were a sprayer and a seed drill as described in Table 4. Simulated delays were added when responding to new setpoints for section work states and application rates received from Clients.

OPC UA Task Controller
The OPC UA Task Controller is a proof-of-concept TC with a focus on the features related to the TC interacting with implements.The main duties of the OPC UA Task Controller are:  The OPC UA Task Controller has various features that would be expected from a TC such as: a Command Algorithm to command the sections on/ off, a Task File, (simulated) Position reader, and a data logger.The most notable differences of the OPC UA TC are that the DDOP consists of OPC UA nodes as previously discussed.
Once the OPC UA Task Controller has been started, it prompts the user for the Endpoint URL of the OPC UA Implement Server.After being connected to the simulated implement represented by the OPC UA Implement Server, the OPC UA Task Controller creates a local copy of the DDOP exposed by the OPC UA Implement Server.This local DDOP is then optimized for more efficient processing by creating a Virtual Device that models the connected implement sufficiently for controlling it.
After the initialization of the local DDOP and the Virtual Device, the user is allowed to select a task and the OPC UA Task Controller checks whether or not the selected task and the connected simulated implement are compatible with each other.For this article, tasks were simplified to lists of products to be applied.Each product has a prescription map, a cultural practice and an application rate unit that are compared against cultural practices and application rate units of bins of the connected implement instead of comparing NAME of the implement to a NAME provided in task data.If a compatible bin can be found for each product, the selected task and the connected implement are compatible.
After a successful compatibility check, the user is allowed to start the task.Once the task has been started, the OPC UA Task Controller performs the following actions: (a) controls application rates based on prescription maps of applied products (b) turns sections on and off based on the coverage map approximated with Bresenham's line algorithm (Bresenham, 1965) and (c) logs the position of the simulated tractor, the current time and data from the simulated implement.The command algorithm of the OPC UA Task Controller is illustrated in Fig. 11.

Modelling implements with OPC UA TC
OPC UA TC enables the modelling of implements that are not possible to model with the DDOP format as standardized in the current most recent version of ISO 11783.Fig. 12 demonstrates how a productapplying implement with multiple bins and multiple booms can be modelled in OPC UA TC.In the figure, DET and RSC objects are represented with rounded rectangles that provide a list of their DTC objects with the Roles that form the Structure Configuration of the DTC object listed in parenthesis.The notation for the Roles is explained in Table 3. Solid arrows connect a parent DET object to its child DET or RSC object and dotted arrows connect an RSC object to its resource DET object.To simplify the diagram, unit DET objects are not included.
In the modelled implement from Fig. 12: • Boom 1 is applying products from bins 1 and 2 • Boom 2 is applying products from bins 1 and 3 Fig. 8. Allowed relationships of different types of DET objects, described using UML convention.The DET objects are represented as containers that provide a list of their DTC objects and in parenthesis are the Roles that form the Structure Configuration of the DTC object.The notation for the Roles is defined in Table 3.
• Boom 3 is applying products from bins 2 and 3 The original DDOP format does not provide means for modelling such complex relationships between bins and booms, which demonstrates the benefits of enhancing the DDOP format with RSC objects.
The figure shows how the model facilitates complex relationships between booms and bin.In addition, it is shown how RSC and DTC objects enable the modelling of implements in an enhanced way, allowing the application rate from a bin to connected booms be controlled separately for each bin-boom pair.As shown in Fig. 12, application rate DTC objects are present in both RSC objects as well as bin DET objects; in the of RSC objects these consist of: the actual value, setpoint value, default value, minimum value and maximum value; while in bin DET objects these consist of just the total.Both the actual value and the setpoint value may be either scalars or one-dimensional arrays.This enables implements that allow application rates to be controlled at a section level to be modeled, without changing the hierarchical structure of DET, RSC and DTC objects.

Test setup
The OPC UA Task Controller and the OPC UA Implement Server were tested by running the applications on two separate Windows 10 PCs connected with via Ethernet cable.The data logged by the OPC UA Task Controller during the test runs was analyzed with MATLAB R2018b (Mathworks, USA) to evaluate the correctness of the command algorithm with regards to site-specific application and section control.
When a task is being executed, the OPC UA Task Controller provides simulated tractor positions based on predetermined paths illustrated in Fig. 13 and Fig. 14.These paths have been chosen such that they involve returning to a treated area in 90 • and 45 • angles.In the former case, all sections should be turned off at the same time.In the latter case, sections should be turned off one by one.

Site-specific application
Tractor positions were read from the logged data to calculate the positions of the booms.The setpoint application rates from bins to booms were read from the logged data and compared with the calculated positions to verify the correctness of the command algorithm in site-specific application.
Fig. 15 shows the cell grid prescription map for the simulated sprayer.The prescribed application rates range from 100 cl/m 2 to approximately 2000 cl/m 2 .In the prescription map, the width and the height of a cell are 0.25 m.
Fig. 16 shows the logged setpoint application rate of the simulated sprayer and the setpoint application of the prescription map.The setpoint application rates match each other.
Fig. 17 shows the absolute value of the difference between logged and prescription setpoint application rates for the simulated sprayer.The maximum for this difference is less than 3 cl/m 2 .Fig. 18 shows the cell grid prescription map for the simulated seed

Relationships between booms and bins
One-to-one One-tomany Application rate control level Boom Section drill.The prescribed application rates range from 1 g/m 2 to approximately 10 g/m 2 .In the prescription map, the width and the height of a cell are 0.125 m.Fig. 19 shows the logged setpoint application rate of the simulated seed drill and the setpoint application of the prescription map.Again, the setpoint application rates match each other.
Fig. 20 shows the absolute value of the difference between logged and prescription setpoint application rates for the simulated seed drill.Again, the maximum for this difference is less than 0.03 g/m 2 .
The errors in the applications presented are so small that the OPC UA Task Controller is considered to be performing site-specific application correctly.

Section control
Tractor positions were read from the logged data to calculate boom positions.The working widths of the booms were read from the logged data and compared with the calculated positions to verify the correctness of the section control command algorithm.Fig. 21 shows the working width of the boom of the simulated seed drill based on its position.The plotted working width shows that sections were turned on and off correctly.
Fig. 22 shows the coverage map created by the Bresenham's line algorithm for the simulated seed drill.Gray areas were not marked as treated and green areas were marked as treated.A tiny gap after exiting the treated areas can be seen on the map which shows the functioning of the section as they turn on late to avoid overlapping application areas.23 shows the working width of the first boom of the simulated sprayer compared to its position based on data logged when the simulated tractor was moving at 2 m/s at 5 m/s.This plot shows that the command algorithm was able to adjust the timing of turning sections on and off based on the speed of the tractor.
Fig. 24 shows the coverage map created by the Bresenham's line algorithm for the simulated sprayer.Grey areas were not treated, dark green areas were marked as treated when moving at both 2 m/s and 5 m/s and light green areas were marked as treated only when moving at 2 m/s.While the command algorithm is not directly affected by the speed of the simulated tractor, the coverage maps drawn by Bresenham's line algorithm became less accurate as the speed of the simulated tractor was increased, which could affect the command algorithm.

Response time
The TC client/server setup was tested in laboratory conditions using The proposed OPC UA implementation presented in this paper is shown to take 2.8 ms on average (see Fig. 25) to control 6 products in each of 200 sections.In the same 2.8 ms it could be expected that ISO 11783 would only be able to control 80 (16 sections multiplied by 5 messages which could be sent in 2.5 ms) sections or update the rate of    While the OPC UA Implement Server was designed with simulated implements in mind, its layered structure should allow the simulation layer to be replaced with the interface of a real implement which would in turn allow the upper layers to read and write live data to/from the implement.Modifying the OPC UA Implement Server to be compatible with real implements would be an interesting topic for future research.
OPC UA allows Variables to have both scalar and multidimensional array Values.OPC UA TC utilized one-dimensional arrays when modelling application rates that could be controlled at a section level.One-dimensional arrays of fixed length could also be used to model device element offsets, angles and dimensions.More interestingly, arrays of variable length could be used as lists.For example, instead of bins providing a single cultural practice they are compatible with, they could provide a list of all cultural practices they are compatible with.The use of arrays could also make it more efficient to model sections of a boom with a single DET Object that provides values for variables and properties of all sections as arrays.
As mentioned earlier in the article, there is a need to allow many-tomany connections between booms and bins.This could be leveraged effectively for example, in sprayers which may have the functionality of broadcast spraying and precision spot-spraying simultaneously.Depending on the products used, the booms will want to select different bins depending on the situation.
This article focused on designing an OPC UA information model for data exchange between the TC and implements.In future research, OPC UA information models for other CFs of ISO 11783 network, such as  TECUs, could be designed.Additionally, the use of OPC UA PubSub communication model in data exchange between the TC and implements should be tested.
In the Results chapter of this paper the performance of a simulated implement is presented and analyzed.This type of implement is not possible with current TCs.Using CAN 2.0B extended frame format at 250 kbit/s, a frame takes approximately 500 µs to send and in the current ISO 11783 protocol, each frame can hold the section control information (on/off) of 16 sections or one single rate-control value.To control the rate and section control state of 6 products on 200 sections (as in Table 4) the ISO 11783 standard would require 1275 messages (200 rate messages per product and 75 messages to command the sections on/off) which would take 637.5 ms.Therefore, this type of machine control scenario would not be feasible currently due to both, bandwidth  constraints, and requirements relating to the update rate.This speed benefit mostly comes from the lower-level upgrade from a CAN-based to an Ethernet-based network, while the focus of this work is not on the lower layers, but the higher-level presentation and application OSI layers which will be in need of updating given the decision to use Ethernet in a future high-speed network.
Limitations and future research directions.A limitation of this work is that it was performed in a simulated environment on (comparatively) powerful PC hardware, whereas the real-life use-case for such a network would be in less powerful embedded hardware and via multiple switches, over wires which may have some low level of interference.
Future research could take several directions.Firstly, network properties such as latency, processing load etc. should be investigated, especially for different typical tractor-implement network configurations and different Ethernet switches.This work explored using OPC UA for TC control algorithms, however the full ISO 11783 range includes general purpose ECU messages (speed, engine RPM etc.) as well as diagnostics connections and VTs (GUI display units).Research should be conducted into how best to    incorporate all of the required elements together into one network, possibly with OPC UA in control of all aspects, or possibly with multiple protocol stacks on the network simultaneously.
It has been shown that OPC UA over an Ethernet network is in theory able to control many more sections than the current IOS 11783 standard would be able to, and at a much faster rate.It remains to be seen what new implements will be able to accomplish with this, and what the benefits will be to the end users (farmers).Future research opportunities exist in analysing and quantifying the agricultural benefits that could be brought about by improved control and communication networking.
This work was undertaken using the OPC UA client-server model.Further research may investigate if the newer PubSub model is more performant for future agricultural use cases.
Additionally, OPC UA is not the only available middleware, and others such as Data Distribution Service (DDS) should be researched from an information modelling perspective.The next step would be to perform like-for-like comparisons to determine the benefits and drawbacks of each, and may suggestions about which is the most suitable overall.

Conclusion
The goal of the work was to develop an information model, for realtime process control of a tractor-implement network, using OPC UA.It was found out that the information model should be based on OPC UA for Devices (DI).It was presented how the current DDOP model of the ISO 11783 Task Controller can be mapped to our novel information model and also extending the modelling rules to allow complex relationships between certain elements.This was done by using container objects for grouping DPD and DPT objects, resource connector objects for modelling complex relationships between boom and bin DET objects, boom device element type for DET objects and new cultural practice identifiers.The previous work by Oksanen et al. (2015) showed that OPC UA was capable of extending the ISO 11783 standard to allow remote condition monitoring.The OPC UA aspects were a separate addon to the existing ISO 11783 system which did not interact with it.There are several important distinctions which greatly separate that work from this one.Firstly, this work is about addressing the current issues with the ISOBUS TC DDOP by extending the modelling rules as discussed.Secondly it has control elements to enable interaction between the ECUs in the network, thirdly the previous work was a system for converting CAN bus messages and sending them via OPC UA but this work proposes a standalone system without CAN.
OPC UA for the Next Generation ISO 11783 Task Controller information model for data exchange between the TC and implements was designed as a collection of ObjectType and VariableType Nodes.OPC UA TC allows device descriptor objects and their relationships to be modelled as Object and Variable Nodes connected by References.Additionally, it allows the TC to control implements by calling functions presented with Method Nodes.
Modelling rules for using OPC UA TC to model implements were defined.The modelling rules define the allowed relationships between different types of device descriptor objects and different types of DET objects.Required DTC objects for all types of DET objects were defined.Instructions on how RSC objects should be used to connect booms to bins when the application rate of a product is controlled at either boom level or section level were presented.
Tests to evaluate information model were done in an office network, with two office computers connected to each other.The tests covered using different task files and the OPC UA Implement Server was configured to represent different simulated implements.The tests showed that the OPC UA Task Controller was controlling the simulated implement via OPC UA Implement Server correctly.The algorithm that verifies whether or not an implement is compatible with a task was also working as intended.The results of these tests conclude that OPC UA using Ethernet-based networks is a viable alternative to the SAE J1939 protocol and CAN bus in data exchange between the TC and implements.
This article presented benefits of OPC UA information modelling and possible way to standardize the Information model, which follows the same concept as the original DDOP of ISO 11783.

Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Fig. 4 .
Fig. 4. DTCvariableType and its instance that groups DPD and DPT objects related to application rate.The Definition of the DTC object is defined by DataDefinitionId, the Unit of is defined by DataUnitId and the Roles of the grouped DPD and DPT objects are specified by DataContainerStructureId.Defined using the notation of OPC UA (OPC Foundation, 2017c, Annex C).
a) Connecting to an implement via an OPC UA Session b) Transferring the implement's DDOP to local memory with Browse and Read Services c) Performing a compatibility check for a selected task and the connected implement d) Controlling the implement based on the selected task and a simulated tractor position with Write and Call Services e) Logging data from the implement with Subscription and Monitor-edItem Services.The software components of the OPC UA Task Controller are illustrated in Fig. 10.The OPC UA Task Controller represents the main task controller and the OPC UA Implement Server represents the implement.

Fig. 7 .
Fig. 7. Allowed relationships between different device descriptor objects.Arrows point from a parent to a child and specify the ReferenceType used to connect the Nodes representing these device descriptor objects; the numbers indicate how many such children the parent may have.

Fig. 10 .
Fig. 10.The components of the OPC UA Task Controller.The components in bold typeface are threads and other components are objects.The arrows point from the component that initiates the interaction to the participating components.

Fig.
Fig.23shows the working width of the first boom of the simulated sprayer compared to its position based on data logged when the simulated tractor was moving at 2 m/s at 5 m/s.This plot shows that the command algorithm was able to adjust the timing of turning sections on and off based on the speed of the tractor.Fig.24shows the coverage map created by the Bresenham's line algorithm for the simulated sprayer.Grey areas were not treated, dark green areas were marked as treated when moving at both 2 m/s and 5 m/s and light green areas were marked as treated only when moving at 2 m/s.While the command algorithm is not directly affected by the speed of the simulated tractor, the coverage maps drawn by Bresenham's line algorithm became less accurate as the speed of the simulated tractor was increased, which could affect the command algorithm.

two
Windows 10 PCs directly connected to each other via a single Ethernet 1000BASE-TX crossover cable.The OPC UA implementation was based on the.NET SDK (Unified Automation, Kalchreuth, Germany).The performance of Write and Call Services used in the command algorithm (as shown in Fig. 11) were evaluated by analyzing the time intervals between OPC UA request and response Messages with Wireshark network protocol analyzer (The Wireshark Foundation, Davis, California, USA).Fig. 25 below shows how the number of products affects the time it takes for the OPC UA Task Controller to exchange data with the OPC UA Implement Server per iteration of the command algorithm.

Fig. 16 .
Fig. 16.Logged and prescription setpoint application rates of the simulated sprayer.

Fig. 17 .
Fig. 17.Difference of logged and prescription setpoint application rates of the simulated sprayer.

Fig. 19 .
Fig. 19.Logged and prescription setpoint application rates of the simulated seed drill.

Fig. 20 .
Fig. 20.Difference of logged and prescription setpoint application rates of the simulated seed drill.

Fig. 21 .
Fig. 21.The working width of the boom of the simulated seed drill.

Fig. 22 .
Fig. 22.The coverage map for the simulated seed drill.

Fig. 23 .
Fig. 23.The working width of the first boom of the simulated sprayer.

Fig. 24 .
Fig. 24.The coverage maps of the simulated sprayer.

Fig. 25 .
Fig. 25.Seed drill Duration of the OPC UA data exchange.

Table 2
Mappings from DDEs to Definition, Role and Unit.

Table 3
Notations for Roles.