Leveraging Variability Modeling Techniques for Architecture Trade Studies and Analysis

Jessica Ryan

B.S. in Computer Engineering, May 2004, University of MD Baltimore County B.S. in Applied Mathematics, May 2004, University of MD Baltimore County

M.S. in Biomedical Engineering, May 2008, Johns Hopkins University

A Dissertation submitted to

The Faculty of The School of Engineering and Applied Science

of The George Washington University in partial satisfaction of the requirements

for the degree of Doctor of Philosophy

May 19, 2013

Dissertation directed by

Shahram Sarkani Professor of Engineering and Applied Science

ii

The School of Engineering and Applied Science of The George Washington

University certifies that Jessica Ryan has passed the Final Examination for the degree of

Doctor of Philosophy as of May 19, 2013. This is the final and approved form of the

dissertation.

Leveraging Variability Modeling Techniques for Architecture Trade Studies and Analysis

Jessica Ryan

Dissertation Research Committee:

[Shahram Sarkani, Dissertation Co-Director]

[Thomas A. Mazzuchi, Dissertation Co-Director]

[James Wasek, Committee Member]

[Lile Murphree, Committee Member]

iii

© Copyright 2013 by Jessica Ryan All rights reserved

iv

Dedication

I dedicate this body of work to my loving family, friends and mentors, whom without

this dissertation would not be possible. To my mother, who values education and has

always pushed me to achieve my goals. Without you I wouldn’t have started down the

doctoral path, nor would I have finished. To my father, with our fun experiments and

love for complicated technology, you have always taught me to take my work seriously,

but have fun on the side. To my sister Kelly, an inspiration who is the most determined

individual I know. You motivate me through our study sessions and I am humbled by

your dedication to improvements of other people’s lives. To Katie, who keeps me sane.

Thanks for all of the laughs and reminding me of the scale of what is important in life. To

Kevin, for the loving support and adventures – many more to come. Last but not least,

Taz, best study partner of all, at my feet for every last sentence.

I would also like to acknowledge Northrop Grumman Corporation for the value of

education through continuous training, financial support and opportunity for growth as

a System Engineer. My mentors, John Ferma and Carolyn Fry who have spent endless

hours teaching me the trades of architecture design and development, along with

capture of complex design decisions. Finally, Dr. Mazzuchi and Dr Sarkani for feedback

and guidance throughout the doctoral process.

v

Acknowledgement

The authors would like to thank several colleagues who have contributed this

body of knowledge. Sean McGervey, who is continuously evolving MBSE initiatives at

Northrop Grumman, inspired by issues facing current MBSE practitioners as well as

forward leaning techniques for future applications. Brad Longo assisted through custom

tool development. Sanford Friedenthal, who has helped to focus my research.

Participants in the 2009 George Washington University Systems Engineering Doctoral

Cohort, for continued support and motivation. Finally, Dr. Mazzuchi from George

Washington University who helped shape the form of my current dissertation.

vi

Abstract of Dissertation

Leveraging Variability Modeling Techniques for Architecture Trade Studies and Analysis

Model Based System Engineering (MBSE) is the formal application of models to

support System Engineering fundamentals through disciplined methodology, semantics,

standards, and tools. Increasing complexity in modern systems, as well as cost and

schedule constraints, require a new paradigm of system engineering to fulfill

stakeholder needs. A recent trend toward Model Based System Engineering (MBSE)

includes flexible architecture definition, program documentation, requirements

traceability and system engineering reuse. This paper proposes a framework for

efficient architecture definition using MBSE in conjunction with domain specific

simulation to evaluate alternatives. Variant modeling techniques are introduced as an

extension to capturing parameterized architecture options. Initial exploration applies

such variant modeling techniques to design for adaptability trade study criteria, as a

means to evaluate candidate architecture configurations against multiple requirement

sets. A framework is provided followed with a specific example including a method for

designing a trade study, defining candidate architectures, planning simulations to fulfill

requirements, and designing a weighted decision analysis to optimize system objectives.

vii

Table of Contents

Dedication ................................................................................................................iv

Acknowledgement ..................................................................................................... v

Abstract of Dissertation ............................................................................................ vi

Table of Contents .................................................................................................... vii

List of Figures ............................................................................................................. x

List of Tables ........................................................................................................... xiii

List of Abbreviations ............................................................................................... xiv

1 Introduction ...................................................................................................... 1

1.1 Statement of the Problem......................................................................... 2

1.2 Rationale and Justification ........................................................................ 3

1.3 Relevance/Importance/Motivation .......................................................... 5

1.4 Contributions to the Body of Knowledge (Significance) ........................... 7

1.5 Organization .............................................................................................. 9

2 Research Problem ........................................................................................... 10

2.1 Purpose (Goals and Objectives) .............................................................. 10

2.2 Scope and Constraints ............................................................................. 10

3 Literature overview ........................................................................................ 11

3.1 SysML as a modeling Language ............................................................... 14

3.2 Architecture Framework ......................................................................... 18

3.2.1 DoDAF ................................................................................................ 20

3.2.2 MDA ................................................................................................... 22

3.3 Methodologies ........................................................................................ 24

3.3.1 Harmony ......................................................................................... 24

3.3.2 Object-Process Methodology (OPM) ................................................ 26

3.3.3 Rational Unified Process (RUP) ................................................. 28

viii

3.3.4 Vitech ................................................................................................ 31

3.3.5 State Analysis .................................................................................... 34

3.3.6 Object Oriented Systems Engineering Methodology (OOSEM) ........ 38

3.4 Model and Simulation Interoperability ................................................... 40

3.4.1 Data Exchange Standards .................................................................. 40

3.4.1.1 MOF ....................................................................................................... 40

3.4.1.2 STEP/ AP233 .......................................................................................... 42

3.4.1.3 XMI ........................................................................................................ 44

3.4.2 Model Transformation ...................................................................... 46

3.4.2.1 OCL ........................................................................................................ 48

3.4.2.2 QVT ........................................................................................................ 49

3.4.2.3 ATL ......................................................................................................... 50

3.4.3 Execution ........................................................................................... 52

3.5 Variability Modeling Support Design for Adaptability ............................ 53

3.6 Gaps or problem areas ............................................................................ 57

4 Research Framework and Hypothesis ............................................................ 57

4.1 Conceptual Framework ........................................................................... 57

4.2 System Requirements ............................................................................. 58

4.2.1 Use Case Diagram .............................................................................. 59

4.2.2 Requirements Diagram ..................................................................... 60

4.3 Trade Study ............................................................................................. 61

4.4 Architecture ............................................................................................. 65

4.4.1 Structural Diagrams ........................................................................... 66

4.4.1.1 Package Diagram(pkg) ........................................................................... 66

4.4.1.2 Block Definition Diagram (bdd) ............................................................. 67

4.4.1.3 Internal Block Diagram (ibd) .................................................................. 68

4.4.2 Behavioral Diagrams ......................................................................... 68

ix

4.4.2.1 Sequence (seq) ...................................................................................... 69

4.4.2.1 State (stm) ............................................................................................. 69

4.4.2.2 Activity (act) .......................................................................................... 70

4.4.3 Cross-Cutting Concepts ..................................................................... 71

4.4.3.1 Allocation ............................................................................................... 71

4.4.3.2 Stereotypes ........................................................................................... 72

4.4.4 Variability Modeling Applied to Architecture Definition .................. 73

4.4.4.1 Heavyweight Extension: ........................................................................ 74

4.4.4.2 Lightweight Extension: .......................................................................... 75

4.4.5 Analyze Design Alternatives through Analysis .................................. 77

4.4.5.1 Parametric Diagrams (par) .................................................................... 78

4.4.6 Evaluation of Multiple Requirement Sets ......................................... 79

4.5 Execute & Evaluate .................................................................................. 81

5 Data Analysis and Results ............................................................................... 81

5.1 System Requirements ............................................................................. 83

5.2 Defining the Trade Study ......................................................................... 83

5.3 Architecture Definition ............................................................................ 85

5.4 Performance Analysis .............................................................................. 88

5.4.1 Dwell Time (Matlab) .......................................................................... 88

5.4.2 Cost Model (excel)............................................................................. 91

5.5 Execute & Evaluate .................................................................................. 93

5.6 Design for Adaptability: ........................................................................... 94

6 Conclusions ................................................................................................... 100

6.1 Contributions to the field ...................................................................... 101

6.2 Recommendations for Future Work ..................................................... 102

Bibliography .......................................................................................................... 103

x

List of Figures

Figure 1.1-1. Application of MBSE to Architecture Definition ......................................... 2

Figure 1.3-1: INCOSE Vision 2020 Roadmap for MBSE Capability.................................... 6

Figure 3.1-1: OMG SysML definition as a subset and extension of UML ....................... 14

Figure 3.1-2: Fundamental Pillars of SysML ................................................................... 17

Figure 3.1-3: SysML Diagram Hierarchy ......................................................................... 18

Figure 3.2-1: Evolution of the DoDAF [128] ................................................................... 21

Figure 3.2-2 Viewpoints Recommended by DoDAF [129] .............................................. 21

Figure 3.2-3: OMG's MDA extension to Platform Specific Models ................................ 23

Figure 3.3-1: Harmony Integrate Systems and Software Development Process [53] 25

Figure 3.3-2: Harmony SE Process Elements ............................................................... 26

Figure 3.3-3: OPM Entities: Object, Process, and State [31] .......................................... 28

Figure 3.3-4: The Rational Unified Process [100] ........................................................... 30

Figure 3.3-5: RUP SE Model Framework ........................................................................ 31

Figure 3.3-6: CORE System Definition Repository[17] ................................................ 33

Figure 3.3-7: Vitech MBSE Onion Model [36] ................................................................. 34

Figure 3.3-8 State Analysis: State Based Behavioral Modeling [62] .............................. 35

Figure 3.3-9: Leveraging Control Theory to Define the Lifecycle of a System ............... 36

Figure 3.3-10: State Analysis used to Execute System Engineering Execution of Mission

[67] .......................................................................................................... 37

Figure 3.3-11: OOSEM MBSE Methodology ................................................................... 39

Figure 3.4-1: Example of the 4 Layer Metamodel Hierarchy [92] .................................. 41

xi

Figure 3.4-2 STEP/AP 233 Structure Data Exchange Throughout Entire Product Lifecycle

[127] ........................................................................................................ 43

Figure 3.4-3: Scope of AP233 [116] ................................................................................ 43

Figure 3.4-4: SysML and AP233 Overlap ........................................................................ 44

Figure 3.4-5 Relationship between MOF, XML, and XMI [1] ......................................... 46

Figure 3.4-6: SysFlow Workflow Engine (SWE) [97] ...................................................... 47

Figure 3.4-7: Relationship between QVT Metamodel [90] ............................................ 50

Figure 3.4-8: ATL Transformation from Source to Target [124] ..................................... 51

Figure 4.1-1. Process Flow Guiding Application Framework of MBSE to Support

Architecture Definition ........................................................................... 58

Figure 4.4-1: SysML Profile to Diagram Example ........................................................... 66

Figure 4.4-2: CVL Base, Variation Resolved Model [49] ................................................ 75

Figure 4.4-3: Ziadi Variation Profile for UML to Support SPL [135] ............................... 75

Figure 4.4-4. DoDAF Analysis of Alternatives ................................................................. 77

Figure 4.5-1. Example Use Case for Passive BiStatic Radar ............................................ 82

Figure 5.1-1. Captured Baseline Requirements.............................................................. 83

Figure 5.2-1. Requirements Categorized as Constraints or Objectives .......................... 84

Figure 5.3-1. Block Definition Diagram of System Architecture..................................... 85

Figure 5.3-2. Defining the Trade Space .......................................................................... 86

Figure 5.3-3. Block Definition Diagram of A2D Converter Represents Structure;

Instances Represent Realization of A2D Component Through Know

COTS Parts. ............................................................................................. 87

xii

Figure 5.3-4. State Machine Show the Transition Between Dwells Per User Needs And

Data Rate Limitations ............................................................................. 88

Figure 5.4-1. Data Flow Simulation Parametric Diagram Shows Links To Requirements,

Input/ Output Ports, And Links To Component Attributes. ................... 90

Figure 5.4-2. Inventory Model Representing Components In Stock, Price, and Min Lot

Buy Requirements .................................................................................. 92

Figure 5.4-3. Example Of The Output Of The Cost Model .............................................. 93

Figure 5.5-1. Model Center Project includes Darwin Optimizer, Input Definition, Cost

Model and Dwell Rate Model ................................................................. 93

Figure 5.5-2. Output from Trade Study Analysis ............................................................ 94

Figure 5.6-1. Use Case Diagram Capturing The Extended Requirement Sets ................ 96

Figure 5.6-2. Plausible Requirements Extensions To The Baseline ................................ 97

Figure 5.6-3. Multiple Architecture Configurations Modeled as Variation from General

System Block ........................................................................................... 98

Figure 5.6-4. Lifetime Value Calculation Evaluates Multiple System Configurations

Against Multiple Requirements Sets .................................................... 100

xiii

List of Tables

Table 3.2-1:Framework vs. Focus Area [6] ........................................................... 19

xiv

List of Abbreviations

MBSE: Model Based System Engineering

INCOSE: International Council of System Engineer

OCL: Object Constraint Language

SysML: System Modeling Language

OMG: Object Management Group

UML: Unified Modeling Language

XMI: XML Metadata Interchange

QVT: Queries/Views/Transformation Language

1

1 Introduction

Model Based System Engineering (MBSE) is a transformational approach to

System Engineering which captures system architecture, relationships, requirements,

and constraints [106]. As a discipline MBSE formalizes model application, methodology,

semantics, standards, and tools as a means to support system definition for a) multiple

levels of abstraction, b) phases of product lifecycle, and c) competing stakeholder needs

[103]. This paper offers a MBSE Application Framework for architecture definition,

which extends traditional parameterized trade studies by defining a mechanism for

representing sophisticated design options through variability modeling. A reference

model described in SysML can capture variant architectures, providing a source-of-truth

model to support product line architecture and design for adaptability.

In the transformation from a baseline set of requirements to architecture

implementation within the system lifecycle various sources of design data must be

collected, transformed, and analyzed against stakeholder input. Domain specific tools

are often associated at each phase of transformation, producing specific artifacts

resulting in fragmented data, with little traceability to cross-domain analysis. MBSE

highlights the need for a central repository, relying on tool interoperability to share

information in a continuous fashion Variability modeling is used as a mechanism to

capture architecture diversity/commonality. Variability Modelling can be applied to

Product Line Architecture concept, or as a means to identify technology insertion into a

design for future requirements growth. To support requirements growth, several

2

architectures can be captured as variants and analyzed against multiple sets of

requirements, using design for adaptability as an input to the trade study decision

criteria. Figure 1.1-1 captures the MBSE Architecture Framework concepts that are

integrated and assessed throughout this thesis.

Figure 1.1-1. Application of MBSE to Architecture Definition

1.1 Statement of the Problem

Recent challenges due to system of systems integration, technological advancements,

social context shift, and distributed development requires novel interdisciplinary

techniques to realize a successful system [106]. Model Based System Engineering

practices have been evolving as a means to mitigate the fundamental increase in

system engineering complexity . Bayer et al. describe current challenges in System

Engineering at JPL: (1) Increasingly complex requirements (2) Competing stakeholder

concerns (3) Complexity due to system interaction JPL [11]. A case study from Saab

3

Aerosystems reports similar experiences, as market desires lead to a demand for faster

design realization and identification of subsystem reuse for novel integrated solutions

[5]. Influences from higher consumer expectations, economic pressure, and challenges

due to increased complexity for integration require a novel approach to System

Engineering. [73]. As a recently developed practice, MBSE is still evolving, therefore

practices are not yet consolidated in an efficient manner to maximize potential benefit.

1.2 Rationale and Justification

Model Based System Engineering complements traditional System Engineering

methodologies through modeling of system behavior, structure, requirements, and

capabilities. INCOSE defines Systems Engineering as “an interdisciplinary approach and

means to enable the realization of successful systems” [60]. Modeling of interfaces at

multiple levels of abstraction aids in understanding system complexity [8, 101]. Bahill

notes that the success of models is due to the fact that stakeholders do not have to

simultaneously consider all of the complexity of a system; rather simplified, yet

