Systems Data Exchange Matrix (SV-6)

Product Definition. The Systems Data Exchange Matrix specifies the characteristics of the system data exchanged between systems. This product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV products only.

Product Purpose. System data exchanges express the relationship across the three basic architecture data elements of an SV (systems, system functions, and system data flows) and focus on the specific aspects of the system data flow and the system data content. These aspects of the system data exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation.
sv-6, systems data exchange matrix
Product Detailed Description. SV-6 describes, in tabular format, system data exchanged between systems. The focus of SV-6 is on how the system data exchange is implemented, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the exchange. In addition, the system data elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix.

SV-6 relates to, and grows out of, OV-3. The operational characteristics for the OV-3 information exchange are replaced with the corresponding system data characteristics. For example, the Levels of Information Systems Interoperability (LISI) level required for the operational information exchange is replaced by the LISI level achieved through the system data exchange(s). Similarly, performance attributes for the operational information exchanges are replaced by the actual system data exchange performance attributes for the automated portion(s) of the information exchange.

On SV-6, each operational needline is decomposed into the interfaces that are the systems equivalents of the needline. SV-1 graphically depicts system data exchanges as interfaces that represent the automated portions of the needlines. The implementation of SV-1 interfaces is described in SV-2 (if applicable). The system data exchanges documented in SV-6 trace to the information exchanges detailed in OV-3 and constitute the automated portion(s) of the OV-3 information elements.

A partial format for the SV-6 matrix can be found in CJCSI 6212.01B, and that format is required for C4ISP development. However additions to the CJCSI 6212.01B matrix to meet program-unique needs should also be allowed.

More Examples of SV-6 at:

Ministry of Defense AF

Technical Standards Forecast

Product Definition. The Technical Standards Forecast contains expected changes in technology-related standards and conventions, which are documented in the TV-1 product. The forecast for evolutionary changes in the standards should be correlated against the time periods as mentioned in the SV-8 and SV-9 products.

Product Purpose. One of the prime purposes of this product is to identify critical technology standards, their fragility, and the impact of these standards on the future development and maintainability of the architecture and its constituent elements. Product Detailed Description. TV-2 lists emerging or evolving technology standards relevant to the systems covered by the architecture. It contains predictions about the availability of emerging standards, and relates these predictions to the Systems View elements and the time periods that are listed in the SV-8 and SV-9.

The specific time periods selected (e.g., 6-month, 12-month, 18- month intervals) and the standards being tracked should be coordinated with architecture transition plans (see SV-8). That is, insertion of new techno logical capabilities and upgrading of existing systems may depend on, or be driven by, the availability of new standards and products incorporating those standards. The forecast specifies potential standards and thus impacts current architectures and influences the development of transition and objective (i.e., target) architectures. The forecast should be tailored to focus on standards areas that are related to the purpose for which a given architecture is being described and should identify potential standards that will affect the architecture. If interface standards are an integral part of the technologies important to the evolution of a given architecture, then it may be convenient to combine TV-2 with SV-9. For other projects, it may be convenient to combine all the standards information into one document, combining TV-2 with TV-1.

TV-2 delineates the standards that will potentially impact the relevant system elements (from SV-1, SV-2, SV-4, SV-6, and OV-7) and relates them to the time periods that are listed in the SV-8 and SV-9. A system’s evolution, specified in SV-8, may be tied to a future standard listed in TV-2. A timed technology forecast from SV-9 is related to a TV-2 standards forecast in the following manner: a certain technology may be dependent on a TV-2 standard (i.e., a standard listed in TV-2 may not be adopted until a certain technology becomes available). This is how a prediction on the adoption of a future standard, as applicable to systems elements from SV-1, SV-2, SV-4, SV-6, and OV-7, may be related to standards listed in TV-1 through the SV-9. A template for TV-2 is not shown in this section. The same template shown in TV-1 may be used to describe TV-2.

Technical Standards Profile

TV-1.

Product Definition. The Technical Standards Profile collects the various systems standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of an architecture.

Product Purpose. Primarily, this product is concerned with delineating systems standards rules and conventions that apply to architecture implementations. When the standards profile is tied to the system elements to which they apply, TV-1 serves as the bridge between the SV and TV.

