## 1 Classification key for CSs  
SoS involves an integrated configuration of CSs, typically characterized by the architecture of a large number and technological diversity of CSs. Effective quality management within a SoS demands the systematic mapping and classification of these CSs. This classification serves as the basis for tailoring specific quality management mechanisms to each CS, facilitating organized prioritization and resource management. This strategy represents an elaboration and extension of the foundational principle outlined as base anchor 4 in the research by [PERSON] et al. [1]. This study introduces a classification key for CSs within a SoS project, serving as a strategic tool for quality management. This framework, depicted in Figure 6, utilizes four defined primary parameters, each parameter spanning a continuum. CS classification is, thus, determined by its position on these continuums, rather than the mere presence or absence of certain parameters. The decision on the number of distinct classes into which CSs are organized is an administrative decision of the G-QMS in SoS.  
With regard to base anchors 5 and 6 of [PERSON] et al. [1], this CS classification is an extension of the QMS standards. AS9100 introduces particular concepts like CI and PS, which can be integral within a feature that characterizes CSs within a SoS. As such, a CS that encompasses numerous CIs, or has significant safety implications, would likely score higher on the classification parameters 1-3. This nuanced approach to classification draws from the literature on SoS attributes [27; 29; 52; 70], suggesting that the distinction of SoS configurations depends on the degree of certain attributes rather than their mere presence. However, this study focuses on mapping and classifying individual CSs, aiming to tailor quality management practices to each CS's unique role and complexity within the SoS. The classification framework, determined by a set of several classes (types), ranks CSs into types based on a calculated score from the levels of the four main parameters. As the CS is classified in a higher type, then _additional unique quality requirements_ shall be defined for it, and the monitoring and control operations by the G-QMS will be _tightened_.  
Figure 6: Classification key for CSs.  
According to this key and the base definition given by [PERSON] et al. [1]: \"\(S_{X}-\textit{Dimension of Classification according to the classification of the constituent systems (SoSx)}\)\". Here, we suggest an extended notation: \(S_{X}-QMS_{CS-typeX}\), or in short, \(QMS_{CS_{x}}\). Here, X designates the classed type, and the number of types can differ from one SoS project to another. For example, CS type A will be symbolized as follows: \(S_{A}-QMS_{CS-typeA}\) or \(QMS_{CS_{A}}\). To complete the notation, we added the letter Y to identify the specific system, resulting in the following: \(S_{X_{y}}-QMS_{CS-typeX_{y}}\) (\(QMS_{CS_{x_{y}}}\)). For example, CS specific 1, classified as type A, will be referred to as follows: \(S_{A_{1}}-QMS_{CS-typeA_{1}}\) (\(QMS_{CS_{A_{1}}}\)). Furthermore, the CSs classification projects directly on the interface entity \(QMS_{[\textit{integ\_CS}]}\), and so characterizes these entities with classification levels as follows: \(QMS_{[\textit{integ\_CS}s_{y}]}\).