|
| 1 | +.. |
| 2 | + # ******************************************************************************* |
| 3 | + # Copyright (c) 2025 Contributors to the Eclipse Foundation |
| 4 | + # |
| 5 | + # See the NOTICE file(s) distributed with this work for additional |
| 6 | + # information regarding copyright ownership. |
| 7 | + # |
| 8 | + # This program and the accompanying materials are made available under the |
| 9 | + # terms of the Apache License Version 2.0 which is available at |
| 10 | + # https://www.apache.org/licenses/LICENSE-2.0 |
| 11 | + # |
| 12 | + # SPDX-License-Identifier: Apache-2.0 |
| 13 | + # ******************************************************************************* |
| 14 | +
|
| 15 | +Component Classification |
| 16 | +======================== |
| 17 | + |
| 18 | + |
| 19 | +.. document:: Log Component Classification |
| 20 | + :id: doc__log_comp_class |
| 21 | + :status: draft |
| 22 | + :safety: QM |
| 23 | + :security: NO |
| 24 | + :realizes: wp__sw_component_class |
| 25 | + :tags: log |
| 26 | + |
| 27 | + |
| 28 | +| Classification of <component> |
| 29 | +| |
| 30 | +| <Link to OSS component source (e.g. in github) including the selected version> |
| 31 | +| |
| 32 | +| Additional documentation considered: |
| 33 | +| <list of documentation links> |
| 34 | +
|
| 35 | + |
| 36 | +Step 1: Determine (P): the uncertainty of the Processes applied |
| 37 | +--------------------------------------------------------------- |
| 38 | + |
| 39 | +| Apply the process measures to determine (P). |
| 40 | +| The result of a process measure shall have as outcome [HE, PE, NE] |
| 41 | +| - HE: High Evidence |
| 42 | +| - PE: Partly Evidence but Manageable |
| 43 | +| - NE: No Evidence |
| 44 | +
|
| 45 | +.. list-table:: Determine (P) |
| 46 | + :header-rows: 1 |
| 47 | + |
| 48 | + * - Id |
| 49 | + - Indicator for applying process |
| 50 | + - Result |
| 51 | + - Rationale for result |
| 52 | + |
| 53 | + * - 1 |
| 54 | + - Are rules, state-of-the art processes applied for the design, implementation and verification? |
| 55 | + - <HE|PE|NE> |
| 56 | + - <Rationale for result> |
| 57 | + |
| 58 | + * - 2 |
| 59 | + - Are requirements available? |
| 60 | + - <HE|PE|NE> |
| 61 | + - <Rationale for result> |
| 62 | + |
| 63 | + * - 3 |
| 64 | + - Are specifications for functionalities and properties available (architecture)? |
| 65 | + - <HE|PE|NE> |
| 66 | + - <Rationale for result> |
| 67 | + |
| 68 | + * - 4 |
| 69 | + - Are design specifications available? |
| 70 | + - <HE|PE|NE> |
| 71 | + - <Rationale for result> |
| 72 | + |
| 73 | + * - 5 |
| 74 | + - Are configuration specification and data available, if applicable? |
| 75 | + - <HE|PE|NE> |
| 76 | + - <Rationale for result> |
| 77 | + |
| 78 | + * - 6 |
| 79 | + - Are verification measures including tests and reports available? |
| 80 | + - <HE|PE|NE> |
| 81 | + - <Rationale for result> |
| 82 | + |
| 83 | + |
| 84 | +| (P=1) shall be selected when none of the determined process measures indicate PE or NE. |
| 85 | +| (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 |
| 86 | +| the risk of systematic faults due to these gaps is sufficiently low or manageable by mitigating the gaps. |
| 87 | +| (P=3) in all other cases. |
| 88 | +
|
| 89 | +<component name> is determined as P=<1|2|3> |
| 90 | + |
| 91 | + |
| 92 | +Step 2: Determine (C): the uncertainty of finding systematic faults based on the Complexity |
| 93 | +------------------------------------------------------------------------------------------- |
| 94 | + |
| 95 | +| Apply the complexity measures to determine (C). |
| 96 | +| The result of a complexity measure shall have as outcome [NH, HM, NM] |
| 97 | +| - NH: Not High |
| 98 | +| - HM: High but Manageable |
| 99 | +| - NM: high and Not Manageable |
| 100 | +| |
| 101 | +| **Complexity measure for programming language: <C++ or RUST>** |
| 102 | +
|
| 103 | +<select the correct table below (table for C++ is TBD)> |
| 104 | + |
| 105 | +.. list-table:: Determine (C) for RUST |
| 106 | + :header-rows: 1 |
| 107 | + |
| 108 | + * - Id |
| 109 | + - Indicator for high Complexity |
| 110 | + - Complexity measure Tool |
| 111 | + - Result |
| 112 | + - Number |
| 113 | + |
| 114 | + * - 1 |
| 115 | + - High amount of Lines of Code |
| 116 | + - Lines of Code (without comments) (generated code is excluded, e.g. ProtoCmpl) |
| 117 | + - <NH|HM|NM> |
| 118 | + - <Number> |
| 119 | + |
| 120 | + * - 2 |
| 121 | + - Unsafe code used / total unsafe code |
| 122 | + - Count: |
| 123 | + * LoUC+N: lines of unsafe code with safety note |
| 124 | + * LoUC : lines of unsafe code, no safety note |
| 125 | + - <NH|HM|NM> |
| 126 | + - <Number> |
| 127 | + |
| 128 | + * - 3 |
| 129 | + - | Test exists / Coverage (Function, Line) |
| 130 | + | (maybe better: testability, but how to measure?) |
| 131 | + - Existing Tests Coverage |
| 132 | + - <NH|HM|NM> |
| 133 | + - <Number> |
| 134 | + |
| 135 | + * - 4 |
| 136 | + - High amount of public function interfaces |
| 137 | + - Number of public function interfaces |
| 138 | + - <NH|HM|NM> |
| 139 | + - <RNumber> |
| 140 | + |
| 141 | + * - 5 |
| 142 | + - High amount of function parameters |
| 143 | + - Number of parameters |
| 144 | + - <NH|HM|NM> |
| 145 | + - <Number> |
| 146 | + |
| 147 | + |
| 148 | +| (C=1) shall be selected when none of the determined complexity measures indicate HM or NM. |
| 149 | +| (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 |
| 150 | +| the risk of systematic faults due to these gaps is sufficiently low in the context of the project or manageable by mitigating the gaps. |
| 151 | +| (C=3) in all other cases. |
| 152 | +| |
| 153 | +
|
| 154 | +<component name> is determined as C=<1|2|3> |
| 155 | + |
| 156 | + |
| 157 | +Step 3: Determine (CLAS_OUT): the classification outcome |
| 158 | +-------------------------------------------------------- |
| 159 | + |
| 160 | +| Select CLAS_OUT depending on the determined values of (C) and (P) |
| 161 | +
|
| 162 | ++-------+-----------------------+ |
| 163 | +| ( C ) | ( P ) | |
| 164 | ++-------+-------+-------+-------+ |
| 165 | +| | 1 | 2 | 3 | |
| 166 | ++=======+=======+=======+=======+ |
| 167 | +| 1 | Q | Q | QR | |
| 168 | ++-------+-------+-------+-------+ |
| 169 | +| 2 | QR | QR | QR | |
| 170 | ++-------+-------+-------+-------+ |
| 171 | +| 3 | QR | QR | NQ | |
| 172 | ++-------+-------+-------+-------+ |
| 173 | + |
| 174 | +<component name> is classified as CLAS_OUT=<Q|QR|NQ> |
| 175 | + |
| 176 | + |
| 177 | +Step 4: Document all results and rationale for choosing (P) and (C) and (CLAS_OUT) |
| 178 | +---------------------------------------------------------------------------------- |
| 179 | +This document |
| 180 | + |
| 181 | + |
| 182 | +Step 5: Based on (CLAS_OUT) select the activities |
| 183 | +------------------------------------------------- |
| 184 | + |
| 185 | +| 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) |
| 186 | +| - Q: Follow the processes for qualification of software components in a safety context. |
| 187 | +| - QR: Follow the process for pre-existing software architectural elements |
| 188 | +| - NQ: Do no use this element in safety context |
0 commit comments