Category-Theoretic Formulation of Model-Based Systems Architecting: The Concept → Model → Graph → View → Concept Transformation Cycle

: We introduce the Concept → Model → Graph → View → Concept (CMGVC) transformation cycle. The CMGVC cycle facilitates coherent architecture analysis, reasoning, insight, and decision making based on conceptual models that are transformed into a common, robust graph data structure (GDS). The GDS is then transformed into multiple views on the model, which inform stakeholders in various ways. This GDS-based approach decouples the view from the model and constitutes a powerful enhancement of model-based systems engineering (MBSE). CMGVC applies the rigorous foundations of Category Theory, a mathematical framework of representations and transformations. The CMGVC architecture is superior to direct transformations and language-coupled common representations. We demonstrate the CMGVC cycle to transform a conceptual system architecture model built with the Object Process Modeling Language (OPM) into dual graphs and a decision support matrix (DSM) that stimulates system architecture insight


Introduction
Models represent concepts by capturing the ideas, observations, notions, theories, insights, and intents that people conceive of and wish to express and communicate to others [1].Conceptual models use syntax and semantics of a modeling language to describe the concepts.A popular example for generating a model for a concept depicts Isaac Newton's observation of gravity, and the ensuing formulation of Newton's Theory of Gravity, in the falling of an apple from a tree.Models represent scientific concepts, as projections of theories on phenomena; they describe and abstract phenomena, while relying on theories that may be hypothetical or partially validated [2].Likewise, models represent engineered, man-made systems in their current or future state [3].
Models also inform concepts: we can enrich our concept, perception, and subject matter understanding, by capturing, manipulating, contextualizing, composing, and analyzing concepts and aspects.Conceptual models play a central and growingly more critical role in complex systems development and operation.Models are supposed to capture and represent various relations and interactions, whose understanding is fundamental to comprehending solutions, designs, or operational processes.Models also have immense importance in facilitating stakeholder communication and discussion.The concept-model duo is therefore a binary self-enhancing system.
Model-Based Systems Engineering (MBSE) is the formalized application of models in systems engineering [4].MBSE facilitates the digital transformation of systems engineering: generating and communicating digitized SE deliverables up and down the value chain.[5].Digital systems engineering (DSE) increases the dependency on MBSE, which gradually becomes a value-focused approach, and not only a model-focused practice, and a critical asset for systems engineering in digital enterprises, as several studies show [6][7][8][9].
Generating stakeholder value out of model-based platforms is a primary expected outcome of DSE.Transforming system models into analyzable and reusable artifacts, decision-supporting information, and machine-generated insight is therefore a critical contribution to enterprise-wide DSE.A DSE ecosystem architecture defined in [10] specifies modeling, infrastructure, data services, simulation, testing, analysis, and repositories (MIDSTAR1) as primary DSE services, and management tools, interoperability services, digital representations, systems, things, auditing, and reporting services (MIDSTAR2) as primary interfaces.We shall refer collectively to such results or artifacts following model processing or analysis as views of those models.
Model-based views abstract, highlight, or pivot specific aspects, and become increasingly more impotant as models grow bigger and more complicated.Observing, reasoning about, processing, analyzing, and deciding according to such views results in ongoing concept revisions [11].The concept-model-view triangle is therefore a self-enhancing system that extends the concept-model duo.However, the potential combination of modeling languages (MLs), models, and views explodes: if every model were to be represented by every necessary view, the number of mappings would a product of the number of models  by the number of views , i.e.,  • .
In the absence of dynamic and robust model-to-view transforms, concept understanding is shaped by ML-bound views.A common representation across a wide variety of models (CR) that MLs could map into, and views could map out of, can make a difference.Graph data structures (GDS) can serve as CRs [12][13][14][15].They are simple, robust, extendable, and amenable to a huge collection of graph-theoretic algorithms.Graph and GDS are not completely interchangeable concepts.A graph is a visual representation of a subset of the GDS, and a GDS is a logical data structure that represents relations, which can be illustrated in graphs.The term graph is used for brevity when we refer to the GDS as a mediating data structure.However, a graph visualization of any portion of a GDS, whether raw or processes, is indeed a view of the model.A robust transformation infrastructure that would transform models into GDS, and generate views from GDS, will make models and views interoperable and interchangeable, and extend the collection of views that support model analysis.
A concept-model-graph-view quadratic cyclic system is potentially more effective, extensive, and efficient than the concept-model-view trio.The evolution from concept-model duos through concept-model-view trios to concept-model-graph-view-concept cycles is illustrated in Matrices are useful views of a model.Matrices facilitate analyzing quantitative and qualitative relations.A matrix is a bidimensional discrete data structure that lends itself to various mathematical or logical analyses.Matrices are common, intuitive, and easy to work with for scientists, engineers, and analysts.As graphic MLs evolved, matrices had not found a place as formal representation modalities, although matrix-like structures or layouts remained present to some extent in modeling frameworks.For instance, the IDEF0 notation advocates a diagonal layout of blocks which resembles the N 2 matrix of inter-component dependencies; UML Activity Diagram supports a "swimlane" layout which helps divide complex multi-participant activities into columns; and Sequence Diagrams apply a similar idea, using vertically-aligned lifelines, as anchors for input and output exchange.
Simple matrices are two-dimensional and non-hierarchical.This construct is insufficient for describing complex architectures.Requirements or structural elements are leaves in an asymmetric hierarchy, which may differ in depth and detail level.Therefore, the matrix kernel must be integrated with hierarchical representations of row and column entities.Advanced matrix representations for systems engineering include the Verification Cross-Reference Matrix (VCRM), Design Structure Matrix (DSM), and System Architecture Matrix (SAM).The Department of Defense Architecture Framework (DoDAF) advocates the use of matrices in some of its views [16].
Various attempts to represent models with matrices and DSMs were mostly model-, aspect-, language-, or visualization-specific (see Section 2).A mathematically sound and robust framework for transforming models to views is needed.In fact, since models are instantiations of MLs, and modeling consists of instantiations of ML patterns, we ought to transform the ML's set of patterns into a superset of representable data structures, rather than from a specific model to a specific view.We will focus on decision-support matrices (DSMs).
This paper defines the CMGVC transformation cycle and introduces both the cognitive and computational transforms it includes.Our framework relies on Category Theory [17].A mathematical category consists of objects and morphisms.An Object represents a type, and a homomorphism (hom or morphism) is a mapping between types.The Curry-Howard-Lambek Correspondence states that categories, theories, and programming languages are equivalent, and that writing a software program is like defining a mathematical category and like proving a mathematical theory [18,19].This insight has inspired us to assert that MLs are also categories, and that mappings within and between modeling categories are powerful means of robust model transformations for various applications.This assertion substantiates a formal, holistic approach for perceiving and implementing concept transformations, particularly in complex systems.Such an approach is instrumental for reasoning about complex concepts using the reasoning mechanisms of people's choice, rather than the representation mechanisms originally used for capturing those concepts.In complex systems, this idea of concept representation interchangeability is critical for a paradigm shift, cohesion of modeling and reasoning practices, and the facilitation of the rising DSE paradigm [10].
We present a series of propositions regarding the possibility, validity, and superiority of creating views from models through a robust mechanism.Our main assertion is that a transform from any model M to any view V through an intermediate GDS representation G is superior to a set of direct transformations from all models M1, .., MM, to all views V1, .., VV.

Proposition A. Superiority of GDS-Based Transform to Direct Transforms
A graph-mediated transform M→G→V is superior to direct model-to-view transforms M→V:  ≽  Another important assertion is that a transform from any model M to any view V through an intermediate GDS representation G is also superior to a transform from all models M1, .., MM, through a ML-bound common representation CR to all views V1, .., VV.

