Model-Based Interoperability Engineering in Systems-of-Systems and Civil Aviation Yaniv Mordecai, St. 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 (MBSE) approach. This paper describes a framework for model-based interoperability engineering (MoBIE) for systems of systems (SoS), which integrates multi-layered interoperability specification into SoS conceptual modeling and architecting. Treating interoperability infrastructure as a system in its own right, MoBIE facilitates interoperability among existing agents, systems, and services. MoBIE is founded on ISO 19450 standard – Object–Process Methodology, a holistic paradigm for modeling and architecting of complex, dynamic, and multidisciplinary systems. OPM accommodates SoS interoperability synergistically with system-centric models. We demonstrate a MoBIE application of modeling the critical passenger departing process in a new airport terminal within the commercial aviation SoS.
Index Terms—Interoperability, Model-Based Systems Engineering, Object Process Methodology, Systems of Systems
I. INTRODUCTION AND LITERATURE REVIEW Interoperability, 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 features of complex systems and systems of systems (SoS) [1]. The primary objective of interoperability is to increase the value that beneficiaries of constituent systems gain and the systems' ability to meet their objectives as a result of the additional value that they obtain from interacting with other systems [2].
This paper evolved from a conference paper [33]. First submitted as regular paper manuscript on December 2014. Revised and resubmitted on Oct 2015. This work was supported by the Gordon Center for Systems Engineering at the Technion – Israel Institute of Technology, Haifa, Israel. Yaniv Mordecai (
[email protected]), Ori Orhof, and Dori are with the Technion – Israel Institute of Technology, Haifa, Israel.
An emerging topic of research [3]–[6], interoperability is especially common in defense applications [7], [8], information technology [9], [10], and manufacturing and supply chains [11]–[14]. 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 or business process interoperability encompasses orchestration, coordination, synchronization, and alignment among multiple, autonomous operational or 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 [15]. 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, and v) enterprise or universal interoperability [16]. Nevertheless, from the constituent systems' perspective, interoperability is secondary in importance to their core, autonomous functionality; it is expected to be "transparent", to have a minimal impact on each individual system, and to be as uninvolved as possible. 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, to require minimal or no changes in order to connect to the service, and to have minimal involvement in or impact on the business transaction. 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. 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 [7], [19]. However, common modeling languages, such as the Systems Modeling Language (SysML) [20], enhanced functional flow block diagrams (EFFBD) [21], and cyber-
physical systems modeling approaches [22], provide limited support for interoperability aspects, because they are designed for system-level analysis and specification rather than for SoS level [23]. Interoperability-oriented specification languages, such as the Monterey-Phoenix (MP) Event Grammar [24] and the Lifecycle Modeling Language (LML) [2], have dedicated syntax, semantics, ontologies, evaluation schemes and utilization frameworks, but are not supported by holistic conceptual modeling frameworks and model-based systems engineering processes. Architecture Frameworks (AF), such as the US Department of Defense (DoDAF) and British Ministry of Defense Architecture Framework (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. This paper proposes a model-based interoperability engineering framework, MoBIE, which accommodates, enhances, and utilizes SoS interoperability. 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]. OPM, the ISO 19450 standard for system and process modeling [32]; is a holistic conceptual modeling paradigm for multidisciplinary, complex, and dynamic systems. OPM is state-of-the-art MBSE paradigm beside the OMG UML and SysML standards [18]. MoBIE has evolved from the I5 concept, an end-to-end view of interoperability, interconnectivity, interaction, interfacing, and integration [33]. In this paper, we demonstrate the applicability of MoBIE to civil aviation, a prominent interoperability-reliant domain. 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 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 bimodal representation and complexity management, we use OPM as our underlying modeling language. We first briefly introduce OPM and the main advantages of basing MoBIE on it.
A. 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 self-similar, notationconsistent, hierarchically organized, interconnected, and cross-validated Object-Process Diagrams (OPDs)—the only kind of OPM diagram (for comparison, SysML has nine diagrams kinds; UML has 13). An OPD contains things—stateful objects and processes—connected with several kinds of links. The root diagram is called System Diagram, SD. 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 lowerlevel 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 created on the fly in response to the modeler's graphic input. OPM Elements are Things and Links. Things are Process (ellipse), and Object (rectangle). Objects can be stateful, i.e., have states. Processes and Objects exhibit the inherent attributes Essence (which can be informatical or physical) and Affiliation (which 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 1 presents OPM’s characteristics and capabilities that make it suitable for interoperability modeling and architecting, and analogous SysML features.
TABLE 1. ADVANTAGES OF OPM FOR SOS INTEROPERABILITY MODELING AND ANALYSIS
OPM feature
Utilization for interoperability modeling and analysis
Availability in SysML
Universal ontology
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 [34]–[37].
Notation focuses on technological elements and concepts.
A unified staticdynamic modeling approach
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.
Each diagram kind highlights a separate aspect.
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.
No uniform mechanism, but BDDs can be elaborated into IBDs; UC in UCD into ADs; AD task into AD activity.
Bimodality provides for validating the evolving graphical model using the textual description, catering to various audiences that may be visually- or verballyoriented: systems architects, business stakeholders, integrators, etc.
Not available as part of the language; possible with reporting tools.
Built-in hierarchical decomposition and complexity management Bimodal graphical-textual equivalent representation Metamodeling capability ISO standardization (ISO 19450) CASE tool availability
Metamodeling provides for transitioning from the generic problem-oriented model to a solution-specific 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 [38] is a free modeling and simulation tool. It supports easy framework adoption and utilization, in conjunction with system-level OPM models.
Partial, available only with Class/Block Diagrams. Distributed as an OMG Standard. Several tools available for free or licensed use.
B. Three Layers of Interoperability The MoBIE interoperability metamodel consists of three layers: i) business/operational interoperability, ii) system interoperability, and iii) system interconnectivity. The synergetic value of the first, business/operational layer emerges from coordination, synchronization, and alignment of disparate interoperable cross-system engagements. These engagements are interwoven into the business/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 business/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 infrastructure, catering to the needs of the system interoperability layer. Key MoBIE ontology concepts are defined in Table 2. Some of the concepts are mapped in the Description column to analogous concepts in UML/SysML, the DoDAF Metamodel (DM2) [26], and LML [2].
TABLE 2. KEY INTEROPERABILITY MODELING CONCEPTS
Concept I-domain
Interoperability
Agent
Interoperabilityempowered story Interoperable Engagement Interconnectivity Onput
Interface
Medium Infrastructure
Description Analogous Concepts I-domain is an infrastructural intermediate bona fide system like any N/A other constituent SoS system, I-domain, which accommodates both the interoperability processes among the agents, assets, and resources of the other systems. Interoperability is the emergent value that stems from collaborative DM2: Vision or SoS-level and collaboration facilitating processes at the stakeholder/operational Capability, level. UML/SysML Use Case with at least two Actors Agent is a party, an organization, a group of people, or an individual DM2: Performer, participating in an interoperable process. It can be an owner, user, LML: Asset, UML/SysML: beneficiary, or stakeholder of a constituent system. Actor. A conceptual end-to-end cross-cutting agent-level process that N/A emerges synergistically from one or more interoperable engagements (defined below). Interoperable engagement is a SoS cross-system process that DM2: Activity, Capability provides value to one or more stakeholder groups. (partial analogy) Interconnectivity is a SoS-level interaction capability that provides N/A value, to at least one constituent system. A portmanteau of input and output, onput is an object of any nature DM2: Resource – energy, matter, money, information, etc. (collectively abbreviated LML: InputOutput. EMMI [39]) – transferrable from the origin as output to the destination as input. Interface is a pair of form (object, subsystem, instrument, endpoint, DM2: Connector, connector, port, etc.) and function (process, method, service, LML: Conduit (form), operation, etc.) – through which two or more systems interact. Action (function) SysML: Port. Medium is the means through which onput transfers from an origin system to a destination one. Infrastructure is an assembly of components, media, services, and interfaces that comprise I-domain’s operational segment.
N/A N/A
Notation Conceptual object
Conceptual object
Physical object Informatical process Informatical process Informatical process Physical or informatical object Objectprocess duo with onputcorrelated essence Physical object Physical object
C. The I-domain and Infrastructure of Interoperability 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 onputs transfer across systems in 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 the air or atmosphere, air corridors, naval ocean routes, satellite orbits, and even more generally—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 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, abuse and fraud detection, 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, high-level design phases, and as the design process gets more detailed—to specific infrastructure I-domain components. D. 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 ambiguous, since resources can also be humans, instruments, devices, or assets. Onput can be complex, compound, continuous, multi-dimensional, 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. Like any object, onputs can exhibit operations and attributes of their own, and these can be elaborated in additional diagrams as the modeler sees fit. The state of an onput (like that of any compound object) consists of the set of values or states of its set of
attributes. These may be physical, such as location, size, direction, shape, temperature, or electric charge, or conceptual, such as availability, completeness, and stability. Onputs can be dynamic, evolving, autonomous, or self-regulating. 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: A stockholder (agent#1) places a sale offer (onput#1) relating to a certain amount of units of some stock at some price. The buyer (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.
Fig. 1. Stock Trading Business Interoperability view
In order to complete a stock exchange transaction, four different onputs are required: sale offer, bid, money, and stock. While the first two onputs, sale offer and bid, are transient ad-hoc 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. 4, in accord 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. E. 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. 5, 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. 5 shows, the OPL text for the folded-ported 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.
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 bufferzoning of internal objects of processes, similar to arguments and results of a function. F. 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 ported-folded to the contour of the Interface object, while the object can be ported- folded 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 [40], 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. G. The MoBIE Reference Model A reference model based on the MoBIE ontology is presented graphically in Fig. 6 and textually in Table 3. 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 refinement-abstraction 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 [41]. Model elaboration corresponds to the business/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 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 business/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 caters to operational stakeholders and end users, who describe the processes they participate in as part of the higher level Interoperability-Empowered Story.
Fig. 3. The Model-Based Interoperability Engineering (MoBIE) reference model
H. The business/operational interoperability view The business/operational interoperability view presented in Fig. 7 captures top-level cross-agent complex, often emergent interoperable engagements.
Fig. 4. Reference pattern of the business/operational interoperability view
TABLE 3. TEXTUAL SPECIFICATION OF THE MOBIE REFERENCE MODEL 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
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.
I. System interoperability view Like the business/operational interoperability view, the system interoperability view is derived from and elaborates on the same reference model. Fig. 8 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 Interaction B1, which are operations of System A and System B, respectively. Service A and Service B, the two front-end
services to the beneficiary 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.
Fig. 5. Reference pattern of the system interoperability view
J. System interconnectivity view The system interconnectivity view is also derived from the reference model. The OPD in Fig. 9 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 at too high a level for this view and are therefore 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 system stakeholders. The emerging AB Interconnectivity allows for functional interaction between the constituent systems themselves, as shown in Fig. 9.
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 [33]. Medical interoperability allows for medical information sharing, blood sample and donation management, organ transplantation management, etc.
Fig. 6. Reference pattern of system interconnectivity view
III. INTEROPERABILITY IN DEPARTING PASSENGER ROUTING 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 [42]. These aviation systems involve a plethora of disciplines, including economics, civil engineering, aerospace engineering, management science, information systems, security, safety, survivability, and operational continuity [43]. The Federal Aviation Administration (FAA)’s Next Generation Air Transportation System (NextGen) program is an interconnected, interdependent SoS, challenging common modeling and analysis techniques [44], [45]. The aerospace domain clearly manifests the three levels of interoperability. Global air travel is made possible due to large-scale 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 [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, loosely-coordinated 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 as an interoperable engagement. Fig. 10 shows the topmost business/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 self-
descriptive process name preamble words Interoperability and Interoperable are optional and mostly used for additional emphasis.
Fig. 7. Interoperability-empowered airport operations – business/operational interoperability view
In addition to the high-level interoperable story and engagements, this view includes the Airport as the I-Domain, the involved agents, both airport-related and external ones, and eight onputs, including Passenger, Baggage, Airplane, and Information associated with each onput. Due to the complexity of the topmost view, in what follows we focus on terminal services, expressed as the Interoperable Terminal Service Operation Engagement – an operation within Airport. We unfold it in Fig. 11 to another lower level
business/operational interoperability view, which shows the relevant agents, onputs, and two core constituent Functional Interactions – Passenger Departure and Passenger Arrival.
Fig. 8. Interoperable terminal service operation – business/operational interoperability view
Examining Fig. 11, we focus on the Passenger Departure process and derive a system interoperability view for this specific interaction. In Fig. 12 we present the system 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. 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 attributed to any specific agent or party. The reason for the preceding higherlevel OPDs in Fig. 10 and Fig. 11 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. 13. 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.
Fig. 9. Passenger departure – system interoperability view
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 fine-grained each constituent system services and operations. 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. There are eight subprocesses from five constituent system services, which are organized in a logical and sequential business process: Passenger Check-in, Baggage Check-in, Passenger Security Clearance, Passenger Immigration Clearance, Baggage Security Clearance, Baggage Routing, Baggage Loading, and Passenger Boarding.
Fig. 10. Passenger departure process in-zoomed
Integrating the processes that Passenger and Baggage undergo separately is critical for two reasons. First, this integration captures the end-to-end process from the Passenger entering the terminal till Passenger Boarding – the pivotal experience around which the entire terminal operation is designed. Second, the integration enables regulation and policy compliance verification, such as passenger-baggage co-boarding 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.
IV. MOBIE WITH UML OR SYSML 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 as an actor has many limitations on that system’s modeling. 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 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 show onput in text tags on (possibly directed) links denoting interfaces or channels. Relying on this legacy notation, the SysML 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 [47]. 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 just a starting point for successful integration; defining, supporting, facilitating, and delivering business-level end-toend 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 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. We have demonstrated the applicability of MoBIE in airport operations, focusing on passenger departure. Insights from this approach have been implemented in at least one newly designed airport. Interoperability in the aerospace domain goes way beyond data sharing between airspace control units and airlines; it is about 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. This universal nature may be perceived as a limitation, and future research should therefore focus on bringing 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 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], [48] may guide this direction.
ACKNOWLEDGMENT We thank the Gordon Center for Systems Engineering at the Technion – Israel Institute of Technology, for supporting this research.
ACRONYM GLOSSARY AF
Architecture Framework
DM2
DoDAF Meta-Model
I5
Interoperability, Interaction, Interconnectivity, Interfacing, and Integration
MBSE
Model-Based Systems Engineering
MoBIE
Model-Based Interoperability Engineering
OPD
Object-Process Diagram
OPL
Object-Process Language
OPM
Object-Process Methodology
SoS
System-of-systems
SysML
Systems Modeling Language
UML
Unified Modeling Language
REFERENCES
[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]
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.
[4]
F. B. Vernadat, “Interoperable enterprise systems: Principles, concepts, and methods,” Annu. Rev. Control, vol. 31, no. 1, pp. 137–145, Jan. 2007.
[5]
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.
[6]
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.
[7]
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.
[8]
R. Brooks and A. P. Sage, “System of systems integration and test,” Information, Knowledge, Syst. Manag., vol. 5, pp. 261–280, 2006.
[9]
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.
[10]
B. Boehm, “Some future trends and implications for systems and software engineering processes,” Syst. Eng., vol. 9, no. 1, pp. 1–19, 2006.
[11]
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.
[12]
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.
[13]
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.
[14]
H. Panetto, R. Jardim-Goncalves, and A. Molina, “Enterprise Integration and Networking: Theory and practice,” Annu. Rev. Control, Oct. 2012.
[15]
M. J. DiMario, “System of systems interoperability types and characteristics in joint command and control,” in 2006 IEEE/SMC International Conference on System of Systems Engineering, 2006, no. April, pp. 236–241.
[16]
C4ISR Architecture Working Group, “Levels of information systems interoperability (LISI),” 1998.
[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 cyber-physical systems,” ACM SIGBED Rev., vol. 5, no. 1, pp. 1–2, Jan. 2008.
[23]
E. a. Lee, “Cyber Physical Systems: Design Challenges,” 2008 11th IEEE Int. Symp. Object Component-Oriented Real-Time Distrib. Comput., pp. 363–369, May 2008.
[24]
M. Auguston and C. Whitcomb, “Behavior Models and Composition for Software and System s Architecture,” in ICSSEA-2012, 24th International Conf. on Software & Systems Engineering, 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 - SMC2005, 2005, vol. 4, pp. 3244–3251.
[26]
DoD, “DoD Architecture Framework Version 2.02,” 2009.
[27]
H. Jørgensen, T. Liland, and S. Skogvold, “Aligning TOGAF and NAF-Experiences 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, 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, Object-Process Methodology: A Holistic Systems Approach. Berlin, Heidelberg, New York: Springer, 2002.
[32]
ISO/TC 184, “ISO/PDPAS 19450 Automation systems and integration — Object-Process Methodology,” no. 20. ISO, 2014.
[33]
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.
[34]
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.
[35]
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.
[36]
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.
[37]
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.
[38]
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.
[39]
E. Grönlund, “A Holistic Socioecological Systems Approach at the Regional Level – The EMPI (EMMI),” in Proceedings of the 55th Annual Meeting of the ISSS, 2011, vol. 55, no. 1, pp. 1–10.
[40]
E. Crawley, O. De-Weck, S. Eppinger, C. Magee, J. Moses, W. Seering, J. Schindall, D. Wallace, and D. Whitney, “Engineering Systems Monograph,” 2004.
[41]
J. E. Kasser, “Seven systems engineering myths and the corresponding realities,” pp. 1–13, 2010.
[42]
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.
[43]
N. J. Ashford, S. Mumayiz, and P. H. Wright, Airport Engineering: Planning, Design and Development of 21st Century Airports. John Wiley & Sons, 2011.
[44]
Y. Haimes, “Systems-based guiding principles for risk modeling, planning, assessment, management, and communication.,” Risk Anal., vol. 32, no. 9, pp. 1451–67, Sep. 2012.
[45]
M. R. Blackburn and A. Pyster, “Modeling and Analysis Framework for Risk - Informed Decision Making for FAA NextGen,” in INCOSE International Symposium, 2013.
[46]
M. Rohatgi and G. Friedman, “A structured approach for assessing & analyzing technical & nontechnical interoperability in socio-technical systems,” in 2010 IEEE International Systems Conference, 2010, pp. 581–586.
[47]
D. Harel and M. Politi, Modeling reactive systems with statecharts: the STATEMATE approach. McGraw-Hill, Inc., 1998.
[48]
T. Ford, “A Survey on Interoperability Measurement,” in ICCRTS 2007, 12th International Command and Control Research and Technology Symposium, 2007, no. 937.
Yaniv Mordecai is a Ph.D. candidate in systems engineering at the Technion – Israel Institute of Technology, Haifa, Israel. He holds M.Sc. (2010, cum laude) and B.Sc. (2002) degrees in industrial engineering from TelAviv University, Tel-Aviv, Israel. His research interests include cybernetics, model-based systems engineering, risk analysis, decision analysis, interoperable systems, and operations research. He is a proficient and active systems engineer, with expertise in aerospace and defense, information technology, command and control, and avionics systems. He has authored more than 10 refereed publications including 6 IEEE conf. papers, and won more than 10 awards, including best paper award at an IEEE CS international conference in Israel (2014), and 2 IEEE SMC student travel grants (2013 and 2014). He has reviewed manuscripts for the IEEE Transactions on Systems, Man, and Cybernetics journal, INCOSE Systems Engineering journal, and Springer. Dr. Ori Orhof is a Ph.D. graduate in information management engineering at the Technion – Israel Institute of Technology, Haifa, Israel. He holds M.Sc. (1996) and B.Sc. (1993) degrees in industrial engineering & management from the Technion. His research interests include program and project management, project classification and evaluation, project-product integration, and aerospace applications. He is a proficient project and program manager in large-scale technological, security and operational projects, with special expertise in airports and terminals ground operations. Dr. Dov Dori (SM’99) is the Harry Lebensfeld Chair of Industrial Engineering and Head of the Enterprise System Modeling Laboratory at the Faculty of Industrial Engineering and Management, Technion – Israel Institute of Technology, Haifa, Israel. He 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. His research interests include model-based systems engineering, conceptual modeling of complex systems, systems architecture and design, software and systems engineering, and systems biology. He is alternately Visiting Professor with the Engineering Systems Division, Massachusetts Institute of Technology, Cambridge, MA, USA. He invented and developed object–process methodology, the ISO 19450 Standard. He has authored, co-authored or edited five books and over 200 journal, conference publications and book chapters.
