Overview of DoDAF(based on Deskbook)

Saurabh Mittal, PhDsaurabh@ece.arizona.edu

Feb 17, 2005

(Last Updated, Dec 2007)

ACIMS Lab, ECE Dept.,www.acims.arizona.edu

University of Arizona

Agenda

Definition of a FrameworkFramework and an ArchitectureArchitecture Basic DoDAF structure

Operational Views System Views Technical Views

Process Flow and creation of Views Steps involved in construction

People involved who, how and where

Examples SSAF (Sensing System Architectural Framework)

Architectures and FrameworksNow consider a set of Rules, that can define and build each of these Architectures.

If we have answer to thisquestion, then this set of Rules is

called a Framework

Can the same rules helpdefine this architecture ?

““Extreme Architecture”: A Minimalist IT Architecture frameworkExtreme Architecture”: A Minimalist IT Architecture frameworkPhil Robinson and Floris Gout Phil Robinson and Floris Gout

IT Architecture and Framework

If you can implement a drawing in ONLY one way, then the drawing contains exact specifications for instantiation and you have a DESIGN

If you can implement a drawing in more than one way, you have an architecture

If you can develop more than one architecture, then you have a framework that provides you with the underlying structure for developing these architectures

A framework should enable you to build specific architectures that meet specific needs.

Clinger-Cohen’s Act’s definition of IT Architecture referring to an Integrated Framework

IT Framework DescriptionDepartment of Defense Architectural Framework (DoDAFDoDAF)

guidelines• To create IT systems and architectures that cross

organizational and national boundaries• To provide a common denominator of understanding,

comparing and integrating these Families of Systems (FoSs), System of Systems (SoSs) and interoperating and interacting architecturesOperationalOperational

ViewView

Identifies What needs to be Identifies What needs to be Accomplished and who does itAccomplished and who does it

SystemsSystemsViewView

Relates Systems and Characteristics Relates Systems and Characteristics To Operational NeedsTo Operational Needs

TechnicalTechnicalViewView

Prescribes Standards and Prescribes Standards and ConventionsConventions

•What

nee

ds to

be

done

•Who d

oes it

•Info

rmat

ion E

xchan

ges

require

d to g

et it

done

•Operational Requirem

ents

and Capabilities

•Sys

tem

s th

at s

upport th

e

Activ

ities

and In

form

atio

n

Exchan

ges

•Specific System Capabilities required to Satisfy Information Exchanges

•Technical Standards Criteria governing interoperable Implementation/Procurement of the selected System capabilities

•Basic Technology

supportability

•New Technical

•Capabilities

The Development Process for Operational ViewsOperational Views

Requirements &Intended Use of SensorNet

ArchitectureProvided by Dr. McNeill

Scope of Architecture

PurposeCritical IssuesObjectivesTradeOffsAnalysis Methods

Geographical, FunctionalAnd Operational Bounds

Time FrameConstraints

Contexts

All View Summary

Informatiion Diagram

AV-1

Operational Activity Model OV-5

Operational Concept created by PL and IPT LeadsDetermine the Information Flow associated with Activity Set. Identify inputs, controls, outputs and mechanisms associated with Activities

Operation View OV-1

Created by PL and IPT Leads

Operation View OV-1

Created by PL and IPT Leads

Operational Activity Sequence and Timing Diagrams OV-6

Supervised by IPT Leads and created by Team MembersDevelop State Transition Diagrams, Internal and External Input EventsAggregation of individual modules by IPT LeadsDevelop model Repository created in this process Operation Node

Connectivity OV-2

Created by IPT Leads

Logical Data Model OV-7

Created by PL and IPT Leads (classes, objects etc)

Organisational Relationship Chart

OV-4

Operational Information Matrix OV-3

Inputs and outputs

Systems ViewSystems View

• OV-1• OV-5• OV-6• OV-2• OV-3• OV-7• OV-4

The Development Process for System System and Technical Viewsand Technical Views

Identify System Functions provided by current Systems

SV-4

Identify System Functions provided by current Systems

SV-4

Systems Function Traceability Matrix SV-5

Provides primary bridge between Operational View and Systems View

Operational Activity Model OV-5

Taken from Back

Operational Activity Sequence and Timing Diagrams OV-6

Taken from Back

Systems State Description and System Event-Trace (SV-10)

Operation Node Connectivity OV-2

Taken From Back

Systems Interface Description SV-1

Develop System Interfaces based on Systems State Diagrams and Node

Connectivity

Systems Communication Descriptions SV-2

Determine Networking RequirementsDetermine networking requirements within SystemLong-Haul Communications AvailabilityMerge the above three and FINALIZE

Systems Performance Parameters Matrix SV-7

Identify Hardware and Software Parameters

System Data Exchange Matrix SV-6

Determine How Well the Information Flows in the system

based on OV-5, SV-5, SV-11, and OV-7

Logical Data Schema Ov-7

Taken From Back

Physical Schema SV-11

Manner in which OV-7 is implemented in Real

world

Operational Information Matrix OV-3

Taken From Back

Systems-Systems Matrix SV-3

A matrix describing either existing and/or required system interfaces

can be built

System Evolution Desctipiton and Technological advancement

System Evolution Desctipiton and Technological advancement

Technical View TV-1

Current standards

Techinical View TV-2

Future TEchnologies

• SV-4• SV-5• SV-10• SV-11• SV-6• SV-1• SV-2• SV-7• SV-3• TV-1• TV-2 • SV-8

