Nato Architecture Framework (NAF) - 3.3 - NATO Operational View
Jump to navigation
Jump to search
NOV, NATO Operational View
NOV-1, High-Level Operational Concept Description。
- Is used to depict the big picture view of the operational context
- The purpose is to provide a quick, high-level description of the architecture, and its functionality.
- It is aimed at senior-level decision makers and may use a graphical picture to represent a high-level view of the operational environment in terms of operational elements involved, geographic regions, nodal connectivity, types of forces employed, etc.
- provides a description of the key (essential) operational elements and their interactions
- Operational elements can mean internal or external systems, organisational units, weapons systems, or other resources
NOV-1, High-Level Operational Concept Description。
Example
NOV-1, High-Level Operational Concept Description。
Definition
- How the subview is tailored depends on the scope and intent of the architecture, but in general, an NOV-1 will depict such things as the missions, high-level operations, organisation, and geographical distribution of assets
- An NOV-1 product identifies the mission/domain covered in the architecture and the viewpoint reflected in the architecture
- NOV-1 will convey, in simple terms, what the architecture is about and an idea of the players and operations involved
- The content of an NOV-1 product depends on the scope and intent of the architecture, but in general it describes the (key) elements of the operational domain and its immediate and relevant environment
- The product will frame the operational concept (what happens, who does what, in what order, to accomplish what goal) and highlight interactions to the environment and other external systems
- However the content will still be of an executive summary level as other views allow for more detailed definition of interactions and sequencing.
NOV-1, High-Level Operational Concept Description。
Development Guidance
- An NOV-1 product can be used to orient and focus detailed discussions
- Its main utility is as a facilitator of human communication, and it is intended for presentation to high- level decision makers
- As such, the NOV-1 product can be used for these purposes by virtually all Communities of Interest (CoI).
- NOV-1 is the most general of the architectural views and the most flexible in format
- A NOV-1 product usually consists of one or more graphics (or possibly a video-clip), as needed, as well as explanatory text
- During the course of developing an architecture, several versions of a NOV-1 product may be produced
- An initial version may be produced to focus the effort and illustrate its scope
- After other products within the architecture‘s scope have been developed and verified, another version of this product may be produced to reflect adjustments to the scope and other architecture details that may have been identified as a result of the architecture development
- After the architecture has been used for its intended purpose and the appropriate analysis has been completed, yet another version may be produced to summarize these findings to present them to high- level decision makers
- In other cases, NOV-1 is the last product to be completed, as it conveys summary information about the whole architecture
NOV-1, High-Level Operational Concept Description。
Running Example
Supporting NNEC Architecture
- Actor
- Operational objective
- Capability
- Process
- Location
- Information product
- Information flow
- Service (Operational service)
- Component
- Component collaboration
NOV-2, Operational Node Connectivity Description。
- The purpose of the Operational Node Connectivity Description is to illustrate the operational domain‘s needs for information exchange in support of operational activities.
- NOV-2 depicts operational nodes with needlines between those nodes that indicate a need to exchange information. The NOV-2 may optionally show the required location of operational nodes. An NOV-2 may be annotated to show flows of materiel, energy, or people between nodes (note that these exchanges are not needlines and do not appear in an NOV-3). The operational nodes shown in an NOV-2 product may be internal nodes to the architecture, or external nodes that communicate with those internal nodes.
NOV-2, Operational Node Connectivity Description。
Example
NOV-2, Operational Node Connectivity Description。
Definition
- The NOV-2 is focused on the operational nodes which are logical collections of operational activities. Operational nodes1 produce or consume information and may represent an operational realization of capabilities
- The main features of NOV-2 are the nodes, the links between them, and the characteristics of the information exchanged. Each needline describes the characteristics of the data or information, i.e. its substantive content, format (voice, imagery, text and message format, etc.), throughput requirements, security or classification level, timeliness requirement, and the degree of interoperability required for the exchange
- The activities associated with a given information exchange can be described explicitly, in order to allow functional solutions, rather than system solutions, to be devised
NOV-2, Operational Node Connectivity Description。
Development Guidance
- The NOV-2 can be used to depict required exchanges of different types of information (e.g. data, voice, and video) between nodes, or particular services required at different nodes
- Operational nodes can be composed of other operational nodes
- The information portrayed in the node connectivity models can be used to make decisions about what systems are needed to satisfy the operational needs of an organisation or functional area
- However, it must be understood that it is the operational needs that are illustrated and not the systems solutions
- This diagram is therefore of use in defining the NATO Operational View and not that of the NATO Systems View
- For complex architectures, NOV-2 may consist of multiple graphics
- There are at least two different ways to decompose NOV-2
- One method involves using multiple levels of abstraction and decomposing the nodes
- Another method involves restricting the nodes and needlines on any given graphic to those associated with a subset of operational activities
- Both of these methods are valid and can be used together
NOV-2, Operational Node Connectivity Description。
Development Guidance
- Nodes are independent of materiel considerations; indeed, they exist to fulfil the missions of the enterprise and to perform its tasks and activities (operational processes, procedures, and functions)
- Use of nodes and needlines supports analysis and design by separating process modelling and information requirements from the materiel solutions that support them
- Similarly, tasks and activities are organised, and Communities of Interest are defined to suit the mission and process requirements
- However, an architecture often has materiel constraints and requirements that must be addressed
- In reality the node being examined may be a platform or system and the NOV-2 diagram just provides the operational view of that node.
NOV-2, Operational Node Connectivity Description。
Running Example
NOV-2, Operational Node Connectivity Description。
Supporting NNEC Architecture Elements
- Actor
- Operational objective
- Capability
- Service (Operational service)
Exercise
- Open M3_v1_2_003_Release.eap file
- Please analyse and discuss examples from MoDAF (export/<<profile>>NMM/NMM examples/NOV-2)
NOV-3, Operational Information Requirements。
- Identify and describe all information exchanges that make up all information needlines between operational nodes, as identified in NOV-2
- Identify who exchanges what information, with whom, why the information is necessary, and with what quality the information exchange must occur
Example
NOV-3, Operational Information Requirements。
Definition
- The NOV-3 subview expresses the relationships across the NATO Operational View‘s three basic entities:
- operational activity (operational task),
- (operational) node,
- information exchange.
- Operational activities are addressed in NOV-5; nodes in NOV-2
- The emphasis in this product is on the operational characteristics of the information
- NOV-3 is not intended to be an exhaustive listing of all the details contained in every information exchange of every operational node associated with the architecture in question
- Nor will the production of such a listing be considered sufficient to replace an integrated architecture development effort
- Rather, this product is intended to capture the most important aspects of selected information exchanges
NOV-3, Operational Information Requirements。
- Many individual information exchanges may be associated with one needline.
- The information media type (i.e. data, voice and video), quality (i.e. frequency, timeliness and security), and quantity (i.e. volume and speed) are attributes of the information and information exchange that must be included in the requirements description
- For example, if the subject architecture concerns tactical battlefield targeting, then the timeliness of the enemy target information is a significant attribute of the information exchange
- Required properties such as availability, secure communications, latency, and reliability may also be captured for each exchange
- Required properties may be extended to capture other needs such as personnel skills or facilities
- The specific mission/scenario and the related operational tasks and activities can be noted as an attribute of the information exchange.
Information Exchange Requirement (IER)。
The identification and description of an information exchange, together with the identification and specification of its information attributes and information exchange attributes, form the Information Exchange Requirement (IER).
Development Guidance
- The definition of information exchange attributes is the starting point for specifying information exchanges
- The purpose and scope for which the architecture is being developed drive the attributes describing the specific information exchanges
- For example, for high level planning architectures, it may only be necessary to identify information exchanges with respect to major categories of information and primary operational nodes involved in the exchange with only a few high level attributes such as media and security described
- However, before a system view can be developed on the basis of IERs, the information exchanges and information exchanged must have all of the required attributes described fully and correctly
- In other words, to support development of systems architectures, it will be necessary to provide greater specificity as to the information content, consuming/producing nodes, and media as well as fairly explicit qualitative and quantitative descriptions of the information exchanges and information exchanged
Information Exchange Requirement (IER)。
Development Guidance
- A tabular approach is often used to represent a NOV-3
- The table is designed to portray information elements (as identified in NOV-7) that are exchanged in separate table rows for each pair of operational nodes that exchange the information objects.
- Multiple rows of the table may be required to describe all of the information exchanges between one pair of nodes
- There may not be a one-to-one correlation between information elements listed in the matrix and the information inputs and outputs that connect operational activities in a related NOV-5.
- Information inputs and outputs between operational activities performed at the same node (i.e. not associated with a needline on NOV-2) will not show in NOV-3
- Information inputs and outputs between operational activities for some levels of operational activity decomposition may be at a higher level of abstraction than the information objects in the matrix
- In this case, multiple information exchanges will map to a single operational activity input or output
- Similarly, the information inputs and outputs between operational activities at a low level of activity decomposition may be at a higher level of detail than the information exchanges in the table, and multiple information inputs and outputs may map to a single information exchange
NOV-3, Operational Information Requirements。
Supporting NNEC Architecture Elements
- Actor
- Information object
- Information requirement
- Information product
- Service (Operational service)
NOV-4, Organisational Relationship Chart。
The Organisational Relationship Chart identifies the key players in the operational domain that is subject to the architecture effort, and illustrates the organisational relationships among these key players.
Example
NOV-4, Organisational Relationship Chart。
Definition
- An NOV-4 product particularly identifies the key players
- These key players may be deployed to the nodes of an NOV-2, which contain added detail on how the key players interact together in order to conduct their corresponding operational activities of NOV-5
- Key players seem to be best described using role-based descriptions, independent of the fact whether a role actually involves an entire operational node or just a single human role
- NOV-4 may be developed using strictly role-based elements representing the key players.
- There can be many types of organisational relationships between the key players:
- Command and Control (C2) relationships;
- hierarchical relationships;
- functional relationships;
- reporting relationships;
- collaboration relationships, and so on.
NOV-4, Organisational Relationship Chart。
Definition
- Organisational relationships are important to depict in a NATO Operational View, because they can illustrate fundamental human roles (e.g. who or what type of skill is needed to conduct operational activities) as well as management relationships (e.g., command structure or relationship to other key players)
- Also, organisational relationships may influence how the operational nodes in an NOV-2 are connected
- For example, command and control relationships may differ under different circumstances
- Differing command relationships may mean that activities are performed differently or by different units
- Different coordination relationships may mean that connectivity requirements are changed.
NOV-4, Organisational Relationship Chart。
Development Guidance
- NOV-4 is particularly useful to the Communities of Interest that are interested in understanding the relationships between key players and other elements of the architecture (such as systems, e.g. answering the question which key players are affected when a certain system is replaced)
- Typically, an NOV-4 product consists of one or more diagrams, depicting hierarchical decompositions of organisational elements, with the various organisational relationships superimposed on them as connecting lines
- Different colours or styles of connecting lines can indicate various types of relationships among the organisations
- The decompositions may consist of both typical organisational element types and actual organisational elements concurrently
- Architects are free to define any kind of organisational relationship necessary and important within their architecture to support the goals of the architecture effort
- In such cases, architects should record and define these additional relationship classifications in NAV-3b.
NOV-4, Organisational Relationship Chart。
Running Example
NOV-4, Organisational Relationship Chart。
Supporting NNEC Architecture Elements
- Actor
- Location
- Service (Operational service)
Exercise。
- Church (Pope, Cardinals, Diacose, Prists)
NOV-5, Operational Activity Model。
The purpose of an Operational Activity Model is to:
- Clearly delineate lines of responsibility for operational activities when coupled with NOV-2
- Uncover unnecessary operational activity redundancy
- Make decisions about streamlining, combining, or omitting activities
- Define or flag issues, opportunities, or operational activities and their interactions (information flows among the activities) that need to be scrutinized further
- Provide a necessary foundation for depicting activity sequencing and timing in NOV-6a, NOV-6b, and NOV-6c
- Provide a clear picture of how operations are performed and thereby support analysis and design of services and systems.
NOV-5, Operational Activity Model。
Example
NOV-5, Operational Activity Model。
Definition
- The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or an operational objective
- It describes operational activities (or operational tasks) and Input/Output (I/O) flows between activities
- I/Os of operational activities relate to information elements of NOV-3 and are further characterized by the information exchange attributes described in NOV-3.
- I/Os that are produced or consumed by leaf operational activities that cross operational node boundaries are carried by needlines of NOV-2.
NOV-5, Operational Activity Model。
Development Guidance
- An NOV-5 product is well suited to start an architecture effort
- The NAF does not endorse specific modelling methods and techniques.
- On of the notation: http://en.wikipedia.org/wiki/IDEF0
- While some may illustrate corresponding systems as mechanisms in this model, the reader is cautioned that the introduction of system data early in the development of the NATO Operational View may result in limiting system design and implementation decisions
- In addition, operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding node from NOV-2
- Annotations to the activities may also identify the costs (actual or estimated) associated with performing each activity
- The Operational Rules that govern the performance of the activities can also be keyed to each activity. (Operational Rules are described in NOV-6a.)
- Annotations to NOV-5s can further the purposes of the description by adding specific attributes of exchanged information, which can later be used in NOV-3
NOV-5, Operational Activity Model。
Development Guidance
- NOV-5 graphic(s) may include a hierarchy chart of the activities covered in the model. A hierarchy chart helps provide an overall picture of the activities involved and a quick reference for navigating the NOV-5 I/O flow model.
- NOV-5 is frequently used in conjunction with a NOV-6 model (such as a UML sequence diagram) that describes the sequence and other attributes (e.g. timing) of the activities
- A NOV-6 model further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organisation works
- In addition, a NOV-6 model may be annotated with the names of the operational nodes responsible for conducting those activities
- The decomposition levels and the amount of detail shown on NOV-5 will be aligned with the operational nodes that are responsible for conducting the operational activities (shown on corresponding NOV-2 products)
- It is important to note that NOV-5 is intended to be only as exhaustive as necessary to attain the objectives for the architecture as stated in NAV-1.
NOV-5, Operational Activity Model。
Running Example
NOV-5, Operational Activity Model。
Supporting NNEC Architecture Elements
- Actor
- Operational objective
- Process
- Information requirement
- Information product
- Service (Operational service)
Nato_Architecture_Framework_(NAF)_-_4.4_-_NATO_Meta_Model_-_NOV#NOV-5_Operational_activity_model
NOV-6, Operational Activity Sequence and Timing Description。
- The Operational View products, discussed in previous sections, with the exception of NOV-5, model the static structure of the architecture elements and their relationships.
- Many of the critical characteristics of an architecture are only discovered when the dynamic behaviour of these elements is modelled to incorporate sequencing and timing aspects of the architecture
- Several modelling techniques may be used to refine and extend the architecture‘s Operational View to adequately describe the dynamic behaviour and timing performance characteristics of an architecture, such as logical languages, such as:
- LDL [Naqvi, 1989]
- Harel Statecharts [Harel, 1987a, b]
- petri- nets [Kristensen, 1998]
- and UML state chart and sequence diagrams [OMG, 2001]
NOV-6, Operational Activity Sequence and Timing Description。
- NOV-6 includes three such models. They are:
- Operational Rules Model (NOV-6a)
- Operational State Transition Description (NOV-6b)
- Operational Event-Trace Description (NOV-6c)
- NOV-6b and NOV-6c may be used separately or together, as necessary, to describe critical timing and sequencing behaviour in the Operational View
- NOV-6b and NOV-6c describe operational activity or operational process responses to sequences of events
- Events may also be referred to as inputs, transactions, or triggers
- Events can be internally or externally generated and can include such things as:
- the receipt of a message
- a timer going off
- or conditional tests being satisfied
- When an event occurs, the action to be taken may be subject to a rule or set of rules (conditions) as described in NOV-6a
NOV-6a, Operational Rule Model。
Operational rules constrain the operational aspects of the architecture and provide references and guidelines for the development and definition of more detailed rules and behavioural definitions that will occur later in the architecture definition process
Definition
- The Operational Rules Model specifies operational constraints on an enterprise, a mission, or an operation, business, or on an architecture. While other NOV products discussed so far (e.g. NOV-1, NOV-2 and NOV-5) describe the structure and behaviour of the operational domain, for the most part they do not describe the constraints under which they operate
- At the mission level, NOV-6a may consist of doctrine, guidance, rules of engagement, and so forth
- At the operation level, rules may include such things as a military Operational Plan (OPLAN)
- At lower levels, NOV-6a describes the rules under which, for example, weapon systems behave under specified conditions
- Such rules can be expressed in a textual form, for example, ?If (these conditions) exist, and (this event) occurs, then (perform these actions)
NOV-6a, Operational Rule Model。
Development Guidance
- Operational Rules are statements that constrain some aspect of the operational domain
- Rules are expressed in natural language (approved by NATO) in one of two forms:
- Imperative – a statement of what shall be under all conditions – e.g. ?Battle Damage Assessment (BDA) shall only be carried out under fair weather conditions
- Conditional Imperative – a statement of what shall be, in the event of another condition being met – ?If battle damage assessment shows incomplete strike, then a re-strike shall be carried out
- As the subview name implies, the rules captured in NOV-6a are operational (i.e., mission-oriented) whereas systems-oriented rules are defined in NSV-10
- NOV-6a rules can include such guidance as the conditions under which operational control passes from one entity to another or the conditions under which a human role is authorized to proceed with a specific activity
- A rule defined in NOV-6a may be applied to any architectural element defined in an Operational View
- Often, NOV-6a rules are associated with activities in NOV-5
- For example, a rule might prescribe the specific set of inputs required to produce a given output
NOV-6a, Operational Rule Model。
Development Guidance
- NOV-6a can also be used to extend the capture of operational requirements by constraining the structure and validity of NOV-7 information elements
- Rules defined in an NOV-6a may optionally be presented in any other Operational View – for example, a rule 'Battle damage assessment shall be carried out under fair weather conditions.' may be shown linked to the 'Conduct BDA'-activity in NOV-5
- Any natural language rule presented in an Operational View product shall also be listed in NOV-6a.
NOV-6a, Operational Rule Model。
Running Example
Supporting NNEC Architecture Elements
- Actor
- Operational objective
- Information object
- Business rule
- Service (Operational service)
NOV-6b, Operational State Transition Description。
- The explicit sequencing of activities in response to external and internal events is not fully expressed in NOV-5.
- An Operational State Transition Description can be used to describe the explicit sequencing of operational activities, especially in terms of the operational activities‘ life-cycles.
- Alternatively, NOV-6b can be used to reflect the explicit sequencing of actions internal to a single operational activity or the sequencing of operational activities with respect to a specific operational node.
Example
NOV-6b, Operational State Transition Description。
Definition
- NOV-6b is based on state machines
A state machine is defined as:
'A specification that describes all possible behaviours of some dynamic model element. Behaviour is modelled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of a series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine. [OMG, 2003]
- State machines can often allow quick analysis of the completeness of the rule set, and detection of dead ends or missing conditions. These errors, if not detected early during the operational analysis phase, can often lead to serious behavioural errors in fielded systems or to expensive correction efforts.
NOV-6b, Operational State Transition Description。
Development Guidance
- The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state
- The diagram represents the sets of events to which the operational domain will respond by taking an action to move to a new state, as a function of its current state
- Each transition specifies an event and an action
- The example shown below represents the graphical method
- NOV-6b may be produced in UML using state chart diagrams that contain simple states and composite states
- They also contain transitions, which are described in terms of triggers or events (generated as a result of an action).
NOV-6b, Operational State Transition Description。
Running Example
Supporting NNEC Architecture Elements
- Actor
- Operational objective
- Operational object
- Process
NOV-6c, Operational Event-Trace Description。
- An NOV-6c product helps define node interactions and operational threads.
- An NOV-6c product can also help ensure that each participating operational node has the necessary information at the right time in order to perform its assigned operational activity.
Example
NOV-6c, Operational Event-Trace Description。
Definition
- The Operational Event-Trace Description provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario
- Each event-trace diagram will have an accompanying description that defines the particular scenario or situation
- NOV-6c allows the tracing of actions in a scenario or critical sequence of events
- NOV-6c can be used by itself or in conjunction with any other of the behavioural operational subviews (i.e. information exchanges in NOV-3, or flow of activity in NOV-5 or NOV-6b) to describe the dynamic behaviour of operational processes or a mission/operational thread
- An operational thread is defined as a set of operational activities, with sequence and timing attributes of the activities, and includes the information needed to accomplish the activities
- A particular operational thread may be used to depict a military capability
- In this manner, a capability is defined in terms of the attributes required to accomplish a given mission objective by modelling the set of activities and their attributes. The sequence of activities forms the basis for defining and understanding the many factors that impact on the overall military capability
NOV-6c, Operational Event-Trace Description。
Development Guidance
- The NAF does not endorse a specific event-trace modelling technique
- However, UML sequence diagrams [OMG, 2003] seem the most appropriate for this purpose
- Different scenarios will be depicted by separate diagrams
- UML Sequence Diagrams may be used to depict operational nodes with lifelines associated with them that run vertically
- Specific points in time can be labelled on the lifelines, running down the left-hand side of the diagram
- One-way arrows between the node lifelines represent events, and the points at which they intersect the lifelines represent the times at which the nodes become aware of the events
- Events represent information passed from one lifeline to another and actions associated with the event
- Labels indicating timing constraints or providing descriptions can be shown in the margin or near the event arrow that they label
- The direction of the events represents the flow of control from one node to another
NOV-6c, Operational Event-Trace Description。
Running Example
NOV-6c, Operational Event-Trace Description。
Supporting NNEC Architecture Elements
- Actor
- Information object
- Information requirement
- Information product
- Service (Operational service)
NOV-7, Information Model。
- The purpose of an information model is to analyze the information aspects of the operational domain and to guide the design of information systems
- By contrast, a data model is used to design the data presentation, handling and storage functionality of an information system.
- An information model should not be confused with a data model
- Although the distinction between the two is not clear, they at least serve different purpose
- There is a grey area where information models and data models overlap
- The purpose of the high-level abstraction is to hide the details of an often complex logical data model in order to facilitate the communication of it to those who are not familiar with the techniques involved in data modelling
NOV-7, Information Model。
Definition
- 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
- Information models address the information aspect of the universe of discourse.
- They are not intended to reflect data storage solutions!
NOV-7, Information Model。
Development Guidance
- In general, it seems advisable to use object-oriented techniques to describe an information model
- In particular, the notions of generalization, abstraction and encapsulation, are considered to be important
- The application of such a technique would also facilitate the use of concept definitions from an NAV-2 product and the production of data models in an NSV-11 product, because for both NAV-2 and NSV-11 products it seems to be advisable to also use object-oriented techniques (e.g. object-oriented techniques can also be used to model entity-relationships)
- An information model should be based on the NAV-2 product, which, in effect, forms the operational domain object model, and which contains the definitions of all the concepts that are relevant within the universe of discourse for the architecture effort. In turn, NOV-7 should be used as an input to NSV-11, which captures logical and physical data models
Supporting NNEC Architecture。
- Operational object
- Information object
- Business rule
Running Example
Nato_Architecture_Framework_(NAF)_-_4.4_-_NATO_Meta_Model_-_NOV#NOV-7_Conceptual_information_model
