Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [openadx] Kuksa for openADx demonstrator

Hello everyone,

 

picking up on the recent discussion around Eclipse Kuksa on this list, I would like to give a short introduction to Eclipse Kuksa with this mail. 

 

The overall goal of the Kuksa project is to provide an ecosystem for the development, distribution, and execution of applications in connected vehicles. Kuksa has three main building blocks:

1.    IDE: An IDE based on Eclipse Che that one can run as a preconfigured instance in the cloud to enable third-party developers to develop their applications

2.    Cloud: A cloud backend to accept, store and process data coming from the vehicle applications. Besides, the cloud backend has an app store to which developers can upload their application. Through the app store, a car owner can then decide and configure that an app should be deployed to the car.

3.    In-Vehicle Platform: A set of layers that run in the car on top of a Linux system. Within the In-Vehicle platform, one can execute Kuksa apps which are essentially Docker containers. Moreover, the Kuksa In-Vehicle platform provides (standardized) APIs to access data from the vehicle enabling a larger degree of portability of the apps.

 

If you have further questions feel free to contact me or the Kuksa community directly: https://accounts.eclipse.org/mailing-list/kuksa-dev .

There is also the website at https://www.eclipse.org/kuksa/.

 

To this point, AD and the toolchain around AD have not been an aspect of the project. However, as Soheila and Andy already pointed out there is potential to use Kuksa features in the context of OpenADx and a toolchain around AD development. One idea would be to use Kuksa and the underlying Eclipse Hono to transport the test and validation data from the vehicle into the cloud. Another option would be to use Kuksa to automatically deploy apps and functionality that one wants to test.

 

An integration with Iceroyx has not been a topic yet because most of the use cases were not that time-critical so that the current messaging was sufficient.

 

Mit freundlichen Grüßen / Best regards

Sven Erik Jeroschewski
 

(IOC/PDL21)
Bosch.IO GmbH | Ullsteinstr. 
128 | 12109 Berlin | GERMANY | www.bosch.io
Tel. +49(30)726112-416 | Mobile +49(152)24308225 | 
Threema / Threema Work: N6PZHU3Z | SvenErik.Jeroschewski@xxxxxxxx

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. 
Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling 

 

 

Von: <openadx-bounces@xxxxxxxxxxx> im Auftrag von "Riexinger Andreas (CC-AD/PRM-P)" <Andreas.Riexinger@xxxxxxxxxxxx>
Antworten an: openadx working group <openadx@xxxxxxxxxxx>
Datum: Donnerstag, 27. Februar 2020 um 17:23
An: openadx working group <openadx@xxxxxxxxxxx>
Betreff: Re: [openadx] Kuksa for openADx demonstrator

 

Hi Soheila,

 

thank you for your input!

From my point of view, the Kuksa IDE can be a starting point or and/or a demonstrator.

And you are right, we should do a kind of matching to the blueprint.

 

I guess, we should at first figure out, what Kuksa is able to support in a first step, to be honest, I do not know … ;-)

Maybe we can integrate DDS and iceoryx, than we could do that.

 

Our current idea is to bring the Kuksa IDE in a cloud environment, if we can get here an instance, which can we use.

And btw, iceoryx are shared memory mechanisms, which also can be used in tools, but more designed for a SW stack in the vehicle.

 

The standards between the toolchain component is more like a standardization of the interfaces and the data flow / data model. If there will be some standards which will be created from others, then we can implement it.

 

We should really refine the idea, so that we have a kind of a plan, how to do that … ;-)

 

Best,

Andy

 

Mit freundlichen Grüßen / Best regards

Andreas Riexinger

Chassis Systems Control, Product Management Automated Driving (CC-AD/PRM-P)
Robert Bosch GmbH | Postfach 13 55 | 74003 Heilbronn | GERMANY
| www.bosch.com
Tel. +49 7062 911-8264 | Mobil +49 172 7258214 | Fax +49 711 811-5111226 | Threema / Threema Work: 2U9UM5XS | Andreas.Riexinger@xxxxxxxxxxxx


Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung,
Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller



Von: openadx-bounces@xxxxxxxxxxx <openadx-bounces@xxxxxxxxxxx> Im Auftrag von SOHEILA DEHGHANZADEH
Gesendet: Mittwoch, 26. Februar 2020 16:47
An: openadx working group <openadx@xxxxxxxxxxx>
Betreff: Re: [openadx] Kuksa for openADx demonstrator

 

Another possibility is to extend kuksa.ide with architecture definition and simulation tools.





From:        SOHEILA DEHGHANZADEH <s.dehghanzadeh@xxxxxxxxxxxxx>
To:        "openadx working group" <openadx@xxxxxxxxxxx>
Date:        26.02.2020 16:11
Subject:        [openadx] Kuksa for openADx demonstrator
Sent by:        openadx-bounces@xxxxxxxxxxx





Dear All,


Wolform, SvenErik  and I had a discussion yesterday for investigating if kuksa can be used as a demonstrator baseline.

I tried to summarize my understanding and the questions we discussed and I am wondering:

1.        Where in the toolchain we should place Kuksa exactly?
2.        We thought of 2 possibilities of a demonstrator based on Kuksa:1) extending kuksa-invehicle with eclipse cyclone DDS or iceoryx. 2) using Kuksa-invehicle for Testdrive and connectivity based validation.
3.        OpenADx is mainly targeting to work on the links between toolchain components (a toolchain component could be in cloud, in vehicle or both). The existing tools are iceoryx, cloe and cycloneDDS and these tools are mainly for in vehicle communication. Now the question is "are we thinking of having another project for out-vehicle communication?" can kuksa cloud be a candidate here and should come under the umbrella of openADx?
4.        What are the standards for each link between the toolchain components?

I really appreciate any comment or feedback.

Best regards

Soheila
_______________________________________________
openadx mailing list
openadx@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/openadx



Back to the top