Agile Modeling of an Evolving Ballistic Missile Defense System with Object-Process Methodology

Yaniv Mordecai Faculty of Industrial Engineering and Management

Technion – Israel Institute of Technology Haifa, Israel

yanivmor@technion.ac.il

Dov Dori Engineering Systems Division

Massachusetts Institute of Technology Cambridge MA, USA;

Faculty of Industrial Engineering and Management Technion – Israel Institute of Technology

Haifa, Israel dori@mit.edu

Abstract—Evolution of requirements and systems has led to the proliferation of agile development as a matter of course in the current technological landscape. The rate of change poses a significant dilemma to stakeholders regarding the amount of effort and resources they should invest in methodological practices, including modeling, design, analysis, and specification. The attempt to move quickly from concept to operation often leads to preference of expedience for gaining early time-to-market over quality and robustness. Rather than referring to the modeling vs. agility challenge as a dilemma, we perceive it as an opportunity for synergy. Building on Object-Process Methodology (OPM)—the new ISO-19450 standard, we propose an agile model-based systems engineering (MBSE) framework that facilitates, and fosters development agility and system evolution. This agile MBSE framework extends the traditional scope of system modeling to cover aspects of functional and structural evolution, phase transition, deployment feedback, and configuration interdependence. We demonstrate the applicability of agile MBSE on a hypothetical ballistic missile defense system, based on publicly available information on Iron Dome – an Israeli ballistic missile defense system with proven operational capability.

Keywords—Agile Model-Based Systems Engineering, Evolving System Models, Agile Development, Object-Process Methodology, Configuration Management, Ballistic Missile Defense.

I. INTRODUCTION Constant system and technology evolution is a major

challenge in the contemporary technological landscape. System evolution is motivated and amplified by increasing software flexibility, software-defined hardware adaptability, and a multitude of available technologies, vendors, and applications. This trend is prevalent in almost all domains, ranging from traditional ones like oil platforms, public transportation services and space missions to cutting edge ones, such as cloud computing, social networks, intelligent and biomedical devices, and nanotechnologies. Differences among domains stem mainly from clock speed—the frequency and magnitude of the domain change cycle.

The current governing approach to system development is evolutionary in essence, even if not considered “agile” in industry terms [1]–[3]. System evolution has become a

strategy, as roadmaps for systems, products, or services are defined and maintained by business stakeholders. System scope and specification change constantly, driving system modification, enhancement, adjustment, and modernization. Concurrent design and development of new system versions, with previous versions still in operation, deployment, adoption or retirement is a matter of course. Large-scale legacy systems experience significant leaps forward with relatively long cycles, while smaller-scale agile systems often move far away from their original starting point and initial intentions over short periods of time.

System evolution involves a host of issues, problems, and often crises, due to the increasing variability in architectural, technological, and operational aspects [4]. The simultaneous emergence and evolution of system form, function, and behavior make the tasks of system integration and verification a major effort, presenting a severe obstacle in many cases. System and component configuration management often becomes a Sisyphean, time-consuming effort. Such an effort requires tracking and controlling component versions and cross-version compliance via system baselines for gradual realization, testing, and deployment [5]. NASA’s four baseline points – “functional”, “allocated”, “product”, and “as-deployed” [6] – respectively align with the primary phases in the system or mission lifecycle – requirement specification, design, implementation, and deployment (see Fig. 1).

Even well-organized, complete, and reliable models and design documents often become outdated or unsynchronized as the systems they specify undergo significant modifications and frequent updates. As a result, configuration management, rationalization, and cross-functional impact tracking is becoming increasingly more difficult, making the investment in design and configuration management seem less valuable. Specification and configuration quality deterioration turns into a vicious circle. Gradual configuration buildup is wrongly perceived as resulting from resource and contract constraints rather than a desired and planned maturation. This is an unintended consequence of the traditional waterfall approach, which assumes that a fully functional system can be delivered within one long, predetermined development cycle. While

nowadays this is deemed impossible and wrong both technologically and business-wise, many large scale programs still operate with this paradigm as an underlying philosophy.

Fig. 1. The NASA Systems Engineering Configuration Management and Baseline Evolution Approach [6]

