We are holding a face to face CAN and vehicle signaling workshop from September 5 - 7 in Vannes, France.
DATE: September 5 - 7, 2017
Time: 9:00 am - 6:00 pm
VENUE:
IoT.bzh offices
IoT.bzh can be found here
can be found here
VIPE - Le Prisme
1, place Albert Einstein
56000 Vannes
FRANCE
Here is a list of hotels in Vannes. We will work with IoT.bzh to organize the hotel situation.
Vannes can be reached by several methods
Via Nantes: The closest airport to Vannes is in Nantes, France. Once arriving in Nantes it is about 1 hour to drive to Vannes. Driving from Nantes Airport to Vannes is simple, the Airport is on the right (west) side of the city.
Via Paris: The fastest way from Paris is to take a direct train from Monparnasse to Vannes ~3h. Trains are also available to Vannes from Charles De Gaulle Airport. Expect about 4.5 - 5 hours depending on connections.
Video Conference
Times in CEST (UTC)
CAN F2F meeting summary - Vannes - September 2017
We all agree on separation of the transport layer from low-level CAN binding and to load it as a plugin depending on the need of the binding.
Doing that, one can reuse the base of low-level binding and just plug a custom transport layer to be able to communicate with different protocols and devices, like LIN, OEM specific hardware, GPS, …
Transport layer should be a library loaded dynamically at binder startup. API between binding and plugin is defined based on work on CAN binding and enriched with a new proprietary transport plugin defined by Yuichi Kusakabe and Romain Forlot. Also, MRAA could be a great idea to be integrated and should be done by Brendan as he is the lead on that topic.
So far, a transport plugin only needs to implement simple functions: 'open'/'close'/'read'/'write'. Configuration has to made by sending a header message with or without can_data, just like a BCM CAN socket is configured (see [1][2]).
Second, we need a “high” level binding that should understand signals coming from different sources. As we separate transport from binding, this is natural to think that we need to gather and be able to compose higher signals from the raw signals provided by the low level.
This make use of C functions or LUA functions callback/handler to react from subscribed signal. Callback/handler should take care of subscribing part and action to take at signal reception time. This way, we can address different low level binding with different transport layer as well as different binding like GPS. Reactive programming patterns will be probably very useful to write an efficient high level binding: some frameworks like ReactiveX could be used.
Binding configuration file has to provide simple definition of signals and be able to define virtual signals composed from real ones. Virtual signals could be defined at runtime dynamically. Binding provides some basic default callback like : average, minimum, maximum, last, median, etc.
The idea here is to be able to provide a high API that Apps will use to grab their needed signals and more importantly, there isn't ONE high level binding that gathers all signals, but rather several of them which are configured differently with various sets of signals. This is more flexible and should answer most of the needs without having the requirement to define a standard that is complicated since we don't know what to standardize and we will not get help from car makers for that. We reproduce the behavior of low-can binding and applies it to a higher level :)
Development began on Github[3].
On the simulation, test & benchmark side, Kusakabe-san already defined an AGL CAN signals bundle that he uses for his test and simulation [4]. CAN signals have been extracted in XML files and converted into JSON OpenXC format. This could be used with the low-can service (to be checked). Maybe Kusakabe-san could provide candump files scenario if it is already available or we can use CANdevStudio or even write a small piece of code to play some basic scenarios. CANdevStudio is a quick and easy way to do that if it supports can-utils log format. Then we will all have the same base to make our tests and benchmarks.
[1] : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/networking/can.txt [2] : http://www.brownhat.org/docs/socketcan/llcf-api.html [3] : https://github.com/iotbzh/afb-signal-composer [4] : https://rawgit.com/w3c/automotive-bg/master/snapshots/data_spec_snapshot_latest.html