Applying Unified Architecture Framework

(UAF) for Systems of Systems Architectures

Aurelijus Morkevicius, PhD, Head of Solutions, No Magic Europe, [email protected]

Categorisation
• Accessibility: BEGINNER
• Application: GOOD PRACTICE
• Topics: Enterprise Systems Engineering, MBSE

Abstract
Architecture frameworks continue to evolve. Taking industry demand into account and addressing
changing landscape of existing domain specific architecture frameworks, in September of 2013, a
Request for Proposal for Unified profile for DoDAF and MODAF (UPDM 3.0) (later renamed to Unified
Architecture Framework (UAF)) was created. Since the issue of the request for proposal (RFP), UPDM
3.0 working group identified the list of requirements. To name a few: Architecture Modeling Support
for Defense, Industry, and government Organizations, support of Security Domain, Human Systems
Integration, Support of Systems of Systems (SoS) Life Cycle Processes and Analyses. Since then four
years past and a brand new UAF 1.0 became an official Object Management Group (OMG) standard
and is about to become ISO/IEC 19517 standard. What is this new architecture framework (AF) all
about? How is it different from other AFs? Is it simply a synthesis of a legacy? Or is it a modern
technology combining the best practices of the old with a new and modern?

This paper explores UAF, answering the fundamental questions above and putting a specific focus on
answering the questions below:

• What kind of problems is UAF applicable for solving?

• Is UAF a replacement for NATO architecture framework (NAF)?
• How is UAF related to model-based systems engineering (MBSE)?

These and many more questions are answered in this paper by presenting real-world UAF application
examples of architecting systems of systems in various industry domains.

Introduction
Applying the Unified Architecture Framework, using an MBSE approach moves the architecture
modelling effort to one that is an integral part of SE [Hause et al. 2016]. This helps the systems
integrator develop interoperable systems with traceability to requirements and across views, using
one integrated architecture model that enables impact analysis, gap analysis, trade studies,
simulations, and engineering analysis [Morkevicius et al. 2017a]. Moreover, the scope of UAF is
expanded beyond defense architectures. It is genericized to be applicable to architecting systems of
systems of any domain. One of the mandatory requirements for UAF was “Architecture Modeling
Support for Defense, Industry, and Government Organizations”. As a response to this requirement,
Page 1 of 8

Copyright © 2018 by Aurelijus Morkevicius. Published and used by INCOSE UK Ltd and INCOSE with permission.
UAF version 1.0 is industry domain agnostic [OMG 2013]. It is targeted to model systems of systems,
including enterprises and IoT systems.

Why UAF? The paradigm shift from a document-centric systems engineering approach to model-based
systems engineering (MBSE) revealed gaps in the MBSE approach, one of which was that no
standardized methodology was available for SoS. The belief that Systems Modeling Language [OMG
2015] was the ultimate solution turned out to be incorrect. Modelling language by definition provides
syntax and semantics, but not pragmatics. To apply a language such as SysML successfully, various
questions must be answered, including how to structure the model, what views to build, which
artefacts to deliver, and in what sequence. Every company deals with these issues differently.
Organizations not complying with a standardized approach end up having differently structured
models with different sets of views, resulting in loss of the capability to exchange data between
models, loss of the capability to communicate with other teams, overhead in tool customization, and
the need for specific training. Moreover, the models become impossible to integrate and reuse
[Morkevicius et al. 2017a].

UAF
UAF consists of three main components (all UAF components are shown graphically in Figure 1):

• framework – a collection of domains, model kinds, and viewpoints,

• metamodel – a collection of types, tuples, and individuals used to construct views according
to the specific viewpoints,
• profile – SysML based implementation of the metamodel to apply model-based systems
engineering principles and best practices while building the views.

Two supplementary components are: (i) a traceability guide to other existing EAFs and UPDM; and (ii)
an example model based on a search & rescue case study.

Figure 1 – UAF Framework Components

Page 2 of 8
Framework

The Grid format (Figure 2) is the best to describe the framework component of the UAF. It is organized
into rows and columns, where rows are Domains and columns are Model Kinds. The intersection of a
row and column is called a Viewpoint. A UAF grid summarizes all viewpoints available in existing AFs.
It serves as a foundation for building domain-specific frameworks by selecting only the viewpoints
required for a specific context.
Taxonomy Structure Connectivity Processes States Interaction Information Parameters Constraints Roadmap Traceability
Tx Sr Cn Pr St Scenarios Is If Pm Ct Rm Tr

