© A. H. Levis INCOSE L. 3 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 3 STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESS.

© A. H. LevisINCOSE L. 3 - 1

C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES

LECTURE 3

STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESS

ALEXANDER H. LEVIS

LEE W. WAGENHALS


OUTLINE

• Fundamentals

• Structured Analysis and Roadmap

• Concordance issues

• Mapping from SA to the C4ISR Constructs

• The C4ISR Architecture Design Process – SA version

• Conclusions


BASIC PHASES

• The architecture design process can be partitioned in three phases:

– Analysis: definition of elements and development of static, behavioral, and implementation

diagrams

– Synthesis: development of executable model

– Evaluation: behavioral and performance analysis

ANALYSIS(C4ISR Views and Products)

SYNTHESIS(Executable) EVALUATION

DOMAIN


BASIC PHASES

• While the design process can be depicted as a sequence of the three phases (Analysis, Synthesis, and Evaluation) this is an abstraction; in practice the process is very iterative

ANALYSIS SYNTHESIS EVALUATION

DOMAIN


SYSTEMS ENGINEERING APPROACH:ANALYSIS PHASE

Unless the Functional and Physical Architectures are restricted to very high level representations, the Operational Concept is needed to drive both representations and keep them compatible

FUNCTIONALARCHITECTURE

OPERATIONALCONCEPT

PHYSICALARCHITECTURE

MISSION

FUNCTIONALDECOMPOSITION

ORGANIZATIONMODEL


OPERATIONAL CONCEPT

• The architecture development process must start with an Operational Concept

• The initial definition of the Operational Concept can be very abstract; as the architecture development process evolves, the Operational Concept becomes more specific

• An Operational Concept describes how a mission is to be carried out

• There is no quantitative procedure for deriving an Operational Concept

• Given a set of goals, given experience and expertise, humans invent Operational Concepts


OPERATIONAL CONCEPTS

• Good Operational Concepts are based on a simple idea of how the overriding goal is to be met

Example: “Centralized decision making, distributed execution”

Non-Example: “Every customer must be serviced in less than an hour” This is not an operational concept – it is a goal.

• Often, an operational concept is described using a graphic - the Operational Concept Diagram. In the past, this diagram was incorrectly referred to as an architecture.


OPERATIONAL CONCEPT

NOTE: The Operational Concept can be described in narrative form as well as graphically in the form of an Operational Concept Diagram. The Operational Concept Diagram alone tends to be ambiguous; the accompanying narrative should clarify the ambiguities

Opn’l Bdry

FSCL

TLAM

JFMCC

JFSOCC

609AIS

513ACE

WOC

JFC JIC/JOC

JFACC(AOC)

DJFLCC(DOCC)

Deep

Operations

Area

FSCL

Opn’l Bdry

MarineForces

ArmyForces

F2C2

CALCM Army TACMS

FA-18

SOFCoalition

Forces

JICCENT

National Systems

Rivet Joint

AWACS

JSTARS F-15EU-2

BCL

F-117

Intelligence SystemsSanctuary or CONUSSplit-Based andReachback

USCENTCOM Deep Operations in the Joint Operations Area

UAV


FUNCTIONAL ARCHITECTURE

• The Functional Architecture is the centerpiece of the Structured Analysis approach

• Definition: A Functional Architecture is a set of activities or functions arranged in a specified (partial) order that, when activated, achieves a defined goal.

• The Functional Architecture representation ranges from:

– A pure Activity or Process model with a Data Dictionary

– An Activity model that is supported by a Data model, with a common Data Dictionary

– An Activity model that includes an embedded Rule model (e.g., Activation rules in IDEF0), supported by a Data model, with a common Data Dictionary

• The Functional Architecture does not include a Dynamics Model or an Organization Model


FUNCTIONAL ARCHITECTURE

FUNCTIONAL ARCHITECTUREIS

DATA MODEL

RULE MODEL

PROCESS MODELDICTIONARY

DATA

IDEF0 or Data Flow Diagram

IDEF1x or Entity-RelationshipDiagram

Embedded on IDEF0 or in the State Transition Diagrams


PHYSICAL* ARCHITECTURE

• The set of physical resources (nodes) that constitute the system and their connectivity (links)

• The Physical Architecture indicates what is possible

In the absence of inputs and an Operational Concept, the Physical Architecture does not show how a mission is to be performed

