User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
agl-distro:sep2017-can-f2f [2017/07/27 00:30]
kusakabe [Attendees]
agl-distro:sep2017-can-f2f [2017/09/11 08:03] (current)
Line 44: Line 44:
 ** Video Conference ** ** Video Conference **
Line 50: Line 51:
    * Romain Forlot -    * Romain Forlot -
    * Yuichi Kusakabe - Fujitsu TEN    * Yuichi Kusakabe - Fujitsu TEN
 +   * Toni Hoang - Daimler AG
 +   * Marcel Büsing - Daimler AG
 +   * Dominig ar Foll - Intel Open Source
 +   * Francois Dugast - Intel
 ===== Agenda ===== ===== Agenda =====
-TBA+Times in CEST (UTC) 
 +==== 5 Sep ==== 
 +  * 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 
 +==== 6 Sep ==== 
 +  * 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({{:​agl-distro:​20170722_agl-rfc-vda_vehicledataagent_.pdf|}}). low level can service performance measurement result[[http://​​hosted_files/​als2017/​e4/​20170526_AGL-ALS_F10_kusakabe_LF.pdf|AGL ALS]].  
 +==== 7 Sep ==== 
 +  * 09:00 (07:​00): ​ Catch-up call with Kołłątaj,​ Remigiusz (CANdevStudio developer) Depends on Remigiusz availability. 
 +  * All day: Social networking 
 +==== Meeting notes ==== 
 +CAN F2F meeting summary - Vannes - September 2017 
 +=== Transport as a plugin === 
 +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]). 
 +=== High level binding === 
 +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]. 
 +=== Simulation === 
 +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://​​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​plain/​Documentation/​networking/​can.txt 
 +[2] : http://​​docs/​socketcan/​llcf-api.html 
 +[3] : https://​​iotbzh/​afb-signal-composer 
 +[4] : https://​​w3c/​automotive-bg/​master/​snapshots/​data_spec_snapshot_latest.html ​
agl-distro/sep2017-can-f2f.1501115410.txt.gz · Last modified: 2017/07/27 00:30 by kusakabe