agrirouter ecosystem

Overview of the ecosystem

The agrirouter is a central data exchange platform, but to understand its full power, it’s important to understand that the data provided from the agrirouter comes from the applications attached to the agrirouter. The following figure lists different Applications that can be attached to one end-user account.

Figure 1. The agrirouter ecosystem of members

Applications

Communication Units

Figure 2. Communication units in the agrirouter ecosystem

Communication units (CU) are mobile applications, mostly running on embedded systems or mobile devices to establish a connection to the agrirouter "in the fields". CUs are used to collect information like machine data or geo positions.

CUs are usually but not necessarily connected to machines via ISOBUS and collect their data during the common ISOBUS interaction using an ISOBUS TaskController or DataLogger.

CUs should have a stable internet connection to provide live data. Otherwise, a CU should buffer generated messages to send them, once the internet connection returns.

Like any other endpoint, CUs are able to request information from the agrirouter, e.g. to inform a driver about other (V)CUs positions (fleet management). The more important job of CUs, however, is to provide data to agrirouter.

A list of compatible CUs can be found here: https://agrirouter.com/en/solutions.

Please note that there might be additional CUs in development.

Communication units can also be tablets or other devices and should meet the following base requirements:

Every single device has to have internet connectivity and must be able to communicate via HTTP(S) with REST or via MQTT. The communication consists mainly of payloads in Google Protocol Buffer format.
Endpoints without constant internet connectivity are not able to send real-time data. Sending recorded data after establishing an internet connection will be a valid use case for endpoints not having internet connectivity during the main working process of a machine.

Farming software

Figure 3. Farming Software Applications in the agrirouter ecosystem

Farming software can be a cloud application or software released on a single device like a PC or Smartphone. Farming software mostly consumes data to provide extra services for farmers or contractors. FMIS (Farm Management and Information Systems) are a common example of farming software.

A list of farming software applications can be found here:

https://agrirouter.com/en/solutions

Please note that there might be additional software in the development of the compatibility.

Telemetry platform and virtual CUs

Figure 4. Telemetry platform with virtual CUs in the agrirouter ecosystem

A telemetry platform is a cloud software solution that handles the communication of so-called "virtual CUs" with the agrirouter. Virtual CUs are comparable to real CUs, but indifference, they do not implement the agrirouter protocol. A virtual CU implements a proprietary protocol to connect to the telemetry platform only.

The telemetry platform is connected to the agrirouter providing the data of selected virtual CUs to the connected agrirouter account. The onboarding process of a telemetry platform equals the process of onboarding a Farming software. Virtual CUs can be onboarded by the telemetry platform without user interaction.

In the agrirouter UI, the telemetry platform and each virtual CU are displayed as endpoints.

A list of compatible CUs can be found here:https://agrirouter.com/en/solutions.

Please note that there might be additional telemetry systems in the development of the compatibility.

Overview of the architecture

This chapter gives a high-level overview of the agrirouter architecture an application can interact with.

Figure 5. agrirouter connectivity platform architecture

Communication addresses: Endpoints

An endpoint is an addressable communication address for an application instance connected to the agrirouter. One application instance can be part of multiple agrirouter accounts or there can be multiple instances of the same application in one agrirouter account. An example of multiple instances of the same application in one account is multiple CUs onboarded to one account.

The address of an endpoint (in this case the "deviceAlternateId") is used by its corresponding app instance to communicate with the agrirouter and by other app instances within the same account to address this app instance (in this case the "sensorAlternateID").

Teamset

A teamset is a set of connected machines that work and move together and are connected to the same (virtual) communication unit. The machines in the teamset are typically connected physically and informationally (for example via ISOBUS).

A (virtual) CU is responsible for the agrirouter communication of one teamset. It sends descriptions of the machines in the teamset whenever the teamset changes or when the descriptions of at least one of the machines change (for example because of a reconfiguration or the CU connects to another machine). This way the agrirouter participants know about the machines themselves, and about which machine is connected to which communication unit.

Each CU only sends one teamset, every teamset can only be part of one CU. If multiple CUs are on the same network (e.g. a terminal in the tractor + a telemetry box on the baler), there will be multiple teamsets including the same machines and sending the same data. Apps are then responsible for filtering duplicated data. If there are no machines connected, the teamset of a CU will just be empty.