Exemplar Series # 1 Interpretation of UPDM 1.0 SAR Diagrams in

Exemplar Series # 1 Interpretation of UPDM 1.0 SAR Diagrams in DoDAF 2.0 / DM2 Concepts Extracts for DoD EA Conference May 2010 DoDAF Development Team

Agenda Accomplishments Since Release of DoDAF V2.0 Promulgation Memo – Mike Wayson UPDM Search & Recue (SAR) Exemplars -Dave McDaniel DoDAF V2.0 SAR Analysis and Fit-for-Purpose Exemplar – Shelton Lee DoDAF V2.0 Way Ahead – Mike Wayson Questions & Answers - DoDAF V2.0 Development Team

Briefing Structure The OMG UPDM Team developed examples of the views as part of UPDM 1.0. It is called “Sample Problem” and is Annex C in the UPDM 1.0 Spec. – The UPDM Team is working on a refinement of the Sample Problem for UPDM 2.0. The DoDAF 2 development team went through the examples and interpreted in DoDAF 2 / DM2 terms. – DM2 PES XML documents corresponding to each marked-up diagram are being posted on the DM2 collaboration site (www.silverbulletinc.com/dm2) Briefing format 1. A UPDM diagram will be shown first, in it’s native form from UPDM 1.0 Annex C. Blue background. 2. Then DM2 annotated version of the same diagram will be shown. White background.

OV-2: Operational Connectivity Description UPDM SAR OV-2 Operational connectivity and resource flow needlines OV-2 [Architectural Description] Nodes Really s/b Search Node (SN) WO : warningOrder «Node» Search «Needline» «Needline» «Node» Place of Safety «Needline» DS : distressSignal Tsk : tasking Stat : status «Needline» «Needline» «Node» Rescue DS : distressSignal «Needline» Ctrl : control «Needline» Rqst : request «Node» SAR Asset Controller «Node» Person in Distress DS : distressSignal Tsk : tasking «Needline» Rqst : request «Needline» «Node» Tactical C2 «Needline» TI : trackInfo «Needline» «Node» Monitoring

OV-2: Operational Connectivity Description OV-2 with DM2 Markups Operational connectivity and resource flow needlines Bounding box means Resource at Location OV-2 [Architectural Description] Organizational Interactions Place of Safety1 WO : warningOrder Search Org Type PoS Org Type DS : distressSignal Produce (Activity)2 APBP Tsk : tasking Rqst : request SAR Asset Controller Organization Types Consume (Activity)2 Person in Distress Ctrl : control Rqst : request PersonType Information (Resource) Stat : status Rescue Org Type Location Type1 Resource Flows DS : distressSignal Tsk : tasking Legend: DS : DistressSignal Tactical C2 Org Type TI : trackInfo Monitoring Org Type Receive Distress Signal NOTE 1. Should generally not be shown in OV-2 unless an important constraint, i.e., not within the solution trade space. NOTE 2: Implied. In DoDAF 2, “produce”, “consume”, “send”, “receive” are Activities. An OV-2 diagram need not show the implied activities but the DM2 PES XML document must, even if they are just placeholders to be completed later, e.g., during OV-5 development. This precision solves the “overspecification” problem of earlier DoDAF OV’s.

Fit-for-Purpose OV-2 with SV-1 Composite OV-2 [Architectural Description] Organizational Interactions Bounding box means Resource at Location Legend: Location Type1 PersonType Search Org Type WO : warningOrder Place of Safety1 PoS Org Type Organization Types Resource Flows Tsk : tasking DS : distressSignal Boat Radio Communications System 2 Stat : status Boat DS : Radio2 distressSignal Rescue Org Type speak Person in DS : Distress voiceDistressSignal key Ctrl : control Information (Resource) Consume (Activity) Produce (Activity) System Materiel Rqst : request Tsk : tasking DS : keyDistressSignal Rqst : request SAR Asset Controller Tactical C2 Org Type TI : trackInfo Monitoring Org Type

UPDM SAR OV-5 Capabilities, activities (operational activities), relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent information OV-5b: Activity Model OV-5 [OperationalActivity] Search Reported Location Reported Condition «OperationalActivityAction» : Send Distress Signal distressSignal distressSignal «NodeRole» SN: Search «NodeRole» RN: Rescue «NodeRole» PoS: Place of Safety «Node» : Search and Rescue «NodeRole» PiD: Person in Distress Search «OperationalActivityAction» : Receive Distress Signal «OperationalActivityAction» : Send Warning Order location condition «OperationalActivityAction» : Find Victim «OperationalActivityAction» : Monitor Health warningOrder distressSignal «OperationalActivityAction» : Receive Distress Signal «OperationalActivityAction» : Provide Medical Assistance condition «OperationalActivityAction» : Recover Victim location warningOrder «OperationalActivityAction» : Transit to SAR Operation «OperationalActivityAction» : Process Warning Order Updated Condition Updated Location

