Cihan,
As said by Scott, AGL abandons any
ambition in cybersecurity and froze at application framework
AFB-V3. Nevertheless AFB-V3/4 is already used in production. This
not only in automotive, but also in other critical industries as
aeronautic or energy where long term support (10 years ++) is not
an option.
As a result AFB continues to be heavily
maintained/supported. In fact current AFB-V4 supports many new
features that never get integrated within AGL as:
- SeLinux security rules automation
- Flat-Buffer/Json/Binary object representation
- New languages (Python, NodeJS, Lua, RUST) on top of
traditional C/C++
- Light weight containers
- Native integration as RPM plugin for installation via standard DNF
- Secure gate for user authentication and dynamic privilege
mapping
- ....
As reinventing the wheel is boring and useless, IoT.bzh
maintain prebuilt binaries packages for:
- Redpesk (our embedded Linux RHEL/Cent-OS-Automotive derivative)
- Fedora (33, 34, 35)
- Ubuntu (20.04)
- Debian 10
- OpenSuse (15.2, 15.3, 15.4)
We try to support both current and previous LTS of major Linux desktop distributions. On the embedded side (Redpesk) we provide a "Red Hat Enterprise Linux derivatives" https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux_derivatives and mostly follow RHEL and CentOS automotive.
Obviously we continue to ship on github source codes and
documentations:
- https://docs.redpesk.bzh/docs/en/master/getting_started/docs/overview.html
- AFV-V4 core services: https://github.com/redpesk-core
- AFV-V4 shared bindings: https://github.com/redpesk-common
About Yocto:
We have few Yocto layer that we use internally for test. Unfortunately as AGL choose to abandon cybersecurity we do not see a huge value for us to maintain them externally. Would someone from the community step up for this work that we would be more than happy to help.
The future:
Since mid-2022 we see far more demands for cybersecurity than new technical features or performances. In 2023 we expect to focus on cybersecurity especially to automate documentation/test to help people during audit assessment processes.
Fulup
On 26/10/2022 16:41, Scott Murray
wrote:
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 (#10240) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [list-automotive-discussions82@xxxxxxxxxxx]
_._,_._,_
