Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapt to new kuksa repos #120

Merged
merged 5 commits into from
Apr 10, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/en/docs/about/repository-overview/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 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/). |
dennismeister93 marked this conversation as resolved.
Show resolved Hide resolved
| [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 Data Broker. |
| [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. |
Expand Down
2 changes: 1 addition & 1 deletion content/en/docs/about/use_cases/seat_adjuster/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 data broker, 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_**.
Expand Down
22 changes: 11 additions & 11 deletions content/en/docs/concepts/development_model/val/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,15 @@ 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

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.

Expand All @@ -31,7 +31,7 @@ The image below shows the main components of the VAL and its relation to the [Ve

### KUKSA Data Broker (aka Vehicle Data Broker)

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 Data Broker](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.
Expand All @@ -45,8 +45,8 @@ Filter- and rule-based subscriptions of data points can be used to reduce the nu

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).

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.
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 data broker using its `Collector` gRPC interface.
The feeder automatically reconnects to the data broker in the event that the connection is lost.

Expand All @@ -61,7 +61,7 @@ The [KUKSA.VAL Services repository](https://github.com/eclipse/kuksa.val.service
### 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" >}}
Expand All @@ -73,7 +73,7 @@ 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).
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 data broker.

### Data flow when a _Vehicle App_ uses the KUKSA Data Broker
Expand All @@ -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 Data Broker](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

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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" ]
},
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ If a _Vehicle App_ provides a `grpc-interface` - a server stub embedded into the
{{<table "table table-bordered">}}
| 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.
Expand All @@ -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"
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.
dennismeister93 marked this conversation as resolved.
Show resolved Hide resolved

More information: [Vehicle Model Creation](/docs/tutorials/vehicle_model_creation/)

Expand Down
Loading
Loading