ISOXML Integration

Skip key takeaways

Updated October 4, 2026

• The transfer runs both ways and the two payloads differ Planned tasks and prescriptions travel out, recorded work comes back and only the outbound half is authored by the platform.
• The element vocabulary sits behind a paywall No institutional page read for this article names an ISOXML tag, so the standard is bought and cited by title rather than assembled from copies.
• The data dictionary is a live registry, not a table Identifiers, units and ranges move independently of the 2011 edition and are synced as reference data rather than compiled in.
• Certification on all three products is what warrants a transfer A platform gets the functionality its counterpart display and implement share, never the capability of the strongest link.
• The import failures the AEF names are not data modeling failures Folder structure and file naming are the two it names, and schema validation is the diagnostic for wrong attributes and elements.

Copy takeaways

ISOXML integration is the work of getting task data out of a farm management platform, onto the terminal in a tractor cab and back again as a record of what was actually applied. The Agricultural Industry Electronics Foundation states the scope that makes the round trip possible: "The worldwide ISO 11783 (ISOBUS) standard defines the communication between agricultural machinery, mainly tractors and implements, and also the data transfer between these mobile machines and farm software applications." The second half of that sentence is the platform engineer's half.

In short: A platform exports planned tasks with their fields, products and rates, a terminal executes them, and the platform reads back what the machine recorded as documentation. The format is defined in ISO 11783-10:2015, which is paywalled, so the element model below is described in our own words and the standard is cited by title rather than quoted. What a receiving product will accept is decided by the task controller functionality both ends are certified for, and the failure the AEF names as most common is not a modeling error at all but folder structure, with file naming next.

The two directions of a task data transfer

A task data set moves twice and carries different content each way. Outbound, the platform writes what is planned. Inbound, the terminal returns what happened, as the recorded-operation data the AEF's conformance test makes an FMIS process and visualize. Treating the two as one symmetrical format is an early and expensive mistake, because the outbound set is authored by the platform and the inbound set by a machine the platform has never seen. Read the AEF list below as a specification of the platform rather than of the file.

The AEF describes the outbound content in terms of what users expect a platform to hold. On its data management update it writes that "Customers expect to be able to plan tasks with products and rates, manage field boundaries and guidance data." and adds the precision layer: "With precision farming, variable rate application maps (Rx Maps) also come into play." The same page names the transfer and attributes it to the standard: "All this can be transferred between the FMIS and the mobile implement control system (MICS), in other words, the tractor and the implement, via ISO XML, as defined in Part 10 of ISO 11783."

The AEF publishes a test for both. Its FMIS conformance test announcement sets out the scope: "The Conformance Test verifies the processing and creation of ISOXML data sets. Furthermore, the FMIS has to be capable of managing farms and fields, plan tasks and list accomplished tasks." The export side is judged by whether the result runs, since a vendor can check "their own implementation to ensure the exported ISOXML data sets (tasks, prescriptions, etc.) are working on the vehicle’s terminal (ISO task controller)." The import side is judged the same way: "Also the FMIS’s processing and visualization of data from recorded operations is tested."

Where Part 10 and Part 11 sit in ISO 11783

Two parts of ISO 11783 carry almost everything a platform that never touches the machine bus needs. The ISO catalog entry for ISO 11783-10:2015, edition 2 gives Part 10 as the task controller applications layer, covering the requirements and services for communication between the task controller and electronic control units, and it records that the data format for communicating with the farm-management computer is defined in that same document. The second point is the one an integrator needs, and the AEF states it in operational words in the sentence quoted above, which is the citable anchor here.

Cite the part by its title: ISO 11783-10:2015, Tractors and machinery for agriculture and forestry, Serial control and communications data network, Part 10: Task controller and management information system data interchange. The catalog page records edition 2, published in September 2015, 205 pages, maintained by ISO/TC 23/SC 19. Those pages sit behind a paywall, which is the fact that shapes every element-level statement below: none of the AEF, isobus.net, ISO catalog or AgGateway pages read for this article names an element tag, attribute or cardinality, so every element-level statement below is our own description and the authority for the vocabulary is the purchased document.

The second part is the dictionary. The ISO catalog entry for ISO 11783-11:2011, edition 2 gives Part 11 as the specification of the identifiers for the data elements used in the Process Data message defined by ISO 11783-10, on a serial data network for forestry and agricultural tractors and their implements. That entry also carries a note explaining why this part behaves unlike the others: it is updated by a Maintenance Agency or Registration Authority. It was published in July 2011 and is three pages long.

