This is a proposed use case? of accessors.
Scenario
Trucks can save fuel by platooning, where the second and subsequent trucks are drafting behind the first truck.
- Trucks in a local area communicate and ask if there are other trucks headed toward their destination
- Trucks bid on being the lead truck, where they get a payment based on fuel savings. Details TBD
- An order is determined and trucks exchange accessors that are hosted on following truck.
- The accessor communicates between the truck in front and the local truck using whatever communication technology the accessor author would like to use.
Discussion
- The interface of the accessor is well defined in advance
- speed (km/Hr).
- distance that the lead truck thinks that the rear truck is behind (meters)
- etc.
- If a truck changes destination, the the trailing trucks need to decide if they want to go there or not, depending on a fuel and time calculation
- Trucks can drop out at any time
- If a lead truck drops out, a new negotiation must occur
- If a follower truck drops out, then the gap is closed.
The key thing is that a simple interface is defined and it is up to the implementer to define how the trucks communicate with the parking meter.
There might be different protocols and different communication methods (BLE, WiFi etc.)
Security
- Authentication: The accessor downloaded from the truck must be associated with the a known vendor, not some random person
- The accessor downloaded must not have been tampered with (Secure Checksum)
- Running the accessor in a Sandbox is a good idea
See Also