Common modeling languages, such as UML [7] and SysML [8], and architecture frameworks, such as the US Department of Defense Architecture Framework (DoDAF) [9], [10] NATO Architecture Framework (NAF) [11], [12], and the Unified Profile for DoDAF and MoDAF (UK Ministry of Defense Architecture Framework) [13] are not designed for agile, evolutionary system lifecycles. They lack the capability to accommodate system evolution in both their programmatic and product layers [14], [15].

Given this current state of affairs, we suggest a different approach—agile MBSE—to streamlining systems evolution and maturation that unifies the system's functional requirements specification and evolutionary dimensions within a single, overarching, holistic model. The agile MBSE model enables formal, interoperable definition, architecting, design, development, documentation, and maintenance of the system and its configuration. We study a hypothetical ballistic missile defense system (BMDS), whose specification consists of published information on Iron Dome – an Israeli BMDS with proven capability. Iron Dome itself is briefly described in Section II. The basis for this agile MBSE model is Object-Process Methodology – OPM [16], a holistic conceptual modeling paradigm, approved as ISO standard 19450 [17], briefly reviewed in Section III. Section IV introduces our framework for integrating system evolution into the nominal model. In Section V we model the evolution of our hypothetical BMDS as a case in point, and Section VI summarizes the paper.

II. THE IRON DOME BALLISTIC MISSILE DEFENSE SYSTEM The Iron Dome is a genuine ballistic missile defense system

(BMDS) manufactured by RAFAEL Advanced Defense Systems. It was developed as a defensive weapon against the

increasing ballistic missile threat on Israeli cities by terrorist organizations in Lebanon and Gaza. Iron Dome intercepts short range rockets and 155 mm artillery shells with ranges of up to 70 km [18]. Iron Dome is operated by the Israeli Air Force since 2011 and has shot down more than 1200 rockets launched from Gaza to civilian concentrations in Israel, mostly during operations Pillar of Defense (2012) and Protective Edge (2014) [19]. Iron Dome consists of (i) A radar that detects and tracks threatening ballistic objects, (ii) a command and control center (CCC), responsible for planning successful defense plans, monitoring Iron Dome’s sensors, actuators, and resources, overseeing the defense mission, and collecting data for debriefing and analysis, (iii) an array of launchers scattered in the vicinity of the CCC and radar, armed with Tamir interceptors; and (iv) the Tamir interceptor, which eventually targets, hits, and destroys ballistic missiles in midair.

Fig. 2. Iron Dome – an Israeli ballistic missile defense system – laucher ejects a Tamir interceptor to shoot down a detected threatening rocket.

The nominal scenario begins with a ballistic missile launched by the enemy, and shortly thereafter detected by the radar. The radar then starts tracking the object and reporting its position, velocity, and acceleration to the CCC. The CCC calculates an interception plan and notifies the designated launcher(s) to launch the interceptor(s) at the designated times. Once the launcher ejects an interceptor, the interceptor maneuvers towards the ballistic missile, tries to acquire it—detect it with its own sensors and follow it directly—and aims to hit it head-on. The interceptor receives information from the radar and CCC and uses it to improve its course. The CCC continuously provides a high-level visualization of the battle to the battery commander and control officers.

III. OBJECT PROCESS METHODOLOGY (OPM) OPM is a leading holistic conceptual modeling

methodology for architecting, design, and analysis of complex systems, products, services, and processes [16], [21]. OPM models capture structure, function, and behavior within the same unified static-dynamic view at various levels of detail [22]. This unification has proven to alleviate system complexity and simplify its management [23]. OPM is bimodal: both graphical and textual. Each model notion captured visually in an OPM diagram (OPD) is accompanied by a formal textual description in Object-Process Language (OPL), a subset of English. OPM’s modeling elements are Process (ellipse), Object

(rectangle), and state (rountangle), along with structural and procedural Links, capturing various types of relations. An OPM metamodel of objects, processes, and structural links is shown in Fig. 3. Procedural links and states are shown in Fig. 4. The OPL sentences were embedded in the diagram next to their respective visualizations.

