Merge branch 'update/vehicle_signal_interface_config' of https://gith…

…ub.com/SoftwareDefinedVehicle/velocitas-docs into update/vehicle_signal_interface_config

.devcontainer/Dockerfile

@@ -14,15 +14,15 @@
 
 # Update the NODE_VERSION arg in docker-compose.yml to pick a Node version: 18, 16, 14
 ARG NODE_VERSION=18
-FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:0-${NODE_VERSION}
+FROM mcr.microsoft.com/devcontainers/javascript-node:${NODE_VERSION}
 
 # VARIANT can be either 'hugo' for the standard version or 'hugo_extended' for the extended version.
 ARG VARIANT=hugo
 # VERSION can be either 'latest' or a specific version number
 ARG VERSION=latest
 
 # Download Hugo
-RUN apt-get update && apt-get install -y ca-certificates openssl git curl golang python pip && \
+RUN apt-get update && apt-get install -y ca-certificates openssl git curl golang python-is-python3 && \
     rm -rf /var/lib/apt/lists/* && \
     case ${VERSION} in \
     latest) \

.devcontainer/devcontainer.json

@@ -37,10 +37,9 @@
 	"forwardPorts": [
 		1313
 	],
-	// Use 'postCreateCommand' to run commands after the container is created.
-	// "postCreateCommand": "uname -a",
 	// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
 	"remoteUser": "node",
+	// Use 'postCreateCommand' to run commands after the container is created.
 	"postCreateCommand": ".devcontainer/scripts/postCreateCommand.sh",
 	"postStartCommand": "hugo server -b http://localhost/velocitas -w"
 }

.devcontainer/scripts/postCreateCommand.sh

@@ -23,7 +23,7 @@ npm install
 hugo mod get -u github.com/google/[email protected]
 
 # install pre-commit
-pip install pre-commit==3.5.0
+pip install pre-commit==3.6.0 --break-system-packages
 
 # add repo to git safe.directory & fix hugo issue with server start
 REPO=$(pwd)

.github/workflows/ci.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Setup Hugo
         uses: peaceiris/[email protected]
         with:
-          hugo-version: "0.110.0"
+          hugo-version: "0.123.3"
           extended: true
 
       - name: Build

.github/workflows/manual.yml

@@ -28,7 +28,7 @@ jobs:
       - name: Setup Hugo
         uses: peaceiris/[email protected]
         with:
-          hugo-version: "0.110.0"
+          hugo-version: "0.123.3"
           extended: true
 
       - name: Build

.vscode/settings.json

@@ -13,7 +13,6 @@
         "controlplane",
         "COVESA",
         "cppdbg",
-        "Dapr",
         "Databroker",
         "datapoint",
         "datapoints",
@@ -31,7 +30,6 @@
         "gohugoio",
         "grpcio",
         "hediet",
-        "helmignore",
         "hitkodev",
         "hotfixes",
         "hvac",

content/en/_index.html

@@ -14,12 +14,6 @@
   ~ SPDX-License-Identifier: Apache-2.0
   -->
 
-+++
-title = "Velocitas™"
-linkTitle = "Velocitas"
-description = "Toolchain for fast and easy development of vehicle applications for OEMs and suppliers"
-+++
-
 {{< blocks/cover title="Eclipse Velocitas™" image_anchor="top" height="full" color="dark">}}
 <div class="mx-auto">
   <p class="lead mt-5">Toolchain for creating containerized in-vehicle applications</p>

content/en/docs/about/repository-overview/_index.md

@@ -19,8 +19,8 @@ description: >
 | [vehicle-app-cpp-template](https://github.com/eclipse-velocitas/vehicle-app-cpp-template)         | GitHub Template repository contains an exemplary _Vehicle App_ that uses an exemplary SDK to provide access to vehicle data points and methods. The sample SDK extends the _sdv-vehicle-app-cpp-sdk_. In addition the template repository contains the development environment for Visual Studio Code for a _Vehicle App_ as well as the CI/CD workflows that can be used as blueprint for your own _Vehicle App_ written in C++.       |
 | [vehicle-app-cpp-sdk](https://github.com/eclipse-velocitas/vehicle-app-cpp-sdk)                   | Provides basic functionality to write a SDK to allow access to vehicle data points and method. This includes publishing & subscribe messaging, _VehicleApp_ API, vehicle data model ontology and function-based query & rule support.                                                                                                                                                                                                |
 | [vehicle-model-cpp](https://github.com/eclipse-velocitas/vehicle-model-cpp)                       | Basic vehicle model for C++ is generated from [VSS](https://github.com/COVESA/vehicle_signal_specification/tree/master/spec) with addition of some specialized vehicle services.                                                                                                                                                                                                                                                       |
-| [kuksa.val](https://github.com/eclipse/kuksa.val/tree/master/kuksa_databroker)                    | Is a part of the _Vehicle Abstraction Layer (VAL)_ of the [Eclipse KUKSA project](https://www.eclipse.org/kuksa/) and provides the KUKSA Data Broker (aka Vehicle Data Broker). The KUKSA Data Broker offers data points available in the vehicle to the _Vehicle Apps_ semantically aligned to a data model like the [Vehicle Signal Specification (VSS)](https://covesa.github.io/vehicle_signal_specification/).                                               |
-| [kuksa.val.feeders](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val)               | The KUKSA DBC Feeder is a generic data feeder that reads data from the vehicle's [CAN bus](https://en.wikipedia.org/wiki/CAN_bus) defined by a DBC file, maps them to a set of data points (e.g. according to the VSS) and feeds it into the Data Broker.                                                                                                                                                                           |
+| [kuksa-databroker](https://github.com/eclipse-kuksa/kuksa-databroker)                    | Is a part of the _Vehicle Abstraction Layer (VAL)_ of the [Eclipse KUKSA project](https://github.com/eclipse-kuksa) and provides the KUKSA Databroker. The KUKSA Databroker offers data points available in the vehicle to the _Vehicle Apps_ semantically aligned to a data model like the [Vehicle Signal Specification (VSS)](https://covesa.github.io/vehicle_signal_specification/).                                               |
+| [kuksa-can-provider](https://github.com/eclipse-kuksa/kuksa-can-provider)               | The KUKSA CAN Provider is a generic data feeder that reads data from the vehicle's [CAN bus](https://en.wikipedia.org/wiki/CAN_bus) defined by a DBC file, maps them to a set of data points (e.g. according to the VSS) and feeds it into the Databroker.                                                                                                                                                                           |
 | [kuksa.val.services](https://github.com/eclipse/kuksa.val.services)                               | Provides exemplary vehicle services and respective implementations that illustrates how to interact with in-vehicle components and services via an unified access that is semantically described e.g. in the [Vehicle Service Catalog (VSC)](https://github.com/COVESA/vehicle_service_catalog).                                                                                                                                    |
 | [release-documentation-action](https://github.com/eclipse-velocitas/release-documentation-action) | GitHub Action to generate a release documentation from the CI workflow output by rendering it to markdown files so that this can be easily published with GitHub Pages.                                                                                                                                                                                                                                                             |
 | [license-check](https://github.com/eclipse-velocitas/license-check)                               | GitHub Action to collect the licenses of the used components and can be configured to fail with an error message on invalid licenses.                                                                                                                                                                                                                                                                                               |

content/en/docs/about/use_cases/seat_adjuster/_index.md

@@ -13,7 +13,7 @@ description: >
 
 In the scenario of a car sharing company, the goal is to provide the functionality of automatically adjusting the driver's seat position based on their preferred settings stored in their profile. When the driver unlocks the car, a request is sent to the vehicle to retrieve the preferred seat position. This is where your implementation begins.
 
-The _Seat Adjuster Vehicle App_ receives a MQTT message containing the seat position, which then triggers a seat adjustment command through the _Seat Service_ to change the seat position. Additionally, to ensure convenience for future trips, the car sharing company saves the driver's preferred seat position and utilizes it accordingly. _The Seat Adjuster Vehicle App_ subscribes to the seat position, receiving updates from the _Data Broker_, which streams data from the _Seat Service_.
+The _Seat Adjuster Vehicle App_ receives a MQTT message containing the seat position, which then triggers a seat adjustment command through the _Seat Service_ to change the seat position. Additionally, to ensure convenience for future trips, the car sharing company saves the driver's preferred seat position and utilizes it accordingly. _The Seat Adjuster Vehicle App_ subscribes to the seat position, receiving updates from the _Databroker_, which streams data from the _Seat Service_.
 
 ## Requesting new seat position
 
@@ -26,7 +26,7 @@ The _Seat Adjuster Vehicle App_ receives a MQTT message containing the seat posi
    ```
 
 2. The **Seat Adjuster _Vehicle App_** that has subscribed to this topic, receives the request to change the seat position as a MQTT message.
-3. The **Seat Adjuster _Vehicle App_** gets the current vehicle speed from the data broker, which is fed by the **CAN Feeder (KUKSA DBC Feeder)**.
+3. The **Seat Adjuster _Vehicle App_** gets the current vehicle speed from the Databroker, which is fed by the **CAN Provider (KUKSA CAN Provider)**.
 4. With the support of the **_Vehicle App_ SDK**, the **Seat Adjuster _Vehicle App_** triggers a seat adjustment command of the **Seat Service** via gRPC in the event that the speed is equal to zero. Hint: This is a helpful convenience check but not a safety check.
 5. The **Seat Service** moves the seat to the new position via CAN messages.
 6. The **Seat Service** returns OK or an error code as gRPC status to the **Seat Adjuster _Vehicle App_**.
@@ -49,8 +49,8 @@ The _Seat Adjuster Vehicle App_ receives a MQTT message containing the seat posi
 ![seat_adjuster_dataflow_2](./seat_adjuster_dataflow_2.png)
 
 1. If the seat position will be changed by the driver, the new seat position will be sent to the **Seat Service** via CAN.
-2. The **Seat Service** streams the seat position via gRPC to the **KUKSA Data Broker** since it was registered beforehand.
-3. The **Seat Adjuster _Vehicle App_** that subscribed to the seat position receives the new seat position from the **KUKSA Data Broker** as a result.
+2. The **Seat Service** streams the seat position via gRPC to the **KUKSA Databroker** since it was registered beforehand.
+3. The **Seat Adjuster _Vehicle App_** that subscribed to the seat position receives the new seat position from the **KUKSA Databroker** as a result.
 4. The **Seat Adjuster _Vehicle App_** publishes this on topic `seatadjuster/currentPosition` with the payload:
 
     ```json

content/en/docs/concepts/deployment_model/_index.md

@@ -13,8 +13,7 @@ The Velocitas project uses a common deployment model. It uses [OCI-compliant](ht
 The deployment model is guided by the following principles
 
 - Applications are provided as OCI-compliant container images.
-- The container runtime offers a Kubernetes-compatible control plane and API to manage the container lifecycle.
-- Helm charts are used as deployment descriptor specification.
+- The container runtime offers a control plane and API to manage the container lifecycle.
 
 The template projects provided come with a pre-configured developer toolchain that accelerates the development process. The developer toolchain ensures an easy creation through a high-degree of automation of all required artifacts needed to follow the _Velocitas_ principles.
 

content/en/docs/concepts/deployment_model/vehicle_app_releases/_index.md

@@ -43,7 +43,6 @@ The `Build multi-arch image workflow` is triggered on every commit to the main b
 - **Building a multi-arch container for the app** - actions create a containerized version of the _Vehicle App_ for multiple architectures (currently AMD64 and ARM64).
 - **Scanning for vulnerabilities** - actions scan your code and container for vulnerabilities and in case of findings the workflow will be marked as "failed".
 - **Storing container images to GitHub action artifacts** - at the end of the workflow, the container image created is stored in a Github Action Artifacts so that it can be referenced by the Release Workflow later.
-- **Generate Deployment Files** - actions generate a PodSpec-file and HelmCharts to ease the deployment of the _Vehicle App_ and the runtime services.
 
 ## Release Workflow ([release.yml](https://github.com/eclipse-velocitas/vehicle-app-python-template/blob/main/.github/workflows/release.yml))
 
@@ -85,5 +84,3 @@ The release process would be the same as described in the overview, except that
 ## Further information
 
 - Tutorial: [How to write integration tests](/docs/tutorials/vehicle_app_development/integration_tests)
-- Tutorial: [Deploy a _Vehicle App_ with Helm](/docs/tutorials/vehicle_app_deployment/helm_deployment.md)
-- Tutorial: [Deploy a _Vehicle App_ with PodSpecs](/docs/tutorials/vehicle_app_deployment/podspecs_deployment.md)

content/en/docs/concepts/development_model/_index.md

@@ -25,7 +25,7 @@ The Vehicle Applications (_Vehicle Apps_) contain the business logic that needs
 
 ### Vehicle Models
 
-A Vehicle Model makes it possible to easily get vehicle data from the [Data Broker](#data-broker) and to execute remote procedure calls over gRPC against [Vehicle Services](#vehicle-services) and other [_Vehicle Apps_](#vehicle-apps). It is generated from the underlying [semantic models](#semantic-models) for a concrete programming language as a graph-based, strongly-typed, intellisense-enabled library. The elements of the vehicle models are defined by the [SDKs](#sdks).
+A Vehicle Model makes it possible to easily get vehicle data from the [Databroker](#kuksa-databroker) and to execute remote procedure calls over gRPC against [Vehicle Services](#vehicle-services) and other [_Vehicle Apps_](#vehicle-apps). It is generated from the underlying [semantic models](#semantic-models) for a concrete programming language as a graph-based, strongly-typed, intellisense-enabled library. The elements of the vehicle models are defined by the [SDKs](#sdks).
 
 ### SDKs
 
@@ -34,15 +34,15 @@ SDKs are available for Python and C++, currently. Further SDKs for Rust and C ar
 
 ### Vehicle Services
 
-Vehicle Services provide service interfaces to control actuators or to trigger (complex) actions. E.g. they communicate with the vehicle internal networks like CAN or Ethernet, which are connected to actuators, electronic control units (ECUs) and other vehicle computers (VCs). They may provide a simulation mode to run without a network interface. Vehicle services may feed data to the [Data Broker](#data-broker) and may expose gRPC endpoints, which can be invoked by [_Vehicle Apps_](#vehicle-apps) over a [Vehicle Model](#vehicle-models).
+Vehicle Services provide service interfaces to control actuators or to trigger (complex) actions. E.g. they communicate with the vehicle internal networks like CAN or Ethernet, which are connected to actuators, electronic control units (ECUs) and other vehicle computers (VCs). They may provide a simulation mode to run without a network interface. Vehicle services may feed data to the [Databroker](#kuksa-databroker) and may expose gRPC endpoints, which can be invoked by [_Vehicle Apps_](#vehicle-apps) over a [Vehicle Model](#vehicle-models).
 
-### KUKSA Data Broker (aka Vehicle Data Broker) {#data-broker}
+### KUKSA Databroker
 
-Vehicle data is stored in the KUKSA Data Broker conforming to an underlying [Semantic Model](#semantic-models) like [VSS](https://covesa.github.io/vehicle_signal_specification/). [_Vehicle Apps_](#vehicle-apps) can either pull this data or subscribe for updates. In addition, it supports rule-based access to reduce the number of updates sent to the _Vehicle App_.
+Vehicle data is stored in the KUKSA Databroker conforming to an underlying [Semantic Model](#semantic-models) like [VSS](https://covesa.github.io/vehicle_signal_specification/). [_Vehicle Apps_](#vehicle-apps) can either pull this data or subscribe for updates. In addition, it supports rule-based access to reduce the number of updates sent to the _Vehicle App_.
 
 ### Semantic models
 
-The Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) provides a domain taxonomy for vehicle signals and defines the vehicle data semantically, which is exchanged between _Vehicle Apps_ and the Data Broker.
+The Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) provides a domain taxonomy for vehicle signals and defines the vehicle data semantically, which is exchanged between _Vehicle Apps_ and the Databroker.
 
 The Vehicle Service Catalog ([VSC](https://github.com/COVESA/vehicle_service_catalog#vehicle-service-catalog)) extends VSS with functional remote procedure call definitions and semantically defines the gRPC interfaces of Vehicle Services and _Vehicle Apps_.
 
@@ -52,16 +52,17 @@ The Velocitas SDK is using [VSS](https://covesa.github.io/vehicle_signal_specifi
 
 ### Communication Protocols
 
-Asynchronous communication between [_Vehicle Apps_](#vehicle-apps) and other vehicle components, as well as cloud connectivity, is facilitated through [MQTT](https://mqtt.org/) messaging. Direct, synchronous communication between [_Vehicle Apps_](#vehicle-apps), [Vehicle Services](#vehicle-services) and the [Data Broker](#data-broker) is based on the [gRPC](https://grpc.io/) protocol.
+Asynchronous communication between [_Vehicle Apps_](#vehicle-apps) and other vehicle components, as well as cloud connectivity, is facilitated through [MQTT](https://mqtt.org/) messaging. Direct, synchronous communication between [_Vehicle Apps_](#vehicle-apps), [Vehicle Services](#vehicle-services) and the [Databroker](#kuksa-databroker) is based on the [gRPC](https://grpc.io/) protocol.
 
 ### Middleware Abstraction
 
-Velocitas provides middleware abstraction interfaces for Service Discovery, PubSub Messaging Protocol and other cross-cutting functionality.
-By default, Velocitas leverages [Dapr](https://dapr.io) for gRPC service discovery, Open Telemetry tracing and the [publish/subscribe building block](https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview/).
+Velocitas basically provides middleware abstraction interfaces for service discovery, pubsub messaging, and other cross-cutting functionalites.
+At the moment, Velocitas just offers a (what we call) "native middleware" implementation, which does not provide (gRPC) service discovery. Instead, addresses and port number of services need to be provided via environment variables to an app; e.g. SDV_VEHICLEDATABROKER_ADDRESS=grpc://localhost:55555.
+The support of Dapr as middleware has recently been removed.
 
 ### Vehicle Edge Operating System
 
-[_Vehicle Apps_](#vehicle-apps) are expected to run on a [Linux](https://www.linux.org/)-based operating system. An OCI-compliant container runtime is required to host the _Vehicle App_ containers and the Dapr middleware mandates a Kubernetes control plane. For publish/subscribe messaging a MQTT broker must be available (e.g., [Eclipse Mosquitto](https://mosquitto.org/)).
+[_Vehicle Apps_](#vehicle-apps) are expected to run on a [Linux](https://www.linux.org/)-based operating system. An OCI-compliant container runtime is required to host the _Vehicle App_ containers. For publish/subscribe messaging a MQTT broker must be available (e.g., [Eclipse Mosquitto](https://mosquitto.org/)).
 
 ## _Vehicle App_ Characteristics