Seat Adjuster Blueprint

[eriksven]

The seat adjuster blueprint shows the development and deployment of an Eclipse Velocitas vehicle application which changes the position of a seat based on commands received over MQTT.

The blueprint bases on the seat adjuster explaination in the Eclipse Leda documentation and aims to combine the ressource referenced in the guide into a single repository.

The used technologies are

• Eclipse Velocitas
• Eclipse Kuksa
• Eclipse Leda
• Eclipsen Kanto

[eriksven]

As part of the blueprint I propose to move existing code which is referenced in the documentation to the new blueprint. The benefit is to have all pieces that create the blueprint in one place where they can be downloaded and tested together.

This code is

• Seat Adjuster App Example from Eclipse Velocitas Python SDK: https://github.com/eclipse-velocitas/vehicle-app-python-sdk/tree/main/examples/seat-adjuster
• Seat Service from Eclipse Kuksa.services: https://github.com/eclipse/kuksa.val.services/tree/main/seat_service

What do you think and would you be willing to maintain the code under the SDV Blueprint: @SebastianSchildt @doosuu @dennismeister93 @int0x27

[AnotherDaniel]

One thought: seat adjustment is just a very specific instance of a more broad category of use cases where this application stack/blueprint would excel - I'm thinking this is more representative of a wider usage scenario like when using a fully-featured 'companion app'. So how about reflecting that in the blueprint name, calling it something like "Companion App Blueprint"...

[SebastianSchildt]

As a sneak peek, just triggered by "companion app" @AnotherDaniel , I might teaser there will be coming something to KUKSA in a few days, that is basically offering an "Companion" Interface on Android.

This is not the same as is discussed here, but I would assume this might then be extended to also move the seat, i.e. being an alternative/standin for the "seat adjuster application" in the sketch by @eriksven

[SebastianSchildt]

Also, I think generally we have no problem moving seat service over to a blueprint - need to discuss with the guys though. Wrt to maintaining it, well... it currently works, but is not that regularly maintained.... However that is a seperate topic, and moving it around would not affect it either way

At least I do think it has no hard dependencies to other things in the services repo, is it? So moving that - and the related CI - someplace else could work, but @int0x27 knows better

[eriksven]

Also, I think generally we have no problem moving seat service over to a blueprint - need to discuss with the guys though. Wrt to maintaining it, well... it currently works, but is not that regularly maintained.... However that is a seperate topic, and moving it around would not affect it either way

At least I do think it has no hard dependencies to other things in the services repo, is it? So moving that - and the related CI - someplace else could work, but @int0x27 knows better

Sounds good. Let me rephrase my initial question to "would you keep a similar level of maintenance as you currently provide as part of the current project?" Based on your answer this is the case for the Seat Service. One could make an argument too, to use the Eclipse Kuksa Mock Service instead and only provide a configuration for the mock service as part of this blueprint. But I actually like a lot that the current Seat Service has the option to produce CAN signals.

[eriksven]

The Android App looks Interesting. It communicates directly with the Databroker, right? Because, the idea of the Blueprint would be too, to show how one can build an extensive in-vehicle application which may expose its own API to enable such companions app scenarios like the MQTT-interface for the Seat Adjuster example. So for more complex companion scenarios the logic stays in the vehicle.

[SebastianSchildt]

Sounds good. Let me rephrase my initial question to "would you keep a similar level of maintenance as you currently provide as part of the current project?" Based on your answer this is the case for the Seat Service. One could make an argument too, to use the Eclipse Kuksa Mock Service instead and only provide a configuration for the mock service as part of this blueprint. But I actually like a lot that the current Seat Service has the option to produce CAN signals.

Yes. We (@int0x27 :D ) are also looking into bringing seat service to VSS4.0 currently (it is currently only VSS3 compliant).

Mock might be interesting in addition, because it should be easy. If it is just about creating "some" CAN messages a CAN provider config can achieve the same, but I think it is currently not yet very good with state handling, i.e. updating "signals" inside a frame independently, so ti might not be able to replicate the required protocol implemented by seat service completely but @erikbosch knows more.

The nice thing is, you could "mix and match" basically showing how different implementations for "seat service" might exist, without the need to change clients

[SebastianSchildt]

The Android App looks Interesting. It communicates directly with the Databroker, right? Because, the idea of the Blueprint would be too, to show how one can build an extensive in-vehicle application which may expose its own API to enable such companions app scenarios like the MQTT-interface for the Seat Adjuster example. So for more complex companion scenarios the logic stays in the vehicle.

Yes it communicates directly with databroker, so it is not the same pattern as shown in the sketch, just want to point out it might be a nice addition

[erikbosch]

From a maintenance perspective I think it would be good to agree on the governance of the seat adjuster blueprint, concerning topics like:

