UPDM 2.0 Modeling - Enterprise Architect

Series: Model Driven Development

UPDM

Enterprise Architect Visual Modeling Platform

http://www.sparxsystems.com

© Sparx Systems 2013 Page 1

UPDM 2.0

Modeling

All material © Sparx Systems 2013


http://www.sparxsystems.com.au/

http://www.sparxsystems.com/


UPDM




Table of Contents

INTRODUCTION ............................................................................................................................................ 3

OVERVIEW OF UPDM PROCESS ............................................................................................................... 3

STRUCTURING YOUR UPDM MODEL ..................................................................................................... 4

ALL VIEWS..................................................................................................................................................... 4 AV-1 Overview and Summary Information ................................................................................................ 5 AV-2 - Operational Activity Dictionary ..................................................................................................... 6 AV-3 – Measurements Definition ............................................................................................................... 7

STRATEGIC VIEWS ........................................................................................................................................ 8 StV-1 Capability Vision (DoDAF CV-1) .................................................................................................... 9 StV-2 Capabilities Taxonomy (DoDAF CV-2) ........................................................................................... 9 StV-3 Capability Phasing (DoDAF CV-3) ............................................................................................... 10 StV-4 Capability Dependencies (DoDAF CV-4) ...................................................................................... 11 StV-5 Capability to Organization Deployment (DoDAF CV-5) ............................................................... 13 StV-6 Operational Activity to Capability Mapping (DoDAF CV-6) ................................................... 13

OPERATIONAL VIEWS ................................................................................................................................. 15 OV-1 Operational Context Graphic ......................................................................................................... 15 OV-2 Operational Node Relationship Description (DoDAF Operational Resource FlowDescription) .. 17 OV-3 Operational Exchange Summary (DoDAF Operational Resource Flow Matrix) .......................... 18 OV-4 Organizational Relationships Chart............................................................................................... 19 OV-5 Operational Activity Model (DoDAF Operational Activity Decomposition Tree – OV-5a) .......... 21 OV-6a Operational Rules Model ............................................................................................................. 22 OV-6b Operational State Transition Desciption ...................................................................................... 23 OV-6c Operational Event Trace .............................................................................................................. 24 OV-7 Logical Data Model (DoDAF DIV-1/DIV-2) ................................................................................. 25

SERVICE ORIENTED VIEWS ......................................................................................................................... 26 SOV-1 Service Taxonomy (DoDAF SvcV-1: Services Interface Description) ......................................... 26 SOV-2 Service Interface Specification (DoDAF SvcV-2)......................................................................... 27 SOV-3 Capability to Service Mapping (DoDAF CV-7) ........................................................................... 28 SOV-4a Service Behaviors and Constraints (DoDAF SvcV-10a) ............................................................ 29 SOV-4b Service State model (DoDAF SvcV-10b) .................................................................................... 30 SOV-4c Service Interaction Specification ................................................................................................ 31 SOV-5 Service Functionality (DoDAF SvcV-4) ....................................................................................... 31

SYSTEM VIEWS ............................................................................................................................................ 33 SV-1 Resource Interaction Specification ................................................................................................. 33 SV-2 Capability Configuration ................................................................................................................ 34 SV-4 Functionality Description (DoDAF Systems Functionality Description)........................................ 35 SV-5 Function to Operational Activity/Service Function Traceability .................................................... 36 SV-6 System Exchange Matrix (DoDAF Systems Resource Flow Matrix) ............................................... 38 SV-7 Resource Performance Parameters (DoDAF Systems Measures Matrix) ....................................... 39 SV-8 System Capability Configuration Management (DoDAF Systems Evolution Matrix) ..................... 41 SV-9 Technology and Skills Forecast (DoDAF Systems Technology and Skills Forecast) ..................... 42 SV-10a System Rules and Constraints (DoDAF Systems Rules Model) ................................................... 42 SV-10b Resource State Transition Description (DoDAF System State Transition Description) ............. 44 SV-10c Resource Event Trace Description (DoDAF System Event Trace Description) .......................... 45 SV-11 System Data Model (DoDAF DIV-3 Physical Data model) .......................................................... 46

ACQUISITION VIEWS ................................................................................................................................... 47 AcV-1 System of Systems Acquisition Clusters (DoDAF PV-1) .............................................................. 48 AcV-2 Program Timeline (DoDAF PV-2) ................................................................................................ 48 AcV-3 Typical Project (DoDAF PV-3) .................................................................................................... 49 AcV-3 Actual Project Instance (DoDAF PV-3)........................................................................................ 50

TECHNICAL VIEWS ...................................................................................................................................... 51 TV-1 Standards Profile (DoDAF StdV-1) ................................................................................................ 52 TV-2 Standards Forecast (DoDAF StdV-2) ............................................................................................. 53

CONCLUSION ............................................................................................................................................... 55



UPDM




Introduction When modeling joint task operations involving different organizational groups you need to

have a consistent model approach. The Unified Profile for DoDAF and MODAF (UPDM)

Version 2.0 provides a framework that incorporates both DoDAF 2.0 and MODAF 1.2

frameworks. Although based on military frameworks, you can use UPDM to model any type

of combined operations from domestic search and rescue through to combined force military

operations.

Enterprise Architect’s MDG Technology for UPDM 2.0 provides, along with the UPDM 2.0

framework, comprehensive facilities to create models and develop code from these models,

as well as test and analyze these software intensive systems within a single development

environment. Using Enterprise Architect you can integrate your model with each and every

phase of the software development lifecycle.

The purpose of this paper is to examine the development of a UPDM model using Enterprise

Architect. The example we use is the Search and Rescue (SAR) model, which is presented in

the UPDM specification and reproduced in the UPDM Example Model provided with the

MDG Technology for UPDM add-in. This paper discusses the core features of the add-in

along with other Enterprise Architect features that are complementary to UPDM modeling.

Overview of UPDM Process UPDM defines an architecture that is broadly structured around a set of ‘Views’ or planes.

These Views start with defining high level strategic concepts and each subsequent view

progressively defines more concrete representations of how these strategic concepts are to be

implemented. UPDM includes the following views:

All Views

Provides a general overview

Operational Views

Provides an operational view of what needs to be accomplished

Service Orientated Views

Identifies the services involved

Strategic Views

Models the capabilities required for delivering a strategy

System Views

Relates systems to operational needs

Acquisition Views

Identifies the acquisition of required resources

Technical Views

Describes the required technical standards

Views can incorporate models defined using UML, SysML or other modeling languages

For more details on UPDM see:

Note: The names of the views used in this paper are based on the MODAF view

names, rather than DoDAF view names, as the SAR example is a

MODAF model.


http://www.omg.org/spec/UPDM/2.0/


UPDM




UPDM Version 2.0 Specification

Structuring your UPDM Model A common method of structuring a project is to define an outline of the views and then

provide a main diagram that provides links to the core diagrams supplied in these views. This

can be automatically generated using the Model Wizard supplied with the UPDM MDG.

A project structure and overview diagram can be created automatically for UPDM using

Enterprise Architect's Model Wizard, as shown in Figure 1.

UPDM Civ ilian Maritime SAR

All Views

Strategic View

Operational View

Service Oriented View

Systems View

Acquisition View

Technical View

«AV-1»

Enterprise Definition

«AV-2»

Operational Activity

Dictionary report

«AV-2»

Capability Configuration

Dictionary report

«AV-3»

Measurements (Class)

«AV-3»

Measurements (Actual)SAR Value Types

«StV-1»

Enterprise

«StV-2»

Capabilities

«StV-4»

Capability Clusters

«StV-4»

Capability Dependencies

«StV-6»

Capabilities (Mappings)

«OV-1a»

Maritime Rescue

«OV-1b»

Operational Context

Description

«OV-1d»

Operational Context Use

Cases (Fit for Purpose)

«OV-2»

Operational Node

Connectivity Description

«OV-3»

Operational Exchange

Summary

«OV-4»

Typical Organizations

«OV-4»

Actual Organizations

«OV-5»

Operational Activities

(Search)

«OV-5»

Operational Activities

(Rescue)

«OV-6b»

Operational State

Transition Description

«OV-6c»

Operational Event Trace

Description

«OV-7»

Logical Data Model

«SOV-1»

Service Taxonomy

«SOV-2»

Service Interface

Specification

«SOV-3»

Capability to Service

Mapping

«OV-6a»

Operational Constraints

«SOV-4a»

Service Behaviors and

Constraints

«SOV-4b»

Service Behaviors and

Constraints

«SOV-5»

Service Functionality

«SV-1»

Resource Interaction

Specification

«SV-4»

Functionality Description

«SV-4»

Activity Diagram

«SV-5»

Function to Operational

Activity/Service Function

Traceability

«SV-6»

System Exchange Matrix

«SV-7»

Resource Performance

Parameters

«SV-9»

Technology and Skills

Forecast

«SV-10a»

System Rules and

Constraints

«SV-10b»

Resource State

Transition Description

«SV-11»

Physical Data Model

«AcV-1»

System of Systems

Acquisition Clusters

«AcV-3»

Project Definitions

«AcV-3»

Actual Projects

«AcV-3»

Additional Milestone

Types

«TV-1»

Standards Profile

«TV-2»

ASTM International

Standards

«TV-2»

System Standards

Figure 1: The overview diagram and corresponding package structure in Enterprise Architect.

Depending on the option you selected in the Model Wizard you will now have an outline of

