Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "© A. H. Levis INCOSE L. 3 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 3 STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESS."— Presentation transcript:

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

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

3 © A. H. Levis INCOSE L 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 DOMAINDOMAIN

4 © A. H. Levis INCOSE L 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 ANALYSISSYNTHESISEVALUATION DOMAINDOMAIN

5 © A. H. Levis INCOSE L 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 FUNCTIONAL ARCHITECTURE OPERATIONAL CONCEPT PHYSICAL ARCHITECTURE MISSION FUNCTIONAL DECOMPOSITION ORGANIZATION MODEL

6 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L FUNCTIONAL ARCHITECTURE FUNCTIONAL ARCHITECTURE IS DATA MODEL RULE MODEL PROCESS MODEL DICTIONARYDICTIONARY DATADATA IDEF0 or Data Flow Diagram IDEF1x or Entity-Relationship Diagram Embedded on IDEF0 or in the State Transition Diagrams

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

13 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L USTRANSCOM ORGANIZATION AND RELATIONSHIPS CJCS USTRANSCOM NCA MSCMTMCAMC 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 CINCs 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L STATE TRANSITION DIAGRAM ENTERING CONTROLLED SPACE CONTROLLED: NO ACTION MANEUVERING IN CONFLICT LEAVING CONTROLLED SPACE HANDOFF TO LOCAL ATC COMPLETED REVISE CLEARANCE ON PILOT'S REQUEST DETECT DEVIATION MANEUVERING COMPLETE DETECT CONFLICT REVISE CLEARANCE RESOLVE CONFLICT (NO MANEUVER) COORDINATE INTER-SECTOR TRANSFER COORDINATE TRANSFER OUT COORDINATE INTER-SECTOR TRANSFER COORDINATE TRANSFER OUT From C4ISR Arch. Framework, v. 2

17 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 Architects tasks) How do the models inter-relate? How do we construct the Integrated Dictionary?

20 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 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) 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-ID Threat-Status Interceptor-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-PICTURE Track-ID (FK) Interceptor-ID (FK) State (FK) Order-Content Order-NB (AK1) ORDER /4 Order-Content ORDER State RULES-OF-ENGAGEMENT /5RULES-OF-ENGAGEMENT State Track-ID (FK) Interceptor-ID (FK) Report-Content Report-NB (AK1) REPORT /6REPORT Report-Content is reported in is used for the generation of is consistent with Track-ID (FK) Interceptor-ID Action CONTROL-TO-INTERCEPTOR /7CONTROL-TO-INTERCEPTOR Action is reported in to 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-INTERCEPTOR x««285»» INTERCEPTOR-REPORT««90»» ICOM/Entity Activity/ Rule Attribute/ Domain Transition/ Rule Value/Rules

21 © A. H. Levis INCOSE L 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 Architects responsibility

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

23 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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. H. Levis INCOSE L A DETAILED VIEW ORGANIZATION MODEL OPERATIONAL CONCEPT FUNCTIONAL ARCHITECTURE PHYSICAL ARCHITECTURE EXECUTABLE MODEL DYNAMICS MODEL MOPS, MOEs TECHNICAL ARCHITECTURE DATA MODEL RULE MODEL PROCESS MODEL DATADATA MISSION EVALUATION PHASE

26 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L ARCHITECTURE EVALUATION User behavioral requirements vs. architecture behavior EXECUTABLEEXECUTABLE ARCHITECTURE SPECIFIED BEHAVIORS USER SPECIFIED BEHAVIORS USER INTERACTION Technical Architecture Functional Architecture Physical Architecture Integrated Dictionary SE Constructs

28 © A. H. Levis INCOSE L CORRESPONDENCE FUNCTIONAL ARCHITECTURE VIEW PHYSICAL ARCHITECTURE VIEW SYSTEMS ARCHITECTURE VIEW OPERATIONAL ARCHITECTURE VIEW Systems Engineering constructs C4ISR constructs

29 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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)

33 KEY ENTITIES Ch

34 © A. H. Levis INCOSE L APPROACH Systems Engineering Approach: Structured Analysis Structured Analysis process C4ISR AF Products Executable Model of Architecture Architecture

35 OVERLAYING THE SYSTEMS ENGINEERING APPROACH FUNCTIONAL ARCHTECTURE PHYSICAL ARCHTECTURE ORGANIZATIONAL MODEL L

36 THE SIX STAGE PROCESS

37 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L 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 © A. H. Levis INCOSE L STAGE 1

42 © A. H. Levis INCOSE L STAGE 2

43 © A. H. Levis INCOSE L STAGE 3a

44 STAGE 3b

45 © A. H. Levis INCOSE L PROCESS STAGES 1Once 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 2The 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. 3A 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 © A. H. Levis INCOSE L PROCESS STAGES 4Based 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. 5From 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 © A. H. Levis INCOSE L 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 architects 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 © A. H. Levis INCOSE L 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


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

Similar presentations


Ads by Google