Proposition B. Superiority of GDS-Based Transform to Language-Specific Transform
A graph-mediated transformation M→G→V is superior to an ML-bound mediating representation-based transformation MRV:  ≽ .
MGV is a composition of M→G and G→V, so we must show that the transform M→G exists.

Proposition C. Existence of a Model-to-Graph Transform
Let ML be a modeling language and M a model in ML.There exists a formal, valid, and feasible model-to-graph transform MG from ML into GDS, MG: ML→GDS.
MGV is a composition of M→G and G→V, so we must show that a transform G→V exists.Proposition D. Existence of Graph-to-View Transform Let V be a view and G a set of GDS tuples.There exists a formal, valid, and feasible graph-to-view transform GV from GDS to V, GV: GDS→V.
Specifically, with a focus on DSM views, we must show that these are valid views on GDS.

Proposition E. Existence of Graph-to-Matrix Transform
Let DSM be a decision-supporting matrix view and G a set of GDS tuples.There exists a formal, valid, and feasible graph-to-DSM transform GV from GDS to DSM, GV: GDS→DSM.
With the above propositions in mind, we set out to validate and demonstrate this theory.In section 2 we review related work, concerning relevant MLs, Graph Theory, and Category Theory.In section 3 we describe the methods we use to conduct the CMGVC transformation cycle.In section 4 we assess the framework according to several criteria.In section 5 we demonstrate our method on a test case.In section 6 we discuss the results, conclude this paper and discusses potential, ongoing, and future research.

Related Work
In this section we review the methods, theories, and concepts that are necessary for constructing a robust CMGVC transformation cycle.We introduce Object-Process Methodology (OPM), the modeling language we focus on in this study in section 2.1.We briefly review basic concepts in Graph Theory and graph data representation in section 2.2.We discuss decision supporting matrices for systems engineering applications in section 2.3.We review Category Theory and specifically its applications and derivatives for systems engineering and MBSE in section 2.4.

Object-Process Methodology (OPM)
OPM is a leading ML and MBSE framework [4], standardized as ISO 19450 [20], which has been applied for modeling and analyzing complex and dynamic systems and processes in thousands of applications in research and industry.OPM relies on a minimal universal ontology, comprising objects (things that exist), which may have states, processes (things that occur), and relations among them.Thus, OPM's vocabulary includes about 30 terms: model, diagram, object, state, process, relation {aggregation-participation, exhibition-characterization, generalization-specialization, classification-instantiation, agent, instrument, consumption (input), result (output), effect, transformation, event (trigger), condition, invocation, in-zooming, un-folding, exception, essence {physical, informatical}, affiliation {systemic, environmental}, OPL paragraph, and OPL sentence.
OPM has a visual modality and a textual modality.The visual representation is a set of hierarchically organized Object-Process Diagrams (OPDs).All OPDs use the same notation, which means that OPM has only one kind of diagram, allowing structural, procedural, and functional aspects to appear side-by-side in any OPD.This makes system decomposition highly coherent and does not require separate notations for different levels of detail.OPM's visual modality uses rectangles to represent objects, ovals to represent processes, and few more shapes and symbols.This is irrelevant for interoperability across MLs, since the logical data representation of the model captures all the entities and relations in the model in a graphics-agnostic manner, while the graphic engine renders the visual representation according to the graphical conventions.
OPM's textual representation consists of sentences in Object-Process Language, OPL -a subset of English.Each sentence corresponds to an OPD construct -a set of linked entities -and vice versa.Each OPD is accompanied by an OPL paragraph -a set of OPL sentences.OPL is formal, machine-readable, and color-coded.A comprehensive model-level OPL Specification (OPS) includes a set of distinct OPL sentences, such that each sentence appears in the OPS only once regardless of the number of appearances in the model (e.g. in different diagrams).Accordingly, every statement can be made only once anywhere in the model in order to hold for the entire model.Thus, modelers cannot specify two contradicting statements in two different places in the same model.
OPM has been broadly applied as a system architecting and design, stakeholder engagement and communication, and concept validation paradigm [3,[21][22][23][24].OPM models can be easily built using OPCloud a novel cloud-based modeling studio [25].OPCloud has been applied in medicine [26], industry [27], aerospace [28] and digital transformation [10].OPCloud was used in this paper to build the model, generate a specification, and submit it for analysis by the proposed approach.
An OPM model of a Lane Keeping System for passenger vehicles, based on a Ford concept [29] is illustrated in Figure 2, including both the graphical (top) and textual (bottom) modalities.

Graph Data Structures
A graph is defined as a set of nodes or vertices, with arcs or edges (commonly known as arrows) connecting pairs of nodes.In a directed graph arcs can have directions (hence the common term "arrows"), meaning that a tuple <N1, R, N2> reads: "N1 R N2", "R connects N1 to N2", or "the direction of R is from N1 to N2".Arrows can also have types and additional attributes like values.Graphs lend themselves to various representations and visualizations, some of which could be matrices.Figure 3 (ii) shows the common presentation of the graph in (i) as an adjacency matrix.The rows and columns of the adjacency matrix are the nodes of the graph, and the cells represent the values or labels of the edges.If the graph were undirected, the adjacency matrix would either have to be symmetric around the diagonal (for example, if the link from node B to node C were undirected, then the cells (B,C) and (C,B) would be both equal to 3). or triangular (cell (C,B) would be empty).
Graphs can also be represented as flat sets of tuples <S,T,V> with S as the source node, T as the target node, and V as the value, as shown in Figure 3 (iii), or <R,S,T> tuples where R is a relation.
A set of tuples <R,S,T>, potentially with additional tuple attributes like identity and value, constitutes a graph data structure (GDS).The GDS is a common exchange protocol.The Resource Description Framework (RDF) protocol for web ontology specification also consists of a set of triplets and resembles the GDS concept.RDF has also been suggested as an alternative representation of an OPM model and as the basis for textual specifications [30][31][32].Indeed, GDS can be viewed as a set of RDF triplets, and vice versa.The advantage of the GDS is its ontology-indifference, and its ability to integrate the syntactic portion of the representation with the semantic one.

System Architecture and Design Decision-Supporting Matrices
The Department of Defense Architecture Framework (DoDAF) encourages the use of matrices in some viewpoints [16].However, there are no formal requirements for the structure or layout of the matrices.In some cases, the term matrix is used to describe other tabular structures that are not matrixial in essence.For instance, a table of inputs with some attributes is not a matrix.The Unified Architecture Framework (UAF), a profile of UML, constitutes a model-based architecture framework that extends DoDAF and provides a formal modeling convention [33].UAF advocates that aspects of the architecture specification's traceability to operational specifications, services, resources, standards, activities, etc. are represented as matrices, however there are no data structures or illustrations to demonstrate how matrices should be extracted from the profiles.
Design Structure Matrices / Dependency Structure Matrices (DSMs) are powerful tools that help systems engineers analyze various interrelated aspects, reach better comprehension, and make decisions [34].Transforming models into DSMs is not a new idea [35][36][37].DSMs require explicit definition of domain ontologies.This might be possible for syntactic ontology -the set of terms of the ML, but more difficult for sematic ontology, which reflects the modeled system or domain.Domainspecific languages (DSLs) capture domain concepts and allow for their syntactic analysis.However, DSLs may also be ambiguous.For instance, UML and SysML define multiple behavioral entities, e.g., use cases, activities, actions, message flows, and state transitions.OPM defines these as processes [4].
Multi-Domain Matrices (MDMs) extend DSMs by including multiple sets on each dimension and composing multiple matrices [38,39].MDMs are more informative but also more cumbersome due to their size.They also require a tremendous effort to define a) a single super-set (set of sets) of concept terms, b) a set-to-set mapping for all set pairs, and c) a member-member mapping for each pair of set members regardless of sets.
System Architecture Matrices (SAMs) are special MDMs for system architecture analysis.Technology selection, for example, can benefit from such a SAM, e.g., a quad-matrix mapping of {Systems, Processes} to {Systems, Processes} (a 2-domain MDM) [37].The mapping relation can be defined per sub-matrix.For example: the System-System relation is an identity relation, i.e. a diagonal mapping of each system/sub-system to itself; the System-Process relation is an instrument relation; the Process-System relation is an effect relation between the Process and a System's attribute; and the Process-Process relation is an input-output transfer between the two Processes.An example of the above set of mappings is illustrated in Table 1 (a).The mappings Instrument, Effect, Generation, and Consumption are drawn from the set of OPM relations.Additionally, the mappings Attribute, Input, Output, and ID are defined as morphisms on relations that are more straightforward to work with.A 3x3 SAM, consisting of Processes (functional and behavioral entities), Operands (inputs, resources, and outputs), and Components (structural entities), is illustrated in Table 1 (b), based on [21].This SAM resembles an N 2 matrix, in which the row/column items are members of the Process, Operand, and Component sets.Each sub-SAM is also a stand-alone mapping of one set to another.The cell value is the relation with which the row item relates to the column item.A row-cell-column tuple in the matrix would read: <row item (iRow)> <cell item (iRow, iCol)> <column item(iCol)>.For example: Table 1.System Architecture Matrices (a) 2-2 SAM mapping of systems and processes [37] (b) 3-3 SAM of processes, operands, and system components [21]

