Ingo,

I confess that I don't have first-hand experience with this scenario.  But I would expect that the operator of the harvester and one or more truck drivers have an established relationship.  I would expect that the harvester operator contracts with one or more truck drivers prior to going into a field and harvesting.  For this reason, I don't foresee the need for a truck driver far from a harvester to be randomly searching for harvester clients.

Because of my lack of familiarity with this business, I may well have the wrong business model in mind.  But as I see it, I am not sure that this problem is all that complicated.

A more interesting problem with the harvester would be data collection and ownership as the harvester moves through a field.  I believe that currently, any data that is collected is owned by the manufacturer (as part of the sales agreement of the harvester).  The manufacturer may then sell subscriptions to the data (in aggregated form?).  For the harvester owner (or the farm owner) to access the data, he needs to subscribe.

Another issue with harvesters is that many of them now operate using GPS to ensure that they don't steer off-course and create an inefficient path bank and forth.  Some service must provide the optimization routine to the harvester to guide it through the fields.  So the harvester needs to locate this service in order to use it.  But, again, as long as he can access a hotspot, he can go to the appropriate web site of the navigation service provider, program his location, and turn over the navigation to the service provider's signal.

Jeff


On Tue, Dec 17, 2013 at 11:20 AM, <Ingo.Friese@telekom.de> wrote:

Jeff,

 

Very good approach. It might work when harvester and truck are close. But what when they are fare from each other. Or let’s assume you have a bunch of trucks with wifi in on parking area.

But let’s see what does it mean in general for addressing in IoT (for our Concept paper)

 

-          You can search for your communication partner manually (you go around and look for SSIDs)

-           

Other ways would be.

-          You exchange protocol and IP-address beforehand (truck drivers could talk to each other and exchange IP-Addresses)…not very attractive but a  theoretical option

-          You use systems that provide already an addressing scheme like the telephony system (you could give Harvester and Truck a phone number)

-          You build a common application- or use-case specific namespace (harvester and truck have to register every morning at the same server)

-          To be discussed…..

 

Something like that I want to describe in our paper (derived from the use-cases).

 

 

From: j stollman [mailto:stollman.j@gmail.com]
Sent: Dienstag, 17. Dezember 2013 15:51
To: Friese, Ingo
Cc: dg-idot@kantarainitiative.org
Subject: Re: [DG-IDoT] Use case "harvester communicates with truck"

 

Ingo,

 

What if the harvester acted like a wifi hotspot?  Trucks could search for the hotspot with whatever name the harvester user chose to give it, in the same way I connect to a standard wifi hotspot at a coffee shop or hotel, or the cable modem in my house..

 

The harvester's computer would also be connected to its built-in hotspot allowing it to communicate with any truck that logs in (with the assistance of the driver who inputs the desired harvester SSID.  The connection might not even need to be secure, since no proprietary information is passing between the two machines.

 

Am I missing something that makes this scenario more complicated?

 

Jeff

 

 

On Mon, Dec 16, 2013 at 6:02 AM, <Ingo.Friese@telekom.de> wrote:

Dear all,

 

I added another use-case for our discussion. I think it not to futuristic and shows “white spots” and open issues in the IDoT discussion.

 

http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=67010899

 

 

best regards Ingo

 

 

Scenario “renting a combine harvester”

Use case “harvester communicates with truck”

Combine harvesters are expensive machines. So renting a harvester or using a harvester service (harvester plus driver) is a preferred choice for many farmers around the world.

A campaign (e.g. harvesting a field) needs different kind of machines. Harvesters doing the work and Trucks transport the crop. Modern combine harvesters are able to communicate to the trucks. When they are nearly full the truck can pass by and take over the current crop and the harvester machine can go on without the need to stop and unload the crop.

 

The use-case in detail

The harvester wants to communicate with the truck and vice versa as well as with other machines. In order to keep the example simple, let’s assume that harvester and truck have 3G/LTE connection and internet access. Telco’s use usually IP-address pools. That’s why harvester and truck get most likely a new IP-address with every login. As a consequence IP-address is no stabile identifier for harvester and truck.
But nevertheless both harvester and truck have a communication interface (discovery) and IP-level routing is available due to the 3G/LTE connection to the internet.

Usually every the harvester manufacturer has solution to communicate between these machines. But when the truck was built by another manufacturer it is not clear what protocol, what kind of ID and what method is used to find the machine.

 

The challenge

Bob is the driver of the harvester. Nearly every morning he is on another field hand has to connect to other machines.

Bob needs an easy and standardized way to say to the truck drivers: “you can find my machine here!”, “You can see it in your radar app (showing all machines nearby), “just google it” or something else.

Then this identifier has to be mapped to the current protocol and IP-address of the machine. Subsequently a message could be send to this machine.

 

-          Is there a standardized identifier?

-          Is there a name service for things (e.g. trucks and harvesters)?

-          How to facilitate authentication?

 


_______________________________________________
DG-IDoT mailing list
DG-IDoT@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-idot



 

--
Jeff Stollman
stollman.j@gmail.com
1 202.683.8699

 

Truth never triumphs — its opponents just die out.

Science advances one funeral at a time.

                                    Max Planck




--
Jeff Stollman
stollman.j@gmail.com
1 202.683.8699

Truth never triumphs — its opponents just die out.
Science advances one funeral at a time.
                                    Max Planck