FFP OV-5b/6c Hybrid Capabilities, activities (operational activities), relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent information One of three models used to describe activity (operational activity) - traces actions in a scenario or sequence of events OV-5b: Activity Model OV-6c: Event-Trace Description Legend: Organization Types OV-5 [OperationalActivity] Search Activities Reported Location Reported Condition Information Search Person In Distress APBP Part-Of Resource Flow Before-After Send Distress Signal Rescue Place of Safety Org Type Search and Rescue Search distressSignal Receive Distress Signal Find Victim Send Warning Order Receive Distress Signal Monitor Health warningOrder Provide Medical Assistance Transit to SAR Operation Process Warning Order Updated Condition NOTE 1: Do not have to be modeled Recover Victim Updated Location

DIV-2: Logical Data Model UPDM SAR DIV-2 Documentation of the data requirements and structural business process rules (In DoDAF V1.5, this was the OV-7) OV-7 [Logical Data Model] Logical Data Model «EntityItem» Last Known Position representedBy «InformationElement» control location * name : String registration : String tonnage : Integer color : String markings : String superstructure : String characteristics : String ownerOrOperator : String personsOnBoard : Integer emergencyEquipmentCarried : String operationalArea * * «EntityItem» SAR Operation caseName : String caseNumber : String taskingAuthority : String * «EntityItem» SearchStatus status : String representedBy «InformationElement» tasking «InformationElement» control «EntityItem» Assignment description : String assetAssignments * * 1 representedBy «InformationElement» status location * «EntityItem» Search Area waypoints : String activationTime : String duration : String driftDirection : String driftSpeed : Integer commenceSearchPoint : String 1 representedBy «InformationElement» warningOrder 1 * * «EntityItem» Search Object objects latitude : String longitude : String time : String sourceOfReport : String representedBy «InformationElement» trackInfo «InformationElement» distressSignal 1 «EntityItem» StrandedPersonInfo name : String condition : String 1 * 1 representedBy «InformationElement» request person

Documentation of the data requirements and structural business process rules (In DoDAF V1.5, this was the OV-7) DIV-2: Logical Data Model DIV-2 with DM2 Markups DIV-2 [Logical Data Model] Logical Data Model Last Known Position control location * latitude : String longitude : String time : String sourceOfReport : String * Legend: 1 DataType location * Search Object objects informationAssociation “has” “aggregates” tasking control * name : String registration : String tonnage : Integer color : String markings : String superstructure : String characteristics : String ownerOrOperator : String personsOnBoard : Integer emergencyEquipmentCarried : String Rule (NOTE 1) Search Area InformationType waypoints : String activationTime : String duration : String driftDirection : String driftSpeed : Integer commenceSearchPoint : String operationalArea * * SAR Operation caseName : String caseNumber : String taskingAuthority : String 1 Subtype (NOTE 2) Assignment description : String assetAssignments * 1 warningOrder trackInfo distressSignal 1 * 1 StrandedPersonInfo name : String condition : String *person 1 request * status SearchStatus status : String NOTE 1: tied to Info via activityResourceOverlapSuperSubtypeOfRule, activityResourceOverlap, Resource, and that Info is a type of Resource NOTE 2: Data is a subtype of Information, a more formatted version.

SV-1 Systems Interface Identification of systems and system items and their interconnections Description UPDM SAR SV-1 SV-1 [Capability Configuration] Maritime Rescue Unit «CapabilityConfiguration» Maritime Rescue Unit «HumanResource» MRT : Maritime Rescue Team «ResourceComponent» MR Boat : Boat «ResourceInteraction» «ItemFlow» : BoatInstruction : BoatInstruction «ResourceInteraction» «ItemFlow» : BeaconInstruction : BeaconInstruction «ResourceComponent» Beacon : Lighting Device «ResourceComponent» Radio : Communication Device «ResourceInteraction» «ItemFlow» : RadioInstruction : RadioInstruction «ResourceComponent» LifePreserver : Life Saving Device «ResourceComponent» MR Aircraft : Aircraft : BoatInstruction : BeaconInstruction : RadioInstruction «ResourceInteraction» «ItemFlow» : AircraftInstruction : AircraftInstruction «PostRole» Searcher : MRT Searcher «PostRole» Radio Operator : MRT Communicator «ResourceInteraction» «ItemFlow» : LifePreserverInstruction : LifePreserverInstruction «PostRole» Driver : MRT Boat Driver : LifePreserverInstruction «PostRole» Rescue Swimmer : MRT Swimmer : AircraftInstruction «PostRole» Pilot : MRT Helo Pilot

