• Basic Contact Info

    General Information and PR
    info@openag.io

    Aaron Ault
    OADA Project Lead
    Senior Research Engineer
    Open Ag Technology Group at Purdue University
    aaron@openag.io

    Media Contact
    Joe Dager, ApRecs
    509-293-7057

  • Let’s Connect

  • We Respect You

    Please let us know a little about yourself and an OADA representative will reach out with information about the organization and how to get involved.

    There are many ways to contribute and benefit from the OADA Community. We look forward to exploring them with you.

  •  
  •  

Principals & Use Cases

Summary

This document describes the motivation behind forming the Open Ag Data Alliance (OADA), data-related challenges that farmer’s face today, how OADA will address those challenges, and how farmers will benefit from OADA. OADA will create a secure data ecosystem that enables data
security, privacy and interoperability
for the entire agriculture industry. OADA will achieve this through an open standards software effort to establish secure data exchange protocols. This open software development approach is how Internet, network and web standards have succeeded in providing secure, scalable solutions for businesses and consumers alike.

Starting with a common, secure, and interoperable Application Program Interface (API) specification, an environment can be created in which farmers have complete freedom to choose best-in-class products from precision ag vendors with confidence in the data security and privacy and no danger of vendor data lock-in. Farmer participation in the newly-enabled OADA-compliant precision ag services market will drive innovation across the agriculture industry to enable the next generation of sustainable agriculture.

Background

Modern production agriculture has the potential to dramatically improve crop yields and reduce environmental impacts by enabling farmers to properly evaluate past, current and future farm management decisions through analysis of agronomic data generated in the field.

However farmers are currently overwhelmed with walled gardens of incompatible data generated by their existing systems (geodata images, logs, reports, charts). Farmer’s want the hardware and software systems they use to interoperate – that is, to share information and be able to adequately rely on each other to help support decision-making.

The most scalable solution for farmers is to enable their hardware and software systems to communicate automatically through secure cloud services or tools. Any system needs to incorporate data from a multitude of sources in order to be useful. However, existing solutions suffer from:

  • an inability to gather data from all aspects of any given farm since no one manufacturer accesses all the operational data on a farm,
  • farmers’ concern about what will happen to their data,
  • and questions about data ownership and intellectual property.

In order to enable this next stage in production agriculture productivity, these three issues have to be resolved. Past attempts at solving data sharing and compatibility have revolved around creating monolithic standards that are licensed commercially and selectively. Farmers require an open solution that works with existing standards, adheres to clear privacy and security policies, and doesn’t require farmers to pay to access their own data. This is not a unique set of challenges. Other industries have faced a similar stage in their evolution, including financial services, healthcare, and the Internet. In all cases, a distributed, rather than centralized, network model emerged as best for the end users.

What OADA is

With the mission to ensure farmers have full data access, security and privacy, OADA:

  • will operate with a farmer-focused approach through a central guiding principle that each farmer owns data generated or entered by the farmer, their employees or by machines performing activities on their farm,
  • will develop open reference implementations of data storage and transfer mechanisms with security and privacy protocols,
  • will provide a forum for technical community discussion,
  • will be led according to the processes of open standards projects that have built much of the Internet’s networking, security, web and data standards with multiple university, individual and corporations participating (often while competing in the marketplace). Examples include the Internet Engineering Taskforce (IETF), World Wide Web Consortium (W3C) and The Apache Software Foundation, (which supports over 100 projects).
  • will direct any financial contributions to a not-for-profit foundation whose purpose will be to enable open source projects in agriculture in service of the OADA mission.

What OADA is not

It is important to also specify what OADA does not intend to do. OADA:

  • will not produce or sell commercial products,
  • will not be a provider of cloud storage or services,
  • will not be a political lobbying organization,
  • and will not endorse or oppose products or services beyond providing software tests that can be used to validate OADA functional support.

The OADA Approach to Interoperability

The OADA approach to interoperability is to avoid implementation frameworks that inherently dictate winners and losers, focusing instead on providing developers with the useful libraries they need in order to communicate and access data without spending tedious hours memorizing several monolithic standards. In short, the problem of interoperability is largely solved simply by making API’s and libraries for data access publicly available rather than requiring everyone to use a predefined standard.

Existing efforts at enabling interoperability are focused on closed, licensed standards that attempt to enforce uniformity of data formats. While uniform representations of data are a laudable goal, organic growth of standards out of open implementations have proven far more effective in other industries than top-down control. For example, images can be stored in many “standard” formats (jpeg, png, gif, etc.), yet there is little developer pain around using images today because simple libraries grew out of communities that enable a developer to use all of them. Software exists today that can handle wide varieties of ag data formats. The real problem is getting secure access to data without tedious human intervention and repeatedly reinventing the wheel.

