## 4 Results
This means checking whether the model and the SoS still correspond to the principles and rules defined by semantics and the meta-model, or if there are any deviations. Verification and validation are mentioned in almost every article on MBSE. For instance, reference [73] stresses that with the growing maturity of model-based design and construction, there is an accompanying rise in the need for system-centric methodologies and toolsets. These aid in supporting system integration, requirement management, verification, validation, and configuration management, which are crucial if model-based information is to effectively assist in the operation of complex civil building infrastructure projects. Continuous **validation** is a key principle mentioned both in MBSE theory and in publications [39]. Validation, in contrast to verification, aims not to check the entire complex technical system and its model for compliance with general rules and its theoretical correctness, but to check (test) the characteristics of individual components of the model. In particular this includes checking for compliance with the ontology, checking for compliance with the behavior of the model and the real object, and maintaining connectivity with other system components. To verify and validate a complex technical system for safety and stability, the principle of **reverse functionality** is used [112; 113; 114; 115]; the state of a complex technical system is built, in which the performance of functions is disrupted or not performed, failures occur, processes do not work in the standard mode, and components are broken. In this case, the result can be achieved by building connections between the system and the \"anti-system\", between functions and anti-functions, and between processes and anti-processes. Through these connections, it is possible to determine the mechanisms for the occurrence of an emergency and the connection of this mechanism with other components and possible sources of occurrence. The principle of inverse functionality is considered as one of the stages in the application of MBSE, as outlined in [113]. This suggests that the second step involves generating functional failure modes and other related failure modes and effects analysis (FMEA) data defined by or specific to customer-required data needs. The task of failure mode generation could be as straightforward as converting a functional statement into an anti-function statement to describe a failure mode. **Ontology** is a special case of metamodeling of a particular considered subsystem or system component [116; 117; 118; 119; 120; 34; 46; 69; 80; 81; 82; 83; 84; 85; 86; 87; 88; 89; 90; 91; 92; 93; 94; 95; 96; 97; 98; 99; 100; 108; 116; 117; 118; 119; 120]. When constructing an ontology, the rules for a given component, its semantics, information about it, and its attributes are determined. The use of ontology, in essence, is referenced in [121], where a knowledge repository is described as a central component of the methodology. This repository accumulates expertise, experiences, patterns, and reference models, promoting the reuse of experiences by enhancing their model with best practice patterns or by avoiding repetition of past errors. The primary goal is to improve efficiency during the commissioning design and execution phases. As the work primarily revolves around models, the most crucial elements of the knowledge repository are patterns and reference models. One of the main principles of the application of MBSE, which also provides interoperability, is the principle of **subjectivity** (context) [122; 123; 124; 96; 99; 92; 125; 34; 81]. Following this principle, a complex technical system is modeled, developed, and used in different contexts from different points of view with respect to specific tasks and industries. At the same time, the complete system combines all these contexts into a single whole unit.