• Physical components (represented by boxes) are capable of carrying out processes

• The interconnections (directed links) between components indicate that a directed flow is possible (e g , information flow)

* This often referred to as the Systems Architecture in the literature – it is not the Systems Architecture view of the C4ISR AF


EXAMPLE: NTCS-A

NTCS-A 2 0 CV/CVN OPEVAL

HARDWARE CONFIGURATION

FLAG PLOT

F/O ETHERNET LAN

OA-XXX(V)2GFCP

OJ-XXX(V)6

DTC-2

OA-XXX(V)3

SW-3000

NIPS

A/BSWITCH

FIST386

OJ-XXX(V)4

DTC-2

ATPHP

9020C

TFCC SUPPLOT

CVIC

CDC ASWM

MAPPINGAND

IMAGERY386

GENSERPOST

OJ-XXX(V)4

DTC-2

OJ-XXX(V)4

DTC-2

OJ-XXX(V)5

DTC-2

OJ-XXX(V)5

DTC-2

OJ-XXX(V)5

DTC-2

OL-XXX(V)2

DTC-2

OJ-XXX(V)6

DTC-2

OJ-XXX(V)5

DTC-2

OJ-XXX(V)8

DTC-2

OJ-XXX(V)3

DTC-2

OJ-XXX(V)8

DTC-2

OJ-XXX(V)3

DTC-2

MAPPINGAND

IMAGERY386


ORGANIZATION MODEL

• The Organization Model shows the organization entities and their interrelationships: command structure, information flows, resource allocation, etc....

(A generalized Physical Architecture may include in it an Organization Model)

• Many different representations of an Organization are possible - each featuring some different aspect of the organization

• The Organization Chart represents the command (line and staff) relationships of the formal organization, if it is hierarchically structured

• Many other constructs represent the informal organization, e.g., the communication patterns


USTRANSCOM ORGANIZATION AND RELATIONSHIPS

CJCS

USTRANSCOM

NCA

MSC MTMC AMC

Combatant Command Line

Coordination

1) Direction from theNCA through theCJCS.

2) USCINCTRANS managesdeployment and redeployment offorces and material in compliancewith the supported CINC’sOPLANs.

3) USCINCTRANS tasks the TCCs(as appropriate) for execution ofairlift, sealift, land movement, andcommon-user seaport operations.

(1)

(2)

(3)

From C4ISR Arch.Framework, v. 2


DYNAMICS MODEL

• A representation of the dynamic behavior of the architecture in the form of

– State Transition Diagrams

– Operational Sequence Diagrams

– Key Threads, etc.

• The Dynamics model is not an Executable Model; it describes dynamic behavior, but does not generate it – only the executable model does.


STATE TRANSITION DIAGRAM

ENTERING CONTROLLEDSPACE

CONTROLLED: NO ACTION

MANEUVERING

IN CONFLICT

LEAVING CONTROLLEDSPACE

HANDOFF TOLOCAL ATC COMPLETED

REVISECLEARANCE ON

PILOT'S REQUEST

DETECTDEVIATION

MANEUVERINGCOMPLETE

DETECTCONFLICT

REVISECLEARANCE

RESOLVECONFLICT(NO MANEUVER)

COORDINATE INTER-SECTOR TRANSFER

COORDINATE TRANSFER OUT

COORDINATE INTER-SECTOR TRANSFER

COORDINATE TRANSFER OUT

From C4ISR Arch.Framework, v. 2


TOOLS AND TECHNIQUES

• The Structured Analysis approach sits on four pillars:

– Activity model

– Data model

– Rules model

– Dynamics model

• It also requires an Integrated Dictionary

• The weakness of Structured Analysis is that the four models are obtained using different approaches and different tools. This leads to the problem of CONCORDACE

• The four models and the dictionary are in concordance if they are coherent and consistent, i.e., if they really are different views of a single architecture


MODEL CONCORDANCE

• Model Concordance is the process of making sure that the

Structured Analysis models are coherent and consistent

with one another

• The models are balanced as follows:

– Each ICOM in the IDEF0 model is represented as an

entity or an attribute of an entity in the IDEF1x model

– The attributes of the entities are the clauses used in the

rule model


REMARKS

• Concordance of the various models

– A tedious, but essential activity

– A total view is necessary from the beginning so that the various models are developed in the context of the other ones (this is one of the Architect’s tasks)

• How do the models inter-relate?

