Presentation from February 2002 Dinner Meeting

8/9/2019 Presentation from February 2002 Dinner Meeting

1/109

2002 Systems and Proposal Engineering Company.All Rights Reserved.

1

Developing a Defensible C4ISRArchitecture

Presented by Dr. Steven H. Dam and

James D. Willis, Colonel, USAF (retired)


2/109


2

RoadmapPart 1: Introduction

Part2: Why Systems Engineering and

Architecture Development?Part 3: Developing Your Architecture

Part 4: Packaging and Selling YourArchitecture

Part 5: Summary


3/109


3

Part 1: Introduction


4/109


4

PurposeTo provide the means to develop complete,

defensible architectures

using the C4ISR Architecture Framework and

good System Engineering processes and tools


5/109


5

Class GuidelinesDiscussionplus group participation

Avoid interrupting others

Ask questions as they arise

Unclassified Discussion


6/109


6

IntroductionsDr. Steve Dam

30+ years of software development and systemsengineering experience

Participated in the development of version 2.0 ofthe C4ISR Architecture Framework

Jim Willis

30+ years experience in the C4ISR domain as aUSAF officer and contractor

Currently provides training in systems engineeringfor NIMA and NIMA contractors


7/109


7

Whos Here?

Defense contractor?

Government employees?

Familiar with Systems Engineering?

Familiar with architectures?

Familiar with the C4ISR ArchitectureFramework?


8/109


9/109


9

Part2: Why Systems Engineeringand Architecture Development?


10/109


10

What is System Engineering?An integrated composite of people, products,and processes that provides a capability orsatisfies a stated need or objective.[DoD 5000.2]

Systems Engineering is an interdisciplinaryapproach and means to enable the realization

of successful systems. [INCOSE]

Problem-solving

In system engineering we seek to better understand

and control our environment


11/109


11

How Do We Go About Doing System

Engineering?Principal approach:

Decomposition

Your methodology should enable you to look at the

complete system and its behavior

Avoid oversimplification


12/109


12

What is an Architecture?Architecture: The structure of components,their interrelationships, and the principle

quidelines governing their design andevolution over time. [DSMC Acquisition Acronyms and Terms ]

Systems Architecture: The fundamentaland unifying system structure defined in terms

of system elements, interfaces, processes,constraints, and behaviors.

[INCOSE Systems Architecture Working Group]


13/109


13

How Does SE relate to C4ISR

Architecture Development?Architecture provides the broader context fora specific set of systems

System engineering methodologies apply

The main difference

Architecture study - less decomposition

System Engineering - more decomposition

Remember, one persons system is another personscomponent, is another persons architecture


14/109


14

What Do Architectures Do For Us?

Architectures provide a means to deal with the past,present and future

NOW NEAR TERM LONG TERM

Transition As - Is To - Be

What you have How you move now to then Your Vision


15/109


15

What Is the C4ISR Architecture

Framework?

So for the purposes of this seminar we will focus on

version 2.0, with highlights from draft 2.1

1996 1997 2000 20011998 1999 2002 2003

C4ISR AF V 1.0

New Standard

C4ISR AF V 2.0

Improvements DraftDoD AF V 2.1

Object-orientedmethodology

????

DoD AF V 1.0

OSD Memo

Mandatory use


16/109


16

Fundamental Linkages Among the

C4ISR Architecture Framework ViewsOperational

View

Identifies WarfighterRelationships and Information Needs

Systems

View

Relates Capabilities and Characteristicsto Operational Requirements

Technical

View

Prescribes Standards andConventions

Specific CapabilitiesIdentified to SatisfyInformation-ExchangeLevels and OtherOperational Requirements

Technical Criteria GoverningInteroperable Implementation/Procurement of the SelectedSystem Capabilities

ProcessingandLevelsof

Inform

ationExchange

RequirementsB

asicTechnology

Supportabilityand

NewCapabilities

Syst

emsA

ssocia

tion

s

toN

odes

,Activ

itie

s,

