Component Classification

Persistency Component Classification		status: valid security: NO safety: ASIL_B
tags: feature_persistency realizes: wp__sw_component_class
doc__persistency_component_classification		Generic Document

Classification of Tiny JSON

Tiny JSON V.2.5.1

Additional documentation considered:

Documentation for Tiny JSON

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 51 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?	PE	Rules for Safe Rust applied.
2	Are requirements available?	PE	n/a. Tiny JSON is a library to parse/generate JSON format document. So this is the main requirement.
3	Are specifications for functionalities and properties available (architecture)?	PE	Yes in the documentation of Tiny JSON.
4	Are design specifications available?	PE	n/a
5	Are configuration specification and data available, if applicable?	PE	Yes in the documentation of Tiny JSON.
6	Are verification measures including tests and reports available?	HE	Stored in github repo within folder tests.

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

Tiny JSON determined as P=2.

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>

Table 52 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	2367 loc
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. Tiny JSON is written in Safe Rust.	0
3	Test exists / Coverage (Function, Line) (maybe better: testability, but how to measure?)	Existing Tests Coverage	NH	<Number>
4	High amount of public function interfaces	Number of public function interfaces	NH	<Number>
5	High amount of function parameters	Number of parameters	NH	<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.

Tiny JSON 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

Tiny JSON 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 contribution request containing this is in status “Accepted”, the module safety plan for the component development is adapted based on the following:

- Q: Follow the processes for qualification of software components in a safety context.