Model-Based Interoperability Engineering in Systems ...

SMCA-15-10-0762.R2

1

Model-Based Interoperability Engineering in Systems-of-Systems and Civil Aviation Yaniv Mordecai, Member, IEEE, Ori Orhof, & Dov Dori, Senior Member, IEEE  Abstract— Interoperability is the capability of multiple parties and systems to collaborate and exchange information and matter to obtain their objectives. Interoperability challenges call for a model-based systems engineering approach. This paper describes a conceptual modeling framework for model-based interoperability engineering (MoBIE) for systems of systems, which integrates multi-layered interoperability specification, modeling, architecting, design, and testing. Treating interoperability infrastructure as a system in its own right, MoBIE facilitates interoperability among agents, processes, systems, services, and interfaces. MoBIE is founded on ISO 19450 standard – Object–Process Methodology, a holistic paradigm for modeling and architecting complex, dynamic, and multidisciplinary systems – and allows for synergistic integration of the interoperability model with system-centric models. We also discuss the implementation of MoBIE with the Unified Modeling Language, UML. We discuss the importance of interoperability in the civil aviation domain, and apply MoBIE to analyze the passenger departure process in an airport terminal as a case-in-point. The resulting model enables architectural and operational decision making and analysis at the system-of-systems level and adds significant value at the interoperability engineering program level. Index Terms—Airport Terminals, Interoperability, ModelBased Systems Engineering, Object Process Methodology, Systems of Systems

ACRONYM GLOSSARY AF DM2 I5 MBSE MoBIE OPD OPL OPM SoS SysML UML

Architecture Framework DoDAF Meta-Model Interoperability, Interaction, Interconnectivity, Interfacing, and Integration Model-Based Systems Engineering Model-Based Interoperability Engineering Object-Process Diagram Object-Process Language Object-Process Methodology System-of-systems Systems Modeling Language Unified Modeling Language

I. INTRODUCTION – the capability of multiple separate entities to interact, collaborate, and utilize each other to achieve a higher level goal or their own goals – has been identified as a primary distinctive feature of complex systems and systems of systems (SoS) [1]. The primary objective of

I

NTEROPERABILITY

Submitted Oct 2, 2015. Revised and resubmitted Feb 29, 2016. Accepted Aug 9, 2016. This work was supported by the Gordon Center for Systems Engineering at the Technion – Israel Institute of Technology, Haifa, Israel.

interoperability is to increase the value that beneficiaries of constituent systems gain and the systems' ability to meet their objectives as a result of interacting with other systems [2]. Systems gradually evolve through several levels of interoperability: i) isolated or manually-enabled interaction, ii) peer-to-peer connection, iii) functional interaction, iv) domain integration, v) enterprise interoperability, and finally vi) ecosystem or universal interoperability [3]. An emerging topic of research [4]–[7], interoperability is especially common in defense applications [8], [9], information technology [10], [11], and manufacturing and supply chains [12]–[15]. Interoperability can be applied at four levels: i) technical interconnectivity, ii) system service and process interaction, iii) operational (or business) end-to-end process, and iv) programmatic coordination. Technical interconnectivity enables information and matter exchange among interfaces, ports, and terminals over reliable linking channels. System service and process interaction allows multiple systems to seamlessly interact with each other and collaborate in carrying out operational end-to-end transactions. Operational or business interoperability enables organizations, users, and stakeholders to interact, collaborate, and participate in joint activities, facilitating the attainment of higher-level goals and objectives. Operational process interoperability encompasses orchestration, coordination, synchronization, and alignment among multiple, autonomous business agents. Programmatic coordination, which is beyond the scope of this paper, is external to the interacting systems – it applies to the capability of multiple project management and system engineering and development teams to collaborate [16]. Capturing and expressing interoperability in a manner that appeals to stakeholders is a significant systems modeling challenge. Conceptual modeling of complex systems focuses on structure, behavior, and function [17]. Model-based systems engineering (MBSE), which relies on formal conceptual modeling to manage complex sociotechnical systems through their entire lifecycle, has been gaining increasing momentum and adoption [18]. MBSE interoperability challenges include interoperability program management, end-to-end operational concept simulation and validation, emergent behavior understanding, risk exposure, and overall balancing and harmonization of goals and objectives of multiple systems [8], [19]. However, common modeling languages, such as the Yaniv Mordecai ([email protected]) and Dori are with the Technion – Israel Institute of Technology, Haifa, Israel. Ori Orhof is with the Center for Academic Studies, Or-Yehuda, Israel.

SMCA-15-10-0762.R2 Systems Modeling Language (SysML) [20], enhanced functional flow block diagrams (EFFBD) [21], and cyberphysical systems modeling approaches [22] are designed for system-level analysis and specification rather than for SoS level [23]. Current practices using these languages are not especially geared for and not supportive of SoS level analysis, and in particular not for analysis of interoperability aspects. Interoperability-oriented specification languages, such as the Monterey-Phoenix (MP) Event Grammar [24], and the Lifecycle Modeling Language (LML) [2] provide bottom-up support for interoperability modeling and engineering with dedicated syntax, semantics, ontologies, evaluation schemes and utilization frameworks. Architecture Frameworks (AF) , such as that of the US Department of Defense, DoDAF, and of the British Ministry of Defense, MODAF [25], [26] have traditionally focused on monolithic systems. NATO Architecture Framework (NAF), Unified Profile for DoDAF and MODAF (UPDM), and NATO's emerging Unified Architecture Framework (UAF) focus on military interoperability [27]–[29] and facilitate the integration of AFs with MBSE [30]. The Open Group Architecture Framework (TOGAF) is a commercially-oriented AF. These AFs rely on Unified Modeling Language, UML, the software-anchored ancestor of SysML, as a modeling formalism. Therefore, they suffer from the same limitations that led to the creation of SysML as a derived solution for general complex systems in the first place, and have a limited capacity to accommodate SoS models. From the constituent systems' perspective, interoperability is secondary in importance to their core, autonomous functionality. Interoperability is tacitly assumed or expected to be "transparent", simple, and have minimal impact on each individual system. Consider, for instance, a credit transaction clearinghouse service, which provides for interoperability among businesses, credit card companies, banks, and consumers. All the parties expect this infrastructure to function flawlessly and invisibly, require minimal or no changes in order to interface with the service, to be minimally involved in the business transaction or impacted by it. Yet, the interoperability infrastructure must provide rich support functionality, including monitoring, control, regulation, quality assurance, safety and security assurance, operational process management capabilities, business continuity and disaster recovery solutions, storage buffers, visualization, and customization interfaces. A dedicated SoS interoperability engineering program, and a designated interoperability engineer (or team) to oversee it, are therefore key to successful interoperability. The challenges for SoS interoperability modeling that our study has identified are the following: i) to provide a rich ontology that supports the common conceptualization of interoperability and has the capability to evolve as the domain's concept maps evolve; ii) to support the management, engineering, and operation of interoperability programs; iii) to support uniformity, integration, interoperability, and mediation across multiple modeling languages between SoS models on the one hand and their constituent system models on the other hand, and iv) to enable end-to-end SoS-level scenario demonstration,