Nee

dlin

esand

Req

uire

men

ts

Proc

essi

ngand

Inte

r-N

odal

Lev

els

ofInf

orm

atio

n

Exc

hang

eR

equi

reme

nts

Reference: C4ISR Architecture Framework, Version 2.0


17/109


17

C4ISR ViewsApplicable

ArchitectureView

All Views(Context)

All Views(Terms)

General Description

Scope, purpose, intended users, environment depicted,analyticalfindings, if applicable

Definitions of all terms used in all products

ArchitectureProduct

Overview and SummaryInformation

Integrated Dictionary

ProductReference

AV-1

AV-2

Mandatory

MandatoryJoint

or

Supporting,Specific-

Purpose

Operational

Operational

Operational

Operational

Operational

Operational

Operational

Operational

Operational

High-level graphical and textual description of operational concept (high-level organizations, missions, geographic configuration, connectivity, etc.)

Command, control, coordination, other relationships among organizations

One of the three products used to describe operational activity sequence andtiming that identifies the business rules that constrain the operation

One of the three products used to describe operational activity sequence andtiming that identifies responses of a business process to events

One of the three products used to describe operational activity sequence andtiming that traces the actions in a scenario or critical sequence of events

Operationalnodes, activities performed at each node,connectivities &information flow between nodes

Information exchanged between nodes and the relevant attributes ofthat exchange such as media, quality, quantity, and the level ofinteroperability required.

Documentation of the data requirements and structural businessprocess rules of the Operational View.

High-level OperationalConcept Description

Organizational RelationshipsChart

Operational Rules Model

Operational State TransitionDescription

Operational Event/TraceDescription

Operational NodeConnectivity Description

Operational InformationExchange Matrix

Logical Data Model

OV-1

OV-4

OV-6a

OV-6b

OV-6c

OV-2

OV-3

OV-7

Mandatory

Mandatory

Mandatory

Activities, relationships among activities,inputs and outputs. In addition

overlays can show cost, performing nodes, or other pertinent information.A

ctivity ModelOV-5 M

andatory

Supporting

Supporting

Supporting

Supporting

Supporting

Systems

Systems

System InterfaceDescription

SV-1 Mandatory Identification of systems and system components and theirinterfaces, within and between nodes

Physical nodes and their related communicationslaydowns Systems CommunicationsDescri tionSV-2

Supporting

Mandatory

All Views(Capabilities)) AV-3

Capability MaturityProfile

SupportingDescription of focus areas in terms of incremental capability

levels, consistent with a standard capability maturity scale.

Reference: DoD Architecture Framework, Version 2.1 (draft)

timing that identifies the business rules that constrain the operation-


18/109


18

C4ISR Views (continued)

Operational

Operational

Operational

g p

One of the three products used to describe operational activity sequence andtiming that identifies responses of a business process to events

One of the three products used to describe operational activity sequence andtiming that traces the actions in a scenario or critical sequence of events

Documentation of the data requirements and structural businessprocess rules of the Operational View.

Operational State TransitionDescription

Operational Event/TraceDescription

Logical Data Model

OV-6b

OV-6c

OV-7

Supporting

Supporting

Supporting

Technical

Technical

Description of emerging standards that are expected to apply to thegiven architecture, within an appropriate set of timeframes

Extraction of standards that apply to the given architecture

Standards TechnologyForecast

TechnicalArchitectureProfile

TV-2

TV-1 Mandatory

Supporting

Planned incremental steps toward migrating a suite of systems to a moreefficient suite, or toward evolving a current system to a futureimplementation

Physical implementation of the information of the Logical DataModel, e.g., message formats, file structures, physical schema

Systems

Systems

Systems

Systems

Systems

Systems

Systems

Systems

Systems

Systems

Functions performed by systems and the information flow amongsystem functions

Mapping of system functions back to operational activities

Detailing of data exchanges among system elements, applications andH/W allocated to system elements

Performance characteristics of each system(s) hardware and softwareelements, for the appropriate timeframe(s)