Three pages cannot hold a dictionary. The identifiers live in an online registry that moves independently of the 2011 edition, so a platform never hard-codes a table lifted from the standard. Part 10 gives the container, Part 11 the vocabulary, and the registry its current contents.

The task data container and its element families

What follows is our description, not a quotation. The vocabulary is defined in ISO 11783-10:2015, cited above by title and nothing here is attributed to the AEF, to isobus.net or to ISO.

A transfer set is a directory holding an entry-point XML document, conventionally TASKDATA.XML, plus the binary files it references. The XML splits into two halves that behave differently. One half is reference data: the farm, the field and its boundary, the crop, the product, the worker and the machine with its addressable parts. The other half is the tasks, each pointing at that reference data rather than repeating it. Respecting the split produces a clean exporter, because the reference half projects the platform's catalogs and the task half its work orders.

Two element families are not only XML. A prescription map is a raster: cells with a value each, stored as a separate file, so a variable-rate job is a lookup by position rather than a list of instructions. A time log is the return trip's payload, a binary stream with an XML header declaring what the records contain and in what order. The header is the decoder, and a log whose header the platform cannot resolve is an opaque blob however well formed the set around it.

The table below is the map an importer and an exporter are written against, and its columns are not equally sourced. Element names are ours, from the standard cited by title. The second column paraphrases what the AEF describes as the content of the transfer, the third is editorial engineering practice, and the fourth is sourced where the cell says so and our engineering judgment everywhere else.

Element family (ours, from ISO 11783-10 by title)	What it carries	FMIS action (editorial)	Failure seen in practice
The TASKDATA.XML container	The whole exchange: reference catalog plus tasks	Single entry point, read first on import	Sourced: a folder structure a strict terminal rejects, or a file name not in capitals
Task	Planned or accomplished work, with products, rates and status	Plan, export, list back as accomplished	A task that imports with no products, because a referenced catalog object did not travel
Partfield and boundary polygon	Field identity and the geometry the machine works inside	Export the boundary; on return match it to the platform's own record	Round-trip identity loss: the field returns as a duplicate because the echoed identifier is not the key
Crop type and variety	What is grown, as reference data a task points at	Map to the crop catalog, export only what is referenced	Silent substitution when no match exists and the importer picks the nearest name
Device and device element	The machine and its addressable parts, booms and sections	Read the device description before trusting a prescription	Declared counts sourced, the failure is practice: a prescription written for more sections than the receiving product declares
Product and product group	What is applied, as reference data with a unit	Map to the product catalog, carry the unit unchanged	A rate unit mismatch between the platform's unit and the dictionary unit logged
Worker	Who ran the task	Optional on export; on import match or ignore, never create	Personal data arriving in an import path never designed to hold it
Time log (binary with XML header)	Positions and process values per record, keyed by dictionary identifier	Parse the header, then decode the stream	Truncated logs after a power cut, and a header identifier with no handler
Grid (prescription raster)	The variable-rate map as cells with a value each	Generate from the prescription, export with its task	Practice, on the sourced intersection rule: a grid a terminal ignores because the functionality is unsupported on one end
Dictionary identifier (DDI, ISO 11783-11)	Meaning, unit, resolution and range of a measured value	Resolve against the online registry, not a compiled table	Practice: an identifier the platform cannot resolve, so the value arrives and is dropped, while the dictionary exists so that new measurements can be consumed

Two things are deliberately absent. The table states no attribute name, no cardinality and no data type, and says nothing about what changed between version 3 and version 4, which no reachable source describes.

The data dictionary and the DDI lookup

Every measured value the machine reports arrives as a number next to an identifier, and the identifier is the only thing that gives the number meaning. Those identifiers live in the ISO 11783-11 online data base at isobus.net, free to read, carrying a version stamp independent of the 2011 edition with a documented change-request route.

A single record is richer than a name and a unit. On one entity page the record opens with "Definition Accumulated Yield specified as volume Comment is a counter of a machine element" and then gives the machine-readable half: "Unit Symbol L - Bit Resolution 1 SAE SPN not specified CANBus Range 0 to 2147483647 Display Range 0 to 2147483647". It closes with a lifecycle rather than a static row: "Current Status ISO-Published Status Date 2005-02-02 Status Comments DDEs have been moved to published for creating the new Annex A version." That status history makes this a registry, and a cached copy a snapshot with an expiry.

The registry grows on purpose. Describing a sensor taskforce, the AEF writes on its data management update that "The taskforce wants to standardize these constituent measurements by adding them into the ISOBUS Data Dictionary so that the farmer can bring the NIR information into their preferred Farm Management Information System (FMIS)." New measurements reach a platform through the dictionary, so an importer built around a fixed list goes stale by design.