2 testing, validation, and verification. This paper proposes a Model-Based Interoperability Engineering framework, MoBIE. MoBIE defines ontology that conceptualizes the interoperability domain, enabling modeling, utilization, and analysis of all the major interoperability aspects. MoBIE advocates SoS interoperability model centrality while empowering the constituent system models with the advantages of interoperability. MoBIE is founded on Object-Process Methodology [31], [32]. OPM, the ISO 19450 specification for system and process modeling [33], is a holistic conceptual modeling paradigm for multidisciplinary, complex, and dynamic systems. OPM is state-of-the-art MBSE paradigm beside the OMG's UML and SysML [18]. MoBIE has evolved from the I5 concept, an end-to-end view of interoperability, interconnectivity, interaction, interfacing, and integration [34]. In this paper, we apply MoBIE to civil aviation, a prominent interoperability-reliant domain, where we study the interoperability aspects of the departing passenger process. The rest of the paper is organized as follows: Section II presents MoBIE foundations and principles. Section III illustrates a case study of implementing MoBIE in passenger routing, a complex airport operation. In Section IV we discuss implementation of MoBIE with UML or SysML, and Section V concludes with discussion, implications, benefits, and future research. II. MODEL-BASED INTEROPERABILITY ENGINEERING - MOBIE MoBIE is a conceptual modeling framework for SoS interoperability. A semantically-grounded approach, MoBIE can be implemented by any conceptual modeling language that accommodates the extensions and building blocks defined in this paper. Relying on key OPM features, such as its graphicaltextual bimodal representation and its complexity management, we use OPM as our underlying modeling language. A. Interoperability Framework Requirements In order to specify and describe an interoperability modeling and engineering framework, we must first define the requirements for such a framework. Based on the literature, experience, and feedback, we have assembled the set of requirements defined in Table I. We realize that this may not be the ultimate set of requirements, so we mark this as Version 1.0. Modeling frameworks are created to provide and facilitate modeling capabilities. Therefore, the set of requirements is essentially a set of expected, required, or resulting modeling capabilities. B. Object-Process Methodology OPM captures the functional, structural, and procedural system aspects in a single model, expressed in both graphics and equivalent text. OPM is founded on a minimal ontology of stateful objects as things that exist and processes as things that transform objects by creating or consuming them, or by changing their state. The graphical modality is a set of selfsimilar, notation-consistent, hierarchically organized, interconnected, and cross-validated Object-Process Diagrams (OPDs)—the only kind of OPM diagram (for comparison, SysML has 9 diagrams kinds; UML has 14). An OPD contains

SMCA-15-10-0762.R2

3

things—stateful objects and processes—connected with several kinds of links. The root diagram is called System Diagram, SD. TABLE I.

REQUIRED INTEROPERABILITY MODELING CAPABILITIES V1.0

ID

Required Modeling Capability

1.

Multiple Stakeholder Modeling Capability

2. 3.

Multiple Constituent System Modeling Capability Interoperability-Facilitating Service Modeling & Design Capability Interoperability-Facilitating Infrastructure Modeling & Design Capability Input-Output Modeling Capability Multiple Input-Output Item Type and Instance Modeling Capability Informatical Input-Output Item Exchange Modeling Capability Physical Input-Output Item Exchange Modeling Capability Input-Output Exchange Channel Abstraction and Specification Modeling Capability Multiple Interoperable Interaction Layer Modeling Capability Interoperability Demonstration Capability Interface Modeling & Design Capability Interoperable Scenario Modeling Capability Multiple Constituent System Model Overarching Capability

4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

To manage the system's complexity, SD can be refined and elaborated recursively by descendent OPDs using several refinement-abstraction mechanisms: i) unfolding and folding of structural hierarchies of things (objects or processes), ii) zooming into or out of the inner details of things, iii) expressing and suppressing states, and iv) creating dedicated views for pivotal things. To alleviate cognitive load, OPM advocates limiting the number of elements (things and links) in each OPD and gradually exposing additional elements at lower-level diagrams. This approach increases system understandability by distributing details of the system structure and behavior across multiple diagrams at increasing levels of detail. OPM's textual modality, Object-Process Language (OPL), is a structured natural textual specification language. Each graphical OPD construct is also expressed by a semantically equivalent textual OPL sentence, which is instantly created in response to the modeler's graphic input. OPM Elements are Things and Links. Things are Process (ellipse), and Object (rectangle). Objects

OPM feature Universal ontology

Unified staticdynamic modeling Built-in hierarchical decomposition and complexity management Bimodal graphicaltextual equivalent representation Metamodeling capability ISO standardization (ISO 19450) CASE tool availability

can be stateful, i.e., have states. Processes and Objects exhibit the inherent attributes Essence (which can be informatical or physical) and Affiliation (can be systemic or environmental). Processes and objects may consist of lower-level processes and objects. Links express graphically various relations between these elements. Structural links support modeling of static system aspects, and can be defined between two objects, two processes, and in some cases between an object and a process. Procedural links express dynamic relations, transformations of objects by processes, control, conditions to process execution, precedence, and causalities. Table II presents OPM’s characteristics and capabilities that make it suitable for interoperability modeling and architecting, and analogous SysML features. C. Interoperability Layers The MoBIE interoperability metamodel consists of three layers: i) operational interoperability, ii) system interoperability, and iii) system interconnectivity. The synergetic value of the first, operational (or in some contexts 'business') layer emerges from coordination, synchronization, and alignment of disparate interoperable cross-system engagements. These engagements are interwoven into the operational 'story' that the interoperability empowers. They include collaboration, interactive functionality, and input/output exchange among the various agents and stakeholders involved: owners, beneficiaries, operators, and users. The second, system interoperability layer is where interoperable engagements occur. These include cross-system interactions and flows among interactive processes, services, functions, and procedures. The operational interactions that take place at this layer facilitate the interoperability at the operational layer, where value for at least one stakeholder group or one constituent system emerges from collaboration, technical interactions, and input/output exchange among systems, subsystems, agents, and services. Finally, the third, system interconnectivity layer encompasses all the physical and informatical interfaces among the constituent systems, capitalizing on the hardware, software, and firmware

TABLE II. ADVANTAGES OF OPM FOR SOS INTEROPERABILITY MODELING AND ANALYSIS Utilization for interoperability modeling and analysis Due to the universality and compactness of its ontology, system architects, designers, and researchers can use OPM to model a large variety of natural and artificial systems [35]–[38]. OPM captures the static-structural aspect, including interfaces, media, and interconnectivity agents, and the dynamic aspects, including the interaction, mutual effects, state transitions, and value creation. OPM captures interactions at various operational and technical levels, dependencies and relations between various layers. This enables modeling interoperability at the user/organization level, system level, and inter-system interconnectivity to facilitate interoperability. Bimodality provides for validating the evolving graphical model using the textual description, appealing to various audiences that may be visually- or verbally-oriented: systems architects, business stakeholders, integrators, etc. Metamodeling provides for transitioning from the generic problem-oriented model to a solutionspecific model, using the same notation to describe the problem (requirements) and solution models, and flexibly adopting the patterns of the metamodel for practical cases. A formal ISO Standard for system and process modeling in general and specifically in future ISO enterprise standards accelerates dissemination and adoption by governments, agencies, and corporates. OPCAT [39] is a free modeling and simulation tool. It supports easy framework adoption and utilization, in conjunction with system-level OPM models.

Availability in SysML Notation focuses on technological elements and concepts. Each diagram kind highlights a separate aspect. No uniform mechanism, BDDs can be elaborated by IBDs; UC in UCD by ADs; AD task by AD activity. Not available as part of the language; possible with reporting tools. Partial, available only with Class/Block Diagrams. Distributed as an OMG Standard. Several tools available for free or licensed use.