representative models help to scope the intricacy [8]. A central repository of design

information is aggregated in a collaborative environment which promotes configuration

control and communication within the design team (and customer interface). This

central repository also enables visualizing inter-domain dependencies [105]. Recent

case studies claim MBSE increases efficiency of System-Software transition using

modeling artifacts [5]. In the case study of developing a UAV, Andersson noted benefits

associated with the fact that systems and software share relevant interfaces in the

4

model from initial concept; later as the transition to software occurred, both were using

consistent nomenclature and could import System models to SW tools.In addition to

successful reports from modeling experiences, Anderson also reports concerns due to

learning curve, configuration management for large-scale projects, multiple

semantics/diagrams to express the same idea and data management and exchange

consistency. Requirements definition, a critical responsibility of System Engineering, can

also be modeled to identify suballocation, derivation, realization, and maintain

traceability. Modeling tools, while capable of capturing requirements, do not have the

legacy, tool interface or specialization to maintain all requirements for a system. Such

requirements management is best left to a domain specific tool which has been

developed specifically for the task of requirements management, as the consistent rise

in system complexity equal is more requirements to manage. What is needed is a

consistent framework to capture requirements in a repository and import to the model

environment.

Process, methodologies, architecture frameworks, languages, data exchange

protocols have all evolved as a need for increasingly complex systems, and specifically to

support MBSE.

While such process, methodologies, frameworks exist, there is to date, few holistic

approaches which at least address the common foundation and underlying linkage

between theses guiding system engineering principles. At this time unique processes

still exist tailored to specific needs of the user. Maturing to standardized information

representation and exchange protocols will maximize benefit of the MBSE techniques

5

across the industry. Model Based System Engineering is evolving to mitigate the

complexity of system engineering challenges, in a graphical, semantically consistent,

centralized data base of information. The fundamental pillars of system engineering

such as requirements derivation, trade study analysis, architecture implementation

must all be incorporated in the MBSE paradigm.

1.3 Relevance/Importance/Motivation

With a trend toward increasing technological capabilities, System Engineering is

tasked with designing and maintaining increasingly complex interfaces [11]. Interface

management has always been a critical responsibility of System Engineering; through

the advancement towards System of System design, the interface management scope

must consider future extensions and interactions for external autonomous systems.

MBSE is flexible enough to capture and define designs from diverse domains, using

standard semantics, which formalize communication. The multifaceted challenges of

System Engineering include design consistency, dependence and interoperability

amongst traditionally stove piped functional disciplines. Kerzhner et al. extend the

benefit of centralized design information by recognizing that related work in computer

science fields can be applied to the computer interpretable data of the MBSE central

repository infrastructure. [73].

Persistent and continual capture of design information through MBSE processes

provide a workspace for information exchange and collaborative information capture

6

throughout the entire lifecycle of a products, as well as a lasting repository for

documentation.

INCOSE recognizes the importance of MBSE and notes in the INCOSE Vision2020:

“INCOSE Vision for 2020, the future of SE will be model-based, embracing high-fidelity

static and dynamic models at different levels of abstraction”.

Figure 1.3-1: INCOSE Vision 2020 Roadmap for MBSE Capability

In the era of the 80% solution regime (Capabilities Based Acquisition), the maximum

value to the stakeholder is often not a system that can meet the corner case of

requirement space, but rather a system that can meet all absolute needs (e.g. a Safety

requirement) with acceptable degraded performance for optimization benefit (e.g. less

performance for a cost efficient solution) [132]. Support of Analysis of Alternatives

allows stakeholders to make critical architecture decision with consistent and holistic

design information. The motivation for the current application of MBSE to support

7

Architecture Definition is to more efficiently handle the increasingly complex challenges

facing a System Engineer to maximize benefit to the user. Current disparate technique

to share information often results in exchange of data through voluminous

documentation which is difficult to interpret and often misses the intra-discpline

interdependencies.

This Application Framework is relevant to the growth path of MBSE to meet

evolving challenges in the SE field through defining a concise top level application of ,

supported by an exemplar system for user comprehension. Aditional motivation defined

Variant modeling techniques. Product Line Architecture, which leverages variant

feature models, benefits from decreasing cost through reuse, a means to communicate

adoptability opportunities to extend capabilities for the future and increased design

reliability.

1.4 Contributions to the Body of Knowledge (Significance)

Model Based System Engineering is a novel approach to mitigating the ever

growing complexity of technological and political developments to Systems. In

particular this framework for architecture development encapsulating variability

modeling techniques offers a way to systematically include logical variant options within

a model offers a purpose for that variability (future adaptability) and then suggests

using that adaptability as a trade study parameter. Currently literature concerning the

multi-step process to transition from requirements to architecture development is often

concerned with specific methodologies, associated with commercial tool vendors, or

8

does not encapsulate purpose throughout the entire lifecycle. This thesis includes a

concise description of current literature, including architecture frameworks,

methodologies, data transformation techniques, decision making criteria for trade study

and encapsulation of logical variant modeling techniques. The notion of adaptability, as

future growth for a system, including additional requirements indicates trade study

decision for a dynamic environment. By representing adaptability as a key trade off

parameter, variant modeling can support the analysis of multiple requirement sets.

Error! Reference source not found. and Error! Reference source not found.

show the current state of system engineering tool information exchange and the

projected future data sharing model, enabled through MBSE. With tool interoperability,

central data repository, visual description of interactions, hierarchical decomposition,

and verification tied through inherent links to design, implementation and

requirements, MBSE has capabilities to greatly reduce cost, schedule, risk, design error,

effort in documentation, and miscommunication due to inconsistent semantics.

However with many disparate standards, methodologies the high level flow through

trade study analysis which is a fundamental responsibility of systems engineering, may

be obscured. This thesis promotes MBSE as it improves or alters each step in ‘typical’

architecture definition, resulting in the aforementioned benefits from a modeling

environment. The end-to –end view of each stage of architecture definition reviews

literature, methods, semantics and basic principles to complete necessary artifacts

defining the system to meet stakeholder needs.

9

Leveraging techniques for interoperability through a central repository, with formal

semantics which allow data processing techniques for further design integration, the

future of SE products with MBSE leads to a highliy integrated model throughout a

system lifecycle.

1.5 Organization

Section 2 defines the Purpose of this dissertation, including Constraints and

Limitations. Section 3 is a formal literature review of the multi-faceted challenge that

faces Architecture Definition through Variability Modeling Techniques. This will include

the evolution of MBSE from classical system engineering. The reader will be introduced

to SysML at the user level. Guiding Architecture frameworks discuss suggested

viewpoints and artifacts desired to generate an architecture definition. MBSE

Methodologies will be reviewed which exposes the various current uses of MBSE,

however not necessarily specified to trade studies, nor incorporating the use of

variability modeling techniques. Model and Simulation Interoperability enables trade

studies by interfacing with Domain Specific tools that execute performance simulations.

The performance simulations assess an architectures ability to meet driving

requirements that are later evaluated against stakeholder needs in an n Objective

Function. Section 4 intriduces the Application Framework, describing the benefit,

process, and implementation Variability Modeling techniques as a means to capture

potential architectures Each phase aims to describe core criteria required for

architecture capture enabling trade studies, the model-based implementation and

10

finally the benefit gained from the MBSE approach versus conventional techniques.

Design for Adaptability is introduced as a critical trade study criteria for future

applications of variability modeling. A nominal example is presented in Section 5 to

show proof-of-concept. Finally Section 6 is a discussion of the results, reinforcing the

value of applying MBSE for architecture definition and offering a path forward for

additional research.

2 Research Problem

2.1 Purpose (Goals and Objectives)

The purpose of this dissertation is to provide a framework which leverages

variability modeling techniques for architecture trade studies and analysis. First a

thorough literature review will introduce the reader to the various concepts associated

with the state of the art in model based system engineering. Next these high level

concepts will be discussed through implementation processes in a framework which

provides descriptions founded in current research and standards. Finally an example is

used as a proof-of-concept to show the framework in a simulated application. This

dissertation aims to describe how MBSE can improve architecture trade studies

through management of design variability, while incorporating concepts towards design

for adaptability.

11

2.2 Scope and Constraints

The scope of this dissertation is limited to the Application of MBSE to Define

Architecture Definition. Data used is a simulated example to describe various MBSE

artifacts. In the same way that MBSE is particularly beneficial for visual

interpretation, the example included is used to aid understanding of the MBSE

principles. This dissertation will review optimization routines (potentially used in a

trade study evaluation) but is not focused on the mathematical description,

derivation, or implementation of such optimization algorithms – rather describing in

the process of trade studies for architecture definition. The purpose is to define

how these routines can be described through parametric relationships, not focus on

an individual routine itself. Semantics of SysML will be discussed for user

comprehension, however full scope discussion of the semantics can be found in [40]

or [92].

The focus is to show a continuous integration of MBSE principles, and

comparison to standard SE practices, not on the simulated data. Design for

Adaptability can be assessed through several mechanism (e.g. number of modular

interfaces, quality factors etc.) in this dissertation adaptability is viewed as the

ability for variant architectures to meet new sets of requirements (adapting to

requirements growth). Determining a value associated with adaptability criteria is

beyond the scope of this dissertation. The example presented in this paper is

12

designed using the MagicDraw Studio SysML Profile, however this design decision is

independent of the fundamental principles of the framework Literature Review

3 Literature overview

Model Based System Engineering : “the formalized application of

modeling to support system requirements, design, analysis, verification and

validation activities beginning in the conceptual design phase and

continuing throughout development and later life cycle Phases [122]”

The following literature review introduces the fundamental concepts related to

industry standard practices that enable the application of MBSE to architecture

definition. In many aspects MBSE complements the classical System Engineering

approaches; however, document-centric processes are replaced with models which

offer traceability, various viewpoints, and a central repository for design information

[101]. Multiview modeling is the foundation of MBSE, which allows various viewpoints

of the underlying composite model to highlight aspects of interest to the target user

[112].

13

Figure 2.2-1. MBSE Facilitates Complex System Design Through Multi-Faceted Methods, Frameworks and Standards

System engineering modeling techniques have evolved from Functional Flow

Block Diagrams (FFBD), Structure Analysis and Design Techniques (SADT), and

Integration Definition for Function Modeling (IDEF0), to an Object Oriented

representation [106]. Desire to support such Object Oriented System Engineering

perspectives inspired several unambiguous language definitions [86]. Success from

the Software Engineering domain using UML motivated the profile extension to

14

SysML, a subset of UML, as well as the addition of a Requirement Diagram and a

Parametric Diagram [43, 107].

3.1 SysML as a modeling Language

Figure 3.1-1: OMG SysML definition as a subset and extension of UML

UML and SysML are graphical modeling languages standardized and maintained

by Object Management Group. Oliver recounts the history of UML from structured

analysis supporting early software engineering techniques published by IBM as early as

1974 [87]. In order to handle the increasing software complexity and idea of

relationships amongst entities and data bases, abstraction and object-oriented

approaches began a fundamental shift in software engineering practices,. Rumbaugh et

al introduce Object Modeling Technique (OMT) in 1991 as a means to capture object-

oriented principles. This later formed the base for UML, originating from Rumbaugh,

Jacobsoon, and Booch as a collaborative effort under Rational Inc. In 1997, UML version

1.1 was accepted and standardized by OMG. As early as 2000, publications indicate the

15

desire to apply UML to extended requirements set, namely the System Engineering

domain. Ogren discusses the “Possible Tailoring of UML for Systems Engineering

Purposes” discussing SEML (System Engineering Modeling Language) which would

extend UML concepts to include hardware, and other features to support the entire

lifecycle development for technology [86]. Ogren investigates how UML can be

extended to system architecture applying object oriented principles such as

Aggregation, Inheritance, Communication and Dependency. Suggested requirements for

a system engineering language include capabilities to:

- Model of components of categories: Operator, Software, and

Hardware

- Model a system’s missions and abilities

- Model a system’s structure

- Model a system’s behavior

- Ease of Construction

- Simplistic notation explain to end-users

- Design independence

- Reusability of Model Elements

- Support for Test Identification

- Support automatic analysis through formal semantics [86, 134].

Still intrigued, Axelson on 2002 releases a paper concerning Continuous Time

modeling through UML to apply modeling techniques to Systems Engineering. Indicating

some of the differentiating features between software and systems:

16

- Dynamics: software is discrete, by system have continuous hardware

aspects

- Nonfunctional features: ilities analysis, programmatic constraints

- Interfaces: needs to be extended beyond just data path control

- Failures:

- Manufacturing: software does not have to handle the physical

implementation through manufacturing process [7]:

Additional studies to apply UML to a system as early as 2002beyond the scope of

software alone, specifically a Mechatronic system, include a simplified alarm clock [84].

In 2006 SysML was released an extension to UML2. As early as 2006 publications

include application of activity modeling through SysML to system behavior analysis.

Bridging the gap between activity diagrams and EEFD, Bock shows how SysML can

complement current system engineering techniques, in addition to extended

capabilities, including consistent semantics with software engineering domain [16].

SysML technically uses a subset of UML and extends UML2.x as necessary. Both are

visual general purpose languages, developed to support large scale development

process [38].

The fundamental pillars of SysML include: Structure, Behavior, Requirements,

and Parametrics [40].

17

Figure 3.1-2: Fundamental Pillars of SysML

SysML extends UML through the addition of Requirements Diagram and

Parametric Diagrams (used to capture constraints and continuous relationships within a

system). Modification to some of the core diagrams exits to meet the requirements for a

Systems Engineering domain. Several diagrams that are more applicable to Software

only are omitted to ease the learning curve and coverage of SysML, where deemed

unnecessary. Additionally SysML extends UML classes with blocks, a modular hierarchy

associated with either structure or behavior. UML dependencies are extended to a

system concept of allocation. Additionally SysML extends UML standard ports with flow

ports, a powerful concept that can be typed by a complex block to encapsulate the

movement of higher order entities (above just data) movement throughout a system

[68].

18

Figure 3.1-3: SysML Diagram Hierarchy

Further discussion on the specifics of each Diagram and SysML concepts are

described in Section 4.4. Core benefits of MBSE realized through using SysML include:

- Enhanced ability to capture, analyze, share and manage information

- Improve communication

- Increase ability to manage system complexity

- Improve product quality

- Enhance knowledge capture

- Improve ability to teach and learn systems engineering fundamentals

[48].

3.2 Architecture Framework

ANSI/IEEE 1471 describes architecture as “the fundamental

organization of a system embodied in its components, their relationships to

19

each other and to the environment and the principles guiding its design and

evolution” [58].

Unique Architecture Frameworks have been developed for various target

domains such as Systems architecting, Enterprise architecting, and Software architecting

[106]. At a minimum, most Architecture Frameworks include at least three viewpoints:

- Operational (user)

- Logical (customer/manager)

- Physical (designer) [74].

Specific Architecture Frameworks such as the Military Architecture Frameworks

have evolved and diverged, which include MODAF, NAF, AGATE, DNDAF, MDAF, AOAF,

DoDAF in an attempt to improve procurement, planning, and execution of military

systems [51]. Ashum aggregates various frameworks and focus areas:

Table 3.2-1:Framework vs. Focus Area [6]

Framework Focus Area

ACTIF Framework Architecture for Intelligent Transport in France Methodology

Reference Architecture

AF-EAF (US) Air Force Enterprise Architecture Framework

Development/Investment Guide

CAF (US) C4ISR Architecture Framework Product Descriptions DAF (Australian) Defense Architecture Framework Product Descriptions

DoDAF (US) Department of Defense Architecture Framework Product Descriptions

E2AF Extended Enterprise Architecture Framework Classification, Methodology

FEAF (US) Federal Enterprise Architecture Framework Components, Levels

IAF * Integrated Architecture Framework Methodology

-- Gartner Group Framework Classification/Organization -- Index Architecture Framework Classification/Organization

20

MODAF (UK) Ministry of Defense Architecture Framework Product Descriptions

NAF NATO C3 Systems Architecture Framework Product Descriptions, COE, TRM, …

TEAF (US) Treasury Enterprise Architecture Framework

Development/Investment Guide

TISAF (US) Treasury Information Sys Architecture Framework

Development/Investment Guide

TOGAF The Open Group Architecture Framework Methodology, TRM, …

