<div dir="ltr">Forwarding to AGL mail list for Magnus. <div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Feuer, Magnus</b> <span dir="ltr"><<a href="mailto:mfeuer1@jaguarlandrover.com">mfeuer1@jaguarlandrover.com</a>></span><br>Date: Tue, Mar 1, 2016 at 1:34 PM<br>Subject: Re: [agl-discussions] Meeting minutes EG Connectivity AMM2016<br>To: Christian Gromm <<a href="mailto:christian.gromm@microchip.com">christian.gromm@microchip.com</a>>, <a href="mailto:genivi-projects@lists.genivi.org">genivi-projects@lists.genivi.org</a><br>Cc: "<a href="mailto:automotive-discussions@lists.linuxfoundation.org">automotive-discussions@lists.linuxfoundation.org</a>" <<a href="mailto:automotive-discussions@lists.linuxfoundation.org">automotive-discussions@lists.linuxfoundation.org</a>><br><br><br><div dir="ltr">Regarding AMB.<div><br></div><div>We at JLR / Genivi have started exploring two projects that may work as an AMB extension or replacement.</div><div><br></div><div><b>1. Vehicle Signal Interface (VSI)</b></div><div>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. </div><div>The current GTK DBUS system seems to top out at 30K signals per second, and it scales poorly as the subscriber base grows. </div><div><br></div><div>AMB can easily be extended with an VSI plugin to feed and consume signals.</div><div><br></div><div><br></div><div><b>2. Standardized Signal Specification</b></div><div>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. </div><div><br></div><div>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.<br></div><div><br></div><div>At the end of the day, we will probably have a few thousand signals specified. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>As per usual, questions, proposals, and criticism would be most welcome.</div><div><br></div><div>Sincerely,</div><div><br></div><div>/Magnus F.</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr" style="font-size:13px"><div>-------------------<br></div><i>Head System Architect - Open Source Projects<br></i><b>Jaguar Land Rover</b><br><br><b>Email</b>: <a href="mailto:mfeuer1@jaguarlandrover.com" style="color:rgb(17,85,204)" target="_blank">mfeuer1@jaguarlandrover.com</a> <br><b>Mobile</b>: <a href="tel:%2B1%20949%20294%207871" value="+19492947871" target="_blank">+1 949 294 7871</a></div><div style="font-size:13px"><br></div><img src="http://www.jaguarlandrover.com/email/jlr.jpg" style="font-size:12.7273px"><br style="font-size:12.7273px"><br style="font-size:12.7273px"><div style="font-size:12.7273px">Jaguar Land Rover North America, LLC<br></div><div style="font-size:12.7273px">1419 NW 14th Ave, Portland, OR 97209<br>-------------------<br><font size="1">Business Details:<br>Jaguar Land Rover Limited<br>Registered Office: Abbey Road, Whitley, Coventry CV3 4LF </font><div><font size="1">Registered in England No: 1672070</font></div><br><font size="1">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.<br><br>This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.</font></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Mar 1, 2016 at 7:58 AM, Christian Gromm <span dir="ltr"><<a href="mailto:christian.gromm@microchip.com" target="_blank">christian.gromm@microchip.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Hi,<br>
<br>
here are the minutes of the Connectivity-EG meeting from last week:<br>
<br>
<br>
Attendees:<br>
- Fulup Ar Foll (IoT.bzh)<br>
- Nobuyuki Uchida (Qualcomm)<br>
- Risto Avila (Qt)<br>
- Keisuke Nakano (NTT DATA)<br>
- Hiroto Imamura (NTT DATA)<br>
- Walt Miner (Linux Foundation)<br>
- Michael Fabry (Microchip)<br>
- Soya Saito (Microchip)<br>
- Christian Gromm (Microchip)<br>
<br>
A) AMB<br>
Discussion started on how connectivity between Application layer and hardware resources should be established best. Current AMB solution comes at following Pros/Cons:<br>
<br>
Pros:<br>
Common API makes it way easier for different companies to use it and to decouple applications from hardware buses (Michael)<br>
E.g.the AMB plugins written by Yury Asheshov (Microchip) were easily used by JLR's HVAC application (Michael)<br>
+1 for AMB (Risto)<br>
<br>
Cons:<br>
AMB most likely is not going to be accepted in mainstream (Fulup)<br>
AMB seems over-engineered (Fulup)<br>
Current implemention has issues and need rework especially in terms of security (Risto, Michael)<br>
A bus like CAN, must not be allowed to be accessed by every application (Michael)<br>
Two-level security approach (Cynara, privileged database at application and context level) (Fulup)<br>
Common mistake when designing an API is to define it as a map not as a protocol (Fulup)<br>
Proposal is to use json protocol as common API instead of dbus (Fulup)<br>
However, the parser needed to decode the Json messages might be too much overhead to be implemented in a small micro (Christian)<br>
<br>
Following tasks need to be addressed:<br>
- Let's take what is already there (take stuff from Tizen)<br>
- Take CES demo and put it in an application framework<br>
- Create a common report to find out what is needed to move DEMO applications to a framework (IoT.bzh and MCHP)<br>
- Question is cost of adaption, e.g. writing documentation<br>
<br>
Timeframe:<br>
- Do we need this for next release? (Michael)<br>
- Security is not that important for (Walt)<br>
- Need "sexy" demo for July most likely 90% can be reused (Fulup)<br>
<br>
Misc:<br>
- How big is implementation of security server? How fast is the http server starting up? Boot time is key! (Risto)<br>
- Didn't do any measurement on boot time yet (Fulup)<br>
- Secure boot is needed and this will slow down boot process (Fulup)<br>
<br>
<br>
B) Cloud Connectivity:<br>
Discussion on how this is intended to work (NTT Data)<br>
<br>
<br>
C) SDL (Smart Device Link):<br>
SDL should not be the center of the AGL architecture (Fulup)<br>
First applications where designed on windows, then QNX (Copyright by Ford)<br>
<br>
<br>
<br>
Thanks,<br>
Chris<br>
<br>
Microchip Technology Germany II GmbH & Co. KG<br>
<br>
Dipl.-Ing. (FH) Christian Gromm<br>
Principal Software Engineer, Automotive Information Systems<br>
<br>
Emmy-Noether-Straße 14, 76131 Karlsruhe | Germany<br>
Tel: <a href="tel:%2B49%20721%2062537%20466" value="+4972162537466" target="_blank">+49 721 62537 466</a> | Fax: <a href="tel:%2B49%20721%2062537%20119" value="+4972162537119" target="_blank">+49 721 62537 119</a><br>
<br>
<a href="mailto:christian.gromm@microchip.com" target="_blank">christian.gromm@microchip.com</a> | <a href="http://www.microchip.com" rel="noreferrer" target="_blank">www.microchip.com</a><br>
<br>
Firmensitz: Ismaning<br>
Registergericht: Amtsgericht München HRA 98692<br>
Haftender Gesellschafter: Microchip Technology Germany GmbH, Gilching<br>
Geschäftsführer: Mohammed Nawaz Sharif, James Eric Bjornholt, Ulrich Hallerberg<br>
_______________________________________________<br>
automotive-discussions mailing list<br>
<a href="mailto:automotive-discussions@lists.linuxfoundation.org" target="_blank">automotive-discussions@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions</a><br>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
genivi-projects mailing list<br>
<a href="mailto:genivi-projects@lists.genivi.org">genivi-projects@lists.genivi.org</a><br>
<a href="https://lists.genivi.org/mailman/listinfo/genivi-projects" rel="noreferrer" target="_blank">https://lists.genivi.org/mailman/listinfo/genivi-projects</a><br>
<br></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136)">Walt Miner</span><div style="color:rgb(136,136,136)">Engineering Project Manager</div><div style="color:rgb(136,136,136)">The Linux Foundation<br></div><div style="color:rgb(136,136,136)">mobile: <a value="+14086234789" style="color:rgb(17,85,204)">+1.847.502.7087</a></div><div style="color:rgb(136,136,136)">skype: vstarwalt</div><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)">Visit us at:</div><div style="color:rgb(136,136,136)"><a href="http://automotive.linuxfoundation.org" target="_blank">automotive.linuxfoundation.org</a><br></div><div style="color:rgb(136,136,136)"><a href="http://www.linuxfoundation.org" target="_blank">www.linuxfoundation.org</a></div><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)"><br></div></div></div>
</div></div>