Emerging technologies and software/hardware products that are expected tobe available in a given set of timeframes, and that will affect futuredevelopment of the architecture

One of three products used to describe systems activity sequence andtiming -- Constraints that are imposed on systems functionality due tosome aspect of systems design or implementation

One of three products used to describe systems activitysequence and timing -- Responses of a system to events

One of three products used to describe systems activity sequence andtiming -- System-specific refinements of critical sequences of eventsdescribed in the operational view

System PerformanceParameters Matrix

Systems State TransitionDescription

Systems FunctionalityDescription

OperationalActivity to SystemFunction Traceability Matrix

System DataExchange Matrix

System EvolutionDescription

System TechnologyForecast

Systems Rules Model

Systems Event/TraceDescription

Physical Data Model

SV-4

SV-5

SV-6

SV-7

SV-8

SV-9

SV-10a

SV- 10b

SV -10c

SV-11

Supporting

Supporting

Supporting

Supporting

Supporting

Supporting

Supporting

Supporting

Supporting

Supporting

Systems

Systems

System InterfaceDescription

SV-1 Mandatory Identification of systems and system components and theirinterfaces, within and between nodes

Systems

Systems

Physical nodes and their related communications laydownsSystems CommunicationsDescriptionSV-2

Supporting

SV-3 Systems2Matrix Supporting

Relationships among systems in a given architecture; can be designed to show

relationships of interest, e.g., system-type interfaces, planned vs.

existing interfaces, etc.

Reference: DoD Architecture Framework, Version 2.1 (draft)


19/109


19

Conceptual Relationship Between

Architecture Purposes and Products

Reference: C4ISR Architecture Framework, Version 2.0


20/109


20

From Chapter 7. FURTHER EVOLUTION OF THE

DOD ARCHITECTURE FRAMEWORK2.1

The Framework does not advocate the use ofany one methodology/notation

[Use] whatever methodology/notation isappropriate.

In other words, the Framework products are intended to come from

the results of a complete system engineering process


21/109


21

How Is the C4ISR Architecture

Framework Useful to You?Provides a standard for communicating theessential elements of your architecture

Makes the case for a complete systemengineering approach, not just viewgraphengineering


22/109


22

Part 3: Developing Your Architecture


23/109


23

The Role of Methodology

Provides structure

Enables concurrent activity

The C4ISR Architecture Framework was intended to bemethodology independent, so we must select our own

methodology


24/109


24

A Variety of Methodologies to Choose

FromStructured Analysis with and without real-time extensions

Object-Oriented Analysis and Design

Unified Modeling Language (UML)

System/Software Requirements EngineeringMethodology (SREM/DCDS)

Zachman FrameworkAd infinitum

Make sure the methodology you choose withprovide a broad, complete foundation for analysis

and specification


25/109


25

Characteristics of a Good

MethodologyAddresses your full life cycle

Integrates a set of processes

Provide executable resultsUses appropriate software tools

Communicates well to all audiences

Extends ability to adjust to specific needsHas been applied successfully


26/109


26

The Role of ToolsTools help us keep track of the variety ofinformation

Before - paper and pencil

Today - wide variety of tools

netViz

System Architect

DOORS

CORE

ERWIN/BPWIN Rational Rose

Choose the tool that best implements the

methodology you want to use


27/109


27

Characteristics of a Good ToolSupports your chosen methodology

Provides several integrated functions

Employs rule-based standards

Enforces consistency

Uses an integrated, common database

Permits simulation capability

Facilitates exporting data and productsEnables flexible reconfiguration

Applies to multiple lifecycle phases

Supports multiple disciplines


28/109


28

The Methodology for This SeminarWe use the SREM/DCDS methodology

Why?

SREM 1969

To perform the system engineering and softwaredevelopment

Proven on major successful systems

DCDS early 1980s

Extension of SREM to distributed systems

Used extensively

Based on Entity, Relationship, Attribute diagrams,


29/109


29