Zachman Zachman Framework for Enterprise Architecture Classification/Organization

MBSE guides the generation of required artifacts therefore complementing the

Architecture Framework of choice. Model elements can be reused in future system

development, similar to the DoD Data Item Descriptions (originally part of MIL-STD-498),

which remain pertinent for System Engineering reuse through templates [101].

3.2.1 DoDAF

“Frameworks are documents that describe useful methods, practices, and

procedures for developing Architectural Descriptions. Frameworks can be prescriptive

(e.g., their use is required) or descriptive (i.e., their use is recommended). DoDAF has

both prescriptive and descriptive elements that organizations within the Department

require its use in developing Architectural Descriptions that respond to their mandates.

[128]”

In particular the Department of Defense framework is often used as guidance for

design description as a means to support interoperable and cost effective military

systems [51]. This framework has continuously evolved to include a complete

description of viewpoints and mapping in order to describe complex systems.

21

Figure 3.2-1: Evolution of the DoDAF [128]

Specific UML (and SysML) profiles have emerged (Unified Profile for DoDAF

and MODAF – UPDM) providing a consistent display of the Architecture Framework

artifacts [91]. UPDM is implemented as a profile extension of UML (including a

predefined set of stereotypes, constraints and tag definitions) [51].Viewpoints

address various operational needs, levels of abstraction and cross-references to

analyze requirements mapping.

Figure 3.2-2 Viewpoints Recommended by DoDAF [129]

22

Piaszczyk et al have published a case study in applying MBSE principles, using

SysML to design following DoDAF Framework [101]. The case study applies an iterative

method of model based system engineering tracing from high level use case diagrams

representing Operational Views as well as allocation matrices to represent an System

Views (i.e. SV-5 system function to activities). Final conclusions indicate increased

communication, organization, coverage and final traceability due to the application

MBSE of DoDAF.

3.2.2 MDA

In the MDA, models are first-class artifacts, integrated into the

development process through the chain of transformations from PIM through

PSM to coded application. To enable this, the MDA requires models to be

expressed in a MOF-based language. This guarantees that the models can be

stored in a MOF-compliant repository, parsed and transformed by MOF-

compliant tools, and rendered into XMI for transport over a network.

Revolutionary to Software Architecture Frameworks, OMG published Model

Driven Architecture in June 2003, which separates business and application logic from

the underlying platform [52, 89]. MDA is the precursor to MBSE, which leverages

underlying metamodels to describe system functionality [73]. Initially conceived for

software intensive systems MDA separates Platform Independent Model from Platform

Specific models. This allows users to highlight necessary behavior, and reuse code, as

applicable to varying specific platforms in a controlled manner. In MDA the model

remains the central element. MDA specifies that a model is always updated and is the

23

most up to date representation of the system[38]. Specific Metamodel concepts provide

a fundamental structure, enabling abstraction of complex system phenomena, which

can then be translated to support automatic code generation. The three primary goals

of MDA are:

- Portability

- Reusability

- Interoperability. [41].

Figure 3.2-3: OMG's MDA extension to Platform Specific Models

MDA concentrates on the variability associated with the platform, however this

notion can be extended to actual architecture variations within desired user functions as

described below [109].

24

3.3 Methodologies

Several MBSE methodologies exist to define processes, tool flow, data exchange

protocol, and artifact generation. While these methodologies have similar foundations

in capturing design, execution, and maintenance of a system through the entire lifecyle,

each offers a unique perspective on the importance of iterative design, maturity of

model fidelity, and methods to share information between models. Popular

methodologies include:

- IBM’s Harmony SE

- INCOSE’s Object Oriented System Engineering Method (OOSEM)

- IBM’s Rational Unified Process for System Engineering

- Vitech MBSE

- JPL State Analysis

- Dori Object-Process Methodology (OPM) [35, 99].

3.3.1 Harmony

Harmony SE is the MBSE methodology developed by I-Logix/ Telelogic/ IBM.

The methodology reflects the traditional Systems Engineering Vee – while

recommending specific artifacts at each top-level process element. Considered a

System/EmbeddedSoftware Development environment, Harmony highlights the

importance of Service-Request architecture, emphasizing the importance of data and

control exchange between subsystems [53]. From requirements derivation to

architecture definition, Harmony stresses function-driven design principles. The

25

foundation is the identification and expansion of operational contract, a message-based

interface communication concept [54]. Key objectives of Harmony for Systems

Engineering are:

- Identification and derivation of required system functions

- Identification of associated system modes and states

- Allocation of the identified system functions and modes/states to a

subsystem structure[55].

Figure 3.3-1: Harmony Integrate Systems and Software Development Process [53]

In the Harmony process, IBM recommends the handoff from Systems to

Software as an executable model, which is an abstract recommendation of

requirements [53]. Critical documents a recommended to be generated from the

26

model itself including: HW/SW requirements/ specifications, logical interface control

documents (ICD).

Figure 3.3-2: Harmony SE Process Elements

3.3.2 Object-Process Methodology (OPM)

Object-Process Methodology (OPM), is an alternative language beyond SysML to

support MBSE, presenting concurrent modeling of structure and behavior using a single

diagram type: Object Process Diagram (OPD). OPM uses hierarchical refinement in order

to mitigate complexity through a series of OPDs, each with increasing level of detail [94].

Essential entities defined by OPM:

27

- Objects: the things that exist or have the potential of existence,

physically or conceptually

- Processes: transform objects by creating, consuming, or changing their

state

- States: the situations that objects can be in [30] .

OPDs describe the relationship between these entities through structural and

procedural links. Static relations between entities are described through Structural

links, whereas system behavior (dynamic relations between entities) is described

through Procedural links [113]. Three refinement/abstraction mechanisms are used to

manage the complexity of OPDs:

- Unfolding/ folding: for additional detail of structural hierarchy of an

object

- In-zooming/ out-zooming: to expose the inner details of an object

- State expressing/ suppressing: to expose an object’s state [76].

In addition to the OPDs, OPM attempts to tie the capture of system artifacts

throughout the entire lifecycle together in a comprehensible manner through Object-

Process Langue (OPL). OPL is an automatically generated, human-readable text that

accompanies the OPDs, supporting those not familiar with the OPM semantics [118].

OPL can also be used for post-processing via automated scripts that recognize the OPL

Ontology for extended customized scripts and data processing.

28

In particular, a recent case study observed the comprehension of various

example system architectures through an experiment that included providing students

with SysML artifacts only, OPDs only, and SysML/OPDs with associated OPL. Results

indicated an increased design comprehension (e.g. identification of faults, ability to

understand system interconnects etc.. ) when supplementing OPDs with automated

model to text translation known as Object Process Language (OPL). [44].

Figure 3.3-3: OPM Entities: Object, Process, and State [31]

3.3.3 Rational Unified Process (RUP)

The Rational Unified Process was created in 1996, when Rational acquired

Objectify (later to be acquired by IBM). This process leveraged principles form the

29

software-centric Unified Process (written by Ivan Jackobson). RUP identifies a

methodology to unify software, systems, and various stakeholder designs throughout

entire product lifecycle . RUP is a tailorable process that guides development through

tools, recommended best practices, and artifact required for a spiral development

process.

RUP Basic Principles include :

- “Adapt the process

- Balance competing stakeholder priorities

- Collaborate across teams

- Demonstrate value iteratively

- Elevate the level of abstraction

- Focus continuously on quality” [100].

RUP is defined through artifacts generated as a result of lifecycle phases, disciplines

and iterations.

- Lifecycle – the four phases based on typical waterfall style SE process

- Disciplines – the main focus areas of effort carried out by the team in developing

the system; note: no separate systems engineering discipline, instead support is

applied within the RUP disciplines throughout

- Iterations – Series of system builds based on risk identification and mitigation;

several spiral development in a waterfall style within each spiral

30

- Viewpoints Recommended modeling artifacts to support development in each

phase

Recognized phases with the lifecycle of an iteration are similar to waterfall development

cycle. Each phase has one key objective and milestone, in order to value completion of

that milestone to proceed to the next iteration [57].

- Inception: scope the system ; provide basis for initial costing and budgets

- Elaboration: plan the project, specify features, baseline architecture

- Construction : development of components and other features of the system

- Transition: transition product to end user community

Figure 3.3-4: The Rational Unified Process [100]

31

RUP SE recommends views based on model levels and targeted stakeholder.

Model levels include

- Context - system and its actors

- Analysis – decomposition of system requirements

- Design – realization of analysis to hardware

- Implementation – design to specific configuration

Figure 3.3-5: RUP SE Model Framework

RUP offers: improved governance, regular feedback to stakeholder, improved

risk management, implementing actual requirements ,early discover for implementation

risks, allowing designers to focus on top priorities. [4]. IBM offers custom profile and

project planning to lead engineering teams through the iterative development cycle.

3.3.4 Vitech

32

Vitech CORE describes a model based methodology based on a layered approach

toward definition throughout the various system engineering domains to increase

consistency and completeness. CORE aims to integrate 4 systems domains:

Requirements Management, Behavior Analysis, Validation and Verification and

Architecture Development.

Vitech offers a CORE framework which offers:

- Integrated requirements

- Executable behavioral models

- Architecture development tools

- Validation and verification support

- Automated system documentation from the CORE model [130]”

It distinguishing (marketed) features claim to :

- Shorten the Learning with full project visibility Curve

- Work Less to Maintain Designs

- Communicate with Clarity.

33

Figure 3.3-6: CORE System Definition Repository[17]

CORE recommends a process known as the “Onion Model” that stressed

the importance of hierarchical detail design. From high-level to final design detail,

each of the system artifacts are maintained in a collaborative data base. At each

level of the “Onion” various criteria must be met before moving toward the next

level of detail:

34

Figure 3.3-7: Vitech MBSE Onion Model [36]

Vitech promotes modeling both the problem and solution space in a

semantically consistent language. Using a single design repository promotes

traceability and collaboration. Engineering the system “vertically before

horizontally”. Use the tools effectively to make the task of system engineering

toward system engineering challenges, not documentation challenges[35]

3.3.5 State Analysis

State Analysis is the methodology derived at JPL. This methodology is based on

principles from control theory. In this MBSE approach, designed begin to model the

behavior of the system to be controlled, followed by models of the control system. It is

intended to address the complexity challenge in an approach that is complementary to

35

functional decomposition [28]. State Analysis specifies Goals which are constraints on

state variables over a time interval.

Figure 3.3-8 State Analysis: State Based Behavioral Modeling [62]

State analysis separates the control system and the system under control,

emphasizing hierarchical breakdown encompassing separation of systems to

subsystems [28]

The foundational Control Concept in State Analysis are considered

- State Knowledge: current condition of evolving system, defined through value of

state variables

- State Constraints: variables and constraints the system must adhere to

- State-Based Models: behavior of system under control in particular state and

interaction with other control systems

- Goal Achievers: enabling models to determine state knowledge

- Deployments: determining how functions are deployed throughout system

36

- Hardware Adapter: Measurements and Commands – interface to the system

under control [62]

Figure 3.3-9: Leveraging Control Theory to Define the Lifecycle of a System

State Analysis extends control theory in manners such as:

- State is explicit

- State estimation is separate from state control

- Hardware adapters and data collections provide the sole interfaces

between the system under control and the control system [83].

Throughout State Analysis models are used to convey information in a closed loop

format to provide feedback to stakeholders.

37

Figure 3.3-10: State Analysis used to Execute System Engineering Execution of Mission [67]

Several case study note attributed benefits of State Analysis including:

- Continuous documenation and representation of a system resulting in

continuous visibility into the state of the design

- Modeling of behaviours and characterizing system interaction which

reduces risk at comlex interfaces

- Capturing critical system constraints and operating rules, co-loacted with

eth design principles from which they are derived. [67]

Wagner et al released an ontology for mapping State Analysis concepts to SysML

through profile extensions in [131]. This formal recommendation for mapping allows the

use of State Analysis methodology to be applied with the standard tools associated with

UML/SySML support.

38

3.3.6 Object Oriented Systems Engineering Methodology

(OOSEM)

OOSEM defines synthesizing candidate architectures, evaluating and optimizing

alternatives (leading to validation and system verification) as continuous processes

developed through iterative design [40]. The foundation of OOSEM developed from

necessary Software Engineering processes prior to the advent of SysMLAs applied to

MBSE, the fundamental principles still apply. The Object Oriented portion of OOSEM as

it applies to MBSE (via SysML) is the application of classes, attributes, and operators,

generalization, encapsulation and use cases.

OOSEM provides an SE methodology to capture complex requirements using

SysML, integrate with OO software and hardware, accommodate changing requirement

and design evolution. This scenario driven process identifies critical artifacts required in

each of the System Engineering Lifecycles phases, allowing that some activities may be

39

executed in parallel, and may be in an iterative nature. OOSEM promotes traceability

and central repository to maximize results from collaborative efforts.

Figure 3.3-11: OOSEM MBSE Methodology

Leveraging the OOSEM methodology, this application framework provides a

mechanism to implement the integration of customer based trade studies with domain

specific simulations, synchronized via MBSE. The application framework presented in

this paper highlights activities typically executed during CONOPS definition, but also

includes an iterative method, which enables incremental requirements redefinition

throughout the lifecycle.

40

3.4 Model and Simulation Interoperability

“The [ resulting] lack of tool interoperability has been a significant inhibitor to

widespread deployment of MBSE. The absence of convergent MBSE standards to date is a

further impediment to adoption, imposing unique training requirements for each tool

and method. [122]”

Domain specific simulations are used to characterize the static implementation

and dynamic system responses germane to a particular field of analysis. Performance

models enable designers to evaluate performance impacts from specific implementation

decisions via specialized tools used for high fidelity analysis. Because of its meta-

language base, SysML can be extended to interact with such domain specific tools,

which enables multi-tool interoperability [40, 96]. Tool interoperability, however,

remains a formidable challenge to synthesizing end-to-end system simulations.

3.4.1 Data Exchange Standards

Data exchange standards offer a means to share information between tools,

models, and users. In particular, widely recognized standards such as: Common Object

Request Broker Architecture (CORBA), OMG Meta-Object Facility (MOF) (ISO/IEC

19502:2005), Extensible Markup Language (XML), and XML Metadata Interchange (XMI)

specification and Standard for the Exchange of Product model data (STEP/ISO 10303:

AP233) are used to structure information exchange [106].

3.4.1.1 MOF

“MOF is an extensible model driven integration framework for defining,

manipulating and integrating metadata and data in a platform independent

41

manner. MOF-based standards are in use for integrating tools, applications and

data [88]”

MOF is a 4-layered architecture used to define the structure and abstract syntax

of language or data. MOF formalizes defining a specific language, notably used to

describe UML and its derivatives [117]. MOF is a standard for data exchange maintained

by OMG, and is also an international standard: ISO/IEC 19502:2005 Information

technology -- Meta Object Facility (MOF). It is used as a metalanguage to define an

integrated process solution in a platform independent manner. Metaobjects enable use

of objects and design information prior to knowing all of the details.

Figure 3.4-1: Example of the 4 Layer Metamodel Hierarchy [92]

42

3.4.1.2 STEP/ AP233

“[STEP (Standard for the Exchange of Product model data )] provides a

representation of product information along with the necessary mechanisms and

definitions to enable product data to be exchanged. Applies to the

representation of product information, including components and assemblies;

the exchange of product data, including storing, transferring, accessing, and

archiving. [63]”

STEP/ ISO 13030 is an ISO Standard Exchange Protocol created to facilitate

understanding of data flow as an output/input product . The purpose of STEP is to

establish a modular vender neutral format for data exchange [106]. Initially associated

with general exchange of product data such as CAD, Computer-aided manufacturing,

Computer-aided engineering, Product Data Management/EDM and other CAxsystems,

several updates and Application Protocols (AP) have been released which apply

standards specific to application domains, including System Engineering (AP233) [65].

As seen in Figure 3.4-2, AP233 is applicable throughout the entire lifecycle of a product,

consistent with System Engineering presence. At various stages throughout the lifecycle

specific domains are more relevant, therefore leveraging data exchange standards from

a unique AP as required.

43

Figure 3.4-2 STEP/AP 233 Structure Data Exchange Throughout Entire Product Lifecycle [127]

The scope of AP233 includes a formal breakdown of the products associated