System (S) Process (P)
System ID(Srow) Instrument(S,P) Process Effect(P,Attrib(S)) Result(Prow, Input(Pcolumn)) Consumption(Output(Prow),Pcolumn) Associating set members with their corresponding set (Process, Operand, Component) is a challenge, which is not always visible at first glance.A DSL that provides a specific syntactic type for an entity simplifies identification of type-corresponding set members.However, the problem domain or solution domain may include types that exceed the DSL's syntax.Even common terms such as Stakeholder and Operand are not included in syntactically-rich MLs like SysML [40].Relations of hierarchy and characterization are also critical for informative SAM renditions, e.g.organization structures, activity breakdowns, product/structure breakdown, and functional decomposition.
As a broad concept, we re-purpose the acronym DSM for Decision-Support Matrix.Design structure matrices, MDMs, SAMs, pivot tables, concept maps, and a variety of matrixial and matrixlike representations, all serve a purpose of informing stakeholders, decision-makers, analysts, and other readers, to help them reason, make better decisions, and take informed action.Thus, the common goal of all those matrices is to serve as Decision Supporting Matrices -DSMs.
Generating DSMs automatically is a difficult problem.Various methods were suggested to infer DSM views from formal specifications [35,38].In [35] a DSM was generated out of automatically generated formal textual Object Process Language (OPL) specifications.Transforming model data into analyzable matrixial representations is not trivial.It mandates transforming any model into a uniform, common, language-agnostic representation that is robust enough to accommodate any domain-specific syntax and semantics, and powerful enough to facilitate any sort of analysis.
Pivot tables are powerful data analysis tools, typically used to aggregate, summarize, cluster, slice, and dice data.Pivot tables are embedded in common spreadsheet tools like Microsoft Excel and Google Sheets, and are also available in data analysis and business intelligence tools.The power of pivot tables lies in allowing the analyst to dynamically manipulate perspectives on the dataset.The analyst can experiment with perspectives and find informative configurations.Pivot tables rely on fact tables -flat representations of relational data.Pivot tables have been massively used in Business Intelligence applications, typically over aggregate operational datasets, often over time, geography, identity, organizational unit, etc. Pivot table applications in systems engineering are scarce [41][42][43], perhaps since systems engineers lack sufficient background in data analysis.

What is a category?
Category Theory is a mathematical formalism of representations and transformations that describes and deals with the structure of mathematical or mathematically-specifiable concepts.A mathematical category is an abstract mathematical structure that consists of objects and morphisms.Objects are types of entities and morphisms are functions that map objects to each other.The term object is a bit overloaded due to the use of this term in programming and engineering for instances rather than  A functor is a structure-preserving mapping between two categories, which maps both the types and the morphisms from one category to another.Functors can be thought of as the equivalent of functions in categorical algebra.:  1 → 2 denotes a functor F that transfers the types and morphisms in  1 to types and morphisms in  2 .Defining functors from one category to another is an important practice in establishing categorical foundations for scientific and engineering theories as it maps the concepts in a theory domain to concepts in a codomain that is possible to work with.

How Are Systems, Models, and Categories Similar?
The Curry-Howard-Lambek Correspondence [18,19] asserts that programming languages and type systems are categories, in which the morphisms are rules or patterns of the language that map types to each other.A software program is an instance of a programming language that reflects or represents some real-world system.Multiple software programs may represent the same real-world system and even solve the same real-world problem in different ways.They can also be built in a variety of programming languages, and work together to solve higher-level problems and represent higher-level systems.For example, if program A assigns numbers to shapes and program B places shapes on a grid, then we can compose a program to place numbered shapes on a grid (B after A, also denoted  ∘ ) or assign numbers to grid shapes ( ∘ ).In this case we should expect  ∘  =  ∘ .
Modeling languages (ML) are programming languages, and conceptual modeling is programming [44].System models can be thought of as instantiations of MLs, much like software programs are instantiations of programming languages.Accordingly, MLs may be thought of as categories, and in fact various system representation languages for creating graphs, matrices, trees, or animations may also be thought of as categories.Transitions across representations are essential for gaining system understanding, and for implementing the system or parts of the system.For example, transforming a functional system model into a visual animation may help explain how that system works.Mapping portions of a system into hardware and software designs is critical for implementing those parts of the system in their designated technologies.These ideas can be expressed formally using Category Theory.Wymore defines a system as a morphism of input to output (IO), composed of a morphism of input to state (IS) and state to output (SO) [45].A system homomorphism is a functional equivalence of two system designs (or models) in terms of their state-sets, their input-sets, and output-sets.A system 1, with a state-set 1, an input set IZ1 and an output set OZ1, is a homomorphic image of a system 2 (with respective sets 2, 2, and 2) if and only if it maps the states of 1 to thsoe of 2, the inputs of 1 to those of 2, the outputs of 1 to those of 2, the input-state transforms in 1 to input-state transformations of pairs to states in 2, and the transformations of state to outputs in 2 to transformations of states to outputs in 1.Accordingly, in a category of system models, the objects are system models, and the morphisms are Wymore's system homomorphisms.Category Theory is gaining attention in recent years as a potential underlying formalism for systems engineering, as an important pillar in systems science, and as the basis for an open information modeling and analysis platform [46], with semantic roots in design theory [47].The envisioned platform's robustness would allow for domain-agnostic cherry-picking and assembling of constructs and transforms.A roadmap for bridging the gap between theory and practice, including particular applications for systems engineering, was published by the US National Institute of Standards and Technology (NIST) [48].State-of-the-art applications of Category Theory in systems analysis, engineering, and design include: 1. Object-Process Networks, a meta-language for System Architecting [49,50], 2. ontological analysis based on a category ONT of ontologies in which Ontologies are the types and ontology mappings are the morphisms [13, 51], 3. representing a system as a category with system component types and inter-component relations as morphisms, with Ologs (knowledge representation structures that capture various non-mathematical, freely-defined relations among objects as morphisms) [52] to specify design constructs, current-state situations, constraints (the problem domain) and requirements ("shall statements") for the to-be system (the solution domain) [53], 4. representing a system as a symmetric monoidal, compact closed category with "block" types and input-output morphisms [54], 5. domain-specific reasoning in stochastic systems, mapping causal probabilistic models the category ℎ, whose types are measurable spaces, and whose morphisms are Markov kernels between spaces [55], 6. iterative co-design of electro-mechanical functions under a given cyber-physical system architecture [56, 57], 7. formal and verifiable system designing [58,59], 8. Semantic modeling for extracting information from, reasoning about, augmenting, and composing computational models of complex systems and natural phenomena [60, 61], 9. hierarchical requirements engineering, gradually evolving a system architecture [62], 10. structural and functional composition of system models [63], and 11. algebraic formulation of open dynamical systems that can be characterized as resource sharers as a category of resource-sharing machines [64].In spite of the abundance of methods, a MBSE perspective is absent.As MBSE is becoming a common and preferred way of conducting systems engineering, it is essential to harness any formalism to MBSE and to leverage MBSE through such a formalism.This paper focuses on the appropriate representation and analysis of system models that already use formal modeling languages, without replacing the existing languages with a mathematical formalism.In stead, the existing models are given artifacts and the focus is on model analysis, visualization, and delivery to various stakeholders.

