 Welcome to the second video in chapter one of the FACE data model learning series, Data Model Introduction. Last video we introduced you to the data model series. In this video we will explain a little bit about why we create data models and explain what a data model is. This video talks about data modeling. But what is a data model? A data model is a description of data. The data model answers what do you mean by questions about data in an unambiguous digital model, providing specificity and utility that might not exist in plain English descriptions. The FACE framework uses data models to document the messages used by interfaces between FACE components. All of the data models in this series relate to the FACE technical standard. So let's start there. The FACE technical standard provides a framework for portable software components. It defines architectural segments similar to the OSI stack categories for enhanced severability and portability of individual software components. Interfaces that govern the way software components communicate across segments. Requirements of each software component based on the segment into which it falls and factors such as safety and security constraints. Application, programming interfaces, or APIs for connecting software components. The data architecture as expressed in a data model must also be included for FACE conformance with specifying a unit of performance for ULC. In the portable components, transport services, or platform-specific services segments. The data model describes messages flowing over the interfaces between components in these segments. It must describe the components, data, and transport characteristics of all messages between components in the portable components segment and platform-specific services segment and must conform to the specifications for the FACE data models. This series will focus on only the data architecture model itself. The FACE data architecture provides semantic definitions of FACE software components and the data and format for those messages they exchange. This section provides only a brief description of the data architecture. More details are provided in later chapters. The FACE data architecture consists of a data model definition portion defined in the universal domain description language, or UDDL standard, and a unit of portability model, or UN portion. The data model portion defines the idea of a conceptual, logical, and platform data model, each of which refines the previous model. The FACE consortium provides and mandates the use of a shared data model, or SDM, that is the authoritative source for high-level conceptual model attributes and logical data model measurement and measurement systems. These are supplemented with additional conceptual, logical, and platform data element definitions provided by the software supplier. The FACE standard extends UDDL data model definition with component-specific data models to form the complete FACE data architecture. The additional data models are the unit of portability or UOP model, the integration model, and the traceability model. Of these, the only one required for a FACE component is the UOP model. The integration model and traceability model are optional and for integration purposes only. The UOP model defines messages based on the content of the data model and describes the components or UOCs that sends and receives the messages. The FACE consortium provides a conformance test suite, or CTS, to ensure conformance to the standard and the FACE data model is one input into the CTS. The CTS tests the data model for conformance and if it passes, uses the data model to generate artifacts such as code headers based on IDL mappings that are then used in software development. IDL, or Interface Definition Language, is a generic language created by the Object Management Group and is used in the conformance test suite to map the data models.FACE elements to software languages such as C, C++, Java, and ADA. For more information on IDL and how it's used in the CTS, please watch the CTS Learning Series on the Open Group's YouTube channel. Because the focus of this video series is the FACE data model, we will start with its primary data model components. This diagram shows the primary data modeling language elements for the Open Universal Domain Description Language Open UDDL that the FACE data model uses as its foundation. There are more details on the FACE data model than shown here. These details will be covered in a later video. Although not a formal distinction in the standard, the standard shows elements grouped by purpose into perspectives. Each perspective focuses on a unified aspect of a data model. As we move from left to right, the elements in a more concrete layer refine those in a more abstract layer. Let's look at these perspectives. The observation perspective is all about data types. Its elements are the ones that define the information types and measurements that are used to type entity and association characteristics. Characteristics may be thought of as attributes of the entities and associations. As we move from left to right, from conceptual to logical to platform, the refinement of those elements provides information that is additive. At the conceptual layer, there are only observables, things that can be observed like distance or orientation, which are characterized by only their names and their descriptions. These are refined to measurements at the logical level, including both the type of measurement, for example, distance or body frame attitude, and the logical characteristics needed to capture the measurements, for example, body frame attitude as pitch, roll, and yaw, each realizing the observable angle and measured in real degrees. At the platform level, each logical characteristic is refined to its machine-specific data type for use in data exchange. The entity association perspective is all about the things in the environment. It contains elements that define the meaning and context of application concepts and their relationships. An entity is the representation of a meaningful and separable element in the subject domain, such as an aircraft or track. Depending on the type of information being exchanged or stored, an entity might be decomposed into constituent entities such as aircraft wings, engines, or other composed entities. An association is the representation of a relationship between two or more entities. Examples are fuselage wing association and aircraft track association. Associations may have characteristics of their own to further describe the way entities are related. As we move from left to right, the conceptual to logical to platform, the elements refine the next higher level of abstraction by applying level-appropriate types. As refinement occurs, the logical or platform entities and associations may prune characteristics that are not relevant to the system being described or may expound to the multiple representations of the characteristics described at higher levels of abstraction. Entities and associations, along with characteristics typed by observation perspective elements, provide a complete description of the things in a problem domain and how they relate to each other. The traces between the levels from platform back to conceptual provide a means of comparison between two elements from different models that enables easy integration. The application perspective transforms the things described and the other two perspectives into information organized for use in interfaces and their integration. It contains views that identify pertinent data from the entities and associations into dataset descriptions for the messages to be exchanged in a software component interface. The characteristics selected by the views can be traced back to the entities and associations described by the other perspectives to determine exactly to what each data element in a message refers. The data types of the selected characteristics can be used to determine what conversions are needed to adapt messages from two different systems for interface to each other. The phase data architecture includes elements beyond the phase data model. The phase standard expands beyond the data model to describe how it applies to phase components known as UOCs or UOPs, some important terminology. A phase unit of conformance or UOC is the phase term for a phase conformant software component. A unit of portability or UOP is a unit of conformance or UOC that resides in the Portable Components segment, PCS, or Platform Specific Services segment, P-SSS. The phase standard requires UOPs to provide data models that describe the software components and the data they exchange. These data models are known as UOP-specific models or USMs. A USM includes all of the information shown in this diagram plus a traceability model which is not shown. A phase UOP-specific model always includes a UOP model. The integration and traceability models are optional. The UOP model in the phase USM describes the connection pertinent aspects of phase software components. These aspects include characteristics of the software such as the security level expressed in the phase profile attribute and the amount of memory required, as well as what kind of data exchanges the UOP engages in and the message that they get. The message type associated with a connection draws data from the platform level application perspective query and refines it into a message format for artifact generation. The phase conformant test suite or the CTS leverages these data model elements to generate interface definition language or IDL that is used to generate programming language-specific headers for the message exchanges. The integration model is optional in the USM and is rarely used. It is meant to document the transformations of data between two or more software components when integrating them. It serves to provide information to the integrator. There are two types of primary elements in the integration model. The integration UOPs are realizations of UOPs described in the UOP model and serves as the origin and destination endpoints of an integration path. The transformation elements describe data changes that must take place between origin and destination UOPs in order for the integration to be successful. The phase traceability model identifies traceable elements which contain traceability points to provide meaningful information about the way a data model element connects to external elements such as relevant standard or data model elements in other USMs. This image shows the metamodel elements that are traceable elements. At the time of this video's creation, the FACE consortium had no graphical notation for traceability models. The traceability model is optional in a FACE USM. We've seen now what kind of information is in the FACE data model. What are the benefits that offset the cost of data model development? Why create a data model? We create data models to document our interfaces. Sometimes systems are created not by us, but by others and interfaces are only provided. Human language interface descriptions may not provide the semantic accuracy of a data model. By using the data models of the interfaces without getting access to the code, engineers can still understand to what the message data refers and how it is measured and recorded. Digital representation of data models such as the ones required by the FACE standard enabled tools to ingest and analyze the data models. By comparing the semantic contents of one data model against another using a common set of observables as in the FACE shared data model, the tools can aid integration by recommending mappings between the message elements and different systems regardless of the field or element names used by the different systems. Because tooling can parse the language used to specify queries and templates, tools enhance the repeatability of their interpretation removing human error from the process. The inclusion of common measurements and documentation of the conversions between them in the model makes it possible for a tool to combine the data mappings with conversions to generate integration code or pseudocode. There are already tools that show message overlap between two data models. Integration automation tools are not fully mature yet but are being worked on. When it's time to upgrade or update or integrate a new system, systems can be matched at the interfaces. System engineers can easily identify where connections can be made, updates need to happen, or conflicts will occur before deploying entire systems to the fleet. Imagine connecting two systems, both tracking position but one system using degrees and the other system using radians. The data model would indicate both the commonality position described as latitude, longitude, and altitude expressed as double-position floating point numbers and the differences measurement in degrees versus radians between the messages. Once the differences between the messages are identified, it becomes clear that the two systems cannot directly communicate without error even though they are using the same interfaces. There needs to be an adapter added to convert the radians to degrees or degrees to radians otherwise the values will be too skewed to make sense to either system. The UDDL data model provides a mechanism to document this conversion. Once an adapter is put in place, data can freely flow between these two systems. Using the interfaces already in place, neither system A or B would have to make any changes. All that was needed was to insert an adapter application between the two to intercept the interfaces making the necessary translation and pass along the new values and being able to find this early in the data modeling or documentation process saves time and money. In this video we presented an overview of the FACE technical standard discussed at a high level what a data model is and why people create them, discussed the different parts of the FACE data model and showed the FACE data architecture extensions beyond data descriptions. This concludes chapter one video two. Thank you for watching. For the next video, video three, we will look at an example of a data model.