1. C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES
LECTURE 3
STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESS
ALEXANDER H. LEVIS
LEE W. WAGENHALS

2. OUTLINE Fundamentals Structured Analysis and Roadmap
Concordance issues
Mapping from SA to the C4ISR Constructs
The C4ISR Architecture Design Process – SA version
Conclusions

3. 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 D O M A I N

4. 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 D O M A I N

5. SYSTEMS ENGINEERING APPROACH: ANALYSIS PHASE
FUNCTIONAL
ARCHITECTURE
OPERATIONAL
CONCEPT
PHYSICAL
MISSION
DECOMPOSITION
ORGANIZATION
MODEL
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

6. 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

7. 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.

8. 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

9. 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

10. FUNCTIONAL ARCHITECTURE
IDEF0 or Data Flow Diagram
FUNCTIONAL
ARCHITECTURE IS
DATA MODEL
RULE MODEL
PROCESS MODEL D I C T O N A R Y
IDEF1x or Entity-Relationship
Diagram
Embedded on IDEF0 or in the State Transition Diagrams

11. 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

12. EXAMPLE: NTCS-A NTCS-A 2 0 CV/CVN OPEVAL HARDWARE CONFIGURATION CVIC
FIST
386
A/B
SWITCH
MAPPING
AND
IMAGERY
386
MAPPING
AND
IMAGERY
386
TFCC
SUPPLOT
GENSER
POST
NIPS
OA-XXX
(V)2
GFCP
OJ-XXX
(V)6
DTC-2
OJ-XXX
(V)4
DTC-2
OA-XXX
(V)3
SW-3000
OJ-XXX
(V)4
DTC-2
ATP HP
9020C
OJ-XXX
(V)3
DTC-2
OJ-XXX
(V)8
DTC-2
OJ-XXX
(V)3
DTC-2
OJ-XXX
(V)8
DTC-2
F/O ETHERNET LAN
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
CDC
ASWM
FLAG PLOT

13. 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

14. USTRANSCOM ORGANIZATION AND RELATIONSHIPS
CJCS
USTRANSCOM
NCA
MSC
MTMC
AMC
Combatant Command Line
Coordination 1)
Direction from the
NCA through the
CJCS. 2)
USCINCTRANS manages
deployment and redeployment of
forces and material in compliance
with the supported CINC’s
OPLANs. 3)
USCINCTRANS tasks the TCCs
(as appropriate) for execution of
airlift, sealift, land movement, and
common-user seaport operations.
(1)
(2)
(3)
From C4ISR Arch.
Framework, v. 2

15. 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.

16. STATE TRANSITION DIAGRAM
ENTERING CONTROLLED
SPACE
CONTROLLED:
NO ACTION
MANEUVERING
IN CONFLICT
LEAVING CONTROLLED
HANDOFF TO
LOCAL ATC
COMPLETED
REVISE
CLEARANCE ON
PILOT'S REQUEST
DETECT
DEVIATION
COMPLETE
CONFLICT
CLEARANCE
RESOLVE
(NO MANEUVER)
COORDINATE INTER-SECTOR TRANSFER
COORDINATE TRANSFER OUT
COORDINATE
TRANSFER OUT
From C4ISR Arch.
Framework, v. 2

17. 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

18. 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

19. 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?

20. DATA ACTIVITY DOMAINS RULE DYNAMICS ICOM/Entity Attribute/ Domain
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-INTERCEPTOR
x««285»»
INTERCEPTOR-REPORT««90»»
ICOM/Entity
Track-ID
Threat-Status
Interceptor-ID (FK)
THREAT /1
THREAT
Interceptor-ID
Track-ID (FK)
Surv-Dir-Content
SURVEILLANCE-DIRECTIVE /2
SURVEILLANCE-DIRECTIVE
TP-Update
TACTICAL-PICTURE /3
TACTICAL-PICTURE
State (FK)
Order-Content
Order-NB (AK1)
ORDER /4
ORDER
State
RULES-OF-ENGAGEMENT /5
RULES-OF-ENGAGEMENT
Report-Content
Report-NB (AK1)
REPORT /6
REPORT
is reported in
is used for the generation of
is consistent with
Action
CONTROL-TO-INTERCEPTOR /7
CONTROL-TO-INTERCEPTOR
to engage
results in
can trigger
constrains the construction of
constrain the generation of
Enemy-Response
INTERCEPTOR-REPORT /9
INTERCEPTOR-REPORT
ACTIVITY
Attribute/
Domain
Activity/
Rule
DOMAINS
RULE
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
Value/Rules
Function :
Sense
S1: if (Surv-Dir-Content=default) and (Threat-Status=incoming)
then (TP-Update=new) and (Threat-Status=sensed)
inc
S2: if (Surv-Dir-Content=track-interc) and(Threat-Status=engaged)
then (TP-Update=in_firing_range)
Transition/
Rule
S3: if (Surv-Dir-Content=assess_kill) and (Threat-Status=destroyed)
then (TP-Update=killed)
Function
Command
C1: if (TP-Update=new) then (Order-Content=intercept)
C2: if (Report-Content=interceptor_away) then (Surv-Dir-Content=track_interc)
DYNAMICS
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) or
C6: if (Report-Content=weapons_away) then (Surv-Dir-Content=assess_kill)
Function
Act
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 delay
if (Action=launch_weapon) then (ThreatStatus=destroyed) after delay
if (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)