Transforming Models to Graphs
Graph-centric design model representation is not new [65].Conceptual modeling languages are inherently graphic, however graph-theoretic model analysis has not evolved alongside MLs.Recent interest can be attributed to the revival and maturation of graph technology, graph databases, and graph analytics, e.g., [66].Mapping conceptual models to graphs remains a challenging task.Although MLs are graphical in essence, models are typically stored as logical data-structures, not straightforwardly as graphs.Graphs fail to capture the various notions that conceptual models convey, such as the distinction between artifact types and hypergraph and topological conventions (e.g.nesting, logical relations, and overlaps).Transformation rules that apply directly for the data structure used by the ML can help.For instance, UML has a uniform interchange structure, XMI, an XML structure that facilitates UML model conversions among various modeling tools.We can transform the XMI structure into a graph and analyze the model as a graph.SysML internal block diagrams can be transformed into graphs, compared against pattern graphs, and searched for the occurrence of design patterns [14].OPM's textual machine-generated specification is another representation that is easy to read and understand for both humans and computers [20].The textual specification covers the OPM model's logical structure.Inferring the system architecture from the model's exported report is possible, but it is not possible to reconstruct the schematic layout of the diagrams.Still, the necessary information for decision support is available.Filtering out graphical layout bias can be beneficial because the layout may affect decision-makers (for instance, due to depicting entities as central or peripheral).Conversely, layout that correctly expresses that model's intent can help in understanding the model.
Graphs belong to a class of algebraic structures known as C-sets [67].A C-set is a functor from some category  into , the category of sets and functions.Thus, a C-set () maps every object  ∈  to a set   (), and every morphism   ∶  →  ′ ∈ , to a function   (  ) ∶ () → (′).If  is a theory or concept, then its C-set is an instance or model of that theory.If C is a programming language or ML, its C-set is a projection of programs or models into .One such set can be a set of tuples that represents a graph or hypergraph (with relations between more than two nodes).
Hypergraph categories are general mathematical models of hierarchy.They are applicable to various computational constructs including matrices, graphs, Markov chains, and Petri nets [67].Hypergraph models can represent system structure, behavior, function, and interaction.Graphs of models are amenable to representation in the broader hypergraph category, an important enabler of model analysis, composition, comparison, and utilization [15].

Methods
This section describes a category-theoretical framework for architecting and executing the CMGVC transformation cycle.This framework consists of defining mappings between the conceptual and computational stations in the cycle: the concept phase (section 3.1), the model phase (section 3.2), the graph data structure phase (section 3.3), the view phase (section 3.4), and so on (section 3.5).While the CMGVC transformation cycle is universal, we focus on conceptual system architectures as an instance of C, on the OPM modeling language (M), on graph data structures (G), and on decisionsupporting matrices (V).

