From d86022982fbb945f765f23dd9f71009dd070e7fb Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Wed, 29 Jul 2026 09:42:53 +0200 Subject: [PATCH 01/14] change code coverage --- .../development/cpp/code_analysis.rst | 33 +++++++++++++------ 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/docs/contribute/development/cpp/code_analysis.rst b/docs/contribute/development/cpp/code_analysis.rst index 0a9e879a137..14904f9bf7f 100644 --- a/docs/contribute/development/cpp/code_analysis.rst +++ b/docs/contribute/development/cpp/code_analysis.rst @@ -102,13 +102,14 @@ Adress/ Leak Sanitizer (ASAN/LSAN) If both tools are combined at runtime memory leaks and the corresponding address can be investigated. -Coverage -======== +Code Coverage +============= -As required by the verification guideline coverage needs to be calculated for the code which is used in the project. Therefore two approaches should be available: +As required by the verification guideline code coverage needs to be calculated for the code which is used in the project. Coverage is calculated on the host using LLVM's source-based coverage: -* As a quick solution it is possible to calculate the coverage on the host via gcc. -* But for a more accurate statement coverage can also be calculated with the qcc compiler with the appropriate libraries and POSIX interfaces. This method will also be used for the reporting. +* Coverage is calculated on the host via clang/llvm. This method is also used for the reporting. + +Since ``qcc`` does not support LLVM's source-based coverage instrumentation, coverage is not collected on the QNX target. LLVM's source-based coverage natively supports MC/DC, which is required for the higher ASIL levels. To enable this, following tools are used: @@ -116,11 +117,23 @@ To enable this, following tools are used: object "Coverage" as coverage object "gtest" as gtest - object "gcov + gcovr" as gcov + object "llvm-cov + llvm-profdata" as llvm object "host" as host - object "QNX" as qnx coverage --> gtest - gtest --> gcov - gcov --> host - gcov --> qnx + gtest --> llvm + llvm --> host + +Argumentation: Host-based Coverage with Target Test Execution +------------------------------------------------------------ + +Measuring code coverage exclusively on the **Linux host** (via LLVM) is considered sufficient for safety certification, provided that a **two-step verification** is performed to demonstrate equivalence on the target: + +#. **Quantitative Verification (Host):** The complete test suite is executed on the Linux host with code coverage enabled. This demonstrates that the test cases are structurally complete (100% C0/C1 coverage) and that no dead code exists. +#. **Qualitative Verification (Target):** The identical test suite is executed on the **QNX target**, but with code coverage instrumentation turned off. This demonstrates that the software compiles, links, and behaves identically on the real target hardware (correctness of execution, no compiler/linker optimization bugs, no endianness or memory alignment issues). + +This approach satisfies *ISO 26262-6* for *ASIL_B* for the following reasons: + +* **Identical Test Results:** Passing 100% of the tests on both the host and the target demonstrates that the control flow under test is identical. +* **Mitigation of Target Instrumentation Risks:** Turning off coverage instrumentation on the target is recommended for embedded systems, as active instrumentation alters the timing behavior, memory footprint, and compiler optimizations on the target. Testing the uninstrumented code on QNX ensures that the actual production binary is verified (mitigating "Heisenbugs"). +* **Equivalence Justification:** The host-based coverage measurement is justified by confirming that no platform-specific code paths (e.g., ``#ifdef QNX`` blocks) are bypassed. Any target-specific hardware abstraction layer (HAL) is verified separately via system-level integration tests. From 090cc477a23f6eedad0432cc0e543b2b856a1af6 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Wed, 29 Jul 2026 09:59:41 +0200 Subject: [PATCH 02/14] fix build warning --- docs/contribute/development/cpp/code_analysis.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contribute/development/cpp/code_analysis.rst b/docs/contribute/development/cpp/code_analysis.rst index 14904f9bf7f..008c2b0339b 100644 --- a/docs/contribute/development/cpp/code_analysis.rst +++ b/docs/contribute/development/cpp/code_analysis.rst @@ -125,7 +125,7 @@ To enable this, following tools are used: llvm --> host Argumentation: Host-based Coverage with Target Test Execution ------------------------------------------------------------- +------------------------------------------------------------- Measuring code coverage exclusively on the **Linux host** (via LLVM) is considered sufficient for safety certification, provided that a **two-step verification** is performed to demonstrate equivalence on the target: From d06079b55d5b085f4487579c23e4912400bc4c6e Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Wed, 29 Jul 2026 13:28:10 +0200 Subject: [PATCH 03/14] add explanation for change --- .../development/cpp/code_analysis.rst | 54 ++++++++++++++++++- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/docs/contribute/development/cpp/code_analysis.rst b/docs/contribute/development/cpp/code_analysis.rst index 008c2b0339b..637bfec87f0 100644 --- a/docs/contribute/development/cpp/code_analysis.rst +++ b/docs/contribute/development/cpp/code_analysis.rst @@ -111,6 +111,11 @@ As required by the verification guideline code coverage needs to be calculated f Since ``qcc`` does not support LLVM's source-based coverage instrumentation, coverage is not collected on the QNX target. LLVM's source-based coverage natively supports MC/DC, which is required for the higher ASIL levels. +LLVM's source-based coverage is preferred over ``gcov``-based coverage for the following reasons: + +* **Precision with templates, generics and modern C++:** ``gcov`` is line-based, so with heavy templating, inlining and macros the mapping is coarse and multiple template instantiations collapse onto the same lines, producing imprecise or misleading results. LLVM's source-based coverage is region- and instantiation-based and therefore significantly more accurate for modern C++. +* **MC/DC support:** ``gcov`` historically provided no MC/DC support (GCC offers it only from GCC 14 via ``-fcondition-coverage``), whereas LLVM/clang supports MC/DC natively (``-fcoverage-mcdc``), which is required for the higher ASIL levels. + To enable this, following tools are used: .. needuml:: @@ -135,5 +140,50 @@ Measuring code coverage exclusively on the **Linux host** (via LLVM) is consider This approach satisfies *ISO 26262-6* for *ASIL_B* for the following reasons: * **Identical Test Results:** Passing 100% of the tests on both the host and the target demonstrates that the control flow under test is identical. -* **Mitigation of Target Instrumentation Risks:** Turning off coverage instrumentation on the target is recommended for embedded systems, as active instrumentation alters the timing behavior, memory footprint, and compiler optimizations on the target. Testing the uninstrumented code on QNX ensures that the actual production binary is verified (mitigating "Heisenbugs"). -* **Equivalence Justification:** The host-based coverage measurement is justified by confirming that no platform-specific code paths (e.g., ``#ifdef QNX`` blocks) are bypassed. Any target-specific hardware abstraction layer (HAL) is verified separately via system-level integration tests. +* **Mitigation of Target Instrumentation Risks:** The two-step verification deliberately splits the two concerns onto the environment best suited for each: the **host run is instrumented** (to measure structural coverage), and the **target run is uninstrumented** (to confirm the tests still pass on the real production binary). This is the same "measure coverage with instrumentation, then re-run without instrumentation to confirm behaviour" pattern applied across two environments. Running uninstrumented on QNX matters because active instrumentation alters timing behaviour, memory footprint and compiler optimizations on embedded targets (mitigating "Heisenbugs"). Note that ``qcc`` cannot produce LLVM source-based coverage, so an *instrumented* coverage run on the target is not an available option. +* **Equivalence Justification:** The host-based coverage measurement is justified by confirming that no platform-specific code paths (e.g., ``#ifdef QNX`` blocks) or QNX-only source files are silently bypassed by the host measurement. The reconciliation strategy for such code, and the process a developer uses to identify it, is described in `Handling Platform-Specific Code`_ below. Any target-specific hardware abstraction layer (HAL) is additionally verified via system-level integration tests. + +Handling Platform-Specific Code +------------------------------- + +Because structural coverage is measured on the **Linux host** while the QNX target is only tested for pass/fail, the coverage *baseline* (the set of source files and lines expected to be covered) differs between the two environments. Code that is strictly platform-specific therefore needs an explicit reconciliation strategy so that it neither skews the release metrics nor becomes unverified "dead" code in the safety case. + +Three cases are distinguished. + +Linux-only code (mocks, emulation, host utilities) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This code is compiled and executed only on the host and is absent on the QNX target. It must not contribute to the ASIL-B production coverage figures. + +* Linux-only helper code and mocks are kept structurally separate from production code (e.g. under dedicated ``mock/`` or ``test/`` directories) and are classified as Quality Managed (QM) / test-support code. +* Such directories are excluded when the coverage report is generated, so this code is not part of the ASIL-B production coverage baseline and cannot inflate or deflate the reported figures. + +QNX-only code inside mixed files (conditional compilation) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For files that are compiled on the host but contain small target-specific blocks (e.g. guarded by ``#ifdef __QNX__``), those blocks are not compiled into the host binary and would otherwise appear as non-covered or non-existent regions. + +* These target-only regions are marked with standardized coverage-exclusion markers understood by the coverage report generator, together with a justification stating that the region is executed and verified on the QNX target rather than on the host. +* The applicable exclusion markers and their justification format are governed centrally (rather than chosen per developer) so that exclusions remain auditable and consistent across repositories. + +.. note:: + + The exclusion-marker syntax must match the coverage tooling actually in use. Because coverage in S-CORE is produced by **LLVM source-based coverage** (``llvm-cov`` / ``llvm-profdata``), the marker mechanism supported by that toolchain (line/region exclusion) must be used; ``lcov``/``gcov`` ``LCOV_EXCL_*`` markers are *not* interpreted natively by ``llvm-cov`` and must not be assumed to work unless an ``lcov`` conversion/merge step is explicitly part of the pipeline. + +QNX-only files excluded from the host build +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Some modules or files are compiled **only** for QNX and cannot be built on the host at all (e.g. sources that call QNX-specific OS APIs). These would report 0% coverage in a host-only measurement. + +* Such files are excluded from the **host structural-coverage baseline**, so they do not produce misleading false-negative 0% figures. +* Because ``qcc`` cannot produce LLVM source-based coverage, **no structural coverage can be obtained for these files**. This is a *justified deviation* from the unit-level structural-coverage objective, not a claim of equivalence: the residual risk is that unit-level statement/branch coverage evidence does not exist for this code. +* The deviation is compensated by verifying these files **on the QNX target** through requirements-based integration tests executed on the real hardware, and by arguing the safety case on the basis of a 100% pass rate of the associated functional requirements. Each such file/module and its compensating verification is recorded so the deviation is traceable and reviewable. + +Identifying platform-specific code +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A developer must be able to determine which code falls into the categories above; this cannot rely on manually reading source for ``#ifdef`` guards, because whole files may be excluded from the host build. The following mechanisms are used: + +* **Build-set comparison:** The set of source files compiled for the host is compared against the set compiled for the QNX target. Files present only in the QNX build are, by construction, the "QNX-only files" case and are flagged automatically. +* **Explicit exclusion manifest:** Every host-coverage exclusion (whether a per-file exclusion or a within-file region marker) is recorded in a reviewable list, so the complete delta between the host coverage baseline and the full target code base is visible in one place rather than scattered across the sources. +* **CI gate:** The comparison and the manifest are checked in CI, so newly added QNX-only files or new conditional blocks that are not accompanied by a documented exclusion and a compensating target verification cause the quality gate to fail. From 109209462d48dfe2bfe5c62b8862658bf9dac8e3 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 10:33:56 +0200 Subject: [PATCH 04/14] add also llvmcov at other places and add tool evaluation --- .../development/cpp/code_analysis.rst | 9 +- docs/design_decisions/DR-001-infra.md | 2 +- .../software_verification.rst | 8 +- .../score_tools_evaluation_list.rst | 14 +- .../_assets/clang-instrumentation.drawio.svg | 349 ++++++++++++++++++ .../tools_compiler/_assets/clang.drawio.svg | 216 +++++++++++ .../_assets/gcc-instrumentation.drawio.svg | 4 +- .../_assets/qcc-instrumentation.drawio.svg | 4 +- docs/score_tools/tools_compiler/clang.rst | 206 +++++++++++ docs/score_tools/tools_compiler/gcc.rst | 3 + docs/score_tools/tools_compiler/index.rst | 1 + ubproject.toml | 282 ++++++++++++++ 12 files changed, 1083 insertions(+), 15 deletions(-) create mode 100644 docs/score_tools/tools_compiler/_assets/clang-instrumentation.drawio.svg create mode 100644 docs/score_tools/tools_compiler/_assets/clang.drawio.svg create mode 100644 docs/score_tools/tools_compiler/clang.rst create mode 100644 ubproject.toml diff --git a/docs/contribute/development/cpp/code_analysis.rst b/docs/contribute/development/cpp/code_analysis.rst index 637bfec87f0..de048865949 100644 --- a/docs/contribute/development/cpp/code_analysis.rst +++ b/docs/contribute/development/cpp/code_analysis.rst @@ -109,12 +109,15 @@ As required by the verification guideline code coverage needs to be calculated f * Coverage is calculated on the host via clang/llvm. This method is also used for the reporting. +In Bazel-based development, this does not imply that every build uses the same compiler configuration. Normal host builds may use the default host compiler/toolchain, while coverage builds select a dedicated host configuration with LLVM source-based instrumentation enabled. The resulting raw profiles are merged with ``llvm-profdata`` and evaluated with ``llvm-cov``. + Since ``qcc`` does not support LLVM's source-based coverage instrumentation, coverage is not collected on the QNX target. LLVM's source-based coverage natively supports MC/DC, which is required for the higher ASIL levels. LLVM's source-based coverage is preferred over ``gcov``-based coverage for the following reasons: -* **Precision with templates, generics and modern C++:** ``gcov`` is line-based, so with heavy templating, inlining and macros the mapping is coarse and multiple template instantiations collapse onto the same lines, producing imprecise or misleading results. LLVM's source-based coverage is region- and instantiation-based and therefore significantly more accurate for modern C++. -* **MC/DC support:** ``gcov`` historically provided no MC/DC support (GCC offers it only from GCC 14 via ``-fcondition-coverage``), whereas LLVM/clang supports MC/DC natively (``-fcoverage-mcdc``), which is required for the higher ASIL levels. + +* **Precision with templates, generics and modern C++:** legacy GCC line-based coverage ``gcov`` is line-oriented, so with heavy templating, inlining and macros the mapping is coarse and multiple template instantiations collapse onto the same lines, producing imprecise or misleading results. LLVM's source-based coverage is region- and instantiation-based and therefore significantly more accurate for modern C++. +* **MC/DC support:** LLVM/clang supports MC/DC natively (``-fcoverage-mcdc``), which is required for the higher ASIL levels. To enable this, following tools are used: @@ -168,7 +171,7 @@ For files that are compiled on the host but contain small target-specific blocks .. note:: - The exclusion-marker syntax must match the coverage tooling actually in use. Because coverage in S-CORE is produced by **LLVM source-based coverage** (``llvm-cov`` / ``llvm-profdata``), the marker mechanism supported by that toolchain (line/region exclusion) must be used; ``lcov``/``gcov`` ``LCOV_EXCL_*`` markers are *not* interpreted natively by ``llvm-cov`` and must not be assumed to work unless an ``lcov`` conversion/merge step is explicitly part of the pipeline. + The exclusion-marker syntax must match the coverage tooling actually in use. Because coverage in S-CORE is produced by **LLVM source-based coverage** (``llvm-cov`` / ``llvm-profdata``), the marker mechanism supported by that toolchain (line/region exclusion) must be used; ``LCOV_EXCL_*`` markers from lcov/GCC workflows are *not* interpreted natively by ``llvm-cov`` and must not be assumed to work unless an ``lcov`` conversion/merge step is explicitly part of the pipeline. QNX-only files excluded from the host build ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/design_decisions/DR-001-infra.md b/docs/design_decisions/DR-001-infra.md index 60b4f827d02..64784a617c5 100644 --- a/docs/design_decisions/DR-001-infra.md +++ b/docs/design_decisions/DR-001-infra.md @@ -167,7 +167,7 @@ _Provided via devcontainer_ - `buildifier`, `bazel-compile-commands` - `curl`, `qemu-system-aarch64`, `sshpass` (??) - `protoc` -- `gcovr` +- `llvm-cov`, `llvm-profdata` **Not Natively Cacheable in Bazel** _Provided via devcontainer_ diff --git a/docs/platform_management_plan/software_verification.rst b/docs/platform_management_plan/software_verification.rst index a887ac8d669..656cee7af48 100644 --- a/docs/platform_management_plan/software_verification.rst +++ b/docs/platform_management_plan/software_verification.rst @@ -547,10 +547,10 @@ components, documentation, and automated tests. The software components of the project written in C++ are unit tested with the help of `GoogleTest `__. -.. rubric:: gcov/gcovr +.. rubric:: Code Coverage (llvm-cov/llvm-profdata) -For C++ code the structural coverage reached by unit testing in the project is evaluated by the gcov/gcovr tool chain -`gcovr `__ - gcov is part of the GNU compiler collection (gcc). +For C++ code the structural coverage reached by unit testing in the project is evaluated by the llvm-cov/llvm-profdata tool chain +`llvm-cov `__ and `llvm-profdata `__ are part of the LLVM toolchain. The C++ unit test tooling supports several coverage metrics: @@ -558,7 +558,7 @@ The C++ unit test tooling supports several coverage metrics: - "branch" - used in S-CORE for the ``structural-branch-coverage`` method - "function" - used in S-CORE for the ``structural-function-coverage`` as additional supporting coverage value for further analysis. -Note gcov/gcovr are not applicable for Rust code. Here coverage values are created using the tooling provided by the Ferrocene. +Note: Rust coverage evidence in S-CORE is primarily generated via Rust/Ferrocene tooling. llvm-cov/llvm-profdata may be used in dedicated host-based LLVM workflows, but this is not the default Rust coverage reporting path. .. rubric:: Integration Testing Framework (ITF) diff --git a/docs/score_tools/score_tools_evaluation_list.rst b/docs/score_tools/score_tools_evaluation_list.rst index 59ceebb966e..d5fef7a0755 100644 --- a/docs/score_tools/score_tools_evaluation_list.rst +++ b/docs/score_tools/score_tools_evaluation_list.rst @@ -179,12 +179,12 @@ release, as part of the Tool Verification Report. - N/A - YES * - 2a-5 - - gcovr - - Code coverage tool (uses gcov from GCC), part of GNU compiler collection + - llvm-cov + llvm-profdata + - Source-based code coverage toolchain from LLVM - T.B.D. (see [1]_) - YES - :need:`rl__infrastructure_tooling_community` - - N/A + - :need:`doc_tool__clang` - YES @@ -547,6 +547,14 @@ release, as part of the Tool Verification Report. - :need:`rl__infrastructure_tooling_community` - :need:`doc_tool__qcc` - N/A + * - 5a-3 + - Clang + - Host C++ compiler used for LLVM source-based coverage instrumentation and reporting workflows + - 19.x (see [1]_) + - YES + - :need:`rl__infrastructure_tooling_community` + - :need:`doc_tool__clang` + - YES 5b Rust Compiler diff --git a/docs/score_tools/tools_compiler/_assets/clang-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/clang-instrumentation.drawio.svg new file mode 100644 index 00000000000..8910bd09d61 --- /dev/null +++ b/docs/score_tools/tools_compiler/_assets/clang-instrumentation.drawio.svg @@ -0,0 +1,349 @@ + + + + + + + + + + + +
+
+
+ Instrumented +
+ binary +
+
+
+
+ + + Instrumented... + + + + + + + + + + + + + +
+
+
+
+ + Software + +
+
+ + sources (C++) + +
+
+
+
+ + + Software... + + + + + + + + + + + + + + + +
+
+
+ + clang / llvm_cov + +
+
+
+ + + clang / llvm_cov + + + + + + + + + + + + + + + + + +
+
+
+
+ Test + + sources (C++) + +
+
+
+
+ + + Test sources (C++) + + + + + + + + + + + + + +
+
+
+
+ Configuration +
+
+
+
+ + + Configuration + + + + + + + + + + + + + + + +
+
+
+ Build log +
+
+
+ + + Build log + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ + Dependencies + +
+
+
+ + + Dependencies + + + + + + + + + + + + + + + +
+
+
+ Coverage data +
+ (*.profraw) +
+
+
+
+ + + Coverage data... + + + + + + + + + + + + + + + +
+
+
+ llvm-profdata +
+
+
+ + + llvm-profdata + + + + + + + + + + + + + + + +
+
+
+ llvm-cov +
+
+
+ + + llvm-cov + + + + + + + + + + + + + + + +
+
+
+ Coverage data +
+ (*.profdata) +
+
+
+
+ + + Coverage data... + + + + + + + + + + + + + + + +
+
+
+ Coverage data +
+ (Text/JSON/HTML/LCOV-export) +
+
+
+ + + Coverage data... + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/score_tools/tools_compiler/_assets/clang.drawio.svg b/docs/score_tools/tools_compiler/_assets/clang.drawio.svg new file mode 100644 index 00000000000..b06b756282b --- /dev/null +++ b/docs/score_tools/tools_compiler/_assets/clang.drawio.svg @@ -0,0 +1,216 @@ + + + + + + + + + + + +
+
+
+ Binary +
+
+
+ + + Binary + + + + + + + + + + + + + +
+
+
+
+ + Software + +
+
+ + sources (C++) + +
+
+
+
+ + + Software... + + + + + + + + + + + + + + + +
+
+
+ + clang + +
+
+
+ + + clang + + + + + + + + + + + + + +
+
+
+ + + Object files + + +
+
+
+ + + Object files + + + + + + + + + + + + + + + + + +
+
+
+
+ Dependencies +
+
+
+
+ + + Dependencies + + + + + + + + + + + + + +
+
+
+
+ Configuration +
+
+
+
+ + + Configuration + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ Build log +
+
+
+ + + Build log + + + + + + + + + + + + + + Text is not SVG - cannot display + + + + diff --git a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg index 764f7babf38..eeda76cd481 100644 --- a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg @@ -246,13 +246,13 @@
- gcov + llvm-cov + llvm-profdata
- gcov + llvm-cov + llvm-profdata diff --git a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg index f0da3fd4910..94014334f34 100644 --- a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg @@ -246,13 +246,13 @@
- (qcc) gcov + (qcc) llvm-cov + llvm-profdata
- (qcc) gcov + (qcc) llvm-cov + llvm-profdata diff --git a/docs/score_tools/tools_compiler/clang.rst b/docs/score_tools/tools_compiler/clang.rst new file mode 100644 index 00000000000..4de6b9f4756 --- /dev/null +++ b/docs/score_tools/tools_compiler/clang.rst @@ -0,0 +1,206 @@ +.. + # ******************************************************************************* + # Copyright (c) 2026 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +.. doc_tool:: clang + :id: doc_tool__clang + :status: draft + :version: 1 + :tool_version: 19.x + :tcl: HIGH + :safety_affected: YES + :security_affected: NO + :realizes: wp__tool_verification_report[version==1] + :tags: tool_management, tools_compiler + +Clang Compiler Verification Report +================================== + +Introduction +------------ +Scope and purpose +~~~~~~~~~~~~~~~~~ +Clang is the C/C++ compiler front end of the LLVM toolchain. + +In the context of the S-CORE project, clang is used on the Linux host for +verification activities that require LLVM source-based instrumentation. +The associated LLVM coverage tooling (``llvm-profdata`` and ``llvm-cov``) is +used together with clang-generated instrumentation for structural coverage +evidence generation and reporting. +For traceability in S-CORE naming, this report explicitly refers to +``llvm_cov`` (llvm-cov) and ``llvm_cov_profdata`` (combined llvm-profdata/ +llvm-cov workflow). + +Inputs and outputs +~~~~~~~~~~~~~~~~~~ +| Inputs: Software sources (C++), compiler options, build configuration, profile runtime output (``*.profraw``) +| Outputs: Object files, host test binaries, instrumentation metadata, merged profile data (``*.profdata``), coverage reports + +.. figure:: _assets/clang.drawio.svg + :width: 80% + :align: center + :alt: clang build + +.. figure:: _assets/clang-instrumentation.drawio.svg + :width: 80% + :align: center + :alt: Code coverage with clang + + + clang overview + +Available information +~~~~~~~~~~~~~~~~~~~~~ +- Version: 19.x [1]_ +- Official documentation: https://clang.llvm.org/docs/ +- Official documentation llvm-cov: https://llvm.org/docs/CommandGuide/llvm-cov.html +- Official documentation llvm-profdata: https://llvm.org/docs/CommandGuide/llvm-profdata.html + +Installation and integration +---------------------------- +Installation +~~~~~~~~~~~~ +clang is provided via the LLVM host toolchain used by the project. + +Integration +~~~~~~~~~~~ +clang is selected in dedicated host build configurations used for coverage +instrumentation and related verification workflows. + +Coverage is generated as part of the host verification workflow: + +#. Build and execute instrumented unit tests. +#. Merge raw profiles with llvm-profdata. +#. Generate coverage reports with llvm-cov. + +Environment +~~~~~~~~~~~ +Requires Linux host environment and Bazel toolchain integration. + +Safety evaluation +----------------- +This section outlines the safety evaluation of clang for its use within the +S-CORE project. + +.. list-table:: clang safety evaluation + :header-rows: 1 + :widths: 1 2 8 2 6 4 2 2 + + * - Malfunction identification + - Use case description + - Malfunctions + - Impact on safety? + - Impact safety measures available? + - Impact safety detection sufficient? + - Further additional safety measure required? + - Confidence (automatic calculation) + * - 1 + - Host compilation for coverage-enabled tests + - | Semantically wrong host test binary + | Could distort verification conclusions. + - yes + - yes + - yes + - no + - high + * - 2 + - Coverage reporting + - | Coverage data too high + | Reported coverage is higher than actual, masking untested code. + - yes + - yes + - yes + - no + - high + * - 3 + - Coverage reporting + - | Coverage data too low + | Reported coverage is lower than actual, causing unnecessary rework. + - no + - yes + - yes + - no + - high + * - 4 + - Profile merge/report generation + - | Incomplete profile merge or incorrect report filtering + | Can distort coverage results. + - yes + - yes + - yes + - no + - high + +Security evaluation +------------------- +This section outlines the security evaluation of clang for its use within the +S-CORE project. + +.. list-table:: clang security evaluation + :header-rows: 1 + + * - Threat identification + - Use case description + - Threats + - Impact on security? + - Impact security measures available? + - Impact security detection sufficient? + - Further additional security measure required? + * - 1 + - TBD + - TBD + - TBD + - TBD + - TBD + - TBD + +Confidence measures +------------------- +To increase confidence in the clang/``llvm_cov``/``llvm_cov_profdata`` coverage +workflow, the following measures are applied or recommended for the S-CORE +verification environment: + +* Provide a small validation suite with dedicated C++ source files whose + expected structural coverage is known in advance. +* Cover representative language constructs such as straight-line code, + conditional branches, loops, switch statements, short-circuit conditions, + templates and excluded regions. +* Provide unit tests for these validation sources so that specific coverage + outcomes are exercised intentionally, for example full coverage, partial + branch coverage and deliberately uncovered code. +* Execute the validation suite in CI with LLVM instrumentation enabled and + compare the produced ``*.profraw``/``*.profdata`` data and final + ``llvm-cov`` report against expected results. +* Use a secondary plausibility cross-check that compares the expected coverage + baseline (for example number of source files and rough line-count totals in the project) + against the files and aggregates reported by ``llvm-cov``. +* Re-run the validation suite whenever the LLVM/clang toolchain version changes + or the coverage workflow is modified. +* Keep the validation sources and expected results version-controlled so that + tool behavior is reproducible and regressions become reviewable. + +The dedicated validation suite with intentionally designed reference cases is +the primary confidence measure. The file/line-count comparison is a secondary +sanity check that can reveal missing files, empty profiles or implausible report +totals, but it does not by itself prove correct branch/region attribution. + +Result +------ +clang is used in host verification workflows and is currently evaluated with +confidence level HIGH for this use case. +The associated llvm-profdata/llvm-cov coverage tooling is covered by this +verification context. +This includes ``llvm_cov`` and ``llvm_cov_profdata``. + +.. [1] The tool version mentioned in this document is preliminary. It is subject to + change and will be updated in future. diff --git a/docs/score_tools/tools_compiler/gcc.rst b/docs/score_tools/tools_compiler/gcc.rst index 35d3f3a931e..d9ac25ee378 100644 --- a/docs/score_tools/tools_compiler/gcc.rst +++ b/docs/score_tools/tools_compiler/gcc.rst @@ -34,6 +34,8 @@ GCC is open-source C/C++ compiler. It is widely used in the software development In the context of the S-CORE project, GCC is used as a development tool to compile software components during the development phase. However, it is not used for production builds of safety-related software components. +The GCC toolchain also provides ``gcov`` for coverage instrumentation/reporting. This capability is available in the project environment if needed, but it is not the primary structural-coverage reporting path used in S-CORE. + Therefore, the safety and security impact of GCC is "NO". @@ -198,6 +200,7 @@ Result ------ GCC is not used for production builds nor during software verification phases. The tool is used for development purposes only to support early-stage issue identification and resolution. +Coverage with ``gcov`` remains technically available through the GCC toolchain for dedicated use cases. .. [1] The tool version mentioned in this document is preliminary. It is subject to change and will be updated in future. diff --git a/docs/score_tools/tools_compiler/index.rst b/docs/score_tools/tools_compiler/index.rst index 61463f5935e..3e04fc278c5 100644 --- a/docs/score_tools/tools_compiler/index.rst +++ b/docs/score_tools/tools_compiler/index.rst @@ -29,5 +29,6 @@ Compiler Tools Overview :hidden: :maxdepth: 2 + clang gcc qcc diff --git a/ubproject.toml b/ubproject.toml new file mode 100644 index 00000000000..133d64b207c --- /dev/null +++ b/ubproject.toml @@ -0,0 +1,282 @@ +# This file is auto-generated by needs-config-writer. +# It is a duplicate of shared and local configs to make tools like ubCode / ubc work. +# Do not manually modify it - changes will be overwritten. + +[needs] +build_json = true +build_needumls = "_plantuml_sources" +default_layout = "score" +id_regex = "^[A-Za-z0-9_-]{6,}" +id_required = true +json_remove_defaults = true +reproducible_json = true +schema_debug_path = "/home/jhr2hi/score_score/docs/schema_debug" + +[[needs.external_needs]] +base_url = "https://eclipse-score.github.io/process_description//main" +json_path = "bazel-bin/external/score_process+/needs_json/_build/needs/needs.json" + +[needs.flow_configs] +cplant = "\n ' CPLANT by AOKI (https://github.com/aoki/cplant)\n !define BLACK #363D5D\n !define RED #F6363F\n !define PINK #F6216E\n !define MAGENTA #A54FBD\n !define GREEN #37A77C\n !define YELLOW #F97A00\n !define BLUE #1E98F2\n !define CYAN #25AFCA\n !define WHITE #FEF2DC\n\n ' Base Setting\n skinparam Shadowing false\n skinparam BackgroundColor transparent\n skinparam ComponentStyle uml2\n skinparam Default {\n FontName 'Hiragino Sans'\n FontColor BLACK\n FontSize 10\n FontStyle plain\n }\n\n skinparam Sequence {\n ArrowThickness 1\n ArrowColor RED\n ActorBorderThickness 1\n LifeLineBorderColor GREEN\n ParticipantBorderThickness 0\n }\n skinparam Participant {\n BackgroundColor BLACK\n BorderColor BLACK\n FontColor #FFFFFF\n }\n\n skinparam Actor {\n BackgroundColor BLACK\n BorderColor BLACK\n }\n " +handwritten = "\n skinparam handwritten true\n " +lefttoright = "\n left to right direction\n " +mixing = "\n allowmixing\n " +monochrome = "\n skinparam monochrome true\n " +score_config = "!include ../.cache/bazel/_bazel_jhr2hi/e0cb86ed182ed08042fdd38dda4484a4/external/score_docs_as_code+/src/extensions/score_layout/assets/puml-theme-score.puml" +tne = "\n ' Based on \"Tomorrow night eighties\" color theme (see https://github.com/chriskempson/tomorrow-theme)\n ' Provided by gabrieljoelc (https://github.com/gabrieljoelc/plantuml-themes)\n !define Background #2d2d2d\n !define CurrentLine #393939\n !define Selection #515151\n !define Foregound #cccccc\n !define Comment #999999\n !define Red #f2777a\n !define Orange #f99157\n !define Yellow #ffcc66\n !define Green #99cc99\n !define Aqua #66cccc\n !define Blue #6699cc\n !define Purple #cc99cc\n\n skinparam Shadowing false\n skinparam backgroundColor #2d2d2d\n skinparam Arrow {\n Color Foregound\n FontColor Foregound\n FontStyle Bold\n }\n skinparam Default {\n FontName Menlo\n FontColor #fdfdfd\n }\n skinparam package {\n FontColor Purple\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam node {\n FontColor Yellow\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam component {\n BackgroundColor Selection\n BorderColor Blue\n FontColor Blue\n Style uml2\n }\n skinparam database {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Orange\n }\n\n skinparam cloud {\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n\n skinparam interface {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Green\n }\n " +toptobottom = "\n top to bottom direction\n " +transparent = "\n skinparam backgroundcolor transparent\n " + +[needs.graphviz_styles.default.edge] +minlen = "2" + +[needs.graphviz_styles.default.node] +margin = "0.21,0.11" + +[needs.graphviz_styles.lefttoright.graph] +rankdir = "LR" + +[needs.graphviz_styles.toptobottom.graph] +rankdir = "TB" + +[needs.graphviz_styles.transparent.graph] +bgcolor = "transparent" + +[needs.layouts.clean] +grid = "simple" + +[needs.layouts.clean.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] + +[needs.layouts.clean_l] +grid = "simple_side_left" + +[needs.layouts.clean_l.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_lp] +grid = "simple_side_left_partial" + +[needs.layouts.clean_lp.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_r] +grid = "simple_side_right" + +[needs.layouts.clean_r.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_rp] +grid = "simple_side_right_partial" + +[needs.layouts.clean_rp.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.complete] +grid = "complex" + +[needs.layouts.complete.layout] +footer = [] +footer_left = [ + "layout: <>", +] +footer_right = [ + "style: <>", +] +head = [ + "<>", +] +head_left = [ + "<>", +] +head_right = [ + "<>", +] +meta_left = [ + "<>", +] +meta_right = [ + "<>", +] + +[needs.layouts.debug] +grid = "simple" + +[needs.layouts.debug.layout] +head = [ + "<> **<>**", + "**<>**", +] +meta = [ + "<>", +] + +[needs.layouts.focus] +grid = "content" + +[needs.layouts.focus.layout] + +[needs.layouts.focus_f] +grid = "content_footer" + +[needs.layouts.focus_f.layout] +footer = [ + "<>", +] + +[needs.layouts.focus_l] +grid = "content_side_left" + +[needs.layouts.focus_l.layout] +side = [ + "<>", +] + +[needs.layouts.focus_r] +grid = "content_side_right" + +[needs.layouts.focus_r.layout] +side = [ + "<>", +] + +[needs.layouts.github] +grid = "complex" + +[needs.layouts.github.layout] +footer = [ + "service: <>", +] +footer_left = [ + "layout: <>", +] +footer_right = [ + "style: <>", +] +head = [ + "**<>** (<>)", +] +head_left = [ + "<>", + "<>", +] +head_right = [ + "<>", + "<>", +] +meta_left = [ + "<>", + "<>", + "<>", + "<>", + "<>", + "<>", +] +meta_right = [ + "<>", + "<>", + "<>", +] + +[needs.layouts.score] +grid = "complex" + +[needs.layouts.score.layout] +footer = [ + "<>", +] +footer_left = [ + "<>", +] +footer_right = [] +head = [ + "<>", + "<>", + "<>", +] +head_left = [ + "<>", +] +head_right = [ + "<>", +] +meta_left = [ + "<>", + "<>", +] +meta_right = [] + +[needs.layouts.test] +grid = "simple" + +[needs.layouts.test.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] + +[parse.extend_directives.grid] +argument = true +options = true +content = true +parse_content = true +content_required = true + +[parse.extend_directives.grid-item-card] +argument = false +options = true +content = true +parse_content = true +content_required = true + +[parse.extend_directives.uml] +argument = true +options = true +content = true +parse_content = false +content_required = false From c04e403802563ffb90f715fa3e408e202cd47f9f Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:01:23 +0200 Subject: [PATCH 05/14] keep gcov in tools --- docs/score_tools/score_tools_evaluation_list.rst | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/docs/score_tools/score_tools_evaluation_list.rst b/docs/score_tools/score_tools_evaluation_list.rst index d5fef7a0755..19c4980cfa8 100644 --- a/docs/score_tools/score_tools_evaluation_list.rst +++ b/docs/score_tools/score_tools_evaluation_list.rst @@ -179,11 +179,19 @@ release, as part of the Tool Verification Report. - N/A - YES * - 2a-5 - - llvm-cov + llvm-profdata - - Source-based code coverage toolchain from LLVM + - gcov + - Code coverage tool from GCC / GNU compiler collection - T.B.D. (see [1]_) - YES - :need:`rl__infrastructure_tooling_community` + - N/A + - YES + * - 2a-6 + - Clang + llvm-cov + llvm-profdata + - Host C++ compiler used for LLVM source-based coverage instrumentation and reporting workflows + - 19.x (see [1]_) + - YES + - :need:`rl__infrastructure_tooling_community` - :need:`doc_tool__clang` - YES From 6257072346adf798e0126987a431a59edd442b2f Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:03:07 +0200 Subject: [PATCH 06/14] keep gcov in tools --- docs/score_tools/score_tools_evaluation_list.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/score_tools/score_tools_evaluation_list.rst b/docs/score_tools/score_tools_evaluation_list.rst index 19c4980cfa8..ad155d86b98 100644 --- a/docs/score_tools/score_tools_evaluation_list.rst +++ b/docs/score_tools/score_tools_evaluation_list.rst @@ -179,8 +179,8 @@ release, as part of the Tool Verification Report. - N/A - YES * - 2a-5 - - gcov - - Code coverage tool from GCC / GNU compiler collection + - gcovr + - Code coverage tool (uses gcov from GCC), part of GNU compiler collection - T.B.D. (see [1]_) - YES - :need:`rl__infrastructure_tooling_community` From 09eec1d192456c755fc0298b7b3b9def5a8e45cd Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:05:01 +0200 Subject: [PATCH 07/14] rework description --- docs/score_tools/score_tools_evaluation_list.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/score_tools/score_tools_evaluation_list.rst b/docs/score_tools/score_tools_evaluation_list.rst index ad155d86b98..2001f8fb939 100644 --- a/docs/score_tools/score_tools_evaluation_list.rst +++ b/docs/score_tools/score_tools_evaluation_list.rst @@ -188,7 +188,7 @@ release, as part of the Tool Verification Report. - YES * - 2a-6 - Clang + llvm-cov + llvm-profdata - - Host C++ compiler used for LLVM source-based coverage instrumentation and reporting workflows + - Code coverage tool from LLVM, used with Clang compiler - 19.x (see [1]_) - YES - :need:`rl__infrastructure_tooling_community` From 7fa0096d40ad18a4042e448de76ddc620c564497 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:07:37 +0200 Subject: [PATCH 08/14] add llvm rust support --- docs/score_tools/score_tools_evaluation_list.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/score_tools/score_tools_evaluation_list.rst b/docs/score_tools/score_tools_evaluation_list.rst index 2001f8fb939..dc36a65615b 100644 --- a/docs/score_tools/score_tools_evaluation_list.rst +++ b/docs/score_tools/score_tools_evaluation_list.rst @@ -235,6 +235,14 @@ release, as part of the Tool Verification Report. - :need:`rl__infrastructure_tooling_community` - N/A - YES + * - 2b-4 + - llvm-cov + llvm-profdata + - LLVM source-based code coverage toolchain, usable in dedicated Rust/LLVM host workflows + - 19.x (see [1]_) + - YES + - :need:`rl__infrastructure_tooling_community` + - :need:`doc_tool__clang` + - YES 2c Python From b3fe2733c86024720c254bbca3ac423f917e103b Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:12:51 +0200 Subject: [PATCH 09/14] revert picture --- .../_assets/gcc-instrumentation.drawio.svg | 6 ++--- .../_assets/qcc-instrumentation.drawio.svg | 22 +++++++++---------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg index eeda76cd481..1abcc405f64 100644 --- a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg @@ -1,4 +1,4 @@ - + @@ -246,13 +246,13 @@
- llvm-cov + llvm-profdata + gcov
- llvm-cov + llvm-profdata + gcov diff --git a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg index 94014334f34..b9842ea296b 100644 --- a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg @@ -1,4 +1,4 @@ - + @@ -28,8 +28,8 @@ - - + + @@ -91,8 +91,8 @@ - - + + @@ -181,8 +181,8 @@ - - + + @@ -246,20 +246,20 @@
- (qcc) llvm-cov + llvm-profdata + (qcc) gcov
- (qcc) llvm-cov + llvm-profdata + (qcc) gcov - + @@ -289,7 +289,7 @@ - + From 6fd9a8482ca5ea95c399dfa3dd69533e2f8622fe Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:22:19 +0200 Subject: [PATCH 10/14] revert picture --- .../_assets/gcc-instrumentation.drawio.svg | 2 +- .../_assets/qcc-instrumentation.drawio.svg | 18 +++++++++--------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg index 1abcc405f64..764f7babf38 100644 --- a/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/gcc-instrumentation.drawio.svg @@ -1,4 +1,4 @@ - + diff --git a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg index b9842ea296b..f0da3fd4910 100644 --- a/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg +++ b/docs/score_tools/tools_compiler/_assets/qcc-instrumentation.drawio.svg @@ -1,4 +1,4 @@ - + @@ -28,8 +28,8 @@ - - + + @@ -91,8 +91,8 @@ - - + + @@ -181,8 +181,8 @@ - - + + @@ -259,7 +259,7 @@ - + @@ -289,7 +289,7 @@ - + From 0334b075d711158bd99921dca0be53f12ec5a838 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 6 Aug 2026 11:23:45 +0200 Subject: [PATCH 11/14] remove toml --- ubproject.toml | 282 ------------------------------------------------- 1 file changed, 282 deletions(-) delete mode 100644 ubproject.toml diff --git a/ubproject.toml b/ubproject.toml deleted file mode 100644 index 133d64b207c..00000000000 --- a/ubproject.toml +++ /dev/null @@ -1,282 +0,0 @@ -# This file is auto-generated by needs-config-writer. -# It is a duplicate of shared and local configs to make tools like ubCode / ubc work. -# Do not manually modify it - changes will be overwritten. - -[needs] -build_json = true -build_needumls = "_plantuml_sources" -default_layout = "score" -id_regex = "^[A-Za-z0-9_-]{6,}" -id_required = true -json_remove_defaults = true -reproducible_json = true -schema_debug_path = "/home/jhr2hi/score_score/docs/schema_debug" - -[[needs.external_needs]] -base_url = "https://eclipse-score.github.io/process_description//main" -json_path = "bazel-bin/external/score_process+/needs_json/_build/needs/needs.json" - -[needs.flow_configs] -cplant = "\n ' CPLANT by AOKI (https://github.com/aoki/cplant)\n !define BLACK #363D5D\n !define RED #F6363F\n !define PINK #F6216E\n !define MAGENTA #A54FBD\n !define GREEN #37A77C\n !define YELLOW #F97A00\n !define BLUE #1E98F2\n !define CYAN #25AFCA\n !define WHITE #FEF2DC\n\n ' Base Setting\n skinparam Shadowing false\n skinparam BackgroundColor transparent\n skinparam ComponentStyle uml2\n skinparam Default {\n FontName 'Hiragino Sans'\n FontColor BLACK\n FontSize 10\n FontStyle plain\n }\n\n skinparam Sequence {\n ArrowThickness 1\n ArrowColor RED\n ActorBorderThickness 1\n LifeLineBorderColor GREEN\n ParticipantBorderThickness 0\n }\n skinparam Participant {\n BackgroundColor BLACK\n BorderColor BLACK\n FontColor #FFFFFF\n }\n\n skinparam Actor {\n BackgroundColor BLACK\n BorderColor BLACK\n }\n " -handwritten = "\n skinparam handwritten true\n " -lefttoright = "\n left to right direction\n " -mixing = "\n allowmixing\n " -monochrome = "\n skinparam monochrome true\n " -score_config = "!include ../.cache/bazel/_bazel_jhr2hi/e0cb86ed182ed08042fdd38dda4484a4/external/score_docs_as_code+/src/extensions/score_layout/assets/puml-theme-score.puml" -tne = "\n ' Based on \"Tomorrow night eighties\" color theme (see https://github.com/chriskempson/tomorrow-theme)\n ' Provided by gabrieljoelc (https://github.com/gabrieljoelc/plantuml-themes)\n !define Background #2d2d2d\n !define CurrentLine #393939\n !define Selection #515151\n !define Foregound #cccccc\n !define Comment #999999\n !define Red #f2777a\n !define Orange #f99157\n !define Yellow #ffcc66\n !define Green #99cc99\n !define Aqua #66cccc\n !define Blue #6699cc\n !define Purple #cc99cc\n\n skinparam Shadowing false\n skinparam backgroundColor #2d2d2d\n skinparam Arrow {\n Color Foregound\n FontColor Foregound\n FontStyle Bold\n }\n skinparam Default {\n FontName Menlo\n FontColor #fdfdfd\n }\n skinparam package {\n FontColor Purple\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam node {\n FontColor Yellow\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam component {\n BackgroundColor Selection\n BorderColor Blue\n FontColor Blue\n Style uml2\n }\n skinparam database {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Orange\n }\n\n skinparam cloud {\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n\n skinparam interface {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Green\n }\n " -toptobottom = "\n top to bottom direction\n " -transparent = "\n skinparam backgroundcolor transparent\n " - -[needs.graphviz_styles.default.edge] -minlen = "2" - -[needs.graphviz_styles.default.node] -margin = "0.21,0.11" - -[needs.graphviz_styles.lefttoright.graph] -rankdir = "LR" - -[needs.graphviz_styles.toptobottom.graph] -rankdir = "TB" - -[needs.graphviz_styles.transparent.graph] -bgcolor = "transparent" - -[needs.layouts.clean] -grid = "simple" - -[needs.layouts.clean.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] - -[needs.layouts.clean_l] -grid = "simple_side_left" - -[needs.layouts.clean_l.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_lp] -grid = "simple_side_left_partial" - -[needs.layouts.clean_lp.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_r] -grid = "simple_side_right" - -[needs.layouts.clean_r.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_rp] -grid = "simple_side_right_partial" - -[needs.layouts.clean_rp.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.complete] -grid = "complex" - -[needs.layouts.complete.layout] -footer = [] -footer_left = [ - "layout: <>", -] -footer_right = [ - "style: <>", -] -head = [ - "<>", -] -head_left = [ - "<>", -] -head_right = [ - "<>", -] -meta_left = [ - "<>", -] -meta_right = [ - "<>", -] - -[needs.layouts.debug] -grid = "simple" - -[needs.layouts.debug.layout] -head = [ - "<> **<>**", - "**<>**", -] -meta = [ - "<>", -] - -[needs.layouts.focus] -grid = "content" - -[needs.layouts.focus.layout] - -[needs.layouts.focus_f] -grid = "content_footer" - -[needs.layouts.focus_f.layout] -footer = [ - "<>", -] - -[needs.layouts.focus_l] -grid = "content_side_left" - -[needs.layouts.focus_l.layout] -side = [ - "<>", -] - -[needs.layouts.focus_r] -grid = "content_side_right" - -[needs.layouts.focus_r.layout] -side = [ - "<>", -] - -[needs.layouts.github] -grid = "complex" - -[needs.layouts.github.layout] -footer = [ - "service: <>", -] -footer_left = [ - "layout: <>", -] -footer_right = [ - "style: <>", -] -head = [ - "**<>** (<>)", -] -head_left = [ - "<>", - "<>", -] -head_right = [ - "<>", - "<>", -] -meta_left = [ - "<>", - "<>", - "<>", - "<>", - "<>", - "<>", -] -meta_right = [ - "<>", - "<>", - "<>", -] - -[needs.layouts.score] -grid = "complex" - -[needs.layouts.score.layout] -footer = [ - "<>", -] -footer_left = [ - "<>", -] -footer_right = [] -head = [ - "<>", - "<>", - "<>", -] -head_left = [ - "<>", -] -head_right = [ - "<>", -] -meta_left = [ - "<>", - "<>", -] -meta_right = [] - -[needs.layouts.test] -grid = "simple" - -[needs.layouts.test.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] - -[parse.extend_directives.grid] -argument = true -options = true -content = true -parse_content = true -content_required = true - -[parse.extend_directives.grid-item-card] -argument = false -options = true -content = true -parse_content = true -content_required = true - -[parse.extend_directives.uml] -argument = true -options = true -content = true -parse_content = false -content_required = false From fe9f32272286ab29ace7257270cc094ebc2f1c95 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Thu, 13 Aug 2026 14:24:29 +0200 Subject: [PATCH 12/14] add some measures --- docs/score_tools/tools_compiler/clang.rst | 42 +++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/score_tools/tools_compiler/clang.rst b/docs/score_tools/tools_compiler/clang.rst index 4de6b9f4756..66031869415 100644 --- a/docs/score_tools/tools_compiler/clang.rst +++ b/docs/score_tools/tools_compiler/clang.rst @@ -41,6 +41,10 @@ For traceability in S-CORE naming, this report explicitly refers to ``llvm_cov`` (llvm-cov) and ``llvm_cov_profdata`` (combined llvm-profdata/ llvm-cov workflow). +This report covers the Linux host verification workflow only. It does not +cover production-target compilation with clang, Rust compiler qualification, +or QNX-specific coverage flows. + Inputs and outputs ~~~~~~~~~~~~~~~~~~ | Inputs: Software sources (C++), compiler options, build configuration, profile runtime output (``*.profraw``) @@ -83,6 +87,18 @@ Coverage is generated as part of the host verification workflow: #. Merge raw profiles with llvm-profdata. #. Generate coverage reports with llvm-cov. +The qualification boundary is explicitly limited to this workflow: + +* clang adds instrumentation during host builds through LLVM source-based + coverage options. +* ``llvm-profdata`` merges ``*.profraw`` execution data into ``*.profdata``. +* ``llvm-cov`` converts the instrumented binaries and merged profile data into + developer-facing coverage reports. + +The resulting coverage report is a development artifact used by human +reviewers in verification activities. Instrumented binaries are executed only +during test runs and are not deployed as production software artifacts. + Environment ~~~~~~~~~~~ Requires Linux host environment and Bazel toolchain integration. @@ -170,6 +186,9 @@ To increase confidence in the clang/``llvm_cov``/``llvm_cov_profdata`` coverage workflow, the following measures are applied or recommended for the S-CORE verification environment: +* Treat the coverage workflow as a separate verification path from production + builds so that instrumentation-related effects stay confined to host test + execution. * Provide a small validation suite with dedicated C++ source files whose expected structural coverage is known in advance. * Cover representative language constructs such as straight-line code, @@ -181,9 +200,17 @@ verification environment: * Execute the validation suite in CI with LLVM instrumentation enabled and compare the produced ``*.profraw``/``*.profdata`` data and final ``llvm-cov`` report against expected results. +* Include at least one intentionally uncovered file or line in the validation + suite so that false-positive reporting is easier to detect during review and + CI execution. +* Re-run the coverage workflow from a clean build in CI so that profile merge + failures, missing reports and threshold regressions are visible as build + failures rather than silent degradations. * Use a secondary plausibility cross-check that compares the expected coverage baseline (for example number of source files and rough line-count totals in the project) against the files and aggregates reported by ``llvm-cov``. +* Compare known-covered and known-uncovered lines in the generated report as a + targeted spot check when the LLVM version or reporting flow changes. * Re-run the validation suite whenever the LLVM/clang toolchain version changes or the coverage workflow is modified. * Keep the validation sources and expected results version-controlled so that @@ -194,6 +221,12 @@ the primary confidence measure. The file/line-count comparison is a secondary sanity check that can reveal missing files, empty profiles or implausible report totals, but it does not by itself prove correct branch/region attribution. +For the LLVM coverage workflow, the relevant error-detection mechanisms are +independent review of selected report lines, CI re-execution from scratch, +threshold-based gating and validation cases with known expected outcomes. +These measures are intended to detect both optimistic and pessimistic coverage +misreporting before the results are used in a safety argument. + Result ------ clang is used in host verification workflows and is currently evaluated with @@ -202,5 +235,14 @@ The associated llvm-profdata/llvm-cov coverage tooling is covered by this verification context. This includes ``llvm_cov`` and ``llvm_cov_profdata``. +Within this scope, ``llvm-profdata`` and ``llvm-cov`` are treated as +development tools whose output is a verification report for human assessment. +Incorrectly low coverage remains a conservative failure mode. Incorrectly high +coverage is the relevant safety concern, and the confidence measures above are +the basis for keeping this workflow in the project-internal high-confidence +category for Linux host verification use. On that basis, this report does not +identify an additional formal qualification action for the current Linux host +coverage-reporting scope. + .. [1] The tool version mentioned in this document is preliminary. It is subject to change and will be updated in future. From 9c6551325d740a3cf97ae6cb088adec278477f25 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Mon, 24 Aug 2026 13:24:32 +0200 Subject: [PATCH 13/14] update after decision in S-CORE --- .../development/cpp/code_analysis.rst | 61 +--- .../platform_assumptions/index.rst | 13 + ubproject.toml | 282 ++++++++++++++++++ 3 files changed, 297 insertions(+), 59 deletions(-) create mode 100644 ubproject.toml diff --git a/docs/contribute/development/cpp/code_analysis.rst b/docs/contribute/development/cpp/code_analysis.rst index de048865949..164ff096b46 100644 --- a/docs/contribute/development/cpp/code_analysis.rst +++ b/docs/contribute/development/cpp/code_analysis.rst @@ -111,7 +111,7 @@ As required by the verification guideline code coverage needs to be calculated f In Bazel-based development, this does not imply that every build uses the same compiler configuration. Normal host builds may use the default host compiler/toolchain, while coverage builds select a dedicated host configuration with LLVM source-based instrumentation enabled. The resulting raw profiles are merged with ``llvm-profdata`` and evaluated with ``llvm-cov``. -Since ``qcc`` does not support LLVM's source-based coverage instrumentation, coverage is not collected on the QNX target. LLVM's source-based coverage natively supports MC/DC, which is required for the higher ASIL levels. +S-CORE determines structural coverage on the host using LLVM's source-based coverage. Structural coverage on the target is not determined by S-CORE. It shall be determined by the user or distributor for the target on which the S-CORE software is integrated. Target structural coverage is needed to identify uncovered target-specific code and to provide evidence for the absence of undefined behaviour on the target. LLVM's source-based coverage is preferred over ``gcov``-based coverage for the following reasons: @@ -132,61 +132,4 @@ To enable this, following tools are used: gtest --> llvm llvm --> host -Argumentation: Host-based Coverage with Target Test Execution -------------------------------------------------------------- - -Measuring code coverage exclusively on the **Linux host** (via LLVM) is considered sufficient for safety certification, provided that a **two-step verification** is performed to demonstrate equivalence on the target: - -#. **Quantitative Verification (Host):** The complete test suite is executed on the Linux host with code coverage enabled. This demonstrates that the test cases are structurally complete (100% C0/C1 coverage) and that no dead code exists. -#. **Qualitative Verification (Target):** The identical test suite is executed on the **QNX target**, but with code coverage instrumentation turned off. This demonstrates that the software compiles, links, and behaves identically on the real target hardware (correctness of execution, no compiler/linker optimization bugs, no endianness or memory alignment issues). - -This approach satisfies *ISO 26262-6* for *ASIL_B* for the following reasons: - -* **Identical Test Results:** Passing 100% of the tests on both the host and the target demonstrates that the control flow under test is identical. -* **Mitigation of Target Instrumentation Risks:** The two-step verification deliberately splits the two concerns onto the environment best suited for each: the **host run is instrumented** (to measure structural coverage), and the **target run is uninstrumented** (to confirm the tests still pass on the real production binary). This is the same "measure coverage with instrumentation, then re-run without instrumentation to confirm behaviour" pattern applied across two environments. Running uninstrumented on QNX matters because active instrumentation alters timing behaviour, memory footprint and compiler optimizations on embedded targets (mitigating "Heisenbugs"). Note that ``qcc`` cannot produce LLVM source-based coverage, so an *instrumented* coverage run on the target is not an available option. -* **Equivalence Justification:** The host-based coverage measurement is justified by confirming that no platform-specific code paths (e.g., ``#ifdef QNX`` blocks) or QNX-only source files are silently bypassed by the host measurement. The reconciliation strategy for such code, and the process a developer uses to identify it, is described in `Handling Platform-Specific Code`_ below. Any target-specific hardware abstraction layer (HAL) is additionally verified via system-level integration tests. - -Handling Platform-Specific Code -------------------------------- - -Because structural coverage is measured on the **Linux host** while the QNX target is only tested for pass/fail, the coverage *baseline* (the set of source files and lines expected to be covered) differs between the two environments. Code that is strictly platform-specific therefore needs an explicit reconciliation strategy so that it neither skews the release metrics nor becomes unverified "dead" code in the safety case. - -Three cases are distinguished. - -Linux-only code (mocks, emulation, host utilities) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This code is compiled and executed only on the host and is absent on the QNX target. It must not contribute to the ASIL-B production coverage figures. - -* Linux-only helper code and mocks are kept structurally separate from production code (e.g. under dedicated ``mock/`` or ``test/`` directories) and are classified as Quality Managed (QM) / test-support code. -* Such directories are excluded when the coverage report is generated, so this code is not part of the ASIL-B production coverage baseline and cannot inflate or deflate the reported figures. - -QNX-only code inside mixed files (conditional compilation) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For files that are compiled on the host but contain small target-specific blocks (e.g. guarded by ``#ifdef __QNX__``), those blocks are not compiled into the host binary and would otherwise appear as non-covered or non-existent regions. - -* These target-only regions are marked with standardized coverage-exclusion markers understood by the coverage report generator, together with a justification stating that the region is executed and verified on the QNX target rather than on the host. -* The applicable exclusion markers and their justification format are governed centrally (rather than chosen per developer) so that exclusions remain auditable and consistent across repositories. - -.. note:: - - The exclusion-marker syntax must match the coverage tooling actually in use. Because coverage in S-CORE is produced by **LLVM source-based coverage** (``llvm-cov`` / ``llvm-profdata``), the marker mechanism supported by that toolchain (line/region exclusion) must be used; ``LCOV_EXCL_*`` markers from lcov/GCC workflows are *not* interpreted natively by ``llvm-cov`` and must not be assumed to work unless an ``lcov`` conversion/merge step is explicitly part of the pipeline. - -QNX-only files excluded from the host build -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Some modules or files are compiled **only** for QNX and cannot be built on the host at all (e.g. sources that call QNX-specific OS APIs). These would report 0% coverage in a host-only measurement. - -* Such files are excluded from the **host structural-coverage baseline**, so they do not produce misleading false-negative 0% figures. -* Because ``qcc`` cannot produce LLVM source-based coverage, **no structural coverage can be obtained for these files**. This is a *justified deviation* from the unit-level structural-coverage objective, not a claim of equivalence: the residual risk is that unit-level statement/branch coverage evidence does not exist for this code. -* The deviation is compensated by verifying these files **on the QNX target** through requirements-based integration tests executed on the real hardware, and by arguing the safety case on the basis of a 100% pass rate of the associated functional requirements. Each such file/module and its compensating verification is recorded so the deviation is traceable and reviewable. - -Identifying platform-specific code -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -A developer must be able to determine which code falls into the categories above; this cannot rely on manually reading source for ``#ifdef`` guards, because whole files may be excluded from the host build. The following mechanisms are used: - -* **Build-set comparison:** The set of source files compiled for the host is compared against the set compiled for the QNX target. Files present only in the QNX build are, by construction, the "QNX-only files" case and are flagged automatically. -* **Explicit exclusion manifest:** Every host-coverage exclusion (whether a per-file exclusion or a within-file region marker) is recorded in a reviewable list, so the complete delta between the host coverage baseline and the full target code base is visible in one place rather than scattered across the sources. -* **CI gate:** The comparison and the manifest are checked in CI, so newly added QNX-only files or new conditional blocks that are not accompanied by a documented exclusion and a compensating target verification cause the quality gate to fail. +Host and target coverage have different responsibilities. LLVM coverage on the host provides S-CORE's structural-coverage result. The user or distributor shall determine structural coverage on the target used for integration, including target-specific code paths, as required by the platform AoU :need:`aou_req__platform__target_structural_coverage`. Target execution tests and target structural-coverage results are separate verification evidence and shall not be treated as interchangeable. diff --git a/docs/requirements/platform_assumptions/index.rst b/docs/requirements/platform_assumptions/index.rst index 8805571e99c..b178dee49ad 100644 --- a/docs/requirements/platform_assumptions/index.rst +++ b/docs/requirements/platform_assumptions/index.rst @@ -256,6 +256,19 @@ This is the highest level of integration. This is the level where the S-CORE SW- Note: The SW-platform integtion tests provided by S-CORE for :need:`aou_req__platform__testing` are for demonstration purpose only, as described in the tailoring section of :need:`doc__score_platform_safety_plan` and thus do not claim correctness and completeness. +.. aou_req:: Target structural coverage + :id: aou_req__platform__target_structural_coverage + :reqtype: Non-Functional + :security: YES + :safety: ASIL_B + :status: valid + :version: 1 + :tags: user + + If the system using the SW-platform has safety goals, the system integrator or distributor shall determine structural coverage for the target on which the SW-platform is integrated. + + Note: S-CORE determines structural coverage on the host using LLVM's source-based coverage. Target structural coverage is required to cover target-specific code and undefined behaviour and is not determined by S-CORE. + .. aou_req:: Integrator safety anomaly reporting :id: aou_req__platform__integration_safety_anomaly :reqtype: Non-Functional diff --git a/ubproject.toml b/ubproject.toml new file mode 100644 index 00000000000..133d64b207c --- /dev/null +++ b/ubproject.toml @@ -0,0 +1,282 @@ +# This file is auto-generated by needs-config-writer. +# It is a duplicate of shared and local configs to make tools like ubCode / ubc work. +# Do not manually modify it - changes will be overwritten. + +[needs] +build_json = true +build_needumls = "_plantuml_sources" +default_layout = "score" +id_regex = "^[A-Za-z0-9_-]{6,}" +id_required = true +json_remove_defaults = true +reproducible_json = true +schema_debug_path = "/home/jhr2hi/score_score/docs/schema_debug" + +[[needs.external_needs]] +base_url = "https://eclipse-score.github.io/process_description//main" +json_path = "bazel-bin/external/score_process+/needs_json/_build/needs/needs.json" + +[needs.flow_configs] +cplant = "\n ' CPLANT by AOKI (https://github.com/aoki/cplant)\n !define BLACK #363D5D\n !define RED #F6363F\n !define PINK #F6216E\n !define MAGENTA #A54FBD\n !define GREEN #37A77C\n !define YELLOW #F97A00\n !define BLUE #1E98F2\n !define CYAN #25AFCA\n !define WHITE #FEF2DC\n\n ' Base Setting\n skinparam Shadowing false\n skinparam BackgroundColor transparent\n skinparam ComponentStyle uml2\n skinparam Default {\n FontName 'Hiragino Sans'\n FontColor BLACK\n FontSize 10\n FontStyle plain\n }\n\n skinparam Sequence {\n ArrowThickness 1\n ArrowColor RED\n ActorBorderThickness 1\n LifeLineBorderColor GREEN\n ParticipantBorderThickness 0\n }\n skinparam Participant {\n BackgroundColor BLACK\n BorderColor BLACK\n FontColor #FFFFFF\n }\n\n skinparam Actor {\n BackgroundColor BLACK\n BorderColor BLACK\n }\n " +handwritten = "\n skinparam handwritten true\n " +lefttoright = "\n left to right direction\n " +mixing = "\n allowmixing\n " +monochrome = "\n skinparam monochrome true\n " +score_config = "!include ../.cache/bazel/_bazel_jhr2hi/e0cb86ed182ed08042fdd38dda4484a4/external/score_docs_as_code+/src/extensions/score_layout/assets/puml-theme-score.puml" +tne = "\n ' Based on \"Tomorrow night eighties\" color theme (see https://github.com/chriskempson/tomorrow-theme)\n ' Provided by gabrieljoelc (https://github.com/gabrieljoelc/plantuml-themes)\n !define Background #2d2d2d\n !define CurrentLine #393939\n !define Selection #515151\n !define Foregound #cccccc\n !define Comment #999999\n !define Red #f2777a\n !define Orange #f99157\n !define Yellow #ffcc66\n !define Green #99cc99\n !define Aqua #66cccc\n !define Blue #6699cc\n !define Purple #cc99cc\n\n skinparam Shadowing false\n skinparam backgroundColor #2d2d2d\n skinparam Arrow {\n Color Foregound\n FontColor Foregound\n FontStyle Bold\n }\n skinparam Default {\n FontName Menlo\n FontColor #fdfdfd\n }\n skinparam package {\n FontColor Purple\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam node {\n FontColor Yellow\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam component {\n BackgroundColor Selection\n BorderColor Blue\n FontColor Blue\n Style uml2\n }\n skinparam database {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Orange\n }\n\n skinparam cloud {\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n\n skinparam interface {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Green\n }\n " +toptobottom = "\n top to bottom direction\n " +transparent = "\n skinparam backgroundcolor transparent\n " + +[needs.graphviz_styles.default.edge] +minlen = "2" + +[needs.graphviz_styles.default.node] +margin = "0.21,0.11" + +[needs.graphviz_styles.lefttoright.graph] +rankdir = "LR" + +[needs.graphviz_styles.toptobottom.graph] +rankdir = "TB" + +[needs.graphviz_styles.transparent.graph] +bgcolor = "transparent" + +[needs.layouts.clean] +grid = "simple" + +[needs.layouts.clean.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] + +[needs.layouts.clean_l] +grid = "simple_side_left" + +[needs.layouts.clean_l.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_lp] +grid = "simple_side_left_partial" + +[needs.layouts.clean_lp.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_r] +grid = "simple_side_right" + +[needs.layouts.clean_r.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.clean_rp] +grid = "simple_side_right_partial" + +[needs.layouts.clean_rp.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] +side = [ + "<>", +] + +[needs.layouts.complete] +grid = "complex" + +[needs.layouts.complete.layout] +footer = [] +footer_left = [ + "layout: <>", +] +footer_right = [ + "style: <>", +] +head = [ + "<>", +] +head_left = [ + "<>", +] +head_right = [ + "<>", +] +meta_left = [ + "<>", +] +meta_right = [ + "<>", +] + +[needs.layouts.debug] +grid = "simple" + +[needs.layouts.debug.layout] +head = [ + "<> **<>**", + "**<>**", +] +meta = [ + "<>", +] + +[needs.layouts.focus] +grid = "content" + +[needs.layouts.focus.layout] + +[needs.layouts.focus_f] +grid = "content_footer" + +[needs.layouts.focus_f.layout] +footer = [ + "<>", +] + +[needs.layouts.focus_l] +grid = "content_side_left" + +[needs.layouts.focus_l.layout] +side = [ + "<>", +] + +[needs.layouts.focus_r] +grid = "content_side_right" + +[needs.layouts.focus_r.layout] +side = [ + "<>", +] + +[needs.layouts.github] +grid = "complex" + +[needs.layouts.github.layout] +footer = [ + "service: <>", +] +footer_left = [ + "layout: <>", +] +footer_right = [ + "style: <>", +] +head = [ + "**<>** (<>)", +] +head_left = [ + "<>", + "<>", +] +head_right = [ + "<>", + "<>", +] +meta_left = [ + "<>", + "<>", + "<>", + "<>", + "<>", + "<>", +] +meta_right = [ + "<>", + "<>", + "<>", +] + +[needs.layouts.score] +grid = "complex" + +[needs.layouts.score.layout] +footer = [ + "<>", +] +footer_left = [ + "<>", +] +footer_right = [] +head = [ + "<>", + "<>", + "<>", +] +head_left = [ + "<>", +] +head_right = [ + "<>", +] +meta_left = [ + "<>", + "<>", +] +meta_right = [] + +[needs.layouts.test] +grid = "simple" + +[needs.layouts.test.layout] +head = [ + "<>: **<>** <> <> ", +] +meta = [ + "<>", + "<>", +] + +[parse.extend_directives.grid] +argument = true +options = true +content = true +parse_content = true +content_required = true + +[parse.extend_directives.grid-item-card] +argument = false +options = true +content = true +parse_content = true +content_required = true + +[parse.extend_directives.uml] +argument = true +options = true +content = true +parse_content = false +content_required = false From b6588c61244b000b38fe10b7bb0cce296f3a6f07 Mon Sep 17 00:00:00 2001 From: "jhr2hi@bosch.com" Date: Mon, 24 Aug 2026 13:26:53 +0200 Subject: [PATCH 14/14] remove toml --- ubproject.toml | 282 ------------------------------------------------- 1 file changed, 282 deletions(-) delete mode 100644 ubproject.toml diff --git a/ubproject.toml b/ubproject.toml deleted file mode 100644 index 133d64b207c..00000000000 --- a/ubproject.toml +++ /dev/null @@ -1,282 +0,0 @@ -# This file is auto-generated by needs-config-writer. -# It is a duplicate of shared and local configs to make tools like ubCode / ubc work. -# Do not manually modify it - changes will be overwritten. - -[needs] -build_json = true -build_needumls = "_plantuml_sources" -default_layout = "score" -id_regex = "^[A-Za-z0-9_-]{6,}" -id_required = true -json_remove_defaults = true -reproducible_json = true -schema_debug_path = "/home/jhr2hi/score_score/docs/schema_debug" - -[[needs.external_needs]] -base_url = "https://eclipse-score.github.io/process_description//main" -json_path = "bazel-bin/external/score_process+/needs_json/_build/needs/needs.json" - -[needs.flow_configs] -cplant = "\n ' CPLANT by AOKI (https://github.com/aoki/cplant)\n !define BLACK #363D5D\n !define RED #F6363F\n !define PINK #F6216E\n !define MAGENTA #A54FBD\n !define GREEN #37A77C\n !define YELLOW #F97A00\n !define BLUE #1E98F2\n !define CYAN #25AFCA\n !define WHITE #FEF2DC\n\n ' Base Setting\n skinparam Shadowing false\n skinparam BackgroundColor transparent\n skinparam ComponentStyle uml2\n skinparam Default {\n FontName 'Hiragino Sans'\n FontColor BLACK\n FontSize 10\n FontStyle plain\n }\n\n skinparam Sequence {\n ArrowThickness 1\n ArrowColor RED\n ActorBorderThickness 1\n LifeLineBorderColor GREEN\n ParticipantBorderThickness 0\n }\n skinparam Participant {\n BackgroundColor BLACK\n BorderColor BLACK\n FontColor #FFFFFF\n }\n\n skinparam Actor {\n BackgroundColor BLACK\n BorderColor BLACK\n }\n " -handwritten = "\n skinparam handwritten true\n " -lefttoright = "\n left to right direction\n " -mixing = "\n allowmixing\n " -monochrome = "\n skinparam monochrome true\n " -score_config = "!include ../.cache/bazel/_bazel_jhr2hi/e0cb86ed182ed08042fdd38dda4484a4/external/score_docs_as_code+/src/extensions/score_layout/assets/puml-theme-score.puml" -tne = "\n ' Based on \"Tomorrow night eighties\" color theme (see https://github.com/chriskempson/tomorrow-theme)\n ' Provided by gabrieljoelc (https://github.com/gabrieljoelc/plantuml-themes)\n !define Background #2d2d2d\n !define CurrentLine #393939\n !define Selection #515151\n !define Foregound #cccccc\n !define Comment #999999\n !define Red #f2777a\n !define Orange #f99157\n !define Yellow #ffcc66\n !define Green #99cc99\n !define Aqua #66cccc\n !define Blue #6699cc\n !define Purple #cc99cc\n\n skinparam Shadowing false\n skinparam backgroundColor #2d2d2d\n skinparam Arrow {\n Color Foregound\n FontColor Foregound\n FontStyle Bold\n }\n skinparam Default {\n FontName Menlo\n FontColor #fdfdfd\n }\n skinparam package {\n FontColor Purple\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam node {\n FontColor Yellow\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n skinparam component {\n BackgroundColor Selection\n BorderColor Blue\n FontColor Blue\n Style uml2\n }\n skinparam database {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Orange\n }\n\n skinparam cloud {\n BackgroundColor CurrentLine\n BorderColor Selection\n }\n\n skinparam interface {\n BackgroundColor CurrentLine\n BorderColor Selection\n FontColor Green\n }\n " -toptobottom = "\n top to bottom direction\n " -transparent = "\n skinparam backgroundcolor transparent\n " - -[needs.graphviz_styles.default.edge] -minlen = "2" - -[needs.graphviz_styles.default.node] -margin = "0.21,0.11" - -[needs.graphviz_styles.lefttoright.graph] -rankdir = "LR" - -[needs.graphviz_styles.toptobottom.graph] -rankdir = "TB" - -[needs.graphviz_styles.transparent.graph] -bgcolor = "transparent" - -[needs.layouts.clean] -grid = "simple" - -[needs.layouts.clean.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] - -[needs.layouts.clean_l] -grid = "simple_side_left" - -[needs.layouts.clean_l.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_lp] -grid = "simple_side_left_partial" - -[needs.layouts.clean_lp.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_r] -grid = "simple_side_right" - -[needs.layouts.clean_r.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.clean_rp] -grid = "simple_side_right_partial" - -[needs.layouts.clean_rp.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] -side = [ - "<>", -] - -[needs.layouts.complete] -grid = "complex" - -[needs.layouts.complete.layout] -footer = [] -footer_left = [ - "layout: <>", -] -footer_right = [ - "style: <>", -] -head = [ - "<>", -] -head_left = [ - "<>", -] -head_right = [ - "<>", -] -meta_left = [ - "<>", -] -meta_right = [ - "<>", -] - -[needs.layouts.debug] -grid = "simple" - -[needs.layouts.debug.layout] -head = [ - "<> **<>**", - "**<>**", -] -meta = [ - "<>", -] - -[needs.layouts.focus] -grid = "content" - -[needs.layouts.focus.layout] - -[needs.layouts.focus_f] -grid = "content_footer" - -[needs.layouts.focus_f.layout] -footer = [ - "<>", -] - -[needs.layouts.focus_l] -grid = "content_side_left" - -[needs.layouts.focus_l.layout] -side = [ - "<>", -] - -[needs.layouts.focus_r] -grid = "content_side_right" - -[needs.layouts.focus_r.layout] -side = [ - "<>", -] - -[needs.layouts.github] -grid = "complex" - -[needs.layouts.github.layout] -footer = [ - "service: <>", -] -footer_left = [ - "layout: <>", -] -footer_right = [ - "style: <>", -] -head = [ - "**<>** (<>)", -] -head_left = [ - "<>", - "<>", -] -head_right = [ - "<>", - "<>", -] -meta_left = [ - "<>", - "<>", - "<>", - "<>", - "<>", - "<>", -] -meta_right = [ - "<>", - "<>", - "<>", -] - -[needs.layouts.score] -grid = "complex" - -[needs.layouts.score.layout] -footer = [ - "<>", -] -footer_left = [ - "<>", -] -footer_right = [] -head = [ - "<>", - "<>", - "<>", -] -head_left = [ - "<>", -] -head_right = [ - "<>", -] -meta_left = [ - "<>", - "<>", -] -meta_right = [] - -[needs.layouts.test] -grid = "simple" - -[needs.layouts.test.layout] -head = [ - "<>: **<>** <> <> ", -] -meta = [ - "<>", - "<>", -] - -[parse.extend_directives.grid] -argument = true -options = true -content = true -parse_content = true -content_required = true - -[parse.extend_directives.grid-item-card] -argument = false -options = true -content = true -parse_content = true -content_required = true - -[parse.extend_directives.uml] -argument = true -options = true -content = true -parse_content = false -content_required = false