Upload
kiley
View
45
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Architecture Framework Standardization. Fatma Dandashi, Ph.D. [email protected] Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task Force May, 2005. What is DODAF. The Department of Defense (DoD) Architecture Framework (DODAF) - PowerPoint PPT Presentation
Citation preview
Architecture Framework Standardization
Fatma Dandashi, Ph.D.
Mr. Dwayne Hardy, OSD ATL-Open Systems Joint Task Force
May, 2005
3
What is DODAF
• The Department of Defense (DoD) Architecture Framework (DODAF)– Defines a common approach for modeling, presenting, and
comparing a System-of-Systems (SoS) architecture (Systems View) along with associated standards (Technical View) within the context of the mission capabilities (Operational View).
• The principal objective of the Framework is to – Ensure that architecture models can be compared and related
across organizational boundaries, including Joint and multi-national boundaries
4
What is MODAF*
• UK Ministry of Defence Architectural Framework– Based on DODAF with some minor changes to TV-1, OV-1, OV-
2, SV-1 and SV-2 – Adds two new viewpoints:
• Strategic Capability Views – these views define the high level capability vision, the capabilities and sub-capabilities (capability functions) required to support that vision, the dependencies between capabilities, the phasing in and out of systems to support the capabilities, and the organizations in which those systems are to be deployed.
• Acquisition Views – these views define the project team structures required to deliver network enabled capabilities. They also define the inter-project dependencies and specify the lines of development status at significant project milestones.
Source: http://www.modaf.com/
5
System-of-Systems Characteristics
Boundaries
Interactions
The increased use of architectures, as a basis for making programmatic decisions, raises the bar for their level of consistency, precision and scalability
SoSs needed to achieve a single capability typically:
•Are not usually managed or funded under a singular authority
•Composed from complex systems that provide independent functionality
•Are hard to bound•Are distributed over time and space
6
Why an Architecture FrameworkMilitary
Capabilities
-Expressed as Concepts-Modeled via: Ways (Behavior /ops activities) and Means (ops resources)
SoS and System Components
Expressed as • System Components• Functions• Interfaces
7
Requires Collaboration of many Communities or Stakeholders
Architecture data can be a means for integrating stakeholder processes, thereby improving communications, analyses, and tradeoff decisions!
TestersTesters
Developers/Developers/IntegratorsIntegrators
VendorsVendors
RegulatorsRegulators
CustomersCustomers
Project Project ManagersManagers
8
Problem Statement
• DODAF V1.0 Volume II provides guidance on using UML– Used extensively to represent DODAF architecture products
across industry– Not sufficiently precise resulting in multiple interpretations (no
one-to-one mapping between UML diagrams and DODAF products)
– Based on UML 1.x which has been superseded by UML 2
DODAF UML guidance is inadequate to facilitate communications, architecture product reuse and
maintainability, and tool interoperability
9
Solution Statement
• DODAF V 1.0 exposed a need for architecture-based model-driven systems engineering
• SysML is a UML profile for model-driven systems engineering
• Initial analysis indicates good coverage of all DODAF/MODAF views with SysML*
Develop a UML Profile for DODAF/MODAF that provides an industry standard SysML representation of DODAF/MODAF
architecture views
* see Bailey et al in references section
10
Why Standards ?
• Standards can offer
– Broader acceptance
– Improved integration with other frameworks
– Improved tool interoperability
– Reduced training requirements
11
Systems Engineering Standards & Architecture Frameworks
SADTSADT
ProcessStandards
Modeling & SimulationStandards
Modeling Methods
ZachmanDODAFArchitecture Frameworks
OOSEM
UML/SysMLUML/SysML IDEF0
Interchange Standards
MOF/XMIMOF/XMI STEP/AP-233 CADM
OtherHLA
Modeling Simulation
ToolToolSupportSupport
EIA 632 CMMI *ISO 15288 IEEE 1220
ADMRUP SE
OtherRM-ODP
Other
The slide illustrates just one of the many standard-based tool chains that can be defined!
CADMCADMMOF/XMIMOF/XMI STEP/AP-233STEP/AP-233
DODAFDODAF
UML/SysMLUML/SysML
TOGAF
12
Vision –Standards-based Tool Interoperability
SV4
AP233
OMG SysMLOther SE Views
Operational
Syst
ems
Technical
DODAF
AP2xx
Detailed Design,Manufacturing,Life Cycle Support,…
ISO 10303STEP APs
specifies requirements for
AP233
ArchRepository
XMI
AP
233
13
What is SysML?
• A UML Profile For Systems Engineering in response to the requirements developed by the OMG, INCOSE, and AP233
• Supports the specification, analysis, design, verification and validation of a broad range of complex systems that may include hardware, software, data, personnel, procedures, and facilities
• Represents a subset of UML 2 with the extensions to meet the requirements for systems engineering– enhancements to composite structure and activity diagrams – two new diagram types for requirements and parametric– allocation relationships and auxiliary constructs– SysML alignment with ISO AP-233
14
Example DODAF ProductsUsing a UML Extension
• Example was provided by Artisan Software• Artifacts included here are for exposition purposes only
• There are several other vendor implementations of DODAF using SysML (e.g., Telelogic, I-Logix) – There are similarities and differences among the tool
implementations– The various implementations expose the need for
standardization
15
Typical OV-2 Using Artisan Tool*
«OperationalNode»Mission Planning
Logistics
Routing
Assessment
Coordination
HQ
Artillery Command
Air Command
C-Rout : Route Info«InformationExchange»
C-Log : Munitions Status«InformationExchange»
ASS-C(W) : Weapons Intel«InformationExchange»
ASS-C(F) : Flight Intel«InformationExchange»
Log-Art : Mission Plan«InformationExchange»
Route-AC : Mission Plan«InformationExchange»
C-HQ : Mission Intel«InformationExchange»
ArtC-Ass : Weapons Intel«InformationExchange»
AC-Ass : Flight Intel«InformationExchange»
OV-2 : Structure for Mission Planning
* Courtesy of Artisan Software
Item Flow
Op Node
Organization
16
Typical OV-5 Using Artisan Tool
Mission Planning
Coordination
Prepare Route
«op activity»
Nominate Artillery Units
«op activity»
Prepare Mission Intell Report
«op activity»
Logistics
Verify and Instruct Artillery Units
«op activity»
Routing
Produce Detailed Routing
«op activity»
Gather Attack Intelligence
«op activity»
Assessment
Gather Flight Intelligence
«op activity»
«InformationExchange»«InformationExchange»
C-Rout«InformationExchange»«InformationExchange»
C-Log
«InformationExchange»«InformationExchange»
ASS-C(W)
«InformationExchange»«InformationExchange»
ASS-C(F)
OV-5 : Mission Planning Flow
* Courtesy of Artisan Software
Op Node
Information Exchange
17
Typical SV-1 Using Artisan Tool
«systemNode»Aircraft
: Class1
«systemNode»MissilePlatform
: Class1
«systemNode»Mobile HQ
: Class1
«systemNode»Main HQ
: Class1
MHQ-HQ : Intell Data
HQ-MHQ : Mission Data«interface»
HQ-AC : Flight Data«SystemDataExchange»
AC-HQ : Intell Data«SystemDataExchange»
«interface»
MHQ-MP : Target Data«SystemDataExchange»
MP-MHQ : Intell Data«SystemDataExchange»
«interface»
DeployedSystems
Defence PlanningWeapon CoordinatorCartography
DeployedSystems
WeaponReconnaisanceSupportedOpNodes
IntelligenceWeapons Control
DeployedSystems
Flight ControlNavigationReconnaisance
DeployedSystems
Flight AssessmentFlight CommsMission PlanningMission Assessment
SV-1 : Systems Interaction Overview
* Courtesy of Artisan Software
Item Flow
Systems Node
18
Typical SV-1 Detail Using Artisan Tool
«systemNode»MissilePlatform
«system»: Weapon
«system»: Targetting
«system»: Guidance
«system»: Reconnaissance
«systemNode»Mobile HQ
: Cartography«system»
: Weapon Coordinator«system»
: Defence Planning
«systemNode»Main HQ
«system»: Mission Planning
«system»: Mission Assessment
«system»: Flight Planning
«system»: Flight Assessment
«systemNode»: Aircraft
«system»: Flight Control
«system»: Navigation
«system»: Reconnaissance«interface»
DP-WC : Defence Plan
WC-W(T) : Target Data
«interface»«interface»Recon Intell
MP-DP : Mission Data
SV-1 : System Interaction Detail
* Courtesy of Artisan Software
System Node
System
Interface/ Item Flow
Interface
19
IssueRFP
VoteAdoption of a SpecificationRFPRFP
4-6 mo InitialSubmissions
InitialSubmissions
6-8 mo RevisedSubmission(s)
RevisedSubmission(s)
8-10 mo
EvaluateSubmissions
EvaluateSubmission
ToolsTools
Need
ImplementationImplementation12 mo
LOI
OMG Technology Adoption Process (Typical)
We are here
20
UML Profile for DODAF/MODAF RFPScope
• Use DODAF V1.0 as a baseline• Incorporate MODAF’s additional views (Acquisition and
Strategic)• Incorporate additional requirements from DODAF V2.0
WG (e.g., support for overlays) • Support for modeling system-of-systems architectures
– Systems that include hardware, software, data, personnel, procedures, and facilities (DOTMLPF & MOD Lines of Development )
– Service oriented architectures and net-centricity
21
UML Profile for DODAF/MODAF RFPRequirements Summary
• Develop RFP that specifies the requirements for a UML Profile for DODAF/MODAF – Standard Notation (concrete syntax)– Implementation-independent domain meta-model (abstract
syntax and constraints)– Views and Viewpoints– Architecture Products– Extensible library of reusable architecture elements and patterns– Standard data interchange mechanism (e.g., XMI)
• Optional requirements to support:– Standard diagram interchange mechanism– Other architecture frameworks (e.g., NATO’s Framework, ..)
22
UML Profile for DODAF/MODAF Roadmap
Feb 2008Feb 2007Feb 2006
SysML/AP233 Alignment
Feb 2005
DODAFV 1.0(2004)
DODAFV 2.0
SysMLV 1.0
Adopted
OMG Kickoff(Feb 05)
RFP(Nov 05)
UML Profile for DODAF/MODAF
SysMLV 0.9
DODAF V 2.0Inputs
MODAFV 1.0
23
Summary of Interested Parties*
• Tool Vendors:– Artisan
– Borland
– I-Logix
– Popkin Software
– Proforma Corp
– Telelogic
• Other Support:– OSD, MOD, others
– BAE Systems
– Boeing
– Eurostep
– LMC
– Raytheon
– Sandia Labs
– Thales
– Unisys
* partial list
24
Long Term Solution
• Develop standard for the specification of general architecture frameworks– Leverage IEEE 1471– Make applicable to a broad range of architecture frameworks
• Military and commercial e.g., Zachman Framework
– Utilize experience from UML Profile for DODAF/MODAF standardization to reduce risks
– Issue RFI followed by RFP through OMG
Questions?
28
Industry Feedback
• Presented architecture framework standardization effort through the OMG in early February
• Resistance to immediate standardization of a UML profile for a generic Architecture Framework– Scope is too large to complete in a reasonable amount of time– Tool Vendors concerned about lack of market and technical risks
• Strong request for a UML profile that implements standard representations for DODAF
• Support for follow-on effort to establish standards for the specification of generalized architecture frameworks