The Conceptual System Architecture as a Category
Wymore's definition of a system [45], in conjunction with the conventional representation of system architecture as a combination of structure and behavior [3], gives rise to a system category, , with the following types: Structure, Input-Output (or interchangeably, Onput [68]), Resource, and State.Onputs and Resources can be referred to as Operands.The morphisms include the Behaviors, which transforms Operands, and Relations that map the types to themselves and to each other.A morphism :  ⊗ → ⊗  is a behavior of the system at any level, which transforms a combination (denoted as a Cartesian product) of operands and the system's state to another combination of operands and state.The morphism  is also a composition of the morphisms   :  ⊗  →  and   :  →  ⊗  , i.e.,  =   ∘   .A system  is an instantiation of the category  .Therefore, Wymore's system homomorphism is a functor   :  → .
Cyber-physical systems (CPS) reside concurrently in the physical and cybernetic spaces, and constitute the primary concern of systems engineering.In our categorization, CPS behaviors/functions are morphisms, while system components (sensors, processors, actuators, etc. allocates a component to perform a function.This mapping of morphism to type and type to morphism implies a type-morphism duality of system behavior.CPS functions can be composed to create higher-level functionalities, for example: sensing, then actuating:  →  →  → .We can also define functions as Cartesian products, e.g.any plant's production function can be defined as (  :  ⊗  ⊗  →  ⊗  ⊗ ), which means that input data (commands), matter (raw material), and energy (e.g., electrical power) are converted to output data (statuses, reports), matter (finished goods, byproducts), and energy (e.g., heat).Some sequences may not be valid within particular system domains.For instance, in logistics, manufacturing a device (an actuator or sensor) is possible, but in an operational system such as an aircraft or autonomous vehicles, manufacturing a new part may not make sense.On the other hand, sensor "manufacturing" of images from signals may be valid.
Our categorical formulation extends the notion of a system as a procedural entity to a behaviorenabling structure, which affects operands.The operands are also types.In fact, a system can be an operand and an operand can be a system.Imagine a vehicle exiting the production line as an operand, and emerging as a system, or a software functionality delivered as a file, i.e., as an operand, and emerging as an executable, i.e. a morphism.

The Modeling Language as a Category
This paper asserts that MLs are categories, since MLs are programming languages [44], and programming languages are categories [18].We must still specify a valid categorical structure for each ML.MLs like OPM and SysML [69] capture structural, behavioral, and relational entities syntactically.The concept set constitutes a syntactic domain-agnostic ontology that accommodates a wide range of instantiations.The Block, for instance, is a fundamental SysML concept.SysML Blocks are modeled in Block Definition Diagrams (BDDs) and Internal Block Diagrams (IBDs).BDDs capture relations among blocks, while IBDs capture interactions among blocks and their internal structure.A block may be both structural and functional, which can be both useful and confusing.For example, a block can specify both the sensor and its sensing function,   .
In SysML and its predecessor, the Unified Modeling Language (UML) [70], capturing a component's behavior, rather than its structure or function, requires behavioral notation such as Activity Diagram or State Chart.In the Activity Diagram notation activities and actions are 'boxes' (types), while control or data flows are 'arrows' (morphisms).In the State Chart notation states are 'boxes' and state-transitions are 'arrows'.The different semantics applied to boxes and arrows in SysML diagrams can be quite confusing, although experienced analysts know which notation to use to interpret various diagrams to make sense.Transforming SysML models through categorical specifications into some unified, coherent notation requires tremendous effort.Due to its scale, we defer this endeavor to future research.
Conversely, OPM models use a minimal ontology of objects, processes, and relations, in which representation ambiguity and redundancy are eliminated or minimized.Since OPM's fundamental building blocks are objects that represent structure and processes that represent behavior, with a relatively small set of relations among them, a category of the OPM language is likely to be small and handy.The challenge is in correctly representing the language domain.One apparent categorical specification could define an OPM category with objects as types and processes as morphisms.
Types in one category can be morphisms in another category.OPM makes no syntactic distinction between component-representing objects and operand-representing objects.In fact, the same object can be both an operand of one system and the operator in another.Therefore, objects can be morphisms if they perform processes, and operands if they feed into or out of processes.Processes and relations represent system morphisms but are captured as graphical shapes, which may be puzzling.Processes and relations also have attributes of their own (processes have durations, relations have cardinalities, etc.).
Any model element is a type, including those that might appear to have operational semantics, such as processes, functions, transitions, etc.This also makes sense from a visual perspective: each shape on the canvas must be explicitly defined, regardless of its geometry or semantics.Thus, both 'boxes' and 'arrows' must be captured in MLs as types.
If operational entities are types, rather than morphisms -then what are the morphisms?Every model has a logical layer that underlies the visual layer.Therefore, every model element must be captured logically, otherwise it is no more than a meaningless sketch.It follows that there exists a hidden type, Specification (Spec) that captures the logical representation of the visual model.Thus, specifying -mapping visual elements to Spec -is a morphism.
However, there is another kind of morphism: modeling -which leads us through model creation or transformation.As modelers, we can take various modeling steps based on the state of our mode: The manual modeling operations on a canvas are realized by computational commands behind the scenes, or directly through a programming interface.This allows for automating the modeling process and for creating models based on other formal representations without manual editing.Although to the best of our knowledge such programmatic commands are not available in OPM, this can be a future extension based on categorical definitions as defined here.
Reconstructing a model from its specifications gives rise to a third morphism to transform Spec statements into visual geometries or textual/logical reports: rendering.The pair specifying-rendering is isomorphic if a Spec can facilitate complete reconstruction (rendering) of the model.OPML also renders part of the Spec as a textual OPL paragraph -OPM's textual modality.
The notion that modeling, specifying, and rendering are morphisms in a ML category is illustrated in Figure 5 for the OPM ML Category, OPML.The Spec is a critical type, as it enables reconstructing, composing, transforming, and comparing models.Rendering the Spec as a processable mediating artifact that represents the model substantiates a mapping of the model to another representation -a functor that maps the ML category to another category.OPCloud's Exported Report of the OPM model constitutes such a mediating artifact.Every instantiation of a type also affects the Spec, and therefore all graphical elements have a mapping into Spec (the morphism s).Spec also feeds into the Rendering morphism r, which renders a Report from the Spec, currently in the form of a PDF file.Diagram created using MATLAB 2019b digraph plotting capabilities [71].
Much like the Report is the model's interface to the digital ecosystem, model entities are its interfaces to the System category, SYS.Model, Diagram, and Spec are not real System concepts -they merely help us manage system complexity.This System-to-Model mapping constitutes the C→M

Transforming Models to Graphs
The MGV transform is a composition of a transform from a model into a uniform GDS representation (M→G), with a second transform from GDS into view (G→V).Transforms into GDS require mapping each ML construct to type in the GDS category.Graphs have only two elements: nodes and edges.GDS has only one element: tuple (an abstraction and extension of a node-edge-node triplet).A graph is merely a view on GDS.Such transforms are possible on graphic MLs, although graphics do not always map to simple graphs -for instance, when shapes are contained inside other shapes or overlap with other shapes (as in Venn diagrams).OPCloud's Exported Report includes the textual OPL specification and lists of all the objects, processes, and relations in the model.This helps in mapping all model entities and relations and translating them to GDS tuples.The final product G is a set of tuples, which includes a relation R, a source node S, a target node T, a unique identifier U, and a valuator V, denoted as the RSTUV tuple.V is useful for various applications such as quantification, verification, validation, versioning, and configuration control.
Let us revisit the lane keeping system model in Figure 2 and study its transformation into a GDS.We illustrate the same model as a graph, as shown in Figure 6.From ExportedReport we generate two interim categories: ElementDictionary and OPLSpec.We refer to both objects as sets, but due to the complicated and heterogenous structure of set members, we need further decomposition and transformation of set members to their appropriate data structures.For example, we need to find the OPDs in which each Object and Process appear.
ElementDictionary does not specify appearance of relations in OPDs, but the statements referring to the relations are specified in the OPL text accompanying each OPD.To extract this information, we need to analyze OPLSpec, identify the sentence that specifies each relation under the diagrams in which it is shown, and match the OPD→OPLStatement relation to the right Relation.
OPLStatements are compound, i.e., they aggregate multiple target entities having the same relation with a source entity into one OPLStatement.In fact, the OPL is a textual representation of the model that provides some information about the model.For example, the sentence "Lane Keeping System exhibits Lane Keeping, as well as Improved Safety" refers to two separate Exhibition relations shown in Figure 2: Lane Keeping System → Lane Keeping, Lane Keeping System → Improved Safety.This mandates additional text parsing, including the following steps: 1. Identify the position of the keyword " exhibits " in the OPLStatement; 2. Parse the left part of the sentence before the keyword position to extract the Source; 3. Parse the right part of the sentence after the keyword end to obtain a list of Targets; 4. Extract target entities from Targets by detecting the separators ", " and ", as well as "; 5. Create a mapping {R=Exhibition, S=Source, T=Targets(t), U=uniqueID} for each t in Targets; For each exhibition link in ElementDictionary, if the RST sub-tuple is found in the OPD, create a mapping {R =Inclusion, S = OPD, T = U of the relation}.
OntologyMapping is a generic transformation function that converts or extends ontological terms and execute all parts of the functor illustrated in Figure 7.A prototype of OntologyMapping has been implemented using MATLAB 2019b, with the capability to read a set of mappings for any ML and apply them to an input source that represents a model in that ML.The prototype supports reading model representations from various input sources, and storing the results to a Microsoft SQL Server database, Microsoft Excel file, text file, etc.
OntologyMapping starts from the raw input representing external models and other sources of information (e.g., OPM.ExportedReport).It continues recursively to either create new items or extend existing items.The ExportedReport→ElementDictionary transform, followed by the three transforms ElementDictionary→{ObjectElement, ProcessElement, RelationSet} create new items sets.RelationSet is further transformed into a new set of Relation items.This additional step is due to OPCloud's exported report clustering of all relations of the same type in groups.
The strength and robustness of OntologyMapping allows it to recursively search for additional mappings needed due to the creation of new items, but it would first make sure all the extended attributes are computed, because those attributes might be needed for creating new items.For instance, to create RSTUVCandidates that cover all the relevant relations pertaining to the Process item, we need to know which OPDs the process is in, and create a separate RSTUVCandidate with R=Inclusion, S=ProcessElement(p).ProcessOPD, and T= ProcessElement(p).Process, where p is a member of the ProcessElement set, p=1,..,|ProcessElement|.
OntologyMapping can receive an extensible data structure in the JavaScript Object Notation (JSON) that defines required conversions for any item.An example of the JSON extensible configuration for mapping ProcessElement to RSTUVCandidate is shown in o The Classification relation maps each entry to its type, which is the attribute name.For example, each item in the OPM.Diagram column is mapped to an RSTUVTuple with R=Classification, S=OPM.Diagram, and T=Item.UUID.• Pairs of Source and Target attributes with a specified relation (sourceTargetPairs) : pairs of attributes, for which each pair of attribute values is transformed into an RST tuple with a specific defined relation.For example, the OPM.Object and OPM.ObjectState attributes are mapped to a set of RST tuples with R=StateSpecification, S={items in OPM.Object -one object per object definition block}, and T={items in OPM.ObjectState -one or more names of states} • Triplets of Source, Target, and Relation (relationSourceTargetTriplets) : triplets of attributes that constitute RST tuples that can be defined as RSTUV tuples.For example: under the OPM.Relation block, R=Relation, S={set of all sources -basically just one object, process, or state}, T=={set of all targets -basically just one object, process, or state}.The mapping function combinatorically searches for all the valid pair and triplet permutations and create a list of unique RSTUV candidates.Subsets of items in all relevant attributes that count only one item result in a single entry.
An RSTUVCandidate referring to the same relation, source, and target entities might be created from multiple blocks.For example, since we derive identity relations for OPM.Diagram from both ObjectElement and ProcessElement, each OPD will have two RSTUVCandidates: one due to its inclusion of an object, and one due to its inclusion of a process.This is because diagram names are not defined separately in ElementDictionary, only indirectly through the listing of OPDs in which each object or process is visualized.We should converge all similar RSTUVCandidates with the same RST and assign the unique instances a unique id (U) and a version indicator (V).This also provides the capability to track changes in model versions through our platform.
OntologyMapping can store the results at any stage throughout the process.We can store the results in a file in various formats: Microsoft Excel (.xlsx), Comma-Separated Values (.csv), JSON (.json), or XML (.xml).We can also store the results in a relational database, such as SQL Server, through DDL queries, or as JSON/XML objects.Result Persistence is usually kept only for the endgame results, but retaining byproduct results is possible.

Transforming Graphs to Views and DSMs
The next step in the process is to define informative views on the model's GDS (set of RSTUV tuples), such as the DSMs discussed in section 2.3.As shown in Figure 3 the essential graph, RST tuple set, and adjacency matrix are equivalent representations.Therefore, any relational pattern in the model, captured in the GDS, can be represented in a matrix.Furthermore, if the mapping via a selected relation or subset of relations makes sense or helps in reasoning about a problem, then we will be able to support this reasoning process by delivering a decision-supporting visualization in the form of a matrix based on the GDS based on the original model.
A DSM captures a mapping of row items to column items.We can specify a subset of relations and get a mapping of row items to column items according to the selected relations.We use SQL as a robust querying language, to reconstruct threads and spans of relations over the GDS, with the RSTUV tuples stored in a relational SQL Server database.Sequential SQL join queries make up functors from the raw GDS to matrix or tensor datasets [72], which visualization and analysis tools can render as matrices.A common spreadsheet tool like Microsoft Excel can import the query results from the database management system, construct a pivot table on top of the raw data, and render the appropriate visualization.Pivot tables have a flexible structure that allows the analyst to adjust, transpose, and organize the matrix hierarchically for various visualization needs.Readily available data analysis tools like pivot tables simplify the analysis and minimize tool dependency.Additional visualization tools and techniques can be explored in the future.
Additional analysis can include tallies, sums, minima, maxima, subtotals on indications, or associated/converted matrix cells values.For example, if the number of allowed relations in each intersection must positive, we can quickly find the discrepancies (both visually and computationally).

Transforming Views into Concepts, and Concepts back into Models
The CMGVC loop's cognitive segment, V→C→M consists of reasoning, decision-making, and actiontaking.During this process, we study the views, mentally fuse the information with knowledge and beliefs, and create or revise a mental model, or concept.Based on the concepts we have in mind, we make decisions that alter the concept, or alter reality to match the revised concept.These cognitive view-to-concept and concept-to-model mappings close the loop by returning to the category of conceptual systems, .A model of an existing system explains hypotheses, theories, or facts about the system.A model of a future system serves to inform system that will suit their concept.Stakeholders may later take action to execute decisions and adjust the model developers about the system's expected structure and behavior to fulfill the concept that the system was meant to realize.The conceptual transformation is a cognitive process that closes the loop and allows us to re-iterate through conceptual models of described or prescribed systems.Rigorous formulation of these transforms requires substantial grounding in cognitive psychology, and is beyond our current scope.

Assessment
The CMGVC cycle offers a significant departure from direct generation of views on models, and a more robust alternative to indirect generation of views based on DSML-specific representations.
In section 1 we have defined five propositions for this research: A. M→G→V (a GDS-mediated transformation from model to view) is superior to M→V (a direct transformation from model to view) B. M→G→V is superior to M→R→V (a language-bound representation-mediated transformation from model to view) C. M→G is a feasible and valid transformation.D. G→V is a feasible and valid transformation.E. G→DSM is a feasible and valid transformation.In sections 3 we have presented a categorical framework for converting conceptual system models from one ML, OPM, into a GDS, and deriving DSM views from the GDS.We have thus managed to validate Propositions C, D, and E regarding the existence of the building blocks of a composed transform M→G→V based on  ∘ , where : →, : →.
To prove Propositions A and B we must compare the benefits and limitations of the CMGVC approach vis-à-vis the two alternative approaches: • MV: Direct generation of views from a model, that we denote V(M) or MV • MRV: Indirect generation of views from a model via a common DSML-specific representation, that we would demote V(RDSML(MDSML)) or MRV We define four lower-is-better (LIB) criteria for comparison, which reflect stakeholders needs: • C1: the number of required transformations of M models to V views.For MGV, MRV: sum of model-to-graph transformations (M) and graph-to-view transformations (V); For MV: product of models by views ( • ).• C2: effort of creating new views for existing models.For MGV, MRV: one effort unit per view (graph-to-view or representation-to-view); For M: M effort units (models-to-view).• C3: effort of creating existing views for new models: For MGV: a single effort unit (modelto-graph); for MV: V effort units (model-to-views); for MRV: V+1 effort units (model-torepresentation and representation-to-views) • C4: dependency on DSML updates: for MGV, MRV: a single effort unit for updates (either model-to-graph or model-to-representation); for MV: V effort units (model-to-views) Since all criteria are LIB, the total score is also LIB.Table 3 defines metrics for each criterion.Total scores for MGV, MV, and MRV are defined in Eq. ( 1), (2), and (3).Table 3. Metrics for comparing approaches to generate views from models.

Representation and Analysis of Process-to-Process Input-Output Exchange
Table 1 illustrates two examples of SAMs that map various system architecture aspects to each other.Both SAMs include a mapping of processes to each other, with Table 1-a being more explicit about the mapping of process to process via operands.The operands serve as indirect process mediators: the output of one process is the input of another.However, there is no explicit mapping in the model in the form <P,O,P>. Therefore, this mapping must be composed.This composition is defined in the following manner, using SQL queries to retrieve and cross the data from the raw set of RSTUV tuples: 1. Find all the processes, i.e., targets in tuples where the source is 'OPM.Process' and the relation is 'Classification'.2. Find all outputs, i.e., targets in tuples where the relation is 'Result', and retrieve the source process item.3. Find all tuples in which the above outputs are sources in a Consumption relation (i.e., inputs), and retrieve the target process items.4. Cross the process-output set with the input-process set such that output = input.5. Cross the process set (1) with the output-generating process set (2) while keeping all processes including those that are generating no output.6. Cross the process set (1) with the input-receiving process set (3) while keeping all processes including those that are receiving no input.7. Layout a matrix with output-generating processes as rows, input-receiving processes as columns, and identity of matching output-input (onput [68]) item as the cell value.Figure 9 illustrates the MGV transform into three views of a generic OPM model (Figure 9-a) with seven processes and eight objects that the processes generate or consume: 8.   c) a process-on-node/onput-onedge graph, and d) a process-to-process onput exchange matrix, which is based on the same query as the process-on-node graph.NULL processes and onputs (in all renditions) serve as placeholders for missing or partial relations, e.g., an input without a source process (e.g.Ob12), a process without an input (e.g.P3) or without an output (e.g.P7), and an output without a target process (e.g.Ob11).Both graph visualizations were rendered using https://csacademy.com/app/graph_editor/.

