System Views (SV) [Physical, Specification or Solution Views]

SV-1 Resource Interaction Specification v1.2

Resource Interaction Specification (SV-1) address the composition and interaction of resources. From MODAF v1.1, SV-1 incorporates the human elements – Posts, Organisations and Roles.

MODAF 1.2 has introduced the Resource Type of an Artefact, which is any physical element. An Artefact can be represented, depending on the context and preference of the user, as a System, Sub-system, Platform, Component or simply a physical item that occupies space and has attributes. In addition, Software has been added as a specific resource type.

Background:

The Resource Interaction Specification (SV-1) links together the operational and systems architecture views by depicting how resources are structured and interact in order to realise the logical architecture specified in an OV-2An SV-1 may represent the realisation of a requirement specified in an OV-2 (i.e. in a to-be architecture), and so there may be many alternative SV suites that could realise the operational requirement. Alternatively, in an as-is architecture, the OV-2 may simply be a simplified, logical representation of the SV-1 to allow communication of key information flows to non-technical stakeholders.

A resource interaction is a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line with with possible amplifying information). The SV-1 depicts all interactions between resources that are of interest to the architect. Note that interactions between systems may be further specified in detail in SV-2 and SV-6.

Sub-resource assemblies may be identified in SV-1 to any level (i.e. depth) of decomposition the architect sees fit. SV-1 may also identify the Physical Asset (e.g. Platforms) at which resources are deployed, and optionally overlay Operational Nodes that utilise those resources. In many cases, an operational node depicted in an OV-2 product may well be the logical representation of the resource that is shown in SV-1.

The Capability Configuration concept is used as a wrapper to bring together resources to satisfy a Capability.

Usage:

Data objects:

The data in an SV-1 can include:



Relationships Between Key Data Objects (Simplified from M3)

Representation:



SV-1 Example for Blogging


SV-1 Example (UML Composite Structure Model)

Resources in MODAF 1.2

MODAF In MODAF 1.2, the way resources are modelled has changed. The changes appear subtle, but are significant in terms of enabling re-use of architectural data. The main change is the introduction of a strong distinction between what a resource is, and how it is used in a particular architecture. In terms of the intrinsic type of resource, the following are possible:

Once defined, the intrinsic resource types can be re-used from architecture to architecture – it is expected that the most commonly re-used elements would be Physical Architectures and Capability Configurations. The following are the ways in which the resource types can be used:

These different ways to employ the same type of resource allow greater re-use. For example, a type of warship doesn’t need to be defined twice, once as a platform and once as a system. It is specified once as an artefact and then can be used with the appropriate context in multiple architectures.

Detailed Product Description:

In MODAF, SV-1 is used in two complementary ways:

An SV-1 can be used simply to depict systems and sub-systems and identify the interfaces between them, but this rarely adds more than can be shown in an SV-2 product. The real benefit of an SV-1 is its ability to show the human aspects of an architecture, and how these interact with systems. In addition, MODAF has the concept of a Capability Configuration which is used to gather together systems, assets and people into a configuration which can meet a specific capability.


SV-1 Example Showing Capability Configuration

The physical resouces contributing to a capability must either be an organisational resource or a physical asset, i.e. a system cannot contribute alone (it must be hosted on a physical asset used by an organisational resource of both). Organisational aspects can now be shown on SV-1 (e.g. who uses a system).

A primary purpose of an SV-1 View Product is to show resource structure – i.e. identify the primary sub-systems, posts and roles and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.

Resource structures may be identified in SV-1 to any level (i.e. depth) of decomposition the architect sees fit. MODAF does not specifically use terms like ‘sub-system’ and ‘component’ as these terms often denote a position relative to a structural hierarchy.

The term System in the framework is used to denote a System of Systems (SoS), nomenclatured system, or a subsystem. Any system may combine hardware and software or these can be treated as separate (sub) systems. In MODAF, the term System specifically excludes human factors. Although there may be debate about whether or not humans constitute systems, there was a requirement for a clear distinction in MODAF. Should an architect wish to describe a system which has human elements, then Capability Configuration should be used to “wrap” the human and system elements together.