with System Engineering workflow, such as requirements , analysis, trade study

execution, etc. . Beyond specifying only to the domain in an Application Protocol, the

AP then specifies on functional bases the format and structure of data exchange

products.

Figure 3.4-3: Scope of AP233 [116]

44

Ongoing efforts exist in mapping SysML and AP233 in order to support data

exchange standards for MBSE. These efforts are aiming to mitigate concerns such as

data loss issues as reported by Shah et al., complicating use of the AP233 standard

[112]. Eurostep, NIST, OMG and INCOSE are leading the initiative to align features from

SysML and AP233 to leverage successful constructs to support model interoperability.

Figure 3.4-4 shows the current state of cohesion between the modeling languages

SysML versus standard construct for information exchange.

Figure 3.4-4: SysML and AP233 Overlap

3.4.1.3 XMI

“ XMI is a model driven XML Integration framework for defining,

interchanging, manipulating and integrating XML data and objects. XMI-based

standards are in use for integrating tools, repositories, applications and data

warehouses. XMI provides rules by which a schema can be generated for any

valid XMI-transmissible MOF-based metamodel. XMI provides a mapping from

MOF to XML. As MOF and XML technology evolved, the XMI mapping is being

45

updated to comply with the latest versions of these specifications OMG (Object

Management Group) Aug 2011 #377}”

ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

XML/XMI is a standard metadata based exchange protocol which can facilitate

sharing of models structure or data, again with challenges such as complex readability.

Formalized through a series of releases, the current ISO version is: ISO/IEC 19503:2005

Information technology – XML Metadata Interchange (XMI) [66]. XMI is a specific

application of XML used to support model information exchange through defining a

schema consistent with MOF. My supporting the MOF schema, XMI enables saving UML

and SysML models in XML, therefore enabling exchange of models in a predefined

format (tool interoperability) [117]. XMI integrates three industry standards:

- XML, eXtensible Markup Language, a W3C standard

- UML, Unified Modeling Language, an OMG modeling specification, ISO/IEC

19501

- MOF, Meta Object Facility (ISO/IEC 19502) [66].

46

Figure 3.4-5 Relationship between MOF, XML, and XMI [1]

3.4.2 Model Transformation

Studies dating back to 2008 show examples of model translation tools to

transform SysML to Modelica (a multi-domain, open source, simulation platform) [68].

Incremental improvements continue as research supplements these current

transformation techniques, which are supported largely by INCOSE challenge teams and

Georgia Tech initiatives [112, 112]. To date examples include SysML to VHDL [79],

SystemC, [97], C++, Simulink [112], Satellite Tool Kit [115].

Shah et al describe a transformation from SysML design models to a domain

specific tool such as EPLAN Fluid and Modelica in order to create production ready

layouts. This case study embodied the application of domain specific tools to an electro-

hydraulic log splitter using indirect modeling techniques in a common SysML repository.

Structural aspects are defined in EPLAN, and performance analysis is derived from

Modelica simulations. Mischkalla shows a multi-layered process which transforms base

design information from SysML to define hardware software interfaces to a co-

simulation environment involving C+, SystemC and VHDL on Modelsim. SystemC allows

a lightweight definition of behavior, which is then transformed to desired VHDL

implementation. Once the simulations were executed and desired system behavior was

attained the final transformation is from the original System Modeling to VHDL as FPGA

Configuration in Xilinx ISE/EDK. Patel shows application of system modeling

transformation to define a SysFLOW Work Engine used to drive Cloud Computing

47

architecture [97]. XMI is used as the intermediate data source to transform SysML

models to inputs for the required workflow for architecture definition.

Figure 3.4-6: SysFlow Workflow Engine (SWE) [97]

Satellite Tool Kit is used for domain specific modeling as Spangelo et al designed

a CubeSat mission: the Radio Aurora Explorer (RAX) mission. SysML elements were

mapped (or generated through profile extension) to parallel STK element to conform

to the required domain specific transformation such that analysis could be executed on

the baseline system descriptive model. Conclusions indicate reduced complexity due to

the foundation of a central data repository, consistent semantics and concise system

description provided by the MBSE approach.

Model transformations can be executed through a variety of tools including

Model to Text Tools and Model to Model Tools. Transformational techniques include:

48

Graph Transformations, Query/View/Transformation (QVT), Atlas Transformation

Language (ATL), Kermeta, Epsilon Transformation Language (ETL), and Visual Automated

Model Transformation (VIATRA) to facilitate automated translation [29, 32] . These

tools allow the SysML model to act as a central repository that can be translated to

domain specific tools. The general flow of model translation include generating a source

model, identifying translation rules from source to target, and executing translation to

generate a target model.

3.4.2.1 OCL

“Specifies the Object Constraint Language (OCL), a formal language

used to describe expressions on UML models. These expressions typically specify

invariant conditions that must hold for the system being modeled or queries over

objects described in a model. OCL expressions can be used to specify operations /

actions that, when executed, do alter the state of the system; specify

application-specific constraints in their models; specify queries on the UML

model. [91]”

OCL is a language maintained by OMG that describes rules that apply to models

[3]. OCL statements are constructed in four parts:

- Context to define the scenario for when the statement is valid

- Property representing a characteristics of the context (e.g., if the context

is a class, a property might be an attribute)

- Operation to manipulates or qualifies a property

- Keywords that are used to specify conditional expressions.

49

OCL can be used to verify that a model conforms to its metamodel, this can be

extended further to verify that a model conforms to the desired requirements

embodied in that model, support system verification [15]. Additionally, OCL can be

used to support model transformations (to domain specific languages or external

executable platforms) OCL is used as a foundation for QVT for querying models [69].

Tessier et al describe the use of OCL to capture variability within a behavior model

[123].

3.4.2.2 QVT

“This specification is one of a series related to developing the 2.0

revision of the OMG Meta Object Facility specification, referred to as MOF 2.0.

This specification addresses a technology neutral part of MOF and pertains to:

1.) queries on models; 2.) views on metamodels; and 3.) transformations of

models. [90]”

QVT (Query/Views/Transformation) is an OMG Specification that describes

model to model transformation. This language specifies a subset of languages that

supports that provides support to query a source model (complying with a source

metamodel) and transforming that to a target model (complying with a target

metamodel) [26]. QVT has both graphical and textual support. The subset languages

include:

- Relations – describe mapping from Target to Source

- Core – target for translations from Relations Mapping

50

- Operation – imperative transformation depicted in Core or Relations

language [68]

Figure 3.4-7: Relationship between QVT Metamodel [90]

Kerzner et al. published a case study using QVT as the model transformation

mechanism, noting however that the Operational Mappings language limits

bidirectional transformations. [72]

3.4.2.3 ATL

“ATL provides a way to produce a number of target models from a set of

source models. An ATL transformation program is composed of rules that define

how source model elements are matched and navigated to create and initialize

the elements of the target models [124].”

The ATLAS transformation Language is another defacto standard used for model

transformation. ATL also began as a response to the QVT request for proposal in 2002,

however since the selection for QVT as an OMG standard, ATL has continued to evolve

in parallel QVT [69]. QVT and ATL share similar goals however, QVT is most often

associated with software engineering transformations, whereas ATL is concerned

primarily with data product transformation, both however require that source and

target models adhere to MOF schema for successful model transformation [75]. ATL is a

text based language, versus a graphical langue. It defines transformation in a

51

unidirectional fashion, therefore bidirectional transformations are really 2 uni-

directional transformations. An ATL transformation program is composed of rules that

define how source model elements are matched and navigated to create and initialize

the elements of the target models. In ATL the source metamodel, target metamodel

and transformation metamodel all transform to OMG’s MetaObject Facility core

specification [88] .

Figure 3.4-8: ATL Transformation from Source to Target [124]

ATL transformation program is composed of rules that define how source model

elements are matched and navigated to create and initialize the elements of the target

models. OCL used to express constrains on rules. These rules are divided as declarative

or imperative into:

- Matched Rules – define which kinds of source elements target elements

must be generated and initialized

- Lazy Rules - applied only when called by another rule

- Called Rules – helper, explicitly called to be executed and they can accept

parameters. [124].

52

An example of using ATL is: the transformation between SysML to VHDL

described by Bouquet et al. [18]. Translation rules specify the transformation from

SysML to VHDL using structural block diagrams such as a BDD and IBD to generate VHDL

code. A project currently funded through Rockwell Collins and Georgia Tech indicates

usage of ATL to transform necessary simulation from a core SysML repository to Arena,

the target simulation and analysis platform for the Application Domain of interest [10],

[59].

3.4.3 Execution

While SysML is not an executable language per se, various vendors offer

integrated solutions which simulate behavioral and parametric diagrams, as an

extension to the basic requirements of syntactical and semantic support. Additionally,

SysML can enable executable simulations through automated code generation, model

transformations, or parameter export to external execution platforms [71]. Many

commercial domain specific tools sets (e.g. Matlab, Excel, and Agilent ADS) offer

Application Programming Interfaces (API), which allow various levels of interaction with

the models. Peak et al. show usability of domain specific model interoperability, where

a system model is described in SysML, with coordinated execution through ModelCenter

to evaluate performance of a Mechatronics system [98]. The example included in this

paper also uses ModelCenter as the execution platform, utilizing evaluation of trade

studies across multiple architectures with a final step of writing the results back into the

configured SysML model.

53

3.5 Variability Modeling Support Design for Adaptability

When initially designing a system, engineers are challenged with architectural

decisions based not only on meeting the current set of requirements, but also designing

for future adaptability. Design techniques such as Modular Open System Architecture

(MOSA) are founded on principles of modularity and reuse in an attempt to reduce

design risk, reduce system cost, and increase flexibility [85]. The complexity and

interfaces of a system can be attributed in part to the number of components and inter-

component dependencies, all of which can be systematically captured in a MBSE

approach [108].

Adaptability has a wide variety of definitions, a software-centric publication from

Chung describe “ the ability of a software system to accommodate changes in its

environment” [24]. In the software domain, the term extensibility is often more

narrowly focused on the ability to adapt to new platforms or additional message traffic.

A case study for SPIN Architecture describes methods to assess software extensibility in

terms of additional Processing Algorithms, Safety, and Performance [14]. In this

dissertation we will view adaptability as a means to adapt to additional, predictable

requirements growth (which may include changes in environment). As defined by Gu:

“ Design adaptability is the capability of an existing design to be adaptable to

create a new or modified design based on the changed requirements.” [45]

Variability modeling supports design for adaptability by allowing visualization of

features that may be either included or deferred in order to meet anticipated future

54

requirements. The inclusion of modular features , standard interfaces, and COTS

components offer potential benefits; however, these choices must be systematically

evaluated for the particular system application both in the immediate design phase and

throughout the lifecycle of the product. The complexity and interfaces of a system can

be attributed in part to the number of components and inter-component dependencies,

all of which can be systematically captured in a MBSE approach [108]. By modeling

architectural variations, stakeholders can make knowledgeable selection of product

configuration, using value gained from expected requirements sets as a trade study

criteria

In order to efficiently model the scope of architecture options, sophisticated

modeling techniques above parameter variation must be used. The software domain

uses variability modeling as a means to capture Software Product Line (SPL) variations

such as Behavior, Quality Attributes, Platform Specific Requirements, Network

Constraints, Physical Configuration, Scale Factors, Code Quality, Maintainability,

Evolvability, Scalability, and Error-proness [9, 12]. Product Line Architecture is

motivated by similar benefits as Software Product Lines including: increased quality of a

feature, consistency in distribution of feature information, configuration for variability

motivation, high similarity between products, global change management, and tailored

vs. specific requirement containment [21].

Design for adaptability is a rich area of research that benefits from the process of

variant modeling in MBSE methodology. Recently Mitchel et al. describe a case study

that uses SysML to manage a catalogue of configurations to support system design

55

between common submarine subsystems as underlying platforms evolve [80]. Multiple

methods exist that attempt to determine system lifetime value. System lifetime value is

a multi-faceted challenge that ultimately affects architecture options. Engel et al.

determine architecture options through a Design for Dynamic Value which includes

metrics associated with component adaptability features, component option values, and

interface cost factors [34]. The purpose of this study is to increase lifetime value

through considering adaptability in architecture selection. This method is an extension

of Real Options ‘In’ Projects (ROIP) theory, based on an economic model that evaluates

systems based on criteria as defined in ISO/IEC 9126. Fitch and Cooper highlight the

importance of uncertainty to a product’s final attributes when determining system

lifecycle cost in the Lifecycle Modeling for Design (LCMD) methodology. This process

leverages LifeCycle Assessment techniques (LCA), which identifies various levels of

appraisals for design components:

- Creating inventory or variant of possible design,

- Classifying component cost impacts,

- Characterizing amount of costs,

- Normalizing cost at various levels

- Weighting or ranking component costs [111];[64]

LCMD expands upon these principles with a process that includes Scoping Potential

Scenarios and Architectures, Design Performance Metrics, and Scenario Analysis and

Interpretation [37].

56

Traditional variation implementation techniques used for SPL include Cloning

(manual copying), Annotations (presence conditions) and Modularized Variability

(inclusion of classes, files, packages), all of which can lead to inconsistencies and

inefficiencies [9]. More sophisticated methods of variation modeling include feature

oriented variation techniques, or explicit modeling of variations through a model driven

approach. By abstracting “factors” common to a particular product line, software reuse

can be increased and particular features can be tailored for inclusion for a specific

Application where the variability points are resolved. Feature Oriented Domain Analysis

(FODA) is the foundation of variability modeling used to support Software Product Line

techniques [70]. Fundamentally, the software applications are defined through a

Feature Diagram Approach, where the central node represents all possible functions

and requirements (user-relevant characteristics), as well as Platform Specific features

(architecture) [9, 33]. Czarnecki et al describe a feature as “a distinguishable

characteristic of a concept (e.g., system, component, and so on) that is relevant to some

stakeholder of the concept” [25]. This seminal approach highlights modeling common

components versus potential variations in order to describe the transformation from

Domain Engineering to Application Engineering [13]. Recent literature reviews

consolidate some of the several techniques which extend the Feature Oriented Domain

Analysis approach including:

