|
I would avoid posix entirely.
Just use an os port layer for encapsulate the needed parts like threading and timers.
If by discovery you mean service discovery or automatic address assignment and resolution, this is tricky. Maybe just a static table in phase 1?
Security is also important. Ideally, we could optionally encrypt each logical channel (conversation) since sometimes encryption is required, sometimes it's not. However, it's easier to encrypt the entire physical layer but key exchange is quite complex. This
definitely required thought. We have a security team that could chime in.
Eric.
From: Fulup Ar Foll <fulup.arfoll@xxxxxxx>
Sent: Wednesday, April 10, 2019 10:01:33 PM
To: Shufro, Eric; Sachin Gwasikoti; automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Project Ideas for AGL
The problem is not so much the transport protocol, but more the discovery, the security, Posix dependencies, ....
On 10/04/2019 12:00, Shufro, Eric wrote:
One possibility would be to use Google proto buffers over SLIP. Lots of ideas in this space but free few implementations. I tried experimenting with MIN (oss IPC stack) but it didn't meet the great with respect to robustness; but most of the sauce was available
to look at. I also tried LWIP but this has serious issues with regard to traffic prioritization and overhead, both could, member and packet, but it sure is tempting to use udp and or TCP to enable security and toe in with sockets on the remote host.
Eric,
This is almost exactly the subject of the talk I proposed for ALS this summer (see abstract here after).
Fulup
AGL-µBinder : a fast, secure and seamless option to connect AGL to small ECUs?
In order to embrace the global automotive ecosystem, AGL micro-services architecture should support not only all Linux in a car, but also seamlessly retrieve data from small ECUs and securely
send collected information to the cloud.
Because of existing application framework dependencies, as today, AGL bindings run only on Linux. In order to extend to global automotive ecosystem, AGL’s binders/bindings architecture
needs to be reviewed. On one hand, remove Linux’s systemD dependencies and extend security model. On a second hand, support ‘alien’ transport protocols including non TCP/IP ones.
This talk presents the lesson learned from a POC to run a subset of current AGL binder onto a micro-controller with Zephyr. How to solve binder/binding dependencies, how to map the transport
onto a non TCP/IP link, how to extend AGL security model, ...
On 10/04/2019 01:02, Shufro, Eric wrote:
Does AGL have a standardized API for inter-processor communication?
In some cases, the heavy lifting SOC will need to communicate with a smaller vehicle interface micro-controller that sits on the vehicle CAN bus. This usually
happens over serial; either UART or SPI, ideally physical layer agnostic since some SOCs have integrated low power microcontrollers and communicate via shared memory).
-Eric
From:
automotive-discussions-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx [mailto:automotive-discussions-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx]
On Behalf Of Sachin Gwasikoti
Sent: Saturday, April 6, 2019 11:14 PM
To:
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
Subject: Project Ideas for AGL
Can you suggest few project ideas which you would like to see in agl. I am looking for ideas to work on as a project.
1> Ideas for Application Development (C/C++ & Qt)
2> Ideas for Middleware & Application Development (C/C++ & Qt)
I would love to get input on this. I am really looking forward to work with the org. I am new to this community.
_______________________________________________
automotive-discussions mailing list
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
|
