adapt to new kuksa repos

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/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,7 +52,7 @@ 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