Re: The future of agl-service-can-low-level with the new Application Framework

["Scott Murray" <scott.murray@xxxxxxxxxxxx>]

On Tue, 25 Oct 2022, cihan.simsek via lists.automotivelinux.org wrote:

> [Edited Message Follows]
> [Reason: Added hashtags to the original message]
>
> Hi,
>
> Can we use agl-service-can-low-level with the new Application
> Framework? What are the plans for integrating this can low level service
> to new App Framework?

The short answers to these two questions are no, and there are none.
More fully, the reason the application framework was dropped was that
there was no interest from members in contributing to it, as they all
have their own in-house frameworks.  That made it difficult to justify
trying to maintain it just for AGL's own demos.  For CAN specifically,
the low-can and signal-composer bindings are pretty significantly tied
to the leagcy framework, and the low-can binding uses a bunch of code
from OpenXC, which is effectively dead and has no active community that
I am aware of.

So for now our plan is to leverage the KUKSA.val server which implements
the emerging Vehicle Information Service (VIS) standard.  The API it
provides is somewhat along the lines of what the signal-composer binding
did, and includes a simple CAN feeder that can be used to drive signals
based on the definitions in a CAN database (Vector DBC) file.  That is
sufficient for the needs of the AGL demos at present, and it is something
that is maintained by a wider community outside of AGL.  It seems likely
that KUKSA.val (or a similar VIS server implementation) is going to end
up in production vehicles, but it is the case that their CAN feeder is
clearly not intended for that.  However, during recent discussions with
members, it has been made clear that they don't see the need for
development of anything in this CAN interfacing area, so it will be what
we use in the upstream demos for at least CES 2023, and likely for the
foreseeable future.

I did a presentation titled "Using CAN services with AGL" at the AGL
workshop in Tokyo last week that covers the above in more detail.
The slides for it are at:

https://wiki.automotivelinux.org/_media/agl-distro/using_can_services_with_agl_-_scottm_-_20221020.pdf

and I believe the video recording will be made available (keep an eye on
the mailing list).

> It would be also much appreciated if you can point to some
> architectural documents on new Application Framework.

At the current time, we've not really developed a new "framework", and to
be honest, I do not expect upstream AGL to ever do so along the lines of
the legacy framework.  The focus now is to do more constrained technology
demonstrator type of development.  Currently, what's done is an API plus
sevice daemon for starting graphical applications, applaunchd, which you
can consider somewhat along the lines of the previous af-main binding.
It is serving as a showcase of defining and implementing an API with gRPC,
and leveraging systemd for sandboxing applications.  There will be some
more demonstration gRPC based APIs coming because there are some demo
features that are outside of the scope of what we can do via VIS /
KUKSA.val (e.g. things like audio mixer controls, radio, Bluetooth
config), but realistically there are not a lot of resources to do new
development, and doing things in a more modular fashion seems more likely
to result in components that a member company might decide they want to
use.

All that said, I am on the hook to write up some documentation for
applaunchd, I will try to get to that soon.  In the meantime, I did a
presentation at last week's workshop titled "Creating AGL Services" that
covers a bunch of the above and discusses using gRPC in more detail.
The slides for it are at:

https://wiki.automotivelinux.org/_media/agl-distro/creating_services_for_agl_-_scottm_-_20221020.pdf

and as mentioned above, there should be video made available at some
point.  Note that I presented "Creating Services for AGL" first, so if
you're going to look at the presentations, I would suggest looking at it
first, as things probably flow a bit better that way.

Scott



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10237): https://lists.automotivelinux.org/g/agl-dev-community/message/10237
Mute This Topic: https://lists.automotivelinux.org/mt/94557034/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/2167316/883735764/xyzzy [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-