This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Vehicle App Runtime

Learn how to run the Vehicle App Runtime Services locally or in Kanto.

1 - Local Runtime

Learn how to run the Vehicle App Runtime Services locally.

Using tasks in Visual Studio Code

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 .

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.

Stop local runtime: To stop local runtime, a task called Local Runtime - Down is available. This task stops running runtime services gracefully. You can run this task by clicking F1 and choose Tasks: Run task, then select Local Runtime - Down.

Tasks Management: Visual Studio Code offers various other commands concerning tasks like Start/Terminate/Restart/… You can access them by pressing F1 and typing task. A list with available task commands will appear.

Logging: Running tasks appear in the Terminals View of Visual Studio Code. From there, you can see the logs of each running task. More detailed logs can be found inside your workspace’s logs directory ./logs/*

Add/Change runtime service configuration

The configuration for services of our provided local runtime are defined in the runtime.json at the root of the repository devenv-runtimes . For a more detailed view on how to change or add runtime service configuration, please visit: Lifecycle Management Package Development

Using KUKSA Databroker CLI

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

Integration of a new runtime service can be done by duplicating one of the existing tasks.

  • Create a new service in either a new created Package or branch/fork of devenv-runtimes as already explained above
  • In .vscode/tasks.json, duplicate section from task e.g. Local Runtime - Up, Local Runtime - Run VehicleApp or Local Runtime - VehicleDataBroker CLI
  • Correct names in a new code block
  • Disclaimer: Problem Matcher defined in tasks.json is a feature of the Visual Studio Code Task, to ensure that the process runs in background
  • Run task using [F1 -> Tasks: Run Task -> <Your new task label>]
  • Task should be visible in Terminal section of Visual Studio Code

Task CodeBlock helper

{
    "label": "<task_name>",
    "detail": "<task_description>",
    "type": "shell",
    "command": [
        "velocitas exec runtime-local <service_id> <args>"
    ],
    "presentation": {
        "close": true,
        "reveal": "never"
    },
    "problemMatcher": []
}

Troubleshooting

Problem description: When integrating new services into an existing dev environment, it is highly recommended to use the Visual Studio Code Task Feature. A new service can be easily started by calling it from bash script, however restarting the same service might lead to port conflicts (GRPC Port or APP port). That can be easily avoided by using the Visual Studio Code Task Feature.

Codespaces

If you are using Codespaces, remember that you are working on a remote agent. That’s why it could happen that the tasks are already running in the background. If that’s the case a new start of the tasks will fail, since the ports are already in use. Another possibility to check if the processes are already running, is to check which ports are already open. Check the Ports-tab to view all open ports (if not already open, hit F1 and enter View: Toggle Ports).

Next steps

2 - Kanto Runtime

Learn how to run the Vehicle App Runtime Services in Kanto.

Besides starting the vehicle runtime components locally , another way is to deploy them as containers using Kanto . To start the runtime, we provide VS Code Tasks, a feature of Visual Studio Code. Additional information on tasks can be found here .

Quick Start: Each step has a task that is defined in /.vscode/tasks.json:

  • Core tasks (dependent on each other in the given order):

    • Kanto - Runtime Up: Starts up the Kanto runtime and deploys the runtime components.
    • Kanto - Build VehicleApp: Builds the VehicleApp.
    • Kanto - Deploy VehicleApp: Deploys the VehicleApp as container in the Kanto runtime.

  • Optional helper tasks:

    • Kanto - Deploy VehicleApp (without rebuild): Deploys the VehicleApp as container in the Kanto runtime but does not build it upfront. That requires, that the task Kanto - Build VehicleApp has been executed once before.
    • Kanto - Runtime Down: Stops the Kanto runtime and all deployed containers.

Run as Bundle: To orchestrate these tasks, you can use the task Kanto - Deploy VehicleApp. This task runs the other tasks in the correct order. You can run this task by clicking F1 and choose Tasks: Run task, then select Kanto - Deploy VehicleApp.

Tasks Management: Visual Studio Code offers various other commands concerning tasks like Start/Terminate/Restart/… You can access them by pressing F1 and typing task. A list with available task commands will appear.

Logging: Running tasks appear in the Terminals View of Visual Studio Code. From there, you can see the logs of each running task. More detailed logs can be found inside your workspace’s logs directory ./logs/*

KantUI

The Leda team developed a tool to easily work with Kanto. It is similar to K9S for Kubernetes. You can find more details about KantUI in the documentation of Leda .

In the devcontainer KantUI is already installed and it can be started via:

sudo kantui

After starting the Kanto runtime with the mentioned tasks above, you will directly see all the running containers in KantUI. Now you could also take a look at the logs, delete or stop single containers. After you deployed your application to Kanto, this container will also show up and can be handled with KantUI.

Mounting folders for FeederCAN

Some applications (e.g. FeederCAN) might make it necessary to load custom files from a mounted volume. All the files that are located in [./config/feedercan](https://github.com/eclipse-velocitas/devenv-runtimes/tree/main/config/feedercan) will be automatically mounted into the container. In order to mount files to the directory that is accessible by the application, please refer to the deployment configuration file: runtime-kanto/src/runtime/deployment/feedercan.json .

Uploading custom candump file to FeederCAN

FeederCAN requires a candump file. A pre-defined candump file is already part of our delivery, however, if necessary, there is an option to upload a custom file by:

  1. Creating/updating candump file with the name candumpDefault.log in ./config/feedercan
  2. Restarting Kanto (execute the tasks Kanto - Runtime Down and Kanto - Runtime Up)

More information about the CAN Provider can be found here

Next steps