The Lane Keeping System Revisited
Our lane keeping system running example can now be analyzed according to the CMGVC cycle.An in-zoomed diagram of the Lane Keeping System, specifying the functions performed by the system and their interactions, is illustrated in Figure 10.This is an intentionally partial diagram, with some critical things missing.As we study this diagram we should notice, for instance, that the Lane Crossing object has no source, and that the Road is consumed by the Imaging Road process, rather than remain an instrument as it was specified in the topmost diagram.It is difficult to ensure continuity and consistency this way, and the problem intensifies as the model grows bigger with more objects, processes, and diagrams.Our lane keeping system running example can now be analyzed according to the CMGVC cycle.An in-zoomed diagram of the Lane Keeping System, specifying the functions performed by the system and their interactions, is illustrated in Figure 10.This is an intentionally partial diagram, with some critical things missing.As we study this diagram we should notice, for instance, that the Lane Crossing object has no source, and that the Road is consumed by the Imaging Road process, rather than remain an instrument as it was specified in the topmost diagram.It is difficult to ensure continuity and consistency this way, and the problem intensifies as the model grows bigger with more objects, processes, and diagrams.Analyzing this model with a POP matrix could help detect some discrepancies in the model.Table 5 is a POP matrix that was derived from the model through the same SQL query defined in section 5.1 for the POP matrix-supporting records, and rendered as a matrix using a MS Excel pivot table on the query results.As the Lane Keeping System model utilizes additional procedural relations besides the result and consumption: the instrument relation is used for non-consumable resources and the invocation relation is used for specifying process activation by another process, implying an unspecified interface object.Additional metrics were added to the POP matrix, including the number of inputs and number of outputs per process (calculated on the columns and rows, respectively).
The POP matrix highlights several issues in the model, which could be helpful for reviews by various stakeholders -customers, system architects, process or function owners, etc.We summarize proposed corrections by entity and issue in Table 6.It would be easy to apply these to the model and reiterate to obtain the revised POP matrix.As more details are added to the model, the POP matrix is likely to grow and detect new issues, in a continuous concept revision and improvement cycle.