OPDs are uniform, self-similar, hierarchically-organized, and interdependent. An OPD can be extended to lower level OPDs through (i) unfolding, (ii) in-zooming, and (iii) view derivation. Unfolding caters to hierarchical breakdown and elaboration of structure and function. In-zooming is used for procedural and behavioral elaboration of processes into ordered subprocesses or for discovering the internal processes and sub-objects of black-box objects. View derivation highlights or elaborates interesting or important aspects around pivotal model elements, such as end-to-end state transitions. All OPDs in the model are cross-validated, associated, integrated, and consistent with the rest.

Fig. 3. OPM Notation (a) – Objects, Processes, and Structural Relations

Fig. 4. OPM Notation (b) – Procedural Relations and State Dynamics

OPM’s freely available CASE tool, OPCAT [24] provides a modeling and model management GUI, auto-generates formal textual specifications in response to graphical model editing, and simulates models by executing them for behavior validation and verification. OPM has been adopted by various complex socio-technical system development programs in aerospace and defense, information systems, medicine, biochemistry, and space exploration. In addition, OPM has been shown to accommodate various model-based aspects, such as standards authoring [25], project management [15], [26], requirements engineering [27], risk analysis [28], and decision making [29].

OPM is a viable alternative to wearisome text-based systems specifying. It provided integrity and consistency, and mitigates costly deficiencies discovered through field trial and error. OPM also challenges multi-diagram, multi-symbol languages by capturing the three major system aspects—

structure, behavior, and function—using a minimal universal ontology of stateful objects and processes that transform them, organized in a set of diagrams of a single kind.

IV. AGILE MBSE WITH OPM Our Agile MBSE approach consists of the notion that the

system and the model evolve concurrently, such that the model is aligned with the system or the system-to-be at all times. Evolving System Model (ESM), a key concept describing the modeling pattern introduced in this paper, is an intentionally ambiguous phrase, as the process Evolving can refer to both System and Model. As we show next, OPM, our underlying conceptual modeling framework, caters to system evolution, evolutionary modeling, and, consequently, for evolving systems engineering.

We clarify our approach by first presenting a simple modeling pattern in Fig. 5. We define System as comprising several Subsystems. System has some high-level emergent Functionality. Functionality is abstract and emergent, while its constituent Functions are actual operations of the Subsystems. Unlike Functionality, which relates to the functional system aspect, Scenario relates to the behavioral aspect: It is a set of Functions, aimed at accomplishing some goal or objective, and can encompass several systems and users. The distinction between Functionality and Scenario provides for modeling two system aspects—the functional and the procedural—to coexist within the same model. This way, we can model emergence—emergent traits of a system as its functionality—a specific combination of ordered functions whose value to some beneficiary is greater than the sum of the values of the individual functions.

Fig. 5. Basic System Design Pattern: System consists of several subsystems; System exhibits Functioality; Scenario and Functionality consist of several Functions, exhibited by Subsystems. Function receives Input, uses a Resource Set, and generates Output.

The Functionality-Scenario distinction allows for modeling both the functional decomposition of the system and the procedural buildup of added value within the same unified model. Preliminary modeling and design can leverage this approach by defining Functionalities and Functions without assigning them to specific Subsystems or components, and defining Scenarios based on Functions without necessarily referring to them collectively as Functionalities. This enables modeling based on functional requirements—which are mostly technical—and procedural requirements—which are mostly operational—in a unified ESM.

The above pattern is useful for early system definition and conceptualization. However, applying this pattern to existing complex systems or ongoing system development programs involves complications and ambiguities. In order to streamline the transition to working with the ESM pattern, we add an evolution layer, as shown in Fig. 6. This layer consists of: a) Subsystem Variants, B) Function Variants, and C) Scenario Variants. Functionalities and Functions are defined at the conceptual system level in an intentionally evolution-indifferent manner. Function Variants are the actual manifestations of the conceptual Functions, and are assigned (often at a later stage) to Subsystem Variants. Scenario Variants are the manifestations of conceptual Scenarios, and they consist of Activities that consist in turn of Function Variants.

Fig. 6. Evolving System Model Pattern: Scenario, Subsystem, Function, Input, Output and Resource Set all have Variants as specilizations.

