Category Archives: Logical

Lr – Lines of Development

NAF v3: NPV-2 MODAF: AcV-2

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The Lr view specifies the logical threads (lines of development) for a set of projects and programmes. The status of each of these threads can be shown at the various milestones in the projects or programmes.

Background

The Lr view is primarily intended to support the acquisition process across multiple projects or programmes, including the management of dependencies between projects and the integration of all the DLODs to achieve a successfully integrated military capability.

Use of the Lr view should support the management of capability delivery and be aligned with Cr Capability Phasing view.

Usage

  • Project management and control (including delivery timescales).
  • Project dependencies and the identification of associated risk.
  • Portfolio management
  • Through Life Management Planning (TLMP).

Representation

Detailed View Description

Key Elements and Their Relationships

lr-hlmm

Meta-Model

The detailed meta-model for Lr can be viewed here

L4-P4 Activity to Function Mapping

NAF v3: NSV-5 MODAF: SV-5

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
L4-P4 (NSV-5)
Physical
Resource
Specifications
P1
Resource Types
NAV-2, NSV-2a,7,9,12
AV-2, SV-2a,7,9,12
P2
Resource Structure
NOV-4,NSV-1
OV-4, SV-1
P3
Resource Connectivity
NSV-2, NSV-6
SV-2, SV-6
P4
Resource Functions
NSV-4
SV-4
P5
Resource States
NSV-10b
SV-10b
P6
Resource Sequence
NSV-10c
SV-10c
P7
Physical Data Model
NSV-11b
SV-11
P8
Resource Constraints
NSV-10a
SV-10a
Pr
Configuration Management
NSV-8
SV-8

The L4-P4 Function to Operational Activity / Service Function Traceability Matrix provides two alternate views:

This view can also support a Service Oriented approach by allowing service functions as well as Operational Activities.

Background

The L4-P4 view depicts the mapping of functions (and optionally, the resources that provide them) to operational activities or service functions. For operational activities it thus identifies the transformation of an operational need into a purposeful action performed by a system or solution. For service functions it provides the link between the services used at the operational level and the specific functions provided by the resources supporting the services.

During requirements definition, L4-P4 plays a particularly important role in tracing the architectural elements associated with system requirements to those associated with user requirements.

Usage

  • Tracing functional system requirements to user requirements.
  • Tracing solution options to requirements.
  • Identification of overlaps.

Representation

Detailed View Description

Key Elements and Their Relationships

Meta-Model

The detailed meta-model for L4-P4 can be viewed here

L1 – Node Types

NAF v3: NAV-2 MODAF: AV-2

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

An L1 view specifies the types of logical Node used in the architecture. The nodes can be organised into a specialisation hierarchy (subtype-supertype).

Concerns Addressed

  • User Requirements
  • Operational Planning
  • High-Level Systems Requirements

Background

An L1 is used to define all the Nodes that will appear in a Logical Architecture. Nodes are elements of capability that are assembled and orchestrated in Logical Architecture. The levels of capability provided by each node are expressed as Measures of Performance, and these may be dependent on the environments in which the Node is required to operate.

Usage

  • Initial set up of a Logical Architecture
  • Defining measure of performance for requirements specification purposes
  • Defining the types of environment in which Nodes may operate

Representation

An L1 can either be shown as a diagram that traces nodes to capabilities (also showing required measures of performance) or as a table:

l1-example
l1-example2

Detailed View Description

Nodes are traced to the Capabilities they manifest using the Capability For Node relationship. In addition, Measures of Performance may be specified for each node that map to the Measures of Effectiveness of the Capabilities. Each Measure can be expressed in terms of the environment – e.g. higher performance may be expected in clear weather than in bad.

The L1 helps to de-clutter an L2 by taking care of the properties and capabilities mappings that were previously shown in NAF v3 in NOV-2. It is still possible to show capabilities and properties in an L2 if required though.

Key Elements and Their Relationships

l1-hlmm

Meta-Model

The detailed meta-model for L1 can be viewed here

L3 – Node Interactions

NAF v3: NOV-2/3 MODAF: OV-2/3

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L3 Node Interactions view addresses operational information exchanges between nodes.

Background

Information exchanges provide further detail of the interoperability requirements associated with the operational capability of interest. The focus is on information exchanges that cross the capability boundary.

Although the primary purpose of this view is to specify information exchanges, an L3 may also list flows of materiel, energy and human resources.

Usage

• Definition of operational concepts.
• Elaboration of capability requirements.
• Definition of collaboration needs.
• Associating capability with a location.
• Problem space definition.
• Operational planning.
• Supply chain analysis.
• Security models – e.g. domain-based security & entity trust models

Security Usage

Representation

Detailed View Description

Key Elements and Their Relationships

l3-hlmm

Meta-Model

The detailed meta-model for L3 can be viewed here

L4 – Logical Activities

NAF v3: NOV-5 MODAF: OV-5

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L4 Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks), Input/Output flows between activities and to/from activities that are outside the scope of the Architecture.

Background

L4 describes the operational processes and activities that are being conducted within the mission or scenario. L4 can be used to:
• Clearly delineate lines of responsibility for activities when coupled with L2 – Logical Scenario.
• 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 scrutinised further.
• Provide a necessary foundation for depicting activity sequencing and timing in L8 – Logical Constraints, L5 – Logical States, and L6 – Logical Sequence.

