Achtergrond
In de trekkerdata module kijken we naar het zelf loggen van trekker- en werktuigdata. Belangrijke parameters zoals de hefbelasting, motorbelasting en het brandstofverbruik, maar ook werktuigdata zoals opbrengstdata en “as-applied” data, komen zo beschikbaar.
Het project begon ooit met een een open source datalogger ontwikkeld aan een Amerikaanse universiteit. In de afgelopen twee jaar is geprobeerd om er een robuuste, stabiele en zo simpel mogelijke toepassing van te maken voor de Nederlandse praktijk.
Het was een lange reis, van een plug in device in je trekker naar het bouwen van een volautomatische data pijplijn, inclusief data visualisatie op een platform. Voor de leergang vormt trekkerdata een krachtig en relevant voorbeeld van wat er allemaal bij komt kijken als je zelf met data aan de slag gaat.
Aanleiding
Trekkerfabrikanten investeren flink in hun eigen technologie, en ook steeds meer in het uitwisselbaar maken van data tussen verschillende systemen. Als boer verkrijg je toegang tot trekkerdata via de cloudomgeving van je fabrikant. Wel maakt de fabrikant slechts een deel van de data beschikbaar. En in het uitwisselbaar maken van data stellen ze prioriteiten en zoeken ze naar commerciële kansen.
Dit levert een ongelijkwaardige positie op. Waar voor de fabrikant alle data uit de trekker-werktuig combinatie beschikbaar is, worden andersom verzoeken om data aan fabrikanten vaak nog geweigerd onder het mom van ‘het geheim van de chef’.
Als je autonoom over je machinedata wil kunnen beschikken, ongeacht het merk of type machine, dan kan je er voor kiezen om eigen apparatuur op de trekker te plaatsen. Daarmee wordt het mogelijk om zonder tussenkomst van de fabrikant over alle (ruwe) data te beschikken. Een bijkomend voordeel is dat je op deze manier direct vanaf de trekker alle data op 1 plek bij elkaar kan brengen, zodat je minder last hebt van de wildgroei aan platforms en cloudoplossingen waar je met een kleurrijk machinepark al snel mee te maken hebt.
Bodem
Bij het ontwikkelen van IT wordt het snel veel en complex. Het is heel belangrijk dat je vanaf het begin de toepassing duidelijk in beeld hebt, zodat je weet welke functionaliteit de toepassing echt moet bevatten om de gebruiker te interesseren. Daarom is het uitwisselen van ideeën tussen boeren en technologie aanbieders meteen vanaf de start heel waardevol.
Tijdens de leergang besteedden we aandacht aan een mogelijke interessante toepassing van trekkerdata. Vanuit de technologie partner werd laten zien hoe zij aan de hand van de gemeten snelheid, brandstofverbruik en motorkoppel van de trekker een schatting kunnen maken van de bodemverdichting op een perceel. In bredere zin is met deelnemers aan de leergang gekeken hoe trekkerdata een bruikbare bodemkaart voor boeren op kan leveren.
De vraag die lastig te beantwoorden bleek was wanneer deze kaart echt bruikbaar zou zijn in de parktijk. Wanneer geeft zo’n kaart genoeg informatie om bijvoorbeeld een uitgebreider onderzoek te starten of om anders te handelen op de verdichte stukken? Met welke andere data kan trekkerdata verrijkt worden? Historische weerdata? De eerder uitgevoerde handelingen op het perceel?
Op het FarmHack Forum, waar alle webinars terug te kijken zijn en door de deelnemers op verschillende thema’s gediscussieerd is, werd een werkgroepje samengesteld om deze vragen rondom trekkerdata samen verder op te pakken (lees hier mee).
Zelf trekkerdata loggen: doen of niet?
De vraag waar we mee begonnen was of het zelf loggen, structureren en opslaan van je data loont, of dat je het beter aan de trekkerfabrikanten en machinebouwers kan overlaten. Duidelijk werd dat het zelf aan de slag gaan met trekkerdata een heel karwei is. Want met directe toegang en ruwe data alleen ben je er nog niet. Er is software nodig om bepaalde data uit de trekker op te vragen en de data te vertalen naar begrijpelijke waardes (decodering). Belangrijke uitdagingen bleken een goede structurering van de data, compatibiliteit en het op een efficiënte wijze verwerken van de grote hoeveelheden data.
“Het lijkt een relatief simpele vraag. Maar zodra je erin gaat wordt het heel snel heel veel. We hebben er wel aan gedacht, om het zelf te doen, zonder fabrikanten. Maar dat is veel te complex.” – Leon
Vasthouden aan je eigen trekkerdata strategie wordt ook moeilijker als je ziet hoe snel fabrikanten zelf gaan. Het wordt dan wel erg verleidelijk om daar gewoon in mee te gaan.
Toch is het al een belangrijke en betekenisvolle stap om toegang tot je eigen ruwe data te hebben. Bodemgegevens worden bijvoorbeeld alleen maar belangrijker. Door nu eerst alle data over de bodem goed te verzamelen, inclusief wat je trekker en werktuig daarover zeggen, stelt je in staat om daar met kennis van buiten of later met nieuwe kennis, slimme dingen mee te doen. Los van je fabrikant, met een eigen lokale IT partij of binnen een studieverband, kan je dan werken aan eigen formules en analyses. Het geeft je een stuk autonomie als boer.
“Het belangrijkste is dat de data continu doorstroomt en dat we zo dicht mogelijk bij de ruwe data komen. En niet via de fabrikant, die eerst gaat zitten filteren en selecteren.” – Jacob
Conclusies
De technologieleverancier staat voor tal van keuzes, bijvoorbeeld rond de meettechniek, het bouwen van datakoppelingen en de weergave van de data. Zeker voor een kleine onafhankelijke IT partij is het dan van groot belang dat eindgebruikers input leveren. Alleen dan kan de technologie leverancier tijd en middelen goed besteden. Hoe meer data, des te waardevoller de toepassing wordt. Maar dat maakt het ook complex en duur. Een boer kan het beste beoordelen welke datalagen echt meerwaarde leveren. Op die manier zit er dus echt meerwaarde in de interactie tussen boeren en technologie leveranciers.
In technisch opzicht is de heilige graal voor trekkerdata om relevante data op plaats en tijd opvraagbaar te maken en ook algoritmes op die wijze met onderliggende data te voeden. Maar dat is geen sinecure. Eerste stappen nu waren echter gericht op het verifiëren van de bodemkaart met de werkelijkheid.
Een interessante route die op tafel kwam tijdens de leergang is om de huidige software voor isobus verzameling en de decodering open source beschikbaar te stellen aan leden van een data coöperatie. De coöperatie kan dan zorgen voor een versnelling, door de vertaling voor specifieke onderdelen op te pakken, prioriteiten te stellen en de kosten en baten van decodeerwerk over alle leden te verdelen. Als zo’n coöperatie dan ook nog een strategie ontwikkelt om de gegevens te combineren met meta data, en die inzichten beschikbaar te maken voor de leden (en eventueel te verwaarden naar derden), dan heb je een interessant model te pakken. Maar om dat speelveld te overzien, en de capaciteit te organiseren om alle benodigde stappen te nemen, daar liggen nog wel aantal grote hobbels op de weg.
Meer informatie
- Compilatie Video webinarserie: P.M.
- Kennis, video’s en discussie vind je op het Forum
Recente reacties