Metadata
Metadata Taxonomy Architecture Metadata Metadata Metadata Metadata
Viewpoints a Connectivity Processes a - - Constraints
a
Traceability
Md Md-Tx
Md-Sr Md-Cn Md-Pr Md-Ct Md-Tr

Strategic
Strategic Strategic Strategic Deployment, Strategic
Strategic Strategic Structure Strategic States
Taxonomy Connectivity - - Constraints St-Rm Traceability
St St-Sr St-St
St-Tx St-Cn St-Ct St-Tr
Strategic Phasing
St-Rm

Operational
Operational Operational Operational Operational Operational Operational Interaction Operational Operational
Taxonomy Structure Connectivity Processes States Constraints - Traceability
0p Scenarios
Op-Tx Op-Sr Op-Cn Op-Pr Op-St Op-Ct Op-Tr
Op-Is

Service
Services Service Service Structure Service Service Service States Interaction Service Service Roadmap Service
Taxonomy Sv-Sr Connectivity Processes Sv-St Constraints Sv-Rm Traceability
Sv Scenarios Conceptual Data Environment
Sv-Tx Sv-Cn Sv-Pr Sv-Ct Sv-Tr
Sv-Is Model, Pm-En
Personnel
Availability,
Personnel Competence,
Personnel Personnel Personnel Personnel Personnel Personnel States Interaction Drivers, Personnel
Taxonomy Structure Connectivity Processes Personnel Evolution, Traceability
Pr Pr-St Scenarios Performance
Pr-Tx Pr-Sr Pr-Cn Pr-Pr Logical Data Model, Pr-Tr
Pr-Is Pr-Ct Personnel Forecast
Pr-Rm

Resource
Resources Resource Resource Resource Resource Resource Resource evolution, Resource
Resource States Interaction
Taxonomy Structure Connectivity Processes Constraints Resource forecast Traceability
Rs Rs-St Scenarios Measurements
Rs-Tx Rs-Sr Rs-Cn Rs-Pr Physical Data Model Rs-Ct Rs-Rm Rs-Tr
Rs-Is Pm-Me

Security Security Security Security Security

Security Security Structure Processes Constraints
Taxonomy Connectivity - - - Traceability
Sc Sc-Sr
Sc-Tx Sc-Cn Sc-Pr Sc-Ct Sc-Tr

Project Project Project Project

Projects Project Structure Project Roadmap
Taxonomy Connectivity Processes - - - Traceability
Pj Pj-Sr Pj-Rm
Pj-Tx Pj-Cn Pj-Pr Pj-Tr

Standards Standard Standards Standards

Taxonomy Structure Standards Roadmap Traceability
- - - - -
Sd Sd-Rm
Sd-Tx Sd-Sr Sd-Tr

Actuals Actual Parametric

Actual Resources
Resources
Resources Structure, Simulation b Execution/ - -
Connectivity, b
Ar Ar-Sr Evaluation
Ar-Cn

Dictionary * Dc
Summary & Overview Sm-Ov
Requirements Req

Figure 2 – UAF Grid

UAF consists of 13 Domains [OMG 2017]:

• Metadata - captures meta-data relevant to the entire architecture, e.g. principles, metamodel
extensions, views to be built, processes of developing architecture, etc.
• Strategic - describes capability taxonomy, composition, dependencies and evolution.
• Operational - describes the requirements, operational behaviour, structure, and exchanges
required to support (exhibit) capabilities.
• Services - shows Service Specifications and required and provided service levels of these
specifications required to exhibit a Capability or to support an Operational Activity.
• Personnel - enables an understanding of the human role in systems/enterprise architectures.
It provides a basis for decisions by stakeholders by providing a structured linkage from the
engineering community to the manpower, personnel, training, and human factors
communities.
• Resources - captures a solution architecture consisting of resources, e.g. organizational,
software, artefacts, capability configurations, natural resources that implement the
operational requirements.
• Security - illustrates the security assets, security constraints, security controls, families, and
measures required to address specific security concerns.

Page 3 of 8
 • Projects - describes projects and project milestones, how those projects deliver capabilities,