• How do we construct the Integrated Dictionary?

StartWait for incoming

threat

Threat detected

Intercepting order issued

Interceptor en route

Interceptor in firing

range

Weapons away

Contact message sent

Threat replied and complied

Threat silent

incoming threat ««398»»

Generate intercepting order ««399»»

Interceptor takes off ««400»»

Interceptor close to the threa ««401»»

state=war ««405»»

response from the threa t««403»»

state=peace ««402»»

no response ««404»»

order=fire ««406»»

Return to base««407»»

Return to base««408»»

Function : S1: if (Surv-Dir-Content=default) and (Threat-Status=incoming) then (TP-Update=new) and (Threat-Status=sensed) S2: if (Surv-Dir-Content=track-interc) and(Threat-Status=engaged) then (TP-Update=in_firing_range) S3: if (Surv-Dir-Content=assess_kill) and (Threat-Status=destroyed) then (TP-Update=killed)

Function C1: if (TP-Update=new) then (Order-Content=intercept) C2: if (Report-Content=interceptor_away) then (Surv-Dir-Content=track_interc) C3: if (TP-Update=in_firing_range) and (State=war) then (Order-Content=fire) C4: if (TP-Update=in_firing_range) and (State=peace) then (Order-Content=make_contact) C5: if (Enemy-Response=silence) and (Report-Content=contacted) then (Order-Content=fire) C6: if (Report-Content=weapons_away) then (Surv-Dir-Content=assess_kill)

Function A1: if (Order-Content=intercept) and (TP-Update=new) then (Action=take_off) and (Report-Content=interceptor_away) A2: if (Order-Content=fire) then (Action=launch_weapons) and (Report-Content=weapons_away) A3: if (Order-Content=make_contact) then (Action=contact) and (Report-Content=contacted)

Rules for the scenario driver:if (Action=take_off) then (Threat-Status=engaged) after delayif (Action=launch_weapon) then (ThreatStatus=destroyed) after delayif (Action=contact) and (Threat-Behavior=reply_comply) then

(Enemy-Response=reply_and_comply)if (Action=contact) and (Threat-Behavior=silent) then (Enemy-Response=silence)

Additional rule for Sense Function:- Associate threat and interceptor tracks: if (Surv-Dir-Content=track_interc) and (Threat-Status=sensed) and (THREAT.Interceptor-ID=0) then (THREAT.Interceptor-ID=SURVEILLANCE-DIRECTIVE.Interceptor-ID)

Sense

Command

Act

inc

or

Surv-Dir-Content««298»»: default««241»», track_interc««299»»««327»»««422»», assess_kill««287»»««337»»

Threat-Status««242»»: incoming««245»», sensed««244»»««423»», engaged««240»»««345»», destroyed««305»»««347»»

TP-Update««306»»: new««307»»««325»»««339»», in_firing_range««308»»««328»»««331»», killed««309»»

Order-Content««296»»: intercept««311»»««338»», fire««312»»««335»»««340»», make_contact««313»»««341»»

Action««314»»: take-off««315»»««343»», launch_weapon««316»»««346»», contact««317»»««348»»««350»»

Report-Content««318»»: , interceptor_away««319»»««326»», weapons_away««320»»««336»», contacted««321»»««334»»

Enemy-Response««322»»: reply_and_comply««323»», silence««324»»««352»»

State««333»»: peace««332»», war««329»»

Threat-Behavior: reply_comply««349»», silent««351»»

THREAT.Interceptor-ID««420»»: 0««421»», 1, 2, ...

new

Track-IDThreat-StatusInterceptor-ID (FK)

THREAT /1

Threat-Status

THREAT

Interceptor-ID

Track-ID (FK)Interceptor-ID (FK)Surv-Dir-Content

SURVEILLANCE-DIRECTIVE /2

Surv-Dir-Content

SURVEILLANCE-DIRECTIVE

Track-ID (FK)Interceptor-ID (FK)TP-Update

TACTICAL-PICTURE /3

TP-Update

TACTICAL-PICTURETrack-ID (FK)Interceptor-ID (FK)State (FK)Order-ContentOrder-NB (AK1)

ORDER /4

Order-Content

ORDER

State

RULES-OF-ENGAGEMENT /5RULES-OF-ENGAGEMENT

State

Track-ID (FK)Interceptor-ID (FK)Report-ContentReport-NB (AK1)

REPORT /6REPORT