SMCA-15-10-0762.R2 infrastructure, supporting the needs of the system interoperability layer. Key MoBIE ontology concepts are defined in Table III. Some of the concepts are mapped in the Description column to analogous concepts in UML/SysML, the DoDAF Metamodel (DM2) [26], and LML [2]. D. The I-domain and Infrastructure While often fuzzy and implicit, the I-domain is a bona fide constituent system of the SoS; it includes the interoperability infrastructure and has functions, boundaries, inputs and outputs, components, and attributes. The I-domain is often more critical to SoS interoperability and more complex than some of its constituent systems. Thus, the I-domain shall be distinctively defined and referred to in any SoS architecture model. Infrastructures can be both physical and virtual. Traditional system-centered architects often perceive the infrastructure as a simple link, ignoring routes and processes that provide for intricate interconnectivity and interoperability of the interfacing systems. While it may be useful to abstract some cross-system interaction as a single link at a higher level, a comprehensive, high-fidelity SoS model must include a detailed specification of the infrastructure. Such a blueprint is indispensable during detailed design of internal and external SoS processes. A detailed infrastructure model helps constituent systems engineers to specify how to utilize the infrastructure in order to generate value for their corresponding beneficiaries. SoS engineers can communicate their model to their constituent systems engineering counterparts, define policies, contracts and interfaces, and provide interaction guidelines. The lowest relevant level of detail of an infrastructure model is the one that affects constituent systems' function, behavior or interoperability, so that level must be in the I-domain model. A medium is a part of the infrastructure through which physical and informatical input-output objects transfer across systems in

Concept Interoperability

I-domain

Interconnectivity Infrastructure Interoperabilityempowered story Interoperable Engagement Agent

Onput

Interface

Medium

4 the SoS. Examples of man-made media are wires, cables, fibers, pipes, conveyor belts, roads, bridges, tunnels, and electromagnetic waves. More immersive, environmental, or informatical media are air, atmosphere, air corridors, naval ocean routes, satellite orbits, interstellar space, intergalactic space, time-space, and cyberspace. Media, such as ocean water or the atmosphere, where naval and air transportation take place, often pertain to the environment, but even environmental media become part of the SoS infrastructure and its model. Defining environmental media as part of the infrastructure allows for gradually extending the borders of the SoS. Auxiliary infrastructure components handle onputs (see next section) and carry out interconnectivity and interoperability management tasks, such as cyber and physical security and safety assurance, content validation and filtering, standardization, regulation, compliance control, traffic control, storage and buffering, service level assurance, billing, pollution monitoring, energy conversion and transformation, signal amplification and multiplication, distribution, and delivery guaranteeing. Capabilities of this nature can be assigned to the I-domain at preliminary, highlevel design phases, and as the design process gets more detailed—to specific infrastructure I-domain components. E. Onput: The abstraction of input and output Interoperability is obtained by sharing and exchanging various onputs. An onput is both the output of its origin— creator, provider, or sender, and the input to its destination— receiver, consumer, or destroyer, hence this overarching bidirectional term replaces both input or output, and we can refer to it also when it is in transit between two SoS systems. The DM2 term Resource [26] is similar, but should not be confused with resources in OPM, which can also be humans, instruments, devices, or assets. As these can be thought of as

TABLE III. KEY INTEROPERABILITY MODELING CONCEPTS Description emergent capability of multiple separate entities to interact, collaborate, and utilize each other to achieve higher level goals

infrastructural, intermediate, and possibly virtual bona fide system, which accommodates the processes among the agents, assets, and resources of the constituent systems, and facilitates or exhibits interoperability SoS-level interaction capability that provides value, to at least one constituent system assembly of components, media, services, and interfaces that comprise I-domain’s operational segment, which facilitates or exhibits interconnectivity. conceptual end-to-end cross-cutting agent-level process that emerges synergistically from one or more interoperable engagements (defined below) SoS cross-system process that provides value to one or more stakeholder groups party, organization, group of people, or individual participating in an interoperable process, who can own, use, benefit from, or hold stakes in constituent systems portmanteau of input and output; object of any nature – energy, matter, money, information, etc. (collectively abbreviated EMMI [40]) – transferrable from the origin as output to the destination as input pair of form (object, subsystem, instrument, endpoint, connector, port, etc.) and function (process, method, service, operation, etc.) – through which two or more systems interact

means through which onput transfers from an origin system to a destination one.

Analogous Concepts DM2: Vision or SoS-level Capability, UML/SysML Use Case with at least two Actors N/A

N/A N/A N/A DM2: Activity, Capability (partial analogy) DM2: Performer, LML: Asset, UML/SysML: Actor. DM2: Resource LML: InputOutput. DM2: Connector, LML: Conduit (form), Action (function) SysML: Port. N/A

SMCA-15-10-0762.R2 enabling resources or progressive onputs, we distinguish between the agent role and the onput role. Progressive onputs can exhibit operations and attributes of their own. These can be elaborated in additional diagrams as the modeler sees fit. An onput can also be an agent or device (performer or asset). The onput's state consists of the set of values or states of its physical and informatical (conceptual) attributes. Physical attributes of onputs include location, size, direction, shape, temperature, or electric charge. Informatical attributes include availability, completeness, and stability. Onput can be complex, compound, continuous, multidimensional, and concurrently physical and informatical. Examples include hard media, printed documents, and currency. Compound information-matter duos travel together or separately through the infrastructure. Examples include data on consumption of various materials being physically consumed, shipping information on cargo or shipped goods, and metadata describing transmitted information. Continuous onputs, such as liquid, electrical charge, or energy, are quantized in some measurement unit (e.g., cubic meters of fluid, Watts of electrical power, Joules of energy. Onputs can be dynamic, evolving, autonomous, or selfregulating. Examples include a vehicle that has left the production line, a product delivered from a hub to its end user through a supply network, a software agent generated by another software in one node of the Internet and installed in another node, and an electromagnetic signal emitted by a transceiver to be relayed by a satellite or relay station and received by another transceiver. Any system can be considered as onput passed between any two consecutive lifecycle stages, e.g., design, development, manufacturing, and deployment. In order to explain the way onput exchange is captured in an interoperability-oriented system view, consider the following annotated narrative on investments and stock exchange: An investor, Investor A, (agent#1) places a sale offer (onput#1) relating to a certain amount of units of some stock at some price. The buyer, Investor B, (agent#2) places a bid (onput#2) against the sale offer. The Broker (agent#3) tries to broker a deal, and, if successful, requests the buyer to transfer money (onput#3). The money is transferred to the seller via a third party clearinghouse (agent#4). The broker then transfers the ownership of the stock (onput#4) from seller to buyer.