L4 activity models describe the business processes associated with the architecture, as well as the:
• Relationships or dependencies among the business processes.
• Information exchanged between business processes.
• External interchanges (from/to business processes that are outside the scope of the model).

An operational activity is a logical process, specified independently of how it is carried out. To maintain this independence from implementation, logical nodes in L2 are used to represent the structure which carries out the operational activities. Operational activities are realised as functions (R4) which are the “how” to the Operational Activities’ “what”. That is, they are specified in terms of the resources that carry them out.

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

l4-hlmm

Meta-Model

The detailed meta-model for L4 can be viewed here

L5 – Logical States

NAF v3: NOV-6b MODAF: OV-6b

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L5 Logical States view describes how operational nodes or activities respond to various events by changing state. The view represents the sets of events to which the architecture 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.

Background

An L5 can be used to describe the detailed sequencing of activities or work flow in the business process. The L5 is particularly useful for describing critical sequencing of behaviours and timing of operational activities that cannot be adequately described in L4 – Logical Activities.

The L5 relates events and states. A change of state is called a transition. Actions may be associated with a given state or with the transition between states in response to stimuli (e.g. triggers and events).

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

l5-hlmm

Meta-Model

The detailed meta-model for L5 can be viewed here

L6 – Logical Sequence

NAF v3: NOV-6c MODAF: OV-6c

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L6 Logical Sequence view provides a time-ordered examination of the 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.

Background

Operational Event-Trace Descriptions, sometimes called sequence diagrams, event scenarios or timing diagrams, allow the tracing of interactions between nodes in a scenario or critical sequence of events. The node interactions may correspond to flows of information, energy, materiel or people specified in the L2 – Logical Scenario. The L6 can be used by itself or in conjunction with an L5 – Logical States to describe the dynamic behaviour of nodes. The diagram below shows the components of an L6. The items across the top of the diagram are operational nodes.
Each node has a vertical timeline associated with it. Specific points in time can be labelled running down the left-hand side of the diagram. Directed lines between the node time lines represent interactions (e.g. information exchanges) between nodes, and the points at which they intersect the timelines represent the times at which the nodes become aware of the events.

Usage

• Analysis of operational events.
• Sequences of interactions between nodes
• Behavioural analysis.
• Identification of non-functional user requirements (input to URD).
• Operational test scenarios.

Representation

Detailed View Description

Key Elements and Their Relationships

l6-hlmm

Meta-Model

The detailed meta-model for L6 can be viewed here

L7 – Logical Data Model

NAF v3: NOV-7 MODAF: OV-7

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L7 Logical Data Model view addresses the information perspective on an operational architecture.

Background

The L7 is used to document the business information requirements and structural business process rules of the architecture. It describes the information that is associated with the information exchanges of the architecture. Included are information items, their attributes or characteristics, and their inter-relationships.

Usage

• Information architecture.
• Information product hierarchy.

Representation

Detailed View Description

Key Elements and Their Relationships

l7-hlmm

Meta-Model

The detailed meta-model for L7 can be viewed here

L8 – Logical Constraints

NAF v3: NOV-6a MODAF: OV-6a

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

An L8 Operational Rules Model specifies operational or business rules that are constraints on the way that business is done in the Enterprise.

Background

L8 is used to constrain the logical architecture without forcing a particular solution. L8 is used for rules which are not expressed as behavioural models, interactions or measures of effectiveness – i.e. they are textual statements of requirement that constrain the architecture.

Usage

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

Representation

Detailed View Description

Key Elements and Their Relationships

l8-hlmm

Meta-Model

The detailed meta-model for L8 can be viewed here

L2 – Logical Scenario

NAF v3: NOV-2 MODAF: OV-2 DNDAF: OV-2, SecV-1/7 (logical)

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L2 Logical Scenario view shows, at a high level, the interactions between logical nodes and places them in the context of location(s).

Background

The primary purpose of the L2 View is to specify nodes (elements of capability) in context of each other. The context is usually expressed in terms of the information that flows between the nodes (e.g. the information flow requirements between capabilities in a given scenario). The context may also be flows of materiel, human resource or energy.

Since NAF v3, the L2 has been developed to:
• Adopt a more formal definition of logical flows to represent node connections.
• Support the introduction of Service Oriented Architecture (SOA).
• Accommodate the use of known resources (as defined in L2 – Resource Structure).

Usage

• Definition of operational concepts.
• Elaboration of capability requirements.
• Definition of collaboration needs.
• Associating capability with a location.
• Problem space definition.
• Operational planning.
• Supply chain analysis.

Security Usage

The L2 view is enhanced with additional features for modelling security:

• Security domain specification
• Logical entity trust models
• Threat specification (e.g. threat vectors) & counter-capability specifications

Representation

The following L2 example shows how security domains can be specified at a logical level:
l2-dbsy-example

The following example is a simple entity trust model described at a logical level:
l2-ent-trust-example

An L2 may also show the Operational Activities performed by each node:
l2 example activities 1

The required locations for Nodes may also be specified:
l2 example locations
Care must be taken when using locations, however. L2 is intended to be a Logical model (i.e. solution independent), and in many cases the location will not be known at design time.

Detailed View Description

**Julie – take care here when pasting in the MODAF documentation. L2 is not quite the same as OV-2. It is now preferred to put the capabilities and measures in L1 (though we still allow it in L2 if necessary). Also, the service orchestration is not in L2 any more, so the service examples go. ***

Key Elements and Their Relationships

l2-hlmm

Meta-Model

The detailed meta-model for L2 can be viewed here