either the DoDAF or MODAF framework that provides a starter for your modeling.

All Views

Tip: – Start by importing the images using the main menu: Extensions | UPDM 2.0 | Import

Images

– Open the Model Wizard to create your template: Ctrl+Shift+M

– Select UPDM 2.0 in the Technology panel and either DoDAF or MODAF in the

Name panel, then click on the OK button.

Tip: On the Default Toolbar, select UPDM 2.0 from the drop-down selection list. This

will give you access within the Toolbox to the full listing of all UPDM element-

types.





UPDM




The All Views Viewpoint allows you to present an architectural overview of the scope of the

model, the timeframe and any related metadata, including a dictionary of key terms used in

the model.

The models within the All Views section can be defined in a number of ways.

We will examine the options using the UPDM MDG add-in, along with the various other

Enterprise Architect features that can be used in creating, viewing and reporting these views.

For more detailed descriptions see:

DoDAF All Viewpoint

MODAF View Summary

AV-1 Overview and Summary Information

The AV-1 Overview and Summary Information view provides an overview and summary

that identifies the architecture goals, viewpoint, findings and recommendations. An AV-1 view

can be defined either with a simple document stored in the model or using an AV-1 diagram

type. It is intended to provide an executive summary of the overall architectural model.

To define an AV-1 view using a document stored in the model, it is best to use a Document

Artifact element. Figure 2 shows an example that is being edited in Enterprise Architect's

document editor. This document is stored in the model under a Document Artifact. The Model

Wizard creates a stub Document Artifact for you under the AV-1 view.

Figure 2: AV-1 Using a Document Artifact

Figure 3 is an alternate example of an AV-1 view using an AV-1 diagram type:


http://dodcio.defense.gov/dodaf20/dodaf20_all_view.aspx

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/38693/20090216ViewsummaryU.pdf


UPDM




«WholeLifeEnterprise»

Search and Rescue

Enterprise

tags

endDate = 01/01/2010

startDate = 01/01/2014

«EnterprisePhase»

Phase 1

tags

endDate = 01/01/2010

startDate = 12/01/2012

The AV-1 Overview and Summary

Information identifies the

architecture goals, viewpoint,

findings and recommendations.

«EnterprisePhase»

Phase2

tags

endDate =

startDate =

Figure 3: AV-1 Top Level context model of temporal phases for Search and Rescue

For more options on using internal documents see the related Help topics on Document

Artifacts and Linked Documents.

AV-2 - Operational Activity Dictionary

The AV-2 Operational Activity Dictionary view provides an overall glossary or

dictionary for the model. This maintains the consistency and clarity of meaning of terms

used to define external items referenced within your model. There are a number of options

in Enterprise Architect for defining a dictionary of key terms including:

Using Enterprise Architect’s Model Glossary. See the Help topic Project Glossary.

Using a Linked Document with terms and definitions combined in text form. See

the related Help topics on Document Artifacts and Linked Documents.

Defining an Ontology or Taxonomy of terms using the Enterprise Architect ODM

OWL/RDF MDG Technology. See the Help topic MDG Technology for ODM

Using an element for each glossary entry, and then displaying these in list–form

using the Package Browser view option. Where extra fields are required for each

term you can create a profile to define Tagged Values for these fields. For more

information see the related Help topics: Package Browser and UML Profiles.

For examples see the following package in the UPDM Example model:

Model.Civilian Maritime SAR.Architectural Description.SAR

Architecture.Resources.Capability Configuration.Capability Configurations


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/document_artifact.html


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/linking_documentation.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/projects_and_teams/modelglossaryoverview.html


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/linking_documentation.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/domain_based_models/mdg_technology_for_odm.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/navigate_search_and_trace/reportview.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/standard_uml_models/umlprofiles.html


UPDM




AV-3 – Measurements Definition

An AV-3 Measurements Definition view is used to enforce consistency in the

measurement definitions used in the model. It can be composed of a Measurements

Definition Class diagram and an Actual Measurements view.

Figure 4 shows an example Measurements Definition view for the SAR reconnaissance

model.

«MeasurementSet»

Standard SAR Measurements

«Measurement»

+ areaCoverage :Coverage

+ findTime :Elapsed Time

+ persistence :Elapsed Time

+ searchCoverage :Coverage

+ weatherConditions :Weather Conditions

«MeasurementSet»

Maritime SAR Measurements

«Measurement»

+ seaConditions :Sea State

«MeasurementSet»

Land SAR Measurements

«Measurement»

+ terrain :Terrain Type

Figure 4: AV-3 Measurements Class

Figure 5 shows an example containing Actual Measurements using the structures from

Figure 4 .



UPDM




«ActualPropertySet»

Initial Values :Maritime SAR

Measurements

seaConditions = Sea State 6

areaCoverage = 500

findTime < 8 hours

persistence > 15 hours

searchCoverage = 400

weatherConditions = Heavy Rain

constraints

{intention = Estimate}


Required Values :Maritime SAR

Measurements


areaCoverage = 600

findTime < 5 hours



weatherConditions = Stormy

constraints

{intention = Required}


Final Values :Maritime SAR

Measurements


areaCoverage = 650

findTime < 4 hours




constraints

{intention = Result}

Figure 5: AV-3 Measurements (Actual)

For more information on setting these actual measurements see the Run Time State Help

topic.

Related to:

StV-1 Capability Vision View

StV-2 Capabilities Taxonomy View

SV-7 Resource Performance Parameters View

Strategic Views

The Strategic views (or DoDAF Capability Views) are used to model the relationships

between the projects and the capabilities. These views are used to define the capabilities, and

through analysis and optimization, map out the evolution of the capabilities.

For more detailed descriptions see:

DoDAF Capability Viewpoint

MODAF View Summary


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/runtimestate.html


http://dodcio.defense.gov/dodaf20/dodaf20_capability.aspx



UPDM




StV-1 Capability Vision (DoDAF CV-1)

The StV-1 Capability Vision view is used to outline the vision for a capability area for

a defined period. It is used to provide, on a high-level scope, a strategic context for

the capabilities being utilized, and any intended changes to these capabilities. StV-1 is

based on the DoDAF CV-1 view.

Figure 6 gives an example StV-1 view modeling the capabilities required for the SAR

model.

«WholeLifeEnterprise»

Search and Rescue

tags

endDate = 2014-06-01 00:00:00

startDate = 2010-01-01 00:00:00

«EnterprisePhase»

Phase 2

tags

endDate = 2014-06-01 00:00:00

startDate = 2012-12-01 00:00:00

«EnterprisePhase»

Phase 1

tags

endDate = 2010-12-01 00:00:00

startDate = 2010-01-01 00:00:00


Initial Values :Maritime SAR

Measurements


areaCoverage = 500

findTime < 8

persistence > 15


weatherConditions = Heavy Rain



Measurements


areaCoverage = 600

findTime < 5 hours

persistence > 20



«EnterpriseGoal»

Fulfill International

Obligations

«EnterpriseGoal»

Maintain SAR

Responsibility

«EnterpriseVision»

SAR Vision

«Capability»

Assistance

«Capability»

Recov ery

«Capability»

Search

1

+TPart1 1

1

+TPart2 1

Figure 6: Stv-1 for the Search and Rescue model example

Related to:

AV-3 Actual Measurements Definition

StV-2 Capabilities Taxonomy (DoDAF CV-2)

The StV-2 Capabilities Taxonomy view describes the communication between systems,

showing the communication networks, pathways and resource flows, and providing details

regarding their configuration. Figure 7 is an example StV-2 view depicting the core

taxonomy for the SAR reconnaissance model.



UPDM




«Capability»

Assistance

«Capability»

Recov ery

«Capability»

Search

«Capability»

SAR

«Capability»

Maritime SAR

«Capability»

Land SAR

«Capability»

Distress Signal

Monitoring

«Capability»

Inform

«Capability»

Military C2

«Capability»

SAR C2



Measurements


areaCoverage = 600

findTime < 5 hours




Figure 7: StV-2/CV-2 Capabilities Taxonomy from the SAR example model

Related to:

AV-3 Measurements (actual)

StV-3 Capability Phasing (DoDAF CV-3)

StV-3 Capability Phasing view lays out the planned achievement of capability in the time-

line of the overall project. The example in Figure 8 shows the SAR Capability Phasing for

the Maritime and the Automated Rescue units using an Enterprise Architect ‘Swimlane

Matrix’.



UPDM




Figure 8: StV-3 example Capability Phasing

For help on constructing a Matrix see the Swimlane Matrix Help topic.

A StV-3 Capability Phasing view can also be created in an external application and then the

external file can be hyperlinked into the StV-3 diagram in the model. Double-clicking the

hyperlink will launch the file in its appropriate application. For more information see the

Hyperlinks Help topic.

Related to:

AcV-2 Program Timeline

SV-8 System Capability Configuration Management

StV-4 Capability Dependencies (DoDAF CV-4)

The StV-4 Capability Dependencies view describes the dependencies between planned

capabilities. It also defines logical groupings of capabilities.

The StV-4 view can be depicted as a Composite Structure diagram (Figure 9) or as a Class

diagram (Figure 10).


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/swimlanes_matrix.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/domain_based_models/hyperlinks.html


UPDM




«Capability»

SAR

DSM Inf

SC2 MIC2

Srch Asst Rec

Figure 9: StV-4 Capability Dependencies (Composite Structure Diagram)

«Capability»

SAR

«Capability»