5 different onputs are required: sale offer, bid, money, and stock. While the first two onputs, sale offer and bid, are transient adhoc entities needed only to complete the transaction, the other two, money and stock, are persistent assets of the participating investors. Money and stock are quasi-physical entities: they can be transformed into tangible forms, so their locations are critical. As illustrated in Fig. 1, in accordance with the narrator’s point-of-view, the constituent systems serving the parties to transfer or handle the onputs are insignificant, and the process may even be completely manually. Associating the onputs with the investors’ accounts is critical and needs to be completed by the corresponding system agents. F. Operation-to-port folding Onput interactions and transformations can be associated with sending and receiving systems (objects) or operations they perform (processes). A port is a component’s access point to other systems or components, or to the environment. In OPM, a process must mediate interactions between any two objects. MoBIE extends OPM notation to enable operation-to-port folding – conversion of an operation to a procedural port, drawn as a nameless ellipse on the contour of the folded object. As illustrated in Fig. 2, the Onput Yielding and Onput Consuming operations of Component are explicitly defined in the unfolded view (a). In the folded view (b), they are replaced by minimal, nameless ellipse placeholders. This port convention reduces diagram clutter while directly associating operand objects with operator objects. Operation-to-port folding provides for modeling onput exchange operations, while encapsulating them. The operator object assumes the role of its operation with respect to the operand onput object. As Fig. 2 shows, the OPL text for the port-folded- view is also shorter, concealing the operations.

(a)

Component exhibits Onput Consuming and Onput Yielding. Onput Consuming consumes Onput. Onput Yielding yields Onput. Component yields Onput. Component consumes Onput.

(b) Fig. 2. OPM object operation-to-port folding: (a) OPD with Component unfolded; (b) OPD with Component folded.

Fig. 1. Stock Trading Business Interoperability view

In order to complete a stock exchange transaction, four

Operation-to-port folding can be applied to processes as well – thereby implying the delegation of a procedural relation to a lower level subprocess. Similarly, components can be converted to ports of their owning objects or processes. Component-to-port folding for objects implies the logical or physical delegation of a relation to the port component (internal object), and the buffer-zoning of internal objects of processes, similar to arguments and results of a function.

SMCA-15-10-0762.R2 G.

Interfaces, interfacing, and the interface duality Interfaces (form) are objects with interfacing and onput handling operations (function). Examples include sockets, inlets, outlets, antennas, filters, corridors, doors, gates, valves, passages, and foyers. Interfacing can be port-folded to the contour of the Interface object, while the object can be portfolded to its owning system (object) or service (process). Onput processing or manipulating is part of interfacing and can occur during the onput transfer, prior to its final release, or upon its arrival. Examples include water filtering or temperature changing, electric current amplifying or rectifying, and packet sequencing in the TCP/IP protocol. While conceptual modeling advocates modeling function before form, designers are biased towards form-based modeling of interfaces and media. MoBIE advocates modeling the form manifestation of interfaces as a resource for functional interactions, and the form manifestation of media as a resource for technical interactions. The functional manifestation of interfaces – the interfacing operation of the interface object – is part of the functional interaction (layer ii), while the functional operation of the medium – mediating – is part of the technical interaction (layer iii). This notation captures the form-function duality [41], with an object (form) exhibiting a primary process (function, or operation). Thus, the form-function construct is traced to the object, the process, and the value from interaction. H. The MoBIE Reference Model A reference model based on the MoBIE ontology is presented graphically in Fig. 3 and textually in Table IV. This reference model captures the three interoperability layers, the main processes in each layer, and main enablers. Agents interact and exchange onputs via interoperable engagements at the topmost, operational process level. Constituent systems act at the intermediate, system interoperability layer, where functional interactions utilize and orchestrate their services. Finally, system interfaces act at the system interconnectivity layer. In order to create a model of an actual complex SoS that facilitates multilayered interoperability with multiple interactions, we demonstrate how to gradually construct and elaborate the reference model using OPM’s refinementabstraction complexity management mechanism. Optimized for detail-decomposition, OPM lends itself naturally to refinement towards an interoperability-oriented model of a SoS architecture. Gradual elaboration of such a model helps avoid unnecessary system and model complication [42]. Model elaboration corresponds to the operational interoperability, system interoperability, and system interconnectivity layers. The central processes at each layer are refined (unfolded or in-zoomed) in subsequent diagrams. If multiple central processes exist in some layer, e.g., multiple interoperable engagements at the system interoperability layer, the SoS architect can define a single view that contains all these processes and derive a dedicated view by refining each process. The I-Domain has been retained for additional emphasis in this view at the background of the central interoperable engagement AB1 Interoperable Engagement, which involves two agents, Agent A and Agent B, and one kind of onput, Onput

6 1. Thus, AB1 Interoperable Engagement requires AB System Interoperability, i.e., interoperability between the systems that serve Agent A and Agent B, and it generates the AB1 Agent interoperability. AB1 Interoperable Engagement is traced to its reference model class, Interoperable Engagement, using

generalization-specialization. An actual model can omit this traceability to the core concepts and focus on the refined details. Each element in the SoS interoperability view can be further extended using in-zooming or unfolding. This view visually abstracts operational interoperability. The constituent systems that facilitate the SoS function are not shown in this view, as the focus here is on business interoperability. This view appeals to operational stakeholders and end users, who describe the processes they participate in as part of the higher level Interoperability-Empowered Story.

Fig. 3. Model-Based Interoperability Engineering (MoBIE) reference model

I. Operational and system interoperability views The operational interoperability view presented in Fig. 4 captures top-level cross-agent complex, often emergent interoperable engagements. Like the operational interoperability view, the system interoperability view is derived from and elaborates on the same reference model. Fig. 5 shows this view for AB Functional Interaction – the functional interaction between Agent A and Agent B – which occurs in the I-Domain and facilitates AB Interoperable Engagement. At this level, we model the two involved Constituent Systems that serve the agents: System A and System B, A, which serve Agent A and Agent B using Service A and Service B, respectively. The involvement of each constituent system in the central process AB Functional Interaction is done via Interaction A1 and

SMCA-15-10-0762.R2 Interaction B1, which are operations of System A and System B, respectively. Service A and Service B, the two front-end services to the agents, and the back-end involvement in AB Functional Interaction via Interaction A1 and Interaction B1

comprise the constituent systems’ participation in the functional interaction, yielding end-to-end interoperability. J. System interconnectivity view The system interconnectivity view is also derived from the reference model. The OPD in Fig. 6 shows AB Interconnectivity Facilitating as the capability of System A and System B, aided by the Infrastructure, to interface at the system level. The two interacting agents, Agent A and Agent B, are omitted to reduce clutter. AB Interconnectivity Facilitating consists of (a set of) Interface Facilitating process(es) between (couples of) Interface A* and Interface B*, indicated in this view without loss of generality as Interface A1 and Interface B1. This view facilitates communication and collaboration among technically-oriented

ID 1000 1100 1110 1120 1130 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 3000 3100 3200 3210 3220 4000 4100 4200 5000 5100 6000 6100 6200 6210 6220 6230 6231 6232 7000 8000 9000 9100 9200 10000 11000 11100 12000 13000

7 stakeholders. The emerging AB Interconnectivity enables the functional interaction among the systems as shown in Fig. 5. There can be more than two agents and systems in the interoperability and interconnectivity views, and more than one interoperable function in each diagram, but this should be avoided to simplify the diagrams. Complexity can be alleviated using OPM's complexity management mechanisms. A MoBIE-based model is interoperable by design. Having defined the infrastructure, we can model various scenarios that interoperability at the SoS level requires. Scenarios can stem from various onput types, constituent system configurations, and triggering events, such as user requests, timed tasks, or environmental (external) events. Using this conceptual framework in its early form, we analyzed the architecture of medical services interoperability [34]. Medical interoperability allows for medical information sharing, blood sample and donation management, organ transplantation management, etc.

