OK, now I had this really “great” idea of writing a blog post once a month in 2021. So, let’s stumble into this and see where we go.
I started by writing about message queues. Really interesting to see how data flows from one terminal to a cloud over an interface… OK, do I need to describe an interface? Well, that’s so off topic, might be an additional blog post? 🤔
OK, let’s start with an article on UIs. Many things to discuss about User Inter….. D’oh 🤦♂️
So, I think I’ll just start with the basics:
A simple view to the world
From an IT guys perspective, the world is just about 2 things: Objects and Interfaces. Objects have Inputs and Outputs, Interfaces describe the match between two Objects’ in- and outputs to transfer information (in general: force, material or data). Too nerdy? Indeed, let’s ag-lify* that.
(*ag-lify: Put something in the context of agriculture 😉)
Objects in ag
The best way to describe an object that I found is definitely this one:
Take information (worm protein), convert information ( …. no details here …), output information ( other form of protein).
For conversion, we can just say:
“A few inputs + some logic = A few outputs”
So, in general an object has inputs, some logic inside, which can be mathematical formulars or Conditional statements (“Output 1 = Input1 if Input 3 = 5, otherwise (else) Output1 = Input2”) and one or multiple outputs.
Let the blue box be an object and the orange dots be inputs (with the one inside the object being some fixed value/attribute without any influence from outside), then this “Mozart’s hair” (actually my first shot to draw a brain 😀 ) is the conversion and the green dots are outputs.
Need another example of an object? Here we go: Tractor
The tractor has many In- and Outputs: The PTO outputs power to an attached machine. The ISOBUS breakaway outputs AND inputs ISOBUS information. For the power output, you need to input fuel into the tractor. Not to forget: The wheels output force to the ground and move it under the tractor (as long as you’re not just digging that thing deeper into the mud ).
On a field, our tractor is a bit lonely, so let’s give him a friend, e.g. a sprayer.
Now they are standing here, our tractor starts to move and …. D’Oh, the sprayer stays where it is? Yep, because without a compatible coupling, the tractor cannot transfer the information (“move on, dude”) to the sprayer.
Let’s call this coupling an interface. It’s just the connection between two objects, where the output of one object (“Move on dude”) is the input for the other object (“Should I stay or should I go now?”).
In a real world, this “Stand by me” interface is just the ball hitch. It is one of multiple interfaces though that connect machine and implement.
We have the ball hitch, maybe a PTO, hydraulic cycles and electronic connections such as ISOBUS.
But is it just ISOBUS? THE ISOBUS? The one and only that we’ve heard of so much?
Onions, oh bloody layered onions
Well, I would say, it’s a Yeah….nope 😐
Of course, ISOBUS is standardized, so you can connect multiple ISOBUS devices to one ISOBUS without burning down your tractor. But ISOBUS – as most interfaces – has different layers (sidenote: The following is simplified; if you’re interested in a full list, see the OSI Model ):
- Physical: This one describes e.g. that an INCAB connector is round and has 3 by 3 pins
- Data Link layer: That one describes, how on-off-on-off is translated into bits and bytes
- PresentationLayer: That one describes, how bits and bytes are to be interpreted
- Application Layer: What to do with those data?
In ISOBUS, there are different Applications like TaskController (TC) and Universal Terminal (UT). Each of them needs a client (on machine side) and a server (on terminal side).
Connecting a machine that only provides TC with a Terminal only supporting UT is somehow like Opening a Website with your Email program. It just doesn’t work.
To check compatibility, the AEF Database is a good place to go.
Zoom, zoom, zoom, zoom….
Let’s now go a bit closer to our tractor. If we take a closer look, it’s not just a Tractor. It’s indeed a combination of different objects: It consists of wheels, an engine, a steering wheel and sometimes a nice carpet in the drivers cap. If taking all these smaller objects (that might consist of objects which might consist of objects, which might…. you get that) together, we can recognize it as a package in a detailed view. But for a high level view, a tractor is OK as an object. All the interfaces of a tractor are those interfaces, that are not connected to any other object within the tractor.
Somehow like that: 4 Inputs (e.g. Fuel, Oxygen, Steering wheel movement, sensor input), but the inner objects convert the input information to different 3 outputs (driving speed, rotating pto, ISOXML machine Data).
(let me know if you need an example of what I meant here)
May I introduce: Process chains
But wait: If we have interfaces between 2 objects and we can convert data of one input to another output, we can build a chain. 😲
Yes, that’s correct 😊 *
(*: Imagine this like a conversation. Since I’m in home office for a while, I can just say “I’m pretty sure, that’s how conversations with other people work”)
So, let’s do this: Lets add a terminal, a modem, a cloud and a laptop and here we go: Ag-IT in a nutshell:
We translate a physical environment status (e.g. a temperature) to a sensor signal to an ISOBUS information to an ISOXML or EFDI entry, package it in some modem signal that’s converted to a Cloud API where our data just hangs around for a while until some guy (or woman) with a laptop decides, it requests some information. Stopping the chain at the user interfaces (next blog post 😉 ), that’s a – very simplified – overview of digital farming already.
Onions, oh lovely layered onions
Agreed, this layer stuff in interfaces makes the description a bit more complicated, but it has a huge advantage: Sometimes, 2 incompatible interfaces are just incompatible in certain layers, so you just have to convert these layers. Need an example?
Imagine you’re in the fields with your laptop and want to google something:
- Your laptop only supports WiFi
- The transmission tower only supports 4G
- Your Smartphone supports both and can translate between those
The upper layers (HTTPS, IP etc.) are the same, but by adding your smartphone to the system, you can setup a hotspot to “convert” from WiFi to 4G.
Asking better questions
First things first: You made it through the article. Congratulations and thank you for taking the time. If you read this, I owe you a beer. (99 bottles of beer on the wall, 99 bottles of beeeeer….) Just hit me up on LinkedIn, Xing or via mail to blog@dev4Agriculture.de.
Now, what’s the essence of all of this. Why did I even write it? Because interoperability is about compatible interfaces, interfaces with different layers and information of different types. With the implementation of IoT on farms, there are more zoom levels: Intra-Machine, Intra-Field, Intra-Process Chain, Intra-Farm, Intra-Farming Community (e.g. contractors).
IoT offers big chances but has also a potential for big confusion.
I recently talked to someone working for a college with focus on farming technology. And I really liked his answer to the question “What’s the most important thing to teach about ag IT?”:
“The best would be if people learn to ask better questions”
So, with a view to all I’ve written above, we might come up with those questions:
- Which information do I want to transfer?
- What’s the source of my information?
- What’s the destination of (the need for) my information?
- Where do I have a mismatch in my interfaces? Is there a special layer to respect?
- Which object could be fit inbetween to convert between these incompatible interfaces?
Sure, it’s not the solution for all our problems (sorry about that 🙁), but I think it’s an interesting view worth sharing and I’ld really love any feedback.
I’m yet missing a good closing for my blog articles, some inspirational catch phrase.
Let’s try that one:
Thanks for reading, I really put my heard and soil into this…
OK, agreed, I’ll find a better one next time. Thanks for reading.
It’s November 20th, 6pm on a friday, a perfect time to start a weekend project: The farmhack 2020. I’ve teamed up with Manuel Blechschmidt and Julian Schroeter but it was clear from the beginning that we were open and looking for additional team members. We had already started to think about possible topics like 2 weeks before while talking about possible collaborations like the ISOXML Service . After iterating through several ideas, we came up with the following rough idea: “Find good spots to open a popup restaurant during corona”. Honestly, Manuel and Julian did the major research part and advised to use mapbox with deck.gl for visualisation and tensorflow for the optimization part, an awesome good combination, which is fun to play with (as Julian has done afterwards).
In the initial call session, Alexander Eistrup, Florian Tröber, Jamina Zaugg and Fabian Helmke join our team and we start building what will be called “PopupPlaces – Orte finden, Kunden binden”. With a team of 7 and a time of less than 1 day, we decide to split into a business team and a development team. Manuel leads the development team, Julian, Florian and I are jumpers, we switch team every now and than to keep both teams in sync.
The development environment
My developers experience
We accept Manuels idea to develop in mob programmings sessions, so each team member gets 15 minutes of “driver time” to work on the code while the others are advisors or issue researchers (and sometimes also living ducks for rubber duck debugging 😀 ). It’s my first mob programming session and I have to admit, that it’s definitely an effective and especially collaborative way of development. For testing mob programming, it turns to be an advantage that I did not research the technology stack as much as Manuel and Julian, this way I can experience the role of “the one person to ask dump questions”. Not my favorite role though, but for the test quite useful. Sometimes I experience a moment of “wait, what did he do there?” or “where did he find that solution?” but that’s not really an issue. I can just ask for the source of the solution and if I didn’t get what they did there after – at a maximum – 45 minutes, I can just check back when it’s my turn. The same happens, when I switched to the business team for a while and try to get back into the code when returning to the development team. Most understanding issues are solved quite fast and we make a good progress.
Remote mob programming however requires some discipline. While in a normal mob programming session, only one person has the physical keyboard on his hands, in a Visual Studio Live share session everyone can potentially add code at any time. So, after a while the drivers sometimes wonder, why our page looks different from what they expected, just because “someone” (… sorry! 😉 ) had an idea that “could not wait”. This access issue can be handled in the Tool (Read/Write-Access), but for a hackathon it’s a funny experience.
The business team checks the initial idea and first comes up with a pivot for the after-corona-phase (yes, we are positive people and there’s still some hope 😀 ): While our first customers are restaurants to setup improvised popup restaurants, food trucks are an evolving business concept that is a perfect fit for our technology. We create a rough setup of a business model, a pitchdeck as well as a rough business website.
The pitch and a woohoo
It’s after 6 pm on monday, November 23rd, the results are presented, finally time for our pitch (anyone beating my high score in saying “genau”?). It turn’s out, that “genau” is not our only high score: We win the farmhack2020… woohooo.
At this point, it’s time for a big thank you to Manuel, Julian, Alexander, Jamina, Florian and Fabian. Great team and a good job, I had a lot of fun this weekend 🙂 .
Let’s sum it up
- Farmhack is definitly worth it. Not only is it a hackathon – a thing I would advice anyone, unimportant if you’re a coder – but I especially like the focus an food and agriculture.
- Mob programming rocks! You’re not lost in code, you work with other people and the mess of bug research is solved way faster if multiple people look for solutions
- Live share programming rocks but needs discipline.
- DeckGL, MapBox deliver great user experience with maps
- Tensorflow might be worth a deeper look. The start is not too hard, but actually it’s a bit complex for just-a-day projects to get really useful results out of it
- Teams win! Maybe, one coder had built his solution faster. Maybe a BWL geek (do those exist?) would have created the perfect business model. But only the combination of our teams lead to this success.
“Never change a winning team” is a good advice here, so Manuel, Julian and I will try to collaborate in the future, e.g. by developing the ISOXML Service or extending the project of PopUpPlaces (give a request and a proper funding for that one). If you’re looking for a team to build a prototype within a week, feel free to contact me.
Thanks for reading, feedback for this very first blog post ever is very welcome.