{"id":42019096,"url":"https://github.com/vectorgrp/ci-siltest-demo","last_synced_at":"2026-01-26T03:30:57.963Z","repository":{"id":248698404,"uuid":"745516186","full_name":"vectorgrp/ci-siltest-demo","owner":"vectorgrp","description":null,"archived":false,"fork":false,"pushed_at":"2026-01-21T05:50:42.000Z","size":2547,"stargazers_count":12,"open_issues_count":1,"forks_count":7,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-01-21T17:34:12.820Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/vectorgrp.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-01-19T14:02:47.000Z","updated_at":"2025-09-25T07:26:02.000Z","dependencies_parsed_at":"2024-12-23T14:25:41.046Z","dependency_job_id":"97d4084f-bc4d-4897-ae16-e5f9ffbc9984","html_url":"https://github.com/vectorgrp/ci-siltest-demo","commit_stats":null,"previous_names":["vectorgrp/ci-siltest-demo"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/vectorgrp/ci-siltest-demo","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vectorgrp%2Fci-siltest-demo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vectorgrp%2Fci-siltest-demo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vectorgrp%2Fci-siltest-demo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vectorgrp%2Fci-siltest-demo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/vectorgrp","download_url":"https://codeload.github.com/vectorgrp/ci-siltest-demo/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vectorgrp%2Fci-siltest-demo/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28765881,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-26T03:19:35.311Z","status":"ssl_error","status_checked_at":"2026-01-26T03:19:13.815Z","response_time":59,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-26T03:30:57.425Z","updated_at":"2026-01-26T03:30:57.957Z","avatar_url":"https://github.com/vectorgrp.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Vector CANoe CLI Toolchain \u0026 Continuous Testing Sample\n\nThis project shows an example how to implement an automated Software-in-the-Loop test workflow (SIL Test) for the development of an automotive ECU using the Vector toolchain, consisting of [MICROSAR Classic](https://www.vector.com/int/en/products/products-a-z/embedded-software/microsar/), [DaVinci Configurator](https://www.vector.com/int/en/products/products-a-z/software/davinci-configurator-classic/), [vVIRTUALtarget](https://www.vector.com/int/en/products/products-a-z/software/vvirtualtarget/) and [CANoe4SW Server Edition](https://www.vector.com/int/en/products/products-a-z/software/canoe4sw-server-edition/) (canoe4sw-se).\n\nThe core part of the automated SIL test approach is the use of text-based specification formats for simulation environments, allowing simulation environments to be constructed on a per-commit basis, thus supporting a branch/merge workflow with fast testing and change feedback of SIL-based system tests.\nFurthermore, the on-demand construction of simulation setups also allows test execution to scale with the amount of available compute resources, rather than being limited by the availability of human operators for integrating new versions of the System Under Test (SUT) into a simulation.\n\nThe intention of this repository is to serve as an example how such a system could be implemented as well as to be used as a starting point for implementing custom, project-specific test workflows.\n\n## Table of Contents\n\n- [Vector CANoe CLI Toolchain \\\u0026 Continuous Testing Sample](#vector-canoe-cli-toolchain--continuous-testing-sample)\n  - [Table of Contents](#table-of-contents)\n  - [Introduction](#introduction)\n  - [Overview](#overview)\n  - [Repository Layout](#repository-layout)\n  - [Implementation Example Using the Vector CLI Toolchain](#implementation-example-using-the-vector-cli-toolchain)\n    - [Workflow Elements explained:](#workflow-elements-explained)\n      - [Jobs and Steps:](#jobs-and-steps)\n    - [Virutal ECU Generation](#virutal-ecu-generation)\n    - [Simulation Enviromment \\\u0026 Test Unit Compilation](#simulation-enviromment--test-unit-compilation)\n    - [Run the Simulation \\\u0026 Execute the Test Units](#run-the-simulation--execute-the-test-units)\n    - [Test Result Visualization](#test-result-visualization)\n  - [Deploying as a GitHub Action Pipeline](#deploying-as-a-github-action-pipeline)\n    - [Vector Tools Execution in Containers](#vector-tools-execution-in-containers)\n    - [Caching Implementation](#caching-implementation)\n    - [Passing Artifacts](#passing-artifacts)\n  - [Trigger the pipeline](#trigger-the-pipeline)\n  - [View the pipeline](#view-the-pipeline)\n\n## Introduction\n\nCI / CT solutions are key to develop and provide fast and reliable software solutions. By combining the work of the whole team in one repository and automatically test the changes, CI / CT provides fast testing and change feedback.\nThis repository should give you a peek of how to setup a Continuous Test (CT) environment with CANoe4SW Server Edition for vVIRTUALtarget ECUs. Starting with the changes of C code for an ECU, we are triggering the whole compilation and testing process of the virtual ECU. Test reports will show you if your changes broke some tests or functionality of your ECU.\n\nIn this demo repository, you can take action, by editing the C files under [/ECU/Appl/](/ECU/Appl/) to trigger the attached CI pipeline and see the involved Vector tools in action.\nAfterwards you can observe the test results.\n\n## Overview\n\n\u003cimg src=\"doc/resources/images/OnPullRequest.svg\" width=300 align=\"right\"\u003e\n\nThe \"LightControl\" ECU in this example implements an automatic control of the low beams of a car.\nIt is implemented as an AUTOSAR SWC running on top of Vector MICROSAR Classic.\n\nTo facilitate the development of this ECU, the development organization performs large parts of their system testing as SIL tests using a virtual ECU.\nThe virtual ECU is built using Vector `vVIRTUALtarget`.\nThe ECU is integrated in a CANoe4SW Server Edition simulation environment with remaining bus simulation.\nIn this simulation environment the system test cases are implemented using CAPL and organized in YAML-based format.\nThese test cases can be efficiently created and managed through our [`Vector Test Unit` Visual Studio Code plugin](https://marketplace.visualstudio.com/items?itemName=VectorGroup.test-unit).\n\nFor an ideal integration into the development workflow, the test workflow as depicted below is set up to run automatically whenever a pull request is opened on the repository.\nPull requests may contain changes to the ECU source code, the ECU BSW configuration, the test cases, and the simulation setup.\nThe test workflow consists of three stages: Rebuilding the SUT, simulation and test cases, running the simulations, and preparing the test results for display in the Web UI.\nRebuilding all parts of the simulation ensures that the test run considers exactly the changes provided in the given pull request, independent of any other changes that may be tested in parallel in concurrent pull requests.\n\nsee below for an example pull request with an execution of the test workflow.\n\n\u003cimg src=\"doc/resources/images/PR_Disconnected_Sensor.PNG\"\u003e\n\nWe will explain the individual steps of the test workflow in more detail in subsequent sections.\n\n\u003cbr clear=\"right\"\u003e\n\n\n## Repository Layout\n\n- [environment-make folder](/environment-make/) contains all files to run environment-make. Most importantly the `venvironment.yaml` file, which describes the `CANoe4SW Server Edition` setup.\n- [doc folder](/doc/) contains documentation and additional infos.\n- [ECU folder](/ECU/) contains the source code for the virtual ECU, which gets tested in this demo pipeline.\n- [test folder](/test) contains the CAPL test cases along with their yaml format test that defines them\n\n\nThe pipeline file is located [here](/.github/workflows/main.yaml)\n\n## Implementation Example Using the Vector CLI Toolchain\n\nVector offers its suite of tools in a CLI toolchain format for streamlined automated operations, along with configuration formats following the everything-as-code philosophy.\nIn this section we will explain the steps involved in the test pipeline and how to use the Vector CLI toolchain in these steps.\n\nIf you are already familiar with the CLI toolchain and are just looking for sample configurations, see [CANoe simulation environment](environment-make/venvironment.yaml), [VttMake configuration](ECU/LightControl.vttmake), [GitHub Action Workflow](.github/workflows/main.yaml)\n\nThe overall test workflow consists of three stages:\n* The Build stage, where the SUT, the environment and the test units are rebuilt from source.\n* The Simulate stage, where test units are executed in the simulated environment.\n* The Display stage, where test results are converted for further processing, e.g., display in a Web UI dashboard.\n\nThe following image gives a detailed view of the steps on the test execution stages, the tools used in each stage as well as the input artifacts and output artifacts. The following subsections will provide more details on the implementation of each stage.\n\n\u003cimg src=\"doc/resources/images/Workflow_Overview.png\" align=\"right\"\u003e\n\n### Workflow Elements explained:\nHere's the main elements of the following workflow [GitHub Action Workflow](.github/workflows/).\n\n#### Jobs and Steps:\n\n- **Build SUT**: Checks out the repository, utilizes caching to optimize the build process, and prepares the System Under Test (SUT) by rebuilding it from source.\n\n- **Compile Simulation**: With the SUT prepared, the environment and tests are compiled. This job fetches the SUT and test case inputs that are needed for the compiler.\n\n- **Run Simulation**: After having a compiled environment and test cases. This job will execute these testcases against the environment and provide a test result.\n\n- **Display Test Report**: The final stage involves processing and displaying the test results. It fetches the results from the simulation, converts them into a format suitable for display, and then presents them on a Web UI dashboard. This allows for an easy review and analysis of the test outcomes.\n\n- **Artifact Management**: Throughout the process, artifacts such as the compiled SUT, test cases, and test results are managed efficiently. They are used to pass outputs between jobs, ensuring that each step of the pipeline has access to the necessary inputs and outputs without redundant operations.\n\n### Virutal ECU Generation\n\n\n\u003cimg src=\"doc/resources/images/Build_SUT.PNG\" alt=\"drawing\"\u003e\n\nThe first step in the test workflow is to build the ECU SWC source code and ECU BSW/RTE configuration into a virutal ECU.\nThis is done using the `VttMake.exe` CLI executable of `vVIRTUALtarget`.\n`VttMake.exe` takes as input an XML file [`LightControl.vttmake`](ECU/LightControl.vttmake).\nWhile being an XML file, the syntax of the `.vttmake` file format is designed to be so simple that it can be edited with any text editor.\nThe `.vttmake` file tells `vVIRTUALtarget` where to find the ECU project with the BSW configuration (Line 5) and points to the SWC implementation files (Lines 12-24).\nFurthermore, it tells `vVIRTUALtarget` which compiler is used for building the ECU, so that the glue code between the BSW and the simulation tool and the build configuration can be generated accordingly.\n`VttMake.exe` can also launch `DaVinci Configurator` to generate the BSW and RTE source code. That also calls the configured compiler to compile the virtual ECU.\n\nYou can find all input artifacts for this job in the [ECU folder](ECU/).\nThe most notable output artifacts are the `ECU.dll`, the DLL containing the executable code for the virtual ECU, along with several files containing metadata for the DLL, all of which will be later loaded into the CANoe simulation.\n\n### Simulation Enviromment \u0026 Test Unit Compilation\n\n\u003cimg src=\"doc/resources/images/Build_Simulation.png\" alt=\"drawing\"\u003e\n\nThe ECU configuration assumes a certain operation environment.\nIn the example, the LightControl ECU expects a connection to a CAN bus with other ECUs present to get sensor readings from and to send actuation commands to.\nTo provide this environment in the SIL Test, a CANoe remaining bus simulation is used that mocks the communication of other ECUs surrounding the LightControl ECU.\n\nThe simulation environment is defined in [`venvironment.yaml`](environment-make/venvironment.yaml), which can be created with the assistance of a Visual Studio Code plugin [Simulation and Test Environment](https://marketplace.visualstudio.com/items?itemName=VectorGroup.simulation-and-test-environment). This file defines the communication networks (Line 11), the communication description for these networks (Line 7) as well as the simulation participants.\nLines 27-35 integrated the previously created virtual ECU, whereas lines 17 onwards and Lines 37 and onwards define two mocked ECUs.\nThe mocked ECUs are implemented using CAPL.\nTheir implementation is also [available in this repository](environment-make/CAPL/).\n\nThe simulation definition in `venvironment.yaml` is designed to be written by hand using any YAML-capable editor.\nIt is then read by the `environment-make` tool.\n`environment-make` gathers all input artifacts parts of the simulation (network databases, CAPL code, virtual ECUs) and compiles them into a simulation environment, suitable for execution by CANoe4SW Server Edition.\n\nStatic input artifacts to creating the simulation environment are stored in [`environment-make` folder](/environment-make/).\nThe only input artifact that is not static is the virtual ECU.\nIt is collected from the [`Virtual ECU Generation` step](#virutal-ecu-generation) using the artifact handling capabilities of GitHub.\nThe output artifact of this step is the simulation environment folder `environment-make/Default.venvironment`.\n\nNext, the tests for execution in `CANoe4SW Server Edition` are implemented as test units in Visual Studio Code using Vector provided plugins, they can be defined in yaml format, for example as in [auto.vtestunit.yaml](tests/auto/auto.vtestunit.yaml).\nOnce the tests are prepared, the compilation of the test is done by running the `test-unit-make` tool, providing it with the location of the simulation environment as well as the location of the `.vtestunit.yaml` files created previously.\n`test-unit-make` does not have a control file, it takes all of its configuration as command line parameters.\n\nThe output artifacts of the compiled tests are generated as `.vtestunit` files and they are located in the environment folder as well `environment-make`, each test unit will have its own folder in this directory.\n\n### Run the Simulation \u0026 Execute the Test Units\n\n\u003cimg src=\"doc/resources/images/Run-Simulation.svg\" alt=\"drawing\"\u003e\n\nOnce all parts of the simulation and the test units are prepared, `CANoe4SW Server Edition` is run to execute the simulation.\n`CANoe4SW Server Edition` simply reads the simulation environment and the test cases to execute in that environment from the command line.\n`CANoe4SW Server Edition` will start the simulation automatically after is launch. It also automatically starts executing all test units that were specified by command line.\nWhen test execution has finished, the simulation is stopped.\nA brief information on the test results is given as part of the command line output.\nThe exit code of the `CANoe4SW Server Edition` executable also indicates a test success or test failure.\nFor more detailed information, a standard `.vtestreport` file is produced for every test unit that was executed.\nThe `.vtestreport` can be stored as a build artifact for later review.\n\nNote that not all test units for a given simulation environment have to be given to `CANoe4SW Server Edition` at once.\nTest units can be split across multiple parallel `CANoe4SW Server Edition` executions, allowing for parallel execution on multiple runner instances of an automated test system.\nThis project makes use of the feature of Matrix Jobs to spawn independent simulation runs for every single test unit, thus parallelizing test execution, so long as there are sufficient compute resources available.\n\nInput artifacts to this step are the `Default.venvironment` folder as well as the respective test units folder.\nThe output artifact is one `.vtestreport` file per test unit provided to CANoe4SW Server Edition.\nEach `.vtestreport` file is named after the corresponding test unit.\n\n### Test Result Visualization\n\n\u003cimg src=\"doc/resources/images/ReportViewer.png\" alt=\"drawing\"\u003e\n\nThe output of `CANoe4SW Server Edition` can be used to give an overall idea of test success/test failure of the provided state of the repository.\nHowever, in many cases it is necessary to have more in-depth information on which test cases passed or failed, e.g. to compute statistics on test success or to identify tests that are currently accepted to fail and should thus not impact the test verdict.\n\nTo this end, Vector Test Report Viewer provides the commandline tool `ReportViewerCLI` which can be used to export each `.vtestreport` file to XUnit format that can be conmsumed by other tools.\nAs part of this sample, the XUnit result is displayed in the Web UI.\n\nThe input artifacts to this step are the `.vtestreport` files produced by the `CANoe4SW Server Edition` simulation runs.\nThe output artifacts are `_xunit.xml` files.\n\nNote that `.vtestreport` files can be processed independently of one another.\nThus, this step can also be parallelized if the need arises.\n\n## Deploying as a GitHub Action Pipeline\n\n### Vector Tools Execution in Containers\n\n- **Containerized Execution**: Vector tools run within Docker containers, ensuring consistent, isolated environments for each test run, facilitating replicable tests and simulations.\n- **Dockerfiles Location**: Required Dockerfiles for setting up these containers are located under a default installation path, like `C:\\Users\\Public\\Documents\\Vector\\CANoe4SW Server Edition\\17 (x64)\\Samples\\` when `CANoe4SW Server Edition` is installed. These files configure the necessary environments for Vector tools.\n\n### Caching Implementation\n\n- **Efficiency Through Caching**: The workflow utilizes caching for the SUT and BSW components, enhancing efficiency by reducing build times and conserving resources.\n- **Caching Strategy**: Utilizes GitHub Actions' `cache@v4` action to cache specific directories, with cache keys based on file hashes to detect changes and ensure that only modified components are rebuilt.\n\n### Passing Artifacts\n\n- **Artifact Sharing Between Jobs**: Compiled components, such as the SUT and simulation environments, are efficiently passed between jobs using GitHub Actions' artifact management features.\n- **Artifact Retention**: Artifacts are set with retention policies (e.g., 7 days) to be available as needed without consuming unnecessary storage.\n\n## Trigger the pipeline\n\nThere are two ways, on how to trigger the pipeline. The first and easy way, is to use the GitHub provided web editor.\nThe second one is to use the git command-line tool. For this option, follow the instructions [here](/doc/trigger-with-git.md)\n\nTo trigger the pipeline, using the web editor, do the following steps:\n\n1. Go to the file you want to edit. For example [ECU/Appl/Source/LightCtrl_SWC.c](/ECU/Appl/Source/LightCtrl_SWC.c)\n\n2. On the top right, there is a button called `Edit this file`. Press it to be able to edit the file.\n\n3. Do the changes and additions to the file you like.\n    E.g.:\n    Uncomment line 59 (`//rtb_LightIntensity_LightIntensi = 0;`) in the source code [LightCtrl_SWC.c](/ECU/Appl/Source/LightCtrl_SWC.c) to cause test fails.\n    Info: Some tests will set the light intensity value and expect a changed head light result. Because the light intensity is now statically set to value zero, some tests will fail.\n\n4. On the top right of the page, is an entry box, to commit the changes `Commit changes...`. It will prompt you to give a commit message as well as an option to create a separate branch out of your commit. Select Creating a new branch and write in text there as you like, and afterwards click the `Propose changes` button.\n\n5. Click on `Create pull request` button to attempt to merge your changes with the main branch thus triggering the pipeline automatically\n\n## View the pipeline\n\nTo see the pipeline working and the CANoe4SW Server Edition Test Report:\n\n```text\n Click \"Actions\" on the top. -\u003e\n Choose the most recent workflow run \"passed\" or \"failed\". -\u003e\n Click on the last job \"CANoe4SW_SE Tests\" listed on the left side bar. -\u003e\n View the test results.\n\n```\n\nFor an image based guide, [click here](/doc/view-pipeline-and-tests.md)\u003c/br\u003e\nMore details about the functionality of Vector Tools inside the pipeline can be viewed [here](/doc/pipeline.md).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvectorgrp%2Fci-siltest-demo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvectorgrp%2Fci-siltest-demo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvectorgrp%2Fci-siltest-demo/lists"}