Conclusion
Systems engineering is undergoing a digital transformation, compounded with the constant growth of systems complexity and interconnectedness.Conceptual modeling is becoming more common for representing complex systems, and more critical for generating deliverables that impact the digital value chain [10].Considering the challenge and opportunity associated with these trends, we set out to find robust foundations for MBSE interoperability and collaboration across digital enterprises.
We have explored the potential of Category Theory to serve as an underlying formalism for systems engineering, particularly in the context of MBSE.Category Theory is an appropriate holistic paradigm, a state of mind, and a formal foundation for the model transformation and reasoning pipeline, which is essential for a smooth, rational, and reliable MBSE cycle that constantly improves, corrects, and refines system architecture specifications.
Drawing on the Curry-Howard-Lambek Correspondence of programing languages and categories, we show that modeling languages, like programming languages, are valid categories.We have used categorical structures to map system concepts to model concept, models to robust graph data structures (GDS), and GDS to decision-supporting views -graphs and matrices.
The Concept-Model-Graph-View-Concept (CMGVC) cycle facilitates the transformation of conceptual models to decision-supporting views.We have shown that it would be imperative to include an intermediate common representation in the form of a GDS, which serves as a common outlet to all MLs, and a common basis for all views, visualizations, and reports.We have proven the superiority of our approach to direct mappings and ML-bound representation-based mappings.
The CMGVC approach has several advantages: • Using the CMGVC approach, stakeholders and decision-makers will be able to derive critical information and insight regarding system development and operation from the system model, rather than through a disparate information gathering and presentation channel, which is the common practice nowadays.• The preferential dominance that we have proven in section 4 facilitates efficiency in model analytics, and thus encourages further adoption.• The transition through GDS enhances system understanding by adding another modality: graphs, which map concepts and relations through one common substantial representation.• The simple-yet-robust GDS can be a prime facilitator of MBSE interoperability and collaboration across digital value chains.• Subject matter experts will be able to leverage the CMGVC approach via semantic and ontological frameworks to better represent emerging patterns and concepts.We have demonstrated how a model can be represented in multiple ways that are all based on the same GDS representation of that model.These include two visual graph renditions, which are also duals: a process-on-node/onput-on-edge graph and an onput-on-node/process-on-edge graph and a process-to-process operand exchange matrix.
Both dual graph renditions have uses and advantages.Being able to generate both graphs from the same data structure is an important benefit, which also ensures consistency and complementarity.The SysML Internal Block Diagram (IBD) uses an object-on-node graph, while the SysML Activity Diagram uses a process-on-node graph, and the State Chart uses a state-on-node graph.These three aspects can be generated from the same GDS representation of an OPM model.Therefore, the GDS can facilitate modeling language translation.We intend to explore this direction in future studies.
The process-operand-process exchange matrix is an important tool for architectural analysis, and it captures a non-trivial compositional mapping relation that we could build by composing relation segments in the GDS through robust data retrieval and integration queries.Obtaining and maintaining such a matrix manually is a significant cognitive effort.The ability to dynamically visualize the matrix using a pivot table is another strong benefit, due to both its accessibility to many potential adopters, and its ability to accommodate their evolving needs.
Further exploring the applicability of this approach to various MLs, we plan to demonstrate that the CMGVC approach can be robustly suited for various other MLs and views.Particularly, we plan to explore the transformation of SysML and Simulink models via the CMGVC pipeline and to create Isomorphic mapping capabilities out of and back into the same ML are also a major challenge.
Reconciling the MBSE paradigm with the Discrete Event Simulation (DEVS) paradigm is a recent ongoing effort [73].Ongoing collaboration between the MBSE and DEVS communities has been institutionalized in a joint workgroup for the International Council on Systems Engineering (INCOSE) and International Association for Engineering Modeling and Simulation (NAFEMS) [74].Our proposed framework can facilitate interoperability across MBSE and DEVS platforms, tools, and models.It alleviates efforts to find and apply an interoperability standard that would appeal to both MBSE and DEVS.The reason is that graph-theoretic DEVS algorithms are abundant, and graphrepresentable problems have been studied with DEVS technology and methodology for decades, for example as part of the Agent-Based Modeling & Simulation (ABMS) paradigm [75,76].This direction should be explored as part of future research.
One limitation in our approach is its scalability.We plan to build a service-oriented software platform that will provide the robust transformation capabilities as web services to MBSE practitioners and researchers, who will be able to upload or plug-in live models and benefit from adhoc or continuous transformations and visualizations.MBSE experts should also be able to define new mappings, maintain and enhance existing mappings, and define sets of views to run on specific models.These will provide continuous visualization or integration with external systems across the digital enterprise.We plan to employ state-of-the-art information visualization techniques to provide stakeholders with flexible, dynamic, and elegant decision-supporting views.

Figure 1 .
Figure 1.The ModelConcept duo (a) is enriched with reasoning-supporting view through the Model→View→Concept trio (b) and extended as a robust Concept→Model→Graph→View→ Concept (CMGVC) cycle, a computational-cognitive concept modeling and analysis process (c).

