Component Classification#

Note

Document header

IAV Primula Component Classification		status: draft security: YES safety: QM
tags: iav_primula, iav_primula version: 0 realizes: wp__sw_component_class

doc__iav_primula_comp_class		Generic Document

Classification of iav_primula

GitHub: https://github.com/eclipse-score/inc_security_crypto/tree/main/score/t.b.d

Additional documentation considered:
- docs/index.rst
- docs/requirements/requirements.rst
- docs/architecture/component_architecture.rst

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

Table 34 Determine (P)#
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	Basic project rules are applied (Rust 2021 crate, tests, standard docs structure).
2	Are requirements available?	HE	Initial component requirements are documented.
3	Are specifications for functionalities and properties available (architecture)?	HE	Initial component architecture documentation is available.
4	Are design specifications available?	HE	Detailed design baseline exists for current low complexity scope.
5	Are configuration specification and data available, if applicable?	HE	No dedicated configuration data is currently required.
6	Are verification measures including tests and reports available?	HE	Hello-world test exists and verifies expected output.

(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.

iav_primula is determined as P=1

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: RUST

Table 35 Determine (C) for RUST#
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	1 function
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	0
3	Test exists / Coverage (Function, Line) (maybe better: testability, but how to measure?)	Existing Tests Coverage	NH	1 test present
4	High amount of public function interfaces	Number of public function interfaces	NH	1 public function
5	High amount of function parameters	Number of parameters	NH	0 parameters for public API

(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 the project or manageable by mitigating the gaps.

(C=3) in all other cases.

iav_primula is determined as C=1

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

iav_primula is classified as CLAS_OUT=Q

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