Presentation is loading. Please wait.

Presentation is loading. Please wait.

DoD Architectures and Systems Engineering Integration

Similar presentations

Presentation on theme: "DoD Architectures and Systems Engineering Integration"— Presentation transcript:

1 DoD Architectures and Systems Engineering Integration
EXTRACT DoD Architectures and Systems Engineering Integration NDIA 15th Annual Systems Engineering Conference Mr. Walt Okon Mr. David McDaniel (ctr) October 2012

2 22 Oct 2012

3 DoDAF Evolution Plan DoDAF v1.5 1995 C4ISR F/W v1.0 v2.0 2003 2007
UDAF v2.05 2003 2007 JCIDS & NR-KPP Applicability beyond C4ISR Use-based Integrated Architecture 2009 2010 2012 2014 v2.01 v2.02 v2.03 DoDAF/DNDAF v2.04 1997 2016 2013 Joint Interoperability DoDAF v1.0 C4ISR F/W v2.0 Net-centricity and SoA SvcV views 26 AV/OV/SV/TV views Linked to I&S policies CADM 2.0 Fit-for-purpose Data-centric architecture Improved models of systems, services, capabilities, rules, measures DoDAF Meta Model (DM2) based on IDEAS Urgent CRs 52  1 XSD IDEAS Foundation v1.0 fixes TECHEDITS DM2 OWL Federal Common Approach DNDAF Security Views MODEM – DM2 Harmonization (IDEAS Domain Level) NATO NAF Standardization, e.g., ISO OMG OASIS UAF Framework Objective: Achieve a single integrated architecture framework for interoperability. Achieve a US, Canada, and United Kingdom single framework with a common data meta-model Achieve alignment with the US Government’s Common Approach to enterprise architecture 22 Oct 2012 3

4 Initiatives: Federal Government Common Approach
sub-architecture domains (6) 50 document artifacts primary outcomes (4) levels of scope (8) basic elements of an EA program (8) There are four primary outcomes that are enabled by the common approach to federal EA:  Service Delivery  Functional Integration  Resource Optimization  Authoritative Reference There are eight levels of scope for implementing an architecture using the common approach:  International  National  Federal  Sector  Agency  Segment  System  Application There are eight basic elements that must be present and be designed to work together in each agency EA program:  Governance  Principles  Method  Tools  Standards  Use  Reporting  Audit There are six sub-architecture domains in the common approach to Federal EA:  Strategic  Business Services  Data and Information  Enabling Applications  Host Infrastructure  Security There are six reference models in the common approach to Federal EA:  Performance Reference Model - PRM  Business Reference Model - BRM  Data Reference Model - DRM  Application Reference Model - ARM  Infrastructure Reference Model - IRM  Security Reference Model - SRM reference models (6) 22 Oct 2012

5 22 Oct 2012

6 Convergence Approach for NAF: IDEAS Layered Approach
ü 1. Foundation (upper ontology) Ontologic concepts and relationships Commonly used patterns (e.g., resource flow, exchange) Consensus concepts and relationships (e.g., person, organization, material) 2. Common patterns 3. Common architecture domain objects & relationships X X X X Views for: NATO “core” architecture views specific to needs and policies of individual nations NAF views national views national views national views 22 Oct 2012 6

7 Fit For Purpose (FFP) Views
22 Oct 2012

8 Fit For Purpose (FFP) and Legacy Views
supported processes views JCIDS DAS DM2 Capabilities Locations OPS SE IDEAS Ontology Set theoretic 4-D mereotopologic Performers Rules legacy PPBE Services CPM fit-for-purpose (FFP) Reification Projects Pedigree Resource Flows 22 Oct 2012

9 DM2 Has Three Model Levels
Conceptual Data Model (CDM) Concepts and concept relationships Propositions and definitions validated by SMEs Logical Data Model (LDM) Reified and formalized relationships This is where almost all DoDAF design and analysis work is done Physical Exchange Specification (PES) XML encoding of LDM Auto-generated from the LDM No need to look at (unless you are a tool programmer) The DM2 has several levels, each of which is important to a particular viewer of Departmental processes. A conceptual level or Conceptual Data Model (CDM) defines concepts and relationships between them business language of the enterprise normative across the six core processes A logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematically A physical level or Physical Exchange Specification (PES) adds required NCDS metadata for security and pedigree to the LDM is generated from the LDM as a set of XSD’s, one schema per DoDAF-described Model 22 Oct 2012

10 Example FFP: OV-2 / SV-1 Hybrid
22 Oct 2012

11 Creating a FFP Model Use the DM2 Logical Data Model.
Create a new diagram. Drag DM2 elements onto the diagram. Extend classes (including relationship classes) as needed. Use the IDEAS Profile to generate XSD. Develop narrative documentation. Share XSD and documentation with your COI. Tutorial at tutorial 22 Oct 2012

