Skip to content

Remove duplicate classification template #660

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
masc2023 merged 1 commit into from
Apr 15, 2026
Merged

Remove duplicate classification template #660

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 24 additions & 12 deletions ..._templates/modules/module_name/component_name/docs/component_classification.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -167,17 +167,29 @@ Step 3: Determine (CLAS_OUT): the classification outcome

| Select CLAS_OUT depending on the determined values of (C) and (P)

+-------+-----------------------+
| ( C ) | ( P ) |
+-------+-------+-------+-------+
| | 1 | 2 | 3 |
+=======+=======+=======+=======+
| 1 | Q | Q | QR |
+-------+-------+-------+-------+
| 2 | QR | QR | QR |
+-------+-------+-------+-------+
| 3 | QR | QR | NQ |
+-------+-------+-------+-------+
.. list-table::
:header-rows: 1
:widths: 20 20 20 20

* -
- P=1
- P=2
- P=3

* - C=1
- Q
- Q
- QR

* - C=2
- QR
- QR
- QR

* - C=3
- QR
- QR
- NQ

<component name> is classified as CLAS_OUT=<Q|QR|NQ>

Expand All @@ -193,4 +205,4 @@ Step 5: Based on (CLAS_OUT) select the activities
| As soon as the change request containing this is in status "Accepted", the module safety plan for the component development is adapted based on the following: (select according to above result)
| - Q: Follow the processes for qualification of software components in a safety context.
| - QR: Follow the process for pre-existing software architectural elements
| - NQ: Do no use this element in safety context
| - NQ: Do not use this element in safety context
163 changes: 1 addition & 162 deletions .../process_areas/safety_management/guidance/template_component_classification.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,165 +20,4 @@ Component Classification Template
:status: valid
:complies: std_req__isopas8926__441, std_req__isopas8926__4421, std_req__isopas8926__4422, std_req__isopas8926__4423, std_req__isopas8926__4424, std_req__isopas8926__4425, std_req__isopas8926__4426, std_req__isopas8926__4427, std_req__isopas8926__4428, std_req__isopas8926__4429, std_req__isopas8926__44210, std_req__iso26262__software_743, std_req__aspice_40__iic-12-03, std_req__aspice_40__iic-15-07


| Classification of <component>
|
| <Link to OSS component source (e.g. in github) including the selected version>
|
| Additional documentation considered:
| <list of documentation links>


Step 1: Determine (P): the uncertainty of the Processes applied
---------------------------------------------------------------

| Apply the process measures to determine (P).
| The result of a process measure shall have as outcome [HE, PE, NE]
| - HE: High Evidence
| - PE: Partly Evidence but Manageable
| - NE: No Evidence

.. list-table:: Determine (P)
:header-rows: 1

* - Id
- Indicator for applying process
- Result
- Rationale for result

* - 1
- Are rules, state-of-the art processes applied for the design, implementation and verification?
- <HE|PE|NE>
- <Rationale for result>

* - 2
- Are requirements available?
- <HE|PE|NE>
- <Rationale for result>

* - 3
- Are specifications for functionalities and properties available (architecture)?
- <HE|PE|NE>
- <Rationale for result>

* - 4
- Are design specifications available?
- <HE|PE|NE>
- <Rationale for result>

* - 5
- Are configuration specification and data available, if applicable?
- <HE|PE|NE>
- <Rationale for result>

* - 6
- Are verification measures including tests and reports available?
- <HE|PE|NE>
- <Rationale for result>


| (P=1) shall be selected when none of the determined process measures indicate PE or NE.
| (P=2) shall be selected when at least one of the determined process measures indicate PE or NE, but the gaps evaluated are acceptable, means
| the risk of systematic faults due to these gaps is sufficiently low or manageable by mitigating the gaps.
| (P=3) in all other cases.

<component name> is determined as P=<1|2|3>


Step 2: Determine (C): the uncertainty of finding systematic faults based on the Complexity
-------------------------------------------------------------------------------------------

| Apply the complexity measures to determine (C).
| The result of a complexity measure shall have as outcome [NH, HM, NM]
| - NH: Not High
| - HM: High but Manageable
| - NM: high and Not Manageable
|
| **Complexity measure for programming language: <C++ or RUST>**

<select the correct table below (table for C++ is TBD)>

.. list-table:: Determine (C) for RUST
:header-rows: 1

* - Id
- Indicator for high Complexity
- Complexity measure Tool
- Result
- Number

* - 1
- High amount of Lines of Code
- Lines of Code (without comments) (generated code is excluded, e.g. ProtoCmpl)
- <NH|HM|NM>
- <Number>

* - 2
- Unsafe code used / total unsafe code
- Count:
* LoUC+N: lines of unsafe code with safety note
* LoUC : lines of unsafe code, no safety note
- <NH|HM|NM>
- <Number>

* - 3
- | Test exists / Coverage (Function, Line)
| (maybe better: testability, but how to measure?)
- Existing Tests Coverage
- <NH|HM|NM>
- <Number>

* - 4
- High amount of public function interfaces
- Number of public function interfaces
- <NH|HM|NM>
- <RNumber>

* - 5
- High amount of function parameters
- Number of parameters
- <NH|HM|NM>
- <Number>


| (C=1) shall be selected when none of the determined complexity measures indicate HM or NM.
| (C=2) shall be selected when at least one of the determined complexity measures indicate HM or NM, but the gaps evaluated are acceptable, means
| the risk of systematic faults due to these gaps is sufficiently low in the context of S-CORE or manageable by mitigating the gaps.
| (C=3) in all other cases.
|

<component name> is determined as C=<1|2|3>


Step 3: Determine (CLAS_OUT): the classification outcome
--------------------------------------------------------

| Select CLAS_OUT depending on the determined values of (C) and (P)

+-------+-----------------------+
| ( C ) | ( P ) |
+-------+-------+-------+-------+
| | 1 | 2 | 3 |
+=======+=======+=======+=======+
| 1 | Q | Q | QR |
+-------+-------+-------+-------+
| 2 | QR | QR | QR |
+-------+-------+-------+-------+
| 3 | QR | QR | NQ |
+-------+-------+-------+-------+

<component name> is classified as CLAS_OUT=<Q|QR|NQ>


Step 4: Document all results and rationale for choosing (P) and (C) and (CLAS_OUT)
----------------------------------------------------------------------------------
This document


Step 5: Based on (CLAS_OUT) select the activities
-------------------------------------------------

| As soon as the change request containing this is in status "Accepted", the module safety plan for the component development is adapted based on the following: (select according to above result)
| - Q: Follow the processes for qualification of software components in a safety context.
| - QR: Follow the process for pre-existing software architectural elements
| - NQ: Do no use this element in safety context
For the content see here: :need:`doc__component_name_comp_class`
Loading