Automotive Linux Wiki

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

Map Vannes, France

Vannes City Info

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.

• Best Western is the nicest hotel, especially if you get a room facing the Golf Of Morbihan.
• Best Western city centre is a new and nicely situated 10mn walk from city center.
• Kryiad Prestige is equivalent to Best Western city centre.
• Mercure le Port is facing a tunnel construction that should not be finish before summer.
• Park&Suite is walking distance from the office but far from the city.

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

https://appear.in/iotbzh

• Romain Forlot - IoT.bzh
• Yuichi Kusakabe - Fujitsu TEN
• Toni Hoang - Daimler AG
• Marcel Büsing - Daimler AG
• Dominig ar Foll - Intel Open Source
• Francois Dugast - Intel

Times in CEST (UTC)

• 09:00-11:00 (07:00-09:00): Call with Kołłątaj, Remigiusz (CANdevStudio developper) Presentation and how it could be integrated into AGL CAN apps development processus ? testsuite, stresstest, simulation, etc.
• 11:00-12:00 (09:00-10:00): Call with Brendan Le Foll to present MRAA.
• 14:00-16:00 (12:00-02:00): Discussion, tests around result of call with Kołłątaj, Remigiusz and which solution to adopts for CAN test, simulation.
• 16:00-18:00 (12:00-02:00): AGL apps development and debug: XDS presentation

• 09:00-11:00 (07:00-09:00): Controller binding presentation, how it can be used to handle signals from different Low level data agent.
• 11:00-12:00 (09:00-11:00): Beezeelinx presentation
• 14:00- (12:00-): CAN update:
  • Protocols integration CAN_FD, ISO-TP, OBDII extension, …
  • François Dugast (Intel): Integration of a dedicated AGL framework CAN chip
  • Yuichi Kusakabe (Fujitsu-ten): How to provide an unique interface to manage signals from car(20170722_agl-rfc-vda_vehicledataagent_.pdf). low level can service performance measurement resultAGL ALS.

• 09:00 (07:00): Catch-up call with Kołłątaj, Remigiusz (CANdevStudio developer) Depends on Remigiusz availability.
• All day: Social networking

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