12 22 Oct 2012

13 DoDAF meta-model for: DOTMLPF
temporality, behavior, scenarios, M&S, executable architectures 22 Oct 2012

14 DOTMLPF Doctrine. In Joint Pub 1-02, Dictionary of Military and Associated Terms, “doctrine” is defined as “Fundamental principles by which the military forces or elements thereof guide their actions in support of national objectives. It is authoritative but requires judgment in application.” The concept of judgment in application concerns decision-making. This cannot be precisely modeled except perhaps as rules affecting the applicability of other rules. The parts of doctrine that can be modeled are included in the Capabilities data group as follows: Principles are modeled as rules. Military forces and elements thereof are modeled as types of performers and assemblies of performers. Actions are modeled as activities. Thus, doctrine is contained in the specification of certain fundamental rules, activities, and performers and the relationships among them. These relationships are: Each performer must be the performer of one or more activities. Each activity must be performed by one or more performers. Each rule may be a constraint on one or more activities. Each activity may be constrained by one or more rules. Thus, since the DM2 contains the entities and relationships listed above it contains the necessary and sufficient set of entities and relationships to permit the modeling of doctrine and a separate data group for doctrine is not required. Organization. An organization is a specific real-world assemblage of people and other resources organized for an ongoing purpose. DM2 models organizations as a type of performer. Defining an organization as an assemblage means that an organization has whole-part relationships. An organization may include other organizations. Each part of one organization may also be a part of other organizations. The following DM2 relationships are involved in the capability-based analysis of organization where each organization is a type of performer: Each capability must be the result of one or more activities. Each activity must be performed by one or more performers, where each performer must be a type of organization; therefore, each capability must be provided by one or more organizations. Each organization must be the performer of one or more activities. Training. Training is defined as an activity or set of activities to increase the capacity of one or more performers to perform one or more activities under specified conditions to specified standards of performance: Each performer may be either an organization or a person in a role. Each performer must be of one or more activities. Each activity must be performed under one or more conditions. Each activity must be completed to meet one or more standards. Each standard must be specified by one or more measures. Materiel. Materiel is a type of resource. Like organizations, materiel has whole-part relationships. Materiel may be a whole comprised of parts that are themselves materiel, and a materiel may be a part of other materiel.[AKB1]  The following DM2 relationships are involved in the capability based analysis of materiel where each Materiel is a part of a Performer: Each performer must be assigned to one or more organizations. Each performer must be used by one or more persons in roles, and each person in a role must be a member of only one organization at any one time. Each activity must be performed by one or more performers, and each performer must be either an organization or a person in a role. Leadership and education. Joint Pub 1-02 does not define leadership. In the context of the DM2, leadership is defined as the ability to lead. Joint Pub 1-02 defines military education as the systematic instruction of individuals in subjects that will enhance their knowledge of the science and art of war. Thus, to a certain extent, leadership is a set of skills that can be taught as part of the science and art of war and a smaller set of skills that can be trained as activities that must be performed under specified conditions to meet specified standards. Leadership is about judgment in application of doctrine. Leadership deals with decision-making, and it cannot be precisely modeled except perhaps as rules affecting the applicability of other rules. Personnel. Personnel refer to persons in roles. Each person in a role is a type of performer. The following DM2 relationships are involved in the capability based analysis of materiel where each person in a role is a type of performer: Each person in a role must be assigned to only one organization at any one time. Each person in a role may be the user of materiel. Each materiel must be used by one or more persons in a role. Each activity must be by one or more performers, where each performer must be either an organization or a person in a role using a materiel. Each person in a role must be the performer of one or more activities. Each rule may be a constraint on one or more persons in a role. Facilities. A facility is a real property entity consisting of underlying land and one or more of the following: a building, a structure (including linear structures), a utility system, or pavement. This definition requires that facilities be firmly sited on or beneath the surface of the earth. Things such as tents, aircraft, and satellites that are not fixed to a location on or beneath the surface of the earth are a type of materiel. Facilities and their materiel are germane to capability-based analyses through these relationships: Each facility may be the site of one or more performers and any materiel that is part-of the performer(s). Each performer may be at only one facility or within a materiel enclosure at any one time. Because a facility is an individual, it has a spatial and temporal extent. An individual instance of materiel has a spatial and temporal extent in contrast to a type, which does not. Generally, architecture descriptions deal with types of materiel, not with specific individuals such as serial-numbered items of equipment. However, the DM2 does represent a performer at a location and, consequently, any materiel that is part of the performer would also be at the location.  [AKB1]not a felicitous name… need to treat this in some way that lets me rewrite in English. 22 Oct 2012