Distress Signal

Monitoring

«Capability»

Recov ery

«Capability»

Search

«Capability»

Military C2

«Capability»

SAR C2

«Capability»

Inform

«Capability»

Assistance

+Rec 1

1

+DSM 1

1

+SC2 1

1

+Srch 1

1

+Asst 1

+Inf 1+MIC2 1

Figure 10: StV-4 Capability Dependencies (Class Diagram)

Related to:

StV-2 Capabilities Taxonomy



UPDM




StV-5 Capability to Organization Deployment (DoDAF CV-5)

The StV-5 Capability to Organization Deployment view lays out how capability

requirements are to be fulfilled using a mapping between the capability and the

organization deployment. It is intended to model the planned capability deployment

and interconnection for a particular capability Phase.

Figure 11 shows an example StV-5 diagram for the SAR reconnaissance model.

«ActualOrganization»

Maritime & Coastguard

Agency

(from Architectural

Description)

«Capability»

Capability::Assistance

«Capability»

Capability::Inform

«Capability»

Capability::Recov ery

«Capability»

Capability::Search

«CapabilityConfiguration»

Capability Configuration::Maritime

Rescue Unit v 2


Volunteer Rescue

Organization

(from Architectural

Description)


Coastguard

(from Architectural

Description)

Applied but not

specifically described

Capabilities

Performer

Organizations

Legend

«Implements»

«Implements»

«IsCapableOfPerforming»




«Implements»

Figure 11: StV-5 -Capability to Organization Deployment from the SAR example

Related to:


StV-3 Capability Phasing

OV-4 Actual Organizations

StV-6 Operational Activity to Capability Mapping (DoDAF CV-6)

The StV-6 Operational Activity to Capability Mapping view identifies how

operational activities support capabilities. It describes the mapping between the

capabilities required by an enterprise and the operational activities that those

capabilities support.

Figure 12 is an example ST-5 diagram from the SAR example, showing the

operational activities necessary to achieve Search and Rescue support. These include

monitoring health and providing medical assistance.



UPDM




«Capability»

Assistance

«Capability»

Inform«Capability»

Recov ery

«Capability»

Search

«StandardOperationalActiv i...

FindVictim


MonitorHealth


Transit to SAR Operation


Track Victim


Recov er Victim


Assist Victim


Prov ide Medical Assistance

«MapsToCapability»









Figure 12: StV-6 Capabilities Mapping from the SAR example model

Related to:




UPDM




Operational Views

Operational Views identify the key objectives that need to be accomplished in an operation,

along with who is to accomplish them. These views lay out what is required to conduct the

operations including:

Tasks and activities

Operational elements

Exchanges of information

Systems

For more detailed descriptions of Operational Views as defined for DoDAF and MODAF

see:

DoDAF Operational Viewpoint

MODAF View Summary

OV-1 Operational Context Graphic

The OV-1 Operational Context Graphic view gives a textual and graphic representation of

the operation being modeled. It describes a mission, class of mission or scenario, showing the

main operational concepts and interesting or unique aspects of the operations.

In the SAR example this is a view of the key components and communications involved in a

search and rescue operation, as shown in Figure 13:


http://dodcio.defense.gov/dodaf20/dodaf20_operational.aspx

http://dodcio.defense.gov/dodaf20/dodaf20_operational.aspx



UPDM




Rescue Helo

Yacht

Monitor Unit

C2 Center

Rescue Boat Nav al Ship

trackInfo

control

control

control

distressSignal

assistance

trackInfo

trackInfo

Figure 13: An OV-1 Operational Context view from the SAR example



UPDM




uc Phase 1

«Mission»

Monitor Health

«Mission»

Find Victim(s)

«Mission»

Search and Rescue

Person in DistressRescue Vessel

«Mission»

Recov er Victim(s)

«Mission»

Air Recov ery

«Mission»

Surface Recov ery

«Mission»

No Victims

«Mission»

Land Recov ery

«Mission»

Water Recov ery

«Mission»

Sub-Surface

Recov ery

«Mission»

Air-to-Ground

Recov ery

«Mission»

Air-to-Water Recov ery

«include» «include»

«include»

«extend»

Figure 14: An alternate OV-1 Operational Context view from the SAR example

Figure 14 is an alternate OV-1 view depicting the Operational Context Use Case view (Fit for

Purpose).

It is popular to model this Operational Context Use Case view using graphical symbols on

the elements. For example a graphic of a ship for the Water Recovery element and set on a

background image of a landscape. To set alternate images for elements see the Select

Alternate Image option in the Appearance Menu Selection Help topic. To set a background

image see the Create Custom background Diagram Help topic.

OV-2 Operational Node Relationship Description (DoDAF Operational

Resource FlowDescription)

The OV-2 Operational Node Relationship Description view lays out the context of the

operational capability for any anticipated users. It depicts the key players (operational nodes)

involved in an operation and the exchange of information (interactions) between these nodes.

An example of this from the SAR model is shown in Figure 15.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/modeling_basics/appearancemenusection.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/createcustomdiagrambackgrou.html


UPDM




«Node»

Search

monitorHealth(Reported_Condition :IN)

findVictim(Reported_Location :IN)

receiveDistressSignal()

Search()

sendWarningOrder()

«Node»

Place Of Safety

processWarningOrder()

transitToSAROperation()

«Node»

Person in Distress

sendDistressSignal()

«Node»

Rescue

provideMedicalAssistance(Updated_Condition :OUT)

receiveDistressSignal()

recoverVictim(Updated_Location :OUT)

«Node»

Monitoring«Node»

SAR Asset Control

«Node»

Tactical C21

control

1 1

warningOrder

1

1

tasking

1

1

request

1 1

trackInfo

1

1

distressSignal

*

1

distressSignal

*

1

tasking 1

1

control 1

1

BlockProperty1 1

1

distressSignal

*

Figure 15: OV-2 Operational Node Connectivity Description

The OV-2 diagram uses Information Flow connectors for conveying information on a flow.

For an overview on how to use these connectors see the Help topics:

Using Information Flows

Convey Information on a Flow

Realize an Information Flow

Related to:

OV-5 Operational Activity Model

OV-3 Operational Exchange Summary (DoDAF Operational Resource Flow

Matrix)

The OV-3 Operational Information Exchange Summary view is used for mapping the

operational information exchanges between the capabilities and the services. It addresses

operational information exchanges between these nodes.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/using_information_flows.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/informationitemsconvey.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/informationitemsrealized.html


UPDM




The OV-3 view can be provided as a simple text document stored within the model using a

Document Artifact element, or it can be generated from the model using the OV-3 UPDM

Search for listing elements in the model that are connected by Needline connectors.

Figure 16 is an OV-3 listing for the example SAR reconnaissance model.

Figure 16: OV-3 view from the SAR example model

OV-4 Organizational Relationships Chart

The OV-4 Organizational Relationships view is used to document the organizational

structure by modeling the relationships between organizational-entities and depicting their

role within the model structure.

An OV-4 view can consist of a Typical Organizational Overview represented by a Class

Diagram, as well as an Actual Organizational Overview represented by an Object Diagram.

A typical Organizational Overview represents the broad relationships between the

organizations involved in the system being modeled, from a corporation down to key players

in the model.

Figure 17 is a typical OV-4 diagram from the SAR reconnaissance model example.

Tips:

1) To access the Search view select Edit | Model Search from the main menu

(Ctrl+F). Select OV-3 from the UPDM 2.0 group.

2) On running the Search you can find the conveyed elements in the Project

Browser by right-clicking on an entry in the table and selecting Find in Project

Browser.

3) On creating an OV-3 diagram you can set up a Hyperlink to the Search. For more

detail see the: Hyperlinks Help topic.



http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/classdiagram.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/classdiagram.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/standard_uml_models/objectdiagram.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/domain_based_models/hyperlinks.html


UPDM




«Organization»

SAR Operator

«Organization»

SAR Organization

«Organization»

SAR Gov ernment

Department

«Organization»

SAR Voluntary

Organization

«Post»

SAR SC Member

«Organization»

Gov ernment Department

«Post»

MRT Communicator

«Post»

MRT Swimmer

«Post»

MRT Helicopter Pilot

«Post»

MRT Searcher

«Post»

MRT Boat Driv er

«Person»

Qualified EMT

«Person»

Qualified Helo Pilot

«Person»

Qualified Lifeboat Driv er

«Person»

Qualified Lifeguard

«Person»

Marine Radio Operator

1

+member 0..*

1

+subOrg 0..*

Figure 17: Typical Organizational Overview OV-4

An Actual Organizational overview depicts the structure of the organization and the posts

within it, along with the People filling these roles (e.g. ‘Ron Radio’ as depicted in Figure

18).



UPDM




«ActualOrganizatio...

Maritime & Coastguard

Agency


Department Of Transport :



Department of Defense


Volunteer Rescue

Organization


Coastguard

«ActualPost»

Lifeboat Driv er

«ActualPost»

Radio Operator

«ActualPost»

Rescue Swimmer

«ActualPost»

Rescue Helo Pilot

«ActualPerson»

Danny Driv er

«ActualPerson»

Ron Radio

«ActualPerson»

Sam Swimmer

«ActualPerson»

Peter Pilot

?FillsPost? Tags:

endDate = 2014-01-01

startDate = 2010-01-01

?FillsPost? Tags:

endDate = 2014-01-01


?FillsPost? Tags:

endDate = 2014-01-01


