• Aucun résultat trouvé

Concept of operations and the DoD architecture framework

N/A
N/A
Protected

Academic year: 2021

Partager "Concept of operations and the DoD architecture framework"

Copied!
87
0
0

Texte intégral

(1)

Concept of Operations and the DoD Architecture

Framework

by

Nicholas K. James

Submitted to the Department of Aeronautics and Astronautics

in partial fulfillment of the requirements for the degree of

Master of Science in Aeronautics and Astronautics

at the

MASSACHUSETTS INSTITUTE OF TECHNOLOGY

June 2018

@

Massachusetts Institute of Technology 2018. All rights reserved.

Signature redacted

A uthor ...

Department of Aeronautics and Astronautics

May 24, 2018

Certified by ...

Signature redacted

EdvzEU1. Crawley

Professor of Aeronautics and Astronautics

Thesis Supervisor

Accepted by...

JUN

28

2018

LIBRARIES

Signature redacted

Hamsa Balakrishnan

Associate Professor of Aeronautics and Astronautics

Chair, Graduate Program Committee

(2)
(3)

Concept of Operations and the DoD Architecture Framework

by

Nicholas K. James

Submitted to the Department of Aeronautics and Astronautics on May 24, 2018, in partial fulfillment of the

requirements for the degree of

Master of Science in Aeronautics and Astronautics

Abstract

This thesis presents a framework for Concept of Operations (ConOps), based on the standards for capturing operations used in the government and industry. An understanding of operations early in system design is critical to the development of effective, successful systems. The current standards for Operational Concepts and the Operational Viewpoint of the Department of Defense Architecture Framework (DoDAF) outline lengthy descriptions that are cumbersome in the early stages of a system's development. The DoDAF Operational Viewpoint was analyzed in depth to distill the important information relevant to operations. This information was built into the System Architecture framework as a bottom-up approach of coordinating the operations of architecture, operators, and context in order to meet system goals. The resulting ConOps definition and framework was then compared against DoDAF Operational Viewpoint diagram samples in a Search and Rescue system case study, in order to validate the framework. The study found that the framework provides a shorter description with more clarity than the DoDAF diagrams.

Thesis Supervisor: Edward F. Crawley

(4)
(5)

Acknowledgments

I would like to thank my advior, Edward F. Crawley, Ford Professor of Engineering

at MIT and Founding President of Skoltech. Ed tirelessly guided me in the field of systems architecture, which I had no experience or prior knowledge of, and taught me how to think in terms of systems. He has been endlessly patient with me, and is an excellent mentor in professional and informal settings. It's been wonderful working with him, and I'm going to miss hearing stories about his fascinating life.

The cadre of AFROTC Det 365, especially Lt Col Sheryl "Double" Ott, Capt Peterson Dela Cruz, and TSgt Jason Spon, were immensely helpful in my development as a leader, and my pursuit of this opportunity at MIT. I wish them all the best, and will keep in touch!

Martin York and John Graham blazed the trail that I followed in taking this fifth year as a graduate student, and I would not have been able to do it without them. I am grateful for their mentorship and friendship over the years, and look forward to joining them in Texas next year!

I was incredibly lucky to have such a great network of friends, throughout my fraternity, the AeroAstro department, Det 365, and all my office mates in 33-409. Nick Villanueva toiled away with me into the wee hours of the morning, and was consistently there to bounce ideas off of, vent to, and blow off steam with. Kirsty Cullinan could always cheer me up and give me the motivation I needed to keep going. Last, I would like to thank my family for supporting me, developing me, and understanding when I had to stay in Boston over breaks to keep working. I promise

(6)
(7)

Contents

1 Introduction

1.1 M otivation . . . . 1.2 Literature review . . . . 1.2.1 System Architecture . . . . 1.2.2 Concept of Operations and Operational Concept .

1.2.3 Department of Defense Architecture Framework .

1.3 Specific thesis objectives . . . . 1.4 Thesis overview . . . .

2 Analysis of DoDAF Operational Viewpoint

2.1 Introduction to the Operational Viewpoint . . . . 2.2 Individual diagram analysis . . . .

2.2.1 OV-1: High-Level Operational Concept Graphic 2.2.2 OV-2: Operational Resource Flow Description .

2.2.3 OV-3: Operational Resource Flow Matrix . . . .

2.2.4 OV-4: Organizational Relationships Chart . . . .

2.2.5 OV-5a: Operational Activity Decomposition Tree

2.2.6 OV-5b: Operational Activity Model . . . . 2.2.7 OV-6a: Operational Rules Model . . . .

2.2.8 OV-6b: State Transition Description . . . . 2.2.9 OV-6c: Event-Trace Description . . . .

2.3 Sum m ary . . . . 13 . . . . 13 . . . . 15 . . . . 15 . . . . 20 . . . . 22 . . . . 26 . . . . 27 29 . . . . 29 . . . . 33 . . . . 33 . . . . 36 . . . . 39 . . . . 41 . . . . 42 . . . . 46 . . . . 47 . . . . 49 . . . . 53 . . . . 55

(8)

3 Development of ConOps Framework 59

3.1 Operational Viewpoint information content ... 59

3.1.1 Overlap within the Operational Viewpoint . . . . 59

3.1.2 Operations versus architecture . . . . 63

3.1.3 Summary of results . . . . 64

3.2 Defining and capturing ConOps . . . . 65

3.2.1 ConOps framework . . . . 66

4 ConOps Case Study: Search and Rescue 71 4.1 Textual SAR ConOps . . . . 72

4.2 Depicting SAR ConOps . . . . 73

4.2.1 Recommended depiction . . . . 73

4.2.2 DoDAF depiction . . . . 74

4.2.3 D iscussion . . . . 78

5 Conclusion 81 5.1 Summary and main findings . . . . 81

(9)

List of Figures

1-1

1-2

1-3

Basic OPM Elements ... OPM Relationships ... Simple OPD Example ... 2-1 DoDAF Operational Viewp

2-2 DoDAF Operational Viewp

2-3 "Complete" OV-1 Sample 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 2-15 2-16 2-17 2-18 int- CPD oint OPI . . . .

with Sample Info.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . Annotations

Sparse OV-1 Sample . . . .

OPD of "Complete" OV-2 Elements OPD of Minimum OV-2 Elements . OV-2 Sample ...

OPD of OV-3 Elements ...

OV-3 Sample ...

OPD of OV-4 Elements ... OV-4 Sample ...

OPD of OV-5a Elements ... OV-5a Sample ... OPD of OV-5b Elements ... OV-5b Sample ...