The Tools for this SeminarCORE integrated rule-based, analysistool

netViz strong graphics with underlyingdatabase

MicrosoftOffice integrated clericalsupport

CORE provides a complete, logical language fordescribing a system or architecture


30/109


30

CORE LanguageEnglish

EquivalentCORE Example

Element OriginatingRequirement

Function

Component

...

Noun

Relationship OriginatingRequirementtracesto Functions

Functionsare allocatedto Components

...

Verb

Attribute Creator

CreationDate

TextDescription

...

Adjective

Attribute ofRelationship

amount ofResource consumed by Function acquire available (holdpartial) Resource for

Function

...

Adverb

Graphic Views: EFFBD, FFBD, N2, ER,

ERA, Hierarchies,IDEF0, Physical Block

Graphics/

Drawings

Structure

Copyright 1996-2000 Vitech Corporation. All rights reserved.

COREs Requirements Statement

Language

Note: CORE ReplacesEntity with Element


31/109


31

Entity-Relationship-Attribute (ERA)

Entity1

Attribute1.1Attribute1.2Attribute1.3

.

.

. Entity2

Attribute2.1Attribute2.2Attribute2.3

.

.

.

Relationship1-2

Attribute1-2.1Attribute1-2.2Attribute1-2.3

...


32/109


implemented by

OperationalArchitecture

Domain

NeedLine

Operational

Activity

OperationalInformation

built

rom

exchanges

(carries)

decomposed by

decomposed by

exits by

inputs / outputs / triggered by

captures / consumes / produces

per

orms

connected to

connected thru

implemented by

implemented by

Guidance

incorporates

traces to

AnyClass

OperationalTask

accomplishes

Mission

achieved by

composed o

OperationalElement

SystemArchitecture

Domain

Interface

Link

Function

Item

built

romjoins

joins thru

carries

decomposed by

decomposed by

inputs / outputs /

triggered by

captures/ consumes /produces

per

orms

connected to

connected thru

CompletionCriterion

Resource

implemented by

Originating

Requirement

incorporates

traces to

AnyClass

Architecture

composed o

System/Component

exits by

comprised o

Copyright 1992-2002. Vitech Corporation.

CORE 4.0 C4ISR Schema Overview


33/109


33

Function

Item

extended by

implements

Package

holds

Class

Extension for Java Software Definition

depends

Component

creates

Variable

JavaInterface

Method

Interface

APIcreated by

created by

made rom

created by

made rom

constructs


34/109


34

Extension for Relational Database

Schema Development

modi ied by

ItemOperationalInformation

leads to

Entity

Attribute

Relationship

elated rom

modi ied by


35/109


35

CORE

BehaviorDiagrams(EFFBDs)

Yes

No

Loop over whatever you want

Ref. OR

AND

Element 1

Element 2

AND

LPElement 3

LE

OR LP

OR Ref.

Input 1 Output 1

Trigger1

Date:

Thursday, March 30, 2000

Author:

Administrator

Number: Name:Not Applicable

Reference

Node

identifies next

function

Loop Exit

Shows

condition for

exiting loop

Multi-Exit Function

provides potential

paths from a function

(decision points)

Loop

specifies a

repeating offunctions until

loop exit

criteria is

satisfied

Trigger

special case

of

input/output

causes

function to

execute, if

enabled

Input data

flow into a

function

Output data

flow out of a

function

AND both

functions are

enabled in

parallel and

must complete

to go on

OR only one

path is

chosen,

usually by a

Trigger event

(Exclusive

OR)

Function Process/Base

Practice or

Procedure

step


36/109


36

Life Cycle ModelsDoD 5000.2

Another way we canvisualize the lifecycle is using the V

DSMC Systems Engineering Fundamentals


37/109


37

The V Model

ArchitectureDevelopment

SystemDesign

Hardware/SoftwareAcquisition

Integrationand Test

OperationalT&E andTransition

Future Operationsand Maintenance

Demolitionand Disposal

ProgramManagement