• Who will monitor incoming issues and pull requests?
• When will a new version be release/tagged?
• Who performs release testing? Can release testing be performed without hardware?
• Who decides on required environment to support? (Like which VSS version to use and which Linux/Ubuntu version to use)

None of this should be the responsibility of the KUKSA project as I see it.

The seat service dependency to "real KUKSA components" is actually quite weak. It use the KUKSA proto definitions to communicate with KUKSA Databroker, but that is about it. So preferably as I would see it not just code but also ownership could be transferred to "eclipse-sdv-blueprints", but then of course the "eclipse-sdv-blueprints" maintainers could ask for support concerning the Databroker integration if they have problems upgrading VSS version or Databroker version.

(A side topic: KUKSA Databroker integration would be easier if KUKSA provided a C++ SDK/Lib so that C++ apps like Seat Service do not need to need to interact directly with the proto messages)

[eriksven]

I agree that the questions raised by @erikbosch should somehow be covered, which is the reason for raising the initial question here. I do not fully understand why we would strictly differentiate between Kuksa maintainers and eclipse-sdv-blueprints maintainers like they are two disjoint sets of people. For me, it makes sense to have the blueprints as a joint activity between maintainers of the showcased projects and people interested in the use case. My assumption was that the points asked by @erikbosch have already been covered in the past. So the question is more: a) Would you be willing to work on the code like you did before the move? b) Are there major implications, e.g., for downstream users, that I have missed so far?

I am not asking for guarantees for the upcoming years, but if you see any blockers, we could reconsider how and whether to create this blueprint.

So far, my understanding was that the Seat Service is mostly used in the context of the Seat Adjuster example anyway, so it would even make sense to tie the service to the releases of the overall blueprint.

[nacidai]

Thank you for your submission. Can you comment on:

• Who will be in charge of maintaining this blueprint and the expected members.
• A list/links to the SDV projects that will be included
• Other technologies worth mentioning

Also, would it be ok for you to present the blueprint at the next Blueprints zoom call (Nov 7, 3PM CEST)?

[eriksven]

Yes, I would like to present the blueprint in the next Blueprints Zoom Call.

The involved SDV projects are Eclipse Velocitas, Eclipse Kuksa, Eclipse Leda

At the moment, I would be initially in charge of the blueprint. My hope is to get some support of other maintainers of the involved project. But that is more on a case by case decision once new feature become available in the named projects not a general maintenance duty.

We also use Eclipse Kanto for orchestrating the containers in Eclipse Leda and rely on the Vehicle Signal Specification (VSS).

[eriksven]

Coming back to the conversation on moving the code for the seat service into the blueprints repository: In the last Eclipse Kuksa community call we came to the understanding to keep the Seat Service in the Kuksa repository for now and aim for using the Eclipse Kuksa Mock Service instead in the Blueprint at some point.

[nacidai]

I will kickoff the voting process to make the Seat Adjuster a new blueprint:

+1

[iarmac]

+1

[sophokles73]

+1

[badiiennouri1987]

+1

[AnotherDaniel]

+1

[nacidai]

5 (+1), 0 (-1)

The proposal has been accepted. @eriksven

Please provide the following details so that I can create a request at the Eclipse EMO help desk to create a repository and add the initial committers for your blueprint:

Blueprint name: Blueprint repository name: ((must be a valid github repository name) List of initial committers: (Name, Email) If they are not already, all committers will become committer members of Eclipse Foundation and accept its policies

[eriksven]

@nacidai that is great news!

Blueprint name: Companion Application Blueprint repository name: https://github.com/eclipse-sdv-blueprints/companion-application List of initial committers: Sven Jeroschewski, svenerik.jeroschewski@bosch.com (I am already a committer)

Based on the proposal by @AnotherDaniel and other feedback, I decided to adapt the name to Companion Application. The idea of the blueprint is more to show how one could build such an In-Vehicle Companion Application which not specific to only moving seats.

[nacidai]

The request at Eclipse Foundation Help desk to track the progress:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3948

[nacidai]

The repository has been created. Welcome companion application!

Committers, I am closing this issue please note the instructions at gitlab for further maintenance of this repository...:

"Also, it may be good opportunity to enable self-service (https://www.eclipse.org/projects/handbook/#resources-github-self-service) for your project at GitHub. This will capture the existing configuration as code in a separate repo (.eclipsefdn) and any committers can create PRs against this repo to change the configuration to fit your needs. The PRs will need to be approved by EF staff (and project leads if needed) before being merged and the changes finally being applied to GitHub. Here is for example a PR from another project enabling consistent branch protection rules for all repos: https://github.com/eclipse-velocitas/.eclipsefdn/pull/1 Here you can see a list of all Eclipse project that have this already enabled: https://eclipsefdn.github.io/otterdog-configs/ If you agree, we will make all preparation and create the first PR for demonstration purposes and also provide help for any questions that may arise."

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3948