FORM : Feature Oriented ReUse Method (incorporates Capability

features, Domain technologies, Implementation Techniques and

Operating Environments

57

FOPL : extension of FORM to include programmatic aspects such as

marketing and product planning

Korba: Component based variation modeling

CBFM: cardinality based staged configuration [21, 23].

3.6 Gaps or problem areas

4 Research Framework and Hypothesis

4.1 Conceptual Framework

Optimal system architecture can be achieved by following a MBSE process which

emphasizes requirements analysis, trade study definition, and performance simulation..

Each phase of architecture definition presented in Figure 2 is systematically explored

including benefits, input and exit criteria, followed by a proof-of-concept example.

After determining the optimal architecture, results are fed back to the model for

configuration control. Continuous documentation of the analysis performed, as well as

assumptions (parameters) used, support an iterative approach. Persistent capture of the

requirements, architecture and performance allow updates or modifications (with

traceability) to the system at various points of the system lifecycle. The application of

variant modeling to support design for adaptability, as a means to evaluate potential

architecture decisions against immediate requirements as well as plausible

extensionsisa potential extension to this framework.

58

Figure 4.1-1. Process Flow Guiding Application Framework of MBSE to Support Architecture Definition

4.2 System Requirements

Similar to the conventional System Engineering Vee process, stakeholder needs are

translated to requirements which ultimately govern design decisions. Increasing levels

59

of fidelity allow requirements to be an iterative process. Sophisticated domain specific

tools have been developed to maintain, organize, format, and trace large data bases of

requirements. Such requirements tools are intricate, specified used of database

managers that support linkage and traceability. Automatic synchronization plug-ins

support the import and synchronization from most industry-standard Requirement

Manager tools to requirements objects in SysML.

4.2.1 Use Case Diagram

Use Case diagrams can be developed and negotiated with customers to ensure

the desired system functionality. In contrast to standard textual capture, visualization

of the key functions of the system enables designers to scope the complexity of design

and improve communication with the customer. Increasingly specific system

requirements must then be methodically gathered and documented. Use case diagrams

capture desired system functionality. These diagrams have not changed significantly

between SysML versus UML.. Use case diagrams are recommended to remain at a

higher level of abstraction to identify top level requirements, as additional detail on

system behavior is refined in other behavioral diagrams.

- Actors: represent the external entity that will affect, use or interact with

the system

- Use Case: describes goal of the system from the user perspective

- Relationships: include, extend describe relationship of system behavior

with alternate use cases

60

4.2.2 Requirements Diagram

SysML defines a Requirements Diagram to show hierarchy and association of

requirements objects. Requirements objects can also be added to Structural Diagrams

(Block Definition, Internal Block Diagram), Behavior (Activity, Sequence, Use Case, and

State) Diagrams, or Parametric Diagrams. Linking explicit relationships (Satisfy, Verify,

Refine, Derive, Copy, and Trace) provides traceability, continuous documentation, and

extends communication to designers identifying rationale for design decisions. Listed

below are the relationships that are inherently defined by the SysML spec:

- Satisfy: how a model element satisfies a requirement (e.g. An activity can

satisfy required system behavior)

- Verify: describes how a model artifact can verify a requirement (e.g.

linking the model of test procedure to a requirement)

- Refine: greater detail to describe requirement

- Derive: relates a derived requirement from its source

- Copy: used for master / slave relationship

- Trace: general purpose relationship

Case studies exist to form a methodology for automatic requirements for a

particular domain using model driven development techniques. Sanyal et al identifies

reusable requirements elements that serve as a foundation for requirements derivation

associated with similar technologies [110]. In this manner a library of common

requirements can be associated with verification and validation processes in an attempt

to reduce cost in lifecycle development. Cardei extends the model driven approach with

61

a Requirements Driven Design Automation methodology that include UML, to XML files,

which can report on requirements consistency through post processing [22]. A clear

description of the formal application of requirements derivation and capture in a model

driven form, through published work by dos Santos et al. describe increased

understanding doe to the graphical modeling nature and explicit mapping of

relationship. In addition they address the benefit of the Requirements table (matrix

form of requirements vs. relationship) which helps to describe the cross-cutting

relationships throughout the model. [114].

4.3 Trade Study

Following definition of system requirements, the focus shifts to the scope and

purpose of the trade study. Paredis et al. reviewed trade studies to help meet

stakeholder needs through performing experiments on domain specific models, in order

to eliminate poor design alternatives and maximize benefit from a realized architecture

[96]. Malak et al. investigate architecture trades through component level tradeoff

models in a predictive relationship between top level attributes to realize system

success [78]. Recognizing a cascading effect for system-level choices, in association with

monotonic subsystem performance a Pareto dominance evaluation is used to show

selection of components can predict the optimal system performance. With respect to

both studies, this framework incorporates techniques for modeling consistency in order

to execute the trade space in a collaborative environment. Bourell lists three dominant

concepts in decision matrix development as:

62

- Alternatives: alternatives are derived in the next section of the

framework, when refining the possible architecture options

- Criteria: are derived from requirements derived in the first phase of the

framework

- Weighting Factors: input from stakeholders which determine the

objective scoring function; methods for weighting versus criteria are

discussed below [19].

This phase of the trade study captures of criteria dimensions and weighting

factors. As discussed below, the criteria and weighting factor (which will be elaborated

as an objective function in a constraint relationship).

Trade study analysis is not limited only to technical performance, but may also

include non-functional requirements as key criteria. DecisionLens, one of many

commercial outfits who specializes in trade study visualization offers example criteria

for a trade study that includes “(1) Support to Business / Mission Objectives (2) Risk of

Integration with Existing Systems / Business Processes (3) Platform/Physical

Characteristics (4) Technological Maturity (5) Reusability/Scalability/Sustainability (6)

Compatibility with Future Plans and Objectives(6) System Interoperability “ [27].

MultiDimensional Criteria Analysis is a field of optimization used to evaluate

alternatives amongst various key decision points to derive the greatest value to

stakeholders. Extensive research exists to determine effective techniques to assess an

automated decision making particularly based on scaling or weighting (input Decision

Variables), sensitivity, and uncertainty [20]. An Objective Function (leveraging Decision

63

Variables) is the evaluation of identified system responses against requirements to

determine an ObjectiveFunction Score. London reviews decision analysis techniques

commonly used during System Engineering value analysis including [76]:

- Decision Tree:

a graphical illustration of alternatives; employs a divide and conquer

strategy which allow analysis of alternative through a tree like graph,

organizing and decomposing decision in a branch/ leaf display to facilitate

optimal alternative selection [104]

- Pugh Decision Matrix:

comparison of alterative as ‘better’ or ‘worse’ than a baseline solution.

The alternative with the most positive results is selected as the optimal

solution [2] , [102]

- Analytical Hierarchy Process

hierarchical view of decision making, where alternatives are grouped

within classes of similar features (e.g. cannot compare size of a Football

to size of Mt Everest). AHP converts qualitative descriptions to a

numerical purposes, prioritizes results and calculate a weighted matrix to

compare in a rational and consistent manner. [125]

- House of Quality (QFD)

64

Established initially to achieve Quality Function Deployment, this matrix

resembles a house structure that includes: include customer

requirements, technical requirements, a planning matrix, an

interrelationship matrix, a technical correlation matrix, and a technical

priorities/benchmarks and targets section [121]. The purpose of House of

Quality

Ulman discusses the importance of trade study inputs in terms of risk reduction

for the optimal identification of determining trade study factors The consolidate the list

of risks associated with trade studies include:

- Uncertainty: due to variability (within system constraints) and lack of

knowledge (from leading stakeholders determining selection criteria) ,

both causing inherent risk to the trade study results

- Evolving: change to trade study can change due to maturity of design

information an users goal change throughout architecture development

- Qualitative vs. quantitative: inability to capture qualitative data in a

measurable format leads to difficulty assessing options in a meangful

manner

- Conflicting Sources: through information gathering, stakeholder have

various objectives and viewpoints, consolidating to a singular trade study

evaluation can be challenging [126]

Additional trade study inputs include “Measures of Effectiveness” (MOE) which

identify system values that capture key performance realizations. SysML provides a

65

Stereotype extension “MOE” that can be associated to Data/Value Properties within the

modeled system, as the System Architecture is defined. These MOEs are used as inputs

to the Objective Function, during the trade study assessment to evaluate system

realization versus the customer requirements via an Objective Function.

The ObjectiveFunction may implement any of the decision analysis techniques,

as determined by the Stakeholders (optimization techniques are beyond the scope of

this paper). The Objective Function Score can be represented as a single value

calculation (weighted calculation), a percentage of requirements met, or a binomial

‘Pass/Fail’ (to name a few techniques). To be consistent with the nomenclature of

execution platform, Trade Study parameters used to calculate the ObjectiveFunction

Score are classified as either Objectives (Threshold Requirement) and Constraints

(Absolute Requirements) [87, 132].

4.4 Architecture

After identifying system requirements and trade study parameters, potential

architectures can be developed, including both structure and behavior.

66

Figure 4.4-1: SysML Profile to Diagram Example

In the phase of the framework, the user will leverage the semantic formalism of

SysML to capture design detail for both the intended structure and behavior of the

system. Enabling features versus tradition Systems Engineering allow a user to diagram

the interdependencies at a higher level of detail, describe interactions through linked

allocation, cooperate in separate diagrams, yet sharing similar model elements with a

team as architecture may vary drastically. If not already determined a priori by a

package structure set through process or tool, the user can begin to organize model

elements to increase comprehension and promote organization.

4.4.1 Structural Diagrams

4.4.1.1 Package Diagram(pkg)

Package diagrams exist for organization purposes. Package diagrams allow

modelers to group cominents through structure, hierarchy, function, IPT (integrated

process team) as necessary per the user’s organizations scheme. Import and export

67

association allow elements to be shared between specified packages as a means to

contain models in an organized fashion [39].

4.4.1.2 Block Definition Diagram (bdd)

System structures are modeled as Block elements, a modular unit of system

description. Blocks can be viewed in a hierarchical fashion on a Block Definition

Diagram. Block element can own properties, contained within the hierarchy of that

model element; however, designers may choose to omit displaying information in any

diagram to mitigate complexity. By examining the system in various levels of detail, each

diagram and viewpoint can serve a different purpose. Each distinct viewpoint uses

information from a central data repository, thereby establishing consistency amongst

objects in the model. In an Object-Oriented fashion, the properties (parts, value

properties, ports, constraints) are identified; however, specific values for such

properties are not yet assigned. Blocks can represent Hardware, Software, Data,

Procedure, Facility or Actors [39]. Blocks are extension of UML classes, extended by

UML composite structures[93]. Values are an extension of UML data types, however

they can be assigned a value property which includes units and dimensions [68].

The Block value properties can be exported to the execution platform as Input

Variables to maintain consistency between the descriptive system model and

performance analysis.

- Properties:

parts- specific usage of a black, for a named instance,

68

references – a block can reference another block/part without owing that

block values – UML data types that also include units and dimensions

- Operations: functions which the block owns, or can perform

- Constraints – discussed later in trade study analysis, this defined

constraining relationships between values within blocks

References and Instances of blocks may be used to represent ‘Commercial Off

the Shelf’ (COTS) components. COTS components typically have known values, but such

values may often not be changes by the system designer. An instance is a block with a

particular usage, therefore unique value properties form other blocks of a similar type.

4.4.1.3 Internal Block Diagram (ibd)

Interfaces between Blocks are identified in Internal Block Diagrams, which can

capture physical connections as well as logical interfaces that carry item flows.

Compartments allow designers to show multiple hierarchical levels of interactions on a

single IBD. IBD define parts, ports and connectors – showing the connection within a

system. The notion of flowports is SysML specific, as a means to abstract item flow and

indicate complex interfaces within a system. An Internal Block Diagram shows the

“usage” of a part, which is a specific role of a Block. Port specifies interaction points on

blocks and parts. Formally broken into Standard ports (UML) heritage and Flow port,

SysML v1.3 simplified to Flow Port only-notation.

4.4.2 Behavioral Diagrams

69

In addition to modeling the key structural aspects, behavioral models are

developed to capture the architecture definition. SysML uses a subset of UML

behavioral diagrams including: Sequence Diagram, State Machine Diagram, Activity

Diagram and Use Case Diagram.

4.4.2.1 Sequence (seq)

Sequence Diagrams highlight interaction between various actors and structural

elements (modeled as Lifelines) within the architecture. Often used to describe message

interfaces, Sequence Diagrams can also be used at a system level to describe control,

timing aspects and interdependencies between modeled entities [39]. The emphasis

for sequence diagrams are the messages exchanges between structural elements, which

can be viewed in an event-driven or timeline manner.

- Lifeline: Can represent ports, actors, blocks, anything that is relevant to

the capture of interactions to be described in the sequence diagram

- Occurrence Specification: describe what can happen to an instance

represented by a lifeline: e.g., sending/receiving messages,

start/completion of messages or behavior, creation and destruction of

instances [39]

- Interaction Operators: defines type of ordered logic, includes graphical

description of frequent event driven sequencing: common operators: alt

(alternative) , opt (optional), par (parallel), loop

4.4.2.1 State (stm)

70

State Machines use a Trigger/Guard/Action nomenclature to describe the

lifecycle of a particular modeling element.

- Triggers can represent Signal events, Time events, Change events of Call

events [40].

- Guard: Criteria that must be met prior to executing a transition (either

entering or existing a state)

- Action: State machines can send or receive messages between blocks

during state transitions; may execute an action or operation while in a

state.

Flexibility within State Machine diagrams can visualize both serial and parallel

operations through the use of regions defining orthogonal composite states. Inline with

the modeling mantra of simplification through decomposition, nested sub-states, within

a top level state machine, can also be defined in an iterative nature with increasing

fidelity. State machines are associated with event-driven behavior as a system

transitions though discrete transitions [68].

4.4.2.2 Activity (act)

Finally activity diagram outline the flow of objects and control through decision

points, transformations and sub-activities. Often called a flow-chart, activity diagrams

are similar to traditional EEFBD, with additional capabilities. The use of swimlanes on

Activity Diagrams allow modelers to display the functional allocation of an activity to a

structural entity. Activity diagrams represent workflows and include:

71

- Activities: describes the transformation of inputs to outputs through a

controlled sequence of actions [40]

- Actions: building block of activities, actions on an activity diagram can

have lower level associated actions for decomposition (call behavior

actions)

- Decisions: the description of a choice, which an object can flow with a

single input and output object flow

- Concurrent/sequential dependencies: fork / join / merge nodes allow

object flows in an activity diagram to occur in parallel, in sequence, or

waiting for additional input prior to progressing (join)

- Input and output parameters: may be typed by a value or a block; may

be continuous or event driven; may be required or optional

Decisions can cause behavior of a system to be determined by influencing factors that

may be due to time, external control, internal data flow. Activities and data flow can

also be associated with probabilities, as a means to capture influences on uncertainty

within a system. Relationships in activity diagrams are always causal, however the

influencing factor may be data flow, time or control, thereby supporting continuous and

discrete system transition [68].

4.4.3 Cross-Cutting Concepts

4.4.3.1 Allocation

Allocation is the term used by systems engineers to denote the

organized cross-association (mapping) of elements within the various structures

72

or hierarchies of a user model. The concept of “allocation” requires flexibility

suitable for abstract system specification, rather than a particular constrained

method of system or software design. - [93]

Allocations are the fundamental principle which associated blocks of both similar

constructs as well as those with cross-cutting purposes. Allocations define underlying

links which describe the inherent traceability of a model. Functions can be associated to

structural elements, a responsibility typical deemed “functional allocation”. Software

allocation to hardware functionality shows the multi-disciplinary capture of design

information. Allocations also provide for the mechanism which associates requirements

to structure and behavior. Allocation is an extension of the UML principle of

dependency. Allocations can be viewed not only through diagrams, but often supported

through a tabular format as a table that most tool vendors support. This concise view of

the relationship between system elements promotes full coverage of a design to

capture the interdependencies between design, model elements, and functions.

Allocations can be implemented through several means including: displaying in a

comment on a diagram, compartments of a block, as an allocation stereotype, explicitly

link between entities, or swimlanes (activity partition) on an activity diagram [39, 93].

4.4.3.2 Stereotypes

Stereotypes are a UML concept which allows customizable classification of

model elements. Considered a lightweight extension, SysML is inherently an extension

of UML through a profile package. User defined stereotypes, tags and package

directories define a profile. Stereotypes can be used to identify elements sharing similar

73

properties or similar functions, or however the user determines appropriate. Stereotype

are a powerful concept allowing designers to identify particular concepts to model

elements which can be used for query, essential to model interoperability and mapping

SysML concepts to Domain Specific Languages.

4.4.4 Variability Modeling Applied to Architecture Definition

Several methods exist to capture variants while modeling architecture concepts.

Abstraction and hierarchical concepts are the object-oriented foundation of refinement

through architecture definition, which may be used to evaluate alternatives. In the case

of more sophisticated variations, specific modeling techniques must be considered to

express all possible variant architectures. As discussed in Section 3.5, literature exists to

define variation points within an architecture. Halim et al. describe techniques for

modeling variation within requirements, tracing the definition of requirements and

potential variations from Primitive Interfaces (objective use case external interfaces) to

a final realized set of requirements for a particular application [47]. In terms of

architecture definition feature based variation techniques often model variation

concepts through:

- Point of variation: capturing variability in terms of ‘Alternatives’,

‘Optional’ and ‘Mandatory’ components within a system

- Dependencies: constraints on variants within a context

74

- Context Models: representations of the environment to support

dependency constraints

- Adaptation rules: rules for the system throughout the lifecycle and

adaptation to its presented context [21, 47, 81].

4.4.4.1 Heavyweight Extension:

A Heavyweight Extension is considered a change to the lower-order MOD. The

recently proposed Common Variability Language (CVL) defines a metamodel that

includes custom association symbols as part of a ‘heavyweight extension’ in order to

capture variability in a SysML-based model. The associations are consistent with the

FODA Feature Analysis Diagram concepts. CVL uses a Base-Variation-Resolution model

transformation in order to transform from the concept of a variability model to a

domain specific mapping of a product realization [49, 50]. Model transformation

approaches cited in Section 3.4.2 can generate resolved architecture solutions, whether

using the CVL approach or as a rule-based approach to a SysML profile [42, 46].

Nominally, these transformations can implement realizations from the base model

through positive variability (add or select additional features), negative variability (base

model contains all possible features), and modifications (most common features are

modeled, but not all variants) [42]. Published experiences using the CVL variant

modeling techniques to improve system design of a domain specific application to Train

Station Control provide motivation for variation modeling within a system modeling

language [49, 119].

75

Figure 4.4-2: CVL Base, Variation Resolved Model [49]

4.4.4.2 Lightweight Extension:

Stereotype and Tag extensions are considered ‘lightweight extensions’ to the

MOF metamodel. Ziadi et al. propose a variant modeling implementation for UML,

which can be extended to SysML, using stereotypes and tags including ‘Variation Point’

and ‘Optional’, as well as Constraints defined in the OCL [135].

Figure 4.4-3: Ziadi Variation Profile for UML to Support SPL [135]

76

In this framework we will extend Ziadi’s work as an application to SysML. Further

extensions to the single variation point include profiles that specifically define not only

the ‘Point of Variability’, but also the ‘VariabilityofElement’ in terms of :

And

Xor

Or

Optional

Vp(i,j): at least i, at most j [82].

The current framework defines variation through stereotypes and

generalizations, leveraging recent work from SysML Revision Task Force (RTF) v1.4, as

well as INCOSE MBSE Challenge Team: SysML for Telescope System Modeling [61, 120].

Figure 5.6-3 captures example variant architectures within the trade space after

extended requirements are considered. Instances are used to analyze components of

the systems where variations are restricted to parameterized values, COTS components,

or specific point design solutions (such as component selection). Complex variations

which include configuration changes, or (independent) parametric implications, are

modeled by distinguishing the variation points explicitly through a stereotype. Use of

the ‘redefines’ data property allows configuration variants to select specific inclusion of

specialized model elements, as opposed to the generalized version selected in the base

model. The stereotypes can then be used when querying the model in order to select

various associated constraints, or behaviors which indicate the performance analysis to

be performed.

77

4.4.5 Analyze Design Alternatives through Analysis

Figure 4.4-4. DoDAF Analysis of Alternatives

Architecture development is an iterative process, evolved over time.

Analyses developed from architectural data remain valid only as long as the

processes and information do not change, and management decision-making

remains focused on the same problem for which the architectural data was

collected. When any of these variables (i.e., architecture purpose, process steps,

information, or management direction) change, previous analyses should be

reviewed to determine if the previous analysis needs to be redone, based on the

newly provided information. Constant feedback and examination needs to be

understood as natural in an environment where program direction and priorities

are constantly in flux.” [129]

Once the requirements are understood, the trade space is defined, and potential

architectures have been identified, simulation models can be designed. Simulation often

requires domain–specific tools. In this example, Model Center is used as the execution

78

platform to facilitate domain specific model interaction through commercially supplied

APIs. Previously mentioned data exchange standards such as XML, STEP, and MOF also

facilitate interoperability through the central repository. By identifying the simulation

inputs and outputs, complex algorithms can be shared amongst a group of engineers.

Sharing algorithms result in higher configuration control and increased collaboration.

Performance trades can encompass both functional and non-functional requirements.

The specification of performance simulations are often executed a lower level of fidelity

in the initial stages of architecture development, with additional refinement as more

knowledge about the system is available.

4.4.5.1 Parametric Diagrams (par)

Performance relationships that define the dependencies of elements within the

system can be modeled as Constraint Blocks. Constraint Blocks can represent a gamut

of complexity from basic equations (which can be stored in a library for reuse) or

customized definition for specialized simulations. Parametric Diagrams incorporate the

interoperability of Constraint Properties (usage of Constraint Block) to show a series of

relationships. Inputs and outputs to the analysis can be identified as parameters on

Constraints Blocks. Block Definition Diagrams can again be used to model hierarchical

relationship of constraints and model elements used to define the analysis (parametric

relationships that support the trade study). Hierarchical decomposition is useful to

mitigate the complexity of any particular analysis in order to facilitate interface to

associated analysis.

79

Where required, simulations which are inherently more complex or process

intensive can be modeled through any of the available behavioral diagrams (activity,

sequence, state) as a means to formalize the intent and artifacts generated by the

simulation. This approach allows concurrent design, simulation, and implementation to

facilitate resource allocation (multiple analysts working towards a common goal).

Benefits associated with defining parametric relationships in SysML are configuration

control, interface definition (reduces integration time), and increased system

engineering reuse of simulation artifacts, and increased understanding of complex

system relationships.

4.4.6 Evaluation of Multiple Requirement Sets

When leveraging techniques to evaluate multiple requirement sets, subject

matter experts, in conjunction with market professionals, must delineate anticipated

requirements (their associated Objective Functions), Value associated with realization of

those requirements (V), and Uncertainty of requirements realization (). Uncertainty of

requirements realization is an indication of confidence that a customer will desire the

new set of requirements for the predicted value. Essentially, this is a higher order

ObjectiveFunction which will include the trade study parameters listed on a per system,

per requirement basis.

A Projected Value is calculated as the Value * Uncertainty. Viable architecture

configurations can then be proposed in order to assess the MOEs of these potential

configurations against the anticipated requirements (calculating the Objective Function

score). In comparison to Engel’s AO approach, only the initial cost (V) is included in this

80

paper. This approach could, however, be expanded to include all quality assessment

factors, Upgrade Cost, Maintainability, etc. Following processes outlined in Section 4.2

the projected requirements will be marked as Objectives and Constraints when

determining weight and scale factors to evaluate MOEs against the requirement

thresholds to calculate the Objective Function score. When evaluating a requirements

set, if an architecture configuration meets or exceeds the Objective Function score for a

set of requirements, consider the ProjectedValue realized. If all Constraints are not met,

ProjectedValue is equal to 0. This methodology again supports Capabilities Based

Systems, where careful analysis is used to select a system based on benefit-

performance, not strict requirements sets.

∑( ) ( )

The TotalLifetimeValue of each architecture configuration is the sum of the

realized ProjectedValue against all requirement sets, less the cost of development per

configuration. Note that each architecture configuration must be evaluated against

each set of requirements (MOEScoreac,r). The final proof of concept example shows a

parametric diagram that represents evaluating multiple requirements sets against

variant architectures, where projected lifetime value is used as an input to the overall

trade study determining the final architecture configuration

81

4.5 Execute & Evaluate

Finally, the trade study is executed on the integrated set of performance

simulations. Resultant MOEs are evaluated against the Objective Function to determine

the optimum architecture definition. After determining the optimum architecture

definition, the results of the study should be recorded into the descriptive system

model. The final step of encompassing trade study results back into the model highlights

the importance of a central repository for data collection, information sharing, and

traceability. Contrary to the standard systems engineering process, the execution of

models occurs through an integrated sense of performance models defined to analyze

the architecture alternatives.

5 Data Analysis and Results

The example model included is a simplified system which addresses a current,

pertinent set of requirements. Variability modeling techniques are applied to represent

architecture alternatives, which are ultimately resolved through a trade study using

performance simulation. This reference variation model, and associated performance

simulations, can be expanded to also evaluate a system’s capability for adaptability as

requirements are update for future needs.

Recent trends in Radar Technology for the 21st Century require non-traditional

means for collecting data, which require low power and high mobility [77]. In this

example model, a simple ground-based, mobile data recording system is used as a

82

passive bi-static radar receiver that captures RF response from a NonCooperative

Emitter. Often referred to as Passive Coherent Location, this system will take advantage

of signals already present in the environment to detect signals through post processing

of collected data [56, 95, 133]. The user wants to maximize the amount of continuous

collection time and maximize the quality of data collected, with a system that is

lightweight, minimal power consumption, and low cost. Figure 4.5-1 portrays the top

level use cases that the user requires from the system. The criteria and analysis used are

for example only. The main focus of the framework is the process and tools utilized to

derive the results. This framework is also scalable into more complex systems, due to

hierarchy and inheritance relationships.

Figure 4.5-1. Example Use Case for Passive BiStatic Radar

83

5.1 System Requirements

Following the MBSE Framework, requirements are systematically defined,

negotiated and recorded. Figure 5.1-1 documents the customer requirements (as

defined in Section 4.2) in a standard tool, as a subset of requirements for a bi-static

radar. These requirements objects are then synchronized to the SysML model to be

used either in Requirements Diagrams, or linked to associated model elements

throughout architecture definition phase(Figure 5.4-1).

Figure 5.1-1. Captured Baseline Requirements

5.2 Defining the Trade Study

In this example, the Objective Requirements include minimizing cost and

maximizing Dwell Time. Sensitivity analysis can be performed to understand how

adjustments to the Constraint requirements values can affect the overall system value.

Unintentional data loss is a Constraint on the system (cannot be violated), therefore

data throughput must be tightly managed. This can be realized through calculating the

possibility of data overflow in each processing interface of the system. As described in

84

Section 4.2 , Requirements are mapped to Objectives and Constraints (weighting for

Objective are used where necessary for the Objective Function).

Figure 5.2-1. Requirements Categorized as Constraints or Objectives

MBSE techniques help to promote several benefits of multidimensional trade

study analysis, within a traceable, modular model including:

- Organizing and clarifying selection task (modeling and capture of MOEs

through requirements derivation)

- Improving understanding of interactions- architecture definition in

following framework

- Providing a written record of selection process – allowing updates and

iterations when requirements adjust or more knowledge of system is

available [19].

ObjectiveFunction max

cost <= $1500

max_dwell_length >= 15sec

dutyCycle >= 50%

bf_InErr FALSE

bf_OverflowErr FALSE

total_data_storage >= 3Tb

Constraint

Trade Study Objective Function

Objective

85

5.3 Architecture Definition

With the requirements defined, SMEs and Engineers can begin architecture

definition. A proposed Block Definition Diagram in Figure 5.3-1 delineates a standard

architecture configuration of a data collection system. This system has a Power Supply,

Receiver, and an Analog to Digital Converter for signal conversion, a Buffer for high

speed data storage and Recorder for long term data storage.

Figure 5.3-1. Block Definition Diagram of System Architecture

Each subsystem is parameterized by either value properties or quantity to

represent optional component configurations. Figure 5.3-2 shows the inputs to the

trade study that represent structural elements for this example.

86

Figure 5.3-2. Defining the Trade Space

Available component selection for the A2D Block can be modeled in greater

detail (Figure 5.3-3) in a separate BDD offering a more detailed viewpoint of the

subsystem. In this example Instances are used to represent COTS components, where

the valid parameters are

a2d A2D001 A2D002 A2D003 A2D004

buffer BF001 BF002 BF003

nBuffers 1-3

recorder REC001 REC002 REC003 REC004

nRecorder 1-2

Inputs

87

later used to drive inputs to the trade study.

Figure 5.3-3. Block Definition Diagram of A2D Converter Represents Structure; Instances Represent Realization of A2D Component Through Know COTS Parts.

88

Architecture definition is not limited to structure but also includes system

behavior. A State Machine is included in Figure 5.3-4 as an example that describes the

transition from an active recording session which may fill the buffer memory, to a data

transfer function – this timeline ultimately affects the DutyCycle MOE of the system.

Figure 5.3-4. State Machine Show the Transition Between Dwells Per User Needs And Data Rate Limitations

5.4 Performance Analysis

The following sections describe two example analyses; one concerning technical

metrics and the other concerning business factors. Ultimately, the requirements include

both technical and business performance metrics, both of which will become inputs to

the final Objective Function.

5.4.1 Dwell Time (Matlab)

89

In this example one of the driving requirements is to maximize the amount of

data continuously collected (dwell time) with limited, low power, light weight hardware.

The longer a user can continuously collect data, the greater chance they can record a

Signal of Interest. A maximum dwell time can be computed based on the output data

rate of the A2D, the input rate of the buffer, the size of the buffer memory, the output

rate of the buffer, and the input rate of the Recorder.

Dwell time is inversely proportional to the output data rate of the Analog to

Digital Converter and Buffer size. Data flow from the A2D is based on number of bits and

sample rate. Limiting the output data rate may not be the best performance option for

the customer. The number of bits provided by the A2D means either greater range of

sensitivity (dynamic range) or finer resolution within a defined energy spectrum. Faster

sample rate allows for a higher frequency IF input signal or potentially greater

instantaneous bandwidth (can sweep more frequencies at a single time).

Mitigating options in the architecture definition then include either increasing

the buffer size or increasing the max input to the Recorder. Increasing the buffer size

increases dwell time as it takes more time to fill the buffer prior to overflow. Increasing

the Recorder input rate (or buffer output rate) increases dwell time through enabling

faster Buffer data output rates (takes longer for the Buffer to overflow) If the data rate

at the output of the A2D exceeds the input rate to the buffer a ‘bf_inError’ occurs,

which would lead to unintentional loss of data (violation of Constraint).

90

Figure 5.4-1. Data Flow Simulation Parametric Diagram Shows Links To Requirements, Input/ Output Ports, And Links To Component Attributes.

By first creating a Block Definition Diagram and associating the System Block to

the Simulation, attributes from the model structure can be linked to Constraints Block

inputs or outputs. In the ‘Data Sim’ Parametric Diagram (Figure 5.4-1) inputs and

outputs of the simulation are identified, requirement are explicitly traced, and hardware

91

realization feeds the input to the analysis. Linking imported requirements objects

associated with each simulation tailors those simulations for specific goals, thereby

limiting their scope and clearly defining the purpose of each simulation.

5.4.2 Cost Model (excel)

The ‘Cost Model’ represents a specific example of a Simulation that models the

component cost of the system based on inputs from the trade study supplied by an

Inventory Model (Figure 5.4-2). Inputs driven by the trade study include a) component