While each commercial vendor can implement their own OADA-compliant tools and services using technologies familiar to their organization, the existence of an open reference implementation that contains a verification test suite will provide a framework by which the industry can work
together.

How OADA Supports Security & Farmer Privacy

OADA will develop authentication and security protocols that will support third-party verification of provider security and privacy practices. OADA security and privacy working groups will collaborate with stakeholder groups in defining the technical capabilities that can represent the range of business security and privacy practices that are desired by the broad community. The farmer will be able to use OADA services with a full understanding of different service provider security and privacy levels which are clearly and simply represented through their OADA-compliant tools.

Example Use Case

The OADA vision is best explained through an example. Consider the common use case of prescription maps. Frank is a farmer with a corn planter capable of varying seed population based on GPS location using a prescription map: i.e., under the irrigator seeds should be closer together and outside the irrigator they should be farther apart because there is less water to go around.

Andy, a local agronomist, has worked with Frank for years. Andy offers to create a custom prescription map for some of Frank’s fields. To do this, Andy says he needs the past three years of yield data, recent soil tests, as-applied fertilizer maps, outlines of Frank’s irrigator pivot coverage area, and info on the type of corn variety that Frank intends to plant in each field. Andy loads Frank’s data into an existing software package, generates a prescription map that works with Frank’s planter monitor, and gets the map to Frank before planting begins.

Use Case with Current Industry State

Figure 1: Current state of the ag data industry from a farmer’s point of view. Note that some important data (in red) never makes it back to the farmer at all.

The way this use case generally occurs today begins with Frank telling Andy those dreams of having all that data aren’t going to happen. Frank then spends a painstaking amount of time simply gathering whatever information he can. Exporting yield data for every field from his desktop computer or OEM-specific cloud service, looking up past PDF files that have soil test information, zipping all these files up, and sending them to Andy. Frank doesn’t have the as-applied maps for fertilizer, because the fertilizer co-op never sent them. Frank looks back at his seed order receipts, and types up a spreadsheet with field names and seed varieties.

Andy then calls up the local seed salesman for some of the unfamiliar varieties to get seeding recommendations. Frank doesn’t have the outlines for his irrigators saved anywhere, so Andy pulls up Google Earth, draws the approximate circles, and saves them to a KML file on his personal computer. After some significant data massaging, Andy gets all this imported into his existing software, makes a seed prescription, exports a file formatted for Frank’s planter monitor, and emails it to Frank. Frank saves the file on his computer with prescriptions from other people for other fields, and eventually puts them on a USB stick to import into his planter monitor.

Use Case with OADA Interoperability

Figure 2: The farmer’s clouds can work together through the common OADA REST API to enable trusted agents to manage the farmer’s data for him. Should the farmer become unhappy with any given cloud provider, he can easily transfer his data to another cloud provider.

The OADA example workflow for the prescription map is one where Frank has an account with an OADA-compliant cloud provider. His precision ag data is there, his third-party applicator’s precision ag records for his fields are there, and the KML for his irrigator pivot outline is there. Some of Frank’s precision ag data first goes into a different OADA-compliant cloud due to device compatibility on one of his tractors, but Frank has configured his main cloud to just sync up those files automatically via those service’s OADA-compliant capabilities (provided by the OADA REST API framework).

Frank likes this, because he finally has a one-and-done place to keep his data, and he can switch to another cloud seamlessly someday if he has reason to do so. Frank logs in to the service and gives Andy permission to access the files he needs. The permission provisioning implementation is provided by the cloud service but must adhere to the community guidelines for privacy.

Andy’s latest version of prescription-building software has support for retrieving files from OADA-compliant data stores. The ag-based file metadata can tell it everything needed to parse the files properly: manufacturer, data type, version, shapefile columns, etc. Andy points it to the cloud, loads in the files, and builds the prescription. He exports a file for Frank’s monitor and puts it directly into Frank’s account. Frank’s new OADA-compliant telematics device has been configured to point to Frank’s cloud and retrieve prescription files directly, and upload as-applied planting maps automatically.

It is the ag-based metadata that distinguishes this approach from a standard cloud-based file store. That basic layer will allow OADA to extend and support a wide array of ag-specific features that simply are not possible with standard file storage, such as opening files directly in client software without the need to manually specify any information about them.