Product Detailed Description. TV-1 consists of the set of systems standards rules that govern systems implementation and operation of that architecture. The technical standards generally govern what hardware and software may be implemented and what system data formats may be used (i.e., the profile delineates which standards may be used to implement the systems, system hardware/software items, communications protocols, and system data formats). TV-1 is constructed as part of a given architecture and in accordance with the architecture purpose. Typically, this will involve starting with one or more overarching reference models or standards profiles, such as OMB’s TRM [OMB, 2003], DoD TRM, or the Joint Technical Architecture (JTA) [DISA, 2002]. Using these reference models or standards profiles, the architect should select the service areas relevant to the architecture. The identification of relevant services within service areas subsequently points to agreed-upon standards. The source document used for identifying each standard must also be cited.
Technical Standards Profile
In most cases, especially in describing architectures with less than a Military Servicewide scope, TV-1 consists of identifying the applicable portions of the JTA and other existing technical standards guidance documents, tailoring those portions, as needed, in accordance with the latitude allowed in these guidance documents, and filling in any gaps. This process of tailoring standards guidance from higher level, more general guidance, is called creating a standards profile. For example, a DoD mission area might create a common mission-area standards profile using TV-1. Each program or project in that mission area would further refine this common profile to create its own standards profile. Care should be taken in the refinement process to ensure that systems compliant with the child profile would cont inue to be interoperable with systems compliant with the parent profile. If service-level JTA-like documents are used, then the relationship between the JTA and those documents must be stated. Some of the existing technical standards guidance documents are described in the Deskbook [see section on URRs in the Deskbook].

For a given domain, TV-1 may also state a common standard implementation for a particular standard, not just list the standard. Many standards can be implemented in compliant, but not interoperable ways, such as MIL STD 6016.

The standards are referenced as relationships to the systems, system functions, system data, hardware/software items or communication protocols in SV-1, SV-2, SV-4, SV-6, OV-7, and SV-11 products, where applicable. That is, each standard listed in the profile should be associated with the SV elements that implement or use the standard (e.g., SV-1, SV-2, SV-4, SV-6, OV-7 and SV-11 element standards, where applicable). Standards for OV-7 and SV-11 do not include system data standards such as naming conventions, attribute lists, and field types, but refer to the source for the data entities (e.g., DoD XML Registry), or the data modeling standard used (e.g., IDEF1X).

Physical Schema

SV-11

Product Definition. The Physical Schema product is one of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture. Product Purpose. The product serves several purposes, including (a) providing as much detail as possible on the system data elements exchanged between systems, thus reducing the risk of interoperability errors, and (b) providing system data structures for use in the system design process, if necessary.

Product Detailed Description. SV-11 is an implementation-oriented data model that is used in the Systems View to describe how the information requirements represented in Logical Data Model (OV-7) are actually implemented. Entities represent (a) system data flows in SV-4, (b) system data elements specified in SV-6, (c) triggering events in SV-10b, and/or (d) events in SV-10c.
Physical Schema
There should be a mapping from a given OV-7 to SV-11 if both models are used. The form of SV-11 can vary greatly, as shown in Figure 5-40. For some purposes, an entityrelationship style diagram of the physical database design will suffice. References to message format standards (which identify message types and options to be used) may suffice for messageoriented implementations. Descriptions of file formats may be used when file passing is the mode used to exchange information. A Data Definition Language (DDL) (e.g., Structured Query Language [SQL]) may also be used in the cases where shared databases are used to integrate systems. Interoperating systems may use a variety of techniques to exchange system data and have several distinct partitions in their SV-11 with each partition using a different form. Standards associated with entities (e.g., entities are those defined in DoD XML Registry) are also documented in this product.

Operational Activity to Systems Function Traceability Matrix (SV-5)


Product Definition.
Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to an architecture and the set of system functions applicable to that architecture.

Product Purpose. SV-5 depicts the mapping of operational activities to system functions and thus identifies the transformation of an operational need into a purposeful action performed by a system.

SV-5 can be extended to depict the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them. Such a matrix allows decision makers and planners to quickly identify stovepiped systems, redundant/duplicative systems, gaps in capability, and possible future investment strategies all in accordance with the time stamp given to the architecture. SV-5 correlates capability requirements that would not be satisfied if a specific system is not fielded to a specific DoD unit.

Product Detailed Description.
The Framework uses the terms activity in the OVs and function in the SVs to refer to essentially the same kind of thing-both activities and functions are tasks that are performed, accept inputs, and develop outputs. The distinction lies in the fact that system functions are executed by automated systems, while operational activities describe business operations that may be conducted by humans, automated systems, or both. Typical systems engineering practices use both of these terms, often interchangeably. However, given the Framework’s use of activities on the operational side and functions on the systems side, and the fact that operational nodes do not map one-to-one to systems nodes, it is natural that operational activities do not map one-to-one to system functions. Therefore, SV-5 forms an integral part of the eventual complete mapping from operational capabilities to systems requirements. SV-5 is an explicit link between the OV and SV. The capabilities and activities are drawn from OV-5, OV-6b, and OV-6c. The system functions are drawn from an SV-4. (SV-1 and SV-2 may also define system functions for identified systems.)
Operational Activity to Systems Function Traceability Matrix, SV-5
The relationship between operational activities and system functions can also be expected to be many-to- many (i.e., one operational activity may be supported by multiple system functions, and one system function may support multiple operational activities).

