Agile Modeling of an Evolving Ballistic Missile Defense System with

Agile Modeling of an Evolving Ballistic Missile
Defense System with Object-Process Methodology
Yaniv Mordecai
Dov Dori
Faculty of Industrial Engineering and Management
Technion – Israel Institute of Technology
Haifa, Israel
yanivmor@technion.ac.il
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 “asdeployed” [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.
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. 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 ObjectProcess 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
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 subobjects 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
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. 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—
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.
Polymorphism is a common design practice even for nonevolutionary 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
1000
1100
1200
2000
2100
2110
2120
2130
3000
4000
5000
6000
7000
Fig. 6. Evolving System Model Pattern: Scenario, Subsystem, Function, Input,
Output and Resource Set all have Variants as specilizations.
7100
7200
7300
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.
7400
8000
9000
10000
10100
Statement
System exhibits many Baselines and many Functionalities.
Baseline relates to many Subsystem Variants.
Functionality consists of many Functions.
System consists of many Subsystems.
Subsystem exhibits many Functions.
Function requires Resource Set.
Function consumes Input.
Function yields Output.
Input Variant is an Input.
Output Variant is an Output.
Resource Set Variant is a Resource Set.
Subsystem Variant is a Subsystem.
Subsystem Variant exhibits many Function Variants.
Function Variant is Function.
Function Variant requires Resource Set Variant.
Function Variant consumes Input Variant.
Function Variant yields Output Variant.
Scenario consists of many Functions.
Scenario Variant is Scenario.
Scenario Variant zooms into many Activities.
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.
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.
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.
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.
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. 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
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.
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
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
[1]
[2]
D. E. B. Ii, “The Agile Enterprise : Systems Engineering
Agility at the Enterprise Level,” 2013.
S. Anderson and R. Dove, “Aircraft Agile Integration-Design
for Quick Reaction Capability Programs,” in INCOSE
Internaional Symposium, 2013.
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
R. S. Carson, “Can Systems Engineering be Agile?
Development Lifecycles for Systems, Hardware, and
Software,” in INCOSE Internaional Symposium, 2013.
I. Sommerville and G. Dean, “PCL: a language for modelling
evolving system architectures,” Softw. Eng. J., no. March, pp.
111–121, 1996.
INCOSE, Systems Engineering Handbook, V. 3.2.2. INCOSE,
2011.
NASA, Systems engineering handbook. 2007.
L. Favre, UML and the Unified Process. IRM Press, 2003.
OMG, OMG Systems Modeling Language (OMG SysML)
Version 1.3, no. 1.3. 2012.
M. Hause and L.-O. Kihlström, “Architecting in the Fourth
Dimension Temporal Aspects of DoDAF,” in INCOSE
Internaional Symposium, 2013.
B. P. Zeigler and S. Mittal, “Enhancing DoDAF with a DEVSBased System Lifecycle Development Process,” in IEEE
International Conference on Systems, Man, and Cybernetics SMC2005, 2005, vol. 4, pp. 3244–3251.
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.
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.
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.
A. Sharon, “A Unified Product and Project Lifecycle Model for
Systems Engineering,” Technion - Israel Institute of
Technology, 2010.
A. Sharon, O. L. De-Weck, and D. Dori, “Improving ProjectProduct 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.
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/94
6.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 ObjectProcess 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 SystemBased Decision-Making,” in INCOSE Internaional Symposium,
2014.