Report-Content

is reported in

is used for the generation of

is consistent with

Track-ID (FK)Interceptor-IDAction

CONTROL-TO-INTERCEPTOR /7CONTROL-TO-INTERCEPTOR

Action

is reported into engage

results in

can trigger

constrains the construction of

constrain the generation of

Track-ID (FK)Interceptor-ID (FK)Enemy-Response

INTERCEPTOR-REPORT /9

Enemy-Response

results in

can trigger

INTERCEPTOR-REPORT

ACTIVITY

DATA

RULE

DOMAINS

DYNAMICS

Sense««274»»

A1

Command««276»»

A2

Act««277»»

A3

ORDER««284»»

SURVEILLANCE-DIRECTIVE««279»»

TACTICAL-PICTURE««281»»

REPORT««286»»

NEW-TRACK««283»»

RULES-OF-ENGAGEMENT««280»»

THREAT««278»»

CONTROL-TO-INTERCEPTORx««285»»

INTERCEPTOR-REPORT««90»»

ICOM/Entity

Activity/Rule

Attribute/Domain

Transition/Rule

Value/Rules


REMARKS

• Need for software having features that can assist in creating an maintaining concordance of process, data, rule and dynamics models

– page link and HyperText can provide graphical connections between critical items in these models

– overlapping of hyper text can be used to detect errors

• There is no such software on the market or in development; Visio™ can be used to draw the models and maintain a common dictionary (work in progress)

• Maintaining Concordance throughout the design process is an Architect’s responsibility


SYSTEMS ENGINEERING: SYNTHESIS

Mapping the Physical onto the Functional Architectureor vice versa and adding the Dynamics Model leads to anexecutable model of the Architecture

ORGANIZATIONMODEL

OPERATIONALCONCEPT



DYNAMICS MODEL EXECUTABLE

MODEL


THE EXECUTABLE MODEL

• Creating an Executable model requires concordance of the multiple models

• If there are concordance errors, they will appear in the construction and running of the executable model

• Even though the executable model is not required by the C4ISR AF, it is essential for

– checking the validity of the architecture design

– providing the means for the evaluation of the architecture (logical, behavioral, and performance levels)

– providing a testbed for system designs


THE EXECUTABLE MODEL

• An Executable architecture model is developed for a given Operational Concept

• An Executable architecture model shows the allocation of resources to functions, the flow of data, the conditions under which functions are performed, and the order in which they are performed. It may also show the organizational entities assigned to perform the functions

• Behavior analysis and performance evaluation can be carried out using scenarios consistent with the Operational Concept


A DETAILED VIEW

ORGANIZATIONMODEL

OPERATIONALCONCEPT



EXECUTABLEMODEL

DYNAMICS MODEL

MOPS, MOEs

TECHNICALARCHITECTURE

DATA MODEL

RULE MODEL

PROCESS MODEL

DATA

MISSION

EVALUATIONPHASE


EVALUATION PHASE

• The executable model can be used for:

– Simulation

– Analysis

• The mathematical framework used for the executable model and the supporting software application bring with them tools and procedures for evaluation

• Define parameters that characterize the architecture design

• Define measures of performance (MOPs)

• Identify the requirements

• Define measures of effectiveness (MOEs) that express how well the architecture meets the requirements


ARCHITECTURE EVALUATION

• User behavioral requirements vs. architecture behavior

EXECUTABLE

ARCHITECTURESPECIFIEDBEHAVIORS

USERSPECIFIEDBEHAVIORS

USER INTERACTION

TechnicalArchitecture

FunctionalArchitecture

PhysicalArchitecture

IntegratedDictionary

SE Constructs


CORRESPONDENCE

FUNCTIONALARCHITECTURE VIEW

PHYSICALARCHITECTURE VIEW

SYSTEMSARCHITECTURE VIEW

OPERATIONALARCHITECTURE VIEW

Systems Engineeringconstructs C4ISR constructs


CONCLUSION

• The Systems Engineering process based on Structured Analysis is capable of supporting the design of a C4ISR Architecture across all three stages – Analysis, Synthesis, and Evaluation

• The Structured Analysis process produces models that contain within them all the information needed by the Essential and Supporting products of the C4ISR Architecture framework


MOTIVATION

• The C4ISR Architecture Framework (v. 2.0) provides high level guidance and a set of essential (mandatory) and supporting products for representing an architecture