Using this pattern, several variants of the same subsystem can be defined in the same model, and functions can be assigned to these variants. Multiple Function Variants may be available under a single deployment as part of a Baseline, – a situation called overloading, or functional polymorphism. Function Variants are reusable: Activities, the building blocks of procedural Scenario Variants, consist of these Function Variants in multiple scenarios. Scenario Variants are the manifestations of the way Scenarios evolve over time, due to Functionality additions and requirement changes.

The modeling pattern’s final extension includes of Input Variants, Output Variants, and Resource Set Variants. Input and Output may evolve as Functions evolve, although it is a good practice to avoid extreme interface changes. Resource Sets, required for Activity or Function to occur, can also evolve, though this happens less often. Input Variant and Output Variant management is especially important for business-level or system-to-system interfaces and interactions. Input and output formats evolve over time to accommodate changes to baseline requirements. For example, the same input message can have several versions to support input from several resources while keeping the enveloping structure and name of the input unit. This practice is known as object polymorphism.

Polymorphism is a common design practice even for non-evolutionary needs, but it becomes a critical principle to employ when evolutionary conditions set in. Thus, our pattern supports both polymorphic object and process structure design as well as adoption of this approach to cope with systemic or environmental evolution. The model supports the definition of an abstract, variant-indifferent layer and of the decomposition of abstract objects and process to their actually-used variants. Thus, the same models can have one function to represent all of its variants and service all internal and external users, while function variants are mapped to and used by specific users. A complete formal and auto-generated OPL textual specification of the finalize ESM pattern appears in Fig. 7. The text is compact, plain, and easily understandable by both experienced and unexperienced readers, users, and reviewers.

ID Statement

1000 System exhibits many Baselines and many Functionalities.1100 Baseline relates to many Subsystem Variants.1200 Functionality consists of many Functions.2000 System consists of many Subsystems.2100 Subsystem exhibits many Functions.2110 Function requires Resource Set.2120 Function consumes Input.2130 Function yields Output.3000 Input Variant is an Input.4000 Output Variant is an Output.5000 Resource Set Variant is a Resource Set.6000 Subsystem Variant is a Subsystem.7000 Subsystem Variant exhibits many Function Variants.7100 Function Variant is Function.7200 Function Variant requires Resource Set Variant.7300 Function Variant consumes Input Variant.7400 Function Variant yields Output Variant.8000 Scenario consists of many Functions.9000 Scenario Variant is Scenario.

10000 Scenario Variant zooms into many Activities.10100 Activity is instance of Function Variant.

Fig. 7. Evolving System Model Pattern: Formal textual OPL specification corresponding to the OPD in Fig. 6.

The generic ESM pattern introduced here provides a single notation for both the abstract pattern and the actual model. Thus, the pattern can be easily instantiated as an actual model of the system of interest, without any notational transformation. In addition, similar artifacts such as subsystems, functionalities, scenarios, and their internal parts can be easily added. Once the model is defined according to this evolvable pattern, it can be easily extended to include additional variants. System engineers need not capture multiple variants without adequate built-in configuration control. Rather than avoiding variant representation and adhering to the nominal model, this pattern allows them to conveniently represent variability while preserving model consistency.

The gradual exposure of the ESM pattern and its extensions is intentional: it resembles and demonstrates actual system

model construction and extension to accommodate system evolution. It also shows OPM’s capability to cater to model evolution and maturation in conjunction with system design and architecture evolution, which is a key component in agile MBSE. The capability of this modeling framework to capture variations and modifications to an existing design reinforces the conceptual model’s viability and value as a systems engineering tool. This modeling capability is powerful as it can work equally well in slowly- and quickly-evolving systems alike. Moreover, it complements and facilitates agile system development by providing a clear visual representation of the conceptual and actual specification and design of the solution, as well as the relations to and discrepancies ("deltas") of the current system as expressed by its model.

V. AGILE MBSE: A BMDS EXAMPLE In this section we demonstrate the use of ESM as part of the

