Skip to main content

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

Hi all,

 

Sounds good. I would love to speed up kuksa with iceoryx. BTW, we started to combine cyclone and iceoryx, so we can have high-performance inter-process-communication + DDS network communication together

 

 

Mit freundlichen Grüßen / Best regards

Michael Poehnl

Chassis Systems Control, Networked systems engineering design (CC/EYN) (CC-AD/ESW1)
Mobil +49 172 7653309 | Michael.Poehnl@xxxxxxxxxxxx



Von: openadx-bounces@xxxxxxxxxxx <openadx-bounces@xxxxxxxxxxx> Im Auftrag von SOHEILA DEHGHANZADEH
Gesendet: Freitag, 28. Februar 2020 17:33
An: openadx working group <openadx@xxxxxxxxxxx>
Betreff: Re: [openadx] Kuksa for openADx demonstrator

 

Hi  All,

Thanks Andy for your comments and Sven for the intro.

Lets consider an AD function that enables kuksa to stop if it sees an obstacle (the demo in [1]).lets see how kuksa.invehicle, kuksa ide and kuksa.cloud can enable the development of such a function and which links between AD toolchain exists  in kuksa project already.
In terms of architecture definition of this function, as far as I know there is nothing in kuksa IDE -> that's why I proposed to extend kuksa.ide with architecture definition tools such as papyrus or capella.

one the function is developed, it needs to be virtually tested first and here an integration of Kuksa.ide with opensource simulation tools (such as carla) and scenario generation tools (is there an opensource tool for it?) is missing. The outcome of the simulation has to be feedback into the ide (using gitlab or jenkins) to assure that only artifacts can be deployed to kuksa.app strore that have been fully tested and successfully passed all tests.  

once the function is fully tested on virtual environment, the link between kuksa.ide and kuksa.cloud (specifically, kuksa app store) enables the integration which as Robert from Kuksa devlist confirmed is using docker containers (a defacto standard).

In terms of vehicle in the loop and integration testing, kuksa.invehicle can help and as Sven suggested we can  use Kuksa and the underlying Eclipse Hono to transport the test and validation data from the vehicle into the cloud. Here the role of openMDM can be very critical as we have already have the in operation used by OEMs.

in the case of the example in [1], icoryx can be used to speedup the communication between the camera and acceleration, for instance.

This so far suggests some extensions that need to be developed in kuksa.ide, kuksa.cloud and kuksa.invehicle with openADx demonstrator. Any comments on this?

Best regards
Soheila

[1]. https://www.youtube.com/watch?v=lK8z8SSrpuY



From:        "Jeroschewski Sven Erik (IOC/PDL21)" <SvenErik.Jeroschewski@xxxxxxxx>
To:        openadx working group <openadx@xxxxxxxxxxx>
Date:        28.02.2020 15:31
Subject:        Re: [openadx] Kuksa for openADx demonstrator
Sent by:        openadx-bounces@xxxxxxxxxxx





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

_______________________________________________
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