?FillsPost? Tags:

endDate = 2014-01-01


subOrg

membermember member member

«ActualOrganizationRelationship»


«FillsPost» «FillsPost»


«FillsPost» «FillsPost»

Figure 18: An OV-4Actual Organizational Overview from the SAR example model

Relates to:

StV-5 Capability to Organization Deployment

OV-5 Operational Activity Model (DoDAF Operational Activity

Decomposition Tree – OV-5a)

An OV-5 Operational Activity Model view describes the Operational Activities that are

conducted in the course of achieving a mission or a business goal. It provides details on the

allocation of service functions to resources, and the flow of resources between service

functions. An example of this is shown in Figure 19.

«OperationalActiv ity»

Search

«Node»

Search«StandardOperationalActiv ity»

Find Victim


Receiv e Distress Signal


Send Warning Order


Monitor HealthPerforms

Performs

Performs

Performs Performs

Figure 19: Operational Activities (Search) OV-5



UPDM




An alternate representation uses an Activity diagram. This uses Swimlanes to represent the

context of the Activity, which describes the Operational Activity actions. These actions are

derived from the nodes defined in the OV-2 view. Figure 20 represents the execution of the

Search activity.

Reported Location Reported Condition

Updated ConditionUpdated Location


Search

Reported Location Reported Condition

Updated ConditionUpdated Location

:Se

arc

h a

nd

Re

sc

ue

:Pe

rso

n i

n D

istr

es

s:S

ea

rch

:Re

sc

ue

:Pla

ce

Of

Sa

fety

«OperationalA...

:Monitor Health

Condition

«OperationalA...

:Process Warning

Order

Warning Order

ActivityInitial

FlowFinal ActivityFinal

«OperationalA...

:Send Distress

Signal

Disress Signal

«OperationalA...

:Receiv e Distress

Signal

Distress Signal

«OperationalA...

:Send Warning

Order

Warning Order

«StandardOpe...

:Find Victim

Location

«StandardOpe...

:Prov ide Medical

Assistance

Condition

«Serv iceFunction»

:Recov er Victim

Location

«OperationalA...

:Receiv e Distress

Signal


:Transit to SAR Operation

Organiszation Types

Information

Activities

Legend

Figure 20: Alternate OV-5 Shown as an Activity Diagram

Related to:

OV-2 Operational Node Connectivity Description View

OV-6a Operational Rules Model

The OV-6a Operational Rules Model view specifies operational or business rules that are

constraints on the way that business is done in the enterprise. Figure 21 is a view of opera-

tional rules laid out for a search and rescue operation from the SAR example.



UPDM




«Node»

Place Of Safety


Monitor For Distress

Signal


Search


Send Distress Signal


Transit to SAR Operation

«OperationalConstraint»

{The place of safety shall

be isolated from the

weather to ensure safety of

the person in Distress.}


{Distress signals shall be

monitored 24/7.}


{Search personnel shall

operate on a shift system to

ensure that they can

perform to maximum

efficiency.}


{The maximum range for

distress signals shall be

posted at all ports and

marinas.}


{[none]}

Figure 21: OV-6a Operational Rules

OV-6b Operational State Transition Description

The OV-6b Operational State Transition Description view uses a State Chart to lay out

the behavior of an operation. Figure 22 depicts the State changes based on Events, Guards

and Transitions for a Search Operation.



UPDM




Waiting for Distress Signal

+ do / Monitor For Distress Signal

Searching for Victim

+ do / Track Victim

+ do / Find Victim

Monitoring Victim

+ do / Monitor Health

Rescuing Victim

+ do / Recover Victim

+ do / Transit to SAR Operation

[Search Cancelled]

[Victim Secure]

[Receive Distress Signal]

/Send Warning Order

[No Assistance Required]

[Assistance Required]

[Victim Found]

[Victim Stable]

Figure 22: OV-6b Operational State Transition Description

Related to:


OV-5 Operational Activity Model View

OV-6c Operational Event Trace

The OV-6c Operational Event Trace view provides a time-ordered examination of the

resource flows/information exchanges between participating operational nodes as a result of a

particular scenario. Figure 23 is an OV-6c view from the SAR example that uses NodeRoles

defined in the OV-2 View (and used in OV-5 views).



UPDM




«NodeRole»

TC2N

«NodeRole»

SAR AC

«NodeRole»

SN

«NodeRole»

MN

«NodeRole»

RN

«NodeRole»

PiD

«NodeRole»

PoS

DS1 : distressSignal()

TI : trackInfo()

Rqst : request()

Tsk : tasking()

Tsk : tasking()

Ctrl : control()

Tsk : tasking()



Stat : status()

WO : warningOrder()

Figure 23: OV-6c Operational Event Trace Description

Relates to:


OV-5 Operational Activity Model View

OV-7 Logical Data Model (DoDAF DIV-1/DIV-2)

The OV-7 Logical Data Model view defines domain data types and their interrelationships

as are commonly defined in a Logical Data Model. Within them you can define entities with

attributes and the relationships that exist between entities.

This view can be used in conjunction with existing Enterprise Architect data modeling

features, allowing you to define Conceptual Data models, Logical Data models and DBMS-

specific Physical Data models. MDA Transformations can be used to generate Physical

models from the Logical models.

For more detail on the data modeling features of Enterprise Architect see the Data Models

Help topic.

Figure 24 describes the information elements and entities used in the operational

context for the SAR reconnaissance model. Attributes represent characteristics of

what would be later used as table-fields.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/domain_based_models/datamodelling2.html


UPDM




«EntityItem»

Search Object

name :String

registration :String

tonnage :String

color :String

markings :String

superstructure :String

characteristics :String

ownerOrOperator :String

personsOnBoard :Integer

emergencyEquipmentCarried :String

«EntityItem»

Last Known Position

latitude :String

longitude :String

time :String

sourceOfReport :String

«EntityItem»

Search Area

waypoints :String

activationTime :String

duration :String

driftDirection :String

driftSpeed :Integer

commenceSearchPoint :String

«EntityItem»

Stranded Person Info

name :String

condition :String

«EntityItem»

SAR Operation

caseName :String

caseNumber :String

taskingAuthority :String

«EntityItem»

Search Status

status :String

«EntityItem»

Assignment

description :String

«ExchangeElement»

control

«ExchangeElement»

distressSignal

«ExchangeElement»

request

«ExchangeElement»

status

«ExchangeElement»

tasking

«ExchangeElement»

trackInfo

«ExchangeElement»

warningOrder

RepresentsEntity

1

status 0..*

0..*

location

0..*

1

assetAssignments 0..*

0..*

operationalArea 0..*

0..*

location 0..*

1

objects 0..*

1

person 0..*

RepresentsEntity

RepresentsEntity

RepresentsEntity

RepresentsEntity

RepresentsEntity

RepresentsEntity

RepresentsEntity

1

location

1

Figure 24: OV-7 Logical Data Model

Service Oriented Views

The Service Oriented Views are used to model the services needed to carry out the operation

being modeled. These views provide a description of any independent services and their

capabilities, along with how the services are to be orchestrated to perform the modeled

operation.

For descriptions of the DoDAF and MODAF Service Oriented view see:

DoDAF Services Viewpoint

MODAF View Summary

SOV-1 Service Taxonomy (DoDAF SvcV-1: Services Interface Description)

The SOV-1 Service Taxonomy view specifies a hierarchy of Services. The elements in the

hierarchy are service specifications (i.e. service interfaces), and the relationships between the

elements are generalizations (i.e. one service is a general type of another). Along with the

SOV-2 view, SOV-1 specifies a standard library of service specifications for an enterprise,

which service implementers are expected to conform to. Figure 25 is an example service

taxonomy view for the SAR reconnaissance model.


http://dodcio.defense.gov/dodaf20/dodaf20_services.aspx



UPDM




«ServiceInterface»

Search and Rescue

Serv ice


Land Search and

Rescue Serv ice


Maritime Search and

Rescue Serv ice


Communications

Serv ices


Air Transportation

Serv ice


Search Serv ice


Medical Serv ices


Rescue Serv ice


Coordination Serv ices


Monitor Serv ice

Figure 25: SOV-1 – Service Taxonomy Views

SOV-2 Service Interface Specification (DoDAF SvcV-2)

The SOV-2 Service Interface Specification view is used to define the interfaces presented

by a service. A service presents one or more interfaces to consumers (a consumer being any

agent capable of using the service - a person, an organization, a system or another service). In

this case, the architect specifies provided interfaces. A service can also be capable of using

interfaces exposed by other services, and the architect might specify these as required

interfaces. Figure 26 is an example of a Service Interface Specification view used in

the SAR reconnaissance model.



UPDM





Air Transportation Serv ice

Air Transportation

Interface


Communications Serv ices

Wireless Comms

Interface



Coordination

Interface

Maritime Rescue

Interface

Medical Services

Interface

Air Transportation

Interface


Maritime Search and

Rescue Serv ice

Maritime Rescue

Interface

Medical Services

Interface

Air Transportation

Interface


Medical Serv ices

Medical Services

Interface


Monitor Serv ice

Monitor Interface


Rescue Serv ice

Maritime Rescue

Interface


Search Serv ice

Search Interface


Search and Rescue Serv ice

Search Interface

Rescue Interface

«interface»

Search Interface

Initiate Search(missingPersonInfo :in, searchCaseID :out*)

Request Search Update(searchCaseID :in, status :out*)