TABLE IV. TEXTUAL SPECIFICATION OF MOBIE REFERENCE MODEL Statement I-Domain exhibits Interoperable Engagement, Interface Facilitating, and Interconnectivity Facilitating. Interoperable Engagement consists of Service Set and Functional Interaction Set. Functional Interaction Set consists of Service Set and Interaction Set. Functional Interaction Set requires System Interconnectivity. Functional Interaction Set affects Onput Interaction Status. Interoperable Engagement requires System Interoperability. Interoperable Engagement affects Onput Interoperability Status. Interoperable Engagement yields Agent Interoperability. Interface Facilitating consists of Interfacing. Interface Facilitating requires Medium and Interface. Interface Facilitating affects Onput Interfacing Status. Interconnectivity Facilitating consists of Interface Facilitating. Interconnectivity Facilitating requires Interconnectivity - Facilitating Component and Constituent System. Interconnectivity Facilitating affects Onput Interconnectivity Status. Interconnectivity Facilitating yields System Interconnectivity. I-Domain consists of Infrastructure. Infrastructure is physical. Infrastructure consists of many Mediums and many Interconnectivity - Facilitating Components. Medium is physical. Interconnectivity - Facilitating Component is physical. Onput Set consists of many Onputs. Onput is physical. Onput exhibits Onput Interoperability Status, Onput Interconnectivity Status, Onput Interaction Status, and Onput Interfacing Status. Agent Set exhibits Agent Interoperability. Agent Interoperability is environmental. Agent Set consists of many Agents. Agent is physical. Agent exhibits Constituent System. Constituent System is physical. Constituent System exhibits Service Set and Interaction Set. Constituent System consists of many Interfaces. Interface is physical. Interface exhibits Interfacing. Agent Set handles Service Set and Interoperable Engagement. System of Systems is physical. System of Systems exhibits System Interconnectivity and System Interoperability. System Interconnectivity is environmental. System Interoperability is environmental. System of Systems consists of many Constituent Systems. Interoperability-Empowered Story exhibits Process Interoperability. Process Interoperability is environmental. Interoperability-Empowered Story consists of Interoperable Engagement. Interoperability-Empowered Story requires Agent Interoperability.

SMCA-15-10-0762.R2

8

Fig. 4. Reference pattern of the operational interoperability view

Fig. 6. Reference pattern of system interconnectivity view

The aerospace domain clearly manifests the three levels of interoperability. Global air travel is made possible due to largescale interoperability across stakeholder parties, including airports, airline companies, aircraft manufacturers, ground service providers, travel agencies, and aerospace authorities. For interoperability at such a high level to thrive, interconnectivity must be maintained among the cyber-physical systems owned and used by the involved parties. This interoperability is a prime condition for air travel management, control, and seamless execution processes. Failure to account for all the three interoperability levels may limit our understanding of the true nature of complex challenges within the problem domain and hinder the ability of systems of systems to exhibit and benefit from emergence [47].

Fig. 5. Reference pattern of the system interoperability view

III. INTEROPERABILITY IN AIRPORT OPERATIONS: PASSENGER DEPARTURE A. Interoperability in civil aviation: A case in point In this section we apply MoBIE to model and analyze airport terminal interoperability. Commercial aviation and aerospace systems, such as air traffic control, airport services and operation, national transportation, and flight scheduling and booking pose complex challenges, strongly qualifying them as SoS problems [43]. These aviation systems involve a plethora of disciplines, including economics, civil engineering, aerospace engineering, management science, information systems, security, safety, survivability, and operational continuity [44]. The Federal Aviation Administration (FAA)’s Next Generation Air Transportation System (NextGen) program is an interconnected, interdependent SoS, challenging common modeling and analysis techniques [45], [46].

B. Passenger departure Our case in point focuses on international passenger departure. Airports were traditionally perceived as constructions with many adjacent systems and facilities owned by silo parties, rather than an integrated SoS, in which communication, coordination, and collaboration among the parties is a matter of course. As part of a major paradigm shift in the domain toward a SoS approach, MoBIE facilitates integrated passenger routing and control by a host of service providers and authorities that share information in real-time, significantly shortening passenger departure and arrival turn-around time. The MoBIE model covers a host of services and activities that facilitate the interoperable scenario of passenger and baggage routing through all relevant airport facilities, all the way to the aircraft. Passenger and baggage routing through an airport all the way to the aircraft is an interoperable engagement. It emerges as a synergetic result of performing a set of coordinated processes and ad-hoc collaborations among disparate, looselycoordinated systems. The passenger departure scenario is modeled from the viewpoint of its primary beneficiary—the passenger. The aggregate set of operations that the passenger experiences during this process and collaboration among the service providers in the various stations qualifies this scenario

SMCA-15-10-0762.R2

9

as an interoperable engagement. Fig. 7 shows the topmost operational interoperability view. We begin by capturing the Interoperability-Empowered Airport Operation interoperability-empowered story in the broadest possible sense, including such interoperable engagements as Interoperable Terminal Service Operation, Interoperable Aerodrome Operation, and Interoperable Airspace Operation. The name preamble terms Interoperability and Interoperable are optional ontological descriptors. In addition to the high-level interoperable story and engagements, this view defines the Airport as an I-Domain, specifies airport-related and external agents, and captures eight onputs, including Passenger, Baggage, Airplane, and the Information associated with them. Due to the complexity of the problem, we focus on terminal services, expressed as the Interoperable Terminal Service Operation Engagement – an operation within Airport. We unfold it in Fig. 8 to another lower level operational interoperability view, which shows the relevant agents, onputs, and two core constituent Functional Interactions – Passenger Departure and Passenger Arrival.

interoperability view that is relevant to this interaction, in which the Passenger Departure process is unfolded. This view exposes i) the constituent systems that serve the various agents, including the Airline’s Ticketing System, and the Airport’s Flight Management System, ii) the functional services and interactions provided by those systems, including the Passenger Management and Baggage Management services provided by the Ticketing System, and iii) the agents that use the systems and operate these services, including the Airline Personnel and Ground Personnel.

Fig. 9. Passenger departure – system interoperability view

This view aggregates the services involved in facilitating the Passenger Departure emerging functional interaction, which takes place in the Airport—the I-Domain, and cannot be

Fig. 7. Interoperability-empowered interoperability view

airport

operations:

operational

Fig. 8. Interoperable terminal service operation: operational interoperability view

Examining Fig. 8, we focus on the Passenger Departure process and derive a system interoperability view for this specific interaction. In Fig. 9 we present the system

attributed to any specific agent or party. The reason for the preceding higher-level OPDs in Fig. 7 and Fig. 8 is that one can reach a high fidelity model of the Passenger Departure process only if it is placed in this context as part of the broader SoS of the Airport, in which the major contributing services that the various agents and systems provide have been identified and modeled. Elaborating on this second-level interoperability view, we can design the interconnectivity view. This level exposes the constituent system interfaces for exchanging the onputs Passenger and her/his Baggage, along with their corresponding informatical iPassenger and iBaggage objects. Using OPM's process in-zooming mechanism, we present the procedural aspect of Passenger Departure in Fig. 10. This OPD elaborates on the activities (subprocesses) that occur sequentially during this process (from top to bottom within the in-zoomed process ellipse, according to the OPM timeline principle), along with the objects they transform. Based on a well-defined and coherently-derived SoS architecture model, we can seamlessly move towards system and SoS procedural scenario modeling. At the system level, we expose details of the

