Doc: Implementation Process Description

docs/_tooling/extensions/score_metamodel/checks/id_format_and_length.py

@@ -28,7 +28,7 @@ def check_id_format(app: Sphinx, need: NeedsInfoType, log: CheckLogger):
     parts = need["id"].split("__")
 
     if need["id"].startswith(
-        ("gd_", "wf__", "wp__", "rl__", "tool_req__", "doc__")
+        ("gd_", "wf__", "wp__", "rl__", "stkh_req__", "tool_req__", "doc__")
     ) or ("process/" in need.get("docname", "")):
         if len(parts) != 2 and len(parts) != 3:
             msg = "expected to consisting of one of these 2 formats:`<Req Type>__<Abbreviations>` or `<Req Type>__<Abbreviations>__<Architectural Element>`."

docs/_tooling/extensions/score_metamodel/metamodel.yaml

@@ -335,6 +335,59 @@ needs_types:
     mandatory_links:
       implements: "^feat_arc_int_op__.*$"
 
+  # Detailed Design
+  unit_dd_sta:
+    title: "Detailed Design Static View"
+    prefix: "unit_dd_sta__"
+    color: "#FEDCD2"
+    style: "card"
+    mandatory_options:
+      id: "^unit_dd_sta__[0-9a-z_]*$"
+      security: "^(YES|NO)$"
+      safety: "^(QM|ASIL_B|ASIL_D)$"
+      status: "^(valid|invalid)$"
+    mandatory_links:
+    # implements: "^comp_req__.*$"
+
+  unit_dd_dyn:
+    title: "Detailed Design Dynamic View"
+    prefix: "unit_dd_dyn__"
+    color: "#FEDCD2"
+    style: "card"
+    mandatory_options:
+      id: "^unit_dd_dyn__[0-9a-z_]*$"
+      security: "^(YES|NO)$"
+      safety: "^(QM|ASIL_B|ASIL_D)$"
+      status: "^(valid|invalid)$"
+    mandatory_links:
+    #implements: "^comp_req__.*$"
+
+  unit_dd:
+    title: "Detailed Design Units"
+    prefix: "unit_dd__"
+    color: "#FEDCD2"
+    style: "card"
+    mandatory_options:
+      id: "^unit_dd__[0-9a-z_]*$"
+      security: "^(YES|NO)$"
+      safety: "^(QM|ASIL_B|ASIL_D)$"
+      status: "^(valid|invalid)$"
+    mandatory_links:
+    #implements: "^comp_req__.*$"
+
+  unit_dd_int:
+    title: "Detailed Design Interfaces"
+    prefix: "unit_dd_int__"
+    color: "#FEDCD2"
+    style: "card"
+    mandatory_options:
+      id: "^unit_dd_int__[0-9a-z_]*$"
+      security: "^(YES|NO)$"
+      safety: "^(QM|ASIL_B|ASIL_D)$"
+      status: "^(valid|invalid)$"
+    mandatory_links:
+    #implements: "^comp_req__.*$"
+
 # Extra link types, which shall be available and allow need types to be linked to each other.
 # We use a dedicated linked type for each type of a conncetion, for instance from
 # a specification to a requirement. This makes filtering and visualization of such connections

docs/platform_management_plan/software_development.rst

@@ -11,17 +11,134 @@
    #
    # SPDX-License-Identifier: Apache-2.0
    # *******************************************************************************
-
 .. _sw_development:
 
 Software Development
-------------------------
+--------------------
+
+.. document:: Software Development Plan
+   :id: doc__software_development_plan
+   :status: draft
+   :safety: ASIL_B
+   :realizes: wp__sw_development_plan
+   :tags: platform_management
 
 Purpose
 +++++++
 
-Objectives and scope
+The main purpose of the software development plan is to define several software development related conditions:
+
+* selection of design and programming language
+* design guideline
+* coding guideline (e.g. MISRA, can also include style guide or naming convention)
+* SW configuration guideline
+* development tools
+
+Objectives and Scope
 ++++++++++++++++++++
 
