Introduction To NCOIC Net-Centric Patterns

Introduction to NCOICNet-Centric PatternsMark K BowlerAdvanced Tactical SystemsPhantom WorksThe Boeing Company714.372.1956mark.k.bowler@boeing.comNIF Architecture Concepts Functional Team ChairOctober 27, 2010Approved for Public ReleaseDistribution UnlimitedNCOIC-NDIA-MB20101027Page 1

The NCOIC at a GlanceMembers areGlobal Leaders:Academic institutionsAir Traffic ManagementprovidersService providersConsultingEngineeringLogisticsDefense suppliersAll military servicesMultinationalA global organization focused on an industry neutralapproach to NCO adoption: Use of Open Standards in NCO domains Net-Centric Architecture Concepts and System DesignBest Practices Tools for Evaluation and Assessment of Net-CentricSystems “Building Blocks” catalog of components & servicescompliant with NCOIC recommendationsGovernment agenciesHuman service agenciesIntegratorsCommercial systemsDefense systemsIT firmsCommunicationsData managementHuman-Machine interfaceInformation assuranceStandards bodiesPrescriptiveGuidance On How ToBuild Interoperable,Network CentricSystemsPage 2

Unity of EffortDifferent Domains, Similar NeedsAviation IPTC3 InteroperabilityIPTMaritimeIPTCyber SecurityIPTOperationalDescriptionsNet CentricPrinciples &AttributesNet cAttributesNCOICInteroperabilityFrameworkSCOPENIF & Concepts,Principles,Processes,PATTERNSNCATNet Enabled EmergencyResponse IPTSpecialized Frameworks Information AssuranceCloud ComputingMobile NetworkingSystem ManagementSemantic InteroperabilityInformation, Services, etc.BuildingBlocksModeling andSimulationSystemsEngineeringand Integration Test & Evaluation Lexicon Education& OutreachFunctional Teams provide the technical expertise to serve customer domains.The Integrated Project Teams provide operational information from customer domain perspectives.Page 3

Where Net-Centric Patternsfit into the NCOICRequirementsNIF SCOPE & NCAT cksBuild &IntegrateNet-CentricPatternsTest & EvalSCOPE & NCAT Page 4

Why Patterns? Standards alone do not guarantee interoperability wealso need guidance on architectural approaches,behaviors, design rules, design principles, etc Often the “best” Standard depends on the mission andperformance requirements In a System-of-Systems, legacy systems cannot beforced to update to newest standard Does Everyone Understand the Standard the SameWay?NCOIC Net-Centric Patterns A vehicle for prescriptiverecommendations on which standards to use, how to use them, and otheressential guidancePage 5

Three Types of Net-Centric PatternsOPERATIONALPATTERN “A”CAPABILITYPATTERN HNICALPATTERN“X”CAPABILITYPATTERN HNICALPATTERN“D”OPERATIONALPATTERN “B”CAPABILITYPATTERN 3TECHNICALPATTERN“E”CAPABILITYPATTERN HNICALPATTERN“Z”Page 6

Typical use ofNCOIC ResourcesActivityNCOIC ResourceConcept Development Specialized Frameworks Operational PatternsArchitecture Development NCOIC Interoperability FrameworkSpecialized FrameworksCapability PatternsNetwork Centric Assessment ToolSystem Design Specialized FrameworksTechnical PatternsNetwork Centric Assessment ToolBuilding Block CatalogSystem Assessments Network Centric Assessment ToolPage 7

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationWhat is the problem beingsolved, and the context?Page 8

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationActors and interfacesinvolved in the NCP orotherwise required toimplement itPage 9

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationPre-Conditions areprerequisites that must bein place before the patterncan be applied. If not met,the pattern cannot besuccessfully applied to theproblem at hand.Post-Conditions are theconcrete results of applyingthe pattern. State what isthe outcome of applyingthe pattern, including anylimitations and/orconsequences.Page 10

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationGraphical or texturaldescription of any structure(architectures, etc) to beimposed on the solutionPage 11

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationRequired behavior(dynamic interaction) ofstructure elements, actors,or interfaces. Includes“rules”, principles,algorithms, etc.Page 12

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationStandardName and NumberOSPFv2IETF RFC 2328 (STD:54)OSPF Traffic EngineeringIETF RFC 3630 TrafficEngineering (TE)Extensions to OSPF Version2Spanning Tree ProtocolIEEE 802.1DDAMA (MIL-STD-188-181)181C - InteroperabilityStandard For Access To 5kHz And 25-kHz UhfSatellite CommunicationsChannelsDAMA Control (MIL-STD-188185)185 - Interoperability UHFMilsatcom Dama ControlSystemPurposeNoteslink state advertisingon DIL linkstraffic engineeringto utilize DIL linksWhen using IPtechnologyWhen using IPtechnologylink layer weightingof DIL linksDAMAWhen using COTSbridgesWhen using UHFsatellite communicationstechnologyDAMA control ofDIL SATCOM linksWhen using UHFsatellite communicationstechnologyDetailed identification of allStandards required forimplementation of the NCPPage 13

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationNon-Prescriptiveinformation that may be ofuse to those using the NCPPage 14