SV-1 Systems Interface Identification of systems and system items and their interconnections Description SV-1 with DM2 Markups SV-1 [Performer] Maritime Rescue Unit Maritime Rescue Unit Maritime Rescue Team MRT Boat Boat Receive Propusion and BoatInstruction Rudder Control Equipment Lighting Device Receive BeaconInstruction Communication Device Life Saving Device Aircraft BeaconInstruction Receive RadioInstruction Send BeaconInstruction RadioInstruction Send RadioInstruction LifePreserverInstruction Send LifePreserverInstruction Receive LifePreserverInstruction Receive AircraftInstruction Helo AircraftInstruction Legend: Systems Information ResourceFlow Activities PersonType Whole - Part Performer Send BoatInstruction BoatInstruction Organization Type APBP Send AircraftInstruction MRT Boat Driver MRT Searcher MRT Communicator MRT Swimmer MRT Helo Pilot

UPDM SAR CV-1 Overall vision for transformational endeavors, provides a strategic context for the capabilities described, and provides a high-level scope. CV-1: Vision StV-1 [Architectural Description] Enterprise [1] «WholeLifeEnterprise» Search and Rescue goals «EnterpriseGoal» Fulfill International Obligations goals «EnterpriseGoal» Maintain UK SAR Responsibility startDate 2010-01-01 00:00:00 visions «EnterpriseVision» UK SAR Vision visions «EnterpriseVision» UK SAR Vision endDate 2014-06-01 00:00:00 1 1 Temporal Part1 Temporal Part2 1 «EnterprisePhase» Phase 1 «EnterprisePhase» Phase 2 startDate 2010-01-01 00:00:00 startDate 2012-12-01 00:00:00 endDate 2010-12-01 00:00:00 endDate 2014-06-01 00:00:00 «EnterpriseVision» UK SAR Vision «EnterpriseGoal» «requirement» Fulfill International Obligations exhibits «Capability» Assistance «Capability» Recovery «Capability» Search exhibits «Capability» Assistance «Capability» Recovery «Capability» Search «EnterpriseGoal» «requirement» Maintain UK SAR Responsibility

CV-1 with DM2 Markups Overall vision for transformational endeavors, provides a strategic context for the capabilities described, and provides a high-level scope. CV-1: Vision CV-1 SAR Vision US SAR Vision International Obligations Fulfilled Search and Rescue US SAR Responsibility Maintained SAR Performer SAR Phase 1 SAR Phase I Performer 2010-01-01 00:00:00 startDate3 2010-01-01 00:00:00 startDate2 2012-12-01 00:00:00 startDate4 2012-12-01 00:00:00 endDate Assist Recover Legend: Visions Capabilities Measures MeasureTypes Resource5 Activities Activities part of Capabilty Performer1 Whole Part 2014-06-01 00:00:00 endDate Temporal Whole Part Measure of Temporal boundary Capability of Performer Desired Effects SAR Phase 2 Performer SAR Phase 2 2014-06-01 00:00:00 endDate Search NOTE 1: Performer is probably an aggregate (wholeparts), aka “Capability Configuration” NOTE 2: Whole Capability lasts 54 months NOTE 3: Phase I lasts 35 months NOTE 4: Phase II lasts 19 months NOTE 5: Desired effects are states of Resources

UPDM SAR SvcV-3 SvcV-3a SystemsServices Matrix Relationships among between systems and services in a given architecture. SvcV-3b ServicesServices Matrix Relationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc. SOV-3 [Architectural Description] SAR Services [2] «Capability» Land SAR «Expose» «ServiceInterface» Land Search and Rescue Service «Capability» Maritime SAR «Expose» «ServiceInterface» Maritime Search and Rescue Service

CV-7: Capability to Services Mapping CV-7 with DM2 Markups Mapping between capabilities and the services that these capabilities enable. CV-7 [Architectural Description] SAR Services [2] Percent Rescued 99 Legend: Maritime SAR Land SAR Capability Land Victims Conduct Land SAR Maritime Search and Rescue Service Land Search and Rescue Service Access Land SAR Resources Rescue Service Part of Activity Activities part of Capabilty Resource Service Description Measure Search Request Measure Type Land Search and Rescue Service Port Process Search Request Land SAR “Capability” Accessed by Service Land SAR System Land Search and Rescue Service Port Description Desired Effect Measure of Desired Effect Performer supports or provides Capability Describes Activity Changes Resource Performer Resource Flow (ARO) Information APBP