Systems Functionality Description (SV-4)

Product Definition. The Systems Functionality Description documents system functional hierarchies and system functions, and the system data flows between them. Although there is a correlation between Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping.

Product Purpose. The primary purposes of SV-4 are to (a) develop a clear description of the necessary system data flows that are input (consumed) by and output (produced) by each system, (b) ensure that the functional connectivity is complete (i.e., that a system’s required inputs are all satisfied), and (c) ensure that the functional decomposition reaches an appropriate level of detail.

Product Detailed Description. SV-4 describes system functions and the flow of system data among system functions. It is the SV counterpart to OV-5. SV-4 may be represented in a format similar to data flow diagrams (DFDs) [DeMarco, 1979]. The scope of this product may be enterprise wide, without regard to which systems perform which functions, or it may be system specific. Variations may focus on intranodal system data flow, internodal system data flow, system data flow without node considerations, function to system allocations, and function to node allocations.
Systems Functionality Description
The system functions documented in the SV-4 may be identified using the Service Component Reference Model (SRM),20 or some other system function taxonomy, and correlated to SV-1 and SV-2 systems. System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions that consume or produce system data from/to system functions that belong to external systems. The external system data sources and/or sinks can be used to represent the human that interacts with the system or external systems. The system data flows between the external system data source/sink (representing the human or system) and the HCI, GUI, or interface function can be used to represent human-system interactions, or system-system interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product.

Like OV-5, SV-4 may be hierarchical in nature and may have both a hierarchy or decomposition model and a system data flow model. The hierarchy model documents a functional decomposition. The functions decomposed are system functions.

Systems Communications Description

SV-2 Templates

Product Definition. The Systems Communications Description depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implement their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces that automate aspects of the needlines represented in OV-2.
Systems Communications Description
Product Purpose. SV-2 can be used to document how interfaces (described in SV-1) are supported by physical media. This kind of communications media support information is critical in performing certain infrastructure and system acquisition decisions.

Product Detailed Description. SV-2 documents the specific communications links or communications networks (e.g., Intelink or Joint Worldwide Intelligence Communications System [JWICS]) and the details of their configurations through which systems interface. While SV-1 depicts interfaces between systems or systems nodes, SV-2 contains a detailed description of how each SV-1 interface is implemented (e.g., composing parts of the implemented interface including communications systems, multiple communications links, communications networks, routers, and gateways).

Communications systems (e.g., switches, routers, and communications satellites) are systems whose primary function is to control the transfer and movement of system data as opposed to performing mission application processing.

A communications link is a single physical connection from one system (or node) to another. A communications path is a (connected) sequence of communications systems and communications links originating from one system (or node) and terminating at another systems (or node).

A communications network may contain multiple paths between the same pair of systems. The term interface used in SV-1 and referenced in SV-2 represents an abstraction of one or more communications path(s).

The graphical presentation and supporting text for SV-2 should describe all pertinent communications attributes (e.g., waveform, bandwidth, radio frequency, and packet or waveform encryption methods). Communications standards are also documented in this product, where applicable.

Because SV-2 depicts the implementation details for the interfaces described in SV-1 by decomposing them into communications systems, communications links, and communications networks, it can present either internodal or intranodal versions. The internodal version details the communications links and/or communications networks that interconnect systems nodes (node edge to node edge) or specific systems (system-system from one node to other nodes). The intranodal version of SV-2 looks inside each of the represented nodes to illustrate the communications links between specific systems.

Logical Data Model

OV-7 Template

Product Definition. The Logical Data Model describes the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s Operational View) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. Product Purpose. OV-7 including the domain’s system data types or entity definitions, is a key element in supporting interoperability between architectures, since these definitions may be used by other organizations to determine system data compatibility. Often, different organizations may use the same entity name to mean very different kinds of system data with different internal structure. This situation will pose significant interoperability risks, as the system data models may appear to be compatible, each having a Target Track data entity but having different and incompatible interpretations of what Target Track means. An OV-7 may be necessary for interoperability when shared system data syntax and semantics form the basis for greater degrees of information systems interoperability, or when a shared database is the basis for integration and interoperability among business processes and, at a lower level, among systems.
Logical Data Model
Product Detailed Description. OV-7 defines the architecture domain’s system data types (or entities) and the relationships among the system data types. For example, if the domain is missile defense, some possible system data types may be trajectory and target with a relationship that associates a target with a certain trajectory. On the other hand, architecture data types for the DoDAF (i.e., DoDAF-defined architecture data elements, AV-2 data types, and CADM entities) are things like an operational node or operational activity. OV-7 defines each kind of system data type associated with the architecture domain, mission, or business as its own entity, with its associated attributes and relationships. These entity definitions correlate to OV-3 information elements and OV-5 inputs, outputs, and controls.