selection (modeled as instances in this case), and b) number of components required

compared to an Inventory Model, which defines component stock level and per

component cost, to compute a cumulative component cost. This inventory model

considers the complexity of available stock versus minimum lot purchase. Component

and quantity selection result in a non-linear effect on the cost of the system.

92

Figure 5.4-2. Inventory Model Representing Components In Stock, Price, and Min Lot Buy Requirements

The computed hardware component cost (Figure 5.4-3) can then be calculated

and stored back in the descriptive SysML model . In this example the customer is looking

to purchase 50 units of the system, which must also be factored in when calculating the

number of lots to purchase of each component separately.

n In Stock Cost Per Min Lot Buy

ADC001 55 $100 100

ADC002 85 $275 100

ADC003 70 $200 100

ADC004 25 $500 100

BF001 150 $50 200

BF002 130 $100 200

BF003 120 $210 200

REC001 75 $120 50

REC002 100 $140 50

REC003 70 $350 50

REC004 90 $500 50

Inventory

nUnits 50

PartId

nReq/

Per Unit

total

Req nPurchased

cost

per ss

a2d ADC001 1 50 50 $100

bf BF001 3 150 150 $50

rec REC003 1 50 50 $350

Total $500

Cost Model

93

Figure 5.4-3. Example Of The Output Of The Cost Model

5.5 Execute & Evaluate

In this example, the simulation models are linked together using ModelCenter

(any custom external execution platform which meets required simulation support can

be used). Model Center organizes a Design of Experiment based on the Input Variables

defined from the SysML model. An embedded routine varies the allowable inputs to

maximize the Objective Function results, ultimately reporting an optimal architecture

solution. This example uses a Darwin Optimizer based on Pareto analysis to determine

the ObjectiveFunction Score, only on valid architecture definitions (all Constraints are

met).

Figure 5.5-1. Model Center Project includes Darwin Optimizer, Input Definition, Cost Model and Dwell Rate Model

94

The optimal design minimizes total cost while maximizing dwell time.

ModelCenter will output the design identification with each of the input variables

specified, along with the expected performance for that design selection. These values

can be written back into the SysML model to capture the current design instantiation.

Figure 5.5-2. Output from Trade Study Analysis

5.6 Design for Adaptability:

The single point architecture used to evaluate a set of requirements for a bi-

static radar will now be expanded to demonstrate an example requirement extension,

95

variant architecture, and multi-tiered evaluation. Fundamentally, the process remains

the same; principles of MBSE in conjunction with stereotype extensions to SysML

support a structured approach to designing a system to maximize stakeholder benefit.

As an iterative update, evolution to the model would include a top-level use case

diagram, requirements definition, potential architecture variations, trade study

evaluation, and simulation execution. The example will include a proof-of-concept