Cancel Search(searchCaseID :in, reason :in)

«interface»

Medical Serv ices Interface

Provide First Aid(trappedPersonInfo :in)

«interface»

Rescue Interface

Initiate Rescue(strandedPersonInfo :in, rescueCaseID :out*)

«interface»

Monitor Interface

Signal Person in Distress(SignalID :in)

«interface»

Maritime Rescue Interface

Rescue Person(strandedPersonInfo :in)

«interface»

Air Transportation Interface

Transport Casualty(patientInfo :in, transportedTo :out*)

«interface»

Coordination Interface

Send Orders(order :in)

«interface»

Wireless Comms Interface

Communicate(message :in)

Figure 26: SOV-2 - Services (Interfaces)

The Service Interfaces depicted in Figure 26 are defined in the SOV-1 View.

Related to:

SOV-1 Service Interface Specification View

SOV-3 Capability to Service Mapping View

SOV-3 Capability to Service Mapping (DoDAF CV-7)

The SOV-3 Capability to Service Mapping view depicts which services contribute to the

achievement of a capability. It is in the form of a table generated from the database. If

network enabled capability is to be delivered by the orchestration of loosely coupled services

(i.e. a service-oriented architecture), it is important to know which services have the potential

to support particular capabilities. This helps to prevent redundant services or capabilities,

(except where specifically required) and what is known as stovepipe development. An SOV-

3 presents a simple mapping of services to capabilities, showing which services contribute to

which capabilities. Figure 27 is an example used in the SAR reconnaissance model.



UPDM




«Capability»

Land SAR

«Capability»

Maritime SAR

«Capability»

Assistance

«Capability»

Distress Signal Monitoring

«Capability»

Recov ery

«Capability»

Inform

«Capability»

Search

«Capability»

SAR C2

«Capability»

Military C2


Land Search and Rescue

Serv ice


Maritime Search and

Rescue Serv ice


Medical Serv ices


Monitor Serv ice


Air Transportation Serv ice


Rescue Serv ice


Communications Serv ices


Search Serv ice



Expose

Expose Expose Expose

Expose Expose

Expose

ExposeExpose

Expose

Figure 27: SOV-3 Capability Service Mapping

The Service Interfaces shown in Figure 27are defined in the SOV-1 View.

Relates to:

SOV-1 View

SOV-4a Service Behaviors and Constraints (DoDAF SvcV-10a)

The SOV-4a Service Behaviors and Constraints view is used to specify constraints that

apply to any service that is to be implemented. It can be used to discern which potential

service-providers meet the constraints required to carry out the service.

The constraints are specified in text and can be functional or structural (i.e. non-functional).

Figure 28 shows examples from the SAR reconnaissance model showing the model

representation of this view.



UPDM





Land Search and Rescue

Serv ice


Maritime Search and

Rescue Serv ice


Search and Rescue Serv ice

«ServicePolicy»

{Any member involved

in the operation of

road vehicles must

have a clean driving

record.}

«ServicePolicy»

{All members of the

rescue team must be

able to swim.}

«ServicePolicy»

{All members of the

rescue team must be

able to perform basic

first aid.}

«ServicePolicy»

{No member of the

search and rescue

team should put

themselves in

unnecessary danger.}

Figure 28: SOV-4a - Service Policies

The Service Behaviors and Constraints view can also be reported using a pre-defined Model

Search (accessible using Ctrl+F, then selecting the SOV-4a search): see Figure 29.

Figure 29: SOV-4a view using SOV-4a Model Search

SOV-4b Service State model (DoDAF SvcV-10b)

The SOV-4b Service State Model view is used to specify the possible states a service must

provide, and the possible transitions between those states, along with any behavioral

constraints to be adhered to.

Figure 30 is a State diagram used in the SAR reconnaissance model covering the state based

behavior required for Maritime Search and Rescue.



UPDM




Maritime SAR

do / Rescue Person

[Victim Assistance]

[Victim Transportation]

[Locate Victims]

Retriev ing

do / RecoverVictim

Aiding

do / ApplyFirstAid

Calming

do / ReassureVictim

Transferring

do / TransportVictim

Searching

TaskingOrder when( NoVictims )

TaskingOrder VictimDiscovered

VictimRecovered [Fatality]

VictimRecovered

[Survivor]

when( Victim Stabilized )

when( Conscious )

Figure 30: An SOV-4b diagram of the Maritime Search and Rescue service

SOV-4c Service Interaction Specification

The SOV-4c Service Interaction Specification view is used to specify how a service

interacts with external agents, and the sequence and dependencies of those interactions.

An SOV-4c product does not specify the sequencing of an orchestrated set of services (see

OV-6c). Its purpose is to specify the general sequence of interactions that are possible for a

given service.

Related to:

OV-6c Operational Event Trace

SOV-5 Service Functionality (DoDAF SvcV-4)

The SOV-5 Service Functionality view defines the behavior of a service in terms of the

functions it is expected to perform.



UPDM




This view enables the description of a service by means of a State diagram, an Activity

model or an Event Trace description. Event Trace descriptions are useful in fully defining the

sequencing of messages and operations that form part of the service interface. State

descriptions are useful in fully defining the handling that takes place in a service due to

possible different internal states. For all of these descriptions, standard UML entities provide

appropriate representation.

Figure 31 shows an SOV-5 view of the SAR example which is a decomposition of the

Maritime Search and Rescue service functions.


Maritime Search and

Rescue Serv ice


Rescue Person


Recov er Victim


Reassure Victim


Apply First Aid


Transport Victim

Provides Function

Figure 31: SOV-5 - Services (Functionality)



UPDM




System Views

The System Views model the resources required to realize the capabilities and implement the

desired services. They model what functionality is required of the resource and the

interactions between resources, as well as provide details on the interfaces between systems.

System Views can cover ‘as is’ and ‘to be’ scenarios, used for trade-off analysis. You can

perform this type of analysis using the Enterprise Architect Gap Analysis features. Where

there is a need for defining requirements and tracing them through the model you can also

use Requirements modeling.

For more detailed DoDAF and MODAF descriptions of System Views see:

DoDAF Systems Viewpoint

MODAF View Summary

SV-1 Resource Interaction Specification

The SV-1 Resource Interaction Specification provides a means of identifying system

resources and modeling their interconnections and interactions. This incorporates any human

elements as types of performer.

The SV-1 view can be interconnected with the Fit for Purpose model (OV-1), which models

these entities showing organizational interactions.

Figure 32 is an example of an SV-1 view from the SAR example, depicting roles that make

up the Maritime Search and Rescue team and their interactions with entities that allow the

personnel to carry out the role, such as a driver for the MR Boat.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/navigate_search_and_trace/gap_analysis_matrix.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/requirement_models/modeling_requirements.html

http://dodcio.defense.gov/sites/dodaf20/systems.html

http://dodcio.defense.gov/sites/dodaf20/systems.html



UPDM




«ResourceRole»

MRT

«ResourceRole»

Radio

«ResourceRole»

Life Preserv er

«ResourceRole»

Beacon

«ResourceRole»

MR Boat

«ResourceRole»

MR Aircraft

«ResourceRole»

Driv er

«ResourceRole»

Searcher

«ResourceRole»

Radio Operator

«ResourceRole»

Rescue Swimmer

«ResourceRole»

Pilot

«ExchangeElement»

beaconInstruction

«ResourceInterface»

«ExchangeElement»

radioInstruction


«ExchangeElement»

l i fePreserverInstruction


«ExchangeElement»

boatInstruction


«ExchangeElement»

aircraftInstruction


Figure 32: SV-1 Resource Interaction Specification - Maritime Rescue Unit v1

Related to:

OV-1 View

TV-1 Standards Profile

TV-2 Standards Forecast

SV-2 Capability Configuration

The SV-2 Capability Configuration view describes the communication between systems,

showing the communications networks, pathways and resource flows, and provides details

regarding their configuration.

Figure 33 shows the connections between the key entities in the maritime search and rescue

model.



UPDM




«ConfigurationRole»

Yacht :Boat

dsOut«ResourceArtifactRole»

Distress Beacon

dsOut

receiver

transmitter

«ResourceArtifactRole»

Part1receiver

transmitter


Rescue Unit :Maritime Rescue Unit v 1


MR Boat«ConfigurationRole»

MR Aircraft

dsIn trkIn«ResourceArtifactRole»

Monitor

dsIn trkIn

transmitter

receiver


Radiotransmitter

receiver

trkOut

tdmReceiver

tdmTransmitter


Digital Serv ice

trkOut

tdmReceiver

tdmTransmitter

tdmTransmitter

tdmReceiver

trkOut


Digital Serv icetdmTransmitter

tdmReceiver

trkOut

trkIn

dsIn


Monitor

trkIn

dsIn

track

TDM

TDM

track

distressSignal

radioInstruction

radioInstruction

distressSignal

Figure 33: SV-2 Capability Configuration view showing communications for the Maritime

Rescue Unit

SV-4 Functionality Description (DoDAF Systems Functionality Description)

The SV-4 Functionality Description view addresses human and system functionality. It

defines the functions carried out by the resources involved in an operation (including any

organizational resources) and provides a mapping of the resource use to function.

Figure 34 is from the SAR example, depicting the resources to be used and the actions to be

performed.

«Function»

Rescue Victim

«Function»

Determine Destination

«Function»

Mov e

«Function»

Transport


Apply First Aid


Reassure Victim