OV-6a Sample ...

Pictorial OV-6a Sample

OPD of OV-6b Elements (A lternativ

2-19 OPD of OV-6b Elements (Alternative 2)

18 19 20 31 32 34 35 37 37 38 40 41 42 43 44 45 46 47 49 50 51 52 (A

(10)

2-20 2-21 2-22 2-23 3-1 3-2 3-3 3-4 OV-6b Sample ...

OPD of OV-6c Elements ...

Flowchart OV-6c Sample . . . . Sequence Diagram OV-6c Sample . . . .

Count of Appearances of Elements in OPDs OPD of Systems Viewpoint -1 Elements . . OPD of ConOps Elements . . . . ConOps Framework . . . . 52 54 55 56 60 64 67 69

(11)

List of Tables

1.1 Standards for Operational Concept Documents/Descriptions . . . . . 23 3.1 Operational Viewpoint Sample Summary Table . . . . 61 3.2 Operational Viewpoint Samples Cross Analysis . . . . 62

(12)
(13)

Chapter 1

Introduction

1.1

Motivation

The idea of operations, or the process of producing an effect, is important and complex enough that an entire field of study, Operations Research (OR), has been built around it. Although the practice has been around for as long as humans have applied science to the organization and management of systems, it only became a named field as recently as World War II, when the British government organized a team that included scientists to advise military leaders on how to employ new radar technology most effectively

133].

The term Operations Research was originally used to distinguish this application from the technical research being done on understanding and improving radar itself [33].

Since then, the domain of OR has been expanded, unified, and codified into a field that "uses indeed quantitative techniques to make and prepare decisions, by deter-mining the most efficient way to act under given circumstances" [16]. The research makes impacts in areas as varied as energy, finance, health care, marketing, and trans-portation [22]. Similarly to how engineering can be thought of as the application of scientific principles to build systems, OR applies scientific methods to organize and manage systems.

There are plentiful examples of well designed systems being improperly or in-efficiently operated. One example of this is the Concorde Supersonic Transport, a

(14)

supersonic passenger aircraft that was flown commercially from 1976 to 2003 [7]. Al-though the aircraft itself met the engineering requirements defined for it and was well built, the aircraft did not succeed in making a profit [7]. An analysis of its operations early on in the process could have set expectations for the operating costs, which would subsequently set some requirements for the design of the aircraft. This exam-ple also hints that operations are relevant to the idea of system validation, which goes beyond verification (satisfying engineering requirements) to determine if the system satisfies the needs of stakeholders.

An example of the impact of OR closer to home is a city power grid. When a person turns on a light, they expect that there will be electricity to power it. However, power plants do not supply a constant amount of power at all times. Rather, they adjust their power production throughout the day and year to meet expected needs [23J. The optimization of this system is non-trivial, and includes factors such maximum plant capacity, individual unit capacities, likelihood and impact of equipment failures and other outages, etc.

1231.

Building power plants that are optimized for efficiency, while also never failing to provide the necessary power, falls within the scope of OR. The question becomes, can the operational considerations from the OR domain be considered during the design process, to produce systems that are already tailored to their operational context? Research shows that as a complex system progresses through its lifecycle, the cost of fixing errors in the system grows exponentially [30].

A similar increase can be assumed to apply to changing a system to better suit its

operational environment. Thus, the earlier that a system's operational context can be understood, the easier and less expensive it will be to tailor it to function efficiently, and the more likely the project will be a success. If the operations of a system can be modeled during the development of a system architecture, then it will have the greatest impact on creating a successful system.

In general, the purpose of this thesis is to determine how operations can be framed and modeled early in the design process to be used as a tool in designing, simulating, and building a successful system.

(15)

1.2

Literature review

In order to build a framework for operations, it is important to determine where the framework should fit in to the design process, and how system operations are currently captured. The domain of System Architecture will be discussed first, to introduce the framework and terminology that will persist throughout the remainder of the thesis. That discussion will also include an introduction to the Object-Process Methodology sometimes used to model architecture. This review will then delve into the literature related to Concept of Operations (and Operational Concepts), followed

by a specific introduction to the Department of Defense Architecture Framework.

1.2.1

System Architecture

The idea of architecting has ancient origins, dating back to thousands of years to

Egypt and Rome [261. The concept of architecture has expanded beyond buildings to

encompass the fundamental structure of any thing; simple circuits, algorithms, space-craft, human teams, and transportation systems all have architectures. Architectures consist of abstractions of the elements of a system and their relationships [111.

The merging of architecture and systems has been spurred on in the past few decades by several factors, including an increase in system complexity and scope, the introduction of computers into systems, and the use of models and simulations in the design process

1261.

System Architecture, as the domain is formally called in modern times, is gaining recognition, with over 100,000 professionals using the title "system architect" 111]. Similarly to System Engineering, System Architecting focuses on managing complexity in a system and organizing its components to achieve a goal beyond that of the sum of its parts [11]. A formal definition of System Architecture is proposed by Crawley et. al.:

System Architecture is the embodiment of concept, the allocation of physical/informational function to the elements of form, and the def-inition of relationships among the elements and with the surrounding

(16)

The fundamental elements of architectures, highlighted in the definition above, are: concept, function, form, relationships, and context. An introduction to these elements follows, but Crawley et. al. provide detailed descriptions in reference [11].

In general, a concept is vision, idea, notion or mental image that maps one set of ideas to another, and supports larger cognitive transitions [111. As such, an ar-chitectural concept is not meant to be a complete model of a system, but rather a simplification of the architecture that allows for high-level reasoning [111. It is an intermediate step in linking the goals of a system to the system architecture.

Form refers to the elements that compose a system and their relationships. These elements need not be strictly physical: for example, the form associated with an al-gorithm would be the lines of code. Many types of relationships can exist between these elements of form. The predominant relationships are spatial/topological, which describe where the elements are relative to one another, and connectivity, which de-scribe how different elements are joined to each other. For example, a vehicle wheel is underneath the vehicle (spatial), and is connected mechanically to the vehicle's axle (connectivity). Other relationships can include membership to a group or class, se-quence, and interpersonal human relationships. Another term for form is instrument, which specifically refers to an element of a system that performs processes.

Function is the combination of process and operand. Operands are the objects that are produced, consumed, or modified by processes. In other words, they are what processes act on. Processes are what happens, entirely independent of form and operand. In this framework, processes are usually stated as verbs ending in "-ing" Elements can also be related via functional relationships, which refer to processes transferring, exchanging, or jointly acting on operands.

Context describes everything relevant to a system, but outside of the system boundary. One strategy for defining the system boundary is to ensure that, when systems in the context intrude on the system, the intrusions can be accommodated without breaking the system [26]. Everything that would break the system is thus included within the boundary. Formal and functional relationships can cross the system boundary into the context.

(17)

Object-Process Methodology

There are several tools that are commonly used to model architectures, including Uni-fied Modeling Language (UML), System Modeling Language (SySML), and Object-Process Methodology (OPM). This thesis will primarily use OPM for architecture modeling, so an introduction to OPM and its notation follows. This introduction provides information on the aspects being used in this thesis, but for more informa-tion refer to reference 115].

OPM was created to be a simple method for modeling complex systems, whether it be during the design of a system or modeling an existing system for understanding or improvement. Dov Dori's philosophy in creating OPM was that systems are complex enough, so a modeling methodology should be as simple as possible while capturing the essential aspects of a system. These aspects were determined to be: function (what a system does), structure (composition and relationships of the system), and behavior (system change over time). OPM was designed to be abstract enough that it can be applied to any domain.

OPM conveys system information through Object-Process Diagrams (OPDs) and Object-Process Language (OPL), in order to appeal to different parts of the brain. These two representations have specified rules relating one to the other. OPL is written in plain English for ease of understanding. The content of this thesis focuses on OPDs, the elements of which are described below.

As shown in Figure 1-1-a, OPDs represent processes as blue-outlined ovals, and ob-jects (form, operands, agents, and organizations) as green-outlined rectangles. Events are not specified entities in OPM, but they are used in this thesis and will be shown in blue-outlined rectangles tapered to a point on the right side. The definition of event used here is a combination of those used in DoDAF and SySML: the instantaneous receipt of an operand (either physical or informational), often from another system [12, 181.

Figure 1-1-b depicts an Exhibition-Characterization relationship between an ob-ject and an attribute. This type of relationship can provide additional details about

(18)

Object Process

objct

EntAttribute Sub Sub

Process Process

a) OPM Building b)

Exhibition-Blocks Characterization c) Aggregation-Participation Relationship Relationship

Figure 1-1: Depicts the building blocks and two essential relationships of OPM, and their representation in OPDs

an object or process by depicting a feature that is important to the system, or is affected by a process. Features, specifically called attributes and operations, are spe-cial instances of either objects or processes respectively, and are depicted in the same manner of their counterparts. Either type of feature can be used to describe objects and processes, and they characterize what they are connected to. For example, the object Printer could have the attribute Black and White, and an operation Printing, since both of these features characterize a printer. The convention is for the triangle to point toward the object or process being described, as shown.

Figure 1-1-c shows an Aggregation-Participation relationship between processes. This relationship is used as a way of decomposing either processes or objects. This relationship can only connect elements of the same type, i.e. a process cannot decom-pose into objects. The convention is for the arrow to point toward the higher-level object or process. Objects and processes can also be nested within higher level objects or processes, but that notation is not used in this thesis.

Other types of relationships used in this thesis are shown in Figure 2. Figure 1-2-a shows the three fundamental relationships between processes and operands, which are (from top to bottom): consumption, modification, and production. Modifications can also be shown by connecting processes to operand attributes.

Figure 1-2-b depicts the other three OPM relationships used in this thesis. The top relationship is an operator/instrument link. Operators and instruments are both

(19)

Proces E Operand peato

ProcessOperand Object Object

Procei " ~OperandPrcsPoes

a) Process-Operand Relationships b) Other Relationships