• It does not identify a specific process for developing the architecture views and the associated products.

• A process is needed to

– identify the relationships among products

– guide in the selection of tools needed

• The process must be generic to accommodate current practices


PROCESS FOR PRODUCT DEVELOPMENT

• A six stage process has been developed for generating the Essential and Supporting products for the Operational and Systems architecture views

• The process has been derived by approaching the problem from the systems engineering point of view and using Structured Analysis; alternative processes are possible

• Each product has been perceived as an Entity containing data; a formal Data Model was derived showing the relationship among the various entities

• The relationships among the entities induced a partial ordering of the entities which led to a series of steps for their production

• The process utilizes existing tools and techniques to derive the requisite products and is compatible with the development of an Executable model


KEY ENTITIES

• Operational Nodes and Operational Elements

• Activities

• Needlines

• Operational Information Elements

• Organization

• Asset

• System, System Element, System Component

• System Function

• System Node

• Link

• System Information Element

• Performance Parameter Set

• Networks and Interfaces

(Systems)

(Operational)

(Organizational)

KEY ENTITIES

Ch. 3 - 5

Operational

Node

Operational

Element

Needline

Operational Information

Element

System Node

SystemSystem Element

System Compon

ent

System Compon

ent

Link

System Information

Element

System Function

Activity

Networks

Interface

Asset

Organization

Has

Representsis Associated with Is associated with

Performs/ Is performed by

Implements/ is implemented by


Implements/ Is implemeneted by

Transmits

Implements/ Is implemented by

Contains

Is Attached To

Is Attached To

Contains

Enables

OPERATIONAL VIEW

SYSTEMS VIEW

Has

Maps To

Is a

May Represent

Parameter Performance

Set


APPROACH

Systems Engineering Approach: Structured Analysis

Structured Analysis process

C4ISR AFProducts

Executable Model

of Architecture

Architecture

OVERLAYING THE SYSTEMS ENGINEERING APPROACH

FUNCTIONAL ARCHTECTURE

PHYSICAL ARCHTECTURE

Operational

Node

Operational

Element

Needline


Element

System Node

SystemSystem Element

System Component

System Component

Link

System Information

Element

System Function

Activity

LAN/WAN

Parameter Performance

Set

Interface

Asset

Organization

Has

Representsis Associated with

Is associated with


Implements/ is implemented by



Transmits


Contains

Is Attached To

Is Attached

To

Contains

Enables

OPERATIONAL VIEW

SYSTEMS VIEW

Has

Maps To Is a

May Represent

Operational Concept

Functional Decomposition

Activity Model OV-5 STD

OV-6b

Rule Model

Logical Data

Model

ORGANIZATIONALMODEL

L. 3 - 9

THE SIX STAGE PROCESS

Define Operational

Nodes

Define Operational Elements

Determine Needlines

Define Operational Information Elements

Define System Nodes

Determine Systems, Elements,

Components

Define Links

Define System

Information Elements

Allocate Activities to systems to

Define System Functions

Allocates Activities to Oerational Elements

Select LAN/WAN Networks

Define Parameter

Performance Set

Define Interfaces

Determine Assets

Select Organizations

OPERATIONAL VIEW

SYSTEMS VIEW

Create High Level Operational

Concept Graphic with Textual Description

Create Functional

Decomposition

Activity Model (OV-5)

STD (OV-6b)

Rule Model (OV-6a)

Logical Data Model (OV-7)

Integrated Dictionary

(AV-2)

System Desciptions

(D12)

Tactical Description of Doctrine, Tactics,

Operational Procedures

(D5)

Operational Information Elements

(D6)

Universal Joint Task

List (D2)

Operational Concept

(AV1 and D1)

Organization List (D3)

Organizatinal Relationships

(D4)

Operational Concept Graphic OV-1

Operational Node

Connectivity Description

(OV-2)

Select Functions

Create Activity Model

Create Logical Data

Model

Define Logical Rules

Create Operational State

Transition Description

Ensure Concordance

Determine Organizational Relationships

Command Relationship

Chart (OV-4 )

Create System

Functionality Description

Create Physical Data

Model

Create System2

Matrix

Create System

Communications Description

Create System Interface

Description

Create System

Information Exchange

Matrix

Create System

Performance Parameter

Matrix

Create System Rule

Model

Create System

Evolution Description

Create System State

Transition Model

Create Operational

