|
Eric,
In my opinion reinventing a new IPC
mechanism for AGL as little value. Opening AGL to an 'alien' world
eg: (RTOS, Android, Autosar, ...) should leverage existing APIs
and existing security model. As today ICP are handle by a
combination of application framework and binder/binding
mechanisms. As I said in a previous mail, the difficulty is not so
much to rewrite a new transport, but to export binding to 'alien'
operating system in order to extend AGL micro-services
architecture to the full automotive ecosystem.
Fulup
On 10/04/2019 21:51, Shufro, Eric
wrote:
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.
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
|
