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