Node Connectivity Desciption

Create Operational Information Exchange

Matrix

Operational Infromation Exchange

Matrix (OV-3)

Create Operational Activity to System

Function Traceability

Matrix

Operational Activity to

System Function Traceability Matrix

(SV-5)

System Interface

Desciption (SV-1)

System Communications

Description (SV-2)

Systems2 Matrix (SV-3)

Systems Functionality Description

(SV-4)System

Information Exchange Matrix

(SV-6)

System Evolution

Description (SV-8)

System State Transition

Description (SV-10b)

Physical Data Model (SV-11)

System Performance

Parameter Matrix (SV-7)

Communication Systems

Description (D9)

Migation Systems

(D11)

System/ Functions

(D8)

System Performance

Attributes (D10)

STAGE 0 STAGE 1 STAGE 2 STAGE 3 STAGE 4 STAGE 5

Maintain Integrated Dictionary

All Processes

States and Events

(D7)

Create System

Technology Forecast

Systems Technology

Forecast (SV-3)


REMARKS

• This is a Data Flow Diagram of the Six Stage Process. It starts with the needed inputs (terminators/sources) on the left (Stage 0) and ends with the last products (terminators/sinks) on the right.

• The top half contains activities or transformations related to the Operational Architecture (OA)view; the bottom half to the Systems Architecture (SA) View

• Note that the two views are crosslinked several times. This was the first lesson learned by those who tried to do C4ISR Architectures: The OA view and the SA View cannot be developed independently from each other

• The crosslinking is in both directions: system information is needed in the OA view and activity information in the SA view

• The OA view can be done independently, but only at a high level of abstraction (Domain level). The SA view cannot be done independently of the OA view.


REMARKS

• C4ISR Architecture products are obtained at every step of the process. This means that, if concordance is not maintained rigorously from the start, there will be continuous need to revise and update already developed products

• Development of such a Data Flow Diagram and the associated Data Model of the products that will be needed for a particular architectural effort is a key responsibility of the Architect.

– The Data Model specifies the dependencies among models and determined the selection of supporting products that must be developed

– The Data Flow Diagram indicates the sequence in which products can be developed and specifies the data needed to construct them

SIX STAGE PROCESS – ESSENTIAL ONLY

Define Operational

Nodes

Define Operational Elements

Determine Needlines

Define Operational Information Elements

Define System Nodes


Components

Define Links

Define System




Allocates Activities to Operational Elements

Determine Assets


OPERATIONAL VIEW

SYSTEMS VIEW


Concept Graphic

with Textual Description

Create Functional

Decomposition

Logical Data Model

(OV-7)

Integrated Dictionary

(AV-2)

System Desciptions

(D12)

Tactical Description of

Doctrine, Tactics, Operational Procedures

(D5)

Operational Information Elements

(D6)

Universal Joint

Task List (D2)

Operational Concept

(AV1 and D1)



(D4)

Operational Concept Graphic OV-1

Operational Node


(OV-2)

Select Functions


Create Logical Data

Model


Create Operational State

Transition Description

Ensure Concordance

Create System


Create Physical

Data Model

Create System Interface

Description

Create Operational

Node Connectivity Desciption


Matrix


Matrix (OV-3)

System Interface

Desciption (SV-1)

Physical Data Model (SV-11)


Description (D9)

Migation Systems

(D11)

System/ Functions

(D8)

System Performance

Attributes (D10)

STAGE 0 STAGE 1 STAGE 2 STAGE 3 STAGE 4 STAGE 5

Maintain Integrated Dictionary

All Processes

States and Events

(D7)

Created by: System Architectures Laboratory George Mason University Fairfax, VA 22020 [email protected]


THE SIX-STAGE PROCESS

STAGE 0: Problem Definition and Collection of Domain Information

--------------------------------------------------------------------------------------------------

STAGE 1; Operational Concept and Requirements

STAGE 2: Functions and Organizations

STAGE 3: Activity Model, Logical Data Model, Needlines, System Nodes, System Elements and Functions, and Task

Allocation

STAGE 4: Operational Information Elements and Exchanges, System Functionality Description, Physical Data

Model

STAGE 5: System Information Elements and Exchanges, LAN/WANs, System Interface Descriptions, System

Performance


STAGE 1

Operational Concept

(AV1 and D1)


Concept Graphic

with Textual Description

Operational Concept

Graphic OV-1


STAGE 2