SMCA-15-10-0762.R2 fine-grained services and operations of each constituent system. At the SoS procedural scenario level, we model, analyze, and simulate SoS behavior that we could not necessarily infer and understand from disparate constituent system views.

10 compliance verification, such as passenger-baggage coboarding assurance, lost or misrouted baggage handling, and passenger and baggage cross-profiling (for security purposes). The integrated view thus triggers insights that a standard SoS model could potentially fail to capture. Third, this process begins when Passenger and Baggage are united before checkin, and ends when they are reunited on the Airplane. Civil aviation regulations mandate joint passenger-baggage travel. As more constraints and considerations are added to the model, the model becomes increasingly valuable for verifying the modeled airport’s compliance with this critical regulation. Fourth, the model jointly captures the exchange of the physical objects and of their corresponding informatical onputs – iPassenger and iBaggage, as reflected by the output state resulting from each subprocess, by using exchange-reflective states and state transitions for each onput. Onput state transitions generalize the simplistic location-biased interoperability paradigm, which perceives the physical transfer of matter and message as the primary manifestation of interoperability. While this is a critical condition for successful interoperability, it is definitely insufficient in complex interaction scenarios. IV. MOBIE WITH UML OR SYSML

Fig. 10. Passenger departure process in-zoomed

Fig. 10 specifies nine subprocesses, assembled from five different constituent system services (shown in Fig. 8), which are organized as a business process in a logical and sequential operational order: Passenger Check-in, Baggage Check-in, Passenger Security Clearance, Passenger Immigration Clearance, Baggage Security Clearance, Baggage Routing, Baggage Loading, Passenger Boarding and Passenger Departing. This view supports interoperability analysis by capturing the evolving states of the onputs of interest to several different airport systems. At each point in the process, we can determine the integrated system state as the combination of the states of all the onputs in the process: Passenger, Baggage, and even the Airplane, which is an instrument (enabler) for Baggage Loading and Passenger Boarding in this process. Fig. 10 also captures a running OPCAT simulation of Passenger Departure. We sampled the simulation after the Passenger has passed security and immigration and is in the passenger hall, and technically at the state out of the country. At the same time, the passenger’s baggage is being loaded onto the parked Airplane. The simulation demonstrates the concurrent state change of the physical Baggage from ready for loading to loaded, and of the informatical iBaggage from listed as safe to listed as loaded. An external collection of Airplaneaffecting process designators implies a parallel Airplane Departure process. Hence, this view demonstrates airport-level interoperability of airplane and passenger departures. Integrating the processes that Passenger and Baggage undergo separately is critical for several reasons. First, this integration captures the end-to-end process from the Passenger entering the terminal till Passenger Departing – the pivotal experience around which the entire terminal operation is designed. Second, the integration enables regulation and policy

MoBIE ontology may be implemented also in UML and SysML. In this section, we briefly discuss the feasibility of utilizing UML or a UML-profile like SysML as a MoBIE modeling language. Interoperable functionalities and scenarios can be captured as use cases, but these can only count as interoperable if they involve at least two actors playing roles in two separate systems. This means that a SysML model has to first capture the SoS that hosts the interoperable use cases as the model’s core system, with the constituent systems being blocks or subsystems. This approach limits the model’s capability to capture interconnectivity processes as use cases, since in this case, the constituent systems have to be represented by actors rather than blocks, or as an actor-block pair. Use case diagrams do not provide for expressing onput exchange, which is key to explicit modeling of interconnectivity and system-level interaction. To model onput exchange, each operational or technical interoperability use case has to be extended to an activity diagram that captures both control flow and data flow. However, activity diagrams are more suitable for describing interactions among actors rather than systems. Referring to a system or subsystem as a business actor is possible, but this restricts the interactions to be actorbased and requires several kinds of diagrams to express the interactions: use case diagram, which is utility-based, activity diagram, which is activity-based, and sequence diagram, which is message-based. Moreover, each system modeled as a business actor would have its own full-scale model, raising the difficult issues of ensuring the long-term consistency of the system's core model with its individual business actor models. Onput exchange can be captured in SysML Functional Block Diagrams (FBDs). However, the onputs are placed on the flow links between blocks or ports rather than being captured as bona

SMCA-15-10-0762.R2 fide classes. For this purpose, a hybrid block-class diagram has to capture the relations among system classes (blocks) and data classes. Physical onputs like money should be captured as stereotyped classes of this nature. In addition, sequence diagrams should be used to model the details of onput exchange transactions among actors, constituent system block designators, components, or ports. Onputs are substantially UML classes or SysML blocks. In class diagrams, it is often unclear whether a class is a component (e.g., UML control or boundary) or an entity. In UML, text tags on links usually describe relations – the ways one class affects another. Legacy block diagrams use text tags on directed links to denote interfaces or channels. SysML's internal block diagram and activity diagram include notation to record onput next to input- and output-ports. However, these text tags often describe inter-object services or actions (e.g., 'induction' or 'filtering', rather than the characterization of the transformed onput – 'induced current' or 'filtered water'), or even the type of the medium underlying the interface (e.g., 'Ethernet', 'Fire wire', or even '100 Mbps' ), rather than the identifier of the transferred onput. This mix of usages due to under-defined semantics confuse modelers and diagram readers, be they novices or experts. Finally, onput states, including location and other state characteristic attributes, can be captured with statecharts [48]. However, each state-chart refers to a single object and does not allow for cross-onput state transition illustrations, such as transferring money in exchange stock in a previous example. According to this analysis, we need at least six different diagram kinds—use case, activity, block, class, sequence, and state-chart—in order to capture the high-level aspects of interoperability among agents and interconnectivity among constituent systems alone. Each diagram kind captures a different aspect of interoperability— structural, functional, procedural, data, or state, but no diagram captures them all in a single view. Some semantics have to be modified or used out of their originally intended context. This can be partially resolved by creating a dedicated UML profile that accommodates the relevant semantic structures. However, profiles are not part of SysML, as it is already a UML profile. V. CONCLUSION AND DISCUSSION We have introduced a model-based interoperability engineering framework, MoBIE, for modeling and architecting interoperability and collaboration in a SoS, and for incorporating these synergetic notions into the design of complex interactions among constituent systems. MoBIE encompasses interoperability from the stakeholder and business process level, via system-level functional interaction, to technical interconnectivity. Establishing information or matter transfer channels between disparate systems is only a starting point for successful integration; defining, supporting, facilitating, and delivering business-level end-to-end capabilities require an interoperability framework, as this study establishes in theory and demonstrates in practice. MoBIE refers to the interoperability domain as a system in its own right, even when vaguely defined as such. MoBIE refers