Our practice on this is unambiguous. Treat the dictionary as reference data the platform syncs and versions, never as an enum compiled into the decoder. Store the raw identifier and value beside the interpreted value, so a record decoded under an old sync can be re-interpreted without a second import. Log an unresolved identifier with its record instead of discarding it, because a value never sent and a value dropped look identical to the farmer.

Task controller functionalities and what they warrant

The task controller is not one thing. The control function register at isobus.net lists the family with a server and a client side each: "7 - Task Controller Basic (TC-BAS) Server 8 - Task Controller Basic (TC-BAS) Client 9 - Task Controller Geo (TC-GEO) Server 10 - Task Controller Geo (TC-GEO) Client 11 - Task Controller Section Control (TC-SC) Server 12 - Task Controller Section Control (TC-SC) Client". A newer member sits in the same register, Task Controller Tramline, so the set is not closed at three.

Those numbers describe control functions on the bus, and an FMIS is not on the bus. What an FMIS is certified for is the AEF functionality, tested separately, and the practical question is which functionality the counterpart product supports. The baseline is TC-BAS: tasks, accomplished-task lists and documentation. TC-GEO is what makes a map work at all, and on its FMIS conformance page the AEF states the difference in a line: "TC-GEO adds handling of field boundaries, prescription maps (rxmaps) and the visualization of logged data (as applied maps)." Section control, TC-SC, is the third member: a TC-SC product declares how many booms and sections it supports, and in our reading that number is what an exported prescription has to respect.

Certification on every product is what turns a hope into a warranty. On its data management update the AEF puts it plainly: "So, if the FMIS, tractor display and implement are all certified for the TC-GEO functionality the AEF warrants that field boundaries and Rx Maps will successfully be transferred from FMIS to display and that the variable rate job can be executed as planned." That is the strongest statement a platform team can lean on, and it is conditional on all three products rather than on a valid file.

Compatibility is an intersection rather than a union. The AEF's ISOBUS database page describes its own answer that way: "The database will show both the functionalities supported by each of the chosen products as well as those supported by all of them, i.e. the functionalities that can actually be used by this specific combination." A crew running a certified platform, a certified display and an uncertified implement has the capability of the weakest link.

Sections are the clearest machine-side constraint an exporter respects. The same register records what a section control product declares as a certified option: "11 Task Controller Section Control (TC-SC) Server (Byte 1) 1 to 255 Number of supported booms 11 Task Controller Section Control (TC-SC) Server (Byte 2) 1 to 255 Number of supported sections". A prescription authored for a geometry the receiving product cannot address is not a file problem, and in our experience no schema validator catches it, because it is not a schema question. Model the functionality level on the machine record and let the exporter branch on it.

Failure modes seen in practice

The most useful institutional text on this subject is not about data modeling. On the page announcing its task data validator the AEF writes that "Operators working with the TaskController in the field sometimes have issues while importing ISO-XML taskdata in different terminals." and names one of the most common: "One of the most common issues is the wrong folder structure on the USB stick. Some terminal suppliers are strict with the folder structure, which means that the TASKDATA.XML cannot be found." Another reason it names is the file name: "Another reason could be the wrong file naming. It’s important that the task data is named “TASKDATA.XML” by using capital letters."

Read that as a product requirement rather than a curiosity. A platform handing a user a download does not control what happens next, so the safe design writes the directory layout and the file name itself and ships one archive that extracts to the right shape. Case sensitivity deserves its own test, because a developer machine that ignores it passes what a customer's terminal fails.

The third class of failure looks like a data problem. The same announcement says why reading the file is the wrong first move: "Sometimes wrong attributes or elements are used which are not easy to find. Checking elements by hand takes a lot of time. For this reason, the ISOXML schema validation is the best way to identify the issue." Schema validation belongs in the export pipeline as a gate, not in a support tool reached after a complaint arrives.

Behind all of that sits a structural cause the AEF states directly on its data management update: "However, the standard ISO 11783 sometimes allows for variations which can lead to data loss or restricted functionality, especially with a mixed fleet." It adds that this is not confined to the machine side: "This is not only the case for the communication between tractor display and implement, but also for the data transferred between tractor display and the FMIS." A platform serving farms with mixed equipment is serving the case the standard handles least well.

The root of it is old and acknowledged. The AEF's ISOBUS overview says so about the standard it exists to support: "It is the most significant and comprehensive standard to date, but it leaves room for interpretation, which has led to a great number of innovative but proprietary ISOBUS solutions." Room for interpretation is why two conformant implementations disagree, and why certification is tested and not declared.