Recov er Victim


Maritime Rescue Unit v 1

«Post»

MRT Searcher

Performs

Performs

PerformsPerforms

Performs

Performs

Figure 34: SV-4 Functionality Descriptions



UPDM




An alternative diagram is an Activity diagram showing the overall workflow of resources

using functions. Figure 35 shows a Workflow of Resources from the SAR example,

implementing the Rescue Victim Activity. This Activity diagram depicts how the Resources

make use of the available Functions.

reportedLocation

name reportedCondition updatedCondition updatedLocation

«Function»

Rescue Victim

reportedLocation

name reportedCondition updatedCondition updatedLocation

:Ma

riti

me

Re

sc

ue

Un

it v

1:M

RT

Se

arc

he

r

«Function»

:Mov e

location


:Reassure Victim

victimName


:Apply First Aid

condition updatedCondition


:Recov er Victim

«Function»

:Determine

Destination

destination

location

«Function»

:Transport

destination

Figure 35: Activity diagram as an alternate SV-4 view, from the SAR example

SV-5 Function to Operational Activity/Service Function Traceability

The SV-5 Function to Operational Activity view provides a traceability view from system

functions to service functions and operational activities. It is intended to provide

requirements traceability between functions and the operational activity. These views can be

used in validating what has been implemented and what is yet to be implemented.

The SV-5 view provides a graphical method of defining the relationships to the functions laid

out in SV-4.

Figure 36 shows an SV-5 view of the operational activities and the services that implement

them, from the SAR reconnaissance model. This is a means of tracing the capability

requirements to verify what functions implement what operational activities.



UPDM




«Function»

Mov e

(from Realizing Function)

«ServiceFunction»

Reassure Victim


«OperationalActivity»

Rescue«OperationalActivity»

Search


«Function»

Transport

«Function»

Rescue Victim

«ServiceFunction»

Apply First Aid

A


«ServiceFunction»

Recov er Victim

«OperationalActi...

Process Warning

Order

«Function»

Determine

Destination


«Implements»

«Implements»

«Implements» «Implements»«Implements»

«Implements»

«Implements»

«Implements»

«Implements»

«Implements»

Figure 36: SV-5 view of SAR Function Relationships to Operations

These relationships can also be displayed using a pre-defined Relationship Matrix profile, as

shown in Figure 37:

Apply First Aid

Determine Destination

Move

Reassure Victim

Recover Victim

Recover Victim

Search

Transport Victim

Monitor For Distress Signal

Process Warning Order

Receive Distress Signal

Rescue

Search

Search

Send Distress Signal

Send Warning Order

Transit To SAR Operation

Figure 37: SV-5 Function to Operational Activity view using a Relationship Matrix



UPDM




To access the Relationship Matrix select View | Relationship Matrix from the main menu,

and in the Profile drop-down, select SV-5.

Related to:

SV-4 View


SV-6 System Exchange Matrix (DoDAF Systems Resource Flow Matrix)

The SV-6 System Exchange Matrix specifies the characteristics of the system data/resource

flows exchanged between systems. The focus is on data crossing the system boundary. Figure

38 shows an SV-6 system change matrix view from the SAR reconnaissance model.

SAR SC Member

«Post»

MRT Helicopter Pilot

SAR SC Member

«Post»

MRT SearcherSAR SC Member

«Post»

MRT Boat Driv er

«ResourceArtifact»

Resource Artifacts::

Lighting Dev ice

SAR SC Member

«Post»

MRT Swimmer

SAR SC Member

«Post»

MRT Communicator



Communication

Dev ice



Link 16

«Performer»

High Lev el

Operational Concept::

Aircraft

«Performer»

High Lev el

Operational Concept::

Boat



ESM System



Life Sav ing Dev ice

«ExchangeElement» track

TRK

«ResourceConnector»

«ExchangeElement» distressSignal

DS


«ExchangeElement» TDM


TD

«ExchangeElement» aircraftInstruction

AI


«ExchangeElement» lifePreserverInstruction

LPI


«ExchangeElement» beaconInstruction

BCI


«ExchangeElement» boatInstruction

BI


«ExchangeElement» radioInstruction

RI«ResourceInterface»

«ExchangeElement» radioInstruction


RI

Figure 38: SV-6 System Exchange Matrix diagram for the SAR example

Tip: The SV-5 Relationship Matrix profile is one of a number of predefined

Relationship Matrix profiles used in UPDM. For more information on setting up

your own Relationship Matrix profiles see the Relationship Matrix Help topic.

.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/navigate_search_and_trace/elementrelationshipmatrix.html


UPDM




This can also be reported using a Search Query. Figure 39 is an SV-6 listing returned for the

SAR example model.

Figure 39: SV-6 System Exchange using a Search Query

To access this search in the model select from the main menu: Edit | Find Project or

(Ctrl+F), then in the Search field select SV-6.

For more tips on using Searches, see Search tips.

Related to:


SV-7 Resource Performance Parameters (DoDAF Systems Measures Matrix)

The SV-7 Resource Performance Parameters view is used for modeling the performance

characteristics of resources. It provides more details on the items defined in SV-1 and can be

defined using:

A table created in a spreadsheet or

SV-7 diagram elements

If using a spreadsheet from an external application, you can include a hyperlink in the

diagram to this spreadsheet. When you double-click on the hyperlink it will launch the file in

its appropriate application.

Figure 40 is an SV-7 diagram for System Measurements from the SAR example model.



UPDM





Maritime Rescue Architecture v 1






Maritime Rescue Architecture v 2

«ActualPropertyS...

Initial Values

«ActualPropertyS...

Required Values

Figure 40: SV-7 - Resource Performance Parameters for the SAR model

Figure 41 shows an example RTF report detailing the Capability Configurations for the SAR model

derived from the STV-1 view.

Capability Name Measurement Value Unit

Phase 1

Initial Values weatherConditions Heavy Rain Weather Severity Index

searchCoverage 400 Square Kilometers

persistence 15 Hours

findTime 8 Hours

areaCoverage 500 Square Kilometers

seaConditions Sea State 6 Meter

Maritime SAR

Phase 2

Required

Values

weatherConditions Stormy Weather Severity Index



findTime 5 hours Hours



Maritime

Rescue Unit v2

Final Values weatherConditions Stormy Weather Severity Index



UPDM






findTime 4 Hours



Figure 41: SV-7 Report in Tabular Format

Related to:

SV-1 Resource Interaction View

SV-8 System Capability Configuration Management (DoDAF Systems

Evolution Matrix)

The SV-8 System Capability Configuration Management view provides a whole lifecycle

overview of how a resource/capability configuration structure changes over time. It shows

the structure of several resource/capability configurations mapped against a timeline. The

SV-8 view is modeled using Swimlanes; for more details on options for setting these up see

the Swimlanes Help topic.

Figure 42 is an SV-8 diagram for System Capability from the SAR example model.

Capability 2010 Qtr-1 2010 Qtr-2 2010 Qtr-3 2010 Qtr-4 2011 Qtr-1

«OutOfServiceMilestone»

OutOfServ iceMilestone1

tags

date = 2010-12-31

The SV-8 provides a whole lifecycle

overview of how a resource/capability

configuration structure changes over time.

It shows the structure of several

resources/capability configurations

mapped against a timeline.



Rescue Unit v 1

tags

doctrine =



Rescue Architecture v 2

tags

doctrine =


Capability Configuration::Automated

Rescue Unit v 1

tags

doctrine =


Capability Configuration::Control Center

tags

doctrine =



Rescue Architecture v 1

tags

doctrine =



Rescue Unit v 2

tags

doctrine =


Capability Configuration::Monitor

tags

doctrine =


MRU v 1 OOS

tags

date = 2010-11-01

description =

(from Architectural Description)

«DeployedMilestone»

MRU v 1 UK DEP

tags

date = 2010-04-01

description =



MRU v 1 EU DEP

tags

date = 2010-07-01

description =


«IncrementMilestone»

MRU v 1 INC

tags

date = 2010-01-01

description =


«NoLongerUsedMilestone»

MRU v 2 NLU

tags

date = 2011-01-01

description =



MRU v 2 OOS

Equipment = Complete

Training = Complete

Concepts & Doctrine = Not Applicable

Personnel = Complete

Information = Complete

Organization = Complete

Infrastructure = Not Applicable

Logistics = Complete

Interoperability = Not Applicable

tags

date = 2011-05-01

description =


«DeployedMiles...

MRU v 2 DEP

tags

date = 2010-10-01

description =

(from Architectural

Description)


MRU v 2 INC

tags

date = 2010-08-01

description =



ARU OOS :Dev elopment Milestone


Training = Complete








tags

date = 2011-01-01

description =



ARU INC :Dev elopment

Milestone

tags

date = 2010-10-01

description =



ARU Beta Unit INC :

Dev elopment Milestone

tags

date = 2010-07-01

description =

(from Architectural

Description)

Figure 42: An SV-8 System Capability View for SAR

Related to:


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/swimlanes.html


UPDM





ACV-2 Project Timeline


SV-9 Technology and Skills Forecast (DoDAF Systems Technology and

Skills Forecast)

The SV-9 Technology and Skills Forecast view defines what technologies and skills are

currently supported, along with any expected improvements. Expected support technologies

and skills are those that can be reasonably forecast as emerging, given the current state, and

trends towards their improvement. New technologies and skills will be tied to specific time

periods, which can correlate against periods that are used in SV-8 milestones and that are