agile MBSE approach on a BMDS with evolutionary characteristics. Our BMDS is a hypothetical one, but our specification is loosely based on publicly available information about Iron Dome. The various reports suggest that Iron Dome has allegedly gone through tremendous upgrades to enable interception of emerging threats, extended target ranges, reduced interceptor consumption, improved salvo handling, integration with other BMDSs, UAV interception, etc. [20]. However, this paper has no intention to claim or argue that our hypothetical system reflects the way the real Iron Dome system functions. Our BMDS has evolved significantly since its initial conception, through its design stages, testing, and operation. We analyze both types of evolution: new functionality, and variant functionality. The different forms of evolution are represented in the model.

Fig. 8. Structural-functional top-level view of a BMDS.

We first define a preliminary high-level structure of the system and its primary functionalities, based on the nominal scenario description. Fig. 8 is a high level structural-functional model view of the Ballistic Missile Defense System (BMDS), showing the four primary subsystems—Radar, CCC, Launcher, and Interceptor. The core functionality of Ballistic Missile Defense System is Ballistic Missile Defense. Each subsystem has 1~3 functionalities, which also comprise the emergent functionality of the system.

To complement this structural-functional view, we add a procedural view showing the Nominal Scenario, including the Ballistic Missile Launching and Flight, Defense Planning Activity based on the functionality of the BMDS, The Interception Activity of Interceptor, and the successful Ballistic Missile Destruction, which consumes both the Ballistic Missile and the Interceptor. This view is illustrated in Fig. 9.

Fig. 9. Top-level view of the nominal scenario, including one ballistic missile, one interceptor, and a ballistic missile defense activity consisting of the ballistic missile defense functionality and its constituent functions.

This naïve simplified model assumes that every ballistic missile is detected by the system and then intercepted. However, as published, in order to save interceptors and avoid an economic attrition war, BMDSs only intercept ballistic missiles if they are going to hit a defended area and are within feasible interception conditions. Therefore, the first modification includes additional functionality to support the Defended Area Management, as well as Defended Area Hitting Probability Assessment. This addition is illustrated in Fig. 10. In Fig. 11. The assessment function becomes part of Defense Planning in the Nominal Scenario. The results of Detection and Hit Probability Assessment either enable the flow of the process or restart it. Defended Area Management is not part of the nominal scenario, but rather part of a separate BMDS Preparation scenario, which includes the deployment of the system’s components, connecting them, and performing a set of preparation activities, some of which are supported by system functions. That scenario, however, is beyond the scope of this paper.

The Interception Planning function modification covers the infeasible Interception option, in which case Defense Planning restarts as well, while feasible planning triggers Intercepting as shown in Fig. 11. The earlier version, which did not include these modifications in the assessment and interception planning processes, could be typical to very early test-range-only proof of concept—an early system version. At a later stage, however, it would be mandatory to include these capabilities in order for the BMDS to be both safe and beneficial to operate.

Based on publications on speculated or actual UAV interception capability, we demonstrate how this additional functionality and its constituent functions would be variants of their nominal ballistic missile defense ancestors. This makes sense, because the system is expected to be indifferent to the

kind of threat it detects—missile or UAV—and at the same time identify it, assess it, and plan its interception accordingly. Thus, UAV Scenario is a variant of the nominal scenario, while UAV Defense Planning is a variant of the nominal Defense Planning. The internal activities consist of variants of the BMDS functions. This modeling approach enables the encapsulation of the variant UAV Scenario within the Nominal Scenario, and the derivation of the relevant variants in both the procedural aspect and the functional aspect. The UAV scenario-functionality dual variant is illustrated in Fig. 12.

Fig. 10. Structural-functional top-level view of a BMDS, including additional functionality to manage defended areas and calculate the ballistic missile’s hitting probability in one of these areas.

Fig. 11. In-zoomed Defense Planning view, inc. Tracking, Hit. Prob. Assessment, and Interception Planning. The planning activity recurs in case of low Hit Prob or low Interception Feasibility. Detection invokes planning but does not recur with it. Each activity is shown to consist of a function of one of the subsystems, which is also part of the system-level functionality Ballistic Missile Defense.

The variant UAV Defense functionality is now unfolded in a dedicated diagram, defining its constituent functions. The baseline constituent functions of Ballistic Missile Defense functionality are selectively adopted as they are, replaced by

