11.2 What Is C4ISR?

11.2 What Is C⁴ISR?

The C⁴ISR Architecture Framework (C⁴ISR-AF) is a semantic framework for representing architectures in a consistent way [1]. It was conceived as a way of providing a common means to specify systems for the Department of Defense (DoD) in its many facets and programs. It is being updated by the DoD Architecture Framework Working Group (AFWG) into a new standard called the DoD Architecture Framework (DAF) [3,4]. As stated in the C⁴ISR-AF specification:

Architectures provide a mechanism for understanding and managing complexity. The purpose of C⁴ISR architectures is to improve capabilities by enabling the quick synthesis of "go-to-war" requirements with sound investments leading to the rapid employment of improved operational capabilities, and enabling the efficient engineering of warrior systems. The ability to compare, analyze, and integrate architectures developed by the geographical and functional, unified Commands, Military Services, and Defense Agencies (hereinafter also referred to as Commands, Services, and Agencies, or C/S/As) from a cross-organizational perspective is critical to achieving these objectives.

The C⁴ISR Architecture Framework is intended to ensure that the architecture descriptions developed by the Commands, Services, and Agencies are interrelatable between and among each organization's operational, systems, and technical architecture views, and are comparable and integratable across Joint and combined organizational boundaries.

The purpose of the C⁴ISR-AF is to provide assistance in the specification of architectures. Architecture itself has a number of definitions. The C⁴ISR-AF uses the definition of IEEE 610.12 [2]:

The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.

Architectures in the C⁴ISR-AF have three fundamental views: operational, systems, and technical. The emphasis in each of these views is, of course, different and distinct, but they overlap to a significant degree.

The operational view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation. This view includes doctrine (which in another environment might be called business rules), activities, and assignment of these activities to operational elements and the sequences and time frames of the execution of the activities. Operational architectures are usually independent of the systems used to implement them.

The systems view is a description of the systems and their interconnections providing for, or supporting, war-fighting functions. The systems view includes the large-scale elements and objects that interact to achieve the operational goals as well as their locations, interconnections, and so on. The systems involved may include key nodes (including materiel), networks (as well as interconnections and interfaces), war-fighting platforms, weapons systems, and so on, as well as their various qualities of service such as mean time between failures (MTBF), maintainability, speed, capacity, and availability. Systems described in the systems view can be used to achieve many different operational architectures, organizations, and missions. The systems view does depend on the underlying technology described in the technical view and is constrained by its limitations.

The technical view provides the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The technical view provides the basis for engineering specification of the systems in the systems view and includes technical standards. Put another way, the technical view is the engineering infrastructure that supports the systems view.

Within each of these architectural areas, the standard defines work products. The list of these products is given in Table 11-1. Each of these products will be discussed and in most cases a UML view that meets both the needs and intent of the product will be shown.

Table 11-1. DAF (C4ISR) Work Products^[1]

Applicable View	Framework Product	UML Views	Framework Product Name	General Description
All Views	AV-1	Descriptions, notes, text	Overview and Summary Information	Scope, purpose, intended users, environment depicted, analytical findings.
All Views	AV-2	Model repository, reports	Integrated Dictionary	Data repository with definitions of all terms used in all products.
Operational	OV-1	Class diagram, deployment diagram	High-Level Operational Concept Graphic	High-level graphical/ textual description of operational concept.
Operational	OV-2	Class diagram, deployment diagram	Operational Node Connectivity Description	Operational nodes, operationalactivities performed at each node, connectivity and information exchange need lines between nodes.
Operational	OV-3	Report from model repository	Operational Information Exchange Matrix	Information exchanged between nodes and the relevant attributes of that exchange.
Operational	OV-4	Class diagram	Command Relationships Chart	Organizational, role, or other relationships among organizations.
Operational	OV-5	Activity diagram, statechart, class diagram with flows	Operational Activity Model	Operational activities, relationships among activities, inputs and outputs. Overlays can show cost, performing nodes, or other pertinent information.
Operational	OV-6a	Sequence diagram, activity diagram, statechart	Operational Rules Model	One of the three products used to describe operational activity sequence and timing. Identifies business rules that constrain operation.
Operational	OV-6b	Statechart, activity diagram	Operational State Transition Description	One of three products used to describe operational activity sequence and timing. Identifies business process responses to events.
Operational	OV-6c	Sequence diagram, statechart, activity diagram	Operational Event-Trace Description	One of three products used to describe operational activity sequence and timing. Traces actions in a scenario or sequence of events and specifies timing of events.
Operational	OV-7	Class diagram	Logical Data Model	Documentation of the data requirements and structural business process rules of the operational view.
Systems	SV-1	Class diagram Text in descriptions	Systems Interface Description	Identification of systems and system components and their interconnections, within and between nodes.
Systems	SV-2	Class diagram	Systems Communications Description	Systems nodes and their related communications lay-downs.
Systems	SV-3	Class diagram, report on model	Systems-Systems Matrix	Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc.
Systems	SV-4	Use case diagram, class diagram with flows	Systems Functionality Description	Functions performed by systems and the information flow among system functions.
Systems	SV-5	Class diagram with dependencies, DOORS traceability matrix	Operational Activity to Systems Function Traceability Matrix	Mapping of systems back to operational capabilities or of system functions back to operational activities.
Systems	SV-6	Data flow on class diagram	Systems Data Exchange Matrix	Provides details of systems data being exchanged between systems.
Systems	SV-7	Class diagram with constraints for performance quality of service	Systems Performance Parameters Matrix	Performance characteristics of each system(s) hardware and software elements, for the appropriate timeframe(s).
Systems	SV-8	Activity diagram	Systems Evolution Description	Planned incremental steps toward migrating a suite of systems to a more efficient suite or toward evolving a current system to a future implementation.
Systems	SV-9	Text	Systems Technology Forecast	Emerging technologies and software/hardware products that are expected to be available in a given set of timeframes and that will affect future development of the architecture.
Systems	SV-10a	Statechart, activity diagram, sequence diagram	Systems Rules Model	One of three products used to describe systems activity sequence and timing. Constraints that are imposed on systems functionality due to some aspect of systems design or implementation.
Systems	SV-10b	Statechart	Systems State Transition Description	One of three products used to describe systems activity sequence and timing. Responses of a system to events.
Systems	SV-10c	Sequence diagram	Systems Event-Trace Description	One of three products used to describe systems activity sequence and timing. System-specific refinements of critical sequences of events and the timing of these events.
Systems	SV-11	Deployment diagram, class diagram	Physical Schema	Physical implementation of the information of the logical data model, e.g., message formats, file structures, physical schema.
Technical	TV-1	Hyperlinks in model, text	Technical Standards Profile	Extraction of standards that apply to the given architecture.
Technical	TV-2	Text	Technical Standards Forecast	Description of emerging standards that are expected to apply to the given architecture, within an appropriate set of timeframes.

^[1] There are a number of ways to map C4ISR products to the UML. This table represents one way proposed by the author.