21. 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

22. SYSTEMS ENGINEERING: SYNTHESIS
ORGANIZATION
MODEL
OPERATIONAL
CONCEPT
FUNCTIONAL
ARCHITECTURE
PHYSICAL
DYNAMICS MODEL
EXECUTABLE
Mapping the Physical onto the Functional Architecture
or vice versa and adding the Dynamics Model leads to an
executable model of the Architecture

23. 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

24. 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

25. A DETAILED VIEW ORGANIZATION MODEL OPERATIONAL CONCEPT FUNCTIONAL
ARCHITECTURE
PHYSICAL
EXECUTABLE
DYNAMICS MODEL
MOPS, MOEs
TECHNICAL
DATA MODEL
RULE MODEL
PROCESS MODEL D A T
MISSION
EVALUATION
PHASE

26. 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

27. ARCHITECTURE EVALUATIONX C U T A B L
ARCHITECTURE
SPECIFIED
BEHAVIORS
USER
USER INTERACTION
Technical
Architecture
Functional
Physical
Integrated
Dictionary
SE Constructs
User behavioral requirements vs. architecture behavior

28. CORRESPONDENCE OPERATIONAL FUNCTIONAL ARCHITECTURE VIEW
PHYSICAL
ARCHITECTURE VIEW
SYSTEMS
ARCHITECTURE VIEW
Systems Engineering
constructs
C4ISR constructs

29. 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

30. 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

31. 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

32. KEY ENTITIES (Operational) (Organizational) (Systems)
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
(Operational)
(Organizational)
(Systems)

33. KEY ENTITIES Operational Node Element Needline Information System Link
System Element
Compon
ent
Link
Function
Activity
Networks
Interface
Asset
Organization
Has
Represents
is Associated with
Is associated with
Performs/
Is performed by
Implements/
is implemented by
Is implemeneted by
Transmits
Is implemented by
Contains
Is Attached To Is
Attached
Enables
OPERATIONAL VIEW
SYSTEMS VIEW
Maps To
Is a
May
Represent
Parameter
Performance
Set
KEY ENTITIES Ch

34. APPROACH Systems Engineering Approach: Structured Analysis C4ISR AF
process
C4ISR AF
Products
Executable
Model
of Architecture
Architecture

35. OVERLAYING THE SYSTEMS ENGINEERING APPROACH
Operational
Node
Element
Needline
Information
System
System Element
Component
Link
Function
Activity
LAN/WAN
Parameter
Performance
Set
Interface
Asset
Organization
Has
Represents
is Associated with
Is associated with
Performs/
Is performed by
Implements/
is implemented by
Is implemented by
Transmits
Contains
Is Attached To Is
Attached
Enables
OPERATIONAL VIEW
SYSTEMS VIEW
Maps To
Is a
May Represent
Concept
Functional
Decomposition
Model
OV-5
STD
OV-6b
Rule
Logical
Data
FUNCTIONAL
ARCHTECTURE
ORGANIZATIONAL
MODEL
PHYSICAL
ARCHTECTURE L

36. THE SIX STAGE PROCESS

37. 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.

38. 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

39. SIX STAGE PROCESS – ESSENTIAL ONLY

40. 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

41. STAGE 1

42. STAGE 2

43. STAGE 3a

44. STAGE 3b

45. PROCESS STAGES
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
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.
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.

46. STAGE 4

47. STAGE 5

48. PROCESS STAGES
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.
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.

49. 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

50. 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