the organizations contributing to the projects and dependencies between projects.
• Standards - shows the technical, operational, and business Standards applicable to the
architecture.
• Actual Resources - illustrates the expected or achieved individual resource configurations and
actual relationships between them.
• Dictionary - provides definitions for all elements in the architecture.
• Summary and overview - provides executive-level summary information in a consistent form
that allows quick reference and comparison between architectural descriptions.
• Requirements - used to represent requirements, their properties, and relationships (trace,
verify, satisfy, refine) to each other and to UAF architectural elements of different domains.

The intersection between rows and columns is called the viewpoint or view specification. It is a
method to build a view. A View is an instance of a viewpoint [ISO 2011]. Every view can be expressed
in different presentation artefacts, such as diagrams, tables, matrixes, graphs, charts, etc. UAF
specification provides recommendations on presentation artefacts for every viewpoint.
Recommended presentation artefacts are described in more detail in the Modelling Language section
of the paper.

Metamodel

A UAF Domain metamodel (DMM) depicted in Figure 3 is organized according to viewpoints. Thus, it
is easy to understand which elements (including types, individuals, and tuples) can be used to build a
specific view. The categorization of elements into types, individuals, and tuples is taken from IDEAS.
In general, a UAF metamodel is a simplified version of complex 4D IDEAS ontology [IDEAS 2012].
Although it is simplified, it is still powerful compared to the majority of existing enterprise modeling
languages and methodologies.

Enterprise vision
Mitigates
Is a vision Depends on/ Affects resource and
Is a goal
of
for specializes/ Security control Risk operational elements
contains
Actual enterprise
Enterprise goal Project
phase
Exhibits actual Requirement
Provides status
Contains Is part of Links to all
for
elements
Capability
Actual Project
Maps to milestone Standard
Defines Owned
Operational by Data model Owned
Maps to
Operational port by Links to all
interface
elements
Operational
Has exchanges Information
Data element element Measurement
Performs
Exhibits Links to all
Operational agent elements
Operational Contains Contains
activity Operational Operational Resource
performer architecture Resource port
interface
Implements Defines
Known resource
Consumes Has Resource
Contains
exchanges

Service Classified by
Actual resource
specification Specializes Resource performer
/ contains Fielded
Organisational capability
Known Resource architecture
Implements resource
Has Performs resource
Actual organisational resource
Security Responsibility
System Capability configuration
Function enclave
Service port Actual Actual
Person Actual post
person otganisation
Physical resource Organization
Specializes/
Defines Resource Natural
Software Post contains
artefact resource

implements

Service interface

Figure 3 – UAF Metamodel

Page 4 of 8
A UAF metamodel uses color coding to distinguish between tuples, types, abstract types, and
individuals. It is very helpful when reading the metamodel. The image above, however, depicts a
different color coding. Element colors reflect row color in the grid. It simplifies the look of the
metamodel, showing the main concepts and relationships defined in the UAF metamodel.

Profile

Profile, in the context of UML, defines limited extensions to a reference metamodel with the purpose
of adapting the metamodel to a specific platform or domain. A UAF profile defines UML extensions to
support a UAF metamodel. It is also dependent on a SysML profile, which is another extension to UML.
Dependencies to SysML are in the form of inheritance relationships. The purpose of this inheritance
is to inherit SysML graphical notation, and engineering analysis techniques applicable to SysML (e.g.
parametric analysis).

A UAF Profile (UAFP) is organized in accordance with viewpoints, exactly the same as a UAF
metamodel. With this organization, it is easy to understand what elements can be used to build a
specific view. In addition to the metamodel, every profile element extends a specific UML metaclass
and inherits from a specific SysML stereotype (e.g. Operational Performer extends a UML Class and
inherits from a SysML block). A UAF profile also defines meta-constraints. For example, a Maps To
capability relationship can only connect Activity to Capability.

UAF metamodel implementation as a UML profile provides several key benefits including:

• fUML standard can be used to execute UAF architectures

• SysML parametrics can be used to perform analytical engineering studies on UAF models
• UAF provides seamless integration with SysML, UML, and other OMG standard profiles to
ensure traceability from high level systems of systems model to systems and software
engineering models
• UAF is easily extendable

The key points listed above emphasize that the UAF profile is the recommended standard-based
implementation of a UAF metamodel.

Modeling Language

A UAF metamodel does not define graphical notation. Systems Modeling Language (SysML) is the
standard method of representing UAF metamodel elements graphically. SysML defines 9 diagram
types, as well as notation for all SysML elements [OMG 2015]. Because the UAF profile is an extension
of SysML, it inherits the same notation. For example, UAF Capability is inherited from SysML block,
meaning that UAF Capability inherits SysML block notation.