corresponding function variants, or removed altogether if they are irrelevant. Additional functions are added wherever necessary. An unfolded view of UAV Defense appears in Fig. 13.

Fig. 12. View of nomianal scenario and functionality of BMDS, extended to corresponding UAV scenario and functionality.

Fig. 13. Unfolded UAV functionality view, including constituent baseline functions, function variants, and additional functions, both systemic and environmental.

The UAV Defense functionality differs from the basic Ballistic Missile Defense functionality in several ways. First, the detection and tracking of enemy aircraft and UAVs are made by external radar systems that are optimized for aircraft kinematics. A central external subsystem, Air Defense Command, is responsible

for providing the detection and tracking services. Thus, the Radar subsystem becomes irrelevant for the UAV Defense functionality and UAV scenario. Specialized UAV Damage Assessment and UAV Interception Planning functions for UAVs replace the original ones used for Ballistic Missile. In addition, aircraft interception mandates approval request from Air Defense Command, while ballistic missile interception does not require such approvals. Hence, an Air Defense Approval Requesting function is also added. Finally, the UAV’s physical interception requires the interceptor to carry out aerodynamic maneuvers that are different from the ones needed for ballistic missile interception. Hence, a function variant of Intercepting – UAV Intercepting, has been added.

Zooming into the UAV Scenario in Fig. 14, we define activities and activity variants utilizing the constituent functions comprising the UAV Defense functionality. Since this is a scenario variant, some of its constituent activities are variants as well. Environmental activities that occur as part of the scenario are not defined as variants, because they are not a part of the system. However, if, for example, we want to emphasize that an external activity, which is performed by an external system, is a variant of the other system, it can be captured in the model as well. Such a distinction might not even impact the system-of-interest. In this model we see that the UAV takeoff and UAV flight are similar to the Ballistic Missile launching and Ballistic Missile flight, but this does not mean that they are variants. UAV Engaging, on the other hand, can be a variant of another function. If, for example, the Air Defense Command already implements a similar scenario with another defense system, parts of that scenario could be reused for the BMDS. BMDS designers may prefer to omit this detail if they don’t see it as informative or relevant to the BMDS.

Fig. 14. In-zoomed UAV Scenario view, including baseline activities, activity variants, and additional, environmental activities.

In this section we have shown how the ESM pattern, a central component of our evolving agile MBSE approach, is applied to the evolving BMDS model. We began with a model of a nominal system for ballistic missile interception, and gradually extended it to also cover a) selective ballistic missile engagement based on area defense policy, and b) UAV

interception. We adjusted the model in both the functional and procedural aspects by defining functionality and function variants for the former, and scenario and activity aspects for the latter. In the end of this evolution cycle, the baseline ballistic missile defense scenario and the emerging UAV defense scenario are both operational, as are their corresponding functional building blocks.

VI. SUMMARY We propose a fresh approach to agile model-based systems

engineering (MBSE) that integrates the evolutionary dimension as part of the core system model. This time- and version-aware framework supports rich, informative, valuable, and usable evolvable system model (ESM) creation and management by gradually constructing a configuration layer on top of a nominal system model. In preparation for extending the system model, we formalize the distinction between the functional and procedural model aspects and provide a supporting modeling pattern. While this distinction may not be mandatory for configuration buildup, formulating the ESM with this distinction enhances the evolutionary model aspects of form and function.

We have demonstrated the applicability of this modeling pattern on a hypothetical, simplified ballistic missile defense system, based on publicly available information about the Israeli Iron Dome. In our example, the operational capability is extended to allow the interception of unmanned air vehicles (UAV). We show that UAV-oriented functional and procedural views are derived from their nominal model counterparts, such that the resulting model reflects an integrated defense system that performs both missions interchangeably.

Agility and evolution on the one hand, and formal modeling and design on the other, are not conflicting objectives or paradigms. Conversely, they reinforce each other when the system is modeled in an evolvable manner, using our ESM pattern, based on Object-Process Methodology as the underlying conceptual modeling framework. One can view this modeling pattern as a variant of nominal OPM modeling, adjusted for the ESM scenario. Further extension and elaboration include ESM simulation and behavior mapping, which increase the reliability, consistency, and verifiability of the model and its realization.

