Transcript Background

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)
– 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 multinational boundaries
3
What is MODAF*
• UK Ministry of Defence Architectural Framework
– Based on DODAF with some minor changes to TV-1, OV-1, OV2, 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/
4
System-of-Systems Characteristics
Interactions
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
Boundaries
•Are hard to bound
•Are distributed
over time and
space
The increased use of architectures, as a basis for making programmatic
decisions, raises the bar for their level of consistency, precision and scalability
5
Why an Architecture Framework
Military
Capabilities
-Expressed as Concepts
-Modeled via:
Ways (Behavior /ops
activities) and
Means (ops resources)
SoS and System
Components
Expressed as
• System Components
• Functions
• Interfaces
6
Requires Collaboration of many
Communities or Stakeholders
Developers/
Integrators
Customers
Project
Managers
Vendors
Regulators
Testers
Architecture data can be a means for integrating stakeholder processes,
thereby improving communications, analyses, and tradeoff decisions!
7
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
8
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
9
Why Standards ?
• Standards can offer
– Broader acceptance
– Improved integration with other frameworks
– Improved tool interoperability
– Reduced training requirements
10
Systems Engineering Standards
& Architecture Frameworks
Process
Standards
Architecture
Frameworks
Modeling
Methods
Modeling &
Simulation
Standards
Interchange
Standards
EIA 632
ISO 15288
DODAF
DODAF
SADT
IEEE 1220
Zachman
RUP SE
UML/SysML
UML/SysML
RM-ODP
OOSEM
IDEF0
Modeling
MOF/XMI
MOF/XMI
CMMI *
TOGAF
Other
Other
ADM
HLA
Other
Simulation
STEP/AP-233
STEP/AP-233
Tool
Support
CADM
CADM
The slide illustrates just one of the many standard-based tool chains that
can be defined!
11
Vision –
Standards-based Tool Interoperability
ISO 10303
STEP APs
Operational
DODAF
specifies requirements for
Detailed Design,
Manufacturing,
Life Cycle Support,
…
Other SE Views
OMG SysML
AP233
AP233
AP2xx
AP233
Arch
Repository
12
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
13
Example DODAF Products
Using 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
14
Typical OV-2 Using Artisan Tool*
OV-2 : Structure for Mission Planning
Op Node
Organization
Item Flow
HQ
«InformationExchange»
C-HQ : Mission Intel
«OperationalNode»
Mission Planning
«InformationExchange»
Route-AC : Mission Plan
«InformationExchange»
C-Rout : Route Info
Coordination
«InformationExchange»
C-Log : Munitions Status
«InformationExchange» Routing
ASS-C(W) : Weapons Intel
Air Command
«InformationExchange»
ASS-C(F) : Flight Intel
«InformationExchange»
Log-Art : Mission Plan
«InformationExchange»
AC-Ass : Flight Intel
Logistics
Assessment
«InformationExchange»
ArtC-Ass : Weapons Intel
Artillery Command
* Courtesy of Artisan Software
15
Typical OV-5 Using Artisan Tool
Op Node
OV-5 : Mission Planning Flow
Mission Planning
Coordination
«op activity»
Prepare Route
«op activity»
Nominate Artillery Units
Logistics
Routing
Assessment
«op activity»
«InformationExchange»
Produce Detailed Routing
C-Rout
«InformationExchange»
C-Log
«op activity»
Verify and Instruct Artillery Units
«op activity»
Prepare Mission Intell Report
«InformationExchange»
ASS-C(W)
«InformationExchange»
ASS-C(F)
«op activity»
Gather Attack Intelligence
«op activity»
Gather Flight Intelligence
Information
Exchange
* Courtesy of Artisan Software
16
Typical SV-1 Using Artisan Tool
SV-1 : Systems Interaction Overview
«systemNode»
Aircraft
«systemNode»
MissilePlatform
DeployedSystems
DeployedSystems
Weapon
: Class1
Reconnaisance
Flight Control
: Class1
Navigation
Reconnaisance
SupportedOpNodes
Intelligence
Weapons Control
«SystemDataExchange»
MHQ-MP : Target Data
«SystemDataExchange»
MP-MHQ : Intell Data
Item Flow
«SystemDataExchange»
HQ-AC : Flight Data
«interface»
«interface»
«systemNode»
Mobile HQ
DeployedSystems
: Class1
Defence Planning
Weapon Coordinator
Cartography
* Courtesy of Artisan Software
«SystemDataExchange»
AC-HQ : Intell Data
MHQ-HQ : Intell Data
Systems
Node
«systemNode»
Main HQ
«interface»
HQ-MHQ : Mission Data DeployedSystems
Flight Assessment
Flight Comms
: Class1
Mission Planning
Mission Assessment
17
Typical SV-1 Detail Using Artisan Tool
System
Node
SV-1 : System Interaction Detail
«systemNode»
Main HQ
«systemNode»
: Aircraft
System
«systemNode»
MissilePlatform
«system»
: Flight Planning
«system»
: Mission Planning
«system»
: Flight Control
«system»
: Weapon
«system»
: Guidance
«system»
: Mission Assessment
«system»
: Flight Assessment
«interface»
Recon Intell
«interface»
«system»
: Targetting
WC-W(T) : Target Data
«systemNode»
Mobile HQ
MP-DP : Mission Data
«interface»
«system»
: Reconnaissance
: Cartography
«system»
: Navigation
«system»
: Weapon Coordinator
«system»
: Reconnaissance
«system»
: Defence Planning
DP-WC : Defence Plan
Interface/
Item Flow
Interface
* Courtesy of Artisan Software
18
OMG Technology Adoption Process (Typical)
We are
here
Evaluate
Submission
LOI
Need
Vote
Adoption of a
Specification
RFP
4-6 mo
Initial
Submissions
6-8 mo
Issue
RFP
Revised
Submission(s)
8-10 mo
Evaluate
Submissions
Implementation
12 mo
Tools
19
UML Profile for DODAF/MODAF RFP
Scope
• 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
20
UML Profile for DODAF/MODAF RFP
Requirements 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, ..)
21
UML Profile for DODAF/MODAF
Roadmap
DODAF
V 1.0
(2004)
MODAF DODAF V 2.0
Inputs
V 1.0
OMG Kickoff
(Feb 05)
SysML
V 0.9
DODAF
V 2.0
UML Profile
for DODAF/MODAF
RFP
(Nov 05)
SysML
V 1.0
Adopted
SysML/AP233 Alignment
Feb 2005
Feb 2006
Feb 2007
Feb 2008
22
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
23
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
24
Questions?
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
28