Figure 1-2: a) Depicts the three Process-Operand relationships used in OPM: (top to bottom) consumption, modification, and production. b) Shows three other important OPM relationships used in this thesis: (top to bottom) operator/instrument link, structural link, and invocation link

performers, with the former referring to a person or organization capable of indepen-dent thought and action, and the latter referring to an element of form. For example, for the process of writing, the operator would be the writer, and the instrument would be a pencil or pen. The OPM documentation actually specifies that instrument links use open circles, but for the purpose of this thesis, all performer links will be shown with closed circles.

The middle relationship in Figure 1-2-b is a structural link. It typically connects objects, and can connect processes, but not between the two types. Structural links are used to show spatial/topological relationships, organizational relationships, or relationships other than those specified elsewhere. The arrow can be double-headed, showing a mutual relationship, or single-headed, showing a one-way relationship.

The bottom part of Figure 1-2-b depicts an invocation relationship. This is used to depict that one process follows another, while repressing the operand that is passed between them. Note that in this framework it is assumed that processes are always triggered by the transfer of an operand, whether that be a signal, physical mass flow, or any other object.

(20)

Salt, water, flour, yeast Mixing Mixer I Dough Baking Oven Bread Slicing Cutter System Boundary Slices

Figure 1-3: Depicts a simple OPD for a sliced-bread-making system [11]. It shows the flow of operands from top to bottom, and the performer-process-operand convention from right to left.