UPDM SAR SvcV-2 SvcV-2 Services Communications Description Services and service items and their related communications laydowns SOV-2 [Architectural Description] SAR Services [1] «Interface» Search Interface «Interface» Maritime Rescue Interface InitiateSearch (in missingPersonInfo, out searchCaseID) RequestSearchUpdate (in searchCaseID, in status) CancelSearch (in searchCaseID, in reason) RescuePerson (in strandedPersonInfo) Maritime Rescue Interface Search Interface «ServiceInterface» Search and Rescue Service «Interface» Fire Service Interface RescuePerson (in trappedPerson) «ServiceInterface» Maritime Search and Rescue Service Fire Service Interface Recue Interface Helicopter Service Interface «Interface» Rescue Interface InitiateRescue (in strandedPersonInfo, out rescueCaseID) «Interface» Helicopter Service Interface TransportCasualty (in patientInfo, in transportedTo)

SvcV-2 with DM2 Markups SvcV-2 [Architectural Description] SAR Services [1] missingPersonInfo InitiateSearch searchCaseID SvcV-2 Services Communications Description Services and service items and their related communications laydowns Search SD searchCaseID RequestSearchUpdate searchCaseID reason CancelSearch status Maritime Rescue SD strandedPersonInfo NOTE 1: only shows the descriptions need to link Service Descriptions to Services Makes available descriptions of how to use the S&R Service RescuePerson Uses descriptions of how to use the different S&R performer types Legend: Services Fire Service SD Search and Rescue Service Maritime Search and Rescue Service trappedPerson Activities RescuePerson Information Service Descriptions Subtypes Resource Flow Recue Interface Rescue SD strandedPersonInfo Helicopter SD patientInfo transportedTo Part of InitiateRescue rescueCaseID TransportCasualty

UPDM SAR SvcV-3 SvcV-3a SystemsServices Matrix Relationships among between systems and services in a given architecture. SvcV-3b ServicesServices Matrix Relationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc. SOV-3 [Architectural Description] SAR Services [2] «Capability» Land SAR «Expose» «ServiceInterface» Land Search and Rescue Service «Capability» Maritime SAR «Expose» «ServiceInterface» Maritime Search and Rescue Service

Helicopter Service Maritime Rescue Service Fire Service Fire Service 1 3 3 1 3 1 2 Degree of interaction between services: 0 - none 1 - low 2 - moderate 3 - high (symmetric matrix) Partial list of services Relationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc. Maritime Rescue Service Land SAR Service SvcV-3b ServicesServices Matrix Helicopter Service Maritime SAR Service Relationships among between systems and services in a given architecture. Land SAR Service Maritime SAR Service SvcV-3b Services-Services Matrix with DM2 Markups SvcV-3a SystemsServices Matrix Legend: Services 3 1 1

SvcV-4 Services Functionality Description UPDM SAR SvcV-4a Functions performed by services and the service data flows among service functions (activities) [Architectural Description] SAR Services [SOV-4a] Service Interface Service Policy Name Name Land Search and Rescue Service Driving Record Any member involved in the operation of road vehicles must have a clean driving record. Maritime Search and Rescue Service Swim All members of the rescue team must be able to swim. First Aid All members of the rescue team must be able to perform basic first aid. Danger No member of the search and rescue team should put themselves in unnecessary danger. Search and Rescue Service Text

SvcV-10a Services Rules Model with DM2 Markups SvcV-10a [Architectural Description] SAR Services One of three models used to describe service functionality - identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation SvcV-10a Services Rules Model Legend: Activity Performed By Performer (APBP)1 Services Land SAR Description Land Search and Rescue Service Land Search and Rescue Service Port Land SAR 2 Rules 3 Performer Rule constrains the Activities performed by Performers1 Service Description Drive Whole Part Provide First Aid Activities Driving Record Avoid Danger Any member involved in the operation of road vehicles must have a clean driving record. Maritime SAR Description2 Maritime Search and Rescue Service Maritime Search and Rescue Service Port Maritime SAR3 Swim All members of the rescue team must be able to swim. Swim Provide First Aid First Aid All members of the rescue team must be able to perform basic first aid. Avoid Danger SAR Description Search and Rescue Service Search and Rescue Service Port Land SAR3 Provide First Aid Avoid Danger Danger 2 No member of the search and rescue team should put themselves in unnecessary danger. NOTE 1: A Service is a type of Performer NOTE 2: The Service Description includes the Rules that will be adhered to. NOTE 3: Means, any Performer that is accessed by the Service.