CurrentOperationsand Maintenance


38/109


38

How Do We Approach an

Architecture?

RequirementsAnalysis

FunctionalAnalysis andAllocation

Synthesis

SystemAnalysis and

Control

Best Use:Classical SE

Best Use:ReverseEngineering

Best Use:ArchitectureDevelopment

Adapted from EIA-632


39/109


39

Architecture Development Process

5. Develop the Architecture Contexts

6. Develop Operational Scenarios

1. Capture and Analyze Related Documents

4. Capture Technical Views (TV)

3. Identify Existing/Planned Systems

2. Identify Assumptions

7. Derive Operational Views (OV)

8. Derive System Views (SV)

9. Allocate OV to SV

10. Prepare Interface Diagrams

14. Provide Options

12. Perform Dynamic Analysis

11. Define Resources, Error Detection & Recovery

13. Develop Operational Demonstration Master Plan

15. Generate Operational and System Architecture Graphics, Briefings and Reports

Requirements Analysis

Functional Analysis

Synthesis

System Analysisand Control

Thisimplementationofthe middle-outapproachhasbeenprovenonavarietyofarchitecture projects


40/109


40

Whats Left?We have a methodology

We have a tool that implements the

methodologyWe have a process

Whats missing?

The People You


41/109


41

Who Should Be Part of My

Architecture Team?Need someone with vision

Need someone who can perform the detailedsystem engineering

Need someone who understands the domain

Need someone familiar with the methodologyand tools

Need someone who understands the process

Team: Pooled expertisereduces risk


42/109


42

Sample Problem


43/109


43

Problem: A New C4ISR Management

SystemThis system shall: Provide distribution of raw and processed data

from a new tactical UAV to support operationsspanning the Joint Task Force to Platoon levels

Platoons do not have to receive raw datadirectly, verbal commands are sufficient

Requested information from a platoon mustbe answered, if at all possible, within a fewminutes of the request, preferably withinseconds of most requests

Objective: Design a new C4ISR Management Systemthat enables this capability


44/109


44

Step 1: Capture and Analyze Related

DocumentsWhat documents would be relevant todeveloping this architecture?

What analysis can we perform?


45/109


45

Step 2: Identify AssumptionsWhat assumptions do we have to make in thestatement of the problem?


46/109


46

Step 3: Identify Existing/Planned

SystemsWhat are the kinds of other systems that mayaffect our architecture? (Keep it unclassified)

How can we find out moreabout these systems?


47/109


47

Step 4: Capture Technical Views (TV)What standards do we need to address here?

How do we build a TV-1?

Do we need to build a TV-2?


48/109


48

Step 5: Develop the Architecture

ContextsHow do we create the context for thisarchitecture?

21


49/109


49

Step 6: Develop Operational

ScenariosWhat scenarios should we address here?

How do we decide whichscenarios to pursue?


50/109


50

Step 7: Derive Operational Views

(OV)Which operational views should we develop?

Can we build them separatefrom the systems andtechnical views?

2

1


51/109


51

Step 8: Derive System Views (SV)Which systems views are appropriate?

21


52/109


52

Step 9: Allocate OV to SVHeres were the art of system engineeringcomes into play


53/109


53

Step 10: Prepare Interface DiagramsInterfaces fall out of the allocation

Which views describe the interfaces?


54/109


54

Step 11: Define Resources, Error

Detection & RecoveryNeeds to be done throughout the analysis,not wait to the last minute


55/109


55

Step 12: Perform Dynamic AnalysisCan be done with the operational and systemviews

Critical to ensure that your logic is executableCan be used to predictperformance when moredetailed information on

systems is available


56/109


56

Step 13: Develop Operational

Demonstration Master PlanA major goal of architecture development isto ensure that the architecture can be

bought offUse requirements derived fromtechnical, operational andsystem views; they specify the

functional, physical and performancerequirements


57/109


57

Step 14: Provide OptionsPresent the architectural options to yourcustomer let them make the decision

The options come from theunderlying trade studies

