DM2 Data Groups
A location is a point or extent in space. The need to specify or describe Locations occurs in some Architectural Descriptions when it is necessary to support decision-making of a core process. Examples of core process analyzes in which locations might have a bearing on the decisions to be made include the following:
- Base Realignment and Closure (BRAC) (SE process).
- Capability for a new regional command (JCIDS).
- Communications or logistics planning in a mission area (Ops process).
- System and equipment installation and Personnel Type assignments to Facilities (Operations and SE processes).
Examples where Locations play little, if any, role in the process are:
- Prioritization of precision engagement programs (PPBE and portfolio management processes).
- Streamlining of a business process (SE process).
- Doctrine development (JCIDS and Operations processes).
The role of Locations in the decision process was implicit in earlier versions of DoDAF. In this version, they are treated explicitly and precisely to allow more rigorous analysis of requirements (e.g., communications or logistics planning) and clearer differentiation among solutions alternatives).
Data Group Description
The DoDAF Meta-model for the data comprising Locations is shown in the figure below.
There are several items to note:
- Addresses such as URLs, Universal Resource Names (URNs), postal addresses, data link addresses, etc. are considered Names for Locations. For example, a postal address is a naming system for the Location of a building. A Universal Resource Locator is a name for a server that is located somewhere on the Web.
- The naming pattern works by identifying the following:
1) the name string,
2) the object being named, and
3) the type of name (e.g., postal address). Name here is used in the broadest sense, such that a description is considered a long name.
- The lower left of the diagram is a model of types of Location objects. These can be alternatively named using the naming pattern in the upper left and delineated using the Extent pattern in the lower right.
- Minimal parts of the Spatial Extent (Point, Line, Surface, and Solid Volume) are detailed because of the varying requirements within a federate. That is, member of the federate may need to specialize the Spatial Extents. Some common and simple classes are modeled, such as a Line described by two Points and a Planar Surface defined by a Line and Point.
- Facilities are types of Locations. In prior versions of DoDAF it was not clear if a Facility could be thought of as a system or just a Location. This is now clarified. To describe the functionality of a Facility, the Activities performed by the Performers located at the Facility are described.
- Installation, Site, and Facility follow Army guidance from the Real Property Inventory Requirements (RIPR). Similarly, a Facility can be a linear structure, such as a road or pipeline.
- Geofeatures (called FEATURE in Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM)) cover man-made control features, as well as geophysical features (including meteorological and oceanographic phenomena).
DoDAF Meta Model for Locations
(Click image to enlarge)
Additional considerations in modeling Location data are as follows:
- For many architecture applications, a locating scheme is some kind of geometric system because many uses (see next paragraph) require geometric calculations.
- Named locations (e.g., facility, base, installation, region names) can be applicable since their use may be merely to describe where performance occurs. In addition, the naming pattern basically can use the name as a surrogate for the geometric location, such as postal addresses are rarely applicable to architectures.
- If a geometric system is needed, the coordinate system, reference frame, and units are chosen. The Geospatial Markup Language (GML) defines 26 different kinds of coordinate systems, including one called user defined. In many cases, a federate may choose reference to GML so issues like handed-ness and orientation don't have to be defined again.
- The accuracy should be determined. For many uses, Locations may not need to be as accurate as some Geospatial system can be, since the use calculation may have many approximations, assumptions, and minor influencing variables that are chosen to be ignored.
- In some cases, there may be need for speed and acceleration ranges. Since these are unusual, they are not part of the core DM2 but would be added as extensions for these kinds of models. The speed could be extended as an attribute or as a trajectory consisting of a set of spatial-temporal points, where the trajectory is a whole and the points are parts.
Usage in Core Processes
Data for Locations are used to describe where Performers perform. The Location concept supported the system node in DoDAF V1.0 and V1.5. In DoDAF V2.0, it is generalized and more precisely defined. Examples of the uses of the various types of Locations in all the core processes are:
- Facility Locations allow description that certain systems or organizations are located at a specific facility. Note that the function of the Facility is determined by the Activities performed by the Performers located at the Facility; that is, the Facility itself is not a Performer.
- Installation Locations allow descriptions of certain organizations that operate or use an installation.
- Region Locations are used to describe what Performers and Activities are performed in certain regions.
- A Point Location can be used to state when a Performer is located at a specific Point; e.g., latitude and longitude. When the location is not that specific, Regions, Countries, and other geometric shapes can be used.
- Line (set of lines) allows description of Performers located on, beside, or within some enclosing lines. The line could be described mathematically so that it could specify an orbit, e.g., that certain satellites are in some orbit.
- Volume, e.g., that some systems cover a certain volume; e.g., an air defense system.
- Addresses (names for locations) allow descriptions of where something is located using the address scheme; e.g., the URL address scheme allows for looking up the internet protocol (IP) and then the files on the server.
Location is typically represented in architecture in pictorial diagrams, however tabular and other representations may be used depending on the "Fit-for-Purpose" application. In many instances, locations are depicted in conjunction with typical models and view used in architectural descriptions.