Three further failure modes are ours, from engineering judgment rather than from any published source. A partfield that loses its identity on the return trip and reappears as a duplicate is the silent corruption we would design against first, and the defense is a reconciliation step that matches on geometry and name before trusting an identifier. A time log ending mid-record after a power cut needs a decoder that keeps every complete record and reports the truncation, because a strict parser rejecting the whole file throws away a day of work. A unit converted twice between platform and dictionary produces numbers that are plausible and wrong, so the conversion belongs in one layer with a round-trip test.

Versions, coordinates and geometry validation

This section is entirely our own engineering practice. None of the AEF, isobus.net, ISO catalog or AgGateway pages read for this article states what differs between version 3 and version 4 of the format, which terminals accept which version or what coordinate convention the format uses.

Our position on the boundary is this. Which version a set declares is a per-machine negotiation rather than a property of the platform, so an exporter that supports more than one carries a target-version setting per machine and a test corpus per target version, and promotes a machine only when that corpus passes. What actually differs between the versions is read from the text of the standard the platform has bought, never from a page like this one. Field-test the combination before a customer does, because a version mismatch presents as a terminal refusing the set with no useful message.

Geometry deserves its own validation stage, run before export and independently of any schema check. Boundary polygons authored in a web map arrive with the defects web maps produce: self-intersections, rings that do not close, holes wound like their outer ring and vertex counts large enough to matter on embedded hardware. A schema validator accepts all of those, because they are valid XML. Normalize winding, snap near-duplicate vertices and reject a self-intersecting ring while it is still being drawn.

The coordinate question has the same shape. Decide the convention once, from the standard you have bought, assert it in one place, and reject any exported geometry whose centroid falls outside the farm's own extent. A swapped axis order is invisible in a file and obvious on a map, so the cheapest place to catch it is a rendered preview.

ADAPT as an intermediate model

A platform talking to more than one file format eventually wants a common model in the middle, and AgGateway built one. Its ADAPT Framework site describes the shape: "The ADAPT framework is comprised of an Agricultural Application Data Model, a common API (Application Programming Interface), and a combination of open source and proprietary data conversion plugins." The plugin layer is where a format meets the model: "Plugin libraries that allow the farm management software to convert to and from the common object model and different file formats."

ISOXML has a named plugin of its own. The AgGateway-ADAPT organization's repository README describes it in one line: "ISOv4Plugin: C plugin to read/write ISOXML (ISO11783-10) format to/from the ADAPT Framework." The same README places the framework under a maintenance heading: "Maintenance Mode - ADAPT Framework: C toolkit including an in-memory data model, plugin architecture, and standard data representations/unit of measure notations." AgGateway's repository map places the ISOv4Plugin under that same maintenance heading rather than under the current-development one. That file is markdown, and the language it prints as C is C# in the source.

Two constraints decide whether the route fits. The framework is .NET, and the framework site is explicit: "It can run on Windows, Mac or Linux if your platform runs the .NET Framework or Mono." Another language reaches the plugin through a service boundary rather than in process. The second constraint matters more: "Participating FMIS (Farm Management Information System) companies will be responsible for completing their own implementation of mapping the Agricultural Application Data Model to their FMIS data model." ADAPT removes the format problem and leaves the modeling problem, the larger of the two.

Status matters here more than capability. AgGateway's own ADAPT Standard page states the framework's position: "AgGateway will continue to process code contributions to the ADAPT Framework, but AgGateway does not intend to organize further development efforts." A team choosing it today is choosing a stable dependency rather than a growing one.

The successor is a data specification rather than a toolkit. The ADAPT Standard README states the relationship and the difference an integrator will feel: "It is the successor to the AgGateway ADAPT Framework released in 2015 that served as a software plugin toolkit to read proprietary files. Unlike the earlier toolkit, the ADAPT Standard does not have any software dependencies. It is data only." The ISOXML route named in AgGateway's own repository map is the framework's ISOv4Plugin.

The online channel beside the file

Removable media is not the only path between machine and platform. The AEF publishes a guideline for the online case, announced on its EFDI page: "This EFDI guideline provides an extensible communication system concept and defines rules for adding new functionalities to cover specific use cases for the communication between ISOBUS machines and FMIS systems." The guideline sits in the AEF's member area, so it is named here and not described.

Beside the guideline, and from our own engineering reading rather than any institutional source, machinery manufacturers operate telematics platforms with their own cloud APIs and account linkage. Our practice treats the online channel as a transport delivering the same domain objects rather than a second integration, keeping the file reader and the API client behind one interface. The telemetry concerns that go with it, collection, buffering and clock discipline, are covered in our IoT development guide.