UAF specification provides guidance for which SysML diagram type should be used to create a specific
UAF view. It is important to note that it is only a guide. Other modeling languages (such as UML, BPMN,
etc.) can also be used. In addition to SysML diagrams, it is recommended that some UAF views be
represented in a tabular, matrix, or chart format.

UAFP, as an extension to SysML and UML, supports standard OMG interchange formats (XMI standard
for model data interchange and DDI for diagram interchange). Additionally, UAF supports the concepts

Page 5 of 8
of views and viewpoints, where a viewpoint specifies a method for building a specific view from model
data dynamically.

Application Use Cases

There are already numerous applications of UAF. The defense industry is most commonly thought of;
however, there are UAF applications in other industries that are well worth looking at.

The National environmental satellite, data, and information service (NESDIS) ground enterprise and
NASA’s Joint Polar Satellite Systems (JPSS) ground project are both successful systems of systems
architecture examples by Jeffries Technology Solutions, Inc. Both were architected in DoDAF using a
UPDM metamodel (the predecessor of UAFP). Lessons learned are that the MBSE approach reduces
rework, increases accuracy, and enables robust and informed decision-making [Barnes 2018].

The development of large, complex, heavy construction equipment can be difficult, time consuming
and expensive, even greater if the goal is to design a complete site solution. This example is taken
from a real, ongoing project called Electric Site, carried out by Volvo Construction Equipment. The aim
is to electrify a transport stage in a quarry, from excavation to primary crushing and transport to
secondary crushing. This will reduce the CO2 by 95% and the total cost of operation by 25%. [Kihlström
2018] and [Sjöberg 2017] describe how a UAF model can be used to significantly influence continued
system engineering efforts, as well as the software architecture for the application development. The
enterprise architecture model has been developed specifically to ensure overall management of the
site.

Other publicly available case studies are the Submarine Warfare Federated Tactical Systems (SWFTS)
project by Lockheed Martin [Mitchell 2010], Airbus Helicopters [Wirtz 2017], UAF for IoT architectures
[Morkevicius et al. 2017b].

UAF vs. NAF vs. DoDAF vs. TOGAF vs. Archimate

A UAF framework is an alternative to NAF and DoDAF. This statement, however, concerns the UAF
framework component only. Other components supplement both DoDAF and NAF. For example, a
UAF metamodel and profile are compatible with both NAF and DoDAF. Depending on the tools used
to create DoDAF or NAF views, either the UAF metamodel or the profile can be used. Using the same
metamodel for creating UAF, NAF, and DoDAF views enables interoperability between the
frameworks. It is up to the tool vendor to provide a conversion mechanism to convert DoDAF OV-2 to
NAF L2 or to UAF Operational Structure. The UAF naming scheme is much more intuitive than the ones
provided by other frameworks. Because of this there are examples where UAF is used to develop
architecture and the architecture is converted to DoDAF just before delivery.

UAF compatibility with TOGAF is different and is worth discussing separately. A UAF metamodel is an
alternative to a TOGAF content metamodel. This means TOGAF architectures can be simply created
using a UAF metamodel following the TOGAF architecture development method (ADM). The TOGAF
ADM can also be combined with a UAF metamodel to build UAF views. This combination compensates
for a lack of UAF architecture development method.

Page 6 of 8
The UAF metamodel and Archimate are both named by the NATO 3C board as the official metamodels
to create NAF views [Ristani 2018]. On one hand, they are competing alternatives. On the other hand,
NATO requires OMG and the Open Group to find a way to support interoperability between the two.
Initial ideas were developed in the OMG UAF group on how Archimate could work with UAF, i.e. using
Archimate to develop high-level capability architectures and UAF to create rich operational and
resource architectures.

Conclusion
UAF is the collection of best practices used in systems, systems of systems, and enterprise engineering
for more than 30 years. Moreover, UAF is applicable to any domain. Additionally, is still the best choice
to build DoDAF, NAF, and MODAF architectures.

A UAFP profile is a formal way of building UAF models. This formal background allows users to build
precise, executable architectures, perform automated trade off analysis, run what-if scenarios, verify
requirements, and add traceability to the systems and software models.

