## 3 Methods
### The Modeling Language as a Category  
Modeling languages are categories, since they are essentially programming languages [82], and programming languages are categories [20; 21]. Moreover, programs are equivalent to theories [22], and likewise, models are equivalent to system concepts, which can be thought of as 'theories' about how a system works or might work. System models are instantiations of MLs, much like software programs are instantiations of programming languages. Similarly, 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 functional models into visual animations, hardware and software designs, text specifications, etc. may further explain the system. The assertion that MLs are categories must be backed up by valid categorical representation. MLs like OPM and SysML [83] 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 is both useful and confusing. For example, a block can specify both the sensor and its sensing function, \(f_{Sensor}\). In SysML and its predecessor, the Unified Modeling Language (UML) [84], 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 confusing, although experienced \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**CPS Component** & **CPS Morphism** & **Input** & **Output** & **Formulation** \\ \hline Engine & Energy Generating & Matter & Energy & \(f_{Engine}:Matter\to\) Energy \\ Sensor & Sensing & Energy & Data & \(f_{Sensor}:Energy\to\) Data \\ Actuator & Actuating & Data & Energy & \(f_{Actuator}:Data\to\) Energy \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Examples of cyber-physical system morphisms. analysts know which notation to use to interpret various diagrams to make sense. Transforming SysML models through categorical specifications into a unified notation requires tremendous effort. We defer this endeavor to future research. Conversely, OPM models use a minimal ontology of objects, processes, and relations, in which semantic 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 (durations, cardinalities, etc.).