From FMIS to farm machinery: making ISOBUS in agriculture and variable-rate workflows interoperable
A variable-rate prescription can reach a tractor terminal and still produce the wrong treatment. Its rate may be misread, a zone displaced, or the completed operation never returned to the Farm Management Information System (FMIS). The connection worked; the workflow did not.
ISOBUS interoperability is a system-level capability that preserves the meaning of agronomic instructions and machine records across equipment and software from different manufacturers. For agricultural machinery OEMs and FMIS providers, the entire process must be verified.
In brief: agricultural machinery needs more than ISO 11783 compliance
ISO 11783 and AEF certification, which cover communication protocols, also lay the foundations for interoperability. However, it cannot guarantee accurate variable-rate application. Successful workflows require supported Task Controller functions, consistent data, resilient synchronisation, and reconciled as-applied records.
- Successful import does not prove correct application.
- TC-GEO, TC-BAS and TC-SC serve different purposes.
- Machine-reported rates are not always the actual measured rates.
- Offline recovery and representative hardware tests are essential.
Why does ISOBUS interoperability extend beyond certification?
ISOBUS follows ISO 11783 as the communication standard for tractors and implements. ISO 11783-10:2015 describes Task Controller and FMIS exchange. The Agricultural Industry Electronics Foundation (AEF) tests defined functionalities and maintains a certified-product database.
A sprayer can work through a Universal Terminal yet reject geo-referenced prescriptions. Certification identifies functions, not the reliability of an OEM cloud connector or full field operation.
Table 1. Selected AEF ISOBUS functionalities. Source: AEF.
AEF also tests FMIS support for TC-GEO prescriptions and records. Consult the AEF functionality guide, then check the complete tractor–terminal–implement combination.
From plan to as-applied record: how should the workflow operate?
Variable-Rate Application (VRA) needs five verified handovers.
- Plan: The FMIS links field, crop, product, target rate, geometry, and task ID. Soil tests, yield maps, or satellite indices may inform the prescription.
- Prepare: Geospatial software transforms management zones or grids into a supported task format, preserving units, product associations, and machine capabilities.
- Transfer: ISOXML travels by removable media or supported online services; some OEMs also use proprietary files or APIs. Uploaded, imported, and accepted are different states.
- Execute: The Task Controller and implement regulate application. Calibration, speed, GNSS quality, section switching, and operator overrides affect the actual result.
- Reconcile: Returned logs, task totals, and available position-dependent values are matched to the original operation, including incomplete areas and duplicate events.
Without returned records, planned, interrupted, and completed work may be confusing. One-way transfer is not a closed loop.
For a practical comparison of these technologies, the FarmPortal guide to variable seeding, fertilisation, and spraying examines how different application methods use soil data, satellite imagery, vegetation indices, and field zoning to produce machine-ready prescription maps. It also provides an implementation example in the FarmPortal FMIS, where agronomic data is translated into application maps for compatible agricultural machinery. The article shows why map resolution, formats such as ISOXML and SHP, and the capabilities of the tractor–terminal–implement combination must be considered together when designing a reliable VRA workflow.
Where do ISOXML and prescription maps most often fail?
Valid ISOXML can still be agronomically wrong. XML validation cannot identify a mislabelled fertiliser, displaced field, or unsupported dosing channel.
Table 2. Common failures in FMIS–machinery data exchange.
Kilograms of fertiliser product per hectare are not kilograms of nitrogen per hectare. Nor is spray-mixture volume equivalent to active substances. Converters require quantity types, units, products, and relevant data dictionary identifiers (DDIs).
Precise GNSS/RTK cannot correct a wrong coordinate reference system; reproject maps, validate boundaries, and retain task identity across revisions.
Which tractor–terminal–implement combinations should an OEM test?
For OEM testing, you should record terminals, controllers, firmware, GNSS, and required AEF functions. Prioritise installed and high-risk combinations. Even TC-GEO implementations can differ in channels, map representations, and logged values. Repeat configuration-specific tests after software or device-description changes.
How should telemetry and GNSS data be integrated with the FMIS?
GPS tracks alone do not prove application. Where available, return task IDs, configurations, commanded and measured rates, speed, section states, working width, GNSS quality, and overrides.
An as-applied map contains machine-reported spatial values. Logged setpoints are not actual verified physical deliveries. Calibration and field checks are essential when actual dose matters, including for processors using farm records in traceability.
Building APIs and offline synchronisation for field conditions
Machinery must tolerate mobile network loss. Accepted tasks should execute locally under machine safeguards, with records queued for later upload.
Preserve task IDs, prescription versions, units, and source timestamps. Track created → delivered → accepted → started → completed → reconciled: an API acknowledgement is not proof of treatment.
Durable queues, idempotent retries, and deduplication protect records. Detect conflicting prescription revisions rather than overwriting accepted tasks. AEF’s Agricultural Interoperability Network (AgIN) supports cloud work-order and machine-record exchange, but cannot validate physical execution.
Testing interoperability: SiL, HiL and field trials
Software-in-the-Loop (SiL) checks ISOXML, units, geometry, and APIs. Hardware-in-the-Loop (HiL) tests real controllers against simulated GNSS and faults. Field trials assess calibration and physical coverage. All these methods complement one another.
Test zero-rate zones, broken polygons, disconnected transfers, GNSS degradation, duplicate logs and overrides. Replay the field data after it has been released.
A 2025 study in Smart Agricultural Technology by Poss and colleagues produced ISO 11783-compatible vineyard prescriptions from LiDAR canopy reconstruction. It reported R² = 0.92 between manually measured leaf area and LiDAR point counts, and a maximum 8.3% RMSE for test-board height estimation. These figures evaluate sensing and modelling within that study; they do not establish spray accuracy or input savings.
Track import success, rate discrepancies, log completeness, and offline recovery. And also agree on task-specific tolerances before testing.
Case study: integrating machine guidance with an FMIS
Spyrosoft supported a European project connecting machine guidance with farm management software: VRA map generation, remote delivery, ISOXML, tracks, and cloud telemetry.
Spyrosoft’s 2026 project documentation records 3,000+ integrated devices, 700,000+ daily events, and 840+ VRA maps remotely updated each day during the season. These indicate scale, not proven savings, application accuracy, or blanket certification.
Scale and field correctness require separate tests.
Acceptance checklist for OEMs and integrators
A release evidence pack should confirm:
- Required AEF functions and firmware combinations are documented.
- Product, unit, DDI, channel, and prescription revision are preserved.
- Field boundaries, zones, headlands, and offsets are spatially correct.
- Terminal import, rejection, pause, and cancellation work as specified.
- Setpoints and available measured values remain distinguishable.
- Partial tasks, missing logs, and duplicates reconcile correctly.
- Offline operation and retry do not lose or overwrite records.
- SiL, HiL, and field evidence reference the tested release.
Remember that a file transfer is not proof of execution.
Who benefits from interoperable ISOBUS in agriculture, and how can Spyrosoft help?
Ensuring interoperable workflows between variable-rate and ISOBUS in agriculture can provide benefits and enhance efficiency for most parties:
- OEMs gain reproducible tests and diagnostics.
- FMIS providers gain maintainable mixed-fleet connectors.
- Growers and processors gain clearer work histories with visible data provenance.
Spyrosoft designs integration layers around existing OEM and farm software, not closed replacement platforms. Its capabilities cover embedded connectivity, APIs, geospatial, cloud engineering, offline synchronisation, and test automation. Start with one validated workflow, then expand.
Conclusion
ISOBUS provides a common language. Interoperability requires the right prescription to reach the machine, execute correctly and return as a trustworthy record.
Start with one VRA workflow, documented configurations, and measurable acceptance criteria, and we will halp you design and test that integration. Contact us via the form below, and let’s see how we can assist you with interoperable workflows in line with ISOBUS standards.
Glossary
FMIS: Software for planning and recording farming operations.
ISOBUS (ISO 11783): Global standard and universal language enabling communication between tractors, terminals, and implements from different manufacturers; key ISOBUS components can support communication, control, and data exchange across agricultural equipment and machines.
ISOXML: Task-data exchange format for FMIS and controllers.
Task Controller: On-machine task control and recording function.
VRA: Variable-Rate Application, adjusting input rates according to a spatial prescription.
Prescription map: Spatial plan of intended rates.
As-applied data: Recorded application values and positions.
GNSS/RTK: Satellite positioning with precision corrections.
SiL/HiL: Software-in-the-Loop/ Human-in-the-Loop – simulation-based testing with software or controllers.
References:
ISO 11783-10:2015 (confirmed in 2026); AEF, ISOBUS Functionalities and TC-GEO Conformance Test FMIS (2021); Poss et al. (2025), Smart Agricultural Technology, 10, 100870; Spyrosoft (2026), Selected Projects Examples, internal project documentation.
FAQ
No. Certification covers defined functionalities, while prescription maps require appropriate Task Controller and implement support, including TC-GEO where applicable. Confirm capabilities for the actual tractor–terminal–implement combination and test the installed firmware. A working Universal Terminal is not sufficient proof of variable-rate support.
TC-GEO handles location-specific prescriptions and spatially referenced records. TC-SC switches implement sections according to position and equipment geometry. They address distinct requirements: a sprayer may need both, but supporting one does not establish support for the other. The AEF compatibility check identifies available functionalities and options.
Yes, as long as the machines and terminals support the relevant ISO 11783 functions and data formats. Mixed fleets still require verification of ISOXML versions, device descriptions, products, units, and supported prescription types. Some OEM services use additional APIs or proprietary files that need separate integration and validation.
Yes, if the terminal has accepted the prescription and the machine supports independent local operation. Data should be buffered until connectivity returns, then uploaded with duplicate protection. Revised cloud tasks must not silently overwrite a prescription already accepted or underway. Offline behaviour should be explicitly tested before release.
Not necessarily. The map may contain setpoints, calculated application values, or calibrated measurements. Positioning, time alignment, implement offsets, and sensor quality determine what can be inferred. Where precise delivered dose matters, verify equipment calibration and compare reported values against independent field measurements.
Scope depends on machine combinations, available OEM APIs, prescription formats, offline requirements, and physical validation. One terminal–implement proof of concept is far narrower than a maintained mixed-brand integration. Define supported workflows, configurations, and acceptance tests before estimating development, laboratory and ongoing regression costs.
arrow_circle_rightContact us
Let’s discuss how we can help you with your AgriTech projects
arrow_circle_right Our articles