15 Temporality, Behavior, Scenarios, M&S, Executable Architectures
22 Oct 2012

16 DM2 is founded on 4D ontology
Four dimensionalist -- xyzt Extensional -- physical existence is the criterion for identity Signs and representations are separated from referents Mathematics: Type theory ~ Set theory Mereology (wholes and parts) 4D Mereotopology (spatio-temporal relations) Then domain concepts inherit several important properties. None of these foundation properties are unusual; they are all used in reasoning everyday: Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent. Types, sets of things. Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework. Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure. Temporal whole-part; e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity). Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition. Interface; e.g., an overlap between two things. [1] Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.) mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology. or 16 22 Oct 2012

17 Maritime Interdiction / ISR “National Critical Contact of Interest”
Example OV-1 Maritime Interdiction / ISR “National Critical Contact of Interest” FORCEnet E-2 P-3 Nat’l CCOI CVN DDG SH-60 C2 Data FORCEnet Data Link Electronic Emission Detection Shipping Lanes SSN SSGN 22 Oct 2012

18 Maritime Interdiction / ISR Scenario “Critical Contact of Interest Surveillance and Prosecution” OV-6c Sequences Command/Control Nat'l Assets SSN CVN DDG SH-60/UAV E-2 P-3 CCOI report Voice report / OPTASK revision Track ID Change Intel report Control Message Launch/Control Message/Imagery Command Message Command and Control Intel Report Various Voice /SIPRNET /GCCS-M Link-11/16 Link-11 / SIPRNET Voice Voice / GCCS-M/ SIPRNET BYG-1 ISIS SSDS GCCS-M AEGIS HAWKLINK E2-C2 P3-C2 Control / Track Message 22 Oct 2012

19 DoDAF and SE Documents and Artifacts
22 Oct 2012

20 DoDAF Artifacts Overlaid on “V”
Operations & Support Life-Cycle Sustainment RD ISR ISR FOC Capability Validation (OT) CBA Full-Rate Production & Deployment RD M&S identify ITR VAL IOC System Validation (OT) ICD ASR MSA LRIP PCA define CPD MS-A MS-C SRR SFR Prototyping System Verification (DT) PRR FCA represent VER REQM MS-B System Design Subsystem Verification (DT) CDD Acquisition Model Decisions & Milestones Capabilities Based Assessment (CBA) Material Solutions Analysis (MSA) Technology Development (TD) Engineering & Manufacturing Development (E&MD) System Engineering Technical Reviews Initial Technical Review (ITR) Alternative System Review (ASR) System Requirements Reviews (SRR) System Functional Reviews (SFR) Preliminary Design Reviews (PDR) Critical Design Reviews (CDR) Test Readiness Review (TRR) Production Readiness Review (PRR) In-Service Review (ISR) Functional Configuration Audit (FCA) Physical Configuration Audit (PCA) JCIDS Documents Initial Capabilities Doc (ICD) Capabilities Design Doc (CDD) Capabilities Production Doc (CPD) Typical Systems Engineering Work Products Performance Specification / System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS) System Design Document (SDD) / System Segment Design Document (SSDD) Software Requirements Specification (SwRS) Software Design Document (SwDD) Interface Requirements Specification (IRS) Interface Control Document (ICD) / Interface Design Document (IDD) Data Base Design Document (DBDD) Test and Evaluation Master Plan (TEMP) CMMI Process Areas Requirements Development (RD) Requirements Management (REQM) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) PDR specify TRR Component Design Component Verification configure PI CDR VER TS instantiated Build Unit Test 22 Oct 2012

21 Notional Systems Engineering Documents with embedded DoDAF artifacts
System Specification (SSS, SDS, SDD, etc.) Functional Description – SV-4 Performance Specification – SV-7 Interfaces – SV-1, high-level SV-2 and 6 Standards to Comply – StdVs mapped to SV’s Components – SV-1 Interface Specification (IRS, ICD, etc.) – SV-2 and 6, possibly linked to DIV-2 and 3 22 Oct 2012

22 Elements of Quality Architecture
Single Architecture Framework Policy, Direction, Guidance Exchange Architecture Tools Certified Architects Enabling efficient and effective acquisition of hardware, software and services used by DoD and Partners in mission performance. Unified Architecture Framework 22 Oct 2012 22 22

23 Summary DoDAF is foundational to Federal Government and NATO
FFP + DM2 enables more sophisticated modeling than legacy views DoDAF’s model for reification supports many life-cycle models, including SE “V” The DoDAF Meta Model (DM2) was designed to allow modeling beyond the legacy views DoDAF artifacts, SE documents, and artifacts should be complimentary 22 Oct 2012

24 22 Oct 2012

Download ppt "DoD Architectures and Systems Engineering Integration"

Similar presentations

Ads by Google