The next section will discussthis in more detail


58/109


58

Step 15: Graphics, Briefings and

ReportsThis step occurs throughout the process,usually in response to in-process reviews,

such as an SRR, SDR, PDR and CDRPart 4 will discuss ways topresent the information needed


59/109


59

Part 4: Packaging and Selling YourArchitecture


60/109


60

What have I been told to use?Standards (e.g. C4ISR ArchitectureFramework, Joint Technical Architecture, DII

COE, ISO9000, DoD 5000)Guidance documents and Directives (e.g.JV 2020, Defense Planning Guidance, DoDDirectives)

Capability Maturity Models (standards foryour process; e.g. SEI SW CMM; CMMI)


61/109


61

What might be useful to choose to

use?Other standards (not required)

System engineering tools (e.g., CORE, Slate,System Architect)

Simulation and Modeling tools (e.g., CORE,OpNet, COMNet, engagement models)

Word processing tools (e.g., MS Word)

Spreadsheets (e.g., MS Excel)Drawing tools (e.g., PowerPoint, netViz,

Adobe Illustrator)


62/109


62

Who is my target audience?Users

Developers

Acquisition personnelWarfighters

Recognize that you may have to tailor individualproducts for different audiences and most will

not understand any system engineering diagrams,except the OV-1


63/109


63

Example: EFFBD vs. PowerPoint

AND

C.1

PerformCustomerFunctions

0

Operate C4ISRManagement

System

C.2

PerformCollectorFunctions

AND

requests productsstatus

tasking data

PerformCustomerFunctions

OperateC4ISR

ManagementSystem

PerformCollectorFunctions


64/109


64

What questions does your target

audience ask?How does this help me understand thearchitecture better?

How does this help me make a decision?How does this help me get the best bang forthe buck?

How does this enhance National Security?

How does this get me my next promotion?


65/109


65

How do we put together an effective

architecture?Do the systems engineering right, thenproduce any required documentation (e.g.

C4ISR AF Views)Summarize the results in an easy to readsection, then provide detail in appendices

Provide a simple briefing that focuses on the

findings, not how you got there You will need the how you got there to back up

the findings


66/109


66

How can I show that elements of my

architecture provide value?One of the recent standards adopted by theGeneral Accounting Office (GAO) is BalancedScorecard*

Balanced Scorecard is an approach to providedecision makers with a way to make investmentstrategy decisions

Balanced Scorecard has three major steps:

Step 1. Define Mission and Desired Outcomes Step 2. Measure Performance Practices

Step 3. Use Performance Information

* GAO Report GAO/AIMD-

98-89, Measuring

Performance and

Demonstrating Results of

Information Technology

Investments


67/109


67

Balanced Scorecard ExampleEvaluation

CriteriaBaseline

Proposed Concepts/

Elements

Concept/Program Element:

Performance

Cost

Concept/Technology Maturity

Schedule for

Implementation

Key Functional

Requirements

Note thatthisscorecardisjustawaytoportraycost,schedule andperformance (andrisk) the basisforsystemsengineering


68/109


68

Part 5: Summary


69/109


69

Key DecisionsA proven methodology

A set of easy to use tools that support the

methodologyAn architecture development process

Other Factors

An achievable schedule

The right people


70/109


70

C4ISR Products NeededDepend on the phase that you are applyingthe Framework

These products should be a natural part ofyour methodology

Remember: Systems Engineering is your methodologyC4ISR products are your output


71/109


71

Questions ?????

Discussion !!!!!


72/109

2002 Systems and Proposal Engineering Company.All Rights Reserved. 72


73/109


Backup slides


74/109


Systems Engineering [INCOSE]

Systems Engineering is an interdisciplinary approach and meansto enable the realization of successful systems. It focuses on defining customerneeds and required functionality early in the development cycle, documentingrequirements, then proceeding with design synthesis and system validationwhile considering the complete problem:

Operations

Performance

Test

Manufacturing

Cost & Schedule

Training & Support

