February 2024 - In this interview, Manuel Gorius (MG) provides IoT software development insights about the agriculture sector from the point of view of a Small-to-Medium sized Enterprise (SME). He describes patterns of demand in today’s industry and discusses work to imagine what requirements the industry should be building towards over the coming decade.
Q: Would you begin with by introducing yourself to our readers?
MG: I have a computer science background and have spent roughly half of my career in academia followed by industry before I got involved in starting-up digisaar. During my early studies at Saarland University in Saarbruecken, Germany, I pursued a Masters degree with an emphasis on telecommunications which set me on the path to a nearly 7-year career in academia. There, 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.
Q: What kinds of interoperability issues are you referring to in the agriculture sector?
MG: There are lots of different types of machinery in the agriculture sector. At a simple level, you can think of machines that might be hitched to a motorized vehicle, like a planting unit connected to a tractor, for example. Typically, the motorized vehicle has a display and a command interface, so the interoperability challenge is to bring data to this common interface for read-out and control functions. Communications take place over a Controller Area Network (CAN Bus) which is a vehicle bus standard that allows microcontrollers and devices to communicate with each other.
The European market is dominated by systems based on the ISO 11783 standard. The big challenge is to ensure that as many types of agricultural equipment as possible conform to this standard so that farmers can plug-n-play with their assets. The AEF (Agricultural Industry Electronics Foundation), which has a global footprint, is responsible for developing guidelines and conformance tests for ISO 11783 compliance. Some of our work at digisaar involves maintenance of AEF’s conformance test which is a component in ensuring interoperability.
Another kind of interoperability came up in a project I worked on around 2018. This had three partners – John Deere, AEF and ETSI which funded a special task force project (ETSI STF 542). The project focused on cross-domain interoperability between the agriculture and transportation safety domains. An example use case is a tractor moving between two fields and using a public road for a part of its journey. If the tractor is shedding mud because the first field is wet, this could present a hazard for any fast-moving passenger vehicle that might pass by later on. Interoperability involves vehicles sharing data so that a car or coach driver knows when to expect a muddy patch of road that might cause them to slide.
With each vehicle using its domain-specific language there is a major opportunity for semantic interoperability, which opens a pathway to reasoning applications. This becomes possible once developers add semantic capabilities to (connected) device descriptions. I am excited by these possibilities, having spent a part of my earlier career studying the Digital Living Network Alliance’s interoperability standard for multimedia sharing in the home environment. Their activities taught me a lot about the challenges of delivering a workable plug-and-play experience to customers. Although there was no notion of semantics designed into the DLNA standard, it was possible to foresee this emerging as a future requirement.
Q: Let us turn for a moment to digisaar. Would you introduce us to the company and what it does?
MG: digisaar is a company I co-founded with two friends in early 2021. We saw an opportunity to specialize in software engineering, beginning with our connections in the agriculture sector. Our early work built on industry connections we had made over the years. For example, one project involved a collaboration with AEF to maintain their conformance testing system and to support plug-fest events for agricultural equipment.
We are also starting to think about the long-term dynamics of the agriculture sector. What will happen if most or all equipment is built to connect to the Internet? What are the implications for plug-and-play solutions, for service discovery across equipment types and also across vendors? Also, what can we say about the protocol stack if providers want to offer web services on top of interfaces?
Of, course we have a range of customers and types of projects at digisaar. We currently operate across Germany with demand for device software solutions covering areas such as legacy product maintenance, development of middleware and communications stacks for embedded devices and, test automation. In addition to the agriculture sector, we are also involved in industrial automation, PLC programming and opportunities to use IoT middleware capabilities to improve system automation.
Q: What are your interests in the IoT market?
MG: Summarizing what I discussed earlier, we do a lot of software development on embedded devices and connected systems. We are active in standardization and looking at the long-term future, primarily for IoT in the agriculture sector and also for industry automation.
In terms of standardization, we are active with AEF, focusing principally on facilitating communications via a standard or suite of protocols. As we think through the issues, our understanding is evolving to a scenario where we view agricultural machinery and vehicles as IoT nodes, hence the importance of standardized communications.
The agriculture sector is moving towards a future with more automation. There will also be many use cases featuring autonomous operations. These developments will require wireless communications between vehicles and to cloud back-end systems.
There will be an explosion in data volumes which brings us to two other IoT challenges. The first is to avoid ‘meaningless data’ which arises when IoT data is not tagged or semantically parametrized. The second challenge is more of a visionary one because it asks the question, “how soon will data from the agriculture domain be accessed routinely by other industry verticals?” As an example, this might involve a temperature sensor on a farm vehicle which provides local data for a farmer’s needs. It might also be accessed by a neighboring smart city application that wants to gather more granular local temperature data. We need to plan for how that exchange will work.
Q: Is there a current IoT project that you can share with us?
MG: Without going into details about individual customers or projects, it might be best to speak about some of our current proof-of-concept projects, many of which make use of oneM2M technical standards. We see that oneM2M has the potential to enhance communications across several interfaces in agriculture domain applications. These include equipment to tractor, (wireless) machine-to-machine, machine-to-cloud, as well as cloud-to-cloud communications.
One of our findings is that existing concepts in the ISO 11783 family of standards (which deal with mobile communications for tractors and machinery in agriculture and forestry applications) can be mapped directly onto oneM2M concepts. For example, the ISOBUS object pools represent a hierarchy of different, small, basic components. They are used for device discovery and are similar to the Smart Device Template used in oneM2M. This has a direct bearing on our current work which focuses on evaluating potential data models to represent farm equipment which can then be related to system management services offered via oneM2M. We are also exploring options for semantic descriptions leading to an improved validation of services offered by specific equipment and applications consuming these services.
Q: Are you seeing any patterns in digisaar’s customer requirements for IoT systems?
MG: As you can tell from our oneM2M proof-of-concept projects, we are seeing system requirements that can best be served by oneM2M with its middleware architecture, open and extensible standards, and interoperability capabilities. Let me explain with an example. In the agriculture sector as well as in (PLC) industry automation, there is growing demand for instant access to machine data via web applications. Even remote control or remote maintenance use cases are under discussion – as far as safety requirements permit.
Among currently deployed machinery, which are usually proprietary, we see that solutions can benefit from enhancements via standardized interfaces and data models because they provide the foundations for fine grained publishing of specific information via oneM2M’s access control policies. We also use oneM2M’s Smart Device Template to describe each system so that it can be represented as a resource tree (or a simple digital twin). For the exchange of data, we use the publish-subscribe scheme that oneM2M supports.
In many of our current projects across different industry domains we observe limitations that can easily be addressed by the semantics designed into oneM2M. We see opportunities for automated conformance testing of interfaces that are semantically described by ontologies. Given the emerging capability of AI tools, in particular the large language models, a well-documented API with semantic descriptors certainly leverages faster and generative development of applications. We expect the ability to access these APIs will enable a diverse market while lowering barriers for start-up companies and SMEs to get involved.
Q: How did you learn about oneM2M and what tools are you using in your work?
MG: I have had the benefit of several interactions with oneM2M over the years, so I have learned gradually. I mentioned a 2018 project with John Deere, AEF and ETSI. For that, we used the OM2M open-source platform or common services entity in oneM2M terminology. That helped me to get an understanding.
Since then, I have switched to the ACME CSE provided by Andreas Kraft. It provides an easier entry point for developers. The web interface, supporting video tutorials and oneM2M’s Developer Guides are all inputs into my “learning by doing” approach. My typical workflow is to outline a solution, then test it using the ACME CSE web interface and then move to implementation. Andreas provides several Jupyter Notebooks and video talks which have helped me to master the basics and map out the way that resources and resource trees are represented in oneM2M.
Q: In closing, what insights or advice would you offer to developers or end-user businesses seeking to apply IoT concepts to their products or services?
MG: I would say that my views are shaped by the agriculture domain which is a very colorful market because there are so many players among the small and large OEMs. It is a market of interoperability for which standards are essential. To this point, I am a big supporter of open and documented APIs and interfaces.
I would also advise users to take a look at oneM2M. I have become a fan because oneM2M offers a generic and efficient way to describe devices, device functionality and services in a cross-industry manner. I will repeat my point about interoperability across domains, which oneM2M supports, because information is increasingly becoming valuable as providers find ways to share meaningful data across boundaries. I would also add that oneM2M members have done a lot of work to establish solid foundations. The technical specifications support different bindings and developers can access a REST interface straight ‘out-of-the-box.’