How Pharos Production helps

An ISOXML integration has four parts that no standard and no framework hands you: the mapping between the transfer set and the platform's own model, the geometry and unit validation that runs before anything leaves, the time log decoder with its dictionary sync and the reconciliation that keeps a field from multiplying on every return trip.

Our agriculture software development team builds that layer inside an existing farm management platform, keeps the file and online routes behind one domain model and tests exported sets against the functionality level a customer's fleet supports. The wider platform picture is in our agriculture software development guide.

Sources: AEF pages on aef-online.org (The AEF ISOBUS, AEF ISOBUS Database, the FMIS conformance test, the Taskdata Validator, the Data Management Update and the EFDI announcement); the ISO 11783-11 online data base at isobus.net; the ISO catalog pages for ISO 11783-10:2015 and ISO 11783-11:2011; AgGateway's ADAPT Framework site, the AgGateway-ADAPT organization and Standard READMEs and AgGateway's ADAPT Standard page. ISO 11783-10:2015 and ISO 11783-11:2011 are cited by title and edition and are not quoted, and their catalog entries are paraphrased rather than quoted. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: October 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• Should we write our own ISOXML reader, use the ADAPT plugin or buy an SDK?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  This one is our engineering judgment rather than a sourced answer. Write in house when the transfer set you need is narrow, your stack is not .NET and you can carry the standard's text as a long-lived dependency.

  Take the ADAPT plugin route when you want one model across more than one file format and can accept a .NET boundary plus a component the organization's own repository map lists under maintenance. Buy an SDK when the deadline is short and you need someone to answer terminal-specific questions. Whichever route you pick, mapping the format onto your own model stays your work.

• Do I need to buy ISO 11783-10 to build an integration?

  Copy link Copies a direct link to this answer to your clipboard.

  To implement it correctly, yes. None of the AEF, isobus.net, ISO catalog or AgGateway pages read for this article names an element tag, an attribute or a cardinality, and the ISO catalog entry records that the data format for communicating with the farm-management computer is defined in ISO 11783-10:2015.

  Free sources tell you what the standard covers, who maintains it and what certification warrants, which is enough to scope a project and choose an approach. It is not enough to write a conformant reader or writer, and a team assembling the format from unofficial copies inherits their errors with no way to check them.

• What does a failed task data export cost the grower?

  Copy link Copies a direct link to this answer to your clipboard.

  Our framing, not a sourced figure. A prescription is consumed inside a field-operation window set by weather, soil condition and crop stage, and the operator is already in the cab with the implement attached when the terminal refuses the set.

  The fallback is a flat rate applied by hand, so the variable-rate plan for that field is gone for the season and so is the as-applied record that would have documented it. The cost is a lost agronomic decision plus a documentation hole, which is why the export gate belongs before the download rather than in support.

• What is a DDI and where do I look one up?

  Copy link Copies a direct link to this answer to your clipboard.

  A DDI is the identifier ISO 11783-11 assigns to a data element, and it is what gives a logged number its meaning. The standard itself is three pages, because the entries are maintained as an online registry rather than printed: the live list is the ISO 11783-11 online data base at isobus.net, versioned independently of the 2011 edition.

  A record carries a definition, a unit, a bit resolution, the device classes that typically use it, valid ranges and a publication status. Sync it as reference data instead of compiling a fixed table into the decoder.

• Which parts of this page apply to my situation?

  Copy link Copies a direct link to this answer to your clipboard.

  Our reading of who needs what. A greenfield farm management platform reads the first half: the two transfer directions, where Part 10 and Part 11 sit and the element families, because those decide the domain model before any code exists.

  A platform retrofitting ISOXML onto a model it already has reads the second half: the dictionary sync, the functionality levels, the failure modes and the ADAPT question, because the mapping is the whole job. An implement maker reads the functionality section, since what an FMIS may send is bounded by what the product declares.

• What can I test before shipping an ISOXML integration?

  Copy link Copies a direct link to this answer to your clipboard.

  Two institutional checks exist and the AEF describes both. The AEF Taskdata Validator was developed and released to support service technicians and operators in analyzing and validating ISO-XML schema automatically to find the issue.

  The AEF FMIS conformance test verifies the processing and the creation of ISOXML data sets, and requires the FMIS to manage farms and fields, plan tasks and list accomplished tasks. Eligibility and current scope are the AEF's to state, so check the AEF pages. Beside them, run your own schema validation and geometry check inside the export pipeline.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.