extension (variability modeling: Figure 5.6-3, multi-requirements parametric diagram:

Figure 5.6-4), however, will be limited to modeling techniques for the Application

Framework (optimization routines and evaluation of technical parameters are beyond

the scope of this paper).

Extended requirements from the Data Collection System include adaptations

such as increased data rate collection requirements, mobility requirements (all weather,

reliability, vibration) or even more profound systems usage such as Intelligent

Collector. Environmental requirements could lead the architecture design to a new

technology base, such as a Solid State Recorder (SSR) instead of a Hard Disk Drive

(HDD). Solid State Recording devices offer advantages such as higher IO rates, lower

power consumption, greater vibration tolerance, but can cost up to fifty times as much

as an HDD with comparable storage.

The Intelligent Collector will continuously receive and process data, however

data will only be stored if a Signal of Interest is detected. The Intelligent Collector could

also be used as a mobile one way communication device. Recording only ‘relevant’ data

will greatly mitigate the storage capacity issues, but incurs a cost of constant power and

96

processing. The Intelligent Collector requires a type of high speed processing detector,

which may be desirable even in the base system as a means to distribute data in order

to effectively route digitized samples to the Recorder, resulting in increased dwell time

and data throughput. Ultimately the iterative architecture definition will account for a

trade study to determine if the potential gain from extended requirements merits

implementing additional features in the baseline solution In the use case diagram

(Figure 5.6-1) note the ‘Optional’ stereotype as an indication of variability while

determining which features would be supported by the architecture concept.

Figure 5.6-1. Use Case Diagram Capturing The Extended Requirement Sets

Following the Application Framework and design for adaptability process,

interested stakeholders then formalize proposed requirements (Figure 5.6-2),

associated metrics, value, uncertainty and Objective Functions as inputs to a

requirements repository, as well as the SysML model. Each input to LifetimeValue

97

calculation for a requirement extension, will be captured as value properties in a Block,

used later in a parametric diagram to describe the calculation (Figure 5.6-4).

Figure 5.6-2. Plausible Requirements Extensions To The Baseline

With new requirement sets defined and trade study scope defined, potential

architectures can be proposed. The architecture configurations in Figure 5.6-3 (CF1, CF2,

CF3) extend prior parameterized architecture variations to now include variation in

terms of cardinality (multiplicity, optional inclusion), in addition to specification of

subsystem structure (SSR vs. HDD) and constraints (aDT – minDwellTime vs. rDT-

routerDwellTime ) .

R1. Bistatic Radar

R2. Mobile Bistatic Radar

Shall continuously collect data >30 seconds

Shall detect signals up to 3GHz

Shall have a mean Time Between Failures >5 hours with respect to

environmental constraints

Shall provide independent power supply up to 3 hours

R2. Intelligent Collector

Shall continuously collect and process data >1 min

Shall store data after processed detection of Signal of Interest

Shall support reconfigurable designation for Signal of Interest

characteristics

Shall support processing of modulated communication data from Friendly

Emitter for long term storage

98

Note the technique of variant modeling used to delineate the primary 3

candidate architectures CF1, CF2, CF3. Specialization and generalization are used to

show that both a Solid State Recorder and a Hard Disk Drive may share similar features,

established by values and constraints in Recorder, the offer unique features that require

specialization. CF1 specializes the System, by selecting only an HDD, whereas CF2 can

only include SSR. CF3 which further specializes CF2, will then by definition also include

only an SSR. This is an example of tiered option selection.

Figure 5.6-3. Multiple Architecture Configurations Modeled as Variation from General System Block

99

Constraints that are owned by a block will be selected in the analysis software

through the inclusion of that block in the system architecture. As described in Section

4.4.4 use of the ‘redefines’ property explicitly shows on the block diagram the allowable

selection of a specialized block. Variant analysis can be applied as delineated by the

selection of routerDwellTime constraint block, which is only applicable to CF3.

Finally, a trade study is executed which evaluates each proposed architecture

against the Objective Function(s) for each requirements set. The parametric diagram in

Figure 18 delineates the caparison of architecture candidates against multiple

requirements set as a unified trade space to select the most appropriate design

solution. Each requirement set constrains a constraint block which associated inputs

from the design such as InitialCost, Uncertainity, etc. … Each requirement set can then

evaluate its own Objective Function, with the ultimate Objective Function being a

comparison across multiple systems.

100

Figure 5.6-4. Lifetime Value Calculation Evaluates Multiple System Configurations Against Multiple Requirements Sets

This systematic approach to anticipated requirements extension allows

stakeholders to purposefully include or omit features to a baseline design, with

rationale and traceability behind the decision. The application framework supports an

iterative method such that as requirements are modified, original analysis can be re-

executed and augmented to reevaluate design alternatives.

6 Conclusions

This paper offers a framework which uses MBSE variant modeling techniques to

implement a trade study evaluation of design alternatives against a set of user

101

requirements. Mechanisms to vary structural and analytical characteristics of potential

design decisions support complex system trades. Benefits of this framework include:

- Current configuration of design decision

- Increased communication between system engineers for performance

simulation

- Explicit traceability between trade studies and requirements

- Potential for system engineering reuse (including models, hardware,

software and analysis tools).

Future applications leveraging modeling of variant architectures include

evaluation against multiple sets of requirements to support design for adaptability.

6.1 Contributions to the field

As new tools are developed, and further examples of explicit program

application emerge, this framework will provide a guideline for architecture analysis

through MBSE and Performance Simulation in the System Engineering user community.

This dissertation conglomerates the multitude of methodologies, standards and data

exchange mechanisms in a formal literature review. By highlighting the fundamental

benefits from MBSE versus traditional system engineering, this dissertation serves to

meet the desires of an INCOSE Vision 2020 as a transition to a modeling infrastructure.

Variability modeling is used to differentiate architectural variants. This allows for the

evaluation of multiple architectures against multiple sets of requirements. Using the

principles of ObjectiveFunctions, a top level trade study ObjectiveFunction defines the

102

inclusion of the evaluation of the variant architecture against potential requirements

derivations.

6.2 Recommendations for Future Work

Future extensions of this MBSE Architecture Framework include extending the

variability application to complex product line architectures. In this dissertation

variability is applied using a lightweight extension through profiles and extensions,

future work could include reusing the principles of this dissertation with an

implementation in a heavyweight extension to the SysML meta-model, such as through

CVL language. This dissertation applies variability to Design for Adaptability, using

Adaptability as a mechanism to drive the trade study. A formal method to determine

Adaptability in a system context would be beneficial to formalize the trade study criteria

103

Bibliography

[1] “Engineering Document Applications — From UML Models to XML Schemas,”

[2] International Council on Systems Engineering (INCOSE) Mid-Atlantic Regional Conference, 2004. https://www.incose.org/so-md/archives/ChapterMeetings/2004/2004NovTrade%20Study%20Brief%20-%20AFelix.pdf.

[3] Abbors, F., Backlund, A., and Truscan, D., “MATERA-an integrated framework for model-based testing,” 2010. In Engineering of Computer Based Systems (ECBS), 2010 17th IEEE International Conference and Workshops on, 321‐328.

[4] Ambler, S., A Manager’s Introduction to The Rational Unified Process (RUP), 2005. http://www.ambysoft.com/downloads/managersIntroToRUP.pdf.

[5] Andersson, H., Herzog, E., Johansson, G., and Johansson, O., “Experience from introducing Unified Modeling Language/Systems Modeling Language at Saab Aerosystems,” Systems Engineering, vol. 13, no. 4, pp. 369‐380, 2010.

[6] Ashum, D., Architecture Frameworks Overview, 2011. http://www.sdincose.org/wp-content/uploads/2011/05/Architecture_Overview.pdf.

[7] Axelsson, J., “Model based systems engineering using a continuous-time extension of the Unified Modeling Language (UML),” Systems Engineering, vol. 5, no. 3, pp. 165‐179, 2002.

[8] Bahill, A. and Szidarovszky, F., “Comparison of dynamic system modeling methods,” Systems Engineering, vol. 12, no. 3, pp. 183‐200, 2009.

[9] Bak, K., “Exemplar of Automotive Architecture with Variability,” http://gp.uwaterloo.ca/sites/default/files/cs746report.pdf.

[10] Batarseh, O. and McGinnis, L., Model-based Manufacturing Engineering System: SysML to Simulation Analysis Model: Georgia Tech MBSE Center, 2011. http://www.pslm.gatech.edu/events/frontiers2011/P1_Batarseh.pdf.

[11] Bayer, T., Bennett, M., Delp, C., Dvorak, D., Jenkins, J., and Mandutianu, S., “Update-concept of operations for Integrated Model-Centric Engineering at JPL,” 2011. In Aerospace Conference, 2011 IEEE, 1‐15.

[12] Belategi, L., Sagardui, G., Agirre, J., and Etxeberria, L., “Variability Issues in MARTE for SPL Model Analysis,”

[13] Belategi, L., Sagardui, G., and Etxeberria, L., “Variability Management in Embedded Product Line Analysis,” 2010. In Advances in System Testing and Validation Lifecycle (VALID), 2010 Second International Conference on, 69‐74.

[14] Bershad, B., Fiuczynski, M., Savage, S., Becker, D., Pardyak, P., Chambers, C., and Sirer, E. E. S., “Extensibility, Safety and Performance in the SPIN Operating System,”

104

University of Washington, Dept of Computer Science and Engineering, 2011. http://www.cs.ucr.edu/~harsha/teaching/Winter2011/CS202/readings/spin.pdf.

[15] Blackburn, M. R., What’s Model Driven Engineering (MDE) and How Can it Impact Process, People, Tools and Productivity: Systems and Software Consortium, 2008. http://www.knowledgebytes.net/downloads/Whats_MDE_and_How_Can_it_Impact_me.pdf.

[16] Bock, C., “SysML and UML 2 support for activity modeling,” Systems Engineering, vol. 9, no. 2, pp. 160‐186, 2006.

[17] Booth, S., System Engineering & Architectuing with CORE. INCOSE WMA Chapter Meeting, 2008. http://www.incose.org/wma/library/docs/INCOSE_WMA.080408.01.pdf.

[18] Bouquet, F., Gauthier, J.-M., Hammad, A., and Peureux, F., eds., Transformation of SysML Structure Diagrams to VHDL-AMS, 2012. http://doi.ieeecomputersociety.org/10.1109/dMEMS.2012.12.

[19] Bourell, D., “Decision matrices in materials selection: Decisin matrices in materials selection,” ASM International, vol. 20, pp. 291–296, 1997. http://products.asminternational.org.proxygw.wrlc.org/hbk/do/section/content/V20/D04/A05/S0065730.html?highlight=false.

[20] Bragge, J., Korhonen, P., Wallenius, H., and Wallenius, J., “Bibliometric analysis of multiple criteria decision making/multiattribute utility theory,” Multiple criteria decision making for sustainable energy and transportation systems, pp. 259‐268, 2010.

[21] Bühne, S., Lauenroth, K., and Pohl, K., “Why is it not sufficient to model requirements variability with feature models,” 2004. In Proceedings of Workshop: Automotive Requirements Engineering (AURE04). IEEE Computer Society Press, Los Alamitos, CA, USA, 60‐61.

[22] Cardei, I., Fonoage, M., and Shankar, R., “Framework for Requirements-Driven System Design Automation,” 2007. In Systems Conference, 2007 1st Annual IEEE, 1‐7.

[23] Chen, L., Ali Babar, M., and Ali, N., “Variability management in software product lines: a systematic review,” 2009. In Proceedings of the 13th International Software Product Line Conference, 81‐90.

[24] Chung, L. and Subramanian, N., “Adaptable architecture generation for embedded systems,” Journal of Systems and Software, vol. 71, no. 3, pp. 271–295, 2004.

[25] Czarnecki, K. and Antkiewicz, M., “Mapping features to models: A template approach based on superimposed variants,” 2005. In Generative Programming and Component Engineering, 422‐437.

[26] Czarnecki, K. and Helsen, S., “Feature-based survey of model transformation approaches,” IBM Systems Journal, vol. 45, no. 3, pp. 621‐645, 2006.

105

[27] Decision Lens, Analytical Approach to Trade Study Decisions. http://www.decisionlens.com/docs/WP_Analytic_Approach_to_Trade_Study_Decisions.pdf.

[28] Delp, C., “FireSAT: Model vs Documents Alone,”

[29] Dingel, J., CISC836: Models in Software Development: Methods, Techniques and Tools, 2009. http://research.cs.queensu.ca/~dingel/cisc836_F09/readings/slides/transformSWModels_4up.pdf.

[30] Dori, D., Object-process methodology: a holistics systems paradigm: Springer Verlag, 2002.

[31] Dori, D., “Object-Process Methodology for Structure-Behavior Co-Design,” 2011. In Handbook of Conceptual Modeling, ed. David W. Embley and Bernhard Thalheim, 209–58: Springer Berlin Heidelberg. http://dx.doi.org/10.1007/978-3-642-15865-0_7.

[32] Dube, M. and Dixit S.K., “Modeling Theories and Model Transformation Scenerio for Complex System Development,” International Journal of Computer Applications, vol. 38, no. 7, 2012. http://research.ijcaonline.org/volume38/number7/pxc3876847.pdf.

[33] Dubois, H., Ibanez, V., Lopez, C., and Machrouh, The product line engineering approach in a model-driven proces. http://www.erts2012.org/Site/0P2RUC89/6C-2.pdf.

[34] Engel, A. and Browning, T. R., “Designing systems for adaptability by means of architecture options,” Syst. Engin, vol. 11, no. 2, pp. 125–146, 2008.

[35] Estefan, J., “Survey of model-based systems engineering (MBSE) methodologies,” Incose MBSE Focus Group, vol. 25, 2007.

[36] Fisher, G., “Model-based systems engineering of automotive systems,” 1998. In Digital Avionics Systems Conference, 1998. Proceedings., 17th DASC. The AIAA/IEEE/SAE, B15/1 -B15/7 vol.1.

[37] Fitch, P. and Cooper, J., “Life-cycle modeling for adaptive and variant design. Part 1: Methodology,” Research in Engineering Design, vol. 15, no. 4, pp. 216‐228, 2005.

[38] Franzini, P., “A Model Driven Approach to the Development of the Controller for an Unmanned All-Terrain Vehicle,” Politencnion Di Milano, 2007.

[39] Friedenthal, S., Moore, A., and Steiner, R., “OMG Systems Modeling Language (OMG SysML) Tutorial,” 2006. In INCOSE Intl. Symp, ed. INCOSE.

[40] Friedenthal, S., Moore, A., and Steiner, R., A practical guide to SysML: the systems modeling language: Morgan Kaufmann Pub, 2012.

[41] Gorton, I. and Zhu, L., “Model-Driven Architecture,” 2011. In Essential Software Architecture, 201–17: Springer Berlin Heidelberg. http://dx.doi.org/10.1007/978-3-642-19176-3_14.

[42] Gouyette, M. B. O. and Noir Jerome Le, “Managing variability in multi-views engineering: A live demo,” 2010. http://hal.inria.fr/inria-00538466.

106

[43] Grady, J., “Universal architecture description framework,” Systems Engineering, vol. 12, no. 2, pp. 91‐116, 2009.

[44] Grobshtein, Y. and Dori, D., “Generating SysML views from an OPM model: Design and evaluation,” Systems Engineering, 2011.

[45] Gu, P., Xue, D., and Nee, A. Y., “Adaptable design: concepts, methods, and applications,” Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, vol. 223, no. 11, pp. 1367‐1387, 2009.

[46] Halim, S. A., Zaki, M., Zulkifli, M., Ibrahim, N., Jawawi, D., and Deris, S., “Mapping Architectural Concepts to SysML Profile for Product Line Architecture Modeling,” 2011. In ICSEA 2011, The Sixth International Conference on Software Engineering Advances, 510‐514.

[47] Halim, S., Jawawi, D., and Deris, S., “Requirements Identification and Representation in Software Product Line,” 2009. In Software Engineering Conference, 2009. APSEC’09. Asia-Pacific, 340‐346.

[48] Hardy, D., “Model Based Systems Engineering and How it Aids DoD Acquisition & Systems Engineering,” 2006.

[49] Haugen, Ø., Standardizing Variability – The process towards CVL – a Common Variability Language, 2010. http://modelingwizards.isti.cnr.it/wp-content/uploads/2010/10/ModWizards-Haugen-CVL-101002-v2.pdf.