An SV-1 can optionally be adorned with nodes originally specified in OV-2. In this way, traceability can be established from the logical OV structure to the physical SV structure.



SV-1 Example with elements traced back to logical nodes

If possible, an SV-1 will show resources and interfaces for the entire Architecture on the same diagram. If a single SV-1 is not possible, the resource of interest should be decomposed into multiple SV-1 products.

Functions

MODAF 1.1 made a distinction between resources that could carry out functions (as defined in SV-4) and those that could not. A simplified model has been adopted in version 1.2, where any resource is allowed to have functions.

These functions can optionally be overlaid on an SV-1. In a sense SV-1 and SV-4 provide complementary representations (structure and function). Either could be modelled first, but usually an iterative approach is used to model these together gradually building up the level of detail in the system description. Note that the same type (class) of resource may be used in different contexts in a given SV-1. For this reason, the tracing of functions to resources is specified in context of their usage (see MODAF Meta Model for details).

Interactions in SV-1

In addition to depicting Resources and their structure, SV-1 addresses interaction relationships between resources. An interaction, as depicted in SV-1, is an indicator that information passes between one resource and the other. In the case of systems, this can be expanded into further detail in SV-2b.

In MODAF 1.1, interactions were only possible between Functional Resources (Systems, Roles & Capability Configurations). MODAF 1.2 states that any resource becomes functional if there is a function associated with it. Therefore any Resource can interact.

Interactions provide a specification for how the exchanges specified in OV-2 needlines are realised. A single Needline shown in the OV-2 may translate into multiple interactions.

The actual implementation of an interaction may take more than one form (e.g. multiple physical links). Details of the physical links and communications networks that implement the interfaces are documented in SV-2. Resource Interactions are summarised in a Resource Interactions Matrix (SV-3).

The functions performed by the resources are specified in an SV-4 Resource Functionality Description, but may optionally be overlaid on the Resources in an SV-1.

SV-1 in Solution Architecture

A key feature in MODAF is the ability to represent entities that are intermediate between operational capabilities and equipment-based systems. These are Capability Configurations. To fully satisfy the Capability, they should also account for all of the lines of development.

A Capability Configuration is a combination of organisational resources (with their competencies) and equipment that combine to provide a capability. A Capability Configuration is a combination of Artifacts (be they termed Systems or Platforms) or Organisational Resource configured with other Resources (System, Roles, other Capability Configurations, Software) to provide a capability. A physical resource contributing to a capability must either be an organisational resource or a physical asset, i.e. a system cannot contribute alone (it must be hosted on a physical asset or used by an organisational resource or both).

Capability Configurations fulfil the operational capability needs and are usually defined to fulfil the requirements associated with Nodes (see OV-2). The article on system requirements in MODAF provides more detail.

The following example illustrates the relationship between Capability Configuration and Nodes.



Capability Configuration Tracing to OV-2 Node

Use of Capability Configurations allows architects to include more of the Defence Lines of Development than just systems and platforms.

A Fielded Capability is a particular instance of a Capability Configuration. For example, a Capability Configuration may be a Type 45 Warship configured for an Anti-Air role, of which HMS Daring will be a Fielded Capability. Fielded Capabilities should be used only when one specific instance is possible.

Trade Analysis

An Operational View (OV) suite may specify a set of requirements – either as a specific operational plan, or a scenario for procurement. As OV-2 and OV-5 specify the logical structure and behaviour, SV-1 and SV-4 specify the physical structure and behaviour (to the level of detail required by the architectural stakeholders). This separation of logical and physical presents an opportunity for carrying out architectural trade studies in MODAF.



Trading off Alternative SV Specifications for and OV Requirement

The structural and behavioural views in the OVs and SVs allow architects and stakeholders to quickly ascertain which functions are carried out by humans and non-human systems for each alternative specification and so carry out trade analysis based on risk, cost, reliability, etc.

Page version 1.2, dated 20th June 2008

Top of Page