People InvolvedDoDAF specifies this ‘hierarchy’ of people involved

in construction of the specification document and physical realization Planner Owner Designer Implementer Contractor

Abstract DescriptionAbstract Description

Realized SystemRealized System

DoDAF specsDoDAF specsRefinementRefinement

conceptualconceptual

System-blocks &System-blocks &COTSCOTS

Planner domainPlanner domain

Organization assembly & Management

11

33

4422

66

77

99

55

1010

1111

Capabilities/FunctionalitiesCapabilities/Functionalities

Owner AOwner A

Designer ADesigner A

Implementer BImplementer B

Designer BDesigner B

Owner BOwner B

Contractor AContractor A

Implementer AImplementer A

Contractor BContractor B

•‘Hierarchy’ is apparently just two level – Planner and Others•Realization and Management of such massive projects would be a major issue•Independent contractors, designers, and implementers•Book-keeping and documentation - a critical part

Contribution by Planner

Summary View (AV-1 and OV-1)

Data centric, node-centric and People centric (OV-2, OV-4)

Functionality-oriented and Motivation behind the plan (OV-5, OV-6)

System Functionality and traceability(SV-5)

System Interface Descriptions (SV-1)

Contribution by Owner

Integrated Dictionary and terminology(AV-2)

Operational Information Exchange Matrix(OV-3)

Operational Activity Model, Event-trace and State Machines(OV-5OV-5, OV-6b,c)

System Interface Description(SV-1SV-1)

Operational to System Traceability Matrix(SV-5SV-5)

System-system matrix(SV-3)

System Evolution description(SV-8)

Refines the Operational Concepts constructed by the PlannerRefines the Operational Concepts constructed by the PlannerEnsures that functionality desired is feasible Ensures that functionality desired is feasible Provides detailed ‘operational’ viewsProvides detailed ‘operational’ viewsDevelops the transition to System ViewsDevelops the transition to System Views

Contribution by Designer Logical Connectivity

(OV-7) System Communication

description(SV-2)

System Functionality description(SV-4)

System data-exchange matrix(SV-6)

Performance parameters matrix(SV-7)

System evolution (SV-8SV-8)

System Rules, Event-traces and State transitions(SV-10a,b,c)

Technical Standards Profile(TV-1)

More so like the Planner… but in ‘Systems’ domain.More so like the Planner… but in ‘Systems’ domain.He actually merges the Operational concepts constructed by the He actually merges the Operational concepts constructed by the Planner and puts them in systems perspectivePlanner and puts them in systems perspectiveVerifies the operational functionality based on the Logical Node Verifies the operational functionality based on the Logical Node description document (OV-7)description document (OV-7)

Contribution by Implementer

System Technology Forecast(SV-9)

Physical Schema(SV-11)

Technical Standards Forecast(TV-2)

Refines the System Views handed over by the DesignerRefines the System Views handed over by the DesignerVerifies the System functionality with Operational functionality description Verifies the System functionality with Operational functionality description using Node Connectivity document (OV-7)using Node Connectivity document (OV-7)Maps it to current technologyMaps it to current technologyDevelops the migration and evolution pathway towards futureDevelops the migration and evolution pathway towards future

Contribution by Contractor

Installation Field Testing Support...etc..etc...etc…

Takes money… for supply and installation of equipmentTakes money… for supply and installation of equipmentRefines the System-View docs on need basis and documents Refines the System-View docs on need basis and documents ititDesigner’s work is realized hereDesigner’s work is realized here

May result in refinement of ‘design’ itselfMay result in refinement of ‘design’ itself

Example

SSAF – A subset of DoDAF

(Sensing System Architectural Framework)

Please refer to link below:http://www.u.arizona.edu/%7Esaurabh/ILS3Docs/ILS3%20Architecture%20Based%20On%20DoDAF.ppt

Published Research 2005-2007 Saurabh Mittal,  Bernard P. Zeigler, Modeling and Simulation for Systems of Systems Engineering,

Chapter for “Systems of Systems Engineering for 21st Century”, Editor Mo Jamshidi, Wiley, to appear

J.2: Saurabh Mittal, Eddie Mak, James J. Nutaro, DEVS-Based Dynamic Model Reconfiguration and Simulation Control to in the Enhanced DoDAF Design Process, Journal of Defense Modeling and Simulation (JDMS), Vol. III No. 4, 2006

J.1: Saurabh Mittal, Extending DoDAF to Allow DEVS-based Modeling and Simulation, Special issue on DoDAF, Journal of Defense Modeling and Simulation JDMS, Vol. III No. 2, 2006

C.3: Saurabh Mittal, José Luis Risco Martín, Bernard P. Zeigler, DEVS-Based Web Services for Net-centric T&E, Summer Computer Simulation Conference (SCSC’07), San Diego, July 2007

C.2: Saurabh Mittal, Amit Mitra, Amar Gupta, Bernard P. Zeigler, Strengthening OV-6a Semantics with Rule-Based Meta-models in DEVS/DoDAF Based Life-cycle Architecture Development, IEEE-Information Reuse and Integration (IRI06) Conference, Special section on DoDAF, Hawaii September2006

C.1: Bernard P. Zeigler, Saurabh Mittal, Enhancing DoDAF with a DEVS-based System Lifecycle Development Process, In Proceedings of IEEE International Conference on Systems, Man and Cybernetics, SMC05, Hawaii 2005