UPDM SAR PV-1 PV-1: Project Portfolio Relationships Organizational structures needed to manage a portfolio of projects and shows dependency relationships between the organizations and projects. AcV-1 [Architectural Description] Enterprise [2] «ActualProject» SAR Project startDate 2009-09-01 00:00:00 endDate 2014-06-01 00:00:00 «IncrementMilestone» Rescue Unit Config 1 endDate 2010-01-01 00:00:00 resource «CapabilityConfiguration» Maritime Rescue Unit «IncrementMilestone» Rescue Unit Config 2 «OutOfServiceMilestone» Rescue Unit Config 1 OOS endDate 2012-01-01 00:00:00 resource «CapabilityConfiguration» Maritime Rescue Unit endDate 2012-01-01 00:00:00 «OutOfServiceMilestone» Rescue Unit Config 2 OOS resource «CapabilityConfiguration» Maritime Rescue Unit V2 endDate 2014-06-01 00:00:00 resource «CapabilityConfiguration» Maritime Rescue Unit V2

PV-2 with DM2 Markups PV-2: Project Timelines A timeline perspective on programs or projects, with the key milestones and interdependencies PV-2 [Architectural Description] Enterprise [2] SAR Project startDate 2009-09-01 00:00:00 endDate 2014-06-01 00:00:00 Individual Project System Temporal Boundaries Performers Bounding box means the temporal boundaries are temporal parts of the Project Rescue Unit Config 1 IncrementMilestoneDate 2010-01-01 00:00:00 Maritime Rescue Unit Temporal parts of the Systems (Resources) that are produced by the Activities that are part of the Project Measures Measure Type Upper part of bounding box means the temporal boundaries is a temporal part of the System, Lower part of bounding box means the System ? Performer (aka “capability configuration”) that enables / supports the SAR sub-capabilities: Assistance, Recovery, etc. Rescue Unit Config 1 OutOfServiceMilestoneDate 2012-01-01 00:00:00 Maritime Rescue Unit Rescue Unit Config 2 IncrementMilestoneDate 2012-01-01 00:00:00 Maritime Rescue Unit V2 Rescue Unit Config 2 OutOfServiceDate 2014-06-01 00:00:00 Maritime Rescue Unit V2 SAR Project Partial Interpretation as GANNT Rescue Unit Config 1 IOC? Rescue Unit Config 1 Rescue Unit Config 2

UPDM SAR PV-1 PV-1: Project Portfolio Relationships Organizational structures needed to manage a portfolio of projects and shows dependency relationships between the organizations and projects. AcV-1 [Architectural Description] Projects «ActualProject» Emergency Response Enhancement startDate 2009-05-15 00:00:00 endDate 2015-05-15 00:00:00 subProject «ActualProject» SAR Project startDate 2009-09-01 00:00:00 subProject «ActualProject» Flood Response endDate 2014-06-01 00:00:00 «ActualProjectMilestone» Project Start «ActualProjectMilestone» Capability Assessment Complete «ActualProjectMilestone» Requirements Complete «ActualProjectMilestone» Start Phase 1 «ActualProjectMilestone» Start Phase 2 «ActualProjectMilestone» Project Complete endDate 2009-09-01 00:00:00 endDate 2009-10-01 00:00:00 endDate 2009-12-01 00:00:00 endDate 2010-01-01 00:00:00 endDate 2012-12-01 00:00:00 endDate 2014-06-01 00:00:00

FFP PV-2 Fusion with Systems Engineering Plan (SEP) with DM2 Markups FFP PV-2 Fusion [Architectural Description] Projects startDate 2009-05-15 00:00:00 Enhance Emergency Response endDate Legend: Individual Project 2015-05-15 00:00:00 Execute SAR Project Flood Response PV-2: Project Timelines A timeline perspective on programs or projects, with the key milestones and interdependencies Measures MeasureTypes Temporal Boundary Measure of Temporal boundary Temporal Whole Part Start Project endDate 2009-09-01 00:00:00 Complete Project endDate 2014-06-01 00:00:00 Assess Capability Develop Requirements Complete Capability Assessment Requirements Complete endDate 2009-10-01 00:00:00 endDate 2009-12-01 00:00:00 Conduct Phase 1 Start Phase 1 endDate 2010-01-01 00:00:00 Conduct Phase 2 Start Phase 2 endDate 2012-12-01 00:00:00