DisposalSystems Engineering integrates all the disciplines and specialty groups into ateam effort forming a structured development process that proceeds fromconcept to production to operation. Systems Engineering considers both thebusiness and the technical needs of all customers with the goal of providing aquality product that meets the user needs.


75/109


Architecture uses

Planning Programming

BudgetingExecution

StrategicPlanning

ProgramDefinition

BudgetingExecution

Threat

YourOrganization

ProgramDefinition$$$

Budgeting

Programs.Projects,

ActivitiesExecution

Products andServices

DefenseAgency

StrategicPlanning


76/109



Systems Engineering Process


77/109



Systems Engineering Process (simplified)


78/109


DoD Systems Engineering and the VEE


79/109



DoD Systems Engineering and the VEE


80/109


Architecture Context Defense Agency

Technology

DevelopmentAcquisition

Management

Information

Systems

Combat

Support

Resource

Management

Agency

Director

CommandersInChief

(CINCs)

Services

Components

JointChiefsof

Staff

(JCS)

Service

Acquistiion

Agencies

Specific

Review Committee

Congress

Secretaryof

Defense

(SECDEF)Acomplexseriesofinteractionswith

organizationsinside andoutsideCustomersOrganization


81/109


Architecture Context Tactical Unit

C4ISRManagement

System

Brigade

Company

Platoon

JTF

TUAV

Platoon

Platoon

Brigade

Company


82/109


Related Websites


83/109


Software Productivity Consortium - Sarah Sheard

Frameworks Quagmire


84/109


Essential C4ISR Products

AV-1. Text file (not provided)

AV-2. Text file (provided)

OV-1. Graphics (two provided)OV-2. Operational Elements Physical BlockDiagram (provided)

OV-3. Table in text file (provided)

SV-1. Context diagram Physical BlockDiagram (provided)

TV-1. Table in text file (provided)


85/109


Hi-level Operational Concept Graphi (OV-1) (template)


86/109


High level Operational Concept


87/109


Operational Node Connectivity (OV-2)


88/109


System Interface Description (SV-1)

2

1

Wide Area


89/109


Platoon

Tactical

UAV

Surveillance

Brigade

JTF

Enemy

Troops

Scenario 1: Tactical UAV

Controlled by JTF HQ (OV-1)

OV-1.Scenario 1

Wide Area


90/109


Platoon

Tactical

UAV

Surveillance

Brigade

JTF

Enemy

Troops

Scenario 2: Tactical UAV

Controlled by Brigade (OV-1)

OV-1.Scenario 2


91/109


OV-2. ScenarioParticipants

Tactical ic icati s

ri ade-JTF icati s

ri ade evel

erati al lem...

JTF evel ( and)

Operati nal lem...

lat n evel

Operati nal lem...


92/109


SV-1. Context Diagram

Command

ink

et

rn

ink

equest

ink

Collector

roduct

in

k

C.1

Customers

Component

C.2

Collectors

Component

Y .1

C4I

anagement

stem

System


93/109


Trace to All Products

SV-7

SV-9SV-8

OV-3SV-1

OV-6a

OV-4

OV-5 OV-2

OV-1

OV-6c

OV-6b

SV-10c

SV-4SV-2

SV-10bSV-10a

OV-7

SV-11

SV-6

SV-7

SV-5

AV-1 AV-2 TV-1

Trace to all Products

SV-3

Trace to All Systems Products

OV-6a

AV-3

DoD Architecture Framework V 2.1 (Draft)


94/109


Myths


95/109


Myth #1: The Framework is a nice tohave, but you dont really have to use it

In reality, for the C4ISR community in DoD,there is a memorandum that directs the useof the Framework for all C4ISR architecture

We see the C4ISR Architecture Framework as acritical element of the strategic direction in theDepartment, and accordingly direct that all on-going and, planned C4ISR or related architectures

be developed in accordance with Version 2.0.*.

*From a memorandum dated February 23, 1998, signed by the USDA&T, Acting ASD/C3I,and Director for C4 Systems, Joint Staff