The applications of UAF, UAFP, and its predecessor UPDM has been proven in practical applications in
different domains. There are multiple publicly-available case studies that prove UAF is the number
one choice to build mature and rich systems of systems architectures.

References
[Barnes 2018] ‘Utilizing MBSE to Modularly Architect the NESDIS Ground Enterprise’, Patrick
Barnes, 14th Annual Symposium on New Generation Operational
Environmental Satellite Systems, 2018, [Available from http://jetsi.com/wp-
content/uploads/2018/01/AMS2018Poster_Final.pdf]

[Bleakley et al. 2016] ‘Transitioning from UPDM to the Unified Architecture Framework (UAF)’,
Graham Bleakley and Aurelijus Morkevicius, Integrated Enterprise
Architecture Presentation, 2016, London

[Hause et al. 2016] ‘Technology Update on the Unified Architecture Framework (UAF)’, Matthew
Hause, Graham Bleakley, and Aurelijus Morkevicius, INCOSE International
Symposium, 26: 1145–1160, 2016

[Hause et al. 2016] ‘Technology Update on the Unified Architecture Framework (UAF)’, Matthew
Hause, Graham Bleakley, and Aurelijus Morkevicius, INSIGHT, 20: 71-78, 2017

[IDEAS 2007] ‘The IDEAS Model’, IDEAS Group, 2007, [Available from
http://www.ideasgroup.org/foundation/ ; accessed May 2018]

[ISO 2011] ‘Systems and software engineering — Architecture description’, International

Organization for Standardization, ISO, 2011 [accessed May 2018]

[Kihlström 2018] ‘How to use Architecture frameworks to speed up systems development’,

Simon Perry, UAF & MBSE tutorials, Reston, 2018, [Available from
https://www.omg.org/cgi-bin/doc?omg/2018-03-11.pdf; accessed May 2018]

Page 7 of 8
[Mitchell. 2010] ‘Efficient Management of Configurations in the Model-Based System
Development of a Common Submarine Combat System’, Steven W. Mitchell,
AFCEA-GMU Critical Issues in C4I Symposium, 2010

[Morkevicius et al. 2017a] ‘MBSE Grid: A Simplified SysML‐Based Approach for Modeling
Complex Systems’, Aurelijus Morkevicius, Aiste Aleksandraviciene, Donatas
Mazeika, Lina Bisikirskiene, and Zilvinas Strolia, INCOSE International
Symposium, 27: 136-150, 2017

[Morkevicius et al. 2017b] ‘Using a systems of systems modeling approach for developing
Industrial Internet of Things applications’, Aurelijus Morkevicius, Lina
Bisikirskiene, and Graham Bleakley, 12th System of Systems Engineering
Conference (SoSE), Waikoloa, HI: pp. 1-6

[Ristani 2018] ‘A NATO ACaT Perspective on the Use of Architecture and Standards’,
Konstandin Ristani, UAF & MBSE Summit, Reston, 2018, [Available from
https://www.omg.org/cgi-bin/doc?omg/2018-03-03.pdf; accessed May 2018]

[OMG 2015] ‘OMG Systems Modelling Language, Version 1.4’, Object Management Group,
2015 [Available from http://www.omg.org/spec/SysML/1.4; accessed May
2018]

[OMG 2017] ‘Unified Architecture Framework (UAF) 1.0’, Object Management Group, 2017
[Available from https://www.omg.org/spec/UAF/1.0/, accessed May 2018]

[OMG 2009] ‘Unified Profile for the Department of Defense Architecture Framework
(DoDAF) and the Ministry of Defence Architecture Framework (MODAF)’,
Object Management Group, 2009 [Available from
http://www.omg.org/spec/UPDM/, accessed May 2018]

[Okon 2012] ‘Moving Towards an Unified Architecture and the US Government Information
Sharing Environment’, Walt Okon, 1105 Enterprise Architecture Conference,
2012

[Sjöberg et al. 2017] ‘An industrial example of using Enterprise Architecture to speed up systems
development’, Peter Sjöberg, Lars‐Olof Kihlström, and Matthew Hause,
INCOSE International Symposium, 27: 401-417

[Wirtz 2017] ‘Introduction of MBSE at Airbus Helicopters’, Jörg Wirtz, UPDM & MBSE
tutorials, Brussels, 2017 [Available from https://www.omg.org/cgi-
bin/doc?c4i/17-06-08.pdf accessed May 2018]

Page 8 of 8