Operational Concept

(AV1 and D1)

Universal Joint Task

List (D2)


(D4)

Command Relationship

Chart (OV-4 )

Determine Organizational Relationships


Determine

AssetsDefine

Operational Elements Define

Operational Nodes

Create Functional

Decomposition

Select Functions


STAGE 3a

Activity Model (OV-5)

STD (OV-6b)

Rule Model

(OV-6a)

Logical Data

Model (OV-7)


Create Logical

Data Model


Create Operational

State Transition

Description

Ensure Concordance

Create Functional

Decomposition

Tactical Description of

Doctrine, Tactics,

Operational Procedures

(D5)

From Stage 2

STAGE 3bCreate Functional

Decomposition

Define Operational

Elements

Define Operational

Nodes

From Step 2


Determine Needlines

Allocates Activities to Operational

Elements

Allocate Activities to Systems to



Components

Define System Nodes

System/ Functions

(D8)

System Desciptions

(D12)

Determine

Assets

Define Links


PROCESS STAGES

1 Once the basic information has been assembled in Stage 0, the process starts by converting the operational concept that implies or includes organizations and actions or tasks into the operational concept graphic with a textual description

2 The organizations implied in the operational concept have assets that are the basis for systems in the physical architecture and operational nodes and elements. The relationships between organizations imply communications requirements. The actions or tasks help in the selection of activities from the Uniform Joint Task List to form the functional decomposition.

3 A full functional architecture with activity model, data model, and rule model is created along with a dynamics model. Concurrently the initial physical architecture is defined using systems, elements, components and links. The activities are allocated to both organizational elements and to system functions.

STAGE 4

Determine Needlines

Logical Data

Model (OV-7) Define


Elements

Create Operational

Node Connectivity Description


Matrix

Allocates Activities to Operational

Elements




Components

Create System


Create Operational

Activity to System Function

Traceability Matrix Create

Physical Data

Model

Operational Activity to System

Function Traceability Matrix

(SV-5)

Physical Data

Model (SV-11)


Matrix (OV-3)

Operational Node


(OV-2)


(SV-4)

From Stage 3

STAGE 5

Define System


Select LAN/WAN Networks

Define Parameter

Performance Set

Define Interfaces

Create System2

Matrix

Create System

Communications Description

Create System

Interface Description

Create System

Information Exchange

Matrix

Create System

Performance Parameter

Matrix

Create System Evolution

Description

System Interface

Desciption (SV-1)

System Communications

Description (SV-2)

Systems2 Matrix (SV-3)

System Information Exchange

Matrix (SV-6)

System Evolution

Description (SV-8)

System Performance

Parameter Matrix (SV-7)

Create System

Technology Forecast

Systems Technology

Forecast (SV-9)

Define Links

Physical Data

Model (SV-11)


(SV-4)




Components


Matrix (OV-3)

Operational Node


(OV-2)


Description (D9)

Migation Systems

(D11)

System Performance

Attributes (D10)

FromStage 3

FromStage 4


PROCESS STAGES

4 Based on the analysis of the functional architecture models, the Operational Node Connectivity Description and the Operational Information Exchange Matrix are finalized. The implementation of the functional architecture is formulated and evaluated by creating the Systems Functionality Description and supporting Physical Data Model.

5 From the previous analysis, the System Information Elements and the LAN/WANs are specified. The remaining products of the Systems Architecture view are created including the System Information Exchange Matrix, the System Communication Description, the System Interface Description and the System Evolution Description.


OBSERVATIONS

• The process appears to be complex; this is due to the tight coupling among products

(This tight coupling is to be expected: all views and products describe aspects of a single architecture)

• The process requires concurrent, but coordinated activities to take place

(It is the architect’s role to plan and direct these activities)

• Products are produced in all six stages

(This allows for continuous review and evaluation of the architecture description process)

• The process diagram (flow chart) indicates what supporting products are needed in each case; the choice is not arbitrary because of interdependencies


CONCLUSION

• The six stage process is one approach to developing the architecture products specified by the C4ISR Architecture Framework

• Alternative approaches are possible; the six stage process can serve as a template to ensure that the alternative approaches cover all needed steps and produce a complete architecture description

© A. H. Levis INCOSE L. 3 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 3 STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESS.

Documents

operational concept

levis incose

operational concept

activity model

v5 dtc

v4 dtc

v3 dtc

dynamics model