eclipse-score · MaximilianSoerenPollak · Jul 31, 2025 · Jul 31, 2025 · Jul 31, 2025 · Jul 31, 2025
@@ -13,7 +13,7 @@
 
 module(
     name = "score_platform",
-    version = "1.0.1",
+    version = "1.1.0",
     compatibility_level = 0,
 )
 
@@ -73,7 +73,7 @@ bazel_dep(name = "rules_java", version = "8.13.0")
 #
 ###############################################################################
 
-bazel_dep(name = "score_python_basics", version = "0.3.3")
+bazel_dep(name = "score_python_basics", version = "0.3.4")
 
 ###############################################################################
 #

@@ -27,75 +27,44 @@ bazel run //:copyright.fix
 
 ### Building Documentation
 
-Score supports multiple methods for generating documentation, tailored to different workflows:
-1. **Bazel-based builds** for clean, sandboxed outputs.
-2. **Incremental builds** for quick iterations during development.
+Score supports multiple methods for generating documentation, tailored to different workflows:  
+1.  **Documentation builds** for building the documentation.
+2. **IDE independent live preview** for live previews of documentation without IDE integration.
 3. **IDE integration** for live previews, live warnings and even faster iterations.
-4. **IDE independent live preview** for live previews of documentation without IDE integration.
-
-#### Bazel-based Build
-
-This method ensures clean and isolated documentation builds in a controlled Bazel environment.
-It is best suited for CI pipelines or production-ready outputs, although it takes longer compared to
-incremental builds.
-Here it is possible to build it either with the current 'main' branch of [process](https://github.com/eclipse-score/process_description) or with the imported release version of it.
-
-
-> Note: 'latest' might not work if it's executed behind a proxy or vpn. If this is the case please use 'release'
 
 
 ```sh
-bazel build //docs:docs_latest # use current main branch of imported docs repositories (e.g. process_description)
-bazel build //docs:docs_release # use release version imported in MODULE.bazel
+bazel run //:docs 
 ```
-The output will be located here,depending on which way was chosen: 
-- bazel-bin/docs/docs_latest/_build/html. 
-- bazel-bin/docs/docs_release/_build/html. 
+The output will be located in `_build`
 
 
+#### IDE independent live preview
 
-#### Incremental build
-
-For local changes and faster feedback, use the incremental build.
-This method generates the documentation directly in the _build directory.
-
+For a documentation live preview independent of an IDE (CLI + browser only), `sphinx-autobuild` can be used.  
+This will automatically rebuild the preview after save and have it available at `http://127.0.0.1:8000`  
 ```sh
-bazel run //docs:incremental_latest # use current main branch of imported docs repositories (e.g. process_description)
-bazel run //docs:incremental_release # use release version imported in MODULE.bazel
+bazel run //:live_preview 
 ```
-Unlike IDE integration, which renders only the current file, this approach is ideal for quickly
-verifying edits across the entire documentation during development.
-
 
 #### IDE integration
 
-For live previews, warnings, and linting during development,
-integrate Esbonio with your IDE (e.g., VS Code):
+For live previews, warnings, and linting during development, integrate Esbonio with your IDE (e.g., VS Code):
 
 ```sh
-bazel run //docs:ide_support
+bazel run //:ide_support
 ```
 
 VS Code: Install the Esbonio extension in VS Code. After installation, restart your IDE.
-You should now have live preview available when you open a `.rst` file.
-Note: if the extension was already installed when you ran the `ide_support` command,
-you will need to restart your IDE.
+You should now have live preview available when you open a `.rst` file.  
 
-For features like type detection in conf.py or extensions,
-point your IDE to the .venv_docs virtual environment.
+> Note: if the extension was already installed when you ran the `ide_support` command,
+you will need to restart your IDE.  
 
+For features like type detection in conf.py or extensions,
+point your IDE to the .venv_docs virtual environment.  
 Re-run //docs:ide_support if you update Sphinx extensions or other dependencies.
 
-#### IDE independent live preview
-
-For a documentation live preview independent of an IDE (CLI + browser only), `sphinx-autobuild` can be used.
-This will automatically rebuild the preview after save and have it available at http://127.0.0.1:8000
-Release and latest are both available here as well.
-```sh
-bazel run //docs:live_preview_latest # use current main branch of imported docs repositories (e.g. process_description)
-bazel run //docs:live_preview_release # use release version imported in MODULE.bazel
-```
-
 
 ### Testing
 
@@ -116,8 +85,9 @@ Grouping of tests via tags is also supported:
 ```sh
 $ bazel test --test_tag_filters=docs-build
 ```
-You can add as many tags as you like, as long as a test has at least one of the tags it will be executed.
-*Note: In order for a test to be picked up by this it has to be marked with the tag. Read more [here](/tools/testing/pytest/README.md)
+You can add as many tags as you like, as long as a test has at least one of the tags it will be executed.  
+
+> *Note: In order for a test to be picked up by this it has to be marked with the tag. Read more [here](/tools/testing/pytest/README.md)
 
 
 ### Test coverage for Python
@@ -126,7 +96,7 @@ To generate coverage data for Python test targets, run the following command:
 ```sh
 bazel coverage --combined_report=lcov //docs:score_metamodel_test
 ```
-This generates a coverage file `_coverage_report.dat` in the folder `bazel-out/_coverage` for the Python test target `//docs:score_metamodel_test`.
+This generates a coverage file `_coverage_report.dat` in the folder `bazel-out/_coverage` for the Python test target `//docs:score_metamodel_test`.  
 Replace the target to execute coverage for a different test target.
 
 You can use the tool `genhtml` to generate an HTML report as follows:
@@ -135,7 +105,7 @@ genhtml --ignore-errors mismatch --branch-coverage --output genhtml "$(bazel inf
 ```
 This generates an HTML report in the folder `genhtml` which shows both line and branch coverage. Open file `genhtml/index.html` in a browser to show the report.
 
-The tool `genhtml` is part of the `lcov` toolchain (https://github.com/linux-test-project/lcov).
+The tool `genhtml` is part of the `lcov` toolchain (https://github.com/linux-test-project/lcov).  
 You can install it on Debian/Ubuntu system as follows:
 ```sh
 sudo apt update
@@ -145,13 +115,11 @@ sudo apt install lcov
 
 ### Notes
 #### Output Locations
-* Bazel builds output, depending on which build was chosen:
-    - bazel-bin/docs/docs_latest/_build/html. 
-    - bazel-bin/docs/docs_release/_build/html. 
+* Bazel builds output in the `_build` directory (cmd: `bazel run //:docs`)
 * Incremental builds output to _build, regardless of chosen way.
 
 #### Troubleshooting
 * Restart your IDE if live previews or warnings are not working after running ide_support.
 * Ensure your virtual environment is up-to-date by re-running //docs:ide_support when dependencies
   change.
-* Ensure you ran //docs:ide_support before executing //:format.check or //:format.fix
+* Ensure you ran //:ide_support before executing //:format.check or //:format.fix
@@ -31,7 +31,7 @@ The following shows the folder structure of the platform repository (ordered alp
                docs/                   -> Documentation of the feature
                    architecture/       -> Feature architecture [:need:`PROCESS_wp__feature_arch`]
                    requirements/       -> Feature requirements [:need:`PROCESS_wp__requirements__feat`]
-                   safety_analysis/    -> Safety analysis on feature level [:need:`PROCESS_wp__feature_safety_analysis`]
+                   safety_analysis/    -> Safety analysis on feature level [:need:`PROCESS_wp__feature_fmea`, :need:`PROCESS_wp__feature_dfa`, :need:`PROCESS_wp__platform_dfa`]
                    safety_planning/    -> Feature specific safety workproducts planning
                    verification/       -> Feature verification report (reporting all feature verifications)
                                              [:need:`PROCESS_wp__verification__platform_ver_report`]
@@ -102,7 +102,7 @@ The modules and components shall follow the folder structure which was presented
                                              [:need:`PROCESS_wp__component_arch`].
             requirements/              -> Component requirements [:need:`PROCESS_wp__requirements__comp`]
             safety_analysis/           -> Safety analysis on component level
-                                             [:need:`PROCESS_wp__sw_component_safety_analysis`]
+                                             [:need:`PROCESS_wp__sw_component_fmea`, :need:`PROCESS_wp__sw_component_dfa` ]
             verification/              -> Architecture review [:need:`PROCESS_wp__sw_arch_verification`],
                                              code inspection [:need:`PROCESS_wp__sw_implementation_inspection`]
             <lower_level_comp>/        -> Lower level component following <component_name> folder structure

@@ -58,7 +58,7 @@ Inter-process Communication Safety Work Products
       - :doc:`../architecture/index`
       - see below
 
-    * - :need:`PROCESS_wp__feature_safety_analysis`
+    * - :need:`PROCESS_wp__feature_fmea`, :need:`PROCESS_wp__feature_dfa`
       - <link to process>
       - <automated>
       - <link to issue>

@@ -372,13 +372,6 @@ None
           - <Link to WP>
           - <automated>
 
-        * - :need:`PROCESS_wp__feature_safety_analysis`
-          - :need:`PROCESS_gd_guidl__safety_analysis`
-          - :ndf:`copy('status', need_id='PROCESS_gd_guidl__safety_analysis')`
-          - <Link to issue>
-          - <Link to WP>
-          - <automated>
-
         * - :need:`PROCESS_wp__module_safety_manual`
           - :need:`PROCESS_gd_guidl__saf_plan_definitions`
           - :ndf:`copy('status', need_id='PROCESS_gd_guidl__saf_plan_definitions')`
@@ -414,7 +407,7 @@ None
           - <Link to WP>
           - <automated>
 
-        * - :need:`PROCESS_wp__platform_feature_dfa`
+        * - :need:`PROCESS_wp__platform_dfa`
           - :need:`PROCESS_gd_guidl__safety_analysis`
           - :ndf:`copy('status', need_id='PROCESS_gd_guidl__safety_analysis')`
           - <Link to issue>
@@ -582,7 +575,14 @@ None
           - <Link to WP>
           - <automated>
 
-        * - :need:`PROCESS_wp__sw_component_safety_analysis`
+        * - :need:`PROCESS_wp__sw_component_fmea`
+          - :need:`PROCESS_gd_guidl__safety_analysis`
+          - :ndf:`copy('status', need_id='PROCESS_gd_guidl__safety_analysis')`
+          - <Link to issue>
+          - <Link to WP>
+          - <automated>
+
+        * - :need:`PROCESS_wp__sw_component_dfa` 
           - :need:`PROCESS_gd_guidl__safety_analysis`
           - :ndf:`copy('status', need_id='PROCESS_gd_guidl__safety_analysis')`
           - <Link to issue>

@@ -325,8 +325,8 @@ Beside :need:`PROCESS_wp__verification__comp_int_test` and :need:`PROCESS_wp__ve
 following aspects define the coverage of the architectural design.
 
 - :need:`PROCESS_wp__sw_arch_verification` - done by walkthrough (QM) or inspection (safety-critical parts)
-- :need:`PROCESS_wp__sw_component_safety_analysis` for safety-critical parts
-- :need:`PROCESS_wp__feature_safety_analysis` for safety-critical parts
+- :need:`PROCESS_wp__sw_component_fmea` and :need:`PROCESS_wp__sw_component_dfa` for safety-critical parts
+- :need:`PROCESS_wp__feature_fmea` and :need:`PROCESS_wp__feature_dfa` for safety-critical parts
 
 Each architectural element has at least one test case linked with attribute "fully verified" or
 multiple test cases with attribute "partially verified".