11 to constituent systems, interfaces, media, and onputs with the same semantics and the same structure, behavior, and function modeling rules. It supports physical, informatical, and hybrid interoperability. Using OPM refinement-abstraction mechanisms, reinforced by operation-to-port folding, MoBIE accommodates the somewhat controversial, yet common expectation for infrastructure 'transparency'. Finally, MoBIE SoS and its constituent system models are similar, allowing for seamless integration based on a shared modeling language, OPM. These significant departures from other interoperability frameworks, offer major advantages over those frameworks. MoBIE can benefit interoperability and interconnectivity infrastructure engineers by facilitating interactions among disparate constituent systems in various domains, including aerospace, defense, healthcare, manufacturing, supply chain, cyber technology, and information technology. MoBIE improves the constituent systems engineers’ awareness of the environmental context. Interoperability programs often fail due to inability of the constituent systems to adapt to each other. MoBIE encourages communication, collaboration, common understanding of goals and objectives, and reasoning about interoperability. This way, it helps reduce the likelihood of failure due to insufficient understanding among stakeholders. Interoperability-oriented modeling frameworks such, as LML, MP, and MoBIE, presented here, foster simplicity through abstraction, elicitation of conditions for interoperability, and executable formalism. This shared approach constitutes a potentially fertile ground for synergistic integration of these approaches. Future work in this area should explore the possibilities for combining and leveraging the strengths of each approach in a unified analysis framework. We have demonstrated the applicability of MoBIE in airport operations, focusing on passenger departure. Insights from this approach can be implemented with relative ease in modern airport designs. Aerospace Interoperability is much more than data sharing between airspace control units and airlines; it is the capability of the global aerospace ecosystem to let any authorized aircraft land, pick up passengers, baggage or cargo, take-off, and safely, securely, reliably, and efficiently reach its destination, wherever around the globe it may be. MoBIE does not directly address tangible issues arising from the physical nature of the interaction, the media, or the type of the SoS constituent systems, such as chemical or mechatronic facets of the interaction. Rather, the power of this framework stems from its generality, which makes it applicable to a host of domains. Future research should attempt to bring the conceptual and physical aspects closer. MoBIE is currently focused on friendly interactions. However, it can potentially be extended to interdependent SoS constellations in which the interaction is random or hostile. This is a modeling challenge that requires joint consideration of SoS risk, resilience, and robustness. Future research should attend to this challenge as well. MoBIE has the potential to be implemented as an architecture framework (AF). Future research should explore the opportunities of interoperability between MoBIE and other AFs. MoBIE can potentially serve as a basis for deriving multilayered interface contracts for

SMCA-15-10-0762.R2

12

complex interactions, which are traditionally recorded in interface contract documents (ICD). Often, the current result is system-centered, which refers to external systems as 'black boxes', leaving room for ambiguity, misunderstanding, and complication. Finally, MoBIE can support quantitative interoperability and interdependence assessment in SoS. Advances in this area [2], [49] may guide this direction. ACKNOWLEDGMENT We thank Gordon Center for Systems Engineering at the Technion – Israel Institute of Technology, for supporting this research. We thank the anonymous referees for their useful feedback and advice on paper improvement and future research. REFERENCES

[16] M. J. DiMario, “System of systems interoperability types and characteristics in joint command and control,” in IEEE International Conference on System of Systems Engineering. [17] J. A. Estefan, “Survey of Model-Based Systems Engineering Methodologies,” 2008. [18] A. L. Ramos, J. V. Ferreira, and J. Barceló, “Model-based systems engineering: An emerging approach for modern systems,” IEEE Trans. Syst. Man Cybern. Part C Appl. Rev., vol. 42, no. 1, pp. 101–111, 2012. [19] M. Bjelkemyr, D. T. Semere, and B. Lindberg, “Definition, classification, and methodological issues of system of systems,” in Systems of Systems Engineering - Principles and Applications, M. Jamshidi, Ed. CRC Press, 2009. [20] OMG, OMG Systems Modeling Language (OMG SysML) Version 1.3, no. 1.3. 2012. [21] D. Long and Z. Scott, A Primer for Model-Based Systems Engineering, 2nd Editio. Vitech Corporation, 2011. [22] Y. Tan, S. Goddard, and L. C. Pérez, “A prototype architecture for cyberphysical systems,” ACM SIGBED Rev., vol. 5, no. 1, pp. 1–2, Jan. 2008.

[1]

A. Tzanev, “Modeling and Simulation of Systems of Systems - a Survey,” Cybern. Inf. Technol., vol. 13, no. 2, pp. 3–36, 2013.

[2]

K. Giammarco, “A Formal Method for Assessing Architecture Model and Design Maturity Using Domain-independent Patterns,” Procedia Comput. Sci., vol. 28, no. Cser, pp. 555–564, 2014.

[3]

C4ISR Architecture Working Group, “Levels of information systems interoperability (LISI),” 1998.

[24] M. Auguston and C. Whitcomb, “Behavior Models and Composition for Software and System s Architecture,” in 24th International Conf. on Software & Systems Engineering - ICSSEA, 2012.

[4]

F. Lamparthaki, S. Koussouris, C. Agostinho, R. Jardim-Goncalves, Y. Charalabidis, and J. Psarras, “Infusing scientific foundations into Enterprise Interoperability,” Comput. Ind., vol. 63, pp. 858–866, 2012.

[25] B. P. Zeigler and S. Mittal, “Enhancing DoDAF with a DEVS-Based System Lifecycle Development Process,” in IEEE International Conference on Systems, Man, and Cybernetics, 2005.

[5]

F. B. Vernadat, “Interoperable enterprise systems: Principles, concepts, and methods,” Annu. Rev. Control, vol. 31, no. 1, pp. 137–145, Jan. 2007.

[6]

D. Chen, G. Doumeingts, and F. B. Vernadat, “Architectures for enterprise integration and interoperability: Past, present and future,” Comput. Ind., vol. 59, no. 7, pp. 647–659, Sep. 2008.

[7]

Y. Naudet, T. Latour, W. Guedria, and D. Chen, “Towards a systemic formalisation of interoperability,” Comput. Ind., vol. 61, no. 2, pp. 176– 185, Feb. 2010.

[8]

A. P. Sage and C. L. Lynch, “Systems integration and architecting: An overview of principles, practices, and perspectives,” Syst. Eng., vol. 1, no. 3, pp. 176–227, 1998.

[9]

R. Brooks and A. P. Sage, “System of systems integration and test,” Information, Knowledge, Syst. Manag., vol. 5, pp. 261–280, 2006.

[10] A. Sheth, “Changing focus on interoperability in information systems: From system, syntax, structure to semantics,” in Interoperating Geographic Information Systems, M. Goodchild, M. Egenhoffer, R. Fegeas, and C. Kottman, Eds. Kluwer, 1998. [11] B. Boehm, “Some future trends and implications for systems and software engineering processes,” Syst. Eng., vol. 9, no. 1, pp. 1–19, 2006. [12] C. M. Parks, D. A. Koonce, L. C. Rabeldo, R. P. Judd, and J. A. Sauter, “Model-Based Manufacturing Integration: A Paradigm for Virtual Manufacturing Systems Engineering,” Comput. Ind. Eng., vol. 27, no. 94, pp. 357–360, 1994. [13] T. J. Williams, P. Bernus, J. Brosvic, D. Cben, G. Doumeingts, L. Nemest, J. L. Nevins, and B. Vallesplr, “Architectures for Integrating Manufacturing Activities and Enterprises,” Control Eng. Pract., vol. 2, no. 6, pp. 939–960, 1994. [14] S. Y. Nof, G. Morel, L. Monostori, a. Molina, and F. Filip, “From plant and logistics control to multi-enterprise collaboration,” Annu. Rev. Control, vol. 30, no. 1, pp. 55–68, Jan. 2006. [15] H. Panetto, R. Jardim-Goncalves, and A. Molina, “Enterprise Integration and Networking: Theory and practice,” Annu. Rev. Control, Oct. 2012.

[23] E. a. Lee, “Cyber Physical Systems: Design Challenges,” 11th IEEE Int. Symp. Object Component-Oriented Real-Time Distrib. Comput., May 2008.