+Objective is to define the main SW development policies as defined in the "Purpose" in an ISO 26262 and ASPICE compliant manner.
+Scope is the complete SW platform and the development parts of the process.
+
 Approach
 ++++++++
+
+Design and programming language
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For specifying **Detailed Design** (like for the Architecture) a mixture of UML diagrams and natural language is used.
+Additionally for the Detailed Design linking to code, Doxygen style comments are used.
+This is described in :need:`doc_concept__imp__concept` and guided by :need:`gd_temp__detailed_design`
+
+As required in :need:`stkh_req__dev_experience__prog_languages`, S-CORE allows the use of two programming languages:
+
+**C++ with the language set of C++17** - in case additional elements from C++20 are needed this will be considered by
+:need:`rl__safety_manager`, :need:`rl__security_manager` and :need:`rl__quality_manager`
+and based on their analysis decided by the technical tead circle (:need:`rl__technical_lead`).
+
+**Rust - in "Edition" <tbd>** - selection of language edition has still to be done in the S-CORE project.
+For the Rust code of ASIL rated units the "safe subset" shall be used (which is checked by the compiler by configuration of #![forbid(unsafe_code)] in lib.rs)
+
+C language is allowed in incubation phase, as long it is compilable be the selected compiler, but not for a S-CORE release.
+
+Design guideline
+^^^^^^^^^^^^^^^^
+
+The design guideline is defined in :need:`doc_concept__imp__concept` and :need:`gd_guidl__implementation`.
+
+Coding guideline
+^^^^^^^^^^^^^^^^
+
+**C++** - see :need:`gd_guidl__cpp_coding_guidelines`
+
+**Rust** - state of the art open source Rust guidelines are currently developed by `Safety Critical Rust Consortium <https://github.com/rustfoundation/safety-critical-rust-consortium/>`_
+(which will be adopted by the S-CORE project)
+
+SW configuration guideline
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+<tbd>
+
+SW development tools
+^^^^^^^^^^^^^^^^^^^^
+
+This list will evolve into the complete "Tool List" for the S-CORE project used for
+tool evaluation and qualification. In the moment the :need:`doc__verification_plan`
+contains additional tools used in verification.
+
+Additional tools for static and dynamic analysis (in addition to compilers and Clang-Tidy) are currently evaluated: `#244 <https://github.com/eclipse-score/score/issues/244>`_
+
+.. rubric:: GitHub
+
+is used for hosting, versioning and contribution of the software. Within
+pull requests it's possible to contribute. For contribution a seperate process description is
+<Link to contribute> available. In the discussion section the informations regarding meeting
+minutes and Working Sections were stored. Within issues can bugfixes, improvements, blank issues
+set up. It's also possible to report there Security vulnerabilities. GitHub Actions is used
+as a support for continuous integration.
+
+.. rubric:: Sphinx
+
+is used for software documentation to generate html-sides from reStructuredText.
+
+.. rubric:: Sphinx-Needs
+
+is used for docs-as-code based documentation that is created
+and managed by the sphinx documentation generator. With "needs" objects, created in rst-files,
+requirements, static architecture views and other Sw development documentation is generated. Sphinx-Needs is 100% compliant to
+Sphinx and reStructuredText.
+
+.. rubric:: PlantUML
+
+this UML drawing tool is used for dynamic and static diagrams for unit interaction. Also for dynamic architecture views.
+
+.. rubric:: Draw.io
+
+this drawing tool is used to create flowcharts and diagrams for all uses where PlantUML is not suited
+e.g. in process or concept descriptions
+
+.. rubric:: Host Compiler C++
+
+GCC is usesd as host C++ compiler with its associated linker. It's used as a development (compilation and linking) and verification tool
+as it generates compiler warnings and builds unit tests and binaries for SW integration testing.
+
+.. rubric:: Target Compiler C++
+
+QCC the qualifiable compiler/linker from Blackberry offered together with its Posix conform Operating System QNX is planned to be used for target compilation.
+
+.. rubric:: Clang-tidy
+
+is used in conjunction with the Clang compiler to perform static analysis.
+
+.. rubric:: Host Compiler Rust
+
+There is currently no selection of a Rust compiler for S-CORE. Pick your own favourite.
+
+.. rubric:: Target Compiler Rust
+
+The qualified `Ferrocene <https://github.com/ferrocene>`__ compiler is planned to be used.
+
+.. rubric:: Bazel
+
+The main build environment of the project is based on `Bazel <https://bazel.build>`__. It it used to build software
+components, documentation, and automated tests.

docs/platform_management_plan/software_verification.rst

@@ -289,7 +289,7 @@ following aspects define the coverage of detailed design.
 
 - Statement/Branch/Path coverage as defined by their specific thresholds
 - Static analysis and Linting
-- :need:`wp__sw_code_inspect` for safety-critical implementation
+- :need:`wp__sw_implementation_inspection` for safety-critical implementation
 
 Coverage of architectural design
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

docs/process/process_areas/implementation/_assets/dd_example_ex_dyn.puml

@@ -0,0 +1,30 @@
+/'
+   # *******************************************************************************
+   # Copyright (c) 2024 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
+   # *******************************************************************************
+'/
+..
+
+@startuml
+
+title Sequence Diagram - unit1 & unit2
+
+participant "unit1" as unit1
+participant "unit2" as unit2
+
+unit1 -> unit2 : api1
+unit2 --> unit1 : int
+
+unit1 -> unit2 : api3
+unit2 --> unit1 : int
+
+@enduml

docs/process/process_areas/implementation/_assets/dd_example_ex_sta.puml

@@ -0,0 +1,37 @@
+/'
+   # *******************************************************************************
+   # Copyright (c) 2024 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
+   # *******************************************************************************
+'/
+..
+
+@startuml
+
+title Static View - dd example
+
+skinparam component {
+    BackgroundColor<<component>> white
+}
+
+skinparam rectangle {
+    BackgroundColor<<unit>> green
+}
+
+' Define Features
+component "component1" <<component>> {
+    rectangle "unit1" as unit1 <<unit>>
+    rectangle "unit2" as unit2 <<unit>>
+}
+
+unit1 ..> unit2 : uses
+
+@enduml

docs/process/process_areas/implementation/_assets/detailed_design_example.rst

@@ -0,0 +1,86 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 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
+   # *******************************************************************************
+
+Detailed Design for Component: component1
+=========================================
+
+Description
+-----------
+
+ - component is split into two units unit1 and unit2 based on single responsibility principle.
+ - unit2 is injected to unit1 one via dependency injection for testability.
+
+
+Static Diagrams for Unit Interactions
+-------------------------------------
+
+.. unit_dd_sta:: dd example static
+    :id: unit_dd_sta__dd_example_static
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+.. uml:: dd_example_ex_sta.puml
+
+Dynamic Diagrams for Unit Interactions
+--------------------------------------
+
+.. unit_dd_dyn:: dd example dynamic
+    :id: unit_dd_dyn__dd_example_dynamic
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+.. uml:: dd_example_ex_dyn.puml
+
+Units within the Component
+--------------------------
+
+.. unit_dd:: unit1
+    :id: unit_dd__unit1
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+    Placeholder for the description that will be generated from doxygen
+
+Interface
+*********
+
+.. unit_dd_int:: int1
+    :id: unit_dd_int__unit1_int1
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+    Placeholder for the description that will be generated from doxygen
+
+.. unit_dd:: unit2
+    :id: unit_dd__unit2
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+    Placeholder for the description that will be generated from doxygen
+
+Interface
+*********
+
+.. unit_dd_int:: int2
+    :id: unit_dd_int__unit2_int2
+    :security: NO
+    :safety: ASIL_B
+    :status: valid
+
+    Placeholder for the description that will be generated from doxygen