Re: [openadx] Kuksa for openADx demonstrator

[SOHEILA DEHGHANZADEH <s.dehghanzadeh@xxxxxxxxxxxxx>]

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