diff --git a/content/en/docs/about/repository-overview/_index.md b/content/en/docs/about/repository-overview/_index.md
index a2d73ab61..705d280be 100644
--- a/content/en/docs/about/repository-overview/_index.md
+++ b/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. |
diff --git a/content/en/docs/about/repository-overview/project-overview.drawio.svg b/content/en/docs/about/repository-overview/project-overview.drawio.svg
index 4ef515d84..e1d6afdbb 100644
--- a/content/en/docs/about/repository-overview/project-overview.drawio.svg
+++ b/content/en/docs/about/repository-overview/project-overview.drawio.svg
@@ -1 +1 @@
-
+
diff --git a/content/en/docs/about/use_cases/seat_adjuster/_index.md b/content/en/docs/about/use_cases/seat_adjuster/_index.md
index 25d70a304..f4368556c 100644
--- a/content/en/docs/about/use_cases/seat_adjuster/_index.md
+++ b/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
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
diff --git a/content/en/docs/about/use_cases/use_case.drawio.svg b/content/en/docs/about/use_cases/use_case.drawio.svg
index 47ae8187e..0a304316b 100755
--- a/content/en/docs/about/use_cases/use_case.drawio.svg
+++ b/content/en/docs/about/use_cases/use_case.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/content/en/docs/concepts/development_model/_index.md b/content/en/docs/concepts/development_model/_index.md
index 0062d6a9a..cbb0e76c1 100644
--- a/content/en/docs/concepts/development_model/_index.md
+++ b/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
diff --git a/content/en/docs/concepts/development_model/val/_index.md b/content/en/docs/concepts/development_model/val/_index.md
index 0568f63a0..9e124c9f0 100644
--- a/content/en/docs/concepts/development_model/val/_index.md
+++ b/content/en/docs/concepts/development_model/val/_index.md
@@ -8,7 +8,7 @@ resources:
- src: "**val_architecture*.png"
- src: "**val_overview*.drawio.svg"
description: >
- Learn about the main concepts and components of the vehicle abstraction and how it relates to the [Eclipse KUKSA project](https://www.eclipse.org/kuksa/).
+ Learn about the main concepts and components of the vehicle abstraction and how it relates to the [Eclipse KUKSA project](https://github.com/eclipse-kuksa).
---
## Introduction
@@ -16,11 +16,11 @@ description: >
The Vehicle Abstraction Layer (VAL) enables access to the systems and functions of a vehicle via a unified - or even better - a standardized _Vehicle API_ abstracting from the details of the end-to-end architecture of the vehicle. The unified API enables _Vehicle Apps_ to run on different vehicle architectures of a single OEM. _Vehicle Apps_ can be even implemented OEM-agnostic, if using an API based on a standard like the [COVESA Vehicle Signal Specification (VSS)](https://covesa.github.io/vehicle_signal_specification/).
The _Vehicle API_ eliminates the need to know the source, destination, and format of signals for the vehicle system.
-The Eclipse Velocitas project is using the VAL of the [_Eclipse KUKSA project_](https://www.eclipse.org/kuksa/), also called _KUKSA.VAL_.
+The Eclipse Velocitas project is using the VAL of the [_Eclipse KUKSA project_](https://github.com/eclipse-kuksa), also called _KUKSA.VAL_.
KUKSA.VAL does not provide a concrete VAL. That's up to you as an OEM (vehicle manufacturer) or as a supplier.
But KUKSA.VAL provides the components and tools that helps you to implement a VAL for your chosen end-to-end architecture. Also, it can support you to simulate the vehicle hardware during the development phase of an _Vehicle App_ or Service.
-KUKSA.VAL provides you with ready-to-use generic components for the signal-based access to the vehicle, like the _KUKSA Data Broker_ and the generic _Data Providers_ (aka _Data Feeders_).
+KUKSA.VAL provides you with ready-to-use generic components for the signal-based access to the vehicle, like the _KUKSA Databroker_ and the generic _Data Providers_ (aka _Data Feeders_).
It also provides you reference implementations of certain _Vehicle Services_, like the _Seat Service_ and the _HVAC Service_.
## Architecture
@@ -29,39 +29,39 @@ The image below shows the main components of the VAL and its relation to the [Ve
-### KUKSA Data Broker (aka Vehicle Data Broker)
+### KUKSA Databroker
-The [KUKSA Data Broker](https://github.com/eclipse/kuksa.val/tree/master/kuksa_databroker) is a gRPC service acting as a broker of vehicle data / signals also called _data points_ in the following.
+The [KUKSA Databroker](https://github.com/eclipse-kuksa/kuksa-databroker) is a gRPC service acting as a broker of vehicle data / signals also called _data points_ in the following.
It provides central access to vehicle data points arranged in a - preferably standardized - vehicle data model like the COVESA VSS or others. But this is not a must, it is also possible to use your own (proprietary) vehicle model or to extend the COVESA VSS with your specific extensions via [VSS _overlays_](https://covesa.github.io/vehicle_signal_specification/rule_set/overlay/).
Data points represent certain states of a vehicle, like the current vehicle speed or the currently applied gear. Data points can represent sensor values like the vehicle speed or engine temperature, actuators like the wiper mode, and immutable attributes of the vehicle like the needed fuel type(s) of the vehicle, engine displacement, maximum power, etc.
Data points factually belonging together are typically arranged in branches and sub-branches of a tree structure (like [this example](https://covesa.github.io/vehicle_signal_specification/introduction/overview/#example) on the COVESA VSS site).
-The KUKSA Data Broker is implemented in Rust, can run in a container and provides services to get data points, update data points and for subscribing to automatic notifications on data point changes.
+The KUKSA Databroker is implemented in Rust, can run in a container and provides services to get data points, update data points and for subscribing to automatic notifications on data point changes.
Filter- and rule-based subscriptions of data points can be used to reduce the number of updates sent to the subscriber.
### Data Providers / Data Feeders
-Conceptually, a data provider is the responsible to take care for a certain set of data points: It provides updates of sensor data from the vehicle to the data broker and forwards updates of actuator values to the vehicle. The set of data points a data provider maintains may depend on the network interface (e.g. CAN bus) via that those data is accessible or it can depend on a certain use case the provider is responsible for (like seat control).
+Conceptually, a data provider is the responsible to take care for a certain set of data points: It provides updates of sensor data from the vehicle to the Databroker and forwards updates of actuator values to the vehicle. The set of data points a data provider maintains may depend on the network interface (e.g. CAN bus) via that those data is accessible or it can depend on a certain use case the provider is responsible for (like seat control).
-Eclipse KUKSA provides several _generic_ [_Data Providers_](https://github.com/eclipse/kuksa.val.feeders) for different datasources.
-As of today, Eclipse Velocitas only utilizes the generic [CAN feeder (KUKSA DBC Feeder)](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val) implemented in Python, which reads data from a CAN bus based on mappings specified in e.g. a CAN network description (dbc) file.
-The feeder uses a mapping file and data point metadata to convert the source data to data points and injects them into the data broker using its `Collector` gRPC interface.
-The feeder automatically reconnects to the data broker in the event that the connection is lost.
+Eclipse KUKSA provides several _generic_ [_Data Providers_](https://github.com/eclipse-kuksa#providers-exchanging-data-with-databrokerserver) for different datasources.
+As of today, Eclipse Velocitas only utilizes the generic [CAN Provider (KUKSA CAN Provider)](https://github.com/eclipse-kuksa/kuksa-can-provider) implemented in Python, which reads data from a CAN bus based on mappings specified in e.g. a CAN network description (dbc) file.
+The feeder uses a mapping file and data point metadata to convert the source data to data points and injects them into the Databroker using its `Collector` gRPC interface.
+The feeder automatically reconnects to the Databroker in the event that the connection is lost.
### Vehicle Services
A vehicle service offers a _Vehicle App_ to interact with the vehicle systems on a RPC-like basis.
It can provide service interfaces to control actuators or to trigger (complex) actions, or provide interfaces to get data.
-It communicates with the Hardware Abstraction to execute the underlying services, but may also interact with the data broker.
+It communicates with the Hardware Abstraction to execute the underlying services, but may also interact with the Databroker.
The [KUKSA.VAL Services repository](https://github.com/eclipse/kuksa.val.services/) contains examples illustrating how such kind of vehicle services can be built.
### Hardware Abstraction
Data feeders rely on hardware abstraction. Hardware abstraction is project/platform specific.
-The reference implementation relies on **SocketCAN** and **vxcan**, see [kuksa.val.feeders](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val).
+The reference implementation relies on **SocketCAN** and **vxcan**, see [KUKSA CAN Provider](https://github.com/eclipse-kuksa/kuksa-can-provider).
The hardware abstraction may offer replaying (e.g., CAN) data from a file (can dump file) when the respective data source (e.g., CAN) is not available.
{{< imgproc val_architecture Resize "800x" >}}
@@ -72,14 +72,14 @@ The hardware abstraction may offer replaying (e.g., CAN) data from a file (can d
The VAL offers an information flow between vehicle networks and vehicle services.
The data that can flow is ultimately limited to the data available through the Hardware Abstraction, which is platform/project-specific.
-The KUKSA Data Broker offers read/subscribe access to data points based on a gRPC service. The data points which are actually available are defined by the set of feeders providing the data into the broker.
-Services (like the [seat service](https://github.com/eclipse/kuksa.val.services/tree/main/seat_service)) define which CAN signals they listen to and which CAN signals they send themselves, see [documentation](https://github.com/eclipse/kuksa.val.services/blob/main/seat_service/src/lib/seat_adjuster/seat_controller/README.md).
-Service implementations may also interact as feeders with the data broker.
+The KUKSA Databroker offers read/subscribe access to data points based on a gRPC service. The data points which are actually available are defined by the set of feeders providing the data into the broker.
+Services (like the [seat service](https://github.com/eclipse-kuksa/kuksa-incubation/tree/main/seat_service)) define which CAN signals they listen to and which CAN signals they send themselves, see [documentation](https://github.com/eclipse-kuksa/kuksa-incubation/blob/main/seat_service/src/lib/seat_adjuster/seat_controller/README.md).
+Service implementations may also interact as feeders with the Databroker.
-### Data flow when a _Vehicle App_ uses the KUKSA Data Broker
+### Data flow when a _Vehicle App_ uses the KUKSA Databroker
{{< imgproc dataflow_broker Resize "800x" >}}
- Architectural representation of the KUKSA data broker data flow
+ Architectural representation of the KUKSA Databroker data flow
{{< /imgproc >}}
### Data flow when a _Vehicle App_ uses a Vehicle Service
@@ -90,11 +90,11 @@ Service implementations may also interact as feeders with the data broker.
## Source Code
-Source code and build instructions are available in the respective KUKSA.VAL repositories:
+Source code and build instructions are available in the respective KUKSA repositories:
-* [KUKSA Data Broker](https://github.com/eclipse/kuksa.val/tree/master/kuksa_databroker)
-* [KUKSA DBC Feeder](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val)
-* [KUKSA example services](https://github.com/eclipse/kuksa.val.services/)
+* [KUKSA Databroker](https://github.com/eclipse-kuksa/kuksa-databroker)
+* [KUKSA CAN Provider](https://github.com/eclipse-kuksa/kuksa-can-provider)
+* [KUKSA example providers](https://github.com/eclipse-kuksa#providers-exchanging-data-with-databrokerserver)
## Guidelines
diff --git a/content/en/docs/concepts/development_model/val/val_overview.drawio.svg b/content/en/docs/concepts/development_model/val/val_overview.drawio.svg
index cf5dd1afe..3063ddcf7 100755
--- a/content/en/docs/concepts/development_model/val/val_overview.drawio.svg
+++ b/content/en/docs/concepts/development_model/val/val_overview.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/content/en/docs/concepts/development_model/vehicle_app_manifest/_index.md b/content/en/docs/concepts/development_model/vehicle_app_manifest/_index.md
index 48208b08f..88c1c9f8e 100644
--- a/content/en/docs/concepts/development_model/vehicle_app_manifest/_index.md
+++ b/content/en/docs/concepts/development_model/vehicle_app_manifest/_index.md
@@ -81,7 +81,7 @@ To fully understand the _AppManifest_, let's have a look at **who** interacts wi
{
"type": "grpc-interface",
"config": {
- "src": "https://raw.githubusercontent.com/eclipse/kuksa.val.services/main/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto",
+ "src": "https://raw.githubusercontent.com/eclipse-kuksa/kuksa-incubation/0.4.0/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto",
"required": {
"methods": [ "Move", "MoveComponent" ]
},
diff --git a/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/grpc_interface.md b/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/grpc_interface.md
index 5481f6a05..9d090752c 100644
--- a/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/grpc_interface.md
+++ b/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/grpc_interface.md
@@ -26,7 +26,7 @@ If a _Vehicle App_ provides a `grpc-interface` - a server stub embedded into the
{{
}}
| Attribute | Type | Example value | Description |
|-|-|-|-|
-| `src` | string | `"https://raw.githubusercontent.com/eclipse/kuksa.val.services/v0.2.0/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto"` | URI of the used protobuf specification of the service. URI may point to a local file or to a file provided by a server. It is generally recommended that a **stable** proto file is used. I.e. one that is already released under a proper tag rather than an in-development proto file. |
+| `src` | string | `"https://raw.githubusercontent.com/eclipse-kuksa/kuksa-incubation/0.4.0/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto"` | URI of the used protobuf specification of the service. URI may point to a local file or to a file provided by a server. It is generally recommended that a **stable** proto file is used. I.e. one that is already released under a proper tag rather than an in-development proto file. |
| `required.methods` | array | Array of service's methods that are accessed by the application. In addition to access control the methods attribute may be used to determine backward or forward compatibility i.e. if semantics of a service's interface did not change but methods were added or removed in a future version. |
| `required.methods.[].name` | string | `"Move"`, `"MoveComponent"` | Name of the method that the application would like to access |
| `provided` | object | `{}` | Reserved object indicating that the interface is provided. Might be filled with further configuration values.
@@ -38,7 +38,7 @@ If a _Vehicle App_ provides a `grpc-interface` - a server stub embedded into the
{
"type": "grpc-interface",
"config": {
- "src": "https://raw.githubusercontent.com/eclipse/kuksa.val.services/v0.2.0/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto",
+ "src": "https://raw.githubusercontent.com/eclipse-kuksa/kuksa-incubation/0.4.0/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto",
"required": {
"methods": [
"Move", "MoveComponent"
diff --git a/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/vehicle_signal_interface.md b/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/vehicle_signal_interface.md
index e9c2999eb..de6f7061b 100644
--- a/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/vehicle_signal_interface.md
+++ b/content/en/docs/concepts/development_model/vehicle_app_manifest/interfaces/vehicle_signal_interface.md
@@ -17,7 +17,7 @@ The _Vehicle Signal Interface_ formerly known as [_Vehicle Model_](/docs/concept
If a _Vehicle App_ requires a `vehicle-signal-interface`, it will act as a consumer of datapoints already available in the system. If, on the other hand, a _Vehicle App_ provides a `vehicle-signal-interface`, it will act as a provider (formerly feeder in KUKSA terms) of the declared datapoints.
-Furthermore, in the source code generated by this functional interface, a connection to [Kuksa Databroker](https://github.com/eclipse/kuksa.val/tree/master/kuksa_databroker) will be established via the configured Velocitas middleware. It uses the `broker.proto` if provided by the Kuksa Databroker to connect via gRPC. A seperate declaration of a `grpc-interface` for the databroker is **NOT** required.
+Furthermore, in the source code generated by this functional interface, a connection to [KUKSA Databroker](https://github.com/eclipse-kuksa/kuksa-databroker) will be established via the configured Velocitas middleware. It uses the `broker.proto` if provided by the KUKSA Databroker to connect via gRPC. A seperate declaration of a `grpc-interface` for the databroker is **NOT** required.
More information: [Vehicle Model Creation](/docs/tutorials/vehicle_model_creation/)
diff --git a/content/en/docs/concepts/development_model/vehicle_app_sdk/_index.md b/content/en/docs/concepts/development_model/vehicle_app_sdk/_index.md
index 981c05ae5..acea4a93e 100644
--- a/content/en/docs/concepts/development_model/vehicle_app_sdk/_index.md
+++ b/content/en/docs/concepts/development_model/vehicle_app_sdk/_index.md
@@ -19,7 +19,7 @@ The _Vehicle App_ SDK consists of the following building blocks:
- **[Middleware integration](#middleware-integration):** Vehicle Models can contain gRPC stubs to communicate with _Vehicle Services_. gRPC communication is integrated natively.
-- **[Fluent query & rule construction](#fluent-query--rule-construction):** Based on a concrete Vehicle Model, the SDK is able to generate queries and rules against the KUKSA Data Broker to access the real values of the data points that are defined in the vehicle model.
+- **[Fluent query & rule construction](#fluent-query--rule-construction):** Based on a concrete Vehicle Model, the SDK is able to generate queries and rules against the KUKSA Databroker to access the real values of the data points that are defined in the vehicle model.
- **[Publish & subscribe messaging](#publish--subscribe-messaging):** The SDK supports publishing messages to a MQTT broker and subscribing to topics of a MQTT broker.
@@ -305,7 +305,7 @@ private:
## Fluent query & rule construction
-A set of query methods like `get()`, `where()`, `join()` etc. are provided through the `Model` and `DataPoint` base classes. These functions make it possible to construct SQL-like queries and subscriptions in a fluent language, which are then transmitted through the gRPC interface to the KUKSA Data Broker.
+A set of query methods like `get()`, `where()`, `join()` etc. are provided through the `Model` and `DataPoint` base classes. These functions make it possible to construct SQL-like queries and subscriptions in a fluent language, which are then transmitted through the gRPC interface to the KUKSA Databroker.
### Query examples
@@ -472,11 +472,11 @@ subscribeToTopic("seatadjuster/setPosition/request")->onItem([this](auto&& item)
## Vehicle App abstraction
-_Vehicle Apps_ are inherited from the `VehicleApp` base class. This enables the _Vehicle App_ to use the Publish & Subscribe messaging and to connect to the KUKSA Data Broker.
+_Vehicle Apps_ are inherited from the `VehicleApp` base class. This enables the _Vehicle App_ to use the Publish & Subscribe messaging and to connect to the KUKSA Databroker.
The `Vehicle Model` instance is passed to the constructor of the `VehicleApp` class and should be stored in a member variable (e.g. `self.vehicle` for Python, `std::shared_ptr m_vehicle;` for C++), to be used by all methods within the application.
-Finally, the `run()` method of the `VehicleApp` class is called to start the _Vehicle App_ and register all MQTT topic and Data Broker subscriptions.
+Finally, the `run()` method of the `VehicleApp` class is called to start the _Vehicle App_ and register all MQTT topic and Databroker subscriptions.
{{% alert title="Implementation detail" color="warning" %}}
In Python, the subscriptions are based on `asyncio`, which makes it necessary to call the `run()` method with an active `asyncio event_loop`.
diff --git a/content/en/docs/tutorials/prototyping/service_integration.md b/content/en/docs/tutorials/prototyping/service_integration.md
index 692887b42..9b46d9568 100644
--- a/content/en/docs/tutorials/prototyping/service_integration.md
+++ b/content/en/docs/tutorials/prototyping/service_integration.md
@@ -8,7 +8,7 @@ description: >
Services can make sure, that when you write a VSS data point, something is actually happening. Eclipse Velocitas has an example seat or hvac service. If your _Vehicle App_ makes use of e.g. `Vehicle.Cabin.Seat.Row1.Pos1.Position` or other seat/hvac specific data points you are in for some real action. To learn more, visit [_Vehicle Services_](/docs/concepts/development_model/val/#vehicle-services).
-Our maintained [`devenv-runtimes`](https://github.com/eclipse-velocitas/devenv-runtimes) package ([Velocitas Lifecycle Management](/docs/concepts/lifecycle_management)) comes with the support of adding further _Vehicle Services_ to the `runtime.json` of a package. More information [here](/docs/concepts/lifecycle_management/packages/development/#configuration-of-runtime-packages). (A general vehicle _mock service_ is also coming soon!)
+Our maintained [`devenv-runtimes`](https://github.com/eclipse-velocitas/devenv-runtimes) package ([Velocitas Lifecycle Management](/docs/concepts/lifecycle_management)) comes with the support of adding further _Vehicle Services_ to the `runtime.json` of a package. More information [here](/docs/concepts/lifecycle_management/packages/development/#configuration-of-runtime-packages).
### Modify existing services
@@ -16,11 +16,11 @@ For more advanced usage you can also try to modify existing services. Check out
### Create your own services
-If you want to create your own service the [KUKSA.VAL Services repository](https://github.com/eclipse/kuksa.val.services/) contains examples illustrating how such kind of vehicle services can be built. You need to write an application that talks to _KUKSA.VAL_ listening to changes of a _target value_ of some VSS data point and then do whatever you want. You can achieve this by using the _KUKSA.VAL_ [gRPC API](https://github.com/eclipse/kuksa.val/tree/master/proto/kuksa/val/v1) with any programming language of your choice (learn more about [gRPC](https://grpc.io)).
+If you want to create your own service the [KUKSA.VAL Services repository](https://github.com/eclipse/kuksa.val.services/) contains examples illustrating how such kind of vehicle services can be built. You need to write an application that talks to _KUKSA.VAL_ listening to changes of a _target value_ of some VSS data point and then do whatever you want. You can achieve this by using the _KUKSA.VAL_ [gRPC API](https://github.com/eclipse-kuksa/kuksa-databroker/tree/main/proto/kuksa/val/v1) with any programming language of your choice (learn more about [gRPC](https://grpc.io)).
-### Mock Service and Mock Service Integration
+### Mock Provider and Mock Provider Integration
-[The Vehicle Mock Service](https://github.com/eclipse/kuksa.val.services/tree/main/mock_service) is a dummy service allowing to control all specified actuator- and sensor-signals via a configuration file. These configuration files are expressed in a Python-based domain-specific language (DSL).
-The default behavior is predefined in [mock.py](https://github.com/eclipse/kuksa.val.services/blob/main/mock_service/mock.py)
+[The Vehicle Mock Provider](https://github.com/eclipse-kuksa/kuksa-mock-provider) is a dummy service allowing to control all specified actuator- and sensor-signals via a configuration file. These configuration files are expressed in a Python-based domain-specific language (DSL).
+The default behavior is predefined in [mock.py](https://github.com/eclipse-kuksa/kuksa-mock-provider/blob/main/mock/mock.py)
-The Mock Service is already integrated in all our [Vehicle Runtimes](/docs/tutorials/vehicle_app_runtime). To be able to configure it, you need to add a custom `mock.py` in the root of your Vehicle App Project. The Mock Service Container will pick it up automatically.
+The Mock Provider is already integrated in all our [Vehicle Runtimes](/docs/tutorials/vehicle_app_runtime). To be able to configure it, you need to add a custom `mock.py` in the root of your Vehicle App Project. The Mock Provider Container will pick it up automatically.
diff --git a/content/en/docs/tutorials/quickstart/quickstart.md b/content/en/docs/tutorials/quickstart/quickstart.md
index 1480f83b6..b79048d39 100644
--- a/content/en/docs/tutorials/quickstart/quickstart.md
+++ b/content/en/docs/tutorials/quickstart/quickstart.md
@@ -123,7 +123,7 @@ You can find more information about the _Vehicle App_ development in the [respec
## How to start the runtime services?
-The runtime services (like _KUKSA Data Broker_ or _Vehicle Services_) are required to develop _Vehicle Apps_ and run integration tests.
+The runtime services (like _KUKSA Databroker_ or _Vehicle Services_) are required to develop _Vehicle Apps_ and run integration tests.
Currently, the supported options to run these services is either [locally](/docs/tutorials/vehicle_app_runtime/local_runtime) or via the [Kanto runtime](/docs/tutorials/vehicle_app_runtime/kanto_runtime).
diff --git a/content/en/docs/tutorials/vehicle_app_development/cpp_development.md b/content/en/docs/tutorials/vehicle_app_development/cpp_development.md
index f24e0acbc..01357d519 100644
--- a/content/en/docs/tutorials/vehicle_app_development/cpp_development.md
+++ b/content/en/docs/tutorials/vehicle_app_development/cpp_development.md
@@ -141,7 +141,7 @@ void onSeatPositionChanged(const DataPointsResult& result) {
```
-The `VehicleApp` class provides the `subscribeDataPoints()` method which allows to listen for changes on one or many data points. Once a change in any of the data points is registered, the callback registered via `AsyncSubscription::onItem()` is called. Conversely, the callback registered via `AsyncSubscription::onError()` is called once there is any error during communication with the KUKSA data broker.
+The `VehicleApp` class provides the `subscribeDataPoints()` method which allows to listen for changes on one or many data points. Once a change in any of the data points is registered, the callback registered via `AsyncSubscription::onItem()` is called. Conversely, the callback registered via `AsyncSubscription::onError()` is called once there is any error during communication with the KUKSA Databroker.
The result passed to the callback registered via `onItem()` is an object of type `DataPointsResult` which holds all data points that have changed. Individual data points can be accessed directly by their reference: `result.get(Vehicle.Cabin.Seat.Row1.Pos1.Position)`)
diff --git a/content/en/docs/tutorials/vehicle_app_development/integration_tests.md b/content/en/docs/tutorials/vehicle_app_development/integration_tests.md
index 6320e91c6..2b7fe1627 100644
--- a/content/en/docs/tutorials/vehicle_app_development/integration_tests.md
+++ b/content/en/docs/tutorials/vehicle_app_development/integration_tests.md
@@ -3,12 +3,12 @@ title: "Vehicle App Integration Testing"
date: 2022-05-09T13:46:21+05:30
weight: 60
description: >
- Learn how to test that a _Vehicle App_ together with the KUKSA Data Broker and potentially other dependant Vehicle Services or _Vehicle Apps_ runs as expected.
+ Learn how to test that a _Vehicle App_ together with the KUKSA Databroker and potentially other dependant Vehicle Services or _Vehicle Apps_ runs as expected.
aliases:
- /docs/tutorials/vehicle_app_development/integration_tests
---
-To be sure that a newly created _Vehicle App_ will run together with the _KUKSA Data Broker_ and potentially other dependant _Vehicle Services_ or _Vehicle Apps_, it's essential to write integration tests along with developing the app.
+To be sure that a newly created _Vehicle App_ will run together with the _KUKSA Databroker_ and potentially other dependant _Vehicle Services_ or _Vehicle Apps_, it's essential to write integration tests along with developing the app.
To execute an integration test, the dependant components need to be running and be accessible from the test runner. This guide will describe how integration tests can be written and integrated in the CI pipeline so that they are executed automatically when building the application.
@@ -18,7 +18,7 @@ This guide is currently only available for development of integration tests with
## Writing Test Cases
-To write an integration test, you should check the sample that comes with the template ([`/app/tests/integration/integration_test.py`](https://github.com/eclipse-velocitas/vehicle-app-python-template/blob/main/app/tests/integration/integration_test.py)). To support interacting with the MQTT broker and the KUKSA Data Broker (to get and set values for data points), there are two classes present in Python SDK that will help:
+To write an integration test, you should check the sample that comes with the template ([`/app/tests/integration/integration_test.py`](https://github.com/eclipse-velocitas/vehicle-app-python-template/blob/main/app/tests/integration/integration_test.py)). To support interacting with the MQTT broker and the KUKSA Databroker (to get and set values for data points), there are two classes present in Python SDK that will help:
- `MqttClient`: this class provides methods for interacting with the MQTT broker. Currently, the following methods are available:
@@ -40,7 +40,7 @@ To write an integration test, you should check the sample that comes with the te
This class can be initialized with a given port. If no port is specified, the environment variable `MQTT_PORT` will be checked. If this is not possible either, the default value of `1883` will be used. **It's recommended to specify no port when initializing that class as it will locally use the default port `1883` and in CI the port is set by the environment variable `MQTT_PORT`. This will prevent a check-in in the wrong port during local development.**
-- `IntTestHelper`: this class provides functionality to interact with the _KUKSA Data Broker_.
+- `IntTestHelper`: this class provides functionality to interact with the _KUKSA Databroker_.
- `register_datapoint`: registers a new data point with given name and type ([here](/docs/concepts/development_model/vehicle_app_sdk/#typed-datapoint-classes) you can find more information about the available types)
- `set_..._datapoint`: set the given value for the data point with the given name (with given type). If the data point does not exist, it will be registered.
@@ -52,8 +52,8 @@ To write an integration test, you should check the sample that comes with the te
To be able to test the _Vehicle App_ in an integrated way, the following components should be running:
- Mosquitto
-- Data Broker
-- Vehicle Mock Service
+- Databroker
+- Vehicle Mock Provider
We distinguish between two environments for executing the _Vehicle App_ and the runtime components:
@@ -103,7 +103,7 @@ Finally the test results are collected and published as artifacts of the workflo
### Troubleshoot IntTestHelper
-- Make sure that the _KUKSA Data Broker_ is up and running by checking the task log.
+- Make sure that the _KUKSA Databroker_ is up and running by checking the task log.
- Make sure that you are using the right ports.
- Make sure that you installed the correct version of the SDK (_SDV_-package).
diff --git a/content/en/docs/tutorials/vehicle_app_development/python_development.md b/content/en/docs/tutorials/vehicle_app_development/python_development.md
index 5e85ddb36..835d1ee3a 100644
--- a/content/en/docs/tutorials/vehicle_app_development/python_development.md
+++ b/content/en/docs/tutorials/vehicle_app_development/python_development.md
@@ -145,7 +145,7 @@ If you want to get notified about changes of a specific `DataPoint`, you can sub
```
Every `DataPoint` provides a _.subscribe()_ method that allows for providing a callback function which will be invoked on every data point update. Subscribed data is available in the respective _DataPointReply_ object and need to be accessed via the reference to the subscribed data point. The returned object is of type `TypedDataPointResult` which holds the `value` of the data point
-and the `timestamp` at which the value was captured by the data broker.
+and the `timestamp` at which the value was captured by the Databroker.
Therefore the `on_seat_position_changed` callback function needs to be implemented like this:
```Python
diff --git a/content/en/docs/tutorials/vehicle_app_runtime/kanto_runtime.md b/content/en/docs/tutorials/vehicle_app_runtime/kanto_runtime.md
index b0696da81..88ab53659 100644
--- a/content/en/docs/tutorials/vehicle_app_runtime/kanto_runtime.md
+++ b/content/en/docs/tutorials/vehicle_app_runtime/kanto_runtime.md
@@ -50,7 +50,7 @@ FeederCAN requires a candump file. A pre-defined candump file is already part of
1. Creating/updating candump file with the name `candumpDefault.log` in `./config/feedercan`
1. Restarting Kanto (execute the tasks ```Kanto - Runtime Down``` and ```Kanto - Runtime Up```)
-More information about FeederCan can be found [here](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val)
+More information about the CAN Provider can be found [here](https://github.com/eclipse-kuksa/kuksa-can-provider)
## Next steps
diff --git a/content/en/docs/tutorials/vehicle_app_runtime/local_runtime.md b/content/en/docs/tutorials/vehicle_app_runtime/local_runtime.md
index 8be4f9253..7c8dd4183 100644
--- a/content/en/docs/tutorials/vehicle_app_runtime/local_runtime.md
+++ b/content/en/docs/tutorials/vehicle_app_runtime/local_runtime.md
@@ -10,7 +10,7 @@ aliases:
## Using tasks in Visual Studio Code
-**Overview:** If you are developing in Visual Studio Code, the runtime components (like _KUKSA Data Broker_ or _Vehicle Services_) are available for local execution coming from our _devenv-runtimes_ package and are accessible as _Tasks_, a feature of the Visual Studio Code. Additional information on tasks can be found [here](https://code.visualstudio.com/docs/editor/tasks).
+**Overview:** If you are developing in Visual Studio Code, the runtime components (like _KUKSA Databroker_ or _Vehicle Services_) are available for local execution coming from our _devenv-runtimes_ package and are accessible as _Tasks_, a feature of the Visual Studio Code. Additional information on tasks can be found [here](https://code.visualstudio.com/docs/editor/tasks).
**Start local runtime:** To start local runtime, a task called `Local Runtime - Up` is available. This task runs the runtime services in the correct order. You can run this task by clicking `F1` and choose `Tasks: Run task`, then select `Local Runtime - Up`.
@@ -23,9 +23,9 @@ aliases:
The configuration for services of our provided local runtime are defined in the [`runtime.json`](https://github.com/eclipse-velocitas/devenv-runtimes/blob/main/runtime.json) at the root of the repository [devenv-runtimes](https://github.com/eclipse-velocitas/devenv-runtimes/tree/main).
For a more detailed view on how to change or add runtime service configuration, please visit: [Lifecycle Management Package Development](/docs/concepts/lifecycle_management/packages/development/#configuration-of-runtime-packages)
-## Using KUKSA Data Broker CLI
+## Using KUKSA Databroker CLI
-A CLI tool is provided for interacting with a running instance of the KUKSA Data Broker. It can be started by running the task `Local Runtime - VehicleDataBroker CLI`(by pressing _F1_, type _Run Task_ followed by `Local Runtime - VehicleDataBroker CLI`). The _Runtime Local_ needs to be running for you to be able to use the tool.
+A CLI tool is provided for interacting with a running instance of the KUKSA Databroker. It can be started by running the task `Local Runtime - VehicleDataBroker CLI`(by pressing _F1_, type _Run Task_ followed by `Local Runtime - VehicleDataBroker CLI`). The _Runtime Local_ needs to be running for you to be able to use the tool.
## Integrating a new runtime service into Visual Studio Code Task
diff --git a/content/en/docs/tutorials/vehicle_model_creation/_index.md b/content/en/docs/tutorials/vehicle_model_creation/_index.md
index d23df418b..ee190623f 100644
--- a/content/en/docs/tutorials/vehicle_model_creation/_index.md
+++ b/content/en/docs/tutorials/vehicle_model_creation/_index.md
@@ -9,7 +9,7 @@ description: >
{{% alert title="Info" %}} On Friday, 2023-03-03 we released our new [model lifecycle approach](automated_model_lifecycle/). With the update of the documentation the previous content of this page can be found in the section [Manual Vehicle Model Creation](manual_model_creation/) now.
{{% /alert %}}
-A _Vehicle Model_ makes it possible to easily get vehicle data from the KUKSA Data Broker and to execute remote procedure calls over gRPC against _Vehicle Services_ and other _Vehicle Apps_. It is generated from the underlying semantic models based e.g. on the [COVESA Vehicle Signal Specification (VSS)](https://covesa.github.io/vehicle_signal_specification/). The model is generated for a concrete programming language as a graph-based, strongly-typed, intellisense-enabled library providing vehicle abstraction "on code level".
+A _Vehicle Model_ makes it possible to easily get vehicle data from the KUKSA Databroker and to execute remote procedure calls over gRPC against _Vehicle Services_ and other _Vehicle Apps_. It is generated from the underlying semantic models based e.g. on the [COVESA Vehicle Signal Specification (VSS)](https://covesa.github.io/vehicle_signal_specification/). The model is generated for a concrete programming language as a graph-based, strongly-typed, intellisense-enabled library providing vehicle abstraction "on code level".
By default our app templates now generate the vehicle model during the devContainer initialization - managed by the Velocitas life cycle management. The respective VSS-based model source is referenced in the app manifest allowing to freely choose the model being used in your project. You will find more details about this in section [Automated Model Lifecycle](automated_model_lifecycle/).
diff --git a/content/en/docs/tutorials/vehicle_model_creation/manual_model_creation/manual_creation_python.md b/content/en/docs/tutorials/vehicle_model_creation/manual_model_creation/manual_creation_python.md
index 11627db6a..0901691e7 100644
--- a/content/en/docs/tutorials/vehicle_model_creation/manual_model_creation/manual_creation_python.md
+++ b/content/en/docs/tutorials/vehicle_model_creation/manual_model_creation/manual_creation_python.md
@@ -184,14 +184,14 @@ description: >
### Add a Vehicle Service
-_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 and may expose gRPC endpoints, which can be invoked by _Vehicle Apps_ over a _Vehicle Model_.
+_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 and may expose gRPC endpoints, which can be invoked by _Vehicle Apps_ over a _Vehicle Model_.
In this section, we add a _Vehicle Service_ to the _Vehicle Model_.
1. Create a new folder `proto` under `my_vehicle_model/my_vehicle_model`.
2. Copy your proto file under `my_vehicle_model/my_vehicle_model/proto`
- As example you could use the protocol buffers message definition [seats.proto](https://github.com/eclipse/kuksa.val.services/blob/main/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto) provided by the KUKSA.VAL services which describes a [seat control service](https://github.com/eclipse/kuksa.val.services/tree/main/seat_service).
+ As example you could use the protocol buffers message definition [seats.proto](https://github.com/eclipse-kuksa/kuksa-incubation/blob/main/seat_service/proto/sdv/edge/comfort/seats/v1/seats.proto) provided by the KUKSA.VAL services which describes a [seat control service](https://github.com/eclipse-kuksa/kuksa-incubation/tree/main/seat_service).
3. Install the grpcio tools including mypy types to generate the Python classes out of the proto-file:
diff --git a/static/assets/diagrams.drawio b/static/assets/diagrams.drawio
index 37fe2453a..d8904dbf2 100644
--- a/static/assets/diagrams.drawio
+++ b/static/assets/diagrams.drawio
@@ -45,13 +45,13 @@
-
+
-
+
@@ -166,7 +166,7 @@
-
+
diff --git a/static/assets/direct_service_invocation.drawio b/static/assets/direct_service_invocation.drawio
index ffe9510bc..bf86abb3d 100644
--- a/static/assets/direct_service_invocation.drawio
+++ b/static/assets/direct_service_invocation.drawio
@@ -128,7 +128,7 @@
-
+
diff --git a/static/assets/programming_model.drawio.svg b/static/assets/programming_model.drawio.svg
index 360c02744..713239200 100644
--- a/static/assets/programming_model.drawio.svg
+++ b/static/assets/programming_model.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/static/assets/project-overview.svg b/static/assets/project-overview.svg
index fbf87b5e5..0aec47908 100644
--- a/static/assets/project-overview.svg
+++ b/static/assets/project-overview.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/static/assets/sdk_overview.drawio.svg b/static/assets/sdk_overview.drawio.svg
index 1dcd4b6bc..e93a705ba 100644
--- a/static/assets/sdk_overview.drawio.svg
+++ b/static/assets/sdk_overview.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/static/assets/seat_adjuster_dataflow.svg b/static/assets/seat_adjuster_dataflow.svg
index 871765ab3..3e56a964d 100644
--- a/static/assets/seat_adjuster_dataflow.svg
+++ b/static/assets/seat_adjuster_dataflow.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/static/assets/seat_adjuster_dataflow_1.svg b/static/assets/seat_adjuster_dataflow_1.svg
index faa9eae09..be893636c 100644
--- a/static/assets/seat_adjuster_dataflow_1.svg
+++ b/static/assets/seat_adjuster_dataflow_1.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/static/assets/seat_adjuster_dataflow_2.svg b/static/assets/seat_adjuster_dataflow_2.svg
index ead154066..5ee9d2f89 100644
--- a/static/assets/seat_adjuster_dataflow_2.svg
+++ b/static/assets/seat_adjuster_dataflow_2.svg
@@ -1,4 +1,4 @@
-
+