[agl-discussions] Meeting minutes EG Connectivity AMM2016
Feuer, Magnus
mfeuer1 at jaguarlandrover.com
Wed Mar 9 01:12:11 UTC 2016
Hello Stephane,
We did explore a number of different options, both local (posix mq, pipes,
etc) and networked (MQTT, DBUS, Corba, etc).
The problem with all these were they did not scale well for a single
publisher and multiple subscribers.
In the case of nanomsg (which I hadn't seen before, thank you for the
link), it can be seen here:
https://github.com/nanomsg/nanomsg/blob/master/src/protocols/utils/dist.c#L87
Each subscriber gets its own write, which means system call and context
switch. This will not really fly when we have dozens subscribers for a
single signal.
As for why we are doing this: We have JLR-internal requirements that
necessitates a fire hose approach to signals, where any component can get
unlimited signal access without having to worry about performance or
publisher-side filtering. I am sure that JLR is not the only OEM working on
these problems, which is why we are pushing this as an OSS solution.
Two examples of high-frequency signalling are capturing individual x/y
coordinates for a finger drag across the infotainment screen and real-time
sensor reporting. Each source on its own may not generate more than a 100
signals / sec, but they do add up quite fast.
/Magnus F.
-------------------
*Head System Architect - Open Source Projects**Jaguar Land Rover*
*Email*: 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 8, 2016 at 9:06 AM, Stephane Desneux <stephane.desneux at iot.bzh>
wrote:
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20160308/754df224/attachment.html>
More information about the automotive-discussions
mailing list