Although they are both called data models, OV-7 should not be confused with the CADM. OV-7 is an architecture product and describes information about a specific architecture domain. The CADM is not an architecture product. The CADM is a database design for a repository of DoDAF products and architecture data. CADM-based repositories can store architecture products, including Logical Data Models, from any DoDAF-based architecture project. Thus, the CADM addresses a structure for storing architecture data (e.g., instances of operational nodes and operational activities), while a Lo gical Data Model for missile defense, for example, might define architecture domain entities and relationships such as missile tracks and points of impact.

The purpose of a given architecture helps to determine the level of detail needed in this product. A formal data model (e.g., the Integrated Definition for Data Modeling [IDEF1X]) [FIPS 184, 1993] that is detailed down to the level of architecture domain system data, their attributes, and their relationships is required for some purposes, such as when validation of completeness and consistency is required for shared data resources. However, for other purposes, a higher- level conceptual data model of the domain of interest will suffice, such as a subject area model or an entity-relation model without attributes. The term logical data model is used here in this context, regardless of the level of detail the model exhibits.

The architecture data elements for OV-7 include descriptions of entity, attribute, and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the architecture.

Operational Event-Trace Description

OV-6c Template

Product 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 should have an accompanying description that defines the particular scenario or situation.

Product Purpose. OV-6c is valuable for moving to the next level of detail from the initial operational concepts. The product helps define node interactions and operational threads. The OV-6c can also help ensure that each participating operational node has the necessary information it needs at the right time in order to perform its assigned operational activity.

Product Detailed Description. OV-6c allows the tracing of actions in a scenario or critical sequence of events. OV-6c can be used by itself or in conjunction with OV-6b to describe the dynamic behavior of business 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 capability. In this manner, a capability is defined in terms of the attributes required to accomplish a given mission objective by modeling 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 capability.
Operational Event-Trace Description
Integrated architectures with DOTMLPF information provide a structured and organized approach for defining capabilities and understanding the underlying requirements for achieving those capabilities. By describing the sequence and timing of activities, tying them to the operational nodes (representing organizations or human roles), relating them to their supporting systems or system functions, and specifying the actions, events, and related guard conditions or business rules that constrain those activities, the full spectrum of DOTMLPF is modeled and related, so that analyses and decisions can be supported. Below is a detailed description of how DOTMLPF is tightly woven into this and related products.

Doctrine is represented as guard conditions, which are associated with events, which, in turn, map to controls in OV-5.
Organization is represented via the lifelines or swimlanes, which map to operational nodes of OV-2; which, in turn, map to organizations, organization types, or human roles of OV-4; and mechanisms in OV-5.
Training is represented via the lifeline or swimlane, since the operational node (shown on the dia gram as a lifeline or swimlane) may represent a human role, which, in turn, embodies a certain skill set or knowledge domain required to perform the actions (which are, in turn, related to operational activities of OV-5).
Materiel is tied to the elements in OV-6c because this product is tightly coupled with OV-5, where mechanisms may be used to represent systems that support operational activities. In addition, further materiel detail may be related to the activities via SV-5, by relating those activities to the system functions that are executed by systems that automate them (wholly or partially). Each operational thread or scenario (represented by an OV-6c) is associated with a certain capability, since a capability is defined in terms of the activities and their attributes depicted in OV-6c. Consequently, an SV-5 may also be used to relate a capability to the systems that support it, by labeling a set of activities with their associated capability (defined in OV-6c), and by labeling the system functions with the systems that execute them (defined in SV-1, SV-2, and SV-4).
Leadership may be represented either directly via the lifeline or swimlane or indirectly through the relationships of an operational node (shown as a lifeline or swimlane on the diagram) in OV-2 to organizations, organization types, or leadership human roles in OV-4.
Personnel may be represented directly via the lifeline or swimlane, or indirectly through the relationships of an operational node (shown as a lifeline or swimlane on the diagram) in OV-2 to organizations, organization types, or human roles in OV-4.
Facility is tied to the elements in OV-6c because the lifeline or swimlane representing an operational node is directly tied to the systems node (facilities) that house the systems, which may be shown as mechanisms that support operational activities.

