## 3 Method
### Knowledge Representation of the Design Process for MC  
In order to obtain computer- and human-processable knowledge representation, the superordinate representation type is an ontology, as this is characterized by high flexibility, reusability, and adaptability [52; 53]. Following the latest design criteria defined by [PERSON] [11], whereby an ontology should require minimal ontological commitment, we claim only a few axioms (see Table 1) about the following concepts. Thus, those concepts can be specialized for certain MC processes: Transition, State, Beginning State, Objective State, Initial State, Terminal State, Design Parameter, Design Process, Design Task, Design Rationale, Requirement, and Solution Principle. In addition, generally accepted concepts are applied e.g., Type, Value, and Unit. The concepts of States are further extended by the axioms demonstrated in Table 1.  
As the various types of states demonstrated in Table 1 define snapshots of the product on the chronological axis, Transitions specify their sequences in the process model and their design intent as well as hierarchical relations by Design Rationale. The concepts of Transitions are further extended by the axioms demonstrated in Table 2. \begin{table}
\begin{tabular}{l l} \hline \hline
**SeEDMC’s Concepts for States** & **Axioms** \\ \hline State & has \(n\geq 1\in\mathbb{N}\) Design Parameters. \\ Beginning State & is a State. \\ Objective State & is a State. \\ Initial State & is a State; disjoint Objective State. \\ Terminal State & is a State; disjoint Beginning State. \\ Design Parameter & has Value; has Unit. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Axioms for States. The Solution Principle excels as it contains exactly one source file. This source file represents the relationships between the Design Rationale (requirements) and Design Parameters in the form of logical, statistical, or mathematical mapping:  
\[\textit{Solution Principle}:\textit{Design Rationale}\mapsto\textit{Design Parameters} \tag{1}\]  
Therefore, a Solution Principle has \(\hat{r}\geq 1\in\mathbb{N}\) forms of Design Rationale as inputs and \(\hat{n}\geq 1\in\mathbb{N}\) Design Parameters as outputs. Depending on the considered domain of interest, solution principles differ in their types of representation. In many cases, markup languages or scripts are sufficient. Typically, principled solutions are stored and managed in catalogs [54]. The axioms shown in Tables 1 and 2 were designed to represent the model described in Section 3.1. In a hypothetical MC process, at least one Design Parameter is adjusted due to individual requirements. The requirement modification can only be quantitative. New additional requirements cannot be taken into account, as otherwise the principle solution would have to be changed, and this would no longer be within the capabilities and scope of the model. Accordingly, there is at least one Transition and two States. If only these exist, the State prior to the Transition is automatically identified as the Initial State, since it is never used as an Objective State of any Transition. Similarly, the State subsequent to the Transition is the Terminal State. The individual requirement modifications specify the Design Rationale of the Transition. If this modification can be implemented by a single solution principle, the Transition is a Design Task that can perform the MC Process. No outputs for subordinate Transitions are required. If this is not the case, it is, by definition, a Design Process, which is used to reflect at least part of the known product's modular structure. Consequently, the Design Process has at least two outputs, which split the Design Rationale from the input among the hierarchically subordinate Transitions.