[agl-discussions] Meeting minutes EG Connectivity AMM2016

Tue Mar 8 17:06:13 UTC 2016

Hi Magnus,

I have a question regarding VSI: why is it necessary to re-invent a new
library for message passing ?

I understand that the limitations of DBUS should be avoided, but some
projects like nanomsg (http://nanomsg.org/index.html) are already
available and probably meet all the requirements.

Second point: you mean that the system should handle more than 30K
signals per second. Can you give us some examples of high frequency
signals that make DBUS unusable ? At some point, filtering or smart
routing could be considered to lower the bus traffic and keep only
significant signals routed to appropriate daemons but I need some real
examples to fully understand.

Thanks !
---
Stephane Desneux - CTO
stephane.desneux at iot.bzh - www.iot.bzh

On 01/03/2016 20:34, Feuer, Magnus wrote:
> Regarding AMB.
> 
> We at JLR / Genivi have started exploring two projects that may work as
> an AMB extension or replacement.
> 
> *1. Vehicle Signal Interface (VSI)*
> A DBUS Signal (only) replacement C-library using shared memory to push
> (currently) 10 million+ signals per second. The reason for this is that
> we have a need for a vastly expanded number of vehicle signals to be
> made available to on- and off board components. 
> The current GTK DBUS system seems to top out at 30K signals per second,
> and it scales poorly as the subscriber base grows. 
> 
> AMB can easily be extended with an VSI plugin to feed and consume signals.
> 
> 
> *2. Standardized Signal Specification*
> In order to manage the increased signal set, we just started to build
> out a tree structure of signals covering everything from engine data to
> UX events. 
> 
> By having components exchanging vehicle data (over AMB, VSI, RVI, etc)
> adhering to this specification, we would get interoperability over a
> wide number of domains, in-vehicle components to backend server WebAPI.
> 
> At the end of the day, we will probably have a few thousand signals
> specified. 
> 
> We will be publishing a first draft of both topics within a couple of
> weeks. Talks are ongoing in GENIVI for the best way to move forward with
> this.
> 
> 
> As per usual, questions, proposals, and criticism would be most welcome.
> 
> Sincerely,
> 
> /Magnus F.
> 
> -------------------
> /Head System Architect - Open Source Projects
> /*Jaguar Land Rover*
> 
> *Email*: mfeuer1 at jaguarlandrover.com <mailto:mfeuer1 at jaguarlandrover.com> 
> *Mobile*: +1 949 294 7871
> 
> 
> 
> Jaguar Land Rover North America, LLC
> 1419 NW 14th Ave, Portland, OR 97209
> -------------------
> Business Details:
> Jaguar Land Rover Limited
> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF 
> Registered in England No: 1672070
> 
> This e-mail and any attachments contain confidential information for a
> specific individual and purpose.  The information is private and
> privileged and intended solely for the use of the individual to whom it
> is addressed.  If you are not the intended recipient, please e-mail us
> immediately.  We apologise for any inconvenience caused but you are
> hereby notified that any disclosure, copying or distribution or the
> taking of any action in reliance on the information contained herein is
> strictly prohibited.
> 
> This e-mail does not constitute an order for goods or services unless
> accompanied by an official purchase order.
> 
> On Tue, Mar 1, 2016 at 7:58 AM, Christian Gromm
> <christian.gromm at microchip.com <mailto:christian.gromm at microchip.com>>
> wrote:
> 
> 
>     Hi,
> 
>     here are the minutes of the Connectivity-EG meeting from last week:
> 
> 
>     Attendees:
>     - Fulup Ar Foll (IoT.bzh)
>     - Nobuyuki Uchida (Qualcomm)
>     - Risto Avila (Qt)
>     - Keisuke Nakano (NTT DATA)
>     - Hiroto Imamura (NTT DATA)
>     - Walt Miner (Linux Foundation)
>     - Michael Fabry (Microchip)
>     - Soya Saito (Microchip)
>     - Christian Gromm (Microchip)
> 
>     A) AMB
>       Discussion started on how connectivity between Application layer
>     and hardware resources should be established best. Current AMB
>     solution comes at following Pros/Cons:
> 
>     Pros:
>       Common API makes it way easier for different companies to use it
>     and to decouple applications from hardware buses (Michael)
>       E.g.the AMB plugins written by Yury Asheshov (Microchip) were
>     easily used by JLR's HVAC application (Michael)
>       +1 for AMB (Risto)
> 
>     Cons:
>       AMB most likely is not going to be accepted in mainstream (Fulup)
>       AMB seems over-engineered (Fulup)
>       Current implemention has issues and  need rework especially in
>     terms of security (Risto, Michael)
>       A bus like CAN, must not be allowed to be accessed by every
>     application (Michael)
>      Two-level security approach (Cynara, privileged database at
>     application and context level) (Fulup)
>      Common mistake when designing an API is to define it as a map not
>     as a protocol (Fulup)
>      Proposal is to use json protocol as common API instead of dbus (Fulup)
>      However, the parser needed to decode the Json messages might be too
>     much overhead to be implemented in a small micro (Christian)
> 
>     Following tasks need to be addressed:
>     - Let's take what is already there (take stuff from Tizen)
>     - Take CES demo and put it in an application framework
>     - Create a common report  to find out what is needed to move DEMO
>     applications to a framework (IoT.bzh and MCHP)
>     - Question is cost of adaption, e.g. writing documentation
> 
>     Timeframe:
>     - Do we need this for next release? (Michael)
>     - Security is not that important for (Walt)
>     - Need "sexy" demo for July most likely 90% can be reused (Fulup)
> 
>     Misc:
>     - How big is implementation of security server? How fast is the http
>     server starting up? Boot time is key! (Risto)
>     - Didn't do any measurement on boot time yet (Fulup)
>     - Secure boot is needed and this will slow down boot process (Fulup)
> 
> 
>     B) Cloud Connectivity:
>       Discussion on how this is intended to work (NTT Data)
> 
> 
>     C) SDL (Smart Device Link):
>       SDL should not be the center of the AGL architecture (Fulup)
>       First applications where designed on windows, then QNX (Copyright
>     by Ford)
> 
> 
> 
>     Thanks,
>     Chris
> 
>     Microchip Technology Germany II GmbH & Co. KG
> 
>     Dipl.-Ing. (FH) Christian Gromm
>     Principal Software Engineer, Automotive Information Systems
> 
>     Emmy-Noether-Straße 14, 76131 Karlsruhe | Germany
>     Tel: +49 721 62537 466 | Fax: +49 721 62537 119
> 
>     christian.gromm at microchip.com <mailto:christian.gromm at microchip.com>
>     | www.microchip.com <http://www.microchip.com>
> 
>     Firmensitz: Ismaning
>     Registergericht: Amtsgericht München HRA 98692
>     Haftender Gesellschafter: Microchip Technology Germany GmbH, Gilching
>     Geschäftsführer: Mohammed Nawaz Sharif, James Eric Bjornholt, Ulrich
>     Hallerberg
>     _______________________________________________
>     automotive-discussions mailing list
>     automotive-discussions at lists.linuxfoundation.org
>     <mailto:automotive-discussions at lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
> 
> 
> 
> 
> _______________________________________________
> genivi-projects mailing list
> genivi-projects at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-projects
> 