96/109


Mandatory Use

direct all on-going or planned

C4ISR or relatedarchitectures beplanned inaccordance with

Version 2.0.


97/109


Myth #2: Only the essential products needbe created

In reality, you need to create many of thesupporting products to obtain the essentialproducts or its just viewgraph engineering.

Myth #3: The Framework provides a


98/109


Myth #3: The Framework provides amethodology for developing architectures

In reality, no detailed methodology was provided. Itprovides some guidelines and suggested processsteps in Section 3 (which is good reading formethodology developers), but there is no detailedmethodology that could evaluated using the SE-CMMor other process standard

This lack of a methodology was on purpose, to avoidforce fitting a methodology on the CINCs, Services

and Agencies. Instead it was assumed that each ofthese organizations and their support contractors hadeffective methodologies in-place

The Framework only provides a means for comparingarchitectures by means of these products.


99/109


99

Architecture Six Step Process

C4ISR Architecture Framework V 2.0

Myth #4: An architecture can be


100/109


100

Myth #4: An architecture can bedeveloped in one view only

In reality, the views are just that, views of anarchitecture and hence are not that easilyseparable

You may get away with it when trying todocument existing architectures, but itguarantees that each view will be sub-

optimizedIdeally, they should be worked onsimultaneously by the same group of people.

Myth #6: The Framework was developed


101/109


101

Myth #6: The Framework was developedto provide Architectures as something

different from the systems we engineer

In reality, the participants in the FrameworkPanel were all (or mostly) systems engineers.

The products are all systems engineeringproducts

The difference between systems andarchitecture engineering in usually in terms ofbreadth and depth. Architecture definitionsare usually broader and shallower thansystems, but the same techniques work forboth.

Myth #7: Using the Framework doesnt


102/109


102

Myth #7: Using the Framework doesn trequire the use of a database tool

In reality, when looking at the AV-2,Integrated Dictionary essential product, adatabase becomes necessary in dealing withall the data. The C4ISR Core ArchitectureData Model (CADM) provides a (complex,IDEF-based) schema for this database.However, not tool was directed, since thegroup believed that sufficient COTS toolswould do the job.


103/109


103

Comparison Enabler


104/109


104

Myth #5: The Framework provides a definitivemeans for comparing architectures

In reality, the Framework and in particular theessential products do not provide enough informationfor decision makers

No common metrics are provided for comparingperformance or cost

The architectures could actually reference different levels ofdecomposition, no hierarchy was define

These limitations were noted at the time and were

determined to be to difficult to arrive at that time.The assumption was that version 3.0 (which has yetto occur) would try to resolve these deficiencies


105/109


105

One Architecture Three Views


106/109


106

Each View Specific Products and References


107/109


107

Framework and the Lifecycle

Frameworkfacilitates allphases of theC4ISR lifecycle

Template of Desired Process


108/109


108

Template of Desired ProcessCOPYRIGHT by A. H. Levis (INCOSE Tutorial, March 2001)

Alternative approaches and tools can be used to design theC4ISR Architecture views

Alternative approaches and tools can be used to developthe executable model

Measures of Performance (MOPs) and Effectiveness(MOEs) are needed to evaluate and compare architectures

Architecture

Design

ExecutableModel

Construction

ArchitectureAnalysis and

Evaluation

D

O

M

A

I

N

C4ISR AF

Product

Generation

C4ISR AF

A hit t M th d l


109/109

Architecture MethodologyCOPYRIGHT by A. H. Levis (INCOSE Tutorial, March 2001)

EXE

CUTABLE

USER/ARCHITECT

INTERACTION

Technical

Arch.view

Operational

Arch.view

Systems

Arch.view

Integrated

Dictionary

USER

SPECIFIED

BEHAVIORS

ARCHITECTURE

SPECIFIED

BEHAVIORS

Date post:	30-May-2018
Category:	Documents
Upload:	incosewma
View:	216 times
Download:	0 times