Overview of Do DAF based on Deskbook Saurabh

Overview of Do. DAF (based on Deskbook) Saurabh Mittal, Ph. D saurabh@ece. arizona. edu Feb 17, 2005 (Last Updated, Dec 2007) ACIMS Lab, ECE Dept. , www. acims. arizona. edu University of Arizona

Agenda n n Definition of a Framework and an Architecture Framework Basic Do. DAF structure ¨ ¨ ¨ n Process Flow and creation of Views ¨ n Steps involved in construction People involved ¨ n Operational Views System Views Technical Views who, how and where Examples ¨ SSAF (Sensing System Architectural Framework)

Architectures and Frameworks Can the same rules help define this architecture ? Now consider a set of Rules, If we have answer to this that can define and build each of question, then this set of Rules is these Architectures. called a Framework “Extreme Architecture”: A Minimalist IT Architecture framework Phil Robinson and Floris Gout

IT Architecture and Framework n n n 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 Clinger-Cohen’s Act’s definition of IT Architecture referring to an Integrated Framework n A framework should enable you to build specific architectures that meet specific needs.

IT Framework Description Department of Defense Architectural Framework (Do. DAF) Do. DAF 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 (Fo. Ss), System of Systems (So. Ss) and interoperating and interacting architectures Operational View ne en ts Relates Systems and Characteristics To Operational Needs • Technical Standards Criteria governing interoperable Implementation/Procurement of the selected System capabilities m View re ui eq l R es na liti tio bi ra pa pe a • O nd C a Identifies What needs to be Accomplished and who does it s ge n o t a ne ds it xch do e e s E it he • B t n oe ion get a t t ion as h o d at o r T o e t ic c a p • W h rm d t s h p rm up n u • W nfo ire • o N s fo p • I qu • C ew ort log at In ap T ab y re th nd s ab ec ili m sa ili hn ty e t tie es tie ic s i g y s al • S ctiv han • Specific System Capabilities A xc required to Satisfy E Information Exchanges Systems be do Technical View Prescribes Standards and Conventions

The Development Process for Operational Views • • OV-1 OV-5 OV-6 OV-2 OV-3 OV-7 OV-4

The Development Process for System and Technical Views • • • 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 Involved Do. DAF specifies this ‘hierarchy’ of people involved in construction of the specification document and physical realization Abstract Description ¨ Planner conceptual ¨ Owner Do. DAF specs Refinement ¨ Designer ¨ Implementer ¨ Contractor System-blocks & COTS Realized System

Organization assembly & Management • ‘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 Capabilities/Functionalities Planner domain 2 Designer B 4 Contractor 9 B Owner B Implementer A 1 Implementer B 3 Owner A Contractor A 5 6 10 Designer A 7 11

Contribution by Planner n Summary View (AV-1 and OV-1) n Data centric, node-centric and People centric (OV-2, OV-4) n Functionality-oriented and Motivation behind the plan (OV-5, OV-6) n System Functionality and traceability (SV-5) n System Interface Descriptions (SV-1)

Contribution by Owner n n n n Integrated Dictionary and terminology (AV-2) Operational Information Exchange Matrix (OV-3) Operational Activity Model, Event-trace and State Machines (OV-5, OV-6 b, c) OV-5 System Interface Description (SV-1) SV-1 Operational to System Traceability Matrix (SV-5) SV-5 System-system matrix (SV-3) System Evolution description (SV-8) Refines the Operational Concepts constructed by the Planner Ensures that functionality desired is feasible Provides detailed ‘operational’ views Develops the transition to System Views

Contribution by Designer n n n n 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-8) SV-8 System Rules, Event-traces and State transitions (SV-10 a, b, c) Technical Standards Profile (TV-1) More so like the Planner… but in ‘Systems’ domain. He actually merges the Operational concepts constructed by the Planner and puts them in systems perspective Verifies the operational functionality based on the Logical Node description document (OV-7)

Contribution by Implementer Refines the System Views handed over by the Designer Verifies the System functionality with Operational functionality description using Node Connectivity document (OV-7) Maps it to current technology Develops the migration and evolution pathway towards future n n n System Technology Forecast (SV-9) Physical Schema (SV-11) Technical Standards Forecast (TV-2)

Contribution by Contractor Takes money… for supply and installation of equipment Refines the System-View docs on need basis and documents it Designer’s work is realized here May result in refinement of ‘design’ itself n n n Installation Field Testing Support. . . etc…

Example SSAF – A subset of Do. DAF (Sensing System Architectural Framework) n Please refer to link below: http: //www. u. arizona. edu/%7 Esaurabh/ILS 3 Docs/ILS 3%20 Architecture%20 Based%20 On%20 Do. DAF. ppt

Published Research 2005 -2007 n Saurabh Mittal, Bernard P. Zeigler, Modeling and Simulation for Systems of Systems Engineering, Chapter for “Systems of Systems Engineering for 21 st Century”, Editor Mo Jamshidi, Wiley, to appear n J. 2: Saurabh Mittal, Eddie Mak, James J. Nutaro, DEVS-Based Dynamic Model Reconfiguration and Simulation Control to in the Enhanced Do. DAF Design Process, Journal of Defense Modeling and Simulation (JDMS), Vol. III No. 4, 2006 n J. 1: Saurabh Mittal, Extending Do. DAF to Allow DEVS-based Modeling and Simulation, Special issue on Do. DAF, Journal of Defense Modeling and Simulation JDMS, Vol. III No. 2, 2006 n C. 3: Saurabh Mittal, José Luis Risco Martín, Bernard P. Zeigler, DEVS-Based Web Services for Netcentric T&E, Summer Computer Simulation Conference (SCSC’ 07), San Diego, July 2007 n C. 2: Saurabh Mittal, Amit Mitra, Amar Gupta, Bernard P. Zeigler, Strengthening OV-6 a Semantics with Rule-Based Meta-models in DEVS/Do. DAF Based Life-cycle Architecture Development, IEEEInformation Reuse and Integration (IRI 06) Conference, Special section on Do. DAF, Hawaii September 2006 n C. 1: Bernard P. Zeigler, Saurabh Mittal, Enhancing Do. DAF with a DEVS-based System Lifecycle Development Process, In Proceedings of IEEE International Conference on Systems, Man and Cybernetics, SMC 05, Hawaii 2005