 Welcome to Chapter 1, Video 3 of the FACE Data Model Learning Series, Data Model Example. This video will provide a simple example of a FACE data model. This video will present a small data model example that uses only the primary elements of the FACE data architecture. It will introduce you to the layers of the FACE data architecture and explain their value. As the data model progresses through the layers from conceptual through platform, the information provided is expanded and refined. The elements of the FACE data model at the conceptual through platform level provide contacts for and give meaning to the data exchanged by the FACE components. Queries and templates are used to specify how the model data is composed into messages. FACE components definitions describe components, attributes, and messages exchanged characteristics. This example is based on the concept of a relevant operating picture which consists of tactical items of interest within a geographic area associated with a specific mission. To further simplify the example, we will focus on only the mission-relevant area which associates a mission with zero or more geographic areas. The notation you are seeing is a custom notation developed by the FACE consortium for graphic representation of FACE data model elements. This notation is used throughout the FACE data model guidance and this video. The conceptual data model captures the semantic meaning of data elements using entities and associations that are each defined using characteristics. A relevant operating picture is defined as a geographic area relevant to a mission. Because of this connection between two basic concepts, area and mission, mission-relevant area is defined to be the association between the entity's area, geographic area, and mission. Each entity and association has at least one characteristic or ID, which is a unique identifier for the element. While no amplifying characteristics are added for mission, area is further defined to have a position and a bounding envelope or extent. The relationship between area and mission is defined by the association mission-relevant area. FACE associations can have two or more participants. Mission and area are the two participants in this association. For each participant, there are multiplicities associated to further characterize the relationship. The way to interpret the multiplicities shown here is for any mission-relevant area, there are exactly one area and one mission. This is indicated by the respective participant multiplicities labeled 1 to 1, nearest to the area and mission conceptual entities. Given any area, it can be a part of zero or more mission-relevant areas, as shown by the zero to star multiplicities. A given mission is associated with one or more mission-relevant areas, as shown by the one to star multiplicity. The conceptual data model captures the semantic meaning of the data elements through the use of observables to define the characteristics of each entity. Observables represent something perceived and measured in the physical world. Each has a description that defines the observable. In this example, there are three observables. Identifier, position, and extent. The diagram shows how characteristics in entities and associations are tight by the observables. The identifier observable is composed into all three of the relevant model elements, while only the characteristics in the area entity use the position and extent observables. Conformance to the face standard requires the use of a face consortium-governed shared data model, which is the sole source of the face conformance data model observables. The observables shown here, along with their definitions, were all drawn from the face shared data model for face 3.1. That was current at the time these examples were authored. A key feature of the face data modeling pattern is linkages between more concrete elements and more abstract elements. In this diagram, the logical entities and association are more refined representations of the conceptual entities and association. The diagram shows how the characteristics that were defined by the observables at the conceptual level are reflected in the corresponding characteristics at the logical level. The logical level refines the characteristics by applying measurements to the logical characteristics. The face data architecture uses the realization relationship as a semantic attribute that indicates the refinement relationship between logical elements and conceptual elements. This diagram shows the realization relationship between the logical entities and association and the corresponding conceptual entities and association. The logical level of the face data model refines conceptual observables by adding more specific details such as units, data types, and a frame of reference. These are captured in the measurement, measurement axis, measurement system, and value type unit elements. Realization relationships indicate the semantic relationship between logical and conceptual elements. In this example, the logical level type of all identifier characteristics is a unique ID unbound integer measurement, rephrase. In this example, the logical level type of all identifier characteristics is a unique ID unbounded integer measurement. The only axis to this measurement happens to realize the same observable as the measurement, but as we will see in subsequent examples, the observables realized for the axis elements are not necessarily the same as the observable realized by the measurement itself. The examples shown in this video are simplified and exclude some of the depth of the measurement portion of the logical metamodel. Full definitions of the measurement can be complex, but don't panic. The face share data model has many of the common logical measurement and their supporting elements, including the ones shown in this example defined for you. The logical level position measurement demonstrates the way the axis elements realize different observables than the measurement to which they belong. The measurement position WGS84 mes is a three-dimensional measurement with one axis for each of latitude, longitude, and altitude, or height. The measurement realizes the observable position, but the latitude and longitude axis each realize the angle observable as bounded degrees. And the height axis realizes the distance observable as meters. The logical extent mes has two axes, length and width. In this case, the measurement and its axis all realize the extent observable, but the measurement axis at the detail of the measurement is in meters, represented as non-negative real numbers. The realization of entities and associations from the logical to platform levels follows the same pattern as the realization from the conceptual to logical levels. We find their representation using platform level element types that realize the corresponding logical element types. The data types at the platform level mimic the structure at the logical measurement and translate the logical data types to platform data types. Because identifier is a single axis measurement, it can be represented as a single data type definition. The platform level unique identifier type realizes the logical unique ID unbounded integer mes measurement as a long. The position measurement consists of three axes at the logical level and so requires a more complex representation at the platform level. The position logical measurement is realized by a struct at the platform level. Each of the platform properties is typed by a platform level data element that realizes a corresponding logical axis. In this case, each of the platform properties types is a double. Because the extent logical measurement consists of multiple axes, the corresponding platform representation is a struct containing two properties. Each of the platform properties is typed by a long. For semantic traceability, each of the platform elements realizes the corresponding logical element. The purpose of a query is to select a subset of the data model for use in describing messages. It selects the characteristics of their relationship entities and associations that can be used as message data. Queries are defined using a SQL like language created by the face consortium for this purpose. The language looks like SQL, but it is not SQL. The full definition of the language can be found in the UDDL specification available through the open group. The query shown here is a very simple one. It identifies the position and extents of the area entity as being of interest. It aliases the extents characteristic to size and the area entity to AOI. Selecting all areas associated with a mission requires a more complex query. This query uses join statements to indicate how the mission and areas are connected through the mission relevant area association. The face data architecture uses templates to specify the message format in which data identifies by a query will be presented. A template is associated with a query through a bound query relationship. In this example, a template for a simple area of interest query formats the area of interest into a struct consisting of a position and extents, each of which is identified by the platform data types detailed previously. The face conformance test suite uses the information to create an intermediate IDL artifact that is later translated into a language specific header representing the message format. This is a template to format all areas of interest for a mission into a message struct. It first specifies that the position and size extents from area should be combined into the same structure. After that is defined, the template indicates that the mission ID is to be combined into a struct that also contains a series of the area type structs. The face data model includes the unit of portability or UOP model for describing the portable components segment PCS and platform specific services segment P-SSS software components that use the data in the rest of the model. Example values have been chosen for this video. For a full description of all options, see the face technical standard. A UOP describes at a minimum the programming language in which the software component has been written, the partition or operating system type, the face profile or level of safety security constraints to apply, the thread information and the random access memory requirements for the component and a connection to send or receive information in addition to describing the characteristics of the message exchange. The connection very importantly identifies the template describing the message to be exchanged. Because the template is connected to the rest of the data model, it has semantic traces that can be used to understand the message at integration time. In this video, you are introduced to a very simple example of a face data architecture model. In this video, you saw how entities and associations defined the structure of data, how data types were defined and how realization between the layers of the data model provided semantic context. In addition, you learned about message data identification using queries and message formatting using templates as well as component declarations through UOP elements. This demonstrated the contents of a complete, if small, face data architecture model. Thank you for watching video 3 in chapter 1. There is much more details to the face data models than demonstrated in this video, but this concludes a simple face data modeling example. The next video in this chapter is titled Data Modeling Resources from the Face Consortium and will describe where to find additional documentation and guidance.