linked to enterprise phases.

Figure 43 is an SV-9 diagram for a Technology and Skills Forecast view from the SAR

example model.



Communication Dev ice



Communications


Resource Artifacts::Life

Sav ing Dev ice



Safety Device



Lighting Dev ice



Distress Signal


Resource Artifacts::ESM

System



Distress Monitoring

«ForecastSpanLiteral»

{Short Term}


{Mid Term}


{Long Term}«ForecastSpanLiteral»

{Short Term}

«Forecast»«Forecast» «Forecast» «Forecast»

Figure 43: SV-9 - Boat & Aircraft Systems Forecast

Related to:


SV-10a System Rules and Constraints (DoDAF Systems Rules Model)

The SV-10a System Rules and Constraints view describes functional and non-functional

constraints on the implementation aspects of the architecture (resources, functions, data and

ports).

Figure 44 is an SV-8 diagram for System Rules and Constraints from the SAR example

model.



UPDM




«System»

Boat

«ResourceConstraint»

{Ships subject to Title II Part II and Part III of the Communications Act of 1934, as amended have

to fit GMDSS equipment under FCC Regulation 47 CFR 80 Subpart W. These include all ships,

including fishing vessels, to be navigated in the open sea outside of a harbor or port, except:

Ships other than passenger vessels less than 300 gross tonnage,

Passenger ships having six passengers or less,

U.S. government ships,

Yachts of less than 600 gross tons,

Vessels in tow,

Ships navigating solely on any bays, sounds, rivers or protected waters within the U.S.,

Ships being navigated within the Great Lakes of North America, and

Small passenger ships meeting the requirements of 47 CFR 80 Subpart S.}


{Mariners need to be able to communicate with other ships of any size or nationality.

Mariners need to be able to receive and send urgent maritime safety information.

Mariners need to be able to send or receive distress alerts in an emergency to or from rescue

coordination centers ashore and nearby ships anywhere in the world.}


{In general, any vessel equipped with a VHF marine radiotelephone (whether voluntarily or

required to) must maintain a watch on channel 16 (156.800 MHz) whenever the radiotelephone is

not being used to communicate.}



Communication

Dev ice


{The radiotelephone alarm signal is used only in a distress, including when a person has been lost

overboard and the assistance of other vessels is required.}