[26] DoD, “DoD Architecture Framework Version 2.02,” 2009. [27] H. Jørgensen, T. Liland, and S. Skogvold, “Aligning TOGAF and NAFExperiences from the Norwegian Armed Forces,” Pract. Enterp. Model., pp. 131–146, 2011. [28] M. Hause, “The Unified Profile for DoDAF/MODAF (UPDM) enabling systems of systems on many levels,” in 2010 IEEE International Systems Conference, 2010, pp. 426–431. [29] M. Hause, “Rebuilding the Tower of Babel The Case for a Unified Architecture Framework,” in INCOSE Internaional Symposium, 2013. [30] J. Durham, R. Zeller-Townson, L. McLauchlan, M. Mehrubeoglu, R. Cardenas, F. Dejesus, and John McDonnell, “Network-Centric Operations Support: Lessons Learned, Status, and Way-Ahead,” in 19th International Command and Control Research and Technology Symposium - ICCRTS, 2014. [31] D. Dori, Model-Based Systems Engineering with OPM and SysML. New York: Springer, 2016. [32] D. Dori, Object-Process Methodology: A Holistic Systems Approach. Berlin, Heidelberg, New York: Springer, 2002. [33] ISO/TC 184, ISO/PAS 19450:2015 Automation systems and integration — Object-Process Methodology, no. 1. ISO, 2015. [34] Y. Mordecai and D. Dori, “I5 : A Model-Based Framework for Architecting System-of-Systems Interoperability, Interconnectivity, Interfacing, Integration, and Interaction,” in INCOSE International Symposium, 2013. [35] J. P. Wachs, B. Frenkel, and D. Dori, “Operation room tool handling and miscommunication scenarios: An object-process methodology conceptual model,” Artif. Intell. Med., vol. 62, no. 3, pp. 153–163, 2014. [36] C. A. Osorio, D. Dori, and Joseph Sussman, “COIM: An Object-Process Based Method for Analyzing Architectures of Complex, Interconnected, Large-Scale Socio-Technical Systems,” Syst. Eng., vol. 14, no. 3, pp. 305–326, 2011. [37] J. Somekh, G. Haimovich, A. Guterman, D. Dori, and M. Choder, “Conceptual Modeling of mRNA Decay Provokes New Hypotheses,” PLoS One, vol. 9, no. 9, p. e107085, 2014.

SMCA-15-10-0762.R2 [38] Y. Mordecai and D. Dori, “Model-based risk-oriented robust systems design with object-process methodology,” Int. J. Strateg. Eng. Asset Manag., vol. 1, no. 4, pp. 331–354, 2013. [39] D. Dori, C. Linchevski, and R. Manor, “OPCAT – An Object-Process CASE Tool for OPM-Based Conceptual Modelling,” in 1st International Conference on Modelling and Management of Engineering Processes, 2010, pp. 1–30. [40] E. Grönlund, “A Holistic Socioecological Systems Approach at the Regional Level – The EMPI (EMMI),” in 55th Annual Meeting of the ISSS, 2011, vol. 55, no. 1. [41] E. Crawley, O. De-Weck, S. Eppinger, C. Magee, J. Moses, W. Seering, J. Schindall, D. Wallace, and D. Whitney, “Engineering Systems Monograph,” 2004. [42] J. E. Kasser, “Seven systems engineering myths and the corresponding realities,” 2010. [43] S. Nahavandi, D. Creighton, M. Johnstone, and V. T. Le, “Airport operations: a system-of-systems approach,” in Systems of Systems Engineering - Principles and Applications, M. Jamshidi, Ed. CRC Press, 2009. [44] N. J. Ashford, S. Mumayiz, and P. H. Wright, Airport Engineering: Planning, Design and Development of 21st Century Airports. John Wiley & Sons, 2011. [45] Y. Y. Haimes, “Systems-based guiding principles for risk modeling, planning, assessment, management, and communication.,” Risk Anal., vol. 32, no. 9, pp. 1451–67, 2012. [46] M. R. Blackburn and A. Pyster, “Modeling and Analysis Framework for Risk - Informed Decision Making for FAA NextGen,” in INCOSE International Symposium, 2013. [47] M. Rohatgi and G. Friedman, “A structured approach for assessing & analyzing technical & nontechnical interoperability in socio-technical systems,” in IEEE International Systems Conference, 2010. [48] D. Harel and M. Politi, Modeling reactive systems with statecharts: the STATEMATE approach. McGraw-Hill, Inc., 1998. [49] T. Ford, “A Survey on Interoperability Measurement,” in 12th International Command and Control Research and Technology Symposium - ICCRTS, 2007.

Yaniv Mordecai (M'2013) holds a Ph.D. in information systems engineering from Technion – Israel Institute of Technology, Haifa, Israel (2016), and M.Sc. (2010, cum laude) and B.Sc. (2002) degrees in industrial engineering from Tel-Aviv University, Tel-Aviv, Israel. He is currently an adjunct lecturer and researcher at the Faculty of Industrial Engineering & Management in the Technion, and a senior systems engineer in an aerospace & defense corporate, with experience in several IT and defense companies and in the Israeli Air Force. He has authored and presented several refereed publications. His research interests include model-based systems engineering, cybernetics, interoperable systems, risk and decision analysis, and operations research. Dr. Mordecai is a member of the IEEE, including the SMC and Computer Societies, INCOSE, and the Society for Risk Analysis (SRA). He won several research

13 awards and grants from IEEE, SRA, Israel Ministry of Science and Technology, and Gordon Center for Systems Engineering. He acted as manuscript reviewer for the IEEE Transactions on Systems, Man, and Cybernetics, INCOSE Systems Engineering journal, IEEE Systems Conference, and Springer Academic Publishers. Ori Orhof received his Ph.D. in information systems engineering from Technion – Israel Institute of Technology, Haifa, Israel (2015). He holds M.Sc. (1996) and B.Sc. (1993) degrees in industrial engineering & management from the Technion. He is a faculty member at the Dan School of HiTech in the Center for Academic Studies, Or-Yehuda, Israel. He is a proficient project management consultant, instructor, and program manager in large-scale technological, security and operational projects, with special expertise in airport and terminal operations and security. He has authored and presented several refereed publications. His research interests include program and project management, project classification and evaluation, project-product integration, and aerospace applications. Dr. Orhof is a member of PMI and INCOSE. Dov Dori (SM’1999) holds a Ph.D. (1988) in computer science from Weizmann Institute of Science, Rehovot, Israel, M.Sc. (1981) in operations research from Tel Aviv University, Tel Aviv, Israel, and a B.Sc. (1975) in industrial engineering and management from Technion – Israel Institute of Technology, Haifa, Israel. Prof. Dori is the Harry Lebensfeld Chair of Industrial Engineering and Head of the Enterprise System Modeling Laboratory at the Faculty of Industrial Engineering and Management at the Technion. He is alternately Visiting Professor at Massachusetts Institute of Technology, Cambridge, MA, USA. He invented and developed object–process methodology, OPM, the ISO 19450 Standard. He has authored, co-authored or edited six books and over 300 journal, conference publications and book chapters. His research interests include model-based systems engineering, conceptual modeling of complex systems, systems architecture and design, software and systems engineering, and systems biology. Prof. Dori is a fellow of INCOSE, fellow of the IAPR, senior member of IEEE, and fellow of the Alpha Omega Alpha Honorary Society. He was awarded the Kaplan Prize for his invention of OPM.