html5-img
1 / 22

C2 Core: Problem , Approach, And Value Proposition

C2 Core: Problem , Approach, And Value Proposition. Dr. Scott Renner sar@mitre.org 8 April 2009. Context. C2 Core concept originates in 2007, along with UCore Envisioned as one of several domain-specific extensions to UCore Responsibility of C2 Capability Portfolio Manager (C2 CPM)

naida
Download Presentation

C2 Core: Problem , Approach, And Value Proposition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C2 Core: Problem, Approach, And Value Proposition Dr. Scott Rennersar@mitre.org8 April 2009

  2. Context • C2 Core conceptoriginates in 2007,along with UCore • Envisioned as one of several domain-specific extensions to UCore • Responsibility ofC2 Capability PortfolioManager (C2 CPM) • Active developmentbegins in 2008 • Data/Services Steering Committee (DSSC) directs development of C2 Core • 18-20 March kickoff meeting in Ft. Leavenworth

  3. C2 Core History And Status • C2 Core version 1.0 presented to DSSC Apr 08 • Large subset of JC3IEDM • No clear definition of scope or conformance • Not accepted • Independent Assessment Team (IAT) created Jul 08 • Reviews issues re. C2 implementation of NCDS Nov 08 • New C2 Core effort started Jan 09 • Technical Framework & Tools Sub-WG stands up Feb 09 • Draft C2 Core CONOPS for review Mar 09

  4. Working Group Organizational Structure C2 DSSC C2 Core Working Group C2 Core Operational Content Sub-Working Group Verification, Validation & Implementation Sub-Working Group Technical Framework and Tools Sub-Working Group UNCLASSIFIED

  5. Basic Problem How do the programs within C2 COIs make use of UCore and C2 Core to define interoperable data exchanges? (Not pairwise – want many producers and consumers to use same message format) Shared vocabularies UCore C2 Core C2 COI understand PORs define application application application application application application Producer Consumer

  6. Basic Approach UCore COIs and their member PORs design and implement the IES, using definitions from UCore and C2 Core C2 Core C2 COI informationexchangespecification PORs IES defines application application application application application application IEP informationexchangepackage

  7. Four Parts Of IAT’s C2 Core C2 Conceptual Model & Vocabulary UCore C2-Specifc Extensions to UCore C2 Core C2 COI C2 Core Service Specifications C2 Information Sharing Framework PORs IES defines application application IEP

  8. Feedback loop: Runtime metrics used to improve all four parts of IAT’s C2 Core Four Parts Of C2 Core C2 Conceptual Model & Vocabulary UCore C2-Specifc Extensions to UCore C2 Core C2 COI C2 Core Service Specifications C2 Information Sharing Framework PORs IES defines application application IEP

  9. Which Parts Are We Working Now? C2 Conceptual Model & Vocabulary UCore C2-Specifc Extensions to UCore C2 Common Core C2 COI C2 Core Service Specifications C2 Information Sharing Framework PORs IES defines application application IEP

  10. C2 Core Problem Statement • COIs deal with understandability / interoperability in NCDS • COIs inevitably overlap • Will develop redundant, incompatible data components • Universal and common core vocabularies • Capture the common definitions • Leave each COI to define just the data it alone needs • UCore provides a small set of common definitionsneeded in almost all COIs • Who, what, where, and when • Doesn’t go deep enough for C2 domain • Commonalities among C2 COIs not defined in UCore • Problem: Need a common core, extending UCore, andcapturing overlaps among the C2 COIs

  11. Another Way To Look At It • We can’t let everyone totally do their own thing • We can’t get everyone to do everything the same • So we want to converge on some things • Some core data components needed in several COIs(out of the complete set of C2 data components) • Some particular ways to use XML to represent data(out of all the possible ways of using XML) • Reduce (not eliminate) diversity where this adds most value

  12. C2 Core Development Concept Problem statement, value proposition, assumptions, architectural framework, and lifecycle CM concepts Enough detail to understand what the TFTSWG is doing, is not doing now, and won’t do at all Defines roles of the DSSC, C2 Core WGs, et al. Provides a baseline level of understanding and agreement to build upon Solid enough to know what the concept is not Detailed enough to agree what the argument is about Good enough to justify further development

  13. Questions And Assumptions • Target of conformanceTo what sort of Core things does an IES conform? • Kind of conformanceSemantic, representation, or runtime? • Scope of conformanceWho should conform, for which info exchanges? • Size of conformanceHow big is the Core, in absolute and relative terms? • Source of Core contentClean sheet, existing models, COIs, or current exchanges? • Speed of creation and adoption • How long until we have a “complete” Core? • How long until our information exchanges conform?

  14. Technical Group Assumptions • Target of conformance: • UCore 2.0 exchange specification • C2 Core (C2-specific extensions) reusable components • C2 Core IES framework and technical specifications • Kind of conformance • Representation conformance expected • Semantic conformance possibly permitted • Scope of conformance • Exchanges within C2 Capability Portfolio • Exchanges where producer is within portfolio • Only exchanges covered by C2 Conceptual Model

  15. Technical Group Assumptions • Size of conformance • Right size determined from experience • No larger than necessary • Start “small” and grow as needed • Source of C2 Core content • Important existing exchanges • Important producers outside C2 CPM • Speed of creation and adoption • Expect rapid change at beginning • Old components changed or removed, new ones added • Stability means decreased rate of change (not zero) • Adopt in all new in-scope implementation • Adopt in existing in-scope services over time

  16. Approach Highlights • Enterprise approach • Balance data interoperability & flexibility • Layered data framework • Reusable XML data components from COI overlaps • COI / POR developed Information Exchange Specifications • Semantic agreement and reuse drive C2 Core size • C2 Core components developed through iterative process • Harvest and harmonize data requirements and semantics from that which exists and is being operationally used • Built with reuse and extensibility in mind – allow for composabilty • Adoption over time through evolution not big bang

  17. C2 Core Value Proposition • Over time, data components properly belonging to many /most COIs are designed once • These components are usedas “building blocks” inall new data exchanges • When these new exchanges are designed, some / most of the data interoperability work is already done • Resulting value • Reduced cost • Faster development • Improved agility / flexibility

  18. Unclassified Concept – FAQ Highlights • Problem statement and value proposition for C2 Core? • How does C2 Core align with UCore? • What is does extension mean in C2 Core? • What is an extension of an IES? • Will C2 Core have a taxonomy like UCore? • What will be the cost or cost savings of C2 Core? • Why do we need an NDR? • C2 Core support low-bandwidth tactical networks? • Is C2 Core mandating JC3IEDM? • How specifically will C2Core extend UCore? • What does C2 Core extension by COI look like in my XSD? • How can I use a schema that isn’t conformant in an IES? • Is every C2 Core conformance IES completely new work? • Why do we need tools, and what do we need them for? • What do we mean by engineering C2 Core for reuse? • What is the connection between a COI Vocabulary & C2 Core? Unclassified

  19. Unclassified Concept – Guidance to OCSWG (harvesting existing data requirements) NOTE: “C2 Core”in this slide represents the resuable data components as developed by the OCSWG from the candidate models. Unclassified

  20. Unclassified Concept – Guidance to OCSWG (data component development process) NOTE: “C2 Core”in this slide represents the resuable data components as developed by the OCSWG from the candidate models. Unclassified

  21. Current Status & Future Plans • DSSC endorses C2 Core Concept Documentas good enough for further development • Wider staffing required, revised draft by September 2009 • Next deliverables • Configuration management plan • Conformance specification, UCore extension rules,C2 Core Naming & Design Rules (NDR) • Tools for C2 Core content developers • Demonstration objectives • Show a worked example of a C2 Core IES • Built with data components from C2 Core • Conforming to UCore and C2 Core specifications • Add the next layer of technical detail to theC2 Core development process and technical framework

  22. References • C2 Core Development Concepthttps://www.us.army.mil/suite/doc/16223485 • C2 Core FAQhttps://www.us.army.mil/suite/doc/16223486 • Technical Framework and Tools Sub-WG folderhttps://www.us.army.mil/suite/folder/15050521

More Related