{A GMDSS Radio Operator's License is necessary for a person to use required GMDSS equipment.}



Lighting Dev ice



Safety Device

Figure 44: SV-10a System Rules and Constraints example

Details in this view can also be generated as an RTF report:

Resource Resource Constraint

Boat

GMDSS Vessel

Requirements

Ships subject to Title II Part II and Part III of the

Communications Act of 1934, as amended have to fit GMDSS

equipment under FCC Regulation 47 CFR 80 Subpart W.

These include all ships, including fishing vessels, to be

navigated in the open sea outside of a harbor or port, except:

Ships other than passenger vessels less than 300 gross

tonnage,

Passenger ships having six passengers or less,

U.S. government ships,

Yachts of less than 600 gross tons,

Vessels in tow,

Ships navigating solely on any bays, sounds, rivers or

protected waters within the U.S.,

Ships being navigated within the Great Lakes of North

America, and

Small passenger ships meeting the requirements of 47 CFR 80

Subpart S.

Marine Vessel

Communications

Mariners need to be able to communicate with other ships of

any size or nationality.

Mariners need to be able to receive and send urgent maritime

safety information.

Mariners need to be able to send or receive distress alerts in

an emergency to or from rescue coordination centers ashore

and nearby ships anywhere in the world.



UPDM




Radio Watch

Keeping

In general, any vessel equipped with a VHF marine

radiotelephone (whether voluntarily or required to) must

maintain a watch on channel 16 (156.800 MHz) whenever the

radiotelephone is not being used to communicate.

Communication

Device

Distress System

Usage

The radiotelephone alarm signal is used only in a distress,

including when a person has been lost overboard and the

assistance of other vessels is required.

GMDSS

Equipment

Operation

A GMDSS Radio Operator's License is necessary for a person

to use required GMDSS equipment.

Lighting Device Distress System

Usage

The radiotelephone alarm signal is used only in a distress,

including when a person has been lost overboard and the

assistance of other vessels is required.

Safety Device

Related to:

SV-4 Functionality Description

SV-10b Resource State Transition Description

SV-10c Resource Event Trace Description

SV-10b Resource State Transition Description (DoDAF System State

Transition Description)

The SV-10b Resource State Transition Description view is a graphical method of

describing behavior of a resource. It defines the response to various events using state

changes modeled in a State Chart. The SV-10b diagram represents the set of events to which

the resources in the architecture will respond (by taking an action to move to a new state), as

a function of its current state. Each transition specifies an event and an action. SV-10b

typically provides a more detailed analysis of the actions to be carried out by functions

defined in an SV-4 view.

Figure 45 shows the behavior of an aircraft (a SV-4 Transport Function) from the SAR

example model.



UPDM




Maintenance

Powering Up

entry / Perform Pre-Flight Checks

Standby

Powering Down

entry / Perform Post-Flight Checks

Operational

[In Flight]

[Searching]

On Surface

Taking Off

entry / Takeoff Aircraft

State2

entry / Land Aircraft

ResourceState1

Searching for Victims

do / Search

Transferring to Rescue

Team

do / Transport

In Flight

[Navigation]

[Flight Control]

Monitoring Victims

do / Rescue Victim

Mov e to Way Point Fly Route

Manage Flight Controls

when (PreFlightChecks == Passed)

when (MaintenanceCompleted)

when (Last Waypoint)

RouteInfo

[PostFlightChecks == Passed]

[PostFlightChecks == Failed]

VictimDiscovered [Visual Contact]

RouteInfo

TrackInfo

when (NoRemainingVictims || SearchCancelled)

VictimRecovered

when (Airborne)

when (FlightCrewReady)

Distress Beacon

/Visual Search

TrackInfo

/Report Status

TaskingOrder [Crew Available]

Figure 45: SV-10b Resource State Transition Description view

Related to:


SV-10c Resource Event Trace Description (DoDAF System Event Trace

Description)

The SV-10c Resource Event Trace Description view provides a time-ordered

examination of the interactions between resources. It lays out the sequence of interactions

involving these resources. Each Event-Trace diagram will have an accompanying

description that defines the particular scenario or situation. This view is typically defined in

combination with the SV-10b view.

Figure 46 is an SV-10c diagram from the SAR rescue example model.



UPDM





Radio


Distress Beacon


Monitor


Radio


Digital Service


Monitor


Radio


Digital Service

alt Person in Distress alt Aircraft alt Boat

DS() :distress signal

DS() :distress

signal

RT1() :radioDiscussion

TRK2()

:track

TRK() :track

TD1() :TDM

TD2() :TDM

RT1() :radioTransmision

RT1() :radiotramsission

Figure 46: SV 10c view from the SAR example model

Related to:


SV-10a System Rules and Constraints

SV-10b Resource State Transition Description

SV-11 System Data Model (DoDAF DIV-3 Physical Data model)

The UPDM SV-11 System Data Model view corresponds to the MODAF SV-11 view and

the DoDAF DIV-3 Physical Data Model view. It models the structure of the system data used

within the architecture.

Figure 47 is an SV-11 Physical Data model for the SAR reconnaissance example.



UPDM




«ExchangeElement»

aircraftInstruction

«ExchangeElement»

lifePreserv erInstruction

«ExchangeElement»

routeInfo

«ExchangeElement»

beaconInstruction

«ExchangeElement»

radioInstruction

«ExchangeElement»

taskingOrder

«ExchangeElement»

boatInstruction

«ExchangeElement»

TDM

«ExchangeElement»

wayPoint

«ExchangeElement»

distressSignal

«ExchangeElement»

track

«ExchangeElement»

searchCriteria

«ExchangeElement»

postFlightCheckList

«ExchangeElement»

preFlightCheckList

«EntityItem»

ELINT Profile

«EntityItem»

RCS Profile

«EntityItem»

Thermal Profile

«EntityItem»

Image Profile

«EntityItem»

Acoustic Data

«EntityItem»

Signal Data

«EntityItem»

Sensor Data

«EntityItem»

Image Data

«EntityItem»

Thermal Data

1

SD

*

1

ID

*

1

TG

*

1

AD

*

Figure 47: SV-11 Physical Data Model for the SAR example model

For more detail on options for creating Physical Data models in Enterprise Architect, see the

Help topics on:

Database Engineering

Data modeling

Related to:




SV-10c Resource Event Trace Description

Acquisition Views

During the lifecycle of a project it will be necessary to acquire the resources needed to fulfill

the mandate of the project. The Acquisition views provide a means of outlining the high-

level tasks for acquiring assets, resources and capabilities that will be required during the full

lifecycle of the operation.

For more details on Acquisition views see:

DoDAF Project Viewpoint

MODAF View Summary


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/database_engineering/database_engineering.html

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/domain_based_models/datamodelling2.html

http://dodcio.defense.gov/dodaf20/dodaf20_project.aspx



UPDM




AcV-1 System of Systems Acquisition Clusters (DoDAF PV-1)

The AcV-1 System of Systems Acquisition Clusters view represents, from a high-level

perspective of the program, how acquisition processes are to be grouped. It lays out the

modeling of the organizational structures needed to manage a portfolio of projects.

Figure 48 is an AcV-1 diagram for System of Systems Acquisition Clusters from the SAR

example model.

«ActualProject»

SAR Manual Project I :

Dev elopment

«ActualProject»

SAR Automation Project :

Dev elopment

«ActualProject»

SAR Manual Project II :

Dev elopment


Department Of Transport :


«ProjectOwnership»



Figure 48: AcV-1 System of Systems Acquisition Clusters example

AcV-2 Program Timeline (DoDAF PV-2)

The AcV-2 Program Timeline view provides a timeline perspective on projects. It is used to

summarize, using milestones, the status of key aspects being developed within the project.

The AcV-2 calendar view can be set using Swimlanes, which can depict annual, quarterly or

monthly periods. For more details see the Swimlanes Help topics.

Each milestone can have DLOD’s defined using element Run-States. For more information

on setting the DLOD see the Run Time States Help topic. These are predefined in the AcV-3

(PV-3) diagram.

Figure 49 is an AcV-2 diagram for Program Timelines from the SAR example model.


http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/modeling_basics/swimlanes.html



UPDM




Actual Projects QTR 1 2010 QTR 2 2010 QTR 3 2010 QTR 4 2010 QTR 1 2011 QTR 2 2011

«ActualProject»


Dev elopment

tags

endDate = 2010-12-01


«ActualProject»


Dev elopment

tags

endDate = 2011-06-28


«ActualProject»


Dev elopment

tags

endDate = 2011-02-01


«IncrementMil...

MRU v 1 INC

tags

date = 2010-01-01

description =

«DeployedMil...

MRU v 1 EU DEP

tags

date = 2010-07-01

description =

«DeployedMil...

MRU v 1 UK DEP

tags

date = 2010-04-01

description =

«NoLongerUs...

MRU v 1 NLU

tags

date = 2010-09-01

description =

«OutOfServic...

MRU v 1 OOS

tags

date = 2010-11-01

description =


MRU v 2 OOS


Training = Complete








tags

date = 2011-05-01

description =

«NoLongerUs...

MRU v 2 NLU

tags

date = 2011-01-01

description =

«DeployedMil...

MRU v 2 DEP

tags

date = 2010-10-01

description =

«IncrementMil...

MRU v 2 INC

tags

date = 2010-08-01

description =




Training = Complete








tags

date = 2011-01-01

description =

«DeployedMil...

ARU INC :

Dev elopment

Milestone

tags

date = 2010-10-01

description =

«IncrementMil...

ARU Beta Unit INC :

Dev elopment

Milestone

tags

date = 2010-07-01

description =

«MilestoneSequence»





Figure 49: AcV-2 diagram showing the quarterly milestones.

Related to:



AcV-3 Typical Project

AcV-3 Typical Project (DoDAF PV-3)

The AcV-3 Typical Project view can be used to define Projects and Project types. This is

where you can define what specific details can be set as Run Time states in the milestone

instances used in AcV-2 diagrams.



UPDM




«ProjectType»

Dev elopment

«ProjectMilestone»

Dev elopment Milestone

«ProjectTheme»

+ Equipment :DLOD Status

+ Training :DLOD Status

+ Concepts & Doctrine :DLOD Status

+ Personnel :DLOD Status

+ Information :DLOD Status

+ Organization :DLOD Status

+ Infrastructure :DLOD Status

+ Logistics :DLOD Status

+ Interoperabil ity :DLOD Status

«enumeration»

DLOD Status

Not Applicable

Complete

In Progress

Not Started

InTest

0..1

+subProject *

1

+milestone *

Related to:


AcV-3 Actual Project Instance (DoDAF PV-3)

The AcV-3 Actual Project Instance view can be defined using a DoDAF PV-3 view. This

allows for defining the actual project and actual project milestones. Figure 50 depicts when

events are initially deployed and when they are intended to be withdrawn from service.



UPDM





MRU v 1 INC

tags

date = 2010-01-01

description =

«ActualProject»


Dev elopment

tags

endDate = 2011-02-01


«ActualProject»


Dev elopment

tags

endDate = 2010-12-01


«ActualProject»


Dev elopment

tags

endDate = 2011-06-28



MRU v 2 INC

tags

date = 2010-08-01

description =


MRU v 1 UK DEP

tags

date = 2010-04-01

description =


MRU v 2 DEP

tags

date = 2010-10-01

description =


MRU v 1 EU DEP

tags

date = 2010-07-01

description =


ARU Beta Unit INC :Dev elopment Milestone

tags

date = 2010-07-01

description =


ARU INC :Dev elopment Milestone

tags

date = 2010-10-01

description =


MRU v 1 NLU

tags

date = 2010-09-01

description =


MRU v 2 NLU

tags

date = 2011-01-01

description =


MRU v 1 OOS

tags

date = 2010-11-01

description =


MRU v 2 OOS


Training = Complete








tags

date = 2011-05-01

description =




Training = Complete








tags

date = 2011-01-01

description =

Press Ctrl+Shift+2 to open the

Relationships window. This will show for

a selected element, which other

elements are related to it. For example,

which capability configuration is

dependent on each milestone.


Figure 50: AcV-3 Actual Project Instance used in the SAR example model

Related to:




Technical Views

The Technical Views (Standards view in DoDAF), are used to lay out the standards, rules

and policies that are used in the architectural modeling of a project.

For more detail on Standards views see:

DoDAF Standards ViewPoint

MODAF View Summary


http://dodcio.defense.gov/dodaf20/dodaf20_standards.aspx



UPDM




TV-1 Standards Profile (DoDAF StdV-1)

The TV-1 Standards Profile view or Technical Standards view lays out the set of standards

that may influence any elements depicted in the systems and services views.

Standards identified in the Technical Standards Profile (TV-1) should be the same as those

identified in the Systems Interface Description (SV-1). The TV-1 collects the various systems

standards rules that implement and sometimes constrain the choices that can be made in the

design and implementation of architecture.

The standards cited are referenced as relationships to the systems, system functions, system

data, hardware/software items or communication protocols in SV-1, SV-2, SV-4, SV-6, OV-

7, and SV-11 Products, where applicable.

Figure 51 is a TV-1 diagram for a Standards Profile from the SAR example model. An

alternative representation of this using a Relationship Matrix is shown in Figure 52.

Figure 51: TV-1 Standards Profile from the SAR model example



UPDM




Figure 52: TV-1 Shown Using a Relationship Matrix

Related to:


SV-2 Systems Capabilities View


SV-6 Systems Exchange Matrix

SV-11 System Data Model


TV-2 Standards Forecast (DoDAF StdV-2)

The TV-2 Technical Standards Forecast view provides a description of emerging standards

and their potential impact on current systems and services view elements, within a set of time

frames. The forecast for evolutionary changes in the standards should be correlated against

the time periods as mentioned in the SV-8 and SV-9 products. A TV-2 complements and



UPDM




expands on the Standards Profile (TV-1) product and should be used when more than one

emerging standard time-period is applicable to the architecture.

Figure 53 is a TV-2 diagram for System Standards from the SAR example model. An

International Standards representation of this is shown in Figure 52.

«Standard»

Distress Monitoring

«Standard»

Link 16 Digital Communications

«Standard»

Global Maritime Distress

and Safety System

(GMDSS)

«Standard»

MIL-STD-6016

«Standard»

STANAG 5516

«Standard»

Marine Radio

«Standard»

ETS 300 387

«Standard»

MGN 324 Operational

Guidance on the Use of VHF

Radio and Automatic

Identification Systems

«Standard»

USCG Marine Radio

Information for Boaters

International Standard US Standard NATO Standard

European Standard UK Standard US Standard

«Forecast» Tags:


«Forecast» Tags:


«Forecast» Tags:


«Forecast» Tags:

startDate = 1994-05-01«Forecast» Tags:



{Long Term}

«Forecast» «Forecast» «Forecast»

«Forecast» «Forecast» «Forecast»

Figure 53: TV-2 System Standards from the SAR model example



UPDM




«Standard»

Standards::ASTM F1824 -

97(2007) Standard Guide

for Performance of a

Water Rescuer-Lev el II

«Standard»


97(2007) Standard Guide for

Water Rescue Personal

Flotation Dev ice (PFD)

«Standard»


03(2008)e1 Standard Spec

for Masses Used inTesting

Rescue Systems and

Components

«Standard»


99(2005) Standard

Classification of Human

Seach and Rescue

Resources

«Standard»

Standards::ASTM International Standard

«Standard»


96(2007) Standard Guide

for Performance of a

Water Rescuer-Lev el I

«Standard»

Standards::ASTM F1490 -04a

Standard Terminology

Relating to Search and

Rescue

tags

mandatedDate = 2010-08-10

«Standard»


08 Guide for Using the

ICSFr in Managing Search

and Rescue Operations

«Definition»

Person in Distress: PiD

«Forecast» Tags:


«Forecast» Tags:



{Short Term}


{Long Term}


{Mid Term}

«Forecast» «Forecast» «Forecast» «Forecast»

«Forecast» «Forecast»«Forecast»

Figure 54: TV-2 International Standards from the SAR model example

Related to:




SV-9 Technology and Skills Forecast

Conclusion When modeling joint task operations involving different organizational groups, the modeling

structure must be consistent - hence the need for the unified profile on defense modeling. In

this paper we have highlighted the comprehensive features of Enterprise Architect used to

design models of combined operations, using UPDM for modeling in the DoDAF and

MODAF frameworks.


Date post:	04-Oct-2021
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times