Figure 2 .
Figure 2. OPM model (OPD on the left, OPL on the right) of a Lane Keeping system, loosely based on [29].The system handles a Lane Keeping function that provided Improved Safety.Lane Keeping generates Alerts, which inform the Driving process, and Steering Commands, which affect the Vehicle's Propelling function.The Road constitutes an instrument for both Propelling and Lane Keeping.Driving and Propelling affect each other regardless of the Lane Keeping system.

Figure 3 Figure 3 .
Figure 3. Equivalent representations of a set of relations between pairs of objects in a set as: (i) a directed graph, (ii) an adjacency matrix in which cell (r,c) holds the value on the arc from the object in row(r) to the object in column (c), and (iii) a set of tuples which constitute triplets of a source object (S), a target object (T), and a value (V) that relates the source object to the target object.
For example, Attrib(S) is the set of model entities Ei that participate in an exhibition-characterization relation to S: Exhibition(S,Ei) or Characterization (Ei,S).Input(Pcolumn) is the set of entities Ei with an Instrument(Ei,Pcolumn) or Consumption(Ei,Pcolumn) relation to the column process.Preprints (www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1

Preprints
(www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1types.OPM objects can represent both a class and an instance.We shall use the common term Type.A homomorphism (hom or morphism in short) is a mapping between two structures.Each morphism has a domain and codomain which are types denoted :  → , where  is the domain and  is the codomain.Two morphisms can be composed if the former's codomain is the latter's domain, like functions: if :  → , and :  → , then  • :  → .This sequential composition executes g after f, and can also be denoted  ∘  .A category with three types, two explicit morphisms and one composed morphism is illustrated in Figure4.A morphism can also map a cartesian product of two or more types to a new type.:  ⊗ →  denotes a mapping of each combination of  and  to .  can be any structure including a multi-dimensional tuple, and the set  ∈  can be a tensor.

Preprints
(www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1 ) and operands (Currency, Data, Energy, and Matter -CDEM) are types.CPS components carry out functions that convert input operands to output operands, for instance: a) an engine runs an Energy Generating function, to turn matter into energy,   :  →  ; b) a sensor runs a Sensing function that converts energy into data,   :  → ; and c) an actuator runs an Actuation function that converts data into energy:   :  → .Conceptual architecting usually specifies the function before the form, while physical architecting might work in the opposite direction.The attribution of a functional-behavioral morphism   to a structural entity  implies or entails a relational morphism  → :   →  that assigns a function to a function-performing system component, and a dual  → :  →   that Preprints (www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1 a) start with a blank diagram; b) add an object, or process -transforming our diagram into a diagram with an object or a process -Hence the morphisms Diagram→Object and Diagram→Process exist; c) create a new diagram to specify the details of an object or process -hence the morphisms Object→Diagram and Process→Diagram exist; d) add a state to an object: Object→State; or e) add a relation between an entity (object, process, or state) and another entity, which results in a two-step morphism: Entity→Relation and Relation→Entity.OPM does not permit creating a Diagram from a State or Relation -although such an extension can be theoretically valid and possible.Challenging the existence or absence of a modeling morphism may help enhance the ML.

Figure 5 .
Figure 5.The OPM modeling language, OPML, as a category.Modeling (the morphism m) is like hopping through the instantiation of category types based on existing artifacts.For example: a) creating a new Diagram D1 in a Model M, b) creating an Object Ob1 in D1, c) creating a Process P1 in D1, d) creating a RelationRr1(Ob1,P1) from Ob1 to P1, e) creating a new Diagram D2 from P1, f) adding States St11, St12 to Ob1 in D2, and so on.Every instantiation of a type also affects the Spec, and therefore all graphical elements have a mapping into Spec (the morphism s).Spec also feeds into the Rendering morphism r, which renders a Report from the Spec, currently in the form of a PDF file.Diagram created using MATLAB 2019b digraph plotting capabilities[71].

Figure 6 .
Figure 6.A graph representation of a subset of the Lane Keeping System (LKS) model in Figure 2. The graph maps the OPM-specifiable terms "$Object", and "$Process" to Domain entities: Object classifies Vehicle, Driver, and LKS; Process classifies Driving, Propelling and Lane_Keeping.Domain-internal relations include the mutual invocation between Driving and Propelling, output of Alert and Steering_Command to Driving and Propelling, respectively, and the exhibition of Lane_Keeping by LKS.The graph is a visualization of a subset of the GDS that represents the model.It is clearly already difficult to comprehend, and is illustrated to build intuition about the possible mapping of a model to a graph.

Figure 8 .
The JSON object can define: • Identity Attributes (identityVars): attributes whose values are converted to the Identity relation and the Classification relation.o The Identity relation maps each entry to a universally unique ID (UUID).Preprints (www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1

Figure 9 -
b: A visual graph with onputs on nodes and processes on edges highlights the systemic morphisms of onputs through processes and is useful for showing onput transformations, e.g.matter to energy, energy to data, etc., as discussed in section 3.1.The SysML Block Diagram notation renders an object-on-node graph.9. Figure 9-c: A visual graph with processes on nodes and onputs on edges -the dual graph of Figure 9-b -highlights process flow and is useful for showing functional compositions through shared onputs, process threads, and functional boundaries and interfaces.The SysML Activity Diagram notation renders a process-on-node graph.10. Figure 9-d: A process-operand-process (POP) exchange matrix maps processes to each other via shared onputs they exchange, including indications for partial exchanges (inputs without source processes, processes without input or output, outputs without target processes, etc.), and facilitates visual or computational analysis, verification, and validation.Preprints (www.preprints.org)| NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1(a) Object-process model with processes that generate outputs and consume inputs.An onput is concurrently an output of one process and input to another (b) Graph visualization of the model, with onputs as nodes and processes as edges Process-Operand-Process (POP) Matrix of the model: the row process generates the cell onput, which is received or used by the column process (c) Graph visualization of the model, with processes as nodes and onputs as edges

Figure 9 .
Figure 9. Transforming an OPM model with processes and onputs (a) through the MGV transform into three renditions: b) an onput-on-node/process-on-edge graph, c) a process-on-node/onput-onedge graph, and d) a process-to-process onput exchange matrix, which is based on the same query as the process-on-node graph.NULL processes and onputs (in all renditions) serve as placeholders for missing or partial relations, e.g., an input without a source process (e.g.Ob12), a process without an input (e.g.P3) or without an output (e.g.P7), and an output without a target process (e.g.Ob11).Both graph visualizations were rendered using https://csacademy.com/app/graph_editor/.

Figure 10 .
Figure 10.Lane Keeping System zooms into Alert Mode, Steer-back Mode, Road Image, Alert Mode, Lane Crossing, and Steer-back Mode, in that vertical sequence, as well as Alerting, Analyzing Road, Imaging Road, Selecting Operational Mode, and Steering (This caption is in fact a formal OPL sentence that specifies the in-zooming of Lane Keeping System in a new diagram).

Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 15 February 2021 doi:10.20944/preprints202102.0316.v1 portion
of the CMGVC cycle.The OPML→GDS transform functor maps all the types in OPML to GDS tuples.This C→M→G segment of the CMGVC cycle is illustrated in Table2.

Table 4 .
Preference Relations of MGV over MV depending on the number of MLs (M) and views (V).MV is preferred when M=V=1; MGV is preferred when  ≥ 2 &  ≥ 2. When  = 1 &  ≥ 2 or  ≥ 2 &  = 1 preference rotates based on weighting.MGV is preferable when weights are equal.  ≤   ⟹  ≽  With this analysis, we have managed to corroborate Proposition A and Proposition B.