[50] Haugen, Ø., Moller-Pedersen, B., Oldevik, J., Olsen, G., and Svendsen, A., “Adding standardized variability to domain specific languages,” 2008. In Software Product Line Conference, 2008. SPLC’08. 12th International, 139‐148.

[51] Hause, M., ed., The Unified Profile for DoDAF/MODAF (UPDM) enabling systems of systems on many levels, 2010.

[52] Haywood, D., MDA in a Nutshell, 2004. http://www.theserverside.com/news/1365166/MDA-Nice-idea-shame-about-the (accessed February 24, 2012).

[53] Hoffmann, H.-P., “Harmony/SE: A SysML Based Systems Engineering Process,” In Innovation 2008: Telelogic User Group Conference. http://download-na.telelogic.com/download/ugcagenda/Mon_HarmonySEASysMLBasedSystemsEngineering_PeterHoffman.pdf.

[54] Hoffmann, H.-P., SysML-Based Systems Engineering Using a Model-Driven Development Approach, 2008. http://www.swd.ru/files/share/Rhapsody/materials/Whitepapers/MDD_WP_SysMLBasedSEUsingMDD_FINAL_080707.pdf.

[55] Hoffmann, H.-P., Systems Engineering Best Practices with teh Rational Solution for Systems and Software Engineering: Deskbook Release 3.1.2, 2011. http://www-01.ibm.com/support/docview.wss?uid=swg27023356&aid=1.

107

[56] Howland, P., “FM radio based bistatic radar,” Radar, Sonar and Navigation, IEE Proceedings, vol. 152, 2005. http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1459145&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F2198%2F31424%2F01459145.pdf.

[57] IBM, Rational Unified Process: Best Practices for Software Development Teams: TP026B, 11/01. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf.

[58] 1471-2000. IEEE Recommended Practice for Architectural Description for Software-Intensive Systems. http://standards.ieee.org/findstds/standard/1471-2000.html.

[59] IEEE, ed., A SIMPLE EXAMPLE OF SYSML-DRIVEN SIMULATION, 2009. http://www.informs-sim.org/wsc09papers/161.pdf.

[60] INCOSE, System Engineering Handbook v3, 2010. http://www.incose.org/ProductsPubs/products/sehandbook.aspx.

[61] INCOSE MBSE Challenge Team, SysML for Telescope System Modeling - Variant Modelling.

[62] Ingham, M. and Rasmussen, R., State Analysis for System Engineers: Model-Based Systems Engineering, State Analysis for Systems Engineer Course, 2008. https://pub-lib.jpl.nasa.gov/docushare/dsweb/View/Collection-91.

[63] 1303-1:1994. Industrial automation systems and integration -- Product data representation and exchange -- Part 1: Overview and fundamental principles. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=20579.

[64] 14040:2006. Life cycle assessment -- Principles and framework. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=37456.

[65] TC 184/SC 4. Industrial automation systems and integration -- Part 233: Systems engineering data representation. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55257.

[66] 19502:2005. Meta Object Facility (MOF). http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=32621.

[67] Jet Propulsion Laboratory, “Technology Mission Data System: MDS Architecture; State Analysis,” http://mds.jpl.nasa.gov/public/arch/.

[68] Johnson, T., “Integrating models and simulations of continuous dynamic system behavior into SysML,” 2008.

108

[69] Jouault, F., and Kurtev, I., eds., On the Architectural Alignment of ATL and QVT, APRIL 23-27.

[70] Kang, K., Cohen, S., Hess, J., Novak, W., and Peterson, A., “Feature-oriented domain analysis (FODA) feasibility study,” 1990.

[71] Kawahara, R., Nakamura, H., Dotan, D., Kirshin, A., Sakairi, T., Hirose, S., Ono, K., and Ishikawa, H., “Verification of embedded system’s specification using collaborative simulation of SysML and simulink models,” 2009. In Model-Based Systems Engineering, 2009. MBSE’09. International Conference on, 21‐28.

[72] Kerzhner, A., “Using Domain Specific Languages to Capture Design Knowledge for Model-Based Systems Engineering,” Master of Science in the School of Mechanical Engineering, Georgia Institute of Technology, 2009.

[73] Kerzhner, A. and Paredis, C., “Using domain specific languages to capture design synthesis knowledge for model-based systems engineering,” 2009. In ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference.

[74] Kossiakoff, A., and Sweet, W., eds., Systems Engineering Principles and Practice, 2nd ed., 2011. http://www.amazon.com/Systems-Engineering-Principles-Practice-Management/dp/0470405481/ref=sr_1_5?s=books&ie=UTF8&qid=1330146330&sr=1-5.

[75] Kurtev, I., Alignment of ATL and QVT.

[76] London, B., “A Model-Based Systems Engineering Framework for Concept Development,” 2012.

[77] Loomis, J., “Army Requirements for the 21st Century,” IEEE Trans. Ind. Inf, 2007.

[78] Malak, R. J., Tucker, L., and Paredis, C. J., “Composing tradeoff models for Multi-Attribute System-Level Decision Making,” 2008. In . ASME International Design Engineering Technical Conferences. New York, NY: American Society of Mechanical Engineers (ASME).

[79] Mischkalla, F., He, D., and Mueller, W., “Closing the gap between UML-based modeling, simulation and synthesis of combined HW/SW systems,” 2010. In Design, Automation & Test in Europe Conference & Exhibition (DATE), 2010, 1201‐1206.

[80] Mitchell, S., “Efficient Management of Configurations in teh ModelBased System Development of a Common Submarine Combate System,”

[81] Morin, B., Fleurey, F., Bencomo, N., Jézéquel, J., Solberg, A., Dehlen, V., and Blair, G., “An aspect-oriented and model-driven approach for managing dynamic variability,” Model Driven Engineering Languages and Systems, pp. 782‐796, 2008.

[82] Morin, B., Perrouin, G., Lahire, P., Barais, O., Vanwormhoudt, G., and Jézéquel, J., “Weaving variability into domain metamodels,” Model Driven Engineering Languages and Systems, pp. 690‐705, 2009.

109

[83] Morris, J., Ingham, M., Mishkin, A., Rasmussen, R., and Starbird, T., “Application of state analysis and goal-based operations to a MER mission scenario,” 2006. In Proceedings of SpaceOps 2006 Conference, Rome, Italy.

[84] Mrozek, Z., “Design of the mechatronic system with help of UML diagrams,” 2002. In Robot Motion and Control, 2002. RoMoCo’02. Proceedings of the Third International Workshop on, 243‐248.

[85] ODASD - Office of the Deputy Assistant Secretary of Defense, “Modular Open Systems Approach (MOSA),” http://www.acq.osd.mil/se/initiatives/init_mosa.html.

[86] Ogren, I., “Possible tailoring of the UML for systems engineering purposes,” Systems Engineering, vol. 3, no. 4, pp. 212‐224, 2000.

[87] Oliver, D., Andary, J., and Frisch, H., “Model-based systems engineering,” A. Sage and W. Rouse, Handbook of Systems Engineering and Management, Edition, vol. Second Edition, pp. 1361‐1400, 2009.

[88] OMG Adopted Specification; The Meta Object Facility (MOF) Core Specification. http://www.omg.org.

[89] Technical Guide to Model Driven Architecture: The MDA Guide. http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf.

[90] formal/2011-01-01. OMG Meta Object Facility (MOF) 2.0 Query/View/ Transformation Specification. http://www.omg.org/spec/QVT/1.1.

[91] formal/2012-01-03. Unified Profile for DoDAF and MODAF (UPDM). http://www.omg.org/spec/UPDM/2.0.

[92] OMG Systems Modeling Language (OMG SysML). http://www.omg.org/spec/SysML/1.2/.

[93] OMG Sysml, ed., OMG Systems Modeling Language (OMG SysML™) Tutorial: Tutorial, 2006.

[94] Osorio, C., Dori, D., and Sussman, J., “COIM: An object-process based method for analyzing architectures of complex, interconnected, large-scale socio-technical systems,” Systems Engineering, 2009.

[95] Palmer, J., Palumbo, S., van Cao, T.-T., and Howard, S., “A new Illuminator of Opportunity Bistatic Radar Research Project at DSTO: DSTO–TR–2269,” 2009 (accessed http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA506106).

[96] Paredis, C. and Johnson, T., “Using OMG’S SYSML to support simulation,” 2008. In Simulation Conference, 2008. WSC 2008. Winter, 2350‐2352.

[97] Patel, V., McGregor, J., and Goasguen, S., “SysML-based domain-specific executable workflows,” 2010. In Systems Conference, 2010 4th Annual IEEE, 505‐509.

[98] Peak, R., ed., Model-Based Systems Engineering (MBSE) Challenge Team Status Update. Pasedena, 2008.

110

[99] Pearce, P., and Hause, M., eds., ISO-15288, OOSEM and Model-Based Submarine Design, 2012.

[100] Peraire, C. e. a., The IBM Rational Unified Process for System z: IBM, 2007. http://www.redbooks.ibm.com/redbooks/pdfs/sg247362.pdf.

[101] Piaszczyk, C., “Model Based Systems Engineering with Department of Defense Architectural Framework,” Systems Engineering, 2011. http://dx.doi.org/10.1002/sys.20180.

[102] Pugh, S., “Total design: integrated methods for successful product development,” Total Design: Integrated Methods for Successful Product Development, 1991.

[103] Qamar, A., During, C., and Wikander, J., “Designing mechatronic systems, a model-based perspective, an attempt to achieve SysML-Matlab/Simulink model integration,” 2009. In Advanced Intelligent Mechatronics, 2009. AIM 2009. IEEE/ASME International Conference on, 1306‐1311.

[104] Quinlan, J., Systems, Man and Cybernetics, IEEE Transactions on, title=Decision trees and decision-making, vol. 20, no. 2, pp. 339–346, 1990.

[105] Raif, M., Walter, U., and Bouwmeester, J., “Dynamic system simulation of small satellite projects,” Acta Astronautica, vol. 67, no. 9-10, pp. 1138‐1156, 2010.

[106] Ramos, A., Ferreira, J., and Barcelo, J., “Model-Based Systems Engineering: An Emerging Approach for Modern Systems,” Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, vol. 42, no. 1, pp. 1‐11, 2011.

[107] Rasmussen, R., Ingham, M., and Dvorak, D., “Achieving Control and Interoperability Through Unified Model-Based Engineering and Software Engineering,” 2005. In AIAA Infotech at Aerospace Conference.

[108] Reichwein, A. and Paredis, C. J., “Overview of Architecture Frameworks and Modeling Languages for Model-Based Systems Engineering,” 2011. In Proc. ASME 2011 International Design Engineering Technical Conf. & Computers and Information in Engineering Conf.

[109] Santos, A., Koskimies, K., and Lopes, A., “A model-driven approach to variability management in product-line engineering,” Nordic Journal of Computing, vol. 13, no. 3, p. 196, 2006.

[110] Sanyal, A., Basu, S., and Choudhury, S., “A Requirement Framework for Automatic Generation of Domain Model to Physical Level Implementation,” International Journal of Computer Information Systems and Industrial Management Applications, vol. 3, 2011.

[111] SETAC (Society of Environmental Toxicology and Chemistry), “Guidelines for life cycle assessment: a code of practice.,” 1991. http://fr1.estis.net/builder/includes/page.asp?site=lcinit&page_id=54C71E3C-9814-4AD9-9089-F20446728DA3.

111

[112] Shah, A. A., Kerzhner, A., Schaefer, D., and Paredis, C , “Multi-View Modeling to Support Embedded Systems Engineering in SysML,” 2009. In . Lecture Notes in Computer Science: Springer.

[113] Sharon, A., Dori, D., and Weck, O. de, “Model-Based Design Structure Matrix: Deriving a DSM from an Object-Process Model,” 2009. In.

[114] Soares, M. and Vrancken, J., “Model-driven user requirements specification using SysML,” Journal of software, vol. 3, no. 6, pp. 57–68, 2008.

[115] Spangelo, S., Kaslow, D., Delp, C., Cole, B., Anderson, L., Fosse, E., Gilbert, B. et al., “Applying Model Based Systems Engineering (MBSE) to a Standard CubeSat,” http://www.omgsysml.org/Applying_MBSE_to_a_Standard_CubeSat-Space_Systems_Challenge_Team.pdf.

[116] Spiby, P. P., STEP AP233: Systems Engineering: Eurostep. http://www2.pdteurope.com/media/54159/1b.%20step%20ap233%20systems%20engineering.pdf (accessed 01.28.2012).

[117] Stevens, P., XMI and MOF a mini-tutorial. Edinburgh: University of Edinburgh. http://homepages.inf.ed.ac.uk/perdita/XMI/tutslides2up.pdf (accessed 02.14.2012).

[118] STURM, A., DORI, D. O., and SHEHORY, O. N., “THE APPLICATION-BASED DOMAIN ANALYSIS APPROACH AND ITS OBJECT-PROCESS METHODOLOGY IMPLEMENTATION,” International Journal of Software Engineering & Knowledge Engineering, vol. 18, no. 8, pp. 1115–1142, 2008. http://proxygw.wrlc.org/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=a9h&AN=36849600&site=ehost-live.

[119] Svendsen, A., Haugen, Ø., and Moller-Pedersen, B., “Using Variability Models to Reduce Verification Effort of Train Station Models,” 2011. In Software Engineering Conference (APSEC), 2011 18th Asia Pacific, 348‐356.

[120] SysML v1.4 Revision Task Force, Issue 14827:Streamlined notation for representing system variance. http://www.omg.org/issues/sysml-rtf.open.html.

[121] Tapke, J., Muller, A., Johnson, G., and Sieck, J., “House of Quality: Steps in Understanding the House of Quality,” vol. IE361rh. http://www.public.iastate.edu/~vardeman/IE361/f01mini/johnson.pdf.

[122] Technical Operations, SYSTEMS ENGINEERING VISION 2020: INCOSE-TP-2004-004-02, 2007.

[123] Tessier, P., Servat, D., and Gérard, S., “Variability management on behavioral models,” 2008. In VaMoS Workshop, 121‐130.

[124] The Eclipse Foundation, ATL/User Guide - Overview of the Atlas Transformation Language, 2012. http://wiki.eclipse.org/ATL/User_Guide_-_Overview_of_the_Atlas_Transformation_Language.

112

[125] Thomas L. Saaty, “How to make a decision: The analytic hierarchy process,” European Journal of Operational Research, vol. 48, no. 1, pp. 9–26, 1990. http://www.sciencedirect.com/science/article/pii/037722179090057I.

[126] Ullman, D. and Spiegel, B., “Trade studies with uncertain information,” 2006. In Sixteenth Annual International Symposium of the International Council On Systems Engineering (INCOSE).

[127] PLM for the US Army, 2005. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.marc.gatech.edu%2Fevents%2Fpde2005%2Fpresentations%2F7.3-iyer.ppt&ei=_RtvUJy8F8P30gGU9oHYCA&usg=AFQjCNHEQ_Cb3ixYKOkimi4TkjH1jk3iUQ.

[128] DoD Architectural Framework V1.5. http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_I.pdf.

[129] DoD Architecture Framework Version 2.0. http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF%20V2%20-%20Volume%201.pdf.

[130] Vitech, Integrated Model-based Systems Engineering for Project Success - CORE slick, 2012. http://www.vitechcorp.com/products/files/core4pageslick.pdf.

[131] Wagner, D., Bennett, M. B., Karban, R., Rouquette, N., Jenkins, S., and Ingham, M., “An ontology for State Analysis: Formalizing the mapping to SysML,” 2012. In Aerospace Conference, 2012 IEEE, 1‐16.

[132] Wasek, J., “Mapping system capabilities to requirements and performance metrics for capabilities-based acquisitions: DoD applications,” DSc, George Washington University, 2006.

[133] Wei, C. and Change, W., “System Level Investigations of Television Based Bistatic Radar,” Masters, 2005.

[134] White, S., “Modeling a system of systems to analyze requirements,” 2009. In Systems Conference, 2009 3rd Annual IEEE, 83‐89.

[135] Ziadi, T., Hélouët, L., and Jézéquel, J., “Towards a UML profile for software product lines,” Software Product-Family Engineering.