ACKNOWLEDGMENT This research was supported by Israel Aerospace Industries

– IAI as part of academic collaboration with the Technion – Israel Institute of Technology. The authors would like to thank the SysCon 2015 referees for their useful feedback.

REFERENCES [1] D. E. B. Ii, “The Agile Enterprise�: Systems Engineering

Agility at the Enterprise Level,” 2013. [2] S. Anderson and R. Dove, “Aircraft Agile Integration-Design

for Quick Reaction Capability Programs,” in INCOSE Internaional Symposium, 2013.

[3] R. S. Carson, “Can Systems Engineering be Agile? Development Lifecycles for Systems, Hardware, and Software,” in INCOSE Internaional Symposium, 2013.

[4] I. Sommerville and G. Dean, “PCL: a language for modelling evolving system architectures,” Softw. Eng. J., no. March, pp. 111–121, 1996.

[5] INCOSE, Systems Engineering Handbook, V. 3.2.2. INCOSE, 2011.

[6] NASA, Systems engineering handbook. 2007. [7] L. Favre, UML and the Unified Process. IRM Press, 2003. [8] OMG, OMG Systems Modeling Language (OMG SysML)

Version 1.3, no. 1.3. 2012. [9] M. Hause and L.-O. Kihlström, “Architecting in the Fourth

Dimension Temporal Aspects of DoDAF,” in INCOSE Internaional Symposium, 2013.

[10] 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.

[11] 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.

[12] A. Wrzosk, “Applying NAF for performance analysis: Performance analysis of SOA systems using LQN models,” in Military Communications and Information Systems Conference (MCC), 2012, pp. 1–8.

[13] 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.

[14] A. Sharon, “A Unified Product and Project Lifecycle Model for Systems Engineering,” Technion - Israel Institute of Technology, 2010.

[15] A. Sharon, O. L. De-Weck, and D. Dori, “Improving Project-Product Lifecycle Management with Model-Based Design Structure Matrix�: A Joint Project Management and Systems Engineering Approach,” Syst. Eng., vol. 16, no. 4, pp. 413–426, 2013.

[16] D. Dori, Object-Process Methodology: A Holistic Systems Approach. Berlin, Heidelberg, New York: Springer, 2002.

[17] ISO/TC 184, “ISO/PDPAS 19450 Automation systems and integration — Object-Process Methodology,” no. 20. ISO, 2014.

[18] RAFAEL, “Iron Dome Fact Sheet.” [Online]. Available: http://www.rafael.co.il/marketing/SIP_STORAGE/FILES/6/946.pdf. [Accessed: 31-Jan-2015].

[19] B. Opall-Rome, “Israel Fortifies Iron Dome for Future War,” Defense News, 08-Nov-2014.

[20] “Iron Dome,” Wikipedia - The Free Encyclopedia. 2015. [21] J. Estefan, “Survey of model-based systems engineering

(MBSE) methodologies,” 2007. [22] D. Dori, “Object-Process Methodology for Structure-Behavior

Codesign,” in Handbook of Conceptual Modeling, D. W. Embley and B. Thalheim, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 209–258.

[23] D. Dori, I. Reinhartz-berger, and A. Sturm, “Developing Complex Systems with Object-Process Methodology Using OPCAT,” in Lecture Notes in Computer Science: 22nd International Conference on Conceptual Modeling - ER2003, 2003, vol. 2813, pp. 570–572.

[24] 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.

[25] A. Blekhman, D. Dori, and R. Martin, “Model-Based Standards Authoring,” in INCOSE International Symposium, 2011.

[26] A. Sharon, O. L. De Weck, and D. Dori, “Project management vs. systems engineering management: A practitioners’ view on integrating the project and product domains,” Syst. Eng., vol. 14, no. 4, pp. 427–440, 2011.

[27] A. Blekhman and D. Dori, “Tesperanto – A Model-Based System Specification Methodology and Language,” in INCOSE International Symposium, 2013.

[28] 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.

[29] Y. Mordecai and D. Dori, “Conceptual Modeling of System-Based Decision-Making,” in INCOSE Internaional Symposium, 2014.