July 2025 - Last year, we spoke to Manuel Gorius (MG) about his involvement with oneM2M and his business activities at the intersection of agriculture, IT, and IoT sectors. In this interview, he discusses what factors are currently influencing technology investment in the agriculture sector. He also talks about new IoT projects his organization, digisaar, is working on.
Q: Would you begin with by introducing yourself and your activities in the IoT arena?
MG: I have a background in computer science and am a co-founder of digisaar, which provides software engineering services in Germany. Before I got involved in starting digisaar, I spent roughly half of my career in academia followed by industry. During my early studies at Saarland University in Saarbrucken, Germany, I pursued a Masters degree with an emphasis on telecommunications. That set me on the path to a career in academia where I worked in a telecoms lab focusing on research into error-correcting schemes and time-sensitive transmission protocols in wireless and mobile communications systems.
I come from a farming family, so my next move was to John Deere’s European Technology and Innovation Center where I worked as an embedded software engineer focusing on interoperability projects for agricultural equipment.
At digisaar, we are always watching out for opportunities to sustainably support industry. We also target public sector and Federal agency services with digital solutions. As we are a small business, our mix of work varies because we have to adapt to variations in market demands and in what customers want. Right now, for example, one of our projects involves working with tax authorities, which differs much from our initial engagement in the agriculture domain.
Q: How would you characterise technology adoption in the agriculture sector right now?
MG: From my perspective in Germany, we are experiencing a post-pandemic effect. COVID put a strain on supply chains so pricing for equipment went up and that has an impact on farmers’ costs. Under current market conditions, it is difficult to increase farm revenues. I have heard from local farmers who would normally be replacing three-to-five-year-old equipment. Now, it seems that many plan to run their machinery for perhaps a year or two longer.
Q: Instead of large CapEx investments, are farmers spending on lower outlay data systems?
MG: There is probably some retrofitting going on since everyone is focused on efficiency. I think our small-scale region in south-west Germany is early in the process of using data more intensively.
To some extent, there is a generational effect because farmers of my parents’ generation tend to look at their crop yields and fertilizer use on an annual basis. Also, if the fuel gauge is reading low, they would simply top up the fuel tank. They would not necessarily compare fuel consumption to the type or location of activity. That way of working will change as farm operators now look at fuel consumption per hectare under different planting conditions, for example. They will also be able to do a lot more because there are telematics systems provided by the equipment manufacturers, which collect and present operational data via flexible and interactive graphical interfaces.
Q: What do you think will speed up the use of machine data?
MG: Collecting and making it easier to access different kinds of farm data is a first step, as I showed you via a few examples in the Farm Management Information System that I use. After that, interoperability is important to make it easier to consolidate data from many different sources and data protocols that each vendor uses. We see this happening in the agriculture sector. That is one reason why the Agricultural Industry Electronics Foundation has set interoperability as a goal via its Agricultural Interoperability Network (AgIN) initiative.
In general interoperability is difficult to implement, whether we are discussing the agriculture sector or other industries. Many potential users seem to be worried about complexity. Data transmission is still mostly thought of in terms of a header, with source and destination information, and a payload, whose content type would then be looked up in a data dictionary. In addition, it is easy to overlook the fact that the Internet Protocol provides a unified channel for a huge variety of transmission protocols and applications. There is nothing wrong with the coexistence of such traffic in a specific solution that has been developed and optimized to handle data with specific qualities and requirements. However, we see value in more general and repeatable use cases.
For us, the oneM2M architecture provides handy solutions for placing a simple and unified interface on top of a diverse communications stack containing the optimum state-of-the-art solution for each variety of data. Our long-term vision is the implementation of semantic interoperability with a unified stack to an upper (semantic) layer that provides a common interface to the outside world. With that approach, it is possible to select the optimal (lower level) protocol for each application and to have multiple protocols coexisting below the semantic layer. It does not matter if I have ten or fifty lower layer protocols. I gain a lot of flexibility as long as there is a common interface to the outside world.
Figure 1: Common Service Layer Enables Flexibility to Mix-and-Match Lower Layer Protocols
Q: What more can you tell us about your work related to interoperability?
MG: I can explain this in relation to the FieldDataSync project which is about developing a manufacturer-independent wireless communication solution for agricultural machinery without internet connections. It is one of our current funded projects, with funding provided by the Federal Ministry of Food and Agriculture.
The project scope deals with multiple use cases for cooperative machine operations with real-time process data exchange. This includes the sharing of process data as well as coverage data of completed work, path planning algorithms, remote control operations between vehicles, and vehicle-to-vehicle video transmission. We are mostly assigned to the latter work package and committed to the development of a solution for seamless communication of cameras and displays distributed across a fleet of machines assigned to a common -farming operation.
In its simplest form, the project involves two camera-equipped vehicles, such as tractor and a combine harvester. Our aim is to enable remote access to different vehicles and their camera feeds. Since these can be vehicles from different manufacturers, there is also an aspect related to service discovery as a first step before data sharing.
Our part in the project is to evaluate which benefits oneM2M can provide on top of basic communication features discussed by the project consortium. We strongly envision a solution based on open standards and well-established communication protocols for wireless video transmission.
Figure 2: Open-standard Architecture for Vehicle-to-Vehicle Video Transmission
I will give you a practical example of how that system might be extended beyond vehicles and devices in the agriculture domain. In Germany, farmers are required by law to mow fields carefully, after checking that there is no large wildlife, like a deer cub, hidden in tall grass. With the kind of system we are trialing, a farmer could fly a drone and analyze heat emissions data to detect a hidden animal. This reduces their dependence on external support such as hunters who offer to inspect the grassland via a drone equipped with an infrared camera. The system in this case synchronizes the mowing machine’s location and video console to drone data; this is how standardized service discovery and interoperability are applicable.
Q: How are you working with oneM2M in your IoT or data sharing projects?
MG: We base our oneM2M work on the ACME CSE which is available as an open-source project. We have not touched the code base although we have built on top of the ‘resource’ and ‘flex-container’ primitives (to connect to the CSE); these were published a few years ago. The aim is to include semantic descriptors and ontologies as we build towards a full-stack IoT system. We hope to make those publicly available once we are confident that they are sufficiently mature.
Another area where we are working with oneM2M in digisaar involves students who are starting work on their thesis projects. One of them will work on tooling to create semantic descriptors to express (connected device) properties in RDF (resource description framework) notation. The base oneM2M documentation we will build off is the (technical specification) TS-0012. We want to help system engineers to use oneM2M without having to understand the complete suite of standards. It is a bit like a PLC engineer wo builds an application via a GUI interface by manipulating function blocks and connectors. I hope we can share more about the project once it is done.
Q: Are there any other observations you wish to add in relation to your work?
MG: While we have covered a lot of industry and technical issues, I was hoping to add more from our last discussion. This is an observation about the pace of change (in operational settings) which is affected by the need to convince people about new technologies and capabilities.
On the positive side, we are seeing funding for projects to explore new areas. That gives us a certain degree of freedom to evaluate new ideas, as long as we remain synchronized with our project partners. For example, we can have a team agreement that the communications stack fulfills some common function; then, our project contribution is to add a semantics layer on top of that to demonstrate the potential and value-creation opportunities.
Long term, if we can combine a common service layer with machine readable semantics, this provides a solid foundation for AI. Just look at how developers are using ChatGPT to build software applications via an API. We are thinking about the same concept applied to IoT applications, sensors, and connected devices.