Net-Centric Pattern Contents1.2.3.4.Introduction and Problem Description1.1. Context1.2. Problem Statement1.3. Expected BenefitsRecommended Solution2.1. Actors2.3. Interfaces2.2. Pre-Conditions2.4. Structure2.5. Behavior2.6. Post-Conditions2.7. StandardsAdditional information3.1. Lessons Learned3.2. Constraints & Opportunities3.3. Known Uses3.4. Potential Capability3.5. Related Patterns3.6. ReferencesVerificationTable of detailedverification criteria forvendors wishing to certifythat their product arecompliant with the NCPPage 15

NCOIC Net-Centric PatternsRELEASED SAGM Mobile Communication andNetworking Legacy Services Design Phase Service Integration Information Dissemination SharedDatabase Land Force Tracking GatewayNetwork Centric All Hazards Alerts and Warnings Disconnected, Intermittent, Limited(DIL) Communications Management Simple and Extensible EmailServices (SEES) Secure Formatted InformationExchange Gateway (SFIEG) Core Network AccessOperational PatternsCapability PatternsTechnical PatternsCOMING SOON Flight Data Object Dissemination Live, Virtual, & ConstructiveIntegrated Middleware Environment Net-Centric Cyber Simulation Access Network Discovery High Level Architecture (HLA) Distributed Interactive Simulation Services Interface Technical Pattern Resource Tracking InformationExchange More in work Page 16

Value for the CustomerSystems A, B, C, System BSystem CFuture Integrated, ad hoc,interoperable solutions Global multi-domainSystem-of-SystemsSystem APresent Technology exists, but not integrated Some transformational programs funded Lack of common approach Industry assistance requiredPast Platform focused Performance driven StandalonePage 17

For Additional Information www.ncoic.orgOr Contact:mark.k.bowler@boeing.comPage 18

andsIsraelSouth ySwitzerlandFranceSwedenUnited StatesUnited rksPage 19

NCOIC Assists Customersin obtaining interoperable solutions:NIF Guides Development of Net-Centric SystemsOperationalSubject ject rational(Domain)PatternsIntegrated ProjectTeams (IPTs) SCOPE ilityPatternsPlus uidanceTechnicalPatternsPlus SpecializedFrameworksPage 20

The Problem withInteroperability StandardsPerformance Performance “B”Standard“B” Often the “BEST” Standard depends on the Mission– Real-World Condition! Often no “One Size Fits All”Page 21

The Problem withInteroperability StandardsNotional Cost (or Risk) What is the appropriate level of NetCentricity for a givenoperational context? May impact selection of Standards!Which is the“Best” Standardfor thishypotheticaloperationalcontext?Standard “A”For Technology XStandard “B”For Technology XThis example istime-based; manyother perspectives!Today’s Range ofrequired performanceFuture Range ofrequired performanceNotional PerformancePage 22

The Problem withInteroperability StandardsNotional Intended Span of Standard% A-to-BInteroperableSYSTEM “A” Extension:Added Highly-DesirableRangeSYSTEM “B” Extension:Added perable “Bad” Standard, or “Bad” System Designs?– Real-World Condition!– In a System-of-Systems, cannot force systems to not use highlydesirable features when operating independentlyPage 23

The Problem withInteroperability Standards% VersionsInteroperableORIGINAL Standard v1.0UPDATED Standard v1.1NEW Standard v2.0: “Backward Compatible”100% all 3 versionsInteroperable100% v1.1 & 2.0InteroperableV1.1 & v2.0V1.0 & v2.0 Is Everyone Running the Same Version?– Real-World Condition!– In a System-of-Systems, cannot force Legacy systems to updateto newest standardPage 24

The Problem withInteroperability Standards%InteroperableInterpretation “A” of StandardInterpretation “B” of StandardGUIDED Interpretation of StandardGoal: 100% Interoperablewith Guided InterpretationInconsistent Interoperabilitywithout Common Guidance Does Everyone Understand the Standard the Same Way?– Real-World Condition! (Not necessarily a bad Standard)– Different Languages; different Cultural backgrounds– Same Standard applied in different Operational Domains,implemented by designers with different levels of experience,different technical disciplines, different company rulesPage 25