Operational Activity Model (OV-5)

Operational Activity Model
OV-5 Template

Product Definition. The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. High- level operational activities should trace to (are decompositions of) a Business Area, an Internal Line of Business, and/or a Business Sub-Function as published in OMB’s Business Reference Model [OMB, 2003].

Product Purpose. OV-5 can be used to:

Clearly delineate lines of responsibility for activities when coupled with OV-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 OV-6a, OV-6b, and OV-6c
Product Detailed Description. OV-5 describes capabilities, operational activities (or tasks), I/O flows between activities, and I/O flows to/from activities that are outside the scope of the architecture.

The Framework does not endorse a specific modeling methodology. However, if the Integration Definition for Function Modeling (IDEF0) method [FIPS 183, 1993] is used, the activities also show controls (factors that affect the way that the activity is performed) and may show mechanisms (the resources, including operational nodes, that perform the activity). 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 OV may result in limiting system design and implementation decisions.

I/Os of operational activities relate to information elements of OV-3 and are further characterized by the information exchange attributes described in OV-3. I/Os that are produced or consumed by leaf operational activities that cross operational node boundaries are carried by needlines of OV-2. In addition, operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding operational node from OV-2. Annotations to the activities may also identify the costs (actual or estimated) associated with performing each activity. The business rules that govern the performance of the activities can also be keyed to each activity. (Business rules are described in OV-6a.) Annotations to OV-5s can further the purposes of the description by adding specific attributes of exchanged information, which can later be used in OV-3.

OV-5 is a key product for describing capabilities and relating capabilities to mission accomplishment. The DoD Dictionary of Military Terms [DoD JP 1-02, 2001] defines a capability as “the ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.)” A capability can be defined by one or more sequences of activities, referred to as operational threads or scenarios. A capability may be further described in terms of the attributes required to accomplish the set of activities (such as the sequence and timing of operational activities or materiel that enable the capability), in order to achieve a given mission objective. Capability-related attributes may be associated with specific activities or with the information flow between activities, or both. When represented by a set of operational activities, a capability can also be linked to an operational node in an OV-2.

Integrated architectures with Doctrine, Organization, Training, Materiel, Leadership & education, Personnel, and Facilities (DOTMLPF) information provide a structured and organized approach for defining capabilities and understanding the underlying requirements for achieving those capabilities. The full spectrum of DOTMLPF is modeled and related so that analyses and decisions can be supported by describing the sequence and timing of activities; tying them to the operational nodes (representing organizations or human roles); relating them to their supporting systems or system functions; and specifying the actions, events, and related guard conditions or business rules that constrain those activities. Below is a detailed description of how DOTMLPF is tightly weaved into this and related products.

Doctrine is represented as controls (or guard conditions) in OV-5.
Organization is represented via the operational nodes of OV-2, which can be shown as mechanisms (or annotations to the activities) in OV-5.
Training is represented via the operational node, which may represent a human role which in turn, embodies a certain skill set or knowledge domain required to perform the activities, which are, in turn, related to operational activities of OV-5.
Materiel is tied to the elements in OV-5, where mechanisms may be used to represent systems that support operational activities. In addition, further materiel detail may be related to the activities via SV-5, by relating those activities to the system functions that are executed by systems that automate them (wholly or partially). Each operational thread or scenario (represented by an OV-6c) is associated with a certain capability, since a capability is defined in terms of the activities and their attributes depicted in OV-6c. Consequently, an SV-5 may also be used to relate a capability to the systems that support it, by labeling a set of activities with its associated capability (defined in OV-6c), and by labeling the system functions with the systems that execute them (defined in SV-1, SV-2, and SV-4).
Leadership may be represented indirectly in OV-5 by first mapping activities to operational nodes via mechanisms and through the relationships of an operational node in OV-2 to organizations, organization types, or leadership human roles in OV-4.
Personnel may be represented indirectly through the relationships of an operational node in OV-2 to organizations, organization types, or human roles in OV-4.
Facility is tied to OV-5, because an operational node is directly tied to the systems nodes (facilities) that house the systems, which may be shown as mechanisms that support operational activities.
OV-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 OV-5 I/O flow model.

OV-5 is frequently used in conjunction with a process flow model (such as an IDEF3 model, or a UML sequence diagram) that describes the sequence and other attributes (e.g., timing) of the activities. A process flow model further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organization works. In addition, a process flow model may be annotated with the names of the operational nodes responsible for conducting those activities. A process flow model may be described in OV-6c.

The decomposition levels and the amount of detail shown on OV-5 should be aligned with the operational nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 products). It is important to note that OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the architecture as stated in AV-1.

1 2