Nato Architecture Framework (NAF) - 4.6 - NATO Meta Model - NSV
NATO System Views (NSV)。
It should be noted that the NMM takes a more general approach than handling of technical systems. The NMM instead considers resources in general, where they can be both technical systems as well as organisational resources. This does not preclude the ability to strictly use these views for technical systems only but instead gives an increased capability when modelling architecture, should this be desired by the user.
NSV-1 System interface description。
System interface description (NSV-1) addresses the composition and interaction of resources. For NMM, NSV-1 incorporates the human elements – Posts, Organisations and Roles. A resource interaction is a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line with possible amplifying information). The data in an NSV-1 can include:
- System
- Organisation Type
- Post Type
- Role
- Capability Configuration
- Physical Asset
- Resource Composition
- Resource Interaction
NSV-1 System interface description。
NSV-1 System interface description。
Only Functional Resources (roles, systems, capability configurations) may interact, and only the following compositions are allowed:
- Physical Asset (whole) to Physical Asset (part) – e.g. a sub-platform or facility
- Physical Asset (whole) to System (part) – e.g. installation
- Physical Asset (whole) to Organisational Resource (part) – e.g. deployment of personnel to facilities or platforms
- Organisation Type (whole) to Organisational Resource (part) – e.g. a suborganisation or post in an organisation
- Organisational Resource (whole) to System (part) – e.g. a person carrying a system
- System (whole) to System (part) – e.g. a sub-system
- Organisational Resource (whole) to Role (part) – e.g. a functional role that a post may have
In addition, the Capability Configuration concept is used as a wrapper to bring together resources to satisfy a Capability.
NSV-1 System interface description。
Functions
Some resources (Systems, Roles & Capability Configurations) can carry out Functions as described in NSV-4 products, and these functions can optionally be overlaid on an NSV-1. Note that the same type (class) of resource may be used in different contexts in a given NSV-1. For this reason, the tracing of functions to resources is specified in context of their usage (see NMM for details).
Interactions in NSV-1
Interactions are only possible between Functional Resources (Systems, Roles & Capability Configurations).
Capability Configurations
A Capability Configuration is a Physical Asset or Organisational Resource configured with Functional Resources (System, Roles, other Capability Configurations) 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). 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.
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-1.2C_System_Interface_Description
NSV-2 Systems communications description。
The NSV-2 View is split into four subviews which define the communications links between systems:
- NSV-2a System Port Specification – defines the ports on each system, and the protocol / hardware stack that is specified or implemented for each of those ports.
- NSV-2b System Port connectivity descriptions – defines the connections between individual ports and shows the protocols and hardware spec used for each connection.
- NSV-2c System Connectivity Clusters – defines the bundles of system to system connections that go to make up a connection between the Physical Assets that host the connected systems (see NSV-1).
- NSV-2d Systems communications quality requirements description – defines the systems that communicate primarily through the radio and uses various portions of the radio spectrum. It can also describe the way in which the spectrum is regulated.
NSV-2 Systems communications description。
NSV-2 Systems communications description。
NSV-2a
The data in an NSV-2a can include:
- System
- System Port
- Protocol
NSV-2b
The data in an NSV-2b can include:
- System
- System Port
- Port Connection
- Protocol
NSV-2c
The data in an NSV-2c can include:
- Physical Asset
- Organisational Resource (Post Type or Organisation Type)
- System
- System Port
- System Port Connection
NSV-2 Systems communications description。
NSV-2d
This view is by and large very similar to NSV-2b. The only additional entity which appears on this view is the entity labelled spectrum allocation. This enable a view to be created where regulated spectrum and bandwidth usage is superimposed on radio connections in between systems. It should especially be noted that networks with a geographical extension is also considered as systems within the NMM.
NSV-3 System to system matrix。
The data in an NSV-3 can include:
- Functional Resources (Systems, Roles, Capability Configurations)
- Resource Interactions
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-3.2C_Systems_to_Systems_Matrix
NSV-4 System Functionality description。
The data in an NSV-4 can include:
- Function
- Functional Resource (system, role, capability configuration)
- Data Element
NSV-5 System function to operational activity traceability matrix。
The data in an NSV-5 can include:
- Function
- Functional Resource
- Operational Activity
NSV-6 Systems data exchange matrix。
- The data in an NSV-6 can include:
- System
- Resource Interaction
- System Port Connector
- Data Element
- Information Exchange (NOV-2)
NSV-6 Systems data exchange matrix。
Note: The term ‘System Data Exchange’ does not refer to one NMM element. A data exchange as described in NSV-6 is a combination of a System Port Connector and the Data Elements that flow across it. Any properties shown in an NSV-6 table will be properties of the System Port Connector.
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-6.2C_Systems_Data_Exchange_Matrix
NSV-7 System quality requirements description。
The data in an NSV-7 can include:
- Functional Resource (system, role, or capability configuration)
- Measurable Property
- Qualitative Property
NSV-8 System evolution description。
The data in an NSV-8 can include:
- Capability Configurations
- Resources that are parts of Capability Configurations
- Project Milestone (reflecting capability delivery)
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-8.2C_Systems_Evolution_Description
NSV-9 Technology forecast。
The data in an NSV-9 can include:
- Resources
- Competences
- Standards
- Forecasts (for the any of the above).
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-9.2C_Technology_Forecast
NSV-10 Systems Rules, Sequence & Timing Description。
NSV-10a
The data in an NSV-10a can include:
- Resource Constraint
NSV-10b
The data in an SV-10b can include:
- Functional Resources
- Resources
- States (associated with a Resource or Function)
- State Transitions (each associated with an event)
NSV-10c
The data in an NSV-10c can include:
- Lifelines (each associated with a Functional Resource or a System Port)
NSV-11 Systems data model。
NAF version 3 contains two different subviews dealing with this:
- Logical data model
- Physical data model
NSV-11a: Logical data model The data in an NSV-11a can include:
- Operational Information Entity
Note that an Operational Information Entity within an NSV-11a may be an Information Element in an NOV-3 or an Activity Flow Object in an NOV-5.
NSV-11b: Physical data model
While the mapping between the logical and physical data models is relatively straightforward, the relationship between the components of each model (e.g. entity types in the logical model versus relational tables in the physical model) is frequently one-to-many or many-to-many. The data in an NSV-11b can include:
- System Data Entity
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-11.2C_System_Data_Model
NSV-12 Service provision。
This view is used to describe how a service is implemented by one or more systems. A particular implementation of a service can be seen as a capability configuration that is associated with this service. By providing this information, a clear connection between a service, as described in the NSOV diagrams, and systems that implement it can be defined.
Nato Architecture Framework (NAF) - 3.5 - NATO Systems View#NSV-12.2C_Service_Provision
NSV metamodel diagrams。
- NSV-1 Systems interface description
NSV metamodel diagrams。
- NSV-2 Systems communications description
NSV metamodel diagrams。
NSV-2a System port specification
NSV metamodel diagrams。
NSV-2b System to system port connectivity
NSV metamodel diagrams。
NSV-2c System connectivity clusters
NSV metamodel diagrams。
NSV-2d Systems communications quality requirements description
NSV-3 Systems to systems matrix。
NSV-4 Systems functionality decription。
NSV-5 Systems function to operational activity traceabilty matrix。
NSV-6 Systems data exchange matrix。
NSV-7 Systems quality requirements description。
NSV-8 Systems evolution description。
NSV-9 Technology forecast。
NSV-10 Systems Rules, Sequence & Timing Description。
NSV-10 Systems Rules, Sequence & Timing Description。
NSV-10a Systems rules model
NSV-10 Systems Rules, Sequence & Timing Description。
NSV-10b Systems state transitions description'
NSV-10 Systems Rules, Sequence & Timing Description。
NSV-10c Systems event trace description
NSV-11 Systems data model。
NSV-11 Systems data model。
NSV-11a Logical data model
NSV-11 Systems data model。
NSV-11b Physical data model
NSV-12 Service provision。
NSV metamodel glossary。
| Element | Definition |
|---|---|
| ActivityToFunctionMapping | Asserts that a <<Function>> (at least in part) performs or assists in the conducting of an <<OperationalActivity>>. |
| CapabilityConfiguration | A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<CapabilityConfiguration>> is a physical asset or organisation configured to provide a capability, and must be guided by [doctrine] which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes. |
| CapabilityRealisation | Asserts that a <<CapabilityConfiguration>> is capable of achieving a <<Capability>>. |
| DataElement | A formalised representation of data which is managed by or exchanged between systems. |
| FieldedCapability | An actual, fully-realised capability. A <<FieldedCapability>> must indicate its configuration <<CapabilityConfiguration>>.
Example: ‘HMS Iron Duke, configured and crewed, operating under the appropriate doctrine’. Note - the <<CapabilityConfiguration>> that this realises would specify a UK Type 23 Frigate, the crew, the weapons systems, etc. |
| Forecast | A statement about the future state of one or more types of system or standard.
Note the forecast is effective for a given period. |
| Function | An activity which is specified in context of the resource (human or machine) that performs it.
Note1: Contrast with <<OperationalActivity>>, where the actor performing the activity is not known (i.e. it is just a logical node). A <<Function>> is implementation-specific. Note2: Should the <<Function>> be specific to one usage of a type of system, then the usageContext is specified by a reference to the composite structure property <<ResourceComposition>> typed by the system. |
| FunctionFlow | An UML::ObjectFlow between <<Function>>s. |
| FunctionProvision | Asserts that a <<FunctionalResource>> provides a <<Function>>. |
| FunctionalResource | A <<Resource>> capable of function.
Note that <<PhysicalAsset>> and OrganisationalResource (<<PostType>>, <<OrganisationType>> are not considered to be <<FunctionalResource>>s. |
| FunctionsUpon | Asserts that a <<Function>> has some effect on a <<DataElement>>. |
| ImplementsDataModel | |
| NodeRealisation | An assertion that a <<CapabilityConfiguration>> provides the functionality specified by an operational node. |
| PhysicalAsset | A <<Resource>> that can host systems and/or people.
Note 1: synonyms for <<PhysicalAsset>>; would be ‘platform’, ‘facility’, or ‘host’. This is the original intent for the ‘SystemsNode’ concept in DoDAF. Note 2: A <<PhysicalAsset>> can contribute to a <<CapabilityConfiguration>>, and is usually configured for that purpose. It may be that a given platform can be configured and manned in many different ways to achieve different capabilities. In these cases, a class should be created for the <<PhysicalAsset>> in general, and this should be abstract. The variants of the asset should be created as concrete classes, specialising from the abstract class. |
| PhysicalDataModel | A <<PhysicalDataModel>> is an implementable specification of a data structure. A <<PhysicalDataModel>> realises a <<LogicalDataModel>>, taking into account implementation restrictions and performance issues whilst still enforcing the constraints, relationships and typing of the logical model. |
| PortType |
A type of <<System>> which is used to provide an interface to which other systems connect. A <<PortType>> may be implemented as a <<SystemPort>>. |
| RadioFrequencyPort | A <<PortType>> which uses radio frequency as its mode of communication. |
| RadioFrequencyPortConnector | A <<SystemPortConnector>> that connects two ports which are typed as <<RadioFrequencyPort>>. |
| Resource | A <<PhysicalAsset>>, <<OrganisationalResource>> or <<FunctionalResource>> that can contribute towards fulfilling a capability. [ABSTRACT] |
| ResourceComposition | A relationship between <<Resource>>s that asserts one resource is part of the other (i.e. composition).
NOTE: Valid <<Resource>> combinations are:
|
| ResourceConstraint | A rule governing the structural or functional aspects of an implementation - this may also include constraints on <<OrganisationalResource>>s that are part of an implementation. |
| ResourceInteraction | An assertion that two <<FunctionalResource>>s interact. Examples: data exchange between systems, conversations between people, people using systems. |
| ResourceInteractionSpecification | A specification of the interactions between aspects of a <<Resource>>s architecture. |
| ResourceLifeLine | A UML::Lifeline that represents a <<ResourceLifelineItem>> that interacts with another <<ResourceLifelineItem>>. |
| ResourceLifelineItem | An element that may be represented as a <<ResourceLifeLine>> in a <<ResourceInteractionSpecification>>. [ABSTRACT] |
| ResourcePartition | A swimlane representing a usage of a <<FunctionalResource>>. |
| ResourceStateMachine | A state transition model which represents the behaviour of a <<Resource>> or <<Function>>. |
| ResourceStateMachineOwner | An item whose behaviour may be represented by a <<ResourceStateMachine>>. [ABSTRACT] |
| ResourceStructureModel | A <<CompositeStructureModel>> that is the container for resources and their interactions. |
| Role | An aspect of a person or organisation that enables them to fulfil a particular function. |
| SubjectOfForecast | Any element that may be subject to a <<Forecast>>. |
| SubjectOfResourceConstraint | Anything that may be constrained by a <<ResourceConstraint>>. |
| System | A coherent combination of physical artefacts, energy and information, assembled for a purpose. |
| SystemPort | An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for <<SystemPort>>s to be typed. |
| SystemPortConnector | Asserts that a connection exists between two ports belonging to parts in a system composite structure model. |
| SystemPortConnectorEnd | The end of a connector between system ports. |
| SystemStructureModel | A <<CompositeStructureModel>> whose parts are <<System>>s. |
| VersionOfConfiguration | Asserts that a <<CapabilityConfiguration>> is a version of a <<WholeLifeConfiguration>>. |
| WholeLifeConfiguration | A set of versions of a <<CapabilityConfiguration>> over time. <<WholeLifeConfiguration>> is used to collect together successive versions of <<CapabilityConfiguration>>s from the first design to the last. |
| Network | A network is a specialisation of system and is used for communication networks that have a geographical extension. |
