Presentation on theme: "C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES"— Presentation transcript:
1C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 3STRUCTURED ANALYSIS AND A C4ISR ARCHITECTURE DESIGN PROCESSALEXANDER H. LEVISLEE W. WAGENHALS
2OUTLINE Fundamentals Structured Analysis and Roadmap Concordance issuesMapping from SA to the C4ISR ConstructsThe C4ISR Architecture Design Process – SA versionConclusions
3BASIC PHASESThe architecture design process can be partitioned in three phases:Analysis: definition of elements and development of static, behavioral, and implementation diagramsSynthesis: development of executable modelEvaluation: behavioral and performance analysisANALYSIS(C4ISR Viewsand Products)SYNTHESIS(Executable)EVALUATIONDOMAIN
4BASIC PHASESWhile 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 iterativeANALYSISSYNTHESISEVALUATIONDOMAIN
5SYSTEMS ENGINEERING APPROACH: ANALYSIS PHASE FUNCTIONALARCHITECTUREOPERATIONALCONCEPTPHYSICALMISSIONDECOMPOSITIONORGANIZATIONMODELUnless 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
6OPERATIONAL CONCEPTThe architecture development process must start with an Operational ConceptThe initial definition of the Operational Concept can be very abstract; as the architecture development process evolves, the Operational Concept becomes more specificAn Operational Concept describes how a mission is to be carried outThere is no quantitative procedure for deriving an Operational ConceptGiven a set of goals, given experience and expertise, humans invent Operational Concepts
7OPERATIONAL CONCEPTSGood Operational Concepts are based on a simple idea of how the overriding goal is to be metExample: “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.
8OPERATIONAL CONCEPTNOTE: 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
9FUNCTIONAL ARCHITECTURE The Functional Architecture is the centerpiece of the Structured Analysis approachDefinition: 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 DictionaryAn Activity model that is supported by a Data model, with a common Data DictionaryAn Activity model that includes an embedded Rule model (e.g., Activation rules in IDEF0), supported by a Data model, with a common Data DictionaryThe Functional Architecture does not include a Dynamics Model or an Organization Model
10FUNCTIONAL ARCHITECTURE IDEF0 or Data Flow DiagramFUNCTIONALARCHITECTUREISDATA MODELRULE MODELPROCESS MODELDICTONARYIDEF1x or Entity-RelationshipDiagramEmbedded on IDEF0 or in the State Transition Diagrams
11PHYSICAL* ARCHITECTURE • The set of physical resources (nodes) that constitute the system and their connectivity (links)The Physical Architecture indicates what is possibleIn the absence of inputs and an Operational Concept, the Physical Architecture does not show how a mission is to be performedPhysical components (represented by boxes) are capable of carrying out processesThe 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
13ORGANIZATION MODELThe 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 organizationThe Organization Chart represents the command (line and staff) relationships of the formal organization, if it is hierarchically structuredMany other constructs represent the informal organization, e.g., the communication patterns
14USTRANSCOM ORGANIZATION AND RELATIONSHIPS CJCSUSTRANSCOMNCAMSCMTMCAMCCombatant Command LineCoordination1)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
15DYNAMICS MODELA representation of the dynamic behavior of the architecture in the form ofState Transition DiagramsOperational Sequence DiagramsKey Threads, etc.The Dynamics model is not an Executable Model; it describes dynamic behavior, but does not generate it – only the executable model does.
17TOOLS AND TECHNIQUESThe Structured Analysis approach sits on four pillars:Activity modelData modelRules modelDynamics modelIt also requires an Integrated DictionaryThe weakness of Structured Analysis is that the four models are obtained using different approaches and different tools. This leads to the problem of CONCORDACEThe 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
18MODEL CONCORDANCEModel Concordance is the process of making sure that the Structured Analysis models are coherent and consistent with one anotherThe 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 modelThe attributes of the entities are the clauses used in the rule model
19REMARKS Concordance of the various models A tedious, but essential activityA 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?
20DATA ACTIVITY DOMAINS RULE DYNAMICS ICOM/Entity Attribute/ Domain Sense««274»»A1Command««276»»A2Act««277»»A3ORDER««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/EntityTrack-IDThreat-StatusInterceptor-ID (FK)THREAT /1THREATInterceptor-IDTrack-ID (FK)Surv-Dir-ContentSURVEILLANCE-DIRECTIVE /2SURVEILLANCE-DIRECTIVETP-UpdateTACTICAL-PICTURE /3TACTICAL-PICTUREState (FK)Order-ContentOrder-NB (AK1)ORDER /4ORDERStateRULES-OF-ENGAGEMENT /5RULES-OF-ENGAGEMENTReport-ContentReport-NB (AK1)REPORT /6REPORTis reported inis used for the generation ofis consistent withActionCONTROL-TO-INTERCEPTOR /7CONTROL-TO-INTERCEPTORto engageresults incan triggerconstrains the construction ofconstrain the generation ofEnemy-ResponseINTERCEPTOR-REPORT /9INTERCEPTOR-REPORTACTIVITYAttribute/DomainActivity/RuleDOMAINSRULESurv-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, ...newValue/RulesFunction :SenseS1: if (Surv-Dir-Content=default) and (Threat-Status=incoming)then (TP-Update=new) and (Threat-Status=sensed)incS2: if (Surv-Dir-Content=track-interc) and(Threat-Status=engaged)then (TP-Update=in_firing_range)Transition/RuleS3: if (Surv-Dir-Content=assess_kill) and (Threat-Status=destroyed)then (TP-Update=killed)FunctionCommandC1: if (TP-Update=new) then (Order-Content=intercept)C2: if (Report-Content=interceptor_away) then (Surv-Dir-Content=track_interc)DYNAMICSC3: 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)orC6: if (Report-Content=weapons_away) then (Surv-Dir-Content=assess_kill)FunctionActA1: 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)
21REMARKSNeed for software having features that can assist in creating an maintaining concordance of process, data, rule and dynamics modelspage link and HyperText can provide graphical connections between critical items in these modelsoverlapping of hyper text can be used to detect errorsThere 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
22SYSTEMS ENGINEERING: SYNTHESIS ORGANIZATIONMODELOPERATIONALCONCEPTFUNCTIONALARCHITECTUREPHYSICALDYNAMICS MODELEXECUTABLEMapping the Physical onto the Functional Architectureor vice versa and adding the Dynamics Model leads to anexecutable model of the Architecture
23THE EXECUTABLE MODELCreating an Executable model requires concordance of the multiple modelsIf there are concordance errors, they will appear in the construction and running of the executable modelEven though the executable model is not required by the C4ISR AF, it is essential forchecking the validity of the architecture designproviding the means for the evaluation of the architecture (logical, behavioral, and performance levels)providing a testbed for system designs
24THE EXECUTABLE MODELAn Executable architecture model is developed for a given Operational ConceptAn 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 functionsBehavior analysis and performance evaluation can be carried out using scenarios consistent with the Operational Concept
26EVALUATION PHASE The executable model can be used for: Simulation AnalysisThe mathematical framework used for the executable model and the supporting software application bring with them tools and procedures for evaluationDefine parameters that characterize the architecture designDefine measures of performance (MOPs)Identify the requirementsDefine measures of effectiveness (MOEs) that express how well the architecture meets the requirements
27ARCHITECTURE EVALUATION XCUTABLARCHITECTURESPECIFIEDBEHAVIORSUSERUSER INTERACTIONTechnicalArchitectureFunctionalPhysicalIntegratedDictionarySE ConstructsUser behavioral requirements vs. architecture behavior
29CONCLUSIONThe Systems Engineering process based on Structured Analysis is capable of supporting the design of a C4ISR Architecture across all three stages – Analysis, Synthesis, and EvaluationThe Structured Analysis process produces models that contain within them all the information needed by the Essential and Supporting products of the C4ISR Architecture framework
30MOTIVATIONThe C4ISR Architecture Framework (v. 2.0) provides high level guidance and a set of essential (mandatory) and supporting products for representing an architectureIt does not identify a specific process for developing the architecture views and the associated products.A process is needed toidentify the relationships among productsguide in the selection of tools neededThe process must be generic to accommodate current practices
31PROCESS FOR PRODUCT DEVELOPMENT A six stage process has been developed for generating the Essential and Supporting products for the Operational and Systems architecture viewsThe process has been derived by approaching the problem from the systems engineering point of view and using Structured Analysis; alternative processes are possibleEach product has been perceived as an Entity containing data; a formal Data Model was derived showing the relationship among the various entitiesThe relationships among the entities induced a partial ordering of the entities which led to a series of steps for their productionThe process utilizes existing tools and techniques to derive the requisite products and is compatible with the development of an Executable model
32KEY ENTITIES (Operational) (Organizational) (Systems) Operational Nodes and Operational ElementsActivitiesNeedlinesOperational Information ElementsOrganizationAssetSystem, System Element, System ComponentSystem FunctionSystem NodeLinkSystem Information ElementPerformance Parameter SetNetworks and Interfaces(Operational)(Organizational)(Systems)
33KEY ENTITIES Operational Node Element Needline Information System Link System ElementComponentLinkFunctionActivityNetworksInterfaceAssetOrganizationHasRepresentsis Associated withIs associated withPerforms/Is performed byImplements/is implemented byIs implemeneted byTransmitsIs implemented byContainsIs AttachedToIsAttachedEnablesOPERATIONAL VIEWSYSTEMS VIEWMaps ToIs aMayRepresentParameterPerformanceSetKEY ENTITIESCh
34APPROACH Systems Engineering Approach: Structured Analysis C4ISR AF processC4ISR AFProductsExecutableModelof ArchitectureArchitecture
35OVERLAYING THE SYSTEMS ENGINEERING APPROACH OperationalNodeElementNeedlineInformationSystemSystem ElementComponentLinkFunctionActivityLAN/WANParameterPerformanceSetInterfaceAssetOrganizationHasRepresentsis Associated withIs associated withPerforms/Is performed byImplements/is implemented byIs implemented byTransmitsContainsIs AttachedToIsAttachedEnablesOPERATIONAL VIEWSYSTEMS VIEWMaps ToIs aMay RepresentConceptFunctionalDecompositionModelOV-5STDOV-6bRuleLogicalDataFUNCTIONALARCHTECTUREORGANIZATIONALMODELPHYSICALARCHTECTUREL
37REMARKSThis 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) ViewNote 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 otherThe crosslinking is in both directions: system information is needed in the OA view and activity information in the SA viewThe 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.
38REMARKSC4ISR 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 productsDevelopment 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 developedThe Data Flow Diagram indicates the sequence in which products can be developed and specifies the data needed to construct them
40THE SIX-STAGE PROCESSSTAGE 0: Problem Definition and Collection of Domain InformationSTAGE 1; Operational Concept and RequirementsSTAGE 2: Functions and OrganizationsSTAGE 3: Activity Model, Logical Data Model, Needlines, System Nodes, System Elements and Functions, and Task AllocationSTAGE 4: Operational Information Elements and Exchanges, System Functionality Description, Physical Data ModelSTAGE 5: System Information Elements and Exchanges, LAN/WANs, System Interface Descriptions, System Performance
45PROCESS STAGESOnce 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 descriptionThe 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.
48PROCESS STAGESBased 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.
49OBSERVATIONSThe 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
50CONCLUSIONThe six stage process is one approach to developing the architecture products specified by the C4ISR Architecture FrameworkAlternative 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