[111. The two-dimensional arrangement of elements in this system is used to

con-vey the conventional performer-function (performer-process-operand) structure. More complicated systems are not expected to be arranged in this way. None of the re-lationships are constrained in number, i.e. a process can have multiple performers, an instrument or operator can be the performer of multiple processes, a process can consume, create, or modify multiple operands, etc.

Note that the inputs (salt, water, flour, yeast) and the outputs (slices) are passed across the system boundary. The accompanying systems (not shown) that produce the inputs and consume the outputs are in the context, not the system. What is shown is the concept of a sliced-bread-making system.

1.2.2

Concept of Operations and Operational Concept

Having reviewed the concepts of architecture, System Architecture, and Object-Process Methodology, the question becomes: how does the understanding of

(21)

oper-ations fit into the picture? A logical starting point is looking into Concept of Opera-tions (ConOps).

ConOps is a widely used tool in engineering to depict how a system is used, or expected to be used, in practice. Various definitions exist throughout literature:

The concept of operations sketches out how the system will operate: who will operate it, when, and coordinated with what else [11]

[ConOps] describes how the system will be operated during life-cycle phases to meet stakeholder expectations. It describes the system char-acteristics from an operational perspective and helps facilitate an under-standing of the system goals.

[..

.

It stimulates the development of the requirements and architecture related to the user elements of the system. [241

A verbal and graphic statement of an enterprise's assumptions or intent

in regard to an operation or series of operations of a system or a related set of systems. The operational concept is frequently developed as part of a system development or acquisition program. The operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the enterprise's operational environment from the users' and operators' perspective. [35]

Note that the last of those definitions is actually for Operational Concept (Op-sCon) rather than ConOps. It was presented next to a definition for ConOps that referred to a strategic plan for the operations of an organization or enterprise, rather than of a designed system, which is what this thesis is interested in. This demon-strates that there is a lack of consensus on even the terminology of ConOps/OpsCon. In general, the difference is just in preferred terminology, and this thesis will continue to use ConOps except when discussing sources that explicitly use OpsCon.

With the exception of the inconsistent terminology, the definitions presented above share some common threads. All three specifically include references to the user or

(22)

operator of a system, and they all focus on depicting how the system is operated. Two of them mention context or environment, but only one mentions sequence or timing. Beyond these commonalities, the definitions offer no rigorous definition of what should be included in ConOps, at what scope, and with what focus.

The search for standards regarding ConOps continued into the evaluation of lit-erature discussing OpsCon. Table 1.1 lists the elements specified by the Depart-ment of Defense, IEEE, and ANSI/AIAA standards for Operational Concept Docu-ments/Descriptions (OCDs) [2]. The literature appears to agree that OpsCon is the more frequently used term in industry, as three standards were found for creating OCDs and none for ConOps.

The first striking observation is how much information the OCDs are expected to include, and how lengthy a full description would be. This observation is proven correct; six sample OCDs for systems ranging from the DalTrans Transportation Management Center to the James Webb Space Telescope range in length from 25 to

265 pages [8, 28, 29, 31, 32, 341.

A closer inspection of the standards shows that not only are these descriptions

lengthy, but they also include many aspects of the systems that fall distinctly into a description of architecture, as described in Section 1.2.1. Both the standards and examples indicate that much of the information is conveyed textually rather than visually. With the rising popularity of model based systems engineering, a visual depiction is preferred for conveying ConOps. The Department of Defense Architecture Framework attempts to capture operations using sets of diagrams, and is introduced next in Section 1.2.3.

1.2.3

Department of Defense Architecture Framework

The Department of Defense Architecture Framework (DoDAF) standardizes the fram-ing and modelfram-ing of all architectures within the Department of Defense (DoD) so that managers can more effectively make key decisions, and information can be easily shared between departments, projects, and other entities

1131.

Although it only gov-erns architectures within the US DoD, it has become a standard for militaries around

(23)

Table 1.1: Contents of the DoD, IEEE, and ANSI/AIAA standards for Operational Concept Documents/Descriptions (OCDs)

121.

OCDs are lengthy and include

infor-mation found in architectural descriptions.

DOD Operational Concept Description Scope

Identification System overview Document overview

Referenced documents Current system or situation

Background, objectives, and scope

Operational policies and constraints

Description of current system or situation

Users or involved personnel

Support concept

Justification for and nature of changes Justification for change

Description of needed changes

Priorities among the changes

Changes considered but not induded

Assumptions and constraints

Concept for a new or modified system Background, objectives, and scope Operational policies and constraints Description of the new or modified system Users/affected personnel Support concept Operational scenarios Summary of impacts Operational impacts Organizational impacts impacts during development

Analysis of the proposed system

Summary of advantages

Summary of disadvantages or limitations

Alternatives and trade-offs considered Notes

Appendixes

IEEE Operational Concept Document Scope

Identification Document overview System overview

Referenced documents Current system or situation

Background, objectives, and scope Operational policies and constraints Description of current system or situation Modes of operation for the currentsystem or situation

User classes and other involved personnel*

Support environment

Justification for and nature of changes

Justification for changes Description of desired changes Priorities among changes

Changes considered but not included

Assumptions and constraints Concepts for the proposed system

Background, objectives, and scope Operational policies and constraints Description of the proposed system Modes of operation

User classes and other involved personnel*

Support environment

Operational scenarios Summary of impacts

Operational impacts Organizational impacts impacts during development

Analysis of the proposed system

Benefits

Disadvantages and limitations

Alternatives considered Appendices Glossary ANSI/AIAA (1992) Scope System identification Purpose Overview Referenced documents User-Oriented Description

How mission accomplished Strategies

Tactics Policies Constraints

Who users are and what the users do When and in what order operation takes

places

Personnel profile; organizational structure Personnel interactions; activities Operational process models; sequence,

interrelationships Operational needs

Mission of personal needs derived from requirements of the system

System Overview Scope

Users interfaces States and modes Capabilities Goals and objectives

System architecture

Operational environment

(24)

the globe, with similar architectures existing for NATO, the UK, France, Canada, Italy, and Australia, among others [17].

The framework specifies two types of architectures: Enterprise Architectures and Solution Architectures. The distinction is that Enterprise Architectures discuss a mission and the organizational approach to that mission, and Solution Architectures focus on a designed system.

The formal definition of Solution Architectures proposed by DoDAF is:

A framework or structure that portrays the relationships among all the

elements of something that answers a problem. This architecture type

[...I is used to define a particular project to create, update, revise, or

delete established activities in the Department. Solution architecture may be developed to update or extend one or more of the other architecture types. [...] Solution architectures include, but are not limited to, those

[Service-Oriented Architecture]-based architectures developed in support of specific data and other services solutions. [13]

This formulation aligns with the discussion of architecture found in Section 1.2.1; it depicts the elements and relationships of a system to meet a goal. Beyond defining what an architecture is, DoDAF also breaks it into several viewpoints, tailored to meet the needs of different stakeholders. These viewpoints are (descriptions from reference [12]):

* All Viewpoint: describes the overarching aspects of architecture context that relate to all viewpoints

* Capability Viewpoint: articulates the capability requirements, the delivery tim-ing, and the deployed capability

" Data and Information Viewpoint: articulates the data relationships and

align-ment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services

(25)

* Operational Viewpoint: includes the operational scenarios, activities, and re-quirements that support capabilities

" Project Viewpoint: describes the relationships between operational and

capa-bility requirements and the various projects being implemented

" Services Viewpoint: the design for solutions articulating the Performers,

Ac-tivities, Services, and their Exchanges, providing for or supporting operational and capability functions

" Standards Viewpoint: articulates the applicable operational, business,

techni-cal, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services

" Systems Viewpoint: the design for solutions articulating the systems, their

com-position, interconnectivity, and context providing for or supporting operational and capability functions

The Operational Viewpoint is of specific interest to this thesis, and will be dis-cussed in depth in Chapter 2. Details of the other viewpoints can be found in refer-ences [12, 13].

History of DoDAF

DoDAF is currently on Version 2.02, but the history of architecture frameworks in the DoD dates back to 1996, with the introduction of Version 1.0 of the C4ISR Architecture Framework

191.

C4ISR stands for Command, Control, Communica-tions, Computers, Intelligence, Surveillance, and Reconnaissance, and is very much an information-technologies domain. Although the scope of applicability was smaller, the purpose of this original architecture was the same as that of DoDAF today: to standardize architectural information across the DoD such that systems are more easily understandable and integratable.

(26)

Even with the introduction of DoDAF V1.0, which took the framework beyond the C4ISR domain and into DoD-wide applicability, remnants of the information-technologies centric framework remained. Until DoDAF V2.0, the only operands (objects that processes act on) that could be passed between processes or form was information. Now they can be funding, personnel, materiel, etc. 1121. Despite this up-date, it is expected that DoDAF may not be entirely equipped to adequately capture operations of systems with physical, mobile elements. The usefulness of the DoDAF

Operational Viewpoint is discussed in Chapters 3 and 4.

Other important changes that came with DoDAF V2.0 were the exclusion of the node element, and the switch from focusing on products to focusing on architectural data. The former change came as a result of nodes being used to represent almost any aspect of a system that this framework dubs form: organizations, systems, facilities, locations, etc. [12]. Thus, the use of nodes varied between architectures, and the resulting confusion led to them being removed in favor of representing each concept

individually.

The change to focusing on specifying architectural data was an attempt to in-crease flexibility and allow architects to display information in whatever format is best suited for the system [121. This shifted the burden of modeling architectures from the DoDAF specification to commercial tools such as UML and SySML [121. The assumption was that these tools would update to the changes in DoDAF V2.0.

1.3

Specific thesis objectives

Having reviewed the literature, a few observations about the state of the field become apparent. The first is that the domain of Systems Architecture is an ideal starting point to define a ConOps. Architectural descriptions are at an appropriate level of abstraction for depicting ConOps, and the terminology and building blocks are general enough that they can be applied to describe operations as well as architectures.

The second observation is that the literature lacks a framework for ConOps that is consistent, but not redundant, with architectural models. Most of the documentation

(27)

on ConOps and OpsCon is lengthy and unwieldy, and consists mainly of elements found in an architecture. These standards are far too detailed to be manageable at an early stage in the design process, and thus their impact will not be as beneficial to the design of the system description.

The last observation, discussed in depth in Chapter 3, is that DoDAF specifically contains far more diagrams than the content suggest are required. Though diagrams can be a more effective tool than the other, largely textual documents, diagrams to excess can waste valuable time in the design process. Further, the number of comparisons required to make sure different diagrams are consistent is the factorial of the number of diagrams. Inconsistent diagrams will be confusing in the best case, and lead to system failure in the worst case.

With these observations in mind, the specific objectives of this thesis are to:

1. analyze the DoDAF Operational Viewpoint by evaluating the information

con-tent of diagram descriptions and samples, using OPM modeling methods 2. construct a ConOps framework by defining ConOps and outlining the

informa-tion that it should contain, using the results from the DoDAF analysis and the existing System Architecture framework

3. validate the ConOps framework developed by comparing it to textual and

DoDAF representations, using a Search and Rescue system case study

1.4

Thesis overview

This chapter reviewed the relevant literature and concepts related to architectures and ConOps. Chapter 2 will dissect the information contained in the DoDAF Operational Viewpoint by modeling the descriptions using OPM and distilling key information from sample diagrams.

The results of that analysis will be discussed in Chapter 3 to help inform a defini-tion of ConOps. This definidefini-tion will then be integrated into a Systems Architecture framework such that they are consistent and minimally redundant.

(28)

Chapter 4 will use a Search and Rescue (SAR) system case study to compare and contrast the DoDAF Operational Viewpoint depiction to that produced by the framework developed in Chapter 3. SAR was chosen because it is frequently used in the sample DoDAF diagrams, due to it being a universally understood concept with plenty of readily available information [201. Chapter 5 will summarize the thesis' main findings and contributions, and outline potential for future work.

(29)

Chapter 2

Analysis of DoDAF Operational

Viewpoint

2.1

Introduction to the Operational Viewpoint

The DoDAF Operational Viewpoint is one of the industry standards for describing the operations of complex systems, and as such, understanding it is vital to developing a ConOps framework. The Operational Viewpoint is just one of several viewpoints prescribed by DoDAF, so the information content, scope, and focus of the diagrams will indicate areas of interest to the development of the framework in Chapter 3.

This chapter will analyze the diagrams prescribed by the operational viewpoint, both by DoDAF specification and by information content of sample diagrams. The viewpoint is divided into nine diagrams that "describe the tasks and activities, oper-ational elements, and resource flow exchanges required to conduct operations" [121. The nine diagrams that comprise the Operational Viewpoint are:

" OV-1: High Level Operational Concept Graphic " OV-2: Operational Resource Flow Description

* OV-3: Operational Resource Flow Matrix

(30)

e OV-5a: Operational Activity Decomposition Tree

" OV-5b: Operational Activity Model " OV-6a: Operational Rules Model " OV-6b: State Transition Description " OV-6c: Event-Trace Description

Although DoDAF specifies that an explanation should accompany each diagram, this analysis will focus purely on diagram content. Each of the nine diagrams will be studied individually in two ways. First, the expected information content will be modeled in an OPD created from the DoDAF descriptions in reference [12]. Following that, sample diagrams found in the open literature will be dissected to determine what information they contain in practice. Approximately 150 sample diagrams were found and analyzed, though they are not uniformly distributed between the nine diagram types. A subset of samples were reviewed for a basic understanding, and to identify appropriate criteria to evaluate the entire set on. It was determined that the samples should be evaluated for the presence of the following information:

" Performers (operators/instruments) " Processes

" Process attributes (removed subsequently because virtually nonexistent)

* Sequence/timing " Operands

" Operand attributes

Following the individual diagram analysis, the total information content of the Operational Viewpoint will be discussed. The DoDAF Operational Viewpoint OPD shown in Figure 2-1 contains at least one instance of every element described in the

(31)

System Boundary Syte oudayBig

F

';M- SV-01 Big liNon-Hierarchical

B nstrument Only 0 rator Relationship

Event I Proes

( a nynProcess n eed Operator

iael en cnstrument iOperator V p Accomp

2 | | 2 0 Oprator

Operand 1 Process Operand 2 rocess Operand 3 Viewp

Event 2

-tiinuO contmportance

Sehuence/wO tha

Timing

Needline 1

(d companying P itcess needsOpe 3)ncnd

Figure 2-1: DoDAF Operational Viewpoint OPD. This OPD depicts at least one

instance of every element contained in the DoDAF Operational Viewpoint.

Operational Viewpoint descriptions. The decomposition of form in the red dashed box appears only in the Systems Viewpoint, and not in the Operational Viewpoint, but is included so that the OPD contains all aspects of a complete system architec-ture. There are a few features of other sequeneh walking through. The top half of the OPD is broken into three somewhat distinct sections. On the left is a process decomposition, which refines Big Process into its component procses. In the center is a decomposition of instruments, which represents the static elements of the system itself. On the right is an organizational decomposition, which shows relationships

among various operators.

Shown across the center of the OPD is the critical sequence, which starts with Process 2 consuming Operand 1, and ends with the Accompanying process modifying Operand 3. Although there are no other sequences in this diagram, it should be noted that identifying the most important sequence of events for an operation is useful for understanding the operation and what might affect it. Below the critical sequence

are some example attributes of processes and operands. Needline 1 shows that the

Accompanying Process requires Operand 3 from Process 2, but does not depict how the operand actually flows through the system. The events on the left side of the diagram trigger the operation.

(32)

Systemn Boundary -~ -_ N

j g SVi 01 Bi INon Hlerarghica

Instrument Only _operator I Relationship

strument Opeator

A I r7o I

j I--!

(Process - - I Acomp

2 2e rator

10perand 1 2 Operand 2rocess %Operand 3L % AcTip .

- - .;-! -..-. Event 2 > Location -seue6cNeOtherAttr I Neecline I . .I - Performers I Operands Sequence I Operand Attributes DI Processes

Figure 2-2: Depicts which elements of the DoDAF Operational Viewpoint OPD cor-respond to which items of interest in the analysis of sample diagrams.

Figure 2-2 delineates what parts of the OPD correspond to the information being identified in the sample diagrams. The samples may include information beyond what is shown, but the important elements are boxed. Note that sequence is indicated both through logical arrangement of elements (hence the critical sequence being boxed) and through a diagram convention (hence the Sequence/Timing attribute being boxed).

There is some ambiguity in the analysis of the DoDAF specifications and sample diagrams. First, the DoDAF diagram descriptions contain imprecise language and, in some cases, contradictions. Second, interpreting sample diagrams with little or no context is a challenge and some decisions had to be made at the researcher's discretion.

Lastly, many of the sample diagrams found were created prior to DoDAF V2.0. The Operational Viewpoint remains mostly the same between versions, with two main changes: the removal of nodes as an element, and the inclusion of non-information resources. Prior to DoDAF V2.0, nodes could represent activities, systems, organiza-tions, personnel types, facilities, locaorganiza-tions, materials, installaorganiza-tions, etc. DoDAF V2.0

(33)

removes nodes in favor of individually depicting those entities. For the purpose of this analysis, nodes were assumed to represent either instruments or operators.

Regarding the latter change, in previous versions of DoDAF, diagrams could only show flows of information, a reminder of the information-technology-centric origins of DoDAF. Now, flows can be funding, personnel, and materiel, in addition to in-formation. For this analysis, any flow (information or otherwise) was categorized as a resource. These changes are not significant to the sample diagram analysis, so diagrams made for previous versions of DoDAF are included.

2.2

Individual diagram analysis

2.2.1

OV-1: High-Level Operational Concept Graphic

The OV-1 is a flexible, high level diagram used as a presentation or discussion tool, and as such is omitted from the combined analysis. Short summaries of the DoDAF description and sample diagrams are included for informative purposes.

Description

The primary purpose of the OV-1 is to aid communication by summarizing the op-erations of a complex system in a mission, class of missions, or scenario. It depicts, at a high level, what the subject of the architecture does, how it does it, and who does what in what order. In addition, the diagram sets the scope of the system, and highlights interactions with the environment and accompanying systems, interesting aspects of the operations, key operators and organizations, location of assets, and any other important high-level aspects of the system. Although there are many differ-ent elemdiffer-ents of information that can be included, it is up to the architect to decide which elements warrant inclusion, and at what level of detail, such that the diagram is understandable and useful. In the language of Systems Architecture, the OV-1 is a level 1 diagram, which is more abstract than level 2, where the other Operational Viewpoint diagrams exist [11].

(34)

OV-1 High-Level Operationa, Concept Graphic [AR HLOC ) Mon tr signal ~ NAkrcrt:INASR alo V ackicto / 4 ~ 4 h41

Figure 2-3: Sample of a "complete"

OV-1

High-Level Operational Concept Graphic for a Search and Rescue system

[3].

This diagram contains most of the information that can be in an OV-1: instruments, operands, and location context.

Samples

As expected from the description above, the sample OV-ls found vary in information contained and presentation format. Most of them, including that in Figure 2-3, took the form of resource flow networks, showing the exchange of information and other operands between instruments at different locations [3]. Figure 2-3 shows a "complete" OV-1, i.e. it depicts all of the information stated above, including labels on the operand flows. However, some of the samples, such as that in Figure 2-4, omitted one or two of those aspects

[10].

Figure 2-4 depicts a sparse diagram that only includes the instruments and limited location information. These two diagrams capture the two ends of the spectrum of OV-1 diagrams found.

(35)

- Teisprwe 4 IV

hirastructurn

Command Center

Figure 2-4: Sample of a sparse

OV-1

High-Level Operational Concept Graphic for a school emergency response system [10]. This diagram contains the minimum amount of information expected in an OV-1: instruments and limited location context.

(36)

2.2.2

OV-2: Operational Resource Flow Description

Description

The OV-2 description is somewhat self-contradictory and ambiguous, focusing in some places on operand flows, and noting that they are optional in other places. The most important feature seems to be the needline, which is a line that indicates a need to exchange operands between processes. The needline does not indicate an actual flow of operands, nor does it indicate the path that an operand flow would follow. The specification conveys that actual flows of operands are optional in the OV-2. Actual operand flows are required to be in the OV-3, and appear in the OV-5b, 6b, and 6c as well. In addition, the attributes of a process (specifically the location of the process) may be included in the OV-2. The information of an OV-2 including optional aspects is shown in Figure 2-5, and the minimum content is shown in Figure 2-5.

OV-2 diagrams can be used to express the capability boundary to stakeholders. DoDAF defines capability as "the ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (ac-tivities and resources) to perform a set of ac(ac-tivities" [121. The capability boundary, though not explicitly defined, is interpreted as the boundary between the processes and operand flows belonging to the system-of-systems that directly provide the capa-bility, and those considered to be external or belonging to accompanying systems. The OV-2 is well suited to describe the capability boundary because it explicitly shows the processes and operand flows being considered, with little cluttering information.

For this reason, the OV-2 (or a simplified version) if often used as an OV-1.

Note that the needline for Operand 3 leads directly to Accompanying Process, whereas the actual flow of Operand 3 comes from Process 3. Figure 2-5 also depicts three different kind of interactions between operands and processes. Process 2 con-sumes Operand 1, and produces Operand 2, and Process 3 concon-sumes Operand 2 and produces Operand 3. The third kind of interaction is transformative, shown by the double headed arrow between Operand 3 and Accompanying Process; the process doesn't consume or produce Operand 3, but rather alters its attributes.

(37)

I

-~~

Bondr sV01 instrumentl Only Instrument IEvo'!rl NI I Big Process Operator I AL I i I cinstrument Operatot A

Operand I Poess Operand 2 PoesOperand 3 cm

2rcs 3 Pr~aor oe

FI e~J nI 2>Lz\

LocaNen dmpoetan1

Needilne 1

(Accompanying Process needs Operand 3)

Figure 2-5: Depicts a "complete" OV-2 Operational Resource Flow Description. Note that it includes optional aspects such as actual resource flows and intermediate pro-cesses. ) rocess Process oc atio Sequenc Timing F---- - - F Instrument Only Astr~ment operator I nstrument Operator 2 2 Oprnd2rocess E~e e]

I

J

Other Lel-Att]

erator1 Nor! -H ierai chicaI

Relationshipi Accomp Operatr_ ran3 I I I I Needline 1

(Accompanying Process needs Operand 3)

Figure 2-6: Depicts the minimum OV-2 Operational Resource Flow Description.

I

Syte Bondr

ris

Pocess

IFperand Big Operator Rehati0ns - no

(38)

UPDM SAR OV-2

OV-2 [Architectural Description] Nodes

V-2: Operya ne cti n na'l Operational connectivity and resource flow needlines

M~odes 10 odes Search * Needlinev Place Of Safety

Tsk tas ing''line*e DS distressSignal

Tsk:tak!

M tsIin 49"% =

Stat : stewus

ee 2lines V odes DS:distressSignal Nodes Rescue - Person In Distress

SNeedinml

as eitedin Figure 27 tedasml foc

DS : distressSignal Rqst: request r oTk atasking b elnea

sNeedli sa

q odes Rqst : request aNodes TI trackinfe inoeb

SAR Asset Controller Tactical C2 Mon"rn

of hischpte, adigra usngaln fte* lbln meds erecutda e Figure 2-7: Sample OV-2 Operational Resource Flow Description for a Search and

Rescue system [141.

Samples

As depicted in Figure 2-7, the OV-2 samples focus on performers (operators or

in-struments) and operands [14i. The performers are typically represented as the nodes using labeled boxes or other shapes, but several of the diagrams use pictures of the

performers. The lines connecting the nodes are labeled in a variety of ways. Some are simply labeled "Needline", some are given an identifying number, some have generic descriptions such as "Data Packet", and some show specific resources such as

"Re-quest for Aid". For the taxonomy of diagram samples introduced in the beginning

of this chapter, a diagram using any of those labeling methods were counted as de-picting resources. However, in diagrams with resource descriptions (whether generic or specific), it was rarely indicated whether the line represented a needline or actual operand flow.

(39)

Several of the samples included processes, generally associated with a performer but sometimes as their own nodes. Fewer included any details about the operands, and those that did simply listed the information type, transmission frequency, or units of measurement.

While the general format and information content of the OV-2 samples match the DoDAF specification, too many of them neglected to specify needlines or distin-guish them from actual resource flows for the needline to be considered a standard in practice. This may result from the fact that many stakeholder needs are more thoroughly identified and analyzed in a stakeholder map, making their inclusion in an Operational Resource Flow Description redundant [11].

2.2.3

OV-3: Operational Resource Flow Matrix

Description

The OV-3 is one of two non-pictorial diagrams prescribed by the Operational View-point (the other being the OV-6a). Instead, it takes the form of a matrix that associates operand flows with their important attributes, as shown in Figure 2-8. It uses this matrix form to organize much of the same information shown in the OV-2, but with more detail, into a table that can be referenced throughout the rest of the viewpoint. The DoDAF description does not specify what information must be included with the operand flows, except for the following: producing and consuming processes and locations, why the operand is necessary, and what needline the operand flow satisfies. One needline can represent one or more operand flows of different types. The information shown in the OV-3 is not meant to be exhaustive, but rather focus on the important operand flows, and the most important attributes associated with those operands. The diagram description specifically highlights flows that cross the capability boundary or are critical to the mission.

(40)

U-B -ig 0 I Nr

h instrument only er a tor era

BA

Ircs Instrument Operator

(Procesas insr ene Operator A

22 Opera

Operand 1 e Oper and Althd sho smportanc

Many of the sample OV-3s are actually templates for making the matrix, rather than examples of a matrix for a specific system such as that depicted in Figure 2-9 [25]. The elements meant to be contained in the matrix are labeled in the headings of each column. The headings align well with the types of information specified in the DoDAF description. Without exception, the samples include processes and operands. The focus is on operands, with processes only mentioned to provide context about where the operands are produced and consumed. Although most of the diagrams include details about the operand transfer (security, timeliness, etc.), only about half of the samples include additional information about the operands themselves.

Not all of the "diagrams" referenced needlines, and instead reference the operands themselves or other identifiers. This further supports the idea that needlines, despite being an important part of the DoDAF specifications, are either not practical or useful enough for universal use in industry, or are not well enough understood or implemented. As discussed in Section 2.2.2, this may be because needlines can be captured elsewhere, while actual operand flows are more important to operations.

(41)

Operational Exchange 5ending Receiving Producing Operational Consuming Operational

Operational Exchange Sending

Item Node

1 CV Request Tactical C2 Node

2 (j) Control Order Tactical C2 Node

3 (J Control Order Tactical C2 Node

4 ® Warning Order Search Node

5 T Medical Condition Search Node 6 CD Task SAR Asset Controller

7 (1 Task c9b SAR Asset Controller

. .. Disres Signlrson In Distress

8 CD Distress Signal Person In Distress

10 CD Distress Signal Person In Distress

11 (1) Track Info I& Monitoring Node

Receiving Producing Operational Consuming Operational

Node Activity Activity

5AR Asset Controller

f

Rescue Node C% Search Node Place Of Safety Rescue Node % Search Node % Rescue Node % Search Node Rescue Node c% Monitoring Node % Tactical C2 Node

Send Warning Order Monitor Health

Send Distress Signal Send Distress Signal

1

Figure 2-9: Sample OV-3 Operational Resource Flow Matrix for a Search and Rescue system 125].

2.2.4

OV-4: Organizational Relationships Chart

Description

The OV-4, as the name suggests, depicts relationships among organizations and op-erators, as shown in Figure 2-10. These relationships can take many forms, and are not strictly hierarchical. Examples include customer-supplier, supervisory reporting, command and control, and collaborative relationships. Architects may define any re-lationship that is useful to understanding the architecture. Though individual billets (roles/jobs) may be included in the OV-4 to represent specific skills required, actual people are not meant to be included.

There are two variations of the OV-4: role-based, and actual. Role-based OV-4s may depict a typical organization and the relationships and roles that it would have, while actual OV-4s depict a real organization at a certain point in time. Architects may also create hybrid diagrams containing aspects of both.

The purpose of the OV-4 is to highlight the key stakeholders involved with an architecture, and the relationships they have with each other. It also serves to specify individual skills that certain operators or organizations need for the architecture to function. As with the needlines discussed in Section 2.2.2, stakeholder identification and analysis is primarily conducted in a stakeholder map.

Process Warning Order Provide Medical Assistance

Receive Distress Signal

(42)

I-System Boundary Process loperand J1Process i Even2 I Isequerl( I~ Timini I

fig '] sv (I Big INon-Hierarchcal

O0nstrumentl Only 0 rator Relationship

nstrument Operator Instrument L2 2Oeao 17 rocess --- Oeau---- Acr Operand 2 rIcess 3 mpoPtonc e Other Attr Needline 1

Figure 2-10: Depicts OV-4 Organizational Relationships Chart. As shown, the chart can include hierarchical and non-hierarchical relationships.

Samples

The information contained in the OV-4 samples examined exactly matches the DoDAF description. The only exception is that one diagram includes actual named people, in addition to the billet they fill. Otherwise, the diagrams only contain organiza-tions, operators, and the relationships among them, as shown in Figure 2-11 [36]. Most of the connections between organizations/operators are unlabeled, and their relationships are implied from their names and two-dimensional arrangement. Some lines, particularly those that do not represent command or aggregation relationships, are labeled for clarity. About a third of the diagrams label every or almost every relationship, or include a legend describing how different relationships are depicted.

2.2.5

OV-5a: Operational Activity Decomposition Tree

Description

The OV-5a simply decomposes higher level processes into more specific ones that are necessary for mission completion. Figure 2-12 depicts the information content of the OV-5a. Note that relationships among processes can be decomposition or other non-hierarchical relationships. The processes specified in the OV-5a are dubbed

(43)

8.arch / 1 CoM-- (C2)vrpn don MM 0 1 T CuResew U T ewMRHS hI

Figure 2-11: Sample OV-4 Organizational Relationships Chart for a Search and Res-cue system [361.

(44)

r

ig B INon Hieracci3 instrument Only Operator Reltionhipl

Big4

Ktii

Process IA

nstrument Operator

Process nstrument Operator Accomp

I2 2 Operator I _Z 1 Operand P Opea .2 d3L vent 2 I Location rnportncej i ~~Sequence/ eArI

Timinge Other Att

Needline 1

(Accompanying Process needs Operand 3)

Figure 2-12: Depicts OV-5a Operational Activity Decomposition Tree. Note that the relationships between processes can be hierarchical, as with Big Process and Processes

1 and 2, or non-hierarchical, as with Process 3 and Accompanying Process.

dard operational activities, which are activities defined in doctrine but still solution-neutral. Solution-neutral means that the activities do not limit the design space; it is the difference between "traveling to Florida" and "flying JetBlue to Florida". Operational activities in the OV-5a map to system or service functions, which are de-scribed in either the Systems or Services Viewpoints respectively. System and service functions describe the "how" to the operational activities' "what".

Samples

As demonstrated by Figure 2-13, the sample OV-5a samples show exactly what the description calls for: processes decomposed or aggregated into other processes [361. Six of the eight samples have letter/number IDs for the processes. One diagram includes the performers, in addition to the processes.

(45)

Search

And

Rescue

Search Communicate

Coordinate Plan Execute Dist

Search Search Search ignal

Locate Warning VictimOrder Monitor Health Rescue Maritime Rescue Modkeal Recover ia Victim Assist

Figure 2-13: Sample OV-5a Operational Decomposition Tree for a Search and Rescue system [36].

Figure

Figure  1-1:  Depicts  the  building  blocks  and  two  essential  relationships  of OPM,  and their  representation  in  OPDs
Figure  1-2:  a)  Depicts the  three  Process-Operand  relationships  used  in OPM:  (top to bottom)  consumption,  modification,  and production
Figure  1-3:  Depicts  a simple  OPD for a sliced-bread-making  system [11].  It shows  the flow  of operands  from  top  to bottom,  and  the  performer-process-operand  convention from  right  to left.
Table  1.1:  Contents  of  the  DoD,  IEEE,  and  ANSI/AIAA  standards  for  Operational Concept  Documents/Descriptions  (OCDs)  121
+7

Références

Documents relatifs

In our context, the blockchain orchestration tool automates the deployment of blockchain infrastructure (nodes, network) and smart contracts in a given environment.. Here, we focus

In these science experiments we aimed at creating naturalistic learning settings which could enable the use of sensory input (e.g. seeing, touching, smelling

The Framework called GlobOpe bears in mind the Operations Strategy key decisions that need to be made regarding a global production and logistic network configuration and design

In 2004, the Quality and Outcomes Framework (QOF) was introduced in England with the main aims of improving the quality of primary health care (PHC), embedding preventive measures

To begin to answer such questions in a secure and protected setting, prior to the unintended onset of consciousness in highly intelligent, powerful and autonomous

More specifically, we are concerned with multimodal communication with the drones suitable for the following purposes: robot selec- tion commands (e.g. “go there”, “land”,

The ASSET framework can nonetheless managed such a product through an external software module called an ASSET Proxy (e.g. a VTR cannot include a built-in ASSET agent and has to

proposes a probabilistic methodology to assess the resilience degradation of transmission networks subject to extreme wind events. In Cadini et al. [18], an extreme weather