Nato Architecture Framework (NAF) - 4.4 - NATO Meta Model - NOV

From Training Material
Jump to navigation Jump to search


title
NAF - Part 4.4 - NATO Meta Model - NOV
author
Bernard Szlachta (NobleProg Ltd)

NATO Operational View (NOV)。

The NATO Operational View describes the tasks and activities, operational elements, and information exchanges required to conduct operations.

NOV-1 High level operational concept description

An NOV-1 is typically just a graphic. The data to be included in an NOV-1 can be any business objects of interest, including:

  • Operational Nodes i.e. Headquarters
  • Systems i.e. aircraft
  • Organisations
  • Information Flows
  • Environmental context objects i.e. rivers, hills

The data in an NOV-1 can also include:

  • Metrics associated with performance associated with specific concepts within

the scenario specified within the NOV-1

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-1.2C_High-Level_Operational_Concept_Description


NOV-2 Operational node relationship description。

  • The data in an NOV-2 can include:
    • Nodes (often known as ‘Operational Nodes’)
    • Needlines (bundles of information exchanges)
    • Node Connections (flows of materiel, people or energy)
    • Operational Activities
    • Locations

Relationship between NOV-2 Key Data Objects - simplified from NMM.png

NOV-2 Operational node relationship description。

Needlines
  • A Needline documents the exchange (required or actual) of information between Nodes. A needline is a conduit for one or more information exchanges – i.e. it represents a logical bundle of information flows. The Needline does not indicate how the information transfer is implemented. For example, if information is produced at Node A, is simply routed through Node B, and is used at Node C, then Node B would not be shown on the NOV-2 diagram – the Needline would go from Node A to Node C. NOV-2 is not a communications link or communications network diagram but a high-level definition of the logical requirement for information exchange. See NSV-1 and NSV-2 for further discussion.
  • Because needline identifiers are often needed to provide a trace reference for information exchange requirements (see NOV-3), a combined approach, with numerical and text labels, can be used.
  • There may be several Needlines (in the same direction) from one Node to another. This may occur because some Needlines are only relevant to certain scenarios, missions or mission phases. In this case, when producing the NOV-2 for the specific case, a subset of all of the Needlines will be displayed.

NOV-2 Operational node relationship description。

Needlines
  • There is a one-to-many relationship from Needlines to information exchanges (e.g. a single Needline in NOV-2 represents multiple individual information exchanges). The mapping of the exchanges to the Needlines of NOV-2 occurs in the Operational Information Exchange Matrix (NOV-3). For example, NOV-2 may list ‘Situation Report’ as a descriptive name for a Needline between two Operational Nodes. In this case, the Needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the ‘Situation Report’ Needline. The identity of the individual elements and their attributes are documented in NOV-3.
  • In the NMM, Node extends UML Class, and NOV-2 is represented as a composite structure model. It therefore may be possible to use a particular Node class in more than one context. For this reason, Needlines associated with a pair of Nodes may be context-specific. This is also the case for Operational Activities, which may be only appropriate in certain contexts.

NOV-2 Operational node relationship description。

Flows of People, Materiel and Energy
  • In addition to Needlines, Node Connectors can be used to overlay contextual information about how the Nodes interact via physical flows.
  • This is achieved by overlaying the Node Connectors on the diagram using a notation that is clearly distinct from Needlines (which only represent the requirement to exchange information between Nodes).
  • These physically-based relationships between Nodes are referred to in NMM as NodeConnectors (based on the UML Connector concept which does not have a physical connotation).

Exercises。

  • Match the model elements to the metamodel

NOV-2 Example ISTAR execise.png


