Dear Robert,
Thanks for your comment. I am not sure if you are also a member of openADx mailing list But I have sent this email to the openADx mailing list.
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?
Do you think this extensions are possible in kuksa?
Best regards
Soheila
From: Robert Höttger <robert.hoettger@xxxxxxxxxxxxxx>
To: Kuksa developer discussions <kuksa-dev@xxxxxxxxxxx>
Date: 27.02.2020 11:59
Subject: Re: [kuksa-dev] kuksa.ide
Sent by: kuksa-dev-bounces@xxxxxxxxxxx
Dear Soheila,
you are correct.
The current kuksa.ide extensions are tested with docker images, which are used by the Kuksa
App-publisher on the kuksa.ide side to be transmitted to the Kuksa cloud that runs Eclipse hawkBit and the Kuksa App Store (among others).
The
Appmanager on the in-vehicle side then handles installation / update commands from Eclipse hawkBit.
The
process of creating docker images and what they contain is currently very simple - but you should be pretty flexible with docker to create custom images / processes.
Best regards,
Robert
On Feb 27, 2020, at 11:29, SOHEILA DEHGHANZADEH <s.dehghanzadeh@xxxxxxxxxxxxx> wrote:
Dear All,
How does kuksa.ide connects with kuksa.cloud and kuksa.invehicle? My understanding is that the app server is the connection point. That means the app written in kuksa.ide goes to the app server after being built successfully. is my understanding correct?
Does the app written in kuksa.ide goes through ci/cd? Can I attach the deployment code of the app to the app so that I can program how the application is being deployed ?
I appreciate any comments on this.
Best regards
Soheila
_______________________________________________
kuksa-dev mailing list
kuksa-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/kuksa-dev
_______________________________________________
kuksa-dev mailing list
kuksa-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/kuksa-dev
_______________________________________________
kuksa-dev mailing list
kuksa-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/kuksa-dev