[Nato_Architecture_Framework_(NAF)_-_3_of_5_-_Views#NOV-2.2C_Operational_Node_Connectivity_Description]]

NOV-3 Operational information Exchange matrix。

  • The data in an NOV-3 can include:
    • Information Exchanges (each associated with a Needline)
    • Information Elements (each carried by one or more Information Exchange)

Relationship between NOV-3 Key Data Objects - simplified from NMM.png

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-3.2C_Operational_Information_Requirements

NOV-4 Organisational relationships chart。

  • The data in an NOV-4 can include:
    • Organisation Types
    • Resource Composition relationships
    • Resource Interaction relationships
    • Post Types
    • Roles
    • Actual Posts and Organisations
    • Competences

Relationship between NOV-4 Key Data Objects - simplified from NMM.png

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-4.2C_Organisational_Relationship_Chart

NOV-5 Operational activity model。

The data in an NOV-5 can include:

  • Operational Activities
  • Standard Operational Activities (originating in NCV-6)
  • Operational Activity Flow Objects
  • Swimlanes (each associated with a Node)

Relationship between NOV-5 Key Data Objects - simplified from NMM.png

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-5.2C_Operational_Activity_Model

NOV-6 Operational activity sequence and timing description。

Relationship between NOV-6 Key Data Objects - simplified from NMM.png

NOV-6 Operational activity sequence and timing description。

NOV-6a

NOV-6a can be used for:

  • Definition of doctrinally correct operational procedures
  • Definition of business rules
  • Identification of operational constraints

The data in an NOV-6a can include:

  • Operational Constraints

NOV-6b

The data in an NOV-6b can include:

  • States (each associated with a Mission, Node or Operational Activity)
  • State Transitions (each associated with an event)

NOV-6c

The data in an NOV-6c can include:

  • Lifelines (each associated with a Node)

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-6.2C_Operational_Activity_Sequence_and_Timing_Description

NOV-7 Conceptual information model。

An information model is a representation of a domain object model according to its information aspect. In other words, it is a model of the information about the concepts in the universe of discourse, relevant to the architecture effort. E.g. if the operational domain recognizes the existence of a concept called ‘weapons platform’, then the information model would contain information objects that reflect what we want to know about weapons platforms and what we want to communicate about weapons platforms to others. As such, the information model is inherently of a conceptual nature (i.e. we could dispense with the word ‘conceptual’ in ‘conceptual information model’). Conceptual information models address the information aspect of the universe of discourse. They are not intended to reflect data storage solutions.

Nato Architecture Framework (NAF) - 3.3 - NATO Operational View#NOV-7.2C_Information_Model


NOV metamodel diagrams。

NOV-1 High level operational concept description

NOV-1 High level operational concept description.png

NOV metamodel diagrams。

NOV-2 Operational Node Connectivity description

NOV-2 Operational Node Connectivity description.png

NOV metamodel diagrams。

NOV-3 Operational information requirements

NOV-3 Operational information requirements.png

NOV metamodel diagrams。

NOV-4 Organisational relationships chart Typical

NOV-4 Organisational relationships chart Typical.png

Exercise。

NOV-4 Example (Typical, Generic) exercise.png

NOV-4 Organisational relationships chart Actual。

NOV-4 Organisational relationships chart Actual.png


NOV-5 Operational activity model。

NOV-5 Operational activity model.png


NOV-6 Operational activity Sequence and timing description。

NOV-6 Operational activity Sequence and timing description.png

NOV-6 Operational activity Sequence and timing description。

NOV-6a Operational rules model

NOV-6a Operational rules model.png

NOV-6 Operational activity Sequence and timing description。

NOV-6b Operational state transition descriptions

NOV-6b Operational state transition descriptions.png

NOV-6 Operational activity Sequence and timing description。

NOV-6c Operational event-trace descriptions

NOV-6c Operational event-trace descriptions.png


NOV-7 Information model。

NOV-7 Information model.png

NOV metamodel glossary。

NOV metamodel glossary
Element Definition
ActivityComposition An assertion that the parent activity has the child as a part - i.e. the child activity is conducted as part of conducting the parent activity.

Note: Unfortunately, UML offers two ways to do this; by composite class properties (i.e. this stereotype) and by UML::CallBehaviourAction. To prevent ambiguity, this metamodel forces both approaches to be used in parallel (SysML takes the same approach). Any <<ActivityComposition>> must be accompanied by a corresponding <<OperationalActivityAction>>. Hopefully, a future version of UML may be more coherent in this department, and this duplication can be removed.

ActivitySubject Anything that is acted upon by an <<OperationalActivity>>.
ActsUpon Asserts that something (subject) is acted upon by an <<OperationalActivity>> (activity).
ActualCompetence Asserts that an <<ActualOrganisationalResource>> actually has a <<Competence>>.
ActualLocation A location anywhere on the earth. The means of describing the location is a string (locationDescription). The information contained in that string is governed by the taxonomy reference - e.g. if the <<ActualLocation>> is a GPS reference, the string will contain the GPS coordinates.
ActualOrganisation An actual specific organisation, an instance of an organisation class - e.g. ‘The US Department of Defense’
ActualOrganisationRelationship A relationship between two actual specific organisations or parts of an organisation. Note1: the typical organisation relationship which is realised by the <<ActualOrganisationRelationship>> is referred to via the typicalRelationship attribute.
ActualOrganisationalResource An instance of either an actual organisation or an actual post. [ABSTRACT]
ActualOrganisationComposition Relates an actual specific organisation to an actual specific organisational resource that fulfils a role in that organisation.
ActualPost An actual, specific post, an instance of a <<PostType>> class - e.g. ‘President of the United States of America’
ArbitraryConnection Represents a visual indication of connection used in high level operational concept diagrams. The connections are purely indicative and cannot be related to any architectural semantics.
CapabilityForNode An assertion that a <<Node>> is required to have a <<Capability>>.
Competence A specific set of abilities defined by knowledge, skills and attitude.
CompetenceForRole Asserts that an <<Role>> requires a <<Competence>>.
ConceptDescription A textual representation of a <<HighLevelOperationalConcept>>.
ConceptItem An item which may feature in a high level operational concept. [ABSTRACT]
HighLevelOperationalConcept A generalized model for operations.

Note: a background image may be associated with the HLOC, which is referred to by the backgroundImageURL attribute. Scaling information is also provided about the image, so that when an <<ItemInConcept>> is shown in the diagram, it can be properly located and scaled. No units are specified, but the same length unit shall be used throughout a single product.

InformationElement A formalized representation of information.
InformationExchange A specification of the information that is to be exchanged. An <<InformationExchange>> must have a unique identifier.

Note: additional information about the requirements for the InformationExchange may be provided by the requirementText attribute.

InformationExchangeMessage A message representing the exchange of information defined by an <<InformationExchange>>.
ItemInConcept A relationship which asserts that a ConceptItem forms part of the high level operational concept .
LocationType A general specification of the surroundings / scenario in which an operation may take place. Examples would be: ‘desert’, ‘arctic’, ‘at sea’, etc.
LogicalDataModel A <<LogicalDataModel>> is a specification of business information requirements as a formal data structure, where relationships and classes (entities) are used to specify the logic which underpins the information.
Mission A purpose to which a person, organisation or autonomous system is tasked
Needline A relationship specifying the need to exchange information between nodes, uniquely identified in context of the product by its needlineNumber.

Note: The needline does not indicate how the transfer is implemented.

Node A logical entity that performs operational activities. Note: nodes are specified independently of any physical realisation.
NodeAssemblyUsage Used to link a parent <<Node>> to its sub-nodes.

Note: Only <<NodeAssemblyUsage>> may be used to represent a node-subnode relationship.

NodeConnectionEnd The end of a connector between nodes - i.e. for <<Needline>> and <<NodeConnector>>.
NodeConnector Asserts that a physical flow exists or is required between <<Node>>s (e.g. flows of people, materiel, or energy).
NodeEnvironment A specification of the <<Environment>> in which the node operates or is required to operate.
NodeHasBehaviour Asserts that an <<OperationalActivity>> is conducted at a <<Node>>. Should the same type of node be used in different contexts in the architecture, and the activity is conducted under only one of the contexts, that context is provided by the [nodeUsageContext] property.
NodeInProblemDomain Asserts that a <<Node>> is within a <<ProblemDomain>>.
NodeRelationshipDescription A CompositeStructureModel whose parts are either <<Node>>s or <<ProblemDomains>>s.
OpActivityInputPin A port for flows that feed into an activity.
OpActivityOutputPin A port for flows that leave an activity.
OperationalActivity A logical process, specified independently of how the process is carried out. Note: an <<OperationalActivity>> may only be carried out by a logical <<Node>>.
OperationalActivityAction Used to relate an <<OperationalActivity>> to its sub-activities.

Note1: An <<OperationalActivityAction>> will be created for every <<OperationalActivity>> to provide a way to manage sub-activities, and to allow flows between activities.

Note2: See also <<ActivityComposition>>.

Note3: Also provides a means for attaching information (properties) to an activity.

OperationalActivityFlow A flow of information, energy or materiel from one activity to another.
OperationalConstraint A rule governing an operational behaviour or property.
OperationalInteractionSpecification A specification of the interactions between nodes in an operational architecture.
OperationalNodeLifeline A lifeline which represents a usage of a node in an operational architecture.
OperationalStateDescription A rule governing an operational behaviour or property.
OperationalSwimlane A visual representation of nodes which conduct activities, shown as ‘swimlanes’.
OrgResourceReference A reference to an <<ActualPost>> or <<ActualOrganisation>>.
OrganisationType A group of persons, associated for a particular purpose.
OrganisationalResource Either an organisation, or a post. [ABSTRACT]
PostType A type of point of contact or responsible person. Note that this is the type of post - e.g. Desk Officer, Commander Land Component, etc.
ProblemDomain The boundary containing those <<Node>>s which may be realised by functional resources. There may be more than one alternative solution for a given <<ProblemDomain>>.
ProcessOwner Asserts that an <<OrganisationalResource>> has responsibility for an <<OperationalActivity>>. Note this does not imply the resource conducts the activity, merely that it has managerial responsibility for it.
ReferredLocation Either an <<ActualLocation>>, or a type of location (i.e. <<Environment>>) at/in which operations may be conducted. [ABSTRACT]
RequiredNodeLocation Relates a node to a location to assert that the operational node is required to be situated at that location.
SubjectOfOperationalConstraint An element of the architecture that may be subject to an <<OperationalConstraint>> or <<OperationalStateDescription>>. [ABSTRACT]