Face Technology PDF

Open Group Guide
Reference Implementation Guide for

FACE™ Technical Standard, Edition 2.1
You have a choice: you can either create your own future, or you can become the victim of a future
that someone else creates for you. By seizing the transformation opportunities, you are seizing the
opportunity to create your own future.
Vice Admiral (ret.) Arthur K. Cebrowski
NAVAIR Public Release 2015-268

Distribution Statement A –“Approved for public release; distribution is unlimited”
Copyright © 2016, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any
part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent
or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed
as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The
Open Group, and may not be licensed hereunder.
This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the
above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to
these publications; these changes will be incorporated in new editions of these publications. The Open Group may make
improvements and/or changes in the products and/or the programs described in these publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or
the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall
have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the
information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques
contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing
products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of
this publication may be downloaded at www.opengroup.org/bookstore.
In the event of any discrepancy between text in this document and the official FACE Technical Standard, the FACE Technical
Standard remains the authoritative version for certification, testing by examination, and other purposes. The official FACE
Documents and Tools can be obtained at www.opengroup.org/face.
Open Group Guide

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1
ISBN: 1-937218-73-7
Document Number: G162
Published by The Open Group, April 2016.

Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to:
[email protected]
ii Open Group Guide (2016)

Contents
1 Introduction ............................................................................................................... 1
1.1 Background ..................................................................................................... 1
1.2 FACE Approach ............................................................................................. 1
1.3 Scope of this Document .................................................................................. 2
1.4 FAQs ............................................................................................................... 2
2 Segment Guidance .................................................................................................... 4

2.1 Introduction..................................................................................................... 4
2.2 Operating System Segment ............................................................................. 5
2.2.1 Partitioning ...................................................................................... 6
2.2.2 File System ...................................................................................... 9
2.2.3 APIs and Profiles ........................................................................... 11
2.2.4 Health Monitoring/Fault Management .......................................... 11
2.2.5 Configuration Services .................................................................. 12
2.2.6 Inter-Partition Communications .................................................... 12
2.2.7 Intra-Partition Communications .................................................... 13
2.2.8 Local Memory Allocation/Deallocation ........................................ 13
2.2.9 Shared Memory ............................................................................. 16
2.2.10 Multi-Process................................................................................. 18
2.2.11 Multi-Threading ............................................................................ 18
2.2.12 Operating System Input/Output (I/O) Support .............................. 19
2.2.13 Networking .................................................................................... 19
2.3 I/O Services Segment.................................................................................... 20
2.3.1 Key Characteristics........................................................................ 21
2.3.2 Configurability .............................................................................. 21
2.3.3 Variability...................................................................................... 25
2.4 Platform-Specific Services Segment............................................................. 32
2.4.1 Platform-Specific Services Segment External
Interfaces ....................................................................................... 33
2.4.2 Platform-Specific Device Services ................................................ 33
2.4.3 Platform-Specific Common Services ............................................ 41
2.4.4 Platform-Specific Graphics Services ............................................. 44
2.5 Transport Services Segment ......................................................................... 45
2.5.1 Key Characteristics........................................................................ 46
2.5.2 Configurability .............................................................................. 85
2.5.3 Variability...................................................................................... 89
2.5.4 TS Interface and Type Safety ........................................................ 98
2.6 Portable Components Segment ................................................................... 100
2.6.1 Key Characteristics...................................................................... 100
2.6.2 Configurability ............................................................................ 101
2.6.3 Variability.................................................................................... 101
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 iii
3 Functional Decomposition into UoPs ................................................................... 102
3.1 Introduction................................................................................................. 102
3.2 Portable Components Segment UoPs ......................................................... 103
3.3 Transport Services Segment UoPs .............................................................. 104
3.4 Platform-Specific Services Segment UoPs ................................................. 105
3.5 UoP Packaging............................................................................................ 105
3.6 Data Rights ................................................................................................. 106
4 FACE Profile Guidance ........................................................................................ 107

4.1 Introduction................................................................................................. 107
4.2 Strategy ....................................................................................................... 107
4.3 Migration Between FACE Profiles ............................................................. 108
4.4 Adaptation of Legacy Operational Flight Programs to FACE
Profiles ........................................................................................................ 108
5 Data Architecture Guidance .................................................................................. 111

5.1 Why Data Modeling? .................................................................................. 111
5.2 Overview of Modeling Concepts ................................................................ 113
5.3 Data Modeling Examples............................................................................ 115
5.3.1 Overview of Example .................................................................. 115
5.3.2 Model Organization..................................................................... 117
5.3.3 Overview of Key Data Modeling Tasks ...................................... 118
5.3.4 Modeling Navigation Management ............................................. 119
5.4 Considerations for Conformance ................................................................ 129
6 Health Monitoring/Fault Management Guidance ................................................. 131

6.1 Overview..................................................................................................... 131
6.1.1 HMFM Areas Addressed by the FACE Technical
Standard ....................................................................................... 131
6.1.2 HMFM Areas Beyond the FACE Technical Standard ................ 131
6.2 Role of Board Support Packages ................................................................ 132
6.3 HMFM Layering ......................................................................................... 133
6.3.1 Hardware-Detected Faults ........................................................... 133
6.3.2 Application Detected Faults ........................................................ 134
6.3.3 Computing Platform Health Manager ......................................... 134
6.3.4 External Systems ......................................................................... 134
6.4 OS Configurations ...................................................................................... 134
6.4.1 ARINC 653 OS ........................................................................... 135
6.4.2 Pure ARINC 653 OS ................................................................... 135
6.4.3 POSIX on ARINC 653 OS .......................................................... 135
6.4.4 POSIX OS ................................................................................... 135
6.4.5 FACE HMFM Services API........................................................ 135
6.5 HMFM Event Flow..................................................................................... 136
6.6 HMFM Implementation Guidance.............................................................. 138
6.6.1 Implementation on ARINC 653 OS ............................................ 138
6.6.2 Implementation on ARINC 653 OS with POSIX APIs ............... 138
6.6.3 Implementation on Pure POSIX OS ............................................ 138
6.7 HMFM and Non-Volatile Storage .............................................................. 140
iv Open Group Guide (2016)

6.8 Fault Handler Guidance .............................................................................. 141
7 Graphics Services Guidance ................................................................................. 143

7.1.1 OpenGL – 2D and 3D Imaging ................................................... 143
7.1.2 ARINC 739 and 739A-1.............................................................. 144
7.1.3 ARINC 661 ................................................................................. 144
7.1.4 Variability.................................................................................... 147
8 Configuration Services Guidance ......................................................................... 152

8.1 Introduction................................................................................................. 152
8.2 FACE Configuration Categories ................................................................. 152
8.2.1 No Software Configurability Available....................................... 152
8.2.2 Legacy Local Configuration ........................................................ 152
8.2.3 API-Based Configuration ............................................................ 153
8.2.4 Hybrid Configuration .................................................................. 154
8.3 Recommended Configuration Services Artifacts........................................ 154
8.3.1 Component Configurability Definition ....................................... 155
8.3.2 Component Configuration Set ..................................................... 158
8.3.3 Configuration Set Identifier List ................................................. 158
8.3.4 Configuration Set Encoding Package .......................................... 161
8.3.5 Configuration Services API......................................................... 162
9 Language Run-Time Guidance ............................................................................. 164

9.1 Introduction................................................................................................. 164
9.2 Compiler Tools ........................................................................................... 165
9.3 Additional Considerations .......................................................................... 165
10 Safety Guidance .................................................................................................... 167
11 Security Guidance ................................................................................................. 168

11.1 Introduction................................................................................................. 168
11.1.1 Basic Security .............................................................................. 169
11.2 Security Architecture .................................................................................. 169
11.3 Process ........................................................................................................ 170
11.3.1 Risk Management ........................................................................ 171
11.3.2 Software Assurance ..................................................................... 171
11.4 Certification ................................................................................................ 173
11.4.1 Methodology ............................................................................... 173
11.4.2 Certification Example.................................................................. 174
11.5 Example Scenario ....................................................................................... 174
11.5.1 Scenario B ................................................................................... 175
11.6 Encryption/Decryption................................................................................ 176
12 Implementation Scenario Examples ...................................................................... 178

12.1 Communications Manager Scenario ........................................................... 178
12.1.1 Introduction ................................................................................. 178
12.1.2 Scope ........................................................................................... 178
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 v

12.1.3 Assumptions ................................................................................ 180
12.1.4 Environment ................................................................................ 181
12.2 Digital Map Manager Scenario ................................................................... 187
12.2.1 Introduction ................................................................................. 187
12.2.2 Scope ........................................................................................... 188
12.2.3 Assumptions ................................................................................ 189
12.2.4 Environment ................................................................................ 190
12.3 Required Navigation Performance Manager Scenario................................ 199
12.3.1 Introduction ................................................................................. 199
12.3.2 Scope ........................................................................................... 200
12.3.3 Assumptions ................................................................................ 201
12.3.4 Environment ................................................................................ 202
12.4 Secure Reporting Status Scenario ............................................................... 211
12.4.1 Introduction ................................................................................. 211
12.4.2 Scope ........................................................................................... 213
12.4.3 Assumptions ................................................................................ 214
12.4.4 Environment ................................................................................ 215
A Example of a FACE Conformant Implementation ................................................ 221

A.1 Common Operating Picture Demo.............................................................. 221
A.1.1 COP Demo Architecture ............................................................. 221
A.2 Code Excerpts ............................................................................................. 221
A.2.1 Data Structures ............................................................................ 221
A.2.2 Platform-Specific Services Code (GPS Sensor) .......................... 222
A.2.3 Portable Component Code (Guidance System) ........................... 230
B FACE Data Model UML Profile ........................................................................... 233

B.1 FACE Data Model UML Profile Overview ................................................ 233
B.2 FACE Data Model UML Profile Detail ...................................................... 234
B.3 FACE Data Model UML Profile for Enterprise Architect (XMI
Format) ....................................................................................................... 278
B.4 FACE Data Model UML Profile for Eclipse (XMI Format) ...................... 286
C Configuration Services API .................................................................................. 310

C.1 Introduction................................................................................................. 310
C.2 Configuration Services API and Message Definitions ............................... 310
C.3 Configuration Initialization Service............................................................ 313
C.4 Configuration Open Service ....................................................................... 314
C.5 Configuration Read Service ........................................................................ 315
C.6 Configuration Seek Service ........................................................................ 316
C.7 Configuration Close Service ....................................................................... 317
D Standard Color Index ............................................................................................ 319
E XSD Schema for Configuration File ..................................................................... 325

E.1 Schema ........................................................................................................ 325
vi Open Group Guide (2016)

F Safety Guidance .................................................................................................... 327
F.1 Safety Overview ......................................................................................... 327
F.2 Purpose ....................................................................................................... 328
F.3 Applicability ............................................................................................... 328
F.4 Safety Assessment and Design Assurance Level ........................................ 329
F.4.1 Start Assessment Very Early and Update as the
Program Progresses ..................................................................... 329
F.5 Design Assurance Level and Qualification Cost are Directly
Proportional ................................................................................................ 330
F.5.1 Assess Criticality During First Application, or as Part
of a Notional Application ............................................................ 330
F.5.2 Plan for Future Use of Functionality at a Higher
Design Assurance Level .............................................................. 330
F.5.3 Safety Assessment May Vary by Context ................................... 331
F.5.4 Plan for the Most Critical Application ........................................ 331
F.5.5 Safety Assessment of Configurable Software ............................. 331
F.6 Qualification Advantage of Various Software Reuse Strategies ................ 332
F.6.1 Basic Principles of Software Qualification ................................. 332
F.6.2 Additional Qualification Considerations ..................................... 333
F.6.3 Memory Management ................................................................. 333
F.6.4 File Management ......................................................................... 334
F.6.5 Concurrency Management (Semaphores, Mutexes).................... 334
F.7 Overview of the Principles of Portable Software ....................................... 334
F.7.1 Documentation of Early Agreement ............................................ 334
F.7.2 Specific Achievements for Portable Software during
the First Qualification.................................................................. 335
F.7.3 Achievements Remaining for Re-Application of
Portable Software ........................................................................ 335
F.7.4 Qualification of Portable Software as Part of a System
Qualification ................................................................................ 335
F.8 Types of Reuse............................................................................................ 336
F.8.1 Binary Reuse ............................................................................... 336
F.8.2 Source Code Reuse...................................................................... 336
F.8.3 Reuse of Artifacts ........................................................................ 336
F.9 Types of Artifacts ....................................................................................... 336
F.9.1 Requirements ............................................................................... 336
F.9.2 Tests ............................................................................................ 338
F.9.3 Traceability.................................................................................. 338
F.9.4 IRS/IDD/ICD............................................................................... 339
F.9.5 Software Accomplishment Summary .......................................... 339
F.10 Reuse of Tests ............................................................................................. 340
F.10.1 Reuse of Manual Tests ................................................................ 340
F.10.2 Reuse of Automated Tests ........................................................... 340
F.11 Consideration of Archival of Artifacts in the FACE Repository
or Reference ................................................................................................ 341
F.12 Coordination of Qualification ..................................................................... 341
F.12.1 Early Agreement and Documentation Facilitates
Efficient Qualification ................................................................. 341
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 vii
F.13 Segregation of Software Components ........................................................ 342
F.13.1 Segregation for Variability .......................................................... 343
F.13.2 Segregation for Criticality ........................................................... 343
F.13.3 Spatial/Temporal Partitioning (ARINC 653) .............................. 344
F.14 Limiting Qualification Impacts Through Configurability .......................... 345
F.14.1 Safety and Configuration Files (using Deactivated
Code) ........................................................................................... 345
F.14.2 Pre-Qualified Selection of Options at Run-Time
(including Initialization) .............................................................. 346
F.14.3 Dead Code versus Deactivated Code .......................................... 346
F.15 Test Programs ............................................................................................. 347
F.15.1 Requirements-Based Testing ....................................................... 347
F.15.2 Low-Level Software Requirements Testing ................................ 348
F.15.3 High-Level Software Requirements Testing ............................... 348
F.15.4 System Integration Testing .......................................................... 348
F.15.5 Hardware Integration Testing ...................................................... 349
F.15.6 Configuration and Setup Testing ................................................. 349
F.15.7 Information Interface Testing ...................................................... 350
F.15.8 Type Consistency Testing ........................................................... 350
F.15.9 Protocol Header Testing .............................................................. 350
F.15.10 Data Integrity Testing.................................................................. 350
F.15.11 Robustness Testing ...................................................................... 350
F.16 Lifecycle Support ........................................................................................ 351
F.16.1 Distribution of Software Maintenance Releases ......................... 352
F.16.2 Collection of Problem Reports .................................................... 352
F.16.3 Dissemination of Problem Reports .............................................. 352
F.16.4 Software Loading Instructions .................................................... 352
F.16.5 Software Compilation Instructions .............................................. 352
F.16.6 Software Users Manual ............................................................... 352
F.17 Documentation ............................................................................................ 353
F.18 Model-Based Engineering of Software ....................................................... 354
F.19 Special Considerations for the Use of Run-Times and
Frameworks ................................................................................................ 354
F.19.1 Language Run-Times .................................................................. 354
F.19.2 Frameworks ................................................................................. 355
F.20 Conclusion .................................................................................................. 356
G FACE Framework Interface .................................................................................. 357

G.1 Component/Conatainer to FACE API Mappings ....................................... 357
G.1.1 PCS Interface Mapping ............................................................... 357
G.1.2 Platform-Specific Services Segment Interface
Mapping ...................................................................................... 358
G.1.3 Data Modeling Framework Interfaces ......................................... 359
G.1.4 Component Assembly ................................................................. 361
G.1.5 Reuse Benefits ............................................................................. 362
G.2 Example API Implementations ................................................................... 363
G.2.1 Initialize Function........................................................................ 363
G.2.2 Create_Connection Function ....................................................... 364
viii Open Group Guide (2016)

G.2.3 Destroy_Connection Function ..................................................... 369
G.2.4 Receive_Message Function ......................................................... 370
G.2.5 Send_Message Function .............................................................. 372
G.2.6 Register_Callback Function ........................................................ 373
G.2.7 Unregister_Callback Function ..................................................... 374
G.2.8 Get_Connection_Parameters Function ........................................ 374
H Example USM FACE XMI ................................................................................... 376
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 ix

List of Figures
Figure 1: FACE Terminology ........................................................................................................ 3
Figure 2: FACE 3D Architectural Segments .................................................................................. 5
Figure 3: I/O Services Segment Capabilities................................................................................ 20
Figure 4: Non-Distributed Data Writing Flow ............................................................................. 26
Figure 5: Non-Distributed Data Reading Flow ............................................................................ 27
Figure 6: Distributed Data Writing Flow ..................................................................................... 29
Figure 7: Distributed Data Reading Flow .................................................................................... 30
Figure 8: Distributed and Non-Distributed Data Flow ................................................................. 31
Figure 9: Multiple Buses in One Service ..................................................................................... 32
Figure 10: PSS Communication ................................................................................................... 33
Figure 11: PDS EGI Example ...................................................................................................... 36
Figure 12: EGI Manager Display Manager Communication Thread ........................................... 37
Figure 13: EGI PDS Implementation with Callbacks .................................................................. 38
Figure 14: EGI Manager with Two Hardware Components ........................................................ 40
Figure 15: PDS – Two EGI Manager Example ............................................................................ 41
Figure 16: Device Protocol Mediation Service ............................................................................ 43
Figure 17: Streaming Media Service ............................................................................................ 44
Figure 18: Transport Services Segment Capabilities ................................................................... 45
Figure 19: Transport Services Interface Message and Internal Data Structure ............................ 46
Figure 20: Inter-Partition Communication ................................................................................... 89
Figure 21: Central Distributor ...................................................................................................... 90
Figure 22: Inter-Processor TSS Data Model Example ................................................................. 92
Figure 23: Message Paradigm Translation ................................................................................... 93
Figure 24: Protocol Paradigm Translation ................................................................................... 94
Figure 25: TSS Protocol Translation (Centralized) ...................................................................... 95
Figure 26: TSS Protocol Translation (Distributed) ...................................................................... 95
Figure 27: TSS Message Paradigm Translation (Centralized) ..................................................... 96
Figure 28: TSS Message Paradigm Translation (Distributed)...................................................... 97
Figure 29: TSS Buffering ............................................................................................................. 97
Figure 30: FACE TSS Architecture ............................................................................................. 99
Figure 31: Portable Components ................................................................................................ 100
Figure 32: System-Level Monolithic UoP ................................................................................. 103
Figure 33: Sub-System-Level UoP............................................................................................. 103
Figure 34: Mission-Level UoP ................................................................................................... 104
Figure 35: TSS UoPs .................................................................................................................. 105
Figure 36: PSSS UoPs ................................................................................................................ 105
Figure 37: Valid UoP Packages .................................................................................................. 106
Figure 38: FACE Profile Diagram ............................................................................................. 107
Figure 39: Adaptation of Legacy OFPs to the FACE Architecture ............................................ 109
Figure 40: Data Architecture Terms ........................................................................................... 111
Figure 41: Basis for Data Model Example ................................................................................. 116
Figure 42: Conceptual Entities Required for Navigation Management Component .................. 120
Figure 43: Orientation and Position Observables ....................................................................... 121
x Open Group Guide (2016)

Figure 44: Orientation and Position Measurements ................................................................... 122
Figure 45: Pitch, Roll and Yaw Measurements .......................................................................... 123
Figure 46: Altitude, Longitude, and Latitude Measurements ..................................................... 123
Figure 47: Logical Navigation Management Entities and Associations .................................... 124
Figure 48: Logical Views and Projections for the Navigation Manager Component ................ 125
Figure 49: Platform Data Types for the Position Measurement ................................................. 126
Figure 50: Physical Data Types for the Orientation Measurement ............................................ 126
Figure 51: Platform Navigation Management Entities and Associations................................... 127
Figure 52: Platform Views and Projections for the Navigation Manager Component............... 128
Figure 53: UoP Model for the Navigation Manager Component ............................................... 129
Figure 54: HMFM Board Support Package and Real-Time Operating System Relationship .... 132
Figure 55: HMFM Layering ....................................................................................................... 133
Figure 56: HMFM Event Flow ................................................................................................... 137
Figure 57: GLX Server Distributed Graphics Communication .................................................. 148
Figure 58: OpenGL Non-Distributed Graphics Communication ............................................... 149
Figure 59: ARINC 739 Server Distributed Graphics Communication....................................... 150
Figure 60: ARINC 661 Server Distributed Graphics Communication....................................... 151
Figure 61: Legacy Local Configuration ..................................................................................... 153
Figure 62: FACE API-Based Local Configuration .................................................................... 153
Figure 63: CSIL Schema Pictorial Representation ..................................................................... 159
Figure 64: Configuration Data Container ................................................................................... 163
Figure 65: Language Run-Time Options.................................................................................... 164
Figure 66: Software Assurance Security Requirements Flow .................................................... 172
Figure 67: Security Requirement Elaboration Example ............................................................. 173
Figure 68: DIACAP Alignment and Activities .......................................................................... 174
Figure 69: Scenario B Component Robustness Levels .............................................................. 176
Figure 70: Encryption/Decryption Example .............................................................................. 177
Figure 71: Communication Manager Operational View ............................................................ 178
Figure 72: Communication Manager Functional View .............................................................. 179
Figure 73: Communication Manager Physical View ................................................................. 180
Figure 74: Communications Manager Partition View ................................................................ 187
Figure 75: Digital Map Operational View.................................................................................. 188
Figure 76: Digital Map Functional View ................................................................................... 189
Figure 77: Digital Map Physical View ....................................................................................... 189
Figure 78: Digital Map Partition View ....................................................................................... 199
Figure 79: Required Navigation Performance Operational View .............................................. 200
Figure 80: Required Navigational Performance Functional View ............................................. 201
Figure 81: Required Navigational Performance Physical View ................................................. 201
Figure 82: Required Navigational Performance Partition View ................................................ 211
Figure 83: NSA SSE-100-1 Scenario B Reporting Status.......................................................... 212
Figure 84: Secure Reporting Status Operational View .............................................................. 213
Figure 85: Secure Reporting Status Functional View ................................................................ 213
Figure 86: Secure Reporting Status Physical View .................................................................... 214
Figure 87: Secure Reporting Status Partition View.................................................................... 219
Figure 88: Secure Reporting Status Data Flow View................................................................. 220
Figure 89: COP Demo Architecture ........................................................................................... 221
Figure 90: FACE PCS UoP as Framework Module ................................................................... 358
Figure 91: FACE PSS UoP a Framework Device Module ......................................................... 359
Figure 92: UoP Model of Lifecycle Messages ........................................................................... 360
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xi

Figure 93: Logical Model of Lifecycle Message........................................................................ 361
Figure 94: FACE Conformant Generic Framework Component ............................................... 362
Figure 95: FACE Conformant Generic Framework Component ............................................... 362
List of Tables
Table 1: Function Parameter Direction ........................................................................................ 50
Table 2: Mapping Between TSS FACE Return Codes and ARINC 653 Return Codes ............... 53
Table 3: Mapping Between TSS FACE Return Codes and POSIX Error Numbers .................... 54
Table 4: Mapping Between TSS FACE Return Codes and CORBA Exception Code ................ 56
Table 5: Mapping Between TSS FACE Return Codes and DDS Return Code............................ 57
Table 6: Initialize Return Codes ................................................................................................... 58
Table 7: Create Connection Return Codes ................................................................................... 59
Table 8: Create Connection Sampling Port Return Code Mapping ............................................. 60
Table 9: Create Connection Queuing Port Return Code Mapping ............................................... 60
Table 10: Create Connection Socket Return Code Mapping ....................................................... 62
Table 11: Create Connection Message Queue Return Code Mapping ......................................... 64
Table 12: Create Connection Shared Memory Return Code Mapping......................................... 65
Table 13: Create Connection CORBA Exception Code Mapping ............................................... 65
Table 14: Create Connection DDS Return Code Mapping .......................................................... 66
Table 15: Destroy Connection FACE Return Codes .................................................................... 67
Table 16: Destroy Connection ARINC 653 Ports Return Code Mapping.................................... 68
Table 17: Destroy Connection Socket Return Code Mapping ..................................................... 68
Table 18: Destroy Connection Message Queue Return Code Mapping ....................................... 69
Table 19: Destroy Connection Shared Memory Return Code Mapping ...................................... 69
Table 20: Destroy Connection CORBA Exception Code Mapping ............................................. 70
Table 21: Destroy Connection DDS Return Code Mapping ........................................................ 70
Table 22: Receive Message FACE Return Codes ........................................................................ 71
Table 23: Receive Message Sampling Port Return Code Mapping ............................................. 72
Table 24: Receive Message Queuing Port Return Code Mapping ............................................... 72
Table 25: Receive Message Socket Return Code Mapping ......................................................... 73
Table 26: Receive Message Message Queue Return Code Mapping ........................................... 74
Table 27: Receive Message Shared Memory Return Code Mapping........................................... 74
Table 28: Receive Message CORBA Exception Code Mapping ................................................. 74
Table 29: Receive Message DDS Return Code Mapping ............................................................ 75
Table 30: Send Message FACE Return Codes ............................................................................. 76
Table 31: Send Message Sampling Port Return Code Mapping .................................................. 77
Table 32: Send Message Queuing Port Return Code Mapping .................................................... 77
Table 33: Send Message Socket Return Code Mapping .............................................................. 78
Table 34: Send Message Message Queue Return Code Mapping ................................................ 79
Table 35: Send Message Shared Memory Return Code Mapping ............................................... 79
Table 36: Send Message CORBA Exception Code Mapping ...................................................... 80
Table 37: Send Message DDS Return Code Mapping ................................................................. 80
Table 38: Register Callback FACE Return Codes ....................................................................... 81
Table 39: Unregister Callback FACE Return Codes .................................................................... 82
xii Open Group Guide (2016)

Table 40: Get Connection FACE Return Codes........................................................................... 83
Table 41: Get Connection Sampling Port Return Code Mapping ................................................ 83
Table 42: Get Connection Queuing Return Code Mapping ......................................................... 83
Table 43: Get Connection Socket Return Code Mapping ............................................................ 84
Table 44: Get Connection Message Queue Return Code Mapping.............................................. 84
Table 45: Get Connection Shared Memory Return Code Mapping ............................................. 84
Table 46: Get Connection CORBA Exception Code Mapping .................................................... 85
Table 47: Get Connection DDS Return Code Mapping ............................................................... 85
Table 48: HM Options per OS Configuration ............................................................................ 136
Table 49: POSIX Signals Mapped to FACE Errors ................................................................... 139
Table 50: OpenGL Functional Behavior Specifications............................................................. 143
Table 51: OpenGL Safety Profile Specifications ....................................................................... 144
Table 52: ARINC 739 Functional Behavior Specifications ....................................................... 144
Table 53: ARINC 661-4 Functional Behavior Specifications .................................................... 145
Table 54: Configuration Parameter Example ............................................................................. 156
Table 55: Configuration Container Terminology ....................................................................... 159
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xiii
Preface
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives
through IT standards. With more than 500 member organizations, The Open Group has a diverse
membership that spans all sectors of the IT community – customers, systems and solutions
suppliers, tool vendors, integrators, and consultants, as well as academics and researchers – to:
 Capture, understand, and address current and emerging requirements, and establish
policies and share best practices
 Facilitate interoperability, develop consensus, and evolve and integrate specifications and
open source technologies
 Offer a comprehensive set of services to enhance the operational efficiency of consortia
 Operate the industry’s premier certification service
Further information on The Open Group is available at www.opengroup.org.
The Open Group publishes a wide range of technical documentation, most of which is focused
on development of Open Group Standards and Guides, but which also includes white papers,
technical studies, certification and testing documentation, and business titles. Full details and a
catalog are available at www.opengroup.org/bookstore.
Readers should note that updates – in the form of Corrigenda – may apply to any publication.
This information is published at www.opengroup.org/corrigenda.
This Document
This document is a Reference Implementation Guide to be used in conjunction with the

Technical Standard for Future Airborne Capability Environment (FACE™) Technical Standard,
Edition 2.1.
xiv Open Group Guide (2016)

Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, The Open Group®,
TOGAF®, UNIX®, UNIXWARE®, X/Open®, and the Open Brand X® logo are registered
trademarks and Boundaryless Information Flow™, Build with Integrity Buy with Confidence™,
Dependability Through Assuredness™, FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo,
O-DEF™, Open FAIR™, Open Platform 3.0™, Open Trusted Technology Provider™, Platform
3.0™, the Open O™ logo, and The Open Group Certification logo (Open O and check™) are
trademarks of The Open Group.
CORBA®, OMG®, UML®, and XMI® are registered trademarks and DDS™, MOF™, and
Unified Modeling Language™ are trademarks of Object Management Group, Inc. in the United
States and/or other countries.
Java® and Solaris® are registered trademarks of Oracle and/or its affiliates.
Linux® is a registered trademark of Linus Torvalds.
LynxOS® is a registered trademark of Lynx Software Technologies, Inc.
Microsoft® is a registered trademark of Microsoft Corporation in the United States and/or other
countries.
POSIX® is a registered trademark of the IEEE.
All other brands, company, and product names are used for identification purposes only and may
be trademarks that are the sole property of their respective owners.
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xv

Acknowledgements
The Open Group gratefully acknowledges the contribution of the following people in the
development of this document.
Principal Authors
 Kirk Avery, Lockheed Martin

 David Bowes, J.F. Taylor Inc.
 H. Glenn Carter, United States (US) Army AED
 James Davis, Institute for Software Integrated Systems (ISIS)
 Stan FitzGerald, J.F. Taylor Inc.
 Stuart Frerking, Institute for Software Integrated Systems (ISIS)
 Patrick Huyck, Green Hills Software
 William C. Kimmel, Naval Air Systems Command (NAVAIR)
 William Kinahan, Sikorsky
 Matthew Mueller, Naval Air Systems Command (NAVAIR)
 Joseph Neal, Harris Corporation
 Joel Sherrill, AMRDEC/Online Applications Research (OAR) Corporation
 Robert Sweeney, Naval Air Systems Command (NAVAIR), Technical Working Group
(TWG) Chair
 Jeffrey VanDorp, General Electric (GE) Aviation
 Michael Vertuno, Northrop Grumman
 Scott Wigginton, US Army Systems Engineering Directorate (SED)
Additional Contributors
 Judy Cerenzia, The Open Group

 Paul Chen, Wind River
 Robert Jefferies, Naval Air Systems Command (NAVAIR)
 Andrew Steffey, MITRE Corporation
With special thanks to W. Mark Vanfleet, National Security Agency (NSA).
xvi Open Group Guide (2016)

Referenced Documents
The following normative referenced documents are indispensable for the application of this
document. For dated references, only the edition cited applies. For undated references, the latest
edition of the referenced document (including any amendments) applies.
 AC 20-148: Reusable Software Components, Federal Aviation Authority (FAA), 2004.
 Aerospace Recommended Practice (ARP) 4754: Guidelines for Development of Civil
Aircraft and Systems (Revision A), SAE International, 2010.
 Aerospace Recommended Practice (ARP) 4761: Guidelines and Methods for Conducting
the Safety Assessment Process on Civil Airborne Systems and Equipment, SAE
International, 1996.
 Aeronautical Radio Inc. (ARINC) Specification 429: Mark 33 Digital Information
Transfer System (DITS), May 2004.
 Aeronautical Radio Inc. (ARINC) Specification 653, Avionics Application Software
Standard Interface, November 2010.
 Aeronautical Radio Inc. (ARINC) Report 661: Cockpit Display System Interfaces to User
System, May 2010.
 Aeronautical Radio Inc. (ARINC) Characteristic 739-1: Multi-purpose Control and
Display Unit (MCDU), June 1990.
 Aeronautical Radio Inc. (ARINC) Characteristic 739A-1: Multi-purpose Control and
Display Unit (MCDU), December 1998.
 Clinger-Cohen Act (CCA), US Federal Law, 1996 – formerly the Information Technology
Management Reform Act of 1996 (ITMRA).
 Committee on National Security Systems (CNSS) 4009: Information Assurance (IA)
Glossary, 2010.
 Common Criteria (CC) for Information Technology Security Evaluation, Version 3.1,
Release 3, July 2009. (This is equivalent to ISO/IEC 15408:2009.)
 Common Object Request Broker Architecture (CORBA) Specification, Version 3.3,
published by the Object Management Group (OMG), November 2012.
 Data Distribution Service (DDS) for Real-time Systems Specification, Version 1.2,
published by the Object Management Group (OMG), July 2001.
 Design Assurance Guidance For Airborne Electronic Hardware, DO-254, published by
Radio Technical Commission for Aeronautics (RTCA), April 2000.
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xvii
 Electronic Industries Alliance (EIA) J-STD-016-1995: IEEE Standard for Information
Technology – Software Lifecycle Processes – Software Development – Acquirer-Supplier
Agreement (withdrawn).
 Enterprise Integration Patterns, 2012; refer to: www.eaipatterns.com.
 Federal Information Security Management Act (FISMA), US Federal Law, 2002.
 Future Airborne Capability Environment (FACE™): Conformance Policy, X1303, June
2013, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/x1303.htm.
 Future Airborne Capability Environment (FACE™): Contract Guide, G145, December
2014, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/g145.htm.
 Future Airborne Capability Environment (FACE™): Shared Data Model Governance
Plan, X1405US, May 2014.
 IEEE Std 1003.1-2008: IEEE Standard for Information Technology – Portable Operating
System Interface (POSIX) – Base Specifications, Issue 7, December 1, 2008.
 IETF RFC 5424: The Syslog Protocol, March 2009; refer to:
http://tools.ietf.org/html/rfc5424.
 IETF RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog, March
2009; refer to: http://tools.ietf.org/html/rfc5425.
 ISO/IEC 12207:2008: Systems and Software Engineering – Software Lifecycle Processes.
 ISO/IEC 15408:2009: Information Technology – Security Techniques – Evaluation
Criteria for IT Security; refer to www.iso.org.
 ISO/IEC 24765:2010: Systems and Software Engineering Vocabulary.
 National Security Telecommunications and Information Systems Security Policy
(NSTISSP) No. 11: National Policy Governing the Acquisition of Information Assurance
(IA) and IA-Enabled Information Technology (IT) Products, National Security
Telecommunications and Information Systems Security Committee (NSTISSC), now
known as the Committee on National Security Systems (CNSS), January 2000 (revised
June 2003).
 NSA SSE-100-1: National Security Agency Information Assurance Guidance for Systems
Based on a Security Real-Time Operating System (RTOS), 2009.
 OSGi Service Platform, Release 4, Version 4.3, OSGi Alliance, 2012; refer to:
www.osgi.org/Release4.
 Software Considerations in Airborne Systems and Equipment Certification, DO-178B,
published by Radio Technical Commission for Aeronautics (RTCA) Inc., December 1992.
 Software Considerations in Airborne Systems and Equipment Certification, DO-178C,
published by Radio Technical Commission for Aeronautics (RTCA) Inc., January 2012.
xviii Open Group Guide (2016)

 Technical Standard for Future Airborne Capability Environment (FACE™), Edition 2.1,
C145, May 2014, published by The Open Group; refer to:
www.opengroup.org/bookstore/catalog/c145.htm.
 US Department of Defense Instruction (DoDI) 8500.1, Information Assurance (IA), 2002.
 US Department of Defense Instruction (DoDI) 8500.2: Information Assurance (IA)
Implementation, 2003.
 US Department of Defense Military Standards: MIL-STD-498 (cancelled 1998) and MIL-
STD-1553.
 XML Metadata Interchange (XMI) Specification, Version 2.4.2, published by the Object
Management Group (OMG), April 2014.
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xix
1 Introduction
1.1 Background
Today’s military aviation community airborne systems are typically developed for a unique set
of requirements by a single vendor. This form of development has served the military aviation
community well; however, this stovepipe development process has had some undesired side-
effects including long lead times, cumbersome improvement processes, lack of hardware and
software reuse between various aircraft platforms, which result in a platform-unique design.
The advent of significantly complex mission equipment and electronics systems has caused an
increase in the cost and schedule to integrate new hardware and software into aircraft systems.
This – combined with the extensive testing and airworthy qualification requirements – has begun
to affect the ability of the military aviation community to deploy these new capabilities across
the military aviation fleet.
The current military aviation community procurement system does not promote the process of
hardware and software reuse across different programs. In addition, the current aviation
development community has not created sufficient standards to facilitate the reuse of software
components across the military aviation fleet. Part of the reason for this is the small military
aviation market. Another part is the difficulty in developing qualified software for aviation. An
additional problem is the inability to use current commercial software Common Operating
Environment (COE) standards because they do not adhere to the stringent safety requirements
developed to reduce risk and likelihood of loss of aircraft, reduced mission capability, and
ultimately loss of life.
To counter these trends, the Naval Aviation Air Combat Electronics program office, enabled by
the expertise and experience of the military aviation community’s industrial base, is adopting a
revolutionary approach.
1.2 FACE Approach

The Future Airborne Capability Environment (FACE) initiative was established to address the
affordability of today’s military aviation community. The approach used by the FACE
Consortium is to develop a Technical Standard for a software COE designed to promote
portability and create software product lines across the military aviation community.
The FACE approach to software portability and reuse consists of:

 Business processes to adjust procurement and incentivize industry
 Promoting development of reusable software components
Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 1

 A software COE Standard to promote the development of portable components between
differing aviation architectures
The FACE approach allows software-based “capabilities” to be developed as components that

are exposed to other software components through defined interfaces. It also provides for the
reuse of software across different hardware computing environments. The FACE Technical
Standard does not guarantee compliance with any safety certification standards.
Ultimately, the FACE key objectives are to reduce development, integration costs, and time-to-
field avionics capabilities.
1.3 Scope of this Document

This Reference Implementation Guide has been designed to:
 Support the FACE Technical Standard, Edition 2.1
Note: In the event of conflict between the FACE Technical Standard and the FACE
Reference Implementation Guide, the FACE Technical Standard takes
precedence.
 Present best practices for architecting and developing FACE Units of Conformance (UoC)
 Guide the developer through example implementation scenarios where FACE UoCs are
bundled together to provide typical airborne capabilities
 Provide further information on FACE Profiles, FACE UoCs, the FACE Data Architecture,
Application Frameworks, Language Run-times, and how Safety, Security, Health
Monitoring/Fault Management (HMFM), and Configuration Services may be
implemented within a FACE UoC
Note: References and descriptions of other published standards (e.g., ARINC 653,
ARINC 661, POSIX) are presented at an overview level relative to the FACE
Technical Standard and not designed to conflict with the referenced standards.
1.4 FAQs
Figure 1 shows how each FACE term relates to the others. It also recommends terms to use
when referring to FACE conformant software.
2 Open Group Guide (2016)

Types of Deliverables:
When referring to FACE
software, use terms
Source Code Executable/Binary Library found within the FACE
Boundary of this
FACE Boundary diagram
UoC Package
Two or more UoCs (excluding OS) can make up a UoC Package1
PSSS Units of Conformance (UoC)

OS2 Graphics I/O Service2
Service
Unit of Portability (UoP)
One or more Components can make up a UoC

Component
Types of Components
1
UoC Package can span
OS2 multiple segments, but PSS
PCS PCS and PCS UoCs cannot be
included in the same UoC
Component PSSS Service
Package as defined in
TS Graphics Section 3.10.2.3 of the FACE
TS Service Technical Standard
Component Service
PSSS PSSS 2
I/O Services and OS cannot
I/O Service2
Component Service be a UoP since they use
non-FACE APIs for external
communication
Figure 1: FACE Terminology

2 Segment Guidance
2.1 Introduction
The FACE Technical Standard is comprised of a set of “places” where variability occurs. These
points of variability are called “segments”. The structure created by connecting these segments
together is the beginning of the FACE Technical Standard.
The five (5) segments of the FACE Technical Standard are:

 Operating System Segment (OSS)
 I/O Services Segment (IOSS)
 Platform-Specific Services Segment (PSSS)
 Transport Services Segment (TSS)
 Portable Components Segment (PCS)
The OSS, IOSS, and TSS segments create functional interfaces that separate software
implementation variability to create portable software. This software is categorized as either
PCS or PSSS software components. Each of the segments defines a set of rules for the allowable
interfaces, creation rules, and rules on how the software components may be used. Each software
component will be deemed as conformant to the FACE Technical Standard if and only if all of
the rules are adhered to.
Figure 2 is a three-dimensional notional representation of the FACE Technical Standard which

illustrates the OSS as the foundation upon which the other FACE segments are built.
This architecture is constrained to promote separation of concerns. It establishes a product line

approach for reusable software capabilities.

FACE Boundary
Operating System Segment
Portable Components Segment

Common Services and Portable
Applications reside here.
FACE defined
TS
interface set
Transport Services Segment

All application I/O, including inter-application I/O
is achieved through message-based transport
middleware which resides in this segment.
TS FACE defined
interface set
Platform-Specific Services Segment
Standardized application-level data products and

indirect hardware access are provided by this
segment.
FACE defined
IO interface set
I/O Services Segment

Standardized, but indirect hardware
access is provided by this segment.
Hardware
Device Drivers
Interface Hardware
(i.e., MIL-STD-1553, Ethernet)
Platform Platform Platform User Input Platform Other

Devices Sensors Displays Devices Radios Transports
Figure 2: FACE 3D Architectural Segments
2.2 Operating System Segment

This section contains implementation guidance for the FACE Operating System Segment (OSS).
The OSS provides and controls access to the computing platform for the other FACE segments.
The OSS uses processor control mechanisms, such as memory management units and register
access controls (e.g., user versus kernel privileges), to restrict FACE segments to their required
computing platform resources and operational capabilities. This level of control, when
supported, permits various levels of independence between FACE components, permitting
greater portability across FACE computing platforms.

2.2.1 Partitioning
2.2.1.1 Key Characteristics
The FACE architecture is intended to support multiple Units of Portability (UoPs) executing on
a common computing platform. To manage multiple UoPs on a common computing platform,
the FACE architecture includes support for partitions and partitioning. Partitions are the base
unit of isolation enforced by the OSS. System developers use partitions to isolate resources
required to perform their intended function and isolate software components from other software
components running in the same FACE environment. A UoP resides in a partition that contains,
or provides access to, resources.
The following list provides the resources and capabilities the OSS may control within a partition:
 Space – The OSS controls how the physical address space is assigned among partitions.
When memory partitioning is enforced, the OSS ensures partitions are assigned their
configured quota of memory. With memory partitioning, one partition may not
inadvertently encroach on the memory associated with another partition (e.g., Partition A
is prevented from accessing or modifying the memory associated with Partition B). Two
or more partitions may share memory by allocating a virtual address space range in each
partition to the same physical memory. Mappings of virtual address space ranges to
physical memory are created to allocate a partition’s memory quota. A typical memory
methodology makes use of a processor’s memory management unit to create a virtual
address space for each partition.
 Access – The OSS controls how accesses to memory and/or devices are assigned. When
access controls are enforced, the OSS ensures a partition is restricted to only its authorized
access controls. Typical access controls include read, write, and execute permissions.
Some components may tolerate broader access controls (e.g., other components can have
read-access), while other components require strict access controls (e.g., restricting read-
access in order to protect the confidentiality of information). For shared memory, each
partition may have unique access permissions (e.g., one with read-write, some with only
read permissions, and others with no access at all) to the shared memory region.
 Resource – The OSS controls how Operating System (OS) resources (e.g., kernel objects,
open file handles, socket port handles) are allocated. When resource partitioning is
enforced, the OSS ensures partitions are allocated their configured quota of resources.
 Time – The OSS controls how execution time on the processor is allocated. When time
partitioning is enforced, the OSS ensures partitions are allocated their configured quota of
time. A typical time enforcement methodology, as defined in ARINC 653, divides
execution time into a sequence of partition time windows (variably sized) repeating over
time. Partitions are allocated time by assigning one or more partition time windows to the
partition. For multi-process allocations, see Section 2.2.10.
2.2.1.2 Configurability
For FACE implementations that utilize partitioning, individual partitions and resources
associated with the partitions are statically defined as part of the configuration data. During
initial start-up, the OSS creates the partitions as defined in the configuration data. During

operation, the OSS controls when partitions are provided access to the processor and prevents
partition violations. The following characteristics need to be selected on a partition basis:
 Whether ARINC 653 or Portable Operating System Interface (POSIX) interfaces are
utilized
 Which FACE Profile is utilized
The configurability of partitions (in terms of capabilities that can be configured) is based on
ARINC 653.
The following provides guidance on configuring memory and access:

 Configurations should be based on least-privilege. That is, a partition should be
configured to have access to only the memory resources it requires (with the least access
permissions required).
 Component-related memory resources (e.g., text and data sections, stacks) should not be
shared with other partitions.
 When supported by the processing hardware, create separate regions of memory based on
component use (e.g., text, read-write data, read-only data, stack) and allocate only access
permissions required for that specific use.
 Consider including spare capacity in each allocated memory region. This reduces the
possibility of partition and process-level errors, and potentially reduces how often the
configuration data will be changed.
The following provides guidance on configuring partition time windows:

 Partition time schedules are sequences of partition time windows where the overall length
of the schedule is referred to as the major frame. During run-time, the OSS allocates
processor execution time based on the partition time schedule. At the end of the major
frame, the OSS starts again at the beginning of the partition time schedule.
 Each partition can be allocated multiple partition time windows over the major frame.
This permits some partitions to run at a faster rate than other partitions. By spacing a
partition time windows at precise intervals of the major frame, the partition is scheduled at
that rate during run-time.
 Not all time has to be allocated. Intentionally not allocating all of the available time
allows for future growth.
 Applications executing at higher rates establish the framework of the partition time
window schedule known as a minor frame. Lower rate applications are scheduled using
minor frames to define the time window.
 An application’s execution time should be assigned using contiguous time durations rather
than being split across multiple smaller time durations to avoid unnecessary overhead due
to context switches and cache flushes.
 The major and minor frame rate should take into account processor clock speed, such that
the clock speed is a multiple of the major and minor frame.

 Partition time window and execution rates should be based on application and system
needs (e.g., additional spare for growth, overhead, partition switch time, caching effects,
interrupts).
— The execution rate is the lowest rate required for an application to perform its
intended function (e.g., the rate the application needs to generate outputs to other
applications). Arbitrarily raising the execution rate results in excessive allocation of
processor bandwidth. The execution rate typically should not need to be modified
when porting to another computing platform (i.e., rate is related to the intended
function, not available processor resources).
— System characteristics (including overhead) must be considered when setting
appropriate partition time window durations.
 The FACE Technical Standard includes requirements for OSS support for two or more
components configured to execute within the same partition time window. This capability
provides support to design a system where a server can immediately respond to a client
request. It also provides support for capabilities similar to POSIX multi-process (i.e.,
components with unique memory spaces but compete for processor execution time).
— A partition time window can be uniquely assigned to a single or multiple partitions.
— A partition time window is shared by multiple components when each of the
associated partitions are assigned the partition time window’s offset and duration as
part of a partition schedule.
— Within the same partition schedule, a partition can have partition time windows that
are uniquely assigned to it and other partition time windows that it shares with other
partitions.
— When partition time windows are shared, each partition retains its assigned memory
resources (i.e., the memory resources are not shared).
— When a partition time window is shared, the active ARINC 653 processes and
POSIX threads associated with the partitions assigned to it compete for processor
execution time on a priority preemptive basis.
— Sharing a partition time window between ARINC 653 and POSIX-based partitions
may require ensuring both environments have compatible priority ranges.
— When a partition time window is shared, the sharing partitions are coupled through
the partition time windows they have in common. This coupling may need to be
taken into account when considering which applications may share a partition time
window (e.g., an error in one sharing partition may prevent the processor from being
released for use by one of the other sharing partitions; potential covert timing channel
could be established between two or more of the sharing partitions).
— When a server is executing a request on behalf of a client, setting the server's thread
priority to values that are higher than those used by the client, along with preventing
the server from making Application Programming Interface (API) calls that block,
ensures that the client is blocked until the request is complete. If a client does have a
higher priority thread, this thread becoming eligible to run could interrupt a server
thread.

— A server partition can make a request to another server partition. In this case the
configurator must insure that circular dependences are not created otherwise it might
not be possible to evaluate the system.
When using periodic ARINC 653 processes or POSIX threads (see Section 2.2.11), the period of
the ARINC 653 process or POSIX thread should be precisely the same period as the partition
time windows. If the periods do not match, the release points of the ARINC 653 processes and
POSIX threads may drift over time, resulting in the execution sequence being split across
multiple partition time windows (starts late in one window, finishes in the next). For ARINC 653
processes, the OSS must support starting periodic ARINC 653 processes relative to the start of
partition time windows configured as starting points for periodic processes. For POSIX threads,
there are no standard-based POSIX APIs that support synchronizing with the start of partition
time windows.
2.2.1.3 Variability
The degree of partitioning enforced by the OSS may vary based on the FACE Profiles.
Development of components to either the Security or Safety Profiles necessitates the
enforcement of partitioning principles (memory, access, and resource, time) in order to have an
acceptable level of isolation between components. Partitioning principles are beneficial even to
the General-Purpose (GP) Profile but not required. Partitioning will prevent components from
inadvertently impacting other partitions. It also permits each partition to have a safety or security
level assignment appropriate to the component(s) allocated (i.e., not all components have to be
developed and execute at the same level).
On many processors, memory accesses made by Dynamic Memory Access (DMA) devices are
not under the control of the processor’s Memory Management Unit (MMU). As such, a DMA
device should be considered as being capable of reading and/or writing to anywhere in memory.
To prevent violations of partitioning, the developer of the software used to configure the DMA
transfer source and destination addresses should satisfy sufficient assurance activities to ensure
that the software can be trusted to only utilize address ranges it is intended to have access to.
2.2.2 File System
The FACE architecture may include file system capabilities. The file system capabilities permit
applications to:
 Store data into and retrieve data from non-volatile storage device (i.e., data preserved
across power cycles)
 Separate data into uniquely identified files
 Separate sets of files into uniquely identified directory structures
 Have an amount of storage (referred to as a volume) reserved for the application’s use
 Share stored information between components

File systems used within the FACE architecture are intended to support atomic updates. This
characteristic permits the consistency of data structures stored within a file to be retained.
Updates to a file within the defined atomic update size of the file system are ensured by the file
system to either be completely stored, or to not be stored at all (e.g., when a power-failure occurs
during the write-cycle). This characteristic prevents a data structure (whose size is less than the
defined atomic update size) from having some contents from a previous state and other partial
contents from an update.
The FACE Technical Standard does not include requirements on safety or security attributes of
the stored data when the equipment is in a powered off state. A particular installation may
impose additional requirements on the data at rest (e.g., encryption to prevent unauthorized
access, check sequences to detect and prevent use of data corrupted by device failures).
The non-volatile storage capabilities can be allocated and sub-divided based on the configuration
data. The individual allocations of non-volatile storage are referred to as file system volumes.
For each file system volume, the following can be configured:
 Access permissions – The use of access permissions permits control over which FACE
conformant components can access a particular file system volume. The access
permissions of each file system volume are configurable on a per partition basis.
— For the Safety Profile, the access permissions of a file system volume permit at most
one partition with write permissions and one or more partitions with read permissions
(there are no executing privileges for volumes used by the Safety Profile).
— For the General-Purpose Profile, additional access permissions may be supported
(access permissions defined for the Safety Profile are the minimum requirements).
— Multiple partitions can be allocated read-access permissions for the same file-system
volume.
— A read-only file system volume is configured by not allocating write permission to
any partition.
— All access permissions are explicitly defined as part of the configuration data (i.e.,
there are no default access permissions).
 Alias name – The use of an alias permits a FACE conformant component to not be
impacted when reused across platforms. The file system configuration data includes
specification of a volume alias name.
— Each partition can have a unique alias name for each of the volumes it has access to.
2.2.2.3 Variability
File system APIs have not been included as part of the Security Profile. The Security Profile use-
case includes applications that may be required to process data of different security
classifications within a single partition. A typical application use of a file system will include
multiple files that are open and being utilized simultaneously. When coupled with the feature
rich capabilities of a typical file system (including temporary data cache management), ensuring

data separation through a file system from a single partition is not feasible. This limitation can
be managed by separating file system-related operations into other partitions that are only on one
side or the other of a security boundary. This permits a file system to have to only handle a
single classification of data, permitting data separation to be managed.
The FACE Safety Profile only permits a single partition to have write access to a volume. This
restriction in behavior prevents data consistency and synchronization issues that could occur
when multiple writers from different partitions attempt to utilize a single file (e.g., only part of
the data is written to a log file during a partition’s time window). Data from multiple partitions
can be written into a single file by designing the contributing partitions to send their data to the
partition that has write permissions for the volume. This partition will collect the data from the
other partitions and write it into the file on their behalf. The writing partition ensures that
complete data sets from the contributing partitions are written into the file.
2.2.3 APIs and Profiles
The FACE Technical Standard defines sets of OS APIs that can be used by a FACE conformant
component. A separate set of APIs is defined for each of the profiles (GP, Safety, and Security).
APIs are defined for both ARINC 653 and POSIX.
2.2.4 Health Monitoring/Fault Management

Although Health Monitoring is primarily associated with ARINC 653, the FACE Technical
Standard supports the development of Health Monitoring/Fault Management (HMFM) in the
POSIX environment. HMFM provides standardized methods for detecting, reporting, and
handling fault, failures, current state, and state change of platform components. Component code
is instrumented to report events (fault, failure, current state, and state change) to the HMFM.
This approach separates component execution activities from error handling activities, making
the code easier to develop and understand.
Once an event is received, the HMFM component reacts to the event by performing a set of
actions that are specified by the system integrator at configuration time.
One possible action is to log the event, allowing a profile/trace of the execution activities to be
created. The log should be saved either in memory or in non-volatile memory. If the event logs
need to be saved in a file, then a partition should be created that is responsible for managing the
logs.
Since the logs are saved in memory, which is a finite resource, a log management policy should
be created in the case a log becomes full. The two standard policies are either to stop logging or
to wrap the log by overwriting the oldest event.

The connection between each event that can be reported by a platform and the set of actions to
take should be configurable, allowing the same HMFM to react differently from one
instantiation to another.
The log management policies should also be configurable.
2.2.4.3 Variability
ARINC 653 clearly defines the Health Monitoring architectures and the basic instrumentation
points. The implementer may augment the number of instrumentation points to provide a safer
solution.
2.2.5 Configuration Services

This section will be added in a future release.
2.2.6 Inter-Partition Communications

This section pertains only to ARINC 653-based Real-Time Operating Systems (RTOS).
Inter-partition communications are the data transfer mechanisms available between partitions.
Use of inter-partition communication is restricted to the TSS and IOSS. All FACE conformant
PCS components must utilize the Transport Services (TS) Interface for all communication
outside of the UoP.
For ARINC 653-based applications, each inter-partition information flow should be based on
sampling ports or queuing ports. A component may be allocated multiple sampling and queuing
ports. The sampling and queuing ports available to a partition are controlled through the
configuration data. If a component attempts during initialization to create access to a sampling or
queuing port that it has not been configured for, an error will be returned. All sampling and
queuing ports must be successfully created during the initialization phase in order for the
component to use the port during the normal operational mode.
With sampling ports, the receive side of the port contains the last data message received on the
port. When a new data message is received, it atomically replaces the previous data message.
Sampling ports are useful for system parameters that periodically vary over time (e.g., aircraft
altitude, airspeed, attitude, and heading). The application assigned to the transmit side of the port
is responsible for updating the data message at some periodic rate. Users of a sampling port
always access the most recent sample of the system parameters. Reading the port again may
result in the same data message being read if another data message has not yet been received.
Multiple partitions can be assigned access to the receiving side of the same sampling port, if
broadcast channels are supported by the OSS. A validity parameter is included with a message
when it is read. This parameter is used to indicate whether the message is within or outside the
configured refresh period for the port.

With queuing ports, the send and transmit side of the port are capable of containing a queue of a
set of messages. When a queuing port is read, the data message is consumed. The queuing port
mechanism prevents overflow of the allocated queues. When the send queue is full, the
application is able to control through the call parameters whether the invoking ARINC 653
process should block always, block with a timeout, or return. A component that is reading from a
queuing port ensures the data’s freshness by reading from the port at some periodic rate. By
reading all available messages, the application ensures that any new messages are no older than
the time period since the port was last checked. If a queuing port is empty, the invoking
application is able to control through the call parameters whether the invoking ARINC 653
process should block always, block with a timeout, or return.
For POSIX-based applications communicating with ARINC 653-based applications, each inter-
partition information flow should be based on sampling ports or queuing ports. For POSIX-
based applications communicating with other POSIX-based applications, each inter-partition
information flow should be based on sockets, message queues, or shared memory. A component
may have multiple open sockets bound to different endpoints simultaneously. The OSS may
limit, based on configuration data, which endpoints a specific application may bind to as part of
enforcing access control over the application.
2.2.6.3 Variability
Each component is likely to have one or more data flows with other components in the system.
The number of data flows is component-dependent.
For portability, sampling and queuing port names should be selected based on the data flow
content, not the source or destination of the data.
For portability, sockets should be established using name service APIs rather than hard coding to
fixed addresses (that may conflict with another application’s fixed addresses).
2.2.7 Intra-Partition Communications

Intra-partition communications are the data transfer and data access control mechanisms
available within a partition.
2.2.8 Local Memory Allocation/Deallocation

Applications developed to the FACE Technical Standard may require memory allocation and
deallocation mechanisms at run-time.
A key safety/security principle is to utilize memory buffers (a set of fixed-size elements) and/or
pools provided to the partition for specific purposes instead of common memory heaps that are
used by all parts of the application. When common memory heaps are used, several
security/safety concepts may be violated:
 Resource reuse within the partition. In a multi-level secure application, part of the
application is dealing with data of one classification, while other portions are dealing with

another classification. If both portions utilize services that draw resources from a common
heap/pool, and these resources may be returned to the heap/pool for use by other parts of
the application, any state remaining in the resource may result in information leakage
when reused by other portions of the application (at another classification level). This
needs to be prevented (potential breach of confidentiality).
 Allocation from a memory heap may be open-ended in terms of number of bytes required.
When open-ended, there is a greater potential for memory exhaustion.
 Traditional heaps for which allocation and deallocation services are provided have
potential for memory fragmentation (deallocated memory range is located between other
memory ranges that are still in use, limiting reallocation of the memory range to requests
of the memory ranges length or smaller). Memory fragmentation leads to the potential for
either temporary loss of function (while resolving fragmentation) or complete loss of
function (due to resources no longer being available). Loss of function results in violating
the application’s availability. The use of pools can still result in impacting the
application’s availability (due to pool resource being exhausted).
 Minimization of duplicate services (to minimize the exposure surface that must be
evaluated, verified, and/or proven).
Services should be re-entrant (e.g., to prevent potential loss of function resulting from two or
more threads attempting to utilize the services, with later threads corrupting internal data that the
earlier threads were dependent upon).
For some applications, the size of some data structures is dependent upon other application
and/or platform variables whose values are not known until run-time. These applications require
the ability to create memory structures during initialization whose sizes are based on parameters
that are not known until run-time.
Some applications will require access to memory regions whose locations, size, and access
permissions are not known until run-time.
Note that some systems may utilize a variable-sized memory region (whose size is discovered at
run- time) to resolve variable-size memory structure allocation at initialization.
Regions of memory (i.e., range of consecutive locations) can be allocated and/or deallocated at
run-time, and be configured on a partition-by-partition basis. Each partition may have memory
regions of various sizes that can be utilized locally during run-time.
2.2.8.3 Variability
Trade-offs with regard to local memory allocation and deallocation that an application may take
into account include:
 Using only static allocation. Here, an application selects as part of the design effort the
size of each data structure. As part of compilation, linking, and integration, memory
resources are reserved to contain the allocated data structures. During partition

initialization, memory resources for the data structures are allocated. During application
run-time, the data structures are utilized.
— The data structure can be a pool of elements that are allocated for a particular use and
returned when that use is complete.
— When all of the allocation decisions were completed by a single designer, and the
data structure was adequately sized for worst-case memory requirements, there will
be no memory allocation issues as there are no other consumers whose memory
usage could result in memory exhaustion during run-time.
— The system cannot adjust the size of the allocation based on system state that is only
known at run-time.
Note: Systems developed within the FACE Safety or Security Profiles should consider
using static allocation.
 Using dynamic allocation only during initialization.
— The system can adjust the size of the allocation based on system state that is known
at run-time during the application’s initialization phase.
— Since the allocation is dynamic, there could be system states which result in all of the
memory available for dynamic allocation is exhausted. Since the system is just
initializing, there may be fewer hazards associated with this erroneous condition. For
a given mission (e.g., flight), the system state should not change. A power-cycle
during operational flight is feasible. If the power-cycle during flight results in a
different system state that has larger memory requirements, a memory exhaustion
could occur during operational flight that did not occur when the aircraft was first
powered up on the ground.
Note: Systems developed within the FACE Safety or Security Profiles should consider
using dynamic allocation only during initialization.
 Permitting full dynamic allocation and deallocation during run-time.
— Some implementations may result in significant memory fragmentation. Recovery of
memory fragmentation could have non-deterministic behaviors. For example, when a
system has to search for available space for the next allocation, and moves current
allocations to a different location in order to make sufficient consecutive memory
locations available for the next allocation.
— Some implementations may result in significant memory under-utilization (e.g., fixed
size allocation that accounts for the largest possible memory allocation, but may be
requested an allocation significantly smaller).
Note: Systems developed within the FACE Safety Extended or General-Purpose

Profiles may consider using full dynamic allocation and deallocation during run-
time. FACE Security and Safety Base Profiles do not support free().
If allocations and deallocations of memory are occurring during run-time for divergent uses,
prediction of worst-case memory requirements may be infeasible. This could result in a memory
exhaustion hazard occurring at any time a memory allocation is requested during run-time.

When possible, to improve security and safety, memory allocated for local memory regions
should exclude execute permissions (i.e., local memory regions should be configured as read-
write-no_execute).
2.2.9 Shared Memory
The FACE Technical Standard includes support for multiple partitions to have access to the
same range of physical memory (i.e., region). For example, this may include multiple partitions
being provided read-access to memory containing navigation data. Use of shared memory to
communicate between partitons or UoCs is restricted to software in the TS and IOS Segments.
Considerations include:
 Not all partitions require the same level of access. A key attribute is the ability to
individually configure the access permissions of each partition. Any partition not
configured to access the shared memory must be denied all types of access (read, write,
and execute).
 In reader/writer usage scenarios, cache coherency can be an issue if the sharing partitions
(or devices in the case that the source of the data is a hardware device such as a DMA
engine) use different caching mechanisms. For example, data loss and/or inconsistency
could occur if the writer is configured for write-back cache, the reader is configured for
uncached, and the writer does not flush its data cache after writing the data.
 In reader/writer usage scenarios, access control and/or notification mechanisms are likely
required in order to ensure each reader a consistent view of the data. This is especially
important when there are multiple readers, all of whom may be in the process of reading a
different message or section of message when the writer has another update.
 If the shared memory includes memory mapped registers for devices, special
considerations apply (e.g., not mapping memory to multiple partitions).
The configurability of shared memory regions is the same as for memory resources associated
with the partition (see Section 2.2.1).
2.2.9.3 Variability
The FACE Technical Standard OS requirements may be satisfied by a variety of OS

implementations. These implementations, partially in support of safety and security trade-offs,
may vary in methods available to define regions of memory shared between partitions. All
implementations are capable of enforcing statically-defined shared memory as part of
configuring the partitions for the platform. While some OSs may have mechanisms to
programmatically determine the location of shared memory, all should support use of APIs at
run-time to determine location information.
The following APIs can be utilized to determine the location and access permissions for shared
memory that has been allocated to a partition:

For ARINC 653-based applications:
 Get_Memory_Block_Status() – The user passes in the name of the memory block as
assigned in the configuration data and the API returns the location, size, and access mode
(read or read-write) of the associated memory block. The memory block names are aliases
that are specific to each partition. Two partitions can utilize the same name to refer to
different blocks of physical memory and two different names used by two partitions can
refer to the same block of physical memory. The configuration data controls the physical
memory that corresponds to the named memory block.
For POSIX-based applications, a series of APIs are required:

 stat() and fstat() – Provides information about a shared memory object. In particular, stat
returns a struct stat which includes fields for the size (st_size) and access permissions
(st_mode) of the object associated with the specified file.
 shm_open() – Opens a shared memory object.
 ftruncate() – Sets the size of the shared memory object. Note that this function is also
supported for use with files as part of the file system.
 mmap() – Provides a pointer to memory that maps to the shared memory object at a
particular offset and for a particular length.
There are no expected variations in the ARINC 653 API behavior. For the above POSIX APIs,
there may be additional behaviors dependent upon the types of memory configuration
capabilities supported by a FACE OSS implementation. For the FACE architecture, the intent of
providing these APIs within the Security and Safety Profiles is to provide a means to the
application developer to find the location, size, and access permissions of any memory regions
(including shared memory regions) allocated for the application’s use. The following code
fragment example provides a means to access this information that will operate for all FACE
OSS implementations regardless of behavior variations:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#define SHM_NAME "pathA/Shm_B"
int main(int argc, char **argv)

{
int shm_fd;
struct stat shm_status;
void *shm_ptr;
mode_t shm_mode;
int shm_access;
int shm_prot;
/*
* obtain the size and access permissions for a configured
* shared memory

*/
if (stat (SHM_NAME, &shm_status) == -1)
/* Handle error */;
/*
* If application has write permission, then set up to use it
*/
if (shm_status.st_mode & S_IWUSR) {
shm_mode = S_IWUSR;
shm_access = O_RDWR;
shm_prot = PROT_READ | PROT_WRITE;
}
else {
shm_mode = S_IRUSR;
shm_access = O_RDONLY;
shm_prot = PROT_READ;
}
/* create shared memory object */

shm_fd = shm_open (SHM_NAME, shm_access, shm_mode);
if (shm_fd == -1)
/* Handle error */;
/* size the shared memory based on its configured size */

if (ftruncate (shm_fd, shm_status.st_size) == -1)
/* Handle error */;
/* obtain pointer to the start of the shared memory region */

shm_ptr = mmap (NULL, shm_status.st_size, shm_prot,
MAP_SHARED, shm_fd, 0);
if (shm_ptr == MAP_FAILED)
/* Handle error */;
/* shm_ptr points to the shared memory region */
When possible, to improve security and safety, memory allocated for shared memory regions
should exclude execute permissions (i.e., shared memory regions should be configured as read-
write-no_execute).
2.2.10 Multi-Process
2.2.11 Multi-Threading

2.2.11.3 Variability
All of the profiles, including the Security Profile, include support for multi-threading.
When supporting the Security or Safety Profiles, the OSS may be limited to only supporting
configuration of static allocations of memory. The safety (and security) of stacks can be
improved by utilizing regions of memory where “guard” pages exist at the end of the stack. A
guard page is a range of virtual memory addresses to which no corresponding physical memory
has been allocated. When accessed (e.g., as part of a stack overflow), the access causes a
memory access violation, causing an exception that can be reported to a health monitoring
capability (see Section 2.2.4).
FACE OSS implementations support the use of OSS configuration data for the creation of
guarded memory regions (e.g., pthread_attr_setguardsize) that can be utilized for stacks. The
location and size of these stacks can be determined at run-time using the techniques described in
Section 2.2.9.3. This information can be utilized with the supported FACE OS APIs (e.g.,
Create_Process, pthread_attr_setstack) to create ARINC processes or POSIX threads that
utilize the stacks. Stacks should not be shared (each simultaneously-defined ARINC process and
POSIX thread should be allocated a unique stack). Use of this technique ensures the portability
of the specification of guarded stacks across all FACE Profiles.
When possible, to improve security and safety, memory allocated for stacks should exclude
execute permissions (i.e., stacks should be configured as read-write-no_execute).
2.2.12 Operating System Input/Output (I/O) Support
2.2.12.3 Variability
When transitioning an application from a non-time partitioned to a time partitioned system, the
application is eligible to execute only during its partition time windows (see Section 2.2.1). In
the non-time partitioned environment, an application may have been able to immediately
respond to some events (e.g., interrupts). However, the application will now only respond during
its allocated partition time windows. In the FACE architecture, this level of interaction has
mainly been addressed by the IOS (i.e., components dedicated to handling specific I/O devices
and the interactions with them) and TS (i.e., reliable endpoints for data transfer). As such,
transitioning such an application requires some re-architecting effort to separate the I/O and
transport operations from the other functional capabilities.
2.2.13 Networking

2.3 I/O Services Segment
The I/O Services provides a common interface for I/O devices that do not have a FACE
standardized API. The I/O Services provides a collection of I/O protocol abstractions that are
used by components in the PSSS. The FACE Technical Standard contains a minimal set of I/O
Services, and is re-evaluated with all future editions for inclusion of other possible I/O Services
candidates.
The I/O Services Segment (IOSS), along with the message-based I/O Services API, is intended
to provide a standardized mechanism for a PSSS component to access I/O hardware. The IOSS
and I/O Services API isolate the PSSS from the unique implementations of vendor-specific
device drivers and OS device driver API sets.
The IOSS provides I/O Services Management and I/O Data Movement Capability. The I/O Data
Movement Capability is used when the IOSS resides in partitions or address spaces other than
the ones occupied by the PSSS for which they provide I/O Services. The I/O Management
Capability is responsible for initializing and configuring the specific I/O Services. The I/O
Services Management Capability could be implemented within individual I/O Services or
centralized. The I/O Service capabilities are shown in Figure 3.
I/O Interface
MANAGEMENT
I/O DATA CAPABILITY
MOVEMENT
CAPABILITY
OS interface
ADAPTATION
CAPABILITY
I/O SERVICES SEGMENT
Non-FACE
Proprietary
Interfaces
Figure 3: I/O Services Segment Capabilities
This section has been written with the expectation that the reader is familiar with the bus and bus
protocols being implemented with the I/O Services.
The I/O Service does not interpret the payload of the message on the bus. The I/O Service is
expected to understand how the bus protocol operates, in order to send and receive messages on

the particular bus. The PSSS interprets the message after the I/O Service encodes the message in
the I/O Message Model (IOMM) format.
Any I/O that uses the OSS standardized interfaces, such as sockets, is handled by the OSS and
not by the IOSS.
2.3.1 Key Characteristics

The I/O Service is designed to understand the I/O protocol (e.g., MIL-STD-1553, ARINC 429)
and interface with the driver handling the hardware. A single I/O interface may be used to
communicate with multiple I/O Services. An I/O Service uses the I/O Interface to communicate
with the PSS.
For distributed I/O Services, the I/O Interface is implemented as a library to provide the I/O Data
Movement Capability. The Library is used to provide access to internal Inter-Process
Communications (IPC) (e.g., ARINC 653 IPC, POSIX IPC, sockets, ARINC 653 ports,
depending on the implementation).
For non-distributed I/O Services, the PSS component, I/O Interface, and I/O Service are
implemented as a single executable. In non-distributed implementations, the I/O Interface
provides the PSS component a normalized interface to the Device Driver.
The I/O Service understands the IOMM; however, it does not have or need knowledge of the
specific data traversing the interface. Understanding of the data traversing the I/O Interface is
handled by the components of the PSSS. The I/O Service is responsible for sending and
receiving data using the IOMM format and the I/O Interface API.
2.3.2 Configurability
It is recommended the I/O Services components be designed to be configured externally.
However, the IOMM does not currently support the Centralized Configuration Service. The I/O
Service component should be designed to service a specific bus type. This means a properly
designed I/O Service should be configurable to handle the bus itself, and not specific endpoints.
A properly designed I/O Service should be configurable to accept bus traffic to and from
different bus endpoints.
Since the I/O Service does not have any knowledge of the content of the bus data within the
IOMM, the arbitration and failover of busses may be handled in the PSSS. If the PSSS is going
to handle failover, it will need to send a control message to the I/O Service component through
the IOMM to command a change to the configuration or role of the I/O Service.
The FACE Technical Standard, Section D.12 provides the mandatory set of configurable items
for the IOSS.
The overarching FACE objectives are to reduce development and integration costs as well as
time-to-field. Configuration supports these goals by increasing the flexibility of software and
simplifying software integration and maintenance tasks. Configuration enables the integration of
FACE conformant software components into multiple environments without modification.
Configurable items to consider include: device address, dataflow, receivers/transmitters, data

rates/sizes, source/destination, and permissions.

2.3.2.1 Example I/O Configuration File
An example I/O Configuration File for an implementation with two connections being
configured is shown below. An example eXtensible Markup Language (XML) Schema
Definition (XSD) for the system is found in Appendix E. The XML has elements for the
parameters defined in the FACE Technical Standard, Section D.12. Unneeded parameters can be
empty fields as seen in the domain and socket type when configuring a nonsocket connection.
Unneeded parameters can also be omitted as shown by the thread-specific parameters left out of
the XML because only one thread is being used.
The connections defined in the example configuration file below are as follows:
 TDLPSS_TO_AVS_AC0: UDP source connection to Aircraft 0.
 TDLPSS_TO_AVS_AC1: UDP source connection to Aircraft 1.
 AVS_TO_TDLPSS: UDP destination connection to receive from all aircraft. Used to
receive vehicle status and track information from all Air Vehicle Systems (AVS).
 TDL_To_CLIP: UDP source connection to CLIP. Used to send track information to CLIP.
<?xml version="1.0" encoding="UTF-8"?>
<connection_list>
<connection>
<name>TDLPSS_TO_AVS_AC0</name>
<type>UDP_DAPI</type>
<direction>SOURCE_PORT</direction>
<createconnection>false</createconnection>
<portname></portname>
<messagesize>8000</messagesize>
<messagerange>20</messagerange>
<refreshperiod>1000000000</refreshperiod>
<reliability></reliability>
<readwrite_behav></readwrite_behav>
<queue_discipline></queue_discipline>
<domain>AF_INET</domain>
<sockettype>SOCK_DGRAM</sockettype>
<receiveflag></receiveflag>
<sendflag></sendflag>
<sourceaddress></sourceaddress>
<destinationaddress>192.168.16.151</destinationaddress>
<sourceport>

</sourceport>
<destinationport>42633</destinationport>
<iotype>GENERIC_BUS</iotype>
<threadlist>

</threadlist>
</connection>
<connection>
<name>TDLPSS_TO_AVS_AC1</name>

<sourceport>
</sourceport>
<threadlist>
</threadlist>
</connection>
<connection>
<name>AVS_TO_TDLPSS</name>
<direction>DESTINATION_PORT</direction>
<sourceport>
</sourceport>
<threadlist>
</threadlist>
</connection>
<connection>
<name>TDL_To_CLIP</name>

<sourceport>
</sourceport>
<threadlist>
</threadlist>
</connection>
<connection>
<name>Dummy_Receive1</name>
<type>QUEUING_ML</type>
<portname>GPS_IOML_QP_DST_MIL1553</portname>
<reliability>RELIABLE</reliability>
<readwrite_behav>QUEUING</readwrite_behav>
<queue_discipline>FIFO</queue_discipline>
<domain>

</domain>
<sockettype>
</sockettype>
<receiveflag>
</receiveflag>
<sendflag>
</sendflag>
<sourceaddress>
</sourceaddress>
<destinationaddress>
</destinationaddress>
<sourceport>

</sourceport>
<iotype>MIL_STD_1553</iotype>
<threadlist>

</threadlist>

<M1553_CHANNEL>0</M1553_CHANNEL>
<M1553_MODE>RT</M1553_MODE>
<M1553_TERMINAL>0</M1553_TERMINAL>
<M1553_SUBADDRESS>0</M1553_SUBADDRESS>
</connection>
<connection>
<name>Dummy_Receive2</name>
<portname>

</portname>
<readwrite_behav>QUEUING</readwrite_behav>
<receiveflag>0</receiveflag>
<sendflag>0</sendflag>
<sourceaddress>10.15.90.20</sourceaddress>

<sourceport/>
<destinationport/>
<threadlist>
</threadlist>
</connection>
Comment: Add another type of connection besides socket.
</connection_list>
2.3.3 Variability
The I/O service can be designed in many different ways to accomplish the same goal, but not all
designs promote portability. In the sections below, recommendations are provided to ensure an
I/O service is reusable beyond its initial use. The brick walls that appear in the figures in this
section indicate a virtual partition or a physical boundary.
Both distributed and non-distributed designs can result in FACE conformance. Distributed
communication allows for communication between partitions while non-distributed

communication allows the Platform-Specific Device Service (PDS) direct read and write access
to the I/O device.
2.3.3.1 Non-Distributed Data Flow
Figure 4 represents the data flow from the PDS to Device through a Non-Distributed I/O
infrastructure.
The list below describes the sequence of actions performed to send data to a Device:
1. PDS packs data using the IOMM (FACE Technical Standard, Section 3.4.1).
2. PDS passes packed data by calling the I/O API Write(I/O) function (FACE Technical
Standard, Section D.8).
3. I/O Service unpacks data using the IOMM (FACE Technical Standard, Section 3.4.1).
4. I/O Service sends data to the device driver using the device driver’s API.
5. I/O Driver writes to Device.
6. I/O Driver may return success or failure to I/O Service using the device driver’s API.
7. I/O Service returns FACE return code to the PDS I/O API Write(I/O) function (FACE
Technical Standard, Section D.8).
PDS and I/O Service
are in the same address
space
Platform-Specific
Services Segment
1
PDS 2
I/O API 7
3
I/O Service
6
I/O Services
Segment 4
Driver and 5
Hardware
Figure 4: Non-Distributed Data Writing Flow
Figure 5 represents the data flow from the PDS to Device and back to the PDS through a Non-
Distributed I/O infrastructure. The details of the steps depend on the type of I/O protocol being
used. The list below describes the sequence of actions performed to read data from a Device
using an I/O Service for a periodic I/O protocol:

1. The PDS sets the message_type field in the header to DATA (FACE Technical Standard,
Section 3.4.1).
2. PDS requests data by calling the I/O API Read(I/O) function (FACE Technical Standard,
Section D.7).
3. I/O Service requests data from the device driver using the device driver’s API.
4. I/O Driver reads data from the Device.
5. I/O Driver returns data to the I/O Service through the device driver using the device
driver’s API.
6. I/O Service packs data using the IOMM (FACE Technical Standard, Section 3.4.1).
7. I/O Service returns data and FACE return code to the PDS through the I/O API Read(I/O)
function (FACE Technical Standard, Section D.7).
8. PDS unpacks data using the IOMM (FACE Technical Standard, Section 3.4.1).
PDS and I/O Service
are in the same address
space
Platform-Specific
Services Segment 1 8
2
PDS 7
I/O API
I/O Service
5
I/O Services
Segment 3
Driver and 4
Hardware
Figure 5: Non-Distributed Data Reading Flow
The list below describes the sequence of actions performed to read data from a Device using an
I/O Service for an on-demand (command-response) type I/O Protocol:
1. The PDS sets the appropriate fields in the message payload to instruct the I/O Service to
perform the read command (sets message_type to COMMAND and CM_ST to READ).
2. PDS issues the command by calling I/O API Write(I/O) function (FACE Technical
Standard, Section D.8). PDS prepares to receive data by calling the I/O API Read(I/O)

3. I/O Service parses the message payload to determine whether it needs to read data from
the device. I/O Service requests data from the device driver using the device driver’s API.
4. I/O Driver reads data from the Device.
5. I/O Driver returns data to the I/O Service through the device driver using the device
driver’s API.
6. I/O Service packs data using the IOMM (FACE Technical Standard, Section 3.4.1).
7. The PDS Receives data from the I/O Service when the I/O API Read(I/O) function (FACE
Technical Standard, Section D.7) initiated in step 2 completes.
8. PDS unpacks data using the IOMM (FACE Technical Standard, Section 3.4.1).
2.3.3.2 Distributed Data Flow
Figure 6 represents the data flow from the PDS to a Device through a Distributed I/O
infrastructure. The following list describes the sequence of actions performed to send data to a
Device:
3. I/O Library implements the I/O Data Movement Capability by executing the Write(I/O)
function using IPC to send packed data to the I/O Service.
4. The data formatted in the IOMM is sent across partitions using IPC.
5. I/O Service and I/O Library receives data sent using the I/O Data Movement Capability.
6. I/O Library handles the callback registered by the I/O Service.
7. I/O Service unpacks data using the IOMM (FACE Technical Standard, Section 3.4.1).
8. I/O Service sends data to the device driver using the device driver’s API.
9. I/O Driver writes to Device.

PDS 1, and
PDS
I/O 2Service
and I/Oare
Service
in different
areaddress
in different
address
spaces spaces
Platform-Specific
Services Segment
1
2
PDS
3 I/O API 4
I/O library
OS API
I/O Message 5
Model
OS API 6
I/O Services
I/O library
Segment I/O API 7
I/O
Service
8
The use of the I/O API
here is not mandated by Driver and
the FACE Standard. For Hardware 9
this example, it was a
design decision to
maximize portability of
the I/O Component.
Figure 6: Distributed Data Writing Flow
Figure 7 represents the data flow from the PDS to a Device and back to the PDS through a
Distributed I/O infrastructure. The details of the steps depend on the type of I/O protocol being
used. The list below describes the sequence of actions performed to read data from a Device
using a distributed I/O Service for a periodic type I/O protocol:
3. I/O library 1 sends the data formatted in the IOMM across partitions to I/O library 2 using
IPC.
4. The I/O Service receives this message by polling the connection using a Read(I/O) from
I/O library 2.
5. The I/O Service parses the message payload and sees that it needs to perform a read.
6. The I/O Service uses the driver’s API read data from the bus and puts it in the
PAYLOAD_DATA field of the message payload.
7. The I/O Service sends this message to I/O library 2 using Write(I/O).
IPC.
9. The PDS receives the message from the Read(I/O) return or the callback function.

10. The PDS sees the message_type is DATA and extracts the data from the message payload.
PDS 1, and
PDS
I/O 2Service
and I/Oare
Service
in different
areaddress
in different
address
spaces spaces
Platform-Specific
Services Segment
10 1
3
2
9 PDS 8
I/O API
I/O library 1
OS API
I/O Message
Model 4 7
I/O Services OS API
Segment I/O library 2

I/O API 5
I/O
Service
6
here is not mandated by
Driver and
the FACE Standard. For Hardware
this example, it was a
design decision to
the I/O Component.
Figure 7: Distributed Data Reading Flow
The list below describes the sequence of actions performed to read data from a Device using a
distributed I/O Service for an on-demand command-response type I/O protocol:
1. The PDS packs data using the IOMM (FACE Technical Standard, Section 3.4.1), setting
the appropriate fields in the message payload to instruct the I/O Service to perform the
read command (sets message_type to COMMAND and CM_ST to READ).
2. The PDS passes packed data to I/O library 1 by calling the I/O API Write(I/O) function
(FACE Technical Standard, Section D.8).
IPC.
4. The I/O Service receives this message by calling Read(I/O) from I/O library 2.
5. The I/O Service parses the message header and sees that it needs to perform a read of the
bus.
6. The I/O Service parses the message payload and determines that it needs to read data from
the device driver. I/O Service requests data from the device driver using proprietary API,
puts it in the message payload, and changes the message_type in the message header from
a command to a response type.
7. The I/O Service sends this message to I/O library 2 using Write(I/O).

IPC.
9. The PDS receives the message from calling Read(I/O) from an IOS library linked in.
10. The PDS sees the message_type is DATA and extracts the data from the message payload.
2.3.3.3 Distributed and Non-Distributed Data Flow
Figure 8 shows how a single I/O Service can be used to communicate with two PDS components
in separate partitions. The I/O Libraries implement the I/O Data Movement Capability using the
IOMM to allow communication between PDS 1 and the driver and hardware since PDS 1 and
the I/O Service are in separate partitions. The I/O API would be used for both the PDS
components. The data flow between PDS 1 and the I/O Service are similar to those described in
Section 2.3.3.2 and the data flow between PDS 2 and the I/O Service are similar to those
described in Section 2.3.3.1.
PDS 1,1 and
PDSI/O2 and
Service
I/O
Service
are in different
are in different
address
address
spaces spaces
Platform-Specific 5
Services Segment 1
1
2
2
PDS 1 I/O Message PDS 2 4
I/O API Model
3 I/O API
I/O library I/O library 6
OS API OS API
7
OS API
OS
API I/O library
I/O API
I/O Services 8
Segment I/O Service
9
here is not mandated by
the FACE Standard. For
Driver and
this example, it was a Hardware 10
design decision to
the I/O Component.
Figure 8: Distributed and Non-Distributed Data Flow
2.3.3.4 Recommendations
The following recommendations maximize the portability of an I/O Service along a product line:
 The I/O Service should be designed as an independent software package or library.
 The I/O Service and I/O Data Movement Capability should be designed to allow multiple
independent PDS tasks access to the same I/O Service without race conditions.
 The independent I/O Service should be designed for each I/O bus type.

 I/O Services (I/O Service and I/O Library) can be separated into different partitions to
isolate I/O types and failures. However, this approach may impact partition scheduling
and increase processor utilization.
 Replication of device data and transfer to multiple consumers may be done at the PSSS
level or above, rather than by the IOSS. Data replication may be handled in the IOSS in
distributed systems.
2.3.3.5 Multiple Buses in One Service
The I/O Service may be designed to handle more than one I/O type as shown in Figure 9. This
design decision may have performance and/or memory benefits but may decrease the
component’s portability. The data flow steps in Figure 9 are similar to those described in Section
2.3.3.1.
PDS and I/O Service are
in the same address
space
Platform-Specific
Services Segment
1
PDS
I/O API
2
I/O Services
Segment
I/O Service 3
(Analogs / Synchros)
4
1
5
1
Analog Driver Synchros Driver

and Hardware and Hardware
Figure 9: Multiple Buses in One Service
2.4 Platform-Specific Services Segment

The Platform-Specific Services Segment (PSSS) creates an infrastructure unique to the aircraft
platform that provides device data to PCS components. The components of the PSSS may be
portable and may be reused between platforms that share the corresponding platform devices.
The PSSS is broken into three sub-segments:
 Platform-Specific Device Services
 Platform-Specific Common Services
 Platform-Specific Graphics Services

Only components that meet the requirements of these three sub-segments reside within the
PSSS.
2.4.1 Platform-Specific Services Segment External Interfaces

Platform-Specific Services (PSS) components can communicate with other components in
multiple ways as exampled in Figure 10. Segments outside of the Platform-Specific Services
Segment (PSSS) have been simplified in Figure 10 to highlight the relevant section.
PSS components use the TS Interface to communicate with the TSS as shown in Figure 10. All
data sent over the TS Interface must use the FACE Data Model. The TS Interface provides
communication between multiple PSS components and PCS components.
PSS components can also use the I/O Interface to communicate with the IOSS as shown in
Figure 10. PSS components can act as software abstractions by converting I/O Interface data to
the FACE Data Model for use in the TSS.
The Platform-Specific Graphics Services sub-segment may communicate directly with the
Graphics Processing Unit (GPU) driver as indicated by the Platform-Specific Graphics Services
block (right-most block in PSSS layer) in Figure 10.
PDS 1, PDS 2 and I/O
Service
Differentare
Different in different
address
address spaces
spaces
address spaces
Transport Services Segment

TS lib TS lib TS lib TS lib TS lib
TS API TS API TS API TS API TS API
Platform- Platform- Platform- Platform-
System-
Specific Level Configuration
Specific Specific Specific
Radar Graphics
Common Device EGI
Health Service Altimeter Graphics Services
Services Monitoring Services Services Services
Segment
I/O API I/O API I/O API I/O API
I/O I/O I/O I/O
I/O Services Lib Lib Lib Lib
Segment
GPU Driver
Figure 10: PSS Communication
For detailed steps on how the PSS components interact with the TS Interface and the I/O
Interface, see Sections 2.5.3 and 2.3.3, respectively.
2.4.2 Platform-Specific Device Services
The Platform-Specific Device Services (PDS) sub-segment is composed of components that are
used to normalize the interface between (a) system peripherals (e.g., EGIs, GPS receivers, radar

altimeters) and (b) components in the PCS and the PSSS which need to interact with those
peripherals.
The function of a PDS component for a given peripheral is to insulate components in the PCS
and PSSS from the effects of changes to the specific peripheral model used. For example, a
system might originally be designed to incorporate a Litton EGI, but later it might prove
necessary to replace the Litton with a Honeywell EGI. In this scenario, the Litton-specific PDS
would be replaced by a Honeywell-specific PDS, but the rest of the PCS and/or PSSS
components would be insulated from this change.
As indicated in Figure 5, a PDS component implements two defined interfaces:

 A PDS implements an interface “down” to a transport-specific I/O Service in the IOS.
— The PDS sends and receives messages over this interface using the I/O API defined
in the FACE Technical Standard Appendix D.
— Traffic on this interface consists of I/O Message Instances as defined in the FACE
Technical Standard, Section 3.4.1.1.
— An example would be an interface between an “EGI Manager” PDS and a MIL-STD-
1553 I/O Service in the IOS, which component talks to the target EGI device via the
1553 device driver. The I/O Data Movement Capability of the IOS would be
configured to route data and command traffic between that specific EGI device and
the corresponding EGI Manager PDS.
 A PDS implements an interface “up” (or “over”) to a component in the PCS (or elsewhere
in the PSSS) which requires communication with the associated peripheral device
— The PDS exchanges messages over this interface using the TS API defined in the
FACE Technical Standard, Appendix E.
— Traffic on this interface consists of messages that conform to the FACE Data Model.
— An example would be an interface between the EGI Manager component in the PDS
and the Display Manager component in the PCS. Both the EGI data output of the
PDS and the EGI data input required by the Display Manager would be defined using
the FACE Data Model, and the TSS would be configured to route EGI data (with unit
conversion and component selection between the two models as necessary) between
the EGI Manager and the Display Manager.
In addition to supplying the interfaces to the PCS and IOS, the PDS component may also
provide device-specific services such as initialization, BIT management, status routing, message
throttling, and filtering, etc.
For any given device type or environment, it will need to be considered whether the interfaces
need to be unidirectional or bidirectional. Typically, the interface to the IOS would need to be
bidirectional, to allow the PDS to initialize the device, command BIT, etc. The interface to the
PCS or PSSS may only need to be unidirectional if its sole function is to pump data to data sinks.
It is recommended that a single PDS (or instantiation of a PDS) be used for each peripheral
device.

It is recommended that the PDS components be configured externally. However, currently,

neither the IOMM nor the FACE Data Model explicitly supports the Centralized Configuration
Service, so a system integrator may choose to use local configuration in the near term.
A PDS component should service a specific device type (e.g., an EGI). However, flexibility and
portability are enhanced if the PDS can be configured to handle different models or versions of
the target device type.
Depending on the context, it may be worthwhile for a PDS component to be configurable in

terms of data pass-through rate, message filtering, BIT control, fault handling, etc.
If a given system design requires it, a PDS component may be designed to handle an arbitrary
number of identical peripherals, in which case it would need to be configurable with the number
and identity of the devices.
2.4.2.3 Variability
PDS component design can vary substantially as a function of its interface requirements.
If a PDS only needs to route data in one direction (e.g., from the IOS to the PCS):
 It could be implemented as an autonomous thread that runs a simple loop:
while (forever)
wait for new message from IOS
pass message on to PCS
endwhile
 Simpler still, the PDS could be implemented as a function that relays data to the PCS,
which is registered as a callback with the I/O Data Movement capability; in this case, the
callback function should not be written to block.

OSS
Display
Processor 2
Manager
TS API
TS library
All data passed through
the TS API is conformant OS API
to the FACE Data Model
OSS
OS API
TS library
TS API
EGI
Processor 1 Manager
I/O API
1553 I/O
Service
1553 Driver
EGI
Figure 11: PDS EGI Example
Figure 11 shows how components from multiple FACE segments can work together to give a
high-level example. For detailed steps on how the PSS components interact with the TS
Interface and the I/O Interface, see Sections 2.5.3 and 2.3.3, respectively.
If a PDS needs to route data in both directions as shown in Figure 11, then it may be
implemented using two separate threads, one for each direction. One thread would be
responsible for communications between the EGI manager and the EGI Device through a non-
distributed MIL-STD-1553 I/O Service. The data flow steps are similar to those described in
Section 2.3.3.1.

7
OSS
Display 6
Processor 2
Manager
TS API 5
TS library
the TS API is conformant OS API 4
3
OSS
OS API
TS library 2
TS API
EGI 1
Processor 1 Manager
I/O API
1553 I/O
Service
1553 Driver
EGI
Figure 12: EGI Manager Display Manager Communication Thread
Figure 12 represents the data flow between the EGI Manager running on Processor 1 and the
Display Manager running on Processor 2 through the TSS. The following list describes the
sequence of actions the EGI manager performs to send data from the EGI to the Display
Manager Portable Component.
1. EGI Manager populates the data structure using the FACE Data Model (FACE Technical
Standard, Section 3.6).
2. EGI Manager sends the message to the TS Library by calling the Send_Message(TS)
function (FACE Technical Standard, Section E.7).
3. TS Library on Processor 1 constructs the TS Message Instance based on the TSS Message
and Internal Data Structure (FACE Technical Standard, Section 3.7.5).
4. TS Library on Processor 1 executes the Send_Message(TS) function using IPC to send the
TS Message Instance to the TS Library on Processor 2 (FACE Technical Standard,
Section E.7).
5. TS Library on Processor 2 receives the TS Message Instance from the EGI Manager.
6. The Display Manager receives the data from the TS Library on Processor 2 by executing
the Receive_Message(TS) function (FACE Technical Standard, Section E.6).

7. The Display Manager interprets the data structure using the FACE Data Model (FACE
Technical Standard, Section 3.6).
The PDS could also be implemented as two send functions (one in each direction) registered as
callbacks. One callback would be registered by the PDS with the I/O Data Movement capability
for data going from the IOS to the PCS. The other callback would be registered by the PCS for
data going from the PDS to the PCS through the TSS. If the PDS is registering a callback, it
assumes that the I/O Service is responsible for handling any interface-specific requirements,
such as the scheduling and issuing of read commands in a command-response type protocol. The
callback would be used by the PDS to subscribe to the data corresponding to a read command
being scheduled and issued by the I/O Service. If the PDS is responsible for timing or issuing
read commands, such as in Section 2.3.3.1, it is not expected that it would register a callback.
OSS 13
1
Display 12
Processor 2
Manager
TS API 11
TS library
the TS API is conformant OS API 10
9
OSS
OS API
8
TS library
TS API 6,7
2
EGI
5
Processor 1 Manager
I/O API
4
3,4 1553 I/O
Service 3
1553 Driver
2
EGI
Figure 13: EGI PDS Implementation with Callbacks
Figure 13 highlights the steps required for initialization of the callbacks using yellow circles.
The following list describes the sequence of actions required for initialization of the callbacks:
1. Display Manager registers a callback function with the TS Library using the
Register_Callback(TS) function (FACE Technical Standard, Section E.8).
2. EGI Manager registers a callback function with the I/O Library using the Register(I/O)

3. MIL-STD-1553 I/O Service Reads its configuration to determine which data needs to be
read from the EGI.
4. MIL-STD-1553 I/O Service schedules a periodic read of the 1553 bus using the device
driver’s API.
Figure 13 details the flow of data using white circles. The following list describes the sequence
of actions for a single PDS to receive a single message from a single EGI device after the
initialization steps complete:
1. MIL-STD-1553 I/O Service uses the 1553 driver’s API to send the read command.
2. MIL-STD-1553 I/O Driver reads data from the EGI.
3. MIL-STD-1553 I/O Driver returns data to the I/O Service through the device driver using
the driver’s API.
4. MIL-STD-1553 I/O Service packs data using the IOMM (FACE Technical Standard,
Section 3.4.1).
5. MIL-STD-1553 I/O Service executes the callback function registered by the PDS.
6. PDS callback function unpacks data using the IOMM (FACE Technical Standard, Section
3.4.1).
7. PDS Callback function populates the data structure conformant to the FACE Data Model
(FACE Technical Standard, Section 3.6).
8. PDS Callback function sends the message to the TS Library by calling the
Send_Message(TS) message (FACE Technical Standard, Section E.7).
9. TS Library on Processor 1 constructs the TS Message Instance based on the TSS Message
10. TS Library on Processor 1 sends the TS Message Instance to the TS Library on Processor
2 using IPC.
11. TS Library on Processor 2 receives the TS Message Instance from the EGI Manager.
12. TS Library on Processor 2 executes the callback function registered by the Display
Manager.
13. Display Manager Callback function unpacks data based on the FACE Data Model (FACE
A PDS could also be designed to handle data from multiple devices of the same type as shown in
Figure 14. An EGI Manager PDS could be designed to handle an arbitrary (but statically
configured) number of EGI devices. This would allow it to internally handle a redundant EGI,
failing over to it should the primary go offline.

OSS
Display
Processor 2
Manager
TS API

TS library
the TS API is conformant OS API
OSS
OS API OS API
TS library TS library
TS API TS API
EGI 1 EGI 2
Processor 1 Manager Manager
I/O API
1553 I/O
Service
1553 Driver
EGI 1 EGI 2
Figure 14: EGI Manager with Two Hardware Components
It is not recommended that a PDS be designed to handle more than one device type, as this
reduces portability.
A more portable design would be to introduce another PCS component to handle multiple EGI
PDS components, as shown in Figure 15. The Navigation Manager would determine which EGI
to listen to and handle failing over to the secondary EGI if necessary. The Display Manager
would still get input from a single source and would only need to be reconfigured to talk to a
different port.

OSS
Display
Processor 2 Nav Manager
Manager
TS API
OS API OS API
the TS API is conformant
OSS OS API OSS OS API

TS API Processor 3 TS API
EGI EGI
Manager Manager
I/O API I/O API
Processor 1 1553 I/O 1553 I/O
Service Service
1553 Driver 1553 Driver
EGI 1 EGI 2
Figure 15: PDS – Two EGI Manager Example
2.4.3 Platform-Specific Common Services

The Platform-Specific Common Services sub-segment defines a set of service components
which may be implemented on a FACE computing platform. The Platform-Specific Common
Services contains only Configuration Services, Platform Logging, Device Protocol Mediation
(DPM) Services, Streaming Media Services, and System-Level Health Monitoring, as defined in
the FACE Technical Standard, Section 3.5.3.
2.4.3.1 Configuration Services
The primary purpose of the Centralized Configuration Service is to enable sharing of

configuration information among system components and services. It handles the configuration
during initialization and run-time of all the FACE components in the system, as required.
Communication with Centralized Configuration Services can be through the TS Interface or the
I/O Interface. For more information on the Centralized Configuration Service, see Chapter 8.

2.4.3.2 Logging
2.4.3.2.1 Key Characteristics
The FACE Platform Logging Service is a software capability with the responsibility of
collecting messages sent by FACE components and logging them in a manner specified by the
system integrator. The Logging Service is able to communicate with FACE components using
the I/O Services Interface and the TS Interface.
Messages are required to be formatted using IETF RFC 5424: The Syslog Protocol, Section 6 –
Syslog Message Format. Only the message format is required by the FACE Technical Standard.
Messages traversing the TS Interface must meet the requirements of the FACE Data Model.
Messages traversing the I/O Services Interface must meet the requirements of the FACE IOMM.
The Logging Service is responsible for managing the implementation specifics of where the
information is logged. As an example, if the message data is stored in a file, any file type (e.g.,
ASCII, binary) can be used as long as the logged message format meets the requirement of IETF
RFC 5424, Section 6.
2.4.3.2.2 Configurability
For the FACE Platform Logging Service to operate, only one partition is required. However, it is
possible to have multiple instances of the Logging Service running on different computing nodes
throughout the platform. This may be necessary to distribute log message traffic throughout the
system instead of having all messages sent to a single location. It is suggested that the Service
runs in a POSIX partition as this allows communication with both POSIX and ARINC 653-
based partitions; however, if the system integrator knows that a certain instance will only be
communicating with ARINC 653-based partitions, a Logging Service running within an ARINC
653-based partition may be chosen.
The Logging Service should not require a significant amount of resources at run-time. Syslog
messages must be at least 480 octets (480 bytes) in length by definition in IETF RFC 5424 and
they have no maximum length; enough memory should be allocated to account for the longest
expected message to be received from other FACE components.
Large time slices for execution may not be required as the Logging Service is not parsing
messages, but disk or network access may be required depending on the type of logging the
system integrator chooses to use. However, if a significant number of log messages are expected,
the Logging Service will need to have a time slice often to service the messages and keep
transport buffers clear.
2.4.3.2.3 Variability
The Platform Logger can be written with one or more threads in order to service incoming
messages from other FACE components. If one thread is used to service messages from all
components, a timeout should be used when checking for messages from TS and I/O Interface
connections to allow for checking all available connections. The number of connections will
increase linearly with the number of IOS components on the platform, so the timeout may need
to be adjusted in order to service all log messages on different platforms.

If multiple threads are used, it is up to the developer to decide which threads will service which
connections and how many connections per thread. It may not be necessary to adjust thread
priorities, but if certain messages should be logged before others, adjusting thread prioritization
can handle that requirement.
There are different forms of logging that can be accomplished by the Platform Logging Service.
It may only need to log to certain files, or it may log the messages to the standard output stream.
Which method of logging is used will be up to the integrator. Also, messages from different
components may go to different files.
When maintaining a security log, a security-hardened OS and Logger may be required.
2.4.3.3 Device Protocol Mediation
Figure 16 shows a Device Protocol Mediation (DPM) service (PSSS Common Service) used to
talk to services and devices outside of the FACE environment. The DPM service acts as a
mediator between software which does not use FACE APIs and the rest of the FACE
components. It will interface with servers and hardware on one side and with a PSSS Device
Service using the I/O Interface (Generic Bus Message) on the other. The PSSS Device Service
provides an interface with the rest of the FACE components using the FACE TS API.
Platform-Specific Platform-Specific Device Services Platform-Specific Common Services

Services Segment
I/O
Device IO I/O OS OS I/O IO Device Protocol
Message
Manager API library API Model API library API Mediation Service
Ethernet
Figure 16: Device Protocol Mediation Service
This DPM service can also be used to virtualize hardware. An Embedded Global Positioning
System/Inertial Navigation System (EGI) software component could talk to the DPM which then
uses an OS service for the Ethernet to get the real EGI data from another processing resource.
2.4.3.4 Streaming Media
Streaming Media Services act as a streaming media adapter for platform imaging devices that
use media protocols (e.g., various Moving Picture Experts Group (MPEG), Society of Motion
Picture and Television Engineers (SMPTE) formats) with the OS. Figure 17 shows the Media
Service communicating with the computing platform and other FACE components.

Portable Component Segment
HMI
TS API
TS library Transport Services Segment
OS API
OS API OS API
TS API TS API
Platform-Specific Platform- Platform-Specific
Services Segment Specific Common Services
Graphics ARINC Media
Services
Platform-Specific 661 Service Media Service may
Device Services have access to the
Media Driver
Data is defined by
Media
the device ICD. Data
Driver is not required to be
GPU OS in the FACE message
Driver
OS format
Figure 17: Streaming Media Service
The data sent to and received from the streaming media device is defined by the streaming media
device Interface Control Document (ICD), and may not include the use of the IOMM. The
Media Service may have access to hardware drivers for the sole purpose of hardware accelerated
decoding of streaming media protocols and formats. The Media Service can communicate with
the Platform-Specific Graphics Services and FACE components using the TS Interface and the
FACE Data Model format.
2.4.3.5 System-Level Health Monitoring
Health Monitoring functionality may be provided as a component or group of components

spanning the OSS, PSSS, and/or PCS (as a Common Service). Health Monitoring can be
provided at partition or system level by PSS component(s). FACE components can be written to
detect faults and report them using the TS Interface or the I/O Interface to the Health Monitoring
component. For more information on the Health Monitoring, see Chapter 6.
2.4.4 Platform-Specific Graphics Services

The Platform-Specific Graphics Services sub-segment provides a set of graphics services to the
PCS. The graphics services provided vary by platform requirements and are selected by the
platform integrator. These components receive ARINC 661-4, X11 Byte Streams, and/or ARINC
739/739A-1 standardized streams of data for rendering. These components may communicate
directly with the GPU Driver or indirectly to other platform devices through the I/O Interface.
For more information on the Graphics Services, see Chapter 7.

2.5 Transport Services Segment
The Transport Services Segment (TSS) provides transport-agnostic communication capabilities
between FACE components. It allows a FACE component to be independent of the specific
transport mechanism. This is achieved by providing a standardized API for FACE components
to access the capabilities of the TSS. The main responsibility of the TSS is the distribution of
data between FACE components; the distribution capability is supported by several other
capabilities provided by the TSS.
Figure 18 illustrates the TSS consisting of several capabilities including:

 Distribution Capability
 Configuration Capability
— Message Association
 Paradigm Translation Capability
 Data Transformation Capability
— Data Transformation
— Data Marshalling
 Quality of Service (QoS) Management Capability
TRANSPORT SERVICES SEGMENT
QoS
MANAGEMENT
CAPABILITY
TS Interface DATA TRANSFORMATION CAPABILITY

Standardized
Interface used by
components of
Platform-Specific DATA
Services Segment TRANSFORMATION
and Portable
Components Segment
DISTRIBUTION DATA
CAPABILITY MARSHALLING
PARADIGM
PARADIGM
OS Interface PARADIGM
TRANSLATION
TRANSLATION
TRANSLATION
CAPABILITY
CAPABILITY
CAPABILITY
Operating System
Interface
MESSAGE
CONFIGURATION CAPABILITY
ASSOCIATION
Figure 18: Transport Services Segment Capabilities

At a minimum, a given TSS instantiation must include a Distribution Capability and a
Configuration Capability. The use of other capabilities, such as QoS Management Capability,
Data Transformation Capability, and Paradigm Translation Capability, are conditional based
upon the system requirements for a given instantiation of the TSS.
Flexibility of execution control (process control and threading) may be required to meet system
requirements. Implementation of execution control is the responsibility of the software supplier
and/or systems integrator. For example, a PCS or PSSS component with tight closed-loop
control requirements may want to exert control over scheduling and memory management of the
TSS. A PCS or PSSS component without stringent timing requirements may be better served by
delegating control of the communications timing to the TSS.
The following sections assume working knowledge of networking principles, POSIX sockets,
ARINC 653 ports, Data Distribution Service (DDS), and Common Object Request Broker
Architecture (CORBA).
MESSAGE DATA STRUCTURES

MESSAGE ROUTING
MESSAGE ROUTING GUID QOS DEFINITION KEY
MESSAGE ROUTING NAME QOS GUID
Required, Transmitted Message
MESSAGE SOURCE GUID QOS NAME
MESSAGE DESTINATION GUID QOS ATTRIBUTES (1..N)

Optional, Transmitted Message
SOURCE MESSAGE DEFINITION GUID
MESSAGE INSTANCE DESTINATION MESSAGE DEFINITION GUID Required, Data Architecture Information
MESSAGE HEADER
Required, Configuration Information
PLATFORM PAYLOAD
TRANSFORMATION MAP
ROUTING QOS Optional, Configuration Information
TRANSFORMATION MAP GUID
ASSOCIATION
TRANSFORMATION MAP NAME
QOS GUID
MESSAGE DEFINITION GUID 1
MESSAGE ROUTING GUID
MESSAGE DEFINTION GUID 2
QOS ATTRIBUTES VALUE (1..N)
TRANSFORMATION GUID
PLATFORM DATA MODEL

MESSAGE ASSOCIATION VIEW (HEADER) *
MESSAGE ASSOCIATION GUID
MESSAGE INSTANCE GUID USM
MESSAGE DEFINITION GUID
MESSAGE ASSOCIATION NAME
MESSAGE SOURCE GUID
MESSAGE GUID 1
MESSAGE TIMESTAMP
MESSAGE GUID 2
MESSAGE VALIDITY
PLATFORM DATA MODEL

VIEW (PAYLOAD) *
MESSAGE DEFINITION GUID
MESSAGE DEFINITION NAME
DATA ELEMENT GUID (1..N)

* Note: These will be transmitted as part
of the Message Instance
Figure 19: Transport Services Interface Message and Internal Data Structure
2.5.1.1 Message Instance
The Message Instance is data transferred between PCS and/or PSSS components using Transport
Services at run-time and consists of the Message Header and Platform Payload. The Message
Header is used for facilitating TSS communication. The Message Header is created by the
Distribution Capability of the TSS, contains the data elements as defined in Section 3.7.5.4 of
the FACE Technical Standard, and is shown in Figure 19. It is recommended the TSS
component implementing the Send_Message() function populates the Message Header. The
Platform Payload is returned to the PCS or PSSS component(s) calling the Receive_Message()

function. If the PCS or PSSS component requires any information represented in the Message
Header, it is recommended the information be included in the USM for the Platform Payload.
2.5.1.2 Distribution Capability
The Distribution Capability is a key capability of the TSS and is meant to abstract the transport
mechanism away from components residing in the PCS and PSSS. Without it, FACE PCS and
PSS components would be unable to communicate. The TSS allows components to be written
generically, without dependencies on a specific transport mechanism or defined communication
endpoint. This allows components to be used in other FACE environments without changes due
to different transport mechanisms.
The supporting capabilities Configuration, QoS Management, Message Association, Data

Conversion, and Paradigm Translation assist the Distribution Capability. Each of these
supporting capabilities will be described in the following sections.
2.5.1.3 Configuration Capability
The Configuration Capability promotes component portability across many different platforms
by avoiding implementation-specific software. In addition, configurability allows the system
integrator flexibility in choosing the appropriate transport and making the component
connections necessary to meet system requirements.
Using the configuration information provided by the Configuration Capability, the Distribution
Capability understands how to route data between endpoints and how it applies to other
capabilities (e.g., Message Association, Data Conversion). The Configuration Capability allows
components to be written for specific data types and named connections by providing a mapping
between the component connections of the implementation. The Configuration Capability
configures the Distribution Capability, on a per-implementation basis, allowing the component
to continue using the same name and data type for a connection. If you choose to make use of
Central Configuration Service, understand that you may need sufficient inherent configuration in
order to contact the Central Configuration Service.
In addition to assisting the Distribution Capability, the Configuration Capability supports QoS
Management, Message Association, Data Conversion, and Paradigm Translation. Each of these
capabilities will be described in the following sections.
2.5.1.4 Message Association Capability
The Message Association Capability allows for message associations within an implementation.
The Message Association Capability supports the ability to tag and associate messages to be sent
by the Distribution Capability. At initialization, the Configuration Capability configures any
message association needed for the implementation.
2.5.1.5 Quality of Service Management Capability
The Quality of Service (QoS) Management Capability allows the transport of information with
special requirements and service demands. FACE components may require certain QoS
attributes in order to adjust behavior of the Distribution Capability. The QoS Management
Capability uses information from the Configuration Capability to allow components to request
the QoS attributes necessary for successful operation of the component within the

implementation. The Distribution Capability must support the requested QoS attributes to
support this successful operation.
The Distribution Capability needs to provide consistent behavior to components as required by

the implementation. The Configuration Service allows QoS parameters to be configured to
support the interface needs of components. QoS parameters are determined by the needs of the
component. The Distribution Capability must support all QoS parameters as required by
components.
2.5.1.6 Data Transformation Capability
As the reuse of FACE conformant components become more prevalent, the potential for one or
more interface mismatches between components increases. In traditional systems, these interface
mismatches are corrected by either modifying the component code, or adding shim-code on top
of the application. Both of these approaches reduce, and often eliminate, any benefit from
component reuse. To mitigate the impact of interface mismatches, and maximize the portability
of UoPs, the ability to mediate data mismatches is allocated to the Data Transformation
Capability within a Transport Service component.
While there are many types of data mismatches, the Data Transformation Capability is explicitly
required to perform linear data conversions and data marshalling. While it is not required that a
TS component provide more complex transformations, such as conversions between certain
Frames of Reference, it is recommended that those conversions be performed by a TS
component.
The UoP Supplied Model (USM) for reusable components contains sufficient information to
document the required transformations. This information may be used by a TS component to
configure a general-purpose Data Transformation Capability. Alternatively, the same
information may be used to create purpose-built transformation code that meets any specific
safety and security requirements.
2.5.1.6.1 Linear Data Conversion
The FACE Data Architecture documents the meaning of each data element in each interface of a
UoP. This documentation includes the data type of the element, the units, the Frame of
Reference, and the precision of the representation. Conversions between data types (e.g., integer
to float) or units (e.g., feet to meters) are called linear conversions. These straightforward
conversions are the responsibility of a TS component. These types of conversions occur when
both the source and sink of the data element use the same Frame of Reference, but use different
units. Some, but not all, Frame of Reference conversions are also considered linear conversions.
2.5.1.6.2 Data Marshalling Capability
In addition to possible differences in the representation of data elements described above, it is

also possible that the source interface contains a different organization of data elements than the
sink interface. These kinds of structural differences require the ability to reorganize data from a
source structure into the structure required by the sink. This capability is provided by the Data
Marshalling Capability within a TS component.
Examples of Data Marshalling are aggregation, de-aggregation, data filter, and data enricher.
Aggregation takes data from multiple sources and combines it into a single interface parameter.

De-aggregation takes data from a single source and provides parts of that information to the sink
in different interfaces. Data filter removes elements from a parameter, and data enricher adds
information from a secondary source to complete an interface parameter. The ability of the TS
Data Marshalling Capability to mediate these types of data parameter mismatches increases the
reusability and portability of components with compatible, but different interfaces. It is the
responsibility of a TS component to make sure data transmitted between two components
maintains integrity, validity, and appropriate structure.
The UoP Supplied Model (USM) documents the content of each UoP interface. Examination of
the USMs of two or more UoPs provides sufficient information to allow an integrator to
determine the degree and amount of Data Marshalling that is required to reconcile the interfaces
and allow integration. Using this information, the integrator can make decisions about the
appropriateness, or the degree of difficulty of integration.
2.5.1.6.3 Other Transformations
In addition to Linear Conversions, and Data Marshalling, it is possible that more complex
transformations may be required. Examples of such conversions include many geospatial Frame
of Reference conversions. For example, the conversion of WGS84 Latitude, Longitude, and
Altitude to North, East, Down is a non-trivial conversion. There is no requirement that a TS
component perform these transformations. However, it is recommended that when geospatial
conversions are required, they are performed by TS components.
2.5.1.7 Paradigm Translation Capability
The FACE Technical Standard, Section 3.8.9, addresses two types of Paradigm Translations:
Message and Protocol. A message paradigm is a pattern of message exchange (e.g.,
Request/Reply, Publish/Subscribe, Queueing, and Command/Response). A protocol paradigm is
a pattern of rules or procedures describing communication interactions (e.g., TCP, UDP, DDS,
and CORBA). Paradigm Translation allows components using different message and/or protocol
paradigms to communicate.
The Paradigm Translation Capability may be implemented as a function or component within a

TSS UoP or as a standalone TSS UoP. When implemented as a standalone TSS UoP, the
Paradigm Translation Capability is required to use the FACE Data Model as specified in Section
3.8.3 of the FACE Technical Standard.
2.5.1.7.1 Message Paradigm Translation
A message paradigm is a pattern of message exchanges. Common examples include

Request/Reply, Publish/Subscribe, and Command/Response. When reusing existing PCS or
PSSS components, it is possible a mismatch in message exchange patterns may exist between
communicating components. As an example, a FACE component producing position
information may use Publish/Subscribe, while another FACE component may use
Request/Reply. Message Paradigm Translation is responsible for mediating such pattern
mismatches.
For additional information on messaging paradigm integration patterns visit Enterprise

Integration Patterns (www.eaipatterns.com).

2.5.1.7.2 Protocol Paradigm Translation
A protocol paradigm is a pattern of rules or procedures describing communication interactions

(e.g., TCP, UDP, DDS, and CORBA). Protocol paradigm translation converts from one transport
protocol to another.
2.5.1.8 Transport Mechanisms
The TSS abstracts components from specific transport mechanisms. Provided are some of the
commonly used transport mechanisms; this is not an all-inclusive list:
 UDP/TCP Sockets
 ARINC 653 Sampling and Queuing Ports
 CORBA
 Data Distribution Service (DDS)
 POSIX shared memory
The above list contains some of the identified options selectable by the integrator. However, the
underlying mechanism employed by the TSS may extend beyond these as long as they adhere to
the APIs and semantics of the above identified transport mechanisms.
Each of these transport mechanisms can be used within the TSS. Transport mechanisms such as
UDP/TCP Sockets, CORBA, and DDS can be used to communicate between different systems
on a platform.
Additional transport mechanisms can be used at the discretion of the system integrator. The TS
Interface is used between components and the Distribution Capability. The specific transport
mechanism standard governs the interface between the Distribution Capability and the transport
mechanism. The Configuration Capability is responsible for configuring any additional transport
mechanisms and associated connections.
2.5.1.9 Send_Message() and Receive_Message() Parameters
Some of the parameters in Send_Message(TS) and Receive_Message(TS) are defined as “in”,

indicating they are passed into the called function, some as “out” indicating they are passed back
to the calling function by pointer or reference, and some as “in/out” indicating they may be
inputs to the function or returns to the caller. The full list of parameters for each message along
with their directivity is shown in Table 1.
Table 1: Function Parameter Direction
Send_Message() Receive_Message()
in connection_id connection_id
message_size
timeout timeout

Send_Message() Receive_Message()
out return_code return_code
in/out message message

message_size
transaction_id transaction_id
connection_id
This parameter is generated by the TSS and returned to the caller during Create_Connection(TS)
as part of the communications setup procedure. It is retained by the calling component for use in
subsequent Send_Message(TS) and Receive_Message(TS) calls to specify to the TSS which
connection to use for the designated action.
timeout
This is an in parameter passed to the call to specify the amount of time the caller is willing to
wait for the action to complete. Note that the resolution of this parameter is one (1) nanosecond
as defined in the FACE Technical Standard and will require scaling when passed to functions
that use other bases (commonly microseconds) for timing parameters. INF_TIME_VALUE (-1)
indicates a wait for an infinitely long time. A function that times out before completion provides
the return code TIMED_OUT.
transaction_id
The use of this parameter is dependent on the role of the component and the messaging
paradigm. In a Request/Reply type interaction, the transaction_id should be used to associate
received data with a previous request when multiple requests may be outstanding within a single
connection. With respect to a CLIENT type connection, this is an out parameter to
Send_Message() and an in parameter for Receive_Message().
For the SERVER side of this connection, transaction_id is an in parameter for Send_Message()
and an out parameter to Receive_Message(). Here, Receive_Message() returns the transaction_id
of the incoming message from the client. The server component then uses this transaction_id
when sending a response using Send_Message(). As a clarification, the same transaction_id does
not need to be supplied on both sides of the TSS. Unique identifiers may be used for the client
and server with the TSS correlating and mapping between them.
In other contexts, such as PUB_SUB, the transaction_id is not intended to be pertinent to the
Send_Message()/Receive_Message() activity and could be disregarded by the end components.
message
The convention of using an in/out parameter for the message buffer signifies that the buffer is
passed by reference or pointer, and not by value, in order to conserve resources. Therefore, it
serves as an input from Send_Message() and an output to Receive_Message().

message_size (Send_Message())
Supplied as an in/out parameter and used by the calling component to indicate to the TSS the
size of the message to be sent. The TSS implementation then returns the actual amount of data
sent to the calling component for verification.
message_size (Receive_Message())
Supplied as an in parameter and used to indicate to the TSS the maximum size available in the
message buffer for incoming data.
Note: Future versions of the FACE Technical Standard will deprecate the use of this
parameter in Send_Message() and Receive_Message(). Neither the TSS, PSSS, nor
PCS should rely upon the value assigned to this parameter. Rather, the size should be
determined from the component’s knowledge of the data structure.
return_code
As an out parameter, this is used to provide a mechanism for the TSS to return a status indicating
the condition of completion of the requested action.
2.5.1.10 TSS Return Code Processing
To promote interoperability and portability between the FACE environments, the return codes
provided by the TSS for each API call should be consistent regardless of the underlying
transport mechanism. For example, the meaning of a return code of NO_ACTION or
NOT_AVAILABLE may differ based on a Receive_Message(TS), Send_Message(TS), or
Register_Callback(TS) function. Similarly, there are certain return codes (e.g.,
NOT_AVAILABLE or ADDR_IN_USE) that may be returned conditionally based on the API
call, transport mechanism used, and system state. Because FACE components do not have
knowledge of the underlying transport mechanism, the TSS must provide a consistent return
status, regardless of transport mechanism, for each API so FACE components can provide
appropriate and consistent handling for the error condition.
This section provides guidance for how TSS implementations should process error conditions
and provide the appropriate FACE return codes for each TS API and the currently identified
transport mechanisms. An explanation of all possible return codes for each TSS function is
provided. Some return codes are specific to a transport mechanism and do not directly map to
status codes in the other standard transport mechanisms.
Note: The next edition of the FACE Technical Standard will provide requirements for Return
Code processing.
Within the following subsections, portions of the transport mechanism descriptions section from
the FACE Technical Standard are shown to provide context.
Similarly, if a DDS connection uses sockets or APEX, the return statuses for those could be
handled accordingly as well. The TS implementer should keep in mind that a component should
be able to be written independent of the TS transport mechanism and interpret status codes
returned by the TS API.

2.5.1.10.1 FACE and ARINC 653 Return Codes
This section documents the correlation between the ARINC 653 functions and return codes to
FACE functions and return codes. ARINC 653 follows a couple of guiding principles when
associating specific error conditions with the return code:
1. Input parameters are validated and INVALID_PARAM is returned if invalid.
2. If the input parameter value is also part of configuration data, but is inconsistent with the
configuration data, INVALID_CONFIG is returned instead of INVALID_PARAM.
These principles were used when considering the differences in the parameters and configuration
data for the ARINC 653 services potentially used by a TSS and the FACE TSS functions used
by a FACE based component.
ARINC 653 defines fewer return codes than the FACE Technical Standard and these are a
proper subset as referenced in Table 2. The FACE return codes without mappings to ARINC 653
are for conditions that cannot occur when using ARINC 653 services.
Table 2: Mapping Between TSS FACE Return Codes and ARINC 653 Return Codes
FACE Return Code ARINC 653 Return Code
NO_ERROR NO_ERROR
NO_ACTION NO_ACTION
NOT_AVAILABLE NOT_AVAILABLE
ADDR_IN_USE (cannot occur)
INVALID_PARAM INVALID_PARAM
INVALID_CONFIG INVALID_CONFIG
PERMISSION_DENIED (cannot occur)
INVALID_MODE INVALID_MODE
TIMED_OUT TIMED_OUT
MESSAGE_STALE (cannot occur)
CONNECTION_IN_PROGRESS (cannot occur)
CONNECTION_CLOSED (cannot occur)
DATA_BUFFER_TOO_SMALL (cannot occur)
Because the FACE return codes fully encapsulate the ARINC 653 return codes, the ARINC 653
transport mechanisms for Queuing ports and Sampling ports will be trivial for the ARINC 653
services that have a corresponding FACE TSS function.

It should also be noted that there are several ARINC 653 functions that map very closely to the
FACE defined functions for inter-partition communication (e.g., ARINC 653 QUEUING_PORT
and SAMPLING_PORT).
2.5.1.10.2 FACE and POSIX Error Numbers
The POSIX standard defines a set of error numbers which are mapped to symbolic constants
found in the file <errno.h>. When the return value of a POSIX service indicates a failure has
occurred (typically by returning -1), the cause of the error can be identified by reading the error
number stored in errno. When a TSS is implemented using an underlying set of POSIX services,
it will be required to map POSIX errors into FACE return codes. This document will provide
guidance for how to map the POSIX error numbers into FACE return codes.
The POSIX specification defines many more error numbers than the FACE Technical Standard
defines return codes. In spite of this, conceptual differences between the FACE, ARINC 653,
and POSIX Specifications lead to FACE return codes which do not map into POSIX error
number equivalents.
An example of mapping between POSIX error numbers and FACE returns codes is shown in
Table 3. The FACE return codes without mappings to POSIX are for conditions that cannot
occur when using POSIX services.
Table 3: Mapping Between TSS FACE Return Codes and POSIX Error Numbers
FACE Return Code POSIX Error Numbers
NO_ERROR Successful return from POSIX service
NO_ACTION EISCONN
EEXIST
NOT_AVAILABLE EAGAIN
EWOULDBLOCK
EADDRNOTAVAIL
EINTR
ADDR_IN_USE EADDRINUSE
EINVAL
INVALID_PARAM EINVAL
EBADF
EAGAIN
ELOOP
ENAMETOOLONG
ENOENT
ENOTDIR
ENOTSOCK
EWOULDBLOCK
EIO
ENOTCONN

FACE Return Code POSIX Error Numbers
INVALID_CONFIG EAFNOSUPPORT
EINVAL
EMFILE
ENETUNREACH
ENFILE
ENOBUFS
ENOMEM
EFAULT
EOPNOTSUPP
EPROTONOSUPPORT
EROFS
ENOSPC
EMSGSIZE
ECONNREFUSED
PERMISSION_DENIED EPERM
EACCES
EFAULT
INVALID_MODE EINTR
TIMED_OUT ETIMEDOUT
EAGAIN
POSIX services do not typically set the errno value when successful. It is up to the calling
function to set errno to 0 before calling any POSIX service to ensure that the value read from
errno is due to a failure in the service being called and not left over from a previous call to a
POSIX service. There is no standard symbolic value for this. Some implementations include
E_OK, EOK, or ENOERROR but these are not standard and, if provided by an OS, should not
be used in a FACE conformant component.
2.5.1.10.3 FACE and CORBA Return Codes
The CORBA connection type is more than just transport mechanisms, but rather transport
services that may use one or more transport mechanisms. Depending upon the CORBA vendor
and TSS implementation, the return statuses from the specific CORBA implementation may
vary for the same condition. It would be difficult to provide detailed return status processing for
all possibilities. TSS implementers for a CORBA connection type should attempt to return status
codes from FACE TS APIs in a manner that is consistent with other transport mechanisms.
The suggested mapping between CORBA return codes and FACE returns codes is shown in
Table 4. The FACE return codes without mappings to CORBA are for conditions that cannot
occur when using CORBA services.

Table 4: Mapping Between TSS FACE Return Codes and CORBA Exception Code
FACE Return Code CORBA Exception Code
NO_ERROR (0 or no exception thrown)
NO_ACTION NO_RESPONSE
NOT_AVAILABLE NO_IMPLEMENT
ADDR_IN_USE (cannot occur)
INVALID_PARAM BAD_CONTEXT
BAD_INV_ORDER
BAD_PARAM
BAD_TYPECODE
DATA_CONVERSION
INV_FLAG
INV_IDENT
INV_OBJREF
MARSHAL
OBJ_ADAPTER
OBJECT_NOT_EXIST
TRANSIENT
UNKNOWN
INVALID_CONFIG BAD_QOS
CODESET_INCOMPATIBLE
IMP_LIMIT
INITIALIZE
INTERNAL
INTF_REPOS
INVALID_POLICY
NO_RESOURCES
PERMISSION_DENIED FREE_MEM
NO_MEMORY
NO_PERMISSION
PERSIST_STORE
INVALID_MODE BAD_OPERATION
TIMED_OUT TIMEOUT
CONNECTION_CLOSED COMM_FAILURE
Table 4 attempts to encompass most of the known CORBA exception codes in the CORBA
specification, Version 3.3. Depending upon the version of CORBA used, not all of these
exception codes may be available. In addition, depending on how CORBA is configured (e.g.,

with or without native exceptions), exception codes may need to be interpreted from the
CORBA::Environment or from a CORBA::Exception. It will be up to the implementer to
determine and return the appropriate FACE return code. For purposes of this document,
exception codes relating to the CORBA Activity Framework or the CORBA Transaction
Services are not listed.
Refer to the CORBA standard for more information and explanation of the specific exception
codes.
2.5.1.10.4 FACE and DDS Return Codes
The DDS connection type is more than just transport mechanisms, but rather transport services
that may use one or more transport mechanisms. Depending upon the DDS vendor and TSS
implementation, the return statuses from the specific DDS implementation may vary for the
same condition. It would be difficult to provide detailed return status processing for all
possibilities. TSS implementers for a DDS connection type should attempt to return status codes
from FACE TS APIs in a manner that is consistent with other transport mechanisms.
The nominal mapping between DDS return codes and FACE return codes is shown in Table 5.
The FACE return codes without mappings to DDS are for conditions that cannot occur when
using DDS services.
Table 5: Mapping Between TSS FACE Return Codes and DDS Return Code
FACE Return Code DDS Return Code
NO_ERROR OK
NO_ACTION ALREADY_DELETED
NO_DATA
NOT_AVAILABLE UNSUPPORTED
ADDR_IN_USE N/A
INVALID_PARAM BAD_PARAMETER
INVALID_CONFIG ERROR
OUT_OF_RESOURCES
IMMUTABLE_POLICY
INCONSISTENT_POLICY
PERMISSION_DENIED N/A
INVALID_MODE NOT_ENABLED
PRECONDITION_NOT_MET
ILLEGAL_OPERATION
TIMED_OUT TIMEOUT

Note: Per the DDS standard, the return codes OK, ERROR, ILLEGAL_OPERATION,
ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard
return codes and the specification won’t mention them explicitly for each operation.
Refer to the DDS standard for more information and for which specific operations may
return any of the additional (non-standard) error codes. For each of the FACE TS APIs,
the standard return codes will be mapped in addition to any additional error codes.
2.5.1.10.5 Initialize Function
The FACE Technical Standard, Section E.3.1 describes the Initialize(TS) function. The C
language prototype is:
/* C style declaration */
void FACE_TS_Initialize (
/* in */ FACE_CONFIGURATION_RESOURCE configuration,
/* out */ FACE_RETURN_CODE_TYPE *return_code);
The possible return codes for this function are described in Table 6.
Table 6: Initialize Return Codes
FACE Return Code Commentary
NO_ERROR Successful completion.
INVALID_CONFIG One or more of the input parameters are inconsistent with

configuration data or system limits.
2.5.1.10.6 Create_Connection Function
The FACE Technical Standard, Section E.3.2 describes the Create_Connection(TS) function.
The C language prototype is:
void FACE_TS_Create_Connection (
/* in */ FACE_CONNECTION_NAME_TYPE connection_name,
/* in */ FACE_MESSAGING_PATTERN_TYPE pattern,
/* out */ FACE_CONNECTION_ID_TYPE *connection_id,
/* out */ FACE_CONNECTION_DIRECTION_TYPE *connection_direction,
/* out */ FACE_MESSAGE_SIZE_TYPE *max_message_size,
/* in */ FACE_TIMEOUT_TYPE timeout,

Table 7: Create Connection Return Codes
NO_ACTION A connection named “connection_name” has already been created.
INVALID_CONFIG One or more of the input parameters are inconsistent with

configuration data or system limits.
INVALID_PARAM One or more of the parameters were invalid.
INVALID_MODE Operating Mode is NORMAL.
ADDR_IN_USE The address specified by the configuration data is already in use.
PERMISSION_DENIED Connection could not be created due to permission issues (e.g.,

either via user privileges or inability to access resource).
TIMED_OUT Timeout period for request has expired. For example, this may be
returned on a POSIX socket “connect”.
CONNECTION_IN_PROGRESS Asynchronous connection in progress.
CONNECTION_CLOSED Returned if the connection was closed or aborted.
Since the specific return codes for each transport mechanism may differ, the following sections
describe the specific return code explanation for each transport mechanism. There is an attempt
to keep the return codes consistent regardless of the transport mechanism. In addition, the TSS
Create_Connection(TS) function should be non-blocking, so a TSS implementation should
avoid performing blocking operations or internal return code processing that would result in a
blocking call.
ARINC 653 Sampling Port
When a sampling port is instantiated through Create_Connection(TS), there are certain

parameters that are required to have values and others associated with POSIX connections that
are NULL because they are not applicable for this particular transport mechanism.
/* NOTE: THESE ARE THE CALLS MADE BY TRANSPORT SERVICES */
void CREATE_SAMPLING_PORT (
/* in */ SAMPLING_PORT_NAME_TYPE SAMPLING_PORT_NAME,
/* in */ MESSAGE_SIZE_TYPE MAX_MESSAGE_SIZE,
/* in */ PORT_DIRECTION_TYPE PORT_DIRECTION,
/* in */ SYSTEM_TIME_TYPE REFRESH_PERIOD,
/* out */ SAMPLING_PORT_ID_TYPE *SAMPLING_PORT_ID,
/* out */ RETURN_CODE_TYPE *RETURN_CODE);
The FACE return codes should be based directly on the return codes for this service in ARINC
653 as shown in Table 8. Refer to ARINC 653 for more information.

Table 8: Create Connection Sampling Port Return Code Mapping
ARINC 653 Sampling

FACE Return Code Port Return Code Commentary
NO_ERROR NO_ERROR Successful completion.
NO_ACTION NO_ACTION The port named SAMPLING_PORT_NAME is

already created.
INVALID_CONFIG INVALID_CONFIG Implementation-defined limit to sampling port

creation is exceeded.
INVALID_CONFIG INVALID_CONFIG SAMPLING_PORT_NAME does not identify a

sampling port known by the configuration.
INVALID_CONFIG INVALID_CONFIG MAX_MESSAGE_SIZE is out of range or not

compatible with the configuration.
INVALID_CONFIG INVALID_CONFIG PORT_DIRECTION is invalid or not compatible

with the configuration.
INVALID_CONFIG INVALID_CONFIG REFRESH_PERIOD is out of range.
INVALID_MODE INVALID_MODE Operating Mode is NORMAL.
ARINC 653 Queuing Port
When a queuing port is instantiated through Create_Connection(TS), there are certain

parameters that are required to have values and others associated with POSIX connections that
are NULL because they are not applicable for this particular transport mechanism.
void CREATE_QUEUING_PORT (
/* in */ QUEUING_PORT_NAME_TYPE QUEUING_PORT_NAME,
/* in */ MESSAGE_SIZE_TYPE MAX_MESSAGE_SIZE,
/* in */ MESSAGE_RANGE_TYPE MAX_NB_MESSAGE,
/* in */ PORT_DIRECTION_TYPE PORT_DIRECTION,
/* in */ QUEUING_DISCIPLINE_TYPE QUEUING_DISCIPLINE,
/* out */ QUEUING_PORT_ID_TYPE *QUEUING_PORT_ID,
/* out */ RETURN_CODE_TYPE *RETURN_CODE);
The FACE return codes should be based directly on the return codes for this service in ARINC
653 as shown in Table 9. Refer to ARINC 653 for more information.
Table 9: Create Connection Queuing Port Return Code Mapping
ARINC 653 Queuing

NO_ACTION NO_ACTION The port named QUEUING_PORT_NAME

is already created.

ARINC 653 Queuing
INVALID_CONFIG INVALID_CONFIG Implementation-defined limit to queuing port

creation is exceeded.
INVALID_CONFIG INVALID_CONFIG QUEUING_PORT_NAME does not identify

a queuing port known by the configuration.
INVALID_CONFIG INVALID_CONFIG MAX_MESSAGE_SIZE is out of range or

not compatible with the configuration.
INVALID_CONFIG INVALID_CONFIG MAX_NB_MESSAGE is out of range or not

INVALID_CONFIG INVALID_CONFIG PORT_DIRECTION is invalid or not

INVALID_CONFIG INVALID_CONFIG QUEUING_DISCIPLINE is invalid or not

INVALID_MODE INVALID_MODE Operating Mode is NORMAL.
POSIX Socket
When a socket is instantiated through Create_Connection(TS), there are certain parameters that
have input and others associated with ARINC 653 connections that are NULL due to no
operation for this particular transport mechanism.
The following POSIX functions are called in this order by TS when the POSIX socket
connection is instantiated by Create_Connection(TS).
int socket(int domain, /* connection_domain */
int type, /* socket_type */
int protocol); /* chosen by the TSS */
int bind(int socket, /* connection_id */

const struct sockaddr *address, /* provided by TSS */
socklen_t address_len); /* provided by TSS */
OR
int connect(int socket, /* connection_id */
int listen(int socket, /* connection_id */

int backlog); /* provided by TSS */
int accept(int socket,

struct sockaddr *restrict address,
socklen_t *restrict address_len);

The FACE return codes should be mapped based on the POSIX errno values that may occur
with any of the socket based calls performed under a Create_Connection(TS) (e.g., socket(),
bind(), listen(), accept()). Table 10 provides a suggested mapping to FACE return codes.
Table 10: Create Connection Socket Return Code Mapping
POSIX Socket errno

FACE Return Code Value Commentary
NO_ERROR socket(), bind(), Successful completion.

connect(), listen(), or
accept() succeeded
NO_ACTION N/A The socket based on the connection

name is already created.
NO_ACTION EISCONN Socket is already connected.
NOT_AVAILABLE EADDRNOTAVAIL Non-existent interface was requested.
INVALID_CONFIG EAFNOSUPPORT Implementation does not support

specified address family.
INVALID_CONFIG EINVAL Unknown protocol, invalid flags.
INVALID_CONFIG EMFILE System limit reached, process file table

overflow.
INVALID_CONFIG ENETUNREACH Network is unreachable.
INVALID_CONFIG ENFILE System limit reached.
INVALID_CONFIG ENOBUFS Insufficient memory available.
INVALID_CONFIG ENOMEM Insufficient memory available.
INVALID_CONFIG EOPNOTSUPP Reference socket is not of correct type.
INVALID_CONFIG EPROTONOSUPPORT Protocol not supported.
INVALID_CONFIG EROFS Socket inode would reside on read-only

file system.
INVALID_PARAM EAGAIN No more free ports, insufficient cache.
INVALID_PARAM EBADF Invalid descriptor.
INVALID_PARAM ELOOP Too many symbolic links encountered.
INVALID_PARAM ENAMETOOLONG addr is too long.
INVALID_PARAM ENOENT File does not exist.
INVALID_PARAM ENOTDIR Path prefix not a directory.
INVALID_PARAM NOTSOCK Not a socket descriptor.

POSIX Socket errno
INVALID_PARAM EWOULDBLOCK Socket marked as non-blocking and no

connections are present to be accepted.
INVALID_MODE EINTR System call was interrupted by a signal.
TIMED_OUT ETIMEDOUT Timeout while attempting connection.
PERMISSION_DENIED EACCES No permission, address is protected.
PERMISSION_DENIED EFAULT addr points outside user’s accessible

address.
PERMISSION_DENIED EPERM No permission, no broadcast flag.
ADDR_IN_USE EADDRINUSE Address already in use.
ADDR_IN_USE EINVAL Set by bind() call if socket already

bound to an address.
CONNECTION_IN_PROGRESS EALREADY Socket is non-blocking and a previous

connection attempt has not yet been
completed.
CONNECTION_IN_PROGRESS EINPROGRESS Socket is non-blocking and the

connection cannot be completed
immediately.
CONNECTION_CLOSED ECONNABORTED Connection aborted.
POSIX Message Queue
When a message queue is instantiated through Create_Connection(TS) there are certain

parameters that have input and others associated with ARINC connections that are NULL due to
no operation for this particular transport mechanism. The TSS completes the parameter list of
the mq_open() function call.
mqd_t mq_open(const char *name, /* connection_name */
int oflag); /* connection_direction */
/* mqd_t is mapped to connection_id through TSS */
The returned “mqd_t” from the mq_open() call maps to the connection_id.
with any of the POSIX message queue calls performed under a Create_Connection(TS) (e.g.,
mq_open()). Table 11 provides a suggested mapping to FACE return codes.

Table 11: Create Connection Message Queue Return Code Mapping
POSIX Message Queue

FACE Return Code errno Value Commentary
NO_ERROR mq_open() succeeded Successful completion.
NO_ACTION N/A The queue based on the connection name is

already created.
NO_ACTION EEXIST O_CREATE and O_EXCL flags specified, but

queue with same name already exists.
INVALID_CONFIG EINVAL Attributes invalid, invalid flags.
INVALID_CONFIG EMFILE Process already has maximum files/queues

open.
INVALID_CONFIG ENFILE System limit of maximum files/queues reached.
INVALID_CONFIG ENOMEM Insufficient memory available.
INVALID_CONFIG ENOSPC Insufficient space for creation of new queue.
INVALID_PARAM ENAMETOOLONG Name was too long.
INVALID_PARAM ENOENT No queue exists with specified name, name was

just “/” followed by no other characters.
PERMISSION_DENIED EACCES The queue exists, but caller does not have
permission to open it, name contained more
than one slash.
POSIX Shared Memory
When shared memory is instantiated through Create_Connection(TS) there are certain

no operation for this particular transport mechanism. The TSS completes the parameter list of
the shm_open() function call.
The following POSIX functions are called in this order by TS when the POSIX shared memory
connection is instantiated by Create_Connection(TS).
int shm_open(const char *name, /* connection_name */
int oflag, /* chosen by TSS */
mode_t mode); /* chosen by TSS */
/* The returned “int” maps to the connection_id */

void *mmap(void *addr, /* connection_id */
size_t len,
int prot, /* chosen by TSS */
int flags, /* chosen by TSS */
int fildes, /* chosen by TSS */
off_t off); /* chosen by TSS */

with any of the POSIX shared memory calls performed under a Create_Connection(TS) (e.g.,
shm_open(), mmap()). Table 12 provides a suggested mapping to FACE return codes.
Table 12: Create Connection Shared Memory Return Code Mapping
POSIX Shared Memory

NO_ERROR shm_open() or mmap() Successful completion.

succeeded
NO_ACTION N/A The shared memory object for the connection

name is already created.
NO_ACTION EEXIST O_CREATE and O_EXCL flags specified, but

shared memory object with same name already
exists.
INVALID_CONFIG EINVAL Name argument invalid.
INVALID_CONFIG EMFILE Process already has maximum files open.
INVALID_CONFIG ENFILE System limit of maximum files reached.
INVALID_PARAM ENAMETOOLONG Name was too long.
INVALID_PARAM ENOENT No name exists and flags do not match request.
PERMISSION_DENIED EACCES Permission denied, no write permission to the

object.
CORBA
The possible CORBA exception codes may differ depending on how the Object Request Broker
(ORB) is initialized and the specific TSS implementation. The return codes listed in Table 13
represent a nominal set of expected return statuses, but may not be inclusive. Refer to Table 4
for additional mappings of exception codes that may be returned depending on the specific
CORBA invocations being made by the TSS implementation.
Table 13: Create Connection CORBA Exception Code Mapping
FACE Return Code CORBA Exception Code Commentary
NO_ERROR 0 or no exception thrown Successful completion.
NO_ACTION N/A The object reference has already been created

and resolved.

INVALID_CONFIG IMP_LIMIT Sample exception conditions:

INITIALIZE  ORB arguments are invalid.
INTERNAL
INTF_REPOS  Naming service could not be found.
INVALID_POLICY  Naming service could not be resolved
NO_RESOURCES (e.g., narrow failed, was NIL).
INVALID_PARAM BAD_CONTEXT Sample exception conditions:

BAD_INV_ORDER  Naming service was not able to resolve
BAD_PARAM the name.
BAD_TYPECODE
INV_FLAG  Parameters invalid.
INV_IDENT  Invalid flags or invalid identifiers.
INV_OBJREF
TRANSIENT
UNKNOWN
INVALID_MODE BAD_OPERATION Connection could not be created in the current

mode (e.g., ARINC 653 Partition Mode =
NORMAL).
Data Distribution Service
The possible DDS-based return statuses may differ depending on how the TSS is implemented.
The return codes listed in Table 14 represent a nominal set of expected return statuses, but may
not be exhaustive:
Table 14: Create Connection DDS Return Code Mapping
FACE Return Code DDS Return Code Commentary
NO_ERROR OK Successful completion.
NO_ACTION N/A There is not a specific DDS return code, but

NO_ACTION should be returned if the
participant has already been created and
registered.
NO_ACTION PRECONDITION_NOT_MET Type has already been registered.
INVALID_CONFIG OUT_OF_RESOURCES Could not allocate enough memory.
INVALID_CONFIG INCONSISTENT_POLICY Policies are not consistent with each other

(e.g., configuration data is invalid, QoS
attributes not supported).
INVALID_CONFIG ERROR Generic, unspecified error.
INVALID_CONFIG IMMUTABLE_POLICY Attempted to modify an immutable QoS

Policy.

INVALID_PARAM BAD_PARAMETER Returned under the following conditions:

 Could not find topic name associated
with the connection.
NOT_AVAILABLE UNSUPPORTED Unsupported operation.
INVALID_MODE ILLEGAL_OPERATION Connection could not be created in the current

mode or operation performed at an
inappropriate type.
2.5.1.10.7 Destroy_Connection Function
The FACE Technical Standard, Section E.3.3 describes the Destroy_Connection(TS) function. A
sample function prototype is:
void FACE_TS_Destroy_Connection(
/* in */ FACE_CONNECTION_ID_TYPE connection_id,
Table 15: Destroy Connection FACE Return Codes
NO_ACTION System state was unaffected by the operation. This will be returned if no
operation was performed (e.g., ARINC 653, connection already destroyed).
INVALID_PARAM No connection found with connection ID.
NOT_AVAILABLE Action could not be completed at the time (e.g., not supported or interrupt).
PERMISSION_DENIED Connection could not be destroyed due to permission issues (e.g., no

permissions).
The following describes the guidelines from the FACE Technical Standard:
1. The Destroy_Connection(TS) function performs no action and returns no errors for
ARINC 653-based software components.
2. TSS keeps track of the mqd_t descriptors and have them searchable by connection name.
3. TSS keeps track of the address and length of the shared memory referenced by the
connection name.
4. int mq_unlink(const char *name); is called after mq_close() in TSS.
5. int shm_unlink(const char *name); is called after munmap() in TSS.

6. For DDS, TSS keeps track of the DDS_DomainParticipant and DDS_Topic variables for
deletion.
7. For SOURCE connection_direction, the DDS_Publisher and DDS_DataWriter is kept
track of for deletion.
8. For DESTINATION connection_direction, the DDS_Subscriber and DDS_DataReader is
kept track of for deletion.
ARINC 653 Sampling Port and ARINC 653 Queuing Port
As an ARINC 653 implementation, no implementation is required on a Destroy_Connection(TS)

function for either sampling or queuing ports. This function will simply return without doing
anything. Therefore, the return code that most closely describes this processing is NO_ACTION
(status of system unaffected by request). This is not an error condition. The other possible return
codes of NO_ERROR (request valid and operation performed), NOT_AVAILABLE (resource
required by request unavailable), and CONNECTION_CLOSED (connection was closed) do not
fit as well due to the descriptions of these return codes. NO_ERROR does not fit because the
description states the operation was performed, but no destroy/disconnect occurs.
NOT_AVAILABLE does not fit because the description states that the action could not be
performed due to the resource needed for the action being unavailable, implying that the
resource may later become available and then the action would return with NO_ERROR, which
will never happen. CONNECTION_CLOSED does not fit because the connection was not
closed. Thus, in an effort to maintain consistency with the return statuses from ARINC 653 and
FACE, we should use the NO_ACTION return status as reflected in Table 16.
Table 16: Destroy Connection ARINC 653 Ports Return Code Mapping
NO_ACTION ARINC 653 connections do not get destroyed.
POSIX Socket
A POSIX socket will need to be closed upon a Destroy_Connection(TS) function call. The
following POSIX functions are called in this order by TS when the POSIX socket connection is
closed by Destroy_Connection(TS):
int close(int socket);
The FACE return codes provided in Table 17 should be mapped based on the POSIX errno
value that may occur with any of the socket-based calls performed under a
Destroy_Connection(TS) (e.g., close()).
Table 17: Destroy Connection Socket Return Code Mapping
POSIX Socket errno

NO_ERROR close() succeeded Successful completion.

POSIX Socket errno
NO_ACTION N/A The socket is already closed.
INVALID_PARAM EIO I/O error occurred.
NOT_AVAILABLE EINTR System call was interrupted by a signal.
POSIX Queue
The FACE return codes referenced in Table 18 should be mapped based on the POSIX errno
value that may occur with any of the POSIX queue calls performed under a
Destroy_Connection(TS) (e.g., mq_close(), mq_unlink()).
Table 18: Destroy Connection Message Queue Return Code Mapping
POSIX Message Queue

NO_ERROR mq_close() or mq_unlink() Successful completion.

succeeded
INVALID_PARAM EBADF Not a valid message queue descriptor.
INVALID_PARAM ENAMETOOLONG Invalid name length.
INVALID_PARAM ENOENT Named queue does not exist.
PERMISSION_DENIED EACCES Permission denied.
POSIX Shared Memory
value that may occur with any of the POSIX shared memory calls performed under a
Destroy_Connection(TS) (e.g., munmap(), shm_unlink()).
Table 19: Destroy Connection Shared Memory Return Code Mapping
POSIX Shared Memory

NO_ERROR munmap() or shm_unlink() Successful completion.

succeeded
INVALID_PARAM EBADF Not a valid message queue descriptor.
INVALID_PARAM ENAMETOOLONG Invalid name length.
INVALID_PARAM ENOENT Named queue does not exist.

POSIX Shared Memory
INVALID_PARAM EINTVAL Arguments invalid.
PERMISSION_DENIED EACCES Permission denied.
CORBA
The possible CORBA-based return statuses may differ depending on how the TSS is
implemented. The exception codes referenced in Table 20 represent a nominal set of expected
return statuses, but may not be exhaustive. Refer to Table 4 for additional mappings of exception
codes that may be returned depending on the specific CORBA invocations being made by the
TSS implementation.
Table 20: Destroy Connection CORBA Exception Code Mapping
NO_ERROR 0 (or no exception) Successful completion.
NO_ACTION OBJECT_NOT_EXIST Object not available.
INVALID_PARAM BAD_INV_ORDER Sample exception conditions:

BAD_PARAM  Invocations out of order
 Bad parameter
The return codes referenced in Table 21 represent a nominal set of expected return statuses, but
may not be exhaustive:
Table 21: Destroy Connection DDS Return Code Mapping
NO_ACTION ALREADY_DELETED Object target of this operation has already been

deleted.
INVALID_MODE ILLEGAL_OPERATION An operation was invoked on an inappropriate

object or at an inappropriate time.
INVALID_PARAM BAD_PARAMETER Connection identification (ID) invalid.

INVALID_MODE PRECONDITION_NOT_MET A pre-condition for the operation was not met.

Note: In a FACE implementation, this error
may imply an implementation problem since
the connection is deleted and should clean up
all entities/children associated with the
connection.
2.5.1.10.8 Receive_Message Function
The FACE Technical Standard, Section E.3.4 describes the Receive_Message(TS) function. A
void FACE_TS_Receive_Message_FACE_SPECIFIED_TYPE (
/* inout */ FACE_TRANSACTION_ID_TYPE *transaction_id,
/* inout */ FACE_SPECIFIED_TYPE *message,
/* in */ FACE_MESSAGE_SIZE_TYPE message_size,
The “_FACE_SPECIFIED_TYPE” suffix is necessary to differentiate calls for multiple message

types since C does not support function overloading (FACE Technical Standard, Section E.2.3).
The type FACE_SPECIFIED_TYPE also needs to be replaced with the specific type of the
message being received and correlates to the suffix of the function name.
Table 22: Receive Message FACE Return Codes
NO_ACTION There is no message in the connection to retrieve (e.g., empty).
INVALID_PARAM One or more of the parameters are incorrect (e.g., invalid connection ID,
timeout out of range).
TIMED_OUT Specified timeout expired.
NOT_AVAILABLE There is no new message in the connection to retrieve (e.g., empty).
INVALID_CONFIG For ARINC/POSIX queues, the queue has overflowed since last read.
INVALID_MODE Connection is not configured to operate as a destination.
Receive message is used to call the following ARINC 653 function calls:
Sampling Port READ_SAMPLING_MESSAGE

Queuing Port RECEIVE_QUEUING_MESSAGE
Receive message is used to call the following POSIX function calls:
Sockets recv(), recvfrom(), recvmsg()
Message Queue mq_receive(), mq_timedreceive()
Shared Memory None.
The FACE return codes for Receive_Message() should be based directly on the return codes for
this service in ARINC 653 as shown in Table 23. Refer to ARINC 653 for more information.
Table 23: Receive Message Sampling Port Return Code Mapping
ARINC 653 Sampling

NO_ACTION NO_ACTION Sampling port is empty.
INVALID_PARAM INVALID_PARAM SAMPLING_PORT_ID does not identify an

existing port.
INVALID_PARAM INVALID_PARAM TIME_OUT is out of range.
INVALID_MODE INVALID_MODE Port is not configured to operate as a

destination.
The FACE return codes for Receive_Message() should be based directly on the return codes for
this service in ARINC 653 as shown in Table 24. Refer to ARINC 653 for more information.
Table 24: Receive Message Queuing Port Return Code Mapping
ARINC 653 Queuing

TIMED_OUT TIMED_OUT Specified timeout is expired.
INVALID_PARAM INVALID_PARAM QUEUING_PORT_ID does not identify an

existing port.

ARINC 653 Queuing
INVALID_MODE INVALID_MODE QUEUING_PORT_ID is not configured to

operate as a destination, (pre-emption is
disabled or process is error handler process),
and timeout is not zero.
INVALID_CONFIG INVALID_CONFIG The queue has overflowed since it was last

read.
NOT_AVAILABLE NOT_AVAILABLE There is no message in the queuing port.
POSIX Socket
values that may occur with any of the socket based calls performed under a
Receive_Message(TS) (e.g., recv(), recvfrom(), recvmsg()).
Table 25: Receive Message Socket Return Code Mapping
POSIX Socket errno

NO_ERROR recv(), recvfrom(), or Successful completion.

recvmsg() succeeded
NO_ACTION recv(), recvfrom(), or No data read from socket.

recvmsg() return 0
INVALID_PARAM ENOTCONN Not associated with protocol, not connected.
INVALID_PARAM ENOTSOCK Argument does not refer to a socket.
INVALID_PARAM EINVAL Invalid argument.
INVALID_MODE EINTR System call was interrupted by a signal.
INAVLID_CONFIG ECONNREFUSED Socket is not connected.
INAVLID_CONFIG EFAULT Outside of addr space.
INAVLID_CONFIG ENOMEM Could not allocate memory for recv.
TIMED_OUT EAGAIN Timeout expired.
POSIX Message Queue
value that may occur with any of the socket-based calls performed under a
Receive_Message(TS) (e.g., mq_receive(), mq_timedreceive()).

Table 26: Receive Message Message Queue Return Code Mapping
POSIX Message Queue

NO_ERROR mq_receive or Successful completion.

mq_timedreceive succeeded
TIMED_OUT ETIMEDOUT Specified timeout is expired.
INVALID_MODE EINTR Call interrupted by signal handler.
INVALID_CONFIG EMSGSIZE Invalid length/size of queue.
NOT_AVAILABLE EAGAIN There is no message in the queuing port.
POSIX Shared Memory
The FACE return codes provided in Table 27 should be mapped according to the implementation
of shared memory read (e.g., memcpy()). There are no specific return codes associated with the
POSIX calls, but the implementation should check for and return the following errors.
Table 27: Receive Message Shared Memory Return Code Mapping
POSIX Shared Memory

NO_ERROR N/A Successful completion.
NO_ACTION N/A Shared memory is empty.
INVALID_PARAM N/A Connection ID does not correspond to a shared

memory object. Timeout is out of range.
INVALID_MODE N/A Connection is not configured to operate as a

destination.
CORBA
The possible CORBA-based return statuses may differ depending on how the TSS is
implemented. The exception codes given in Table 28 represent a nominal set of expected return
statuses, but may not be exhaustive. Refer to Table 4 for additional mappings of exception codes
that may be returned depending on the specific CORBA invocations being made by the TSS
implementation.
Table 28: Receive Message CORBA Exception Code Mapping
NO_ERROR 0 or no exception Successful completion.

INVALID_CONFIG INTERNAL Sample exception conditions:

INVALID_POLICY  Internal error
NO_RESOURCES
 Not configured to operate as a destination
 Insufficient resources

INV_OBJREF  Invocations out of order
MARSHAL
TRANSIENT  Invalid object reference
OBJECT_NOT_EXIST  Error in marshalling
 Transient failure
 Object is not available
The return codes given in Table 29 represent a nominal set of expected return statuses, but may
not be exhaustive:
Table 29: Receive Message DDS Return Code Mapping

deleted.

INVALID_PARAM BAD_PARAMETER Illegal parameter value (e.g., connection ID).
INVALID_MODE NOT_ENABLED Operation invoked on an entity that is not yet

enabled.
NO_ACTION NO_DATA Indicates a transient situation where the

operation did not return any data but there is no
inherent error.
TIMED_OUT N/A DDS will not return TIMEOUT, but this could
be returned by the TSS implementation.

2.5.1.10.9 Send_Message Function
The FACE Technical Standard, Section E.3.5 describes the Send_Message(TS) function. A
void FACE_TS_Send_Message_FACE_SPECIFIED_TYPE (
/* inout */ FACE_TRANSACTION_ID_TYPE *transaction_id,
/* inout */ FACE_SPECIFIED_TYPE *message,
/* inout */ FACE_MESSAGE_SIZE_TYPE *message_size,
The “_FACE_SPECIFIED_TYPE” suffix is necessary to differentiate calls for multiple message

types since C does not support function overloading (FACE Technical Standard, Section E.2.3).
The type FACE_SPECIFIED_TYPE also needs to be replaced with the specific type of the
message being sent and correlates to the suffix of the function name.
Table 30: Send Message FACE Return Codes
NO_ACTION There is no message in the connection to retrieve (e.g., empty).
INVALID_PARAM One or more of the parameters are incorrect (e.g., invalid connection ID,
timeout out of range, message size).
TIMED_OUT Specified timeout expired.
NOT_AVAILABLE Insufficient space to store a new message.
INVALID_CONFIG Length not compatible with connection.
INVALID_MODE Connection is not configured to operate as a source.
Send message is used to call the following ARINC 653 function calls:
Sampling Port WRITE_SAMPLING_MESSAGE
Queuing Port SEND_QUEUING_MESSAGE
Send message is used to call the following POSIX function calls:
Sockets send(), sendmsg(), sendto()
Message Queue mq_send(), mq_timedsend()
Shared Memory None.

The FACE return codes for should be based directly on the return codes for this service in
ARINC 653 as given in Table 31. Refer to ARINC 653 for more information.
Table 31: Send Message Sampling Port Return Code Mapping
ARINC 653 Sampling

INVALID_CONFIG INVALID_CONFIG Length is does not match configuration for

specified port.

existing port.
INVALID_MODE INVALID_MODE Port is not configured to operate as a source.
The FACE return codes for should be based directly on the return codes for this service in
ARINC 653 as given in Table 32. Refer to ARINC 653 for more information.
Table 32: Send Message Queuing Port Return Code Mapping
ARINC 653 Queuing

TIMED_OUT TIMED_OUT Specified timeout is expired.

existing port.
INVALID_MODE INVALID_MODE QUEUING_PORT_ID is not configured to

operate as a source, (pre-emption is disabled or
process is error handler process), and timeout is
not zero.
INVALID_CONFIG INVALID_CONFIG Length is not compatible with configuration of

specified port.
NOT_AVAILABLE NOT_AVAILABLE There is no message space in the queuing port

to accept a new message.

POSIX Socket
value that may occur with any of the socket-based calls performed under a Send_Message(TS)
(e.g., send(), sendmsg(), sendto()).
Table 33: Send Message Socket Return Code Mapping
POSIX Socket errno

NO_ERROR send(), sendmsg(), or Successful completion.

sendto() succeeded
NO_ACTION EISCONN Already connected but a recipient specified.
INVALID_PARAM ENOTCONN Not associated with protocol, not connected.
INVALID_PARAM EINVAL Invalid argument.
INVALID_PARAM EMSGSIZE Invalid message size.
INVALID_MODE EDESTADDRREQ Not connection-mode.
INVALID_CONFIG EAGAIN Non-blocking would block.
INVALID_CONFIG EWOULDBLOCK Non-blocking would block.
INVALID_CONFIG EFAULT Outside of addr space.
INVALID_CONFIG ENOMEM Could not allocate memory for recv.
INVALID_CONFIG ENOBUFS No buffers available.
INVALID_CONFIG EOPNOTSUPP Some bit in flags not valid for socket.
NOT_AVAILABLE EINTR Signal occurred before data transmitted.
TIMED_OUT EAGAIN Timeout expired.
CONNECTION_CLOSED ECONNRESET Connection reset.
CONNECTION_CLOSED ENOTCONN Not connected.
CONNECTION_CLOSED EPIPE Local end has been shut down.
POSIX Message Queue
value that may occur with any of the socket-based calls performed under a Send_Message(TS)
(e.g., mq_send(), mq_timedsend()).

Table 34: Send Message Message Queue Return Code Mapping
POSIX Message Queue

NO_ERROR mq_send() succeeded or Successful completion.

mq_timedsend()
succeeded
NO_ACTION EINVAL Call would have blocked.
TIMED_OUT ETIMEDOUT Specified timeout is expired.
INVALID_MODE EINTR Call interrupted by signal handler.
INVALID_CONFIG EMSGSIZE Invalid length/size of queue.
NOT_AVAILABLE EAGAIN Queue was full and O_NON_BLOCK flag

specified.
POSIX Shared Memory
The FACE return codes referenced in Table 35 should be mapped according to the
implementation of shared memory write (e.g., memcpy()). There are no specific return codes, but
the implementation should check for and return the following errors.
Table 35: Send Message Shared Memory Return Code Mapping
POSIX Shared Memory


memory object. Timeout is out of range.
INVALID_MODE N/A Connection is not configured to operate as a

source.
CORBA
The possible CORBA-based return statuses may differ depending on the ORB selected and how
the TSS is implemented. The exception codes referenced in Table 36 represent a nominal set of
expected return statuses, but may not be exhaustive. Refer to Table 4 for additional mappings of
exception codes that may be returned depending on the specific CORBA invocations being made
by the TSS implementation.

Table 36: Send Message CORBA Exception Code Mapping
NO_ERROR 0 or no exception Successful completion.
INVALID_CONFIG INTERNAL Sample exception conditions:

INVALID_POLICY  Internal error
NO_RESOURCES
 Not configured to operate as a destination
 Insufficient resources

INV_OBJREF  Invocations out of order
MARSHAL
TRANSIENT  Invalid object reference
OBJECT_NOT_EXIST  Error in marshalling
 Transient failure
 Object is not available
The return codes referenced in Table 37 represent a nominal set of expected return statuses, but
may not be exhaustive:
Table 37: Send Message DDS Return Code Mapping

deleted.

INVALID_PARAM BAD_PARAMETER Illegal parameter value (e.g., connection ID).
INVALID_CONFIG OUT_OF_RESOURCES Service ran out of resources needed to complete

the operation.
INVALID_MODE NOT_ENABLED Operation invoked on an entity that is not yet

enabled.

TIMED_OUT TIMEOUT The operation timed out.
2.5.1.10.10 Register_Callback Function
The FACE Technical Standard, Section E.3.6 describes the Register_Callback(TS) function. A
void FACE_TS_Register_callback (
/* in */ FACE_WAITSET_TYPE waitset,
/* inout */ FACE_Read_Callback *data_callback,
/* in */ FACE_MESSAGE_SIZE_TYPE max_message_size,
The return status for the registration of the callback is specific to the TSS implementation and
not necessarily specific to the transport mechanism associated with the connection. Thus, TSS
implementers should return one of the following return statuses so the caller knows whether a
callback function is available, and if so whether it was successful and processing from the FACE
component can continue.
Table 38: Register Callback FACE Return Codes
NO_ACTION A callback is already registered for this connection.
INVALID_PARAM One or more of the parameters are incorrect (e.g., invalid connection
identification (ID), invalid callback, invalid message size).
NOT_AVAILABLE Callback/routing function not available (e.g., callback service is not

provided in this implementation).
INVALID_CONFIG One or more fields in the configuration data for the connection is invalid
(e.g., invalid TSS thread parameters).
2.5.1.10.11 Unregister_Callback Function
The FACE Technical Standard, Section E.3.7 describes the Unregister_Callback(TS) function.
A sample function prototype is:
void FACE_TS_SPECIFIED_TYPE_Unregister_Callback_<MessageType> (
The return status for the unregistration of the callback is specific to the TSS implementation and
not necessarily specific to the transport mechanism associated with the connection. Thus, TSS

implementers should return one of the following return statuses so the caller knows whether a
callback function is available, and if so whether it was successful and processing from the FACE
component can continue.
Table 39: Unregister Callback FACE Return Codes
NO_ACTION No callback is registered for this connection.
INVALID_PARAM One or more of the parameters are incorrect (e.g., invalid connection
identification (ID), invalid callback, invalid message size).
NOT_AVAILABLE Callback/routing function not available (e.g., callback service is not

provided in this implementation).
2.5.1.10.12 Get_Connection_Parameters Function
The FACE Technical Standard, Section E.3.8 describes the Get_Connection_Parameters(TS)

function. A sample function prototype is:
void FACE_TS_get_connection_parameters (
/* inout */ FACE_CONNECTION_NAME_TYPE *connection_name,
/* inout */ FACE_CONNECTION_ID_TYPE *connection_id,
/* out */ FACE_TRANSPORT_CONNECTION_STATUS_TYPE *connection_status,
The purpose of Get_Connection_Parameters(TS) is to get the information regarding the

requested connection. Certain communication APIs may be called natively without using the TS
Interface. For restrictions, see the FACE Technical Standard, Section E.4.
The FACE_TS_Get_Connection_Parameters() call is used to call the following ARINC 653

function calls:
Sampling Port GET_SAMPLING_PORT_ID GET_SAMPLING_PORT_STATUS
Queuing Port GET_QUEUING_PORT_ID GET_QUEUING_PORT_STATUS
POSIX function calls:
Sockets getsockname()
Message Queue mq_getattr()
Shared Memory None.
DDS does not need to call anything to determine the status of the connection. The most recent
DDS_ReturnCode_t or the validity of DataReader/Writer handles can be used to determine the
connection status.

Table 40: Get Connection FACE Return Codes
INVALID_PARAM The connection name or ID does not identify an existing connection.
NOT_AVAILABLE Connection status information is not available for the specified connection
ID.
INVALID_CONFIG Insufficient resources to perform the operation.
The FACE return codes for Get_Connection_Parameters(TS) should be based directly on the
return codes for this service in ARINC 653 as referenced in Table 41. Refer to ARINC 653 for
more information.
Table 41: Get Connection Sampling Port Return Code Mapping
ARINC 653 Sampling


existing port.
The FACE return codes for Get_Connection_Parameters(TS) should be based directly on the
return codes for this service in ARINC 653 as referenced in Table 42. Refer to ARINC 653 for
more information.
Table 42: Get Connection Queuing Return Code Mapping
ARINC 653 Queuing


existing port.

POSIX Socket
The FACE return codes given in Table 43 should be mapped based on the POSIX errno value
that may occur with any of the socket-based calls performed under a
Get_Connection_Parameters(TS) (e.g., getsockname()).
Table 43: Get Connection Socket Return Code Mapping
POSIX Socket errno

INVALID_PARAM EFAULT Name points to memory not valid to process

address space.
INVALID_CONFIG ENOBUFS Insufficient resources to perform operation.
POSIX Message Queue
The FACE return codes given in Table 44 should be mapped based on the POSIX errno value
that may occur with any of the message queue-based calls performed under a
Get_Connection_Parameters(TS) (e.g., mq_getattr()).
Table 44: Get Connection Message Queue Return Code Mapping
POSIX Message Queue

NO_ERROR mq_getattr() succeeded Successful completion.
POSIX Shared Memory
The FACE return codes given in Table 45 should be mapped according to the implementation.
There are no specific return codes, but the implementation should check for and return the
following errors.
Table 45: Get Connection Shared Memory Return Code Mapping
POSIX Shared Memory


memory object.

CORBA
Since there is not a specific CORBA implementation for getting connection status, it will be up
to the TSS implementation to maintain the connection status and provide the appropriate return
codes. The return codes referenced in Table 46 represent a nominal set of expected return
statuses, but may not be exhaustive:
Table 46: Get Connection CORBA Exception Code Mapping
FACE Return Code CORBA Return Code Commentary
INVALID_PARAM N/A Connection ID invalid.
NOT_AVAILABLE N/A Implementation not available.
Since there is not a specific DDS implementation for getting connection status, it will be up to
the TSS implementation to maintain the connection status and provide the appropriate return
codes. The return codes referenced in Table 47 represent a nominal set of expected return
statuses, but may not be exhaustive:
Table 47: Get Connection DDS Return Code Mapping
INVALID_PARAM N/A Connection ID invalid.
NOT_AVAILABLE N/A Implementation not available.
The Configuration Capability is responsible for retrieving and providing configuration
information to the TS capabilities. Most of the configuration information supports the
Distribution Capability directly.
Reference the FACE Technical Standard, Section E.5 for the full list of configuration attributes.
The following is a list of the attributes with a brief description of each.
The Connection Name attribute is used to match configuration information to a requested

connection by a UoP. The UoP will pass this value in with a call to the Create_Connection(TS)
function as defined in the FACE Technical Standard, Section E.5. The TS will use this parameter
to match the requested connection to the specific configuration parameters associated with that
name.
The Connection Type attribute is used to specify the underlying transport mechanism used for a
TS connection. There are attributes specified later for further configuration information specific

to the different underlying mechanisms. Connection Type is designed to be extensible so new
transport mechanisms may be added as necessary.
The Connection Direction attribute is used to specify the behavior of the connection and is
returned from the Create_Connection(TS) call. It helps distinguish whether a connection is
Publish/Subscribe or client/server and which part of the interaction the UoP requires of the
connection.
Connection Domain and Socket Type are specific to the POSIX socket transport mechanism and
are internal to the TSS. Connection Domain distinguishes between UNIX or Internet sockets.
Socket Type is used to determine whether TCP or UDP is used. If other network protocols (e.g.,
Real-time Transport Protocol (RTP)) are used, these Connection Domain and Socket Type
values should be adjusted to indicate this.
Max Message Size is used to indicate the maximum size of the data to be sent on the connection.
This value should be the maximum size of the data plus the size of the TSS header as described
in the FACE Technical Standard, Section 3.7.5, and determined by the system integrator when
configuring the TS connection.
Message Range describes the maximum number of messages the Distribution Capability is
required to buffer. Message Range is only used when ReadWriteBehavior is configured to be
Queuing.
Messages Associated is a list of Globally Unique Identifiers (GUIDs) used to indicate the
messages transmitted in the configuration. Note that this is not related to the Message
Association Capability described in Section 2.5.1.4.
Data Transform Required is a boolean used to indicate whether or not data on this connection
needs to be converted to allow for proper execution of the UoP.
Refresh Period is an attribute used to indicate the length of time a message is valid. For example,
Refresh Period can be used to configure ReadWriteBehavior for Sampling Ports.
The Reliability attribute indicates whether or not transmission of data must be guaranteed or
best-effort. If guaranteed delivery is required, use an underlying guaranteed delivery transport
mechanism. Transports that provide guaranteed delivery natively can be used for best-effort
delivery without further configuration or development.
ReadWriteBehavior is used to indicate whether or not the connection should act in a similar
manner to the ARINC 653 Sampling or Queuing ports. The use of this attribute does not require
the use of the ARINC 653 transport mechanisms.
Queue Discipline attribute describes the queuing behavior of a connection. The attribute can be
set to First In, First Out (FIFO) or Priority. Treatment of queuing buffers is different in POSIX
and ARINC. POSIX is priority-based and ARINC is FIFO-based. For ARINC this attribute
affects blocked processes. Priority queuing allows for the possibility that some data may be more
important than others. Data may be placed into the queue based on priority. This attribute is only
valid when the ReadWriteBehavior is configured to be Queuing.
Receive Flag and Send Flag are used to configure POSIX socket connections only.

Source, Destination, Source Port, and Destination Port are POSIX socket-specific configuration
attributes. They identify the IP address and port number to be used for the connection. There
must be an IP address and port for each Source and Destination. There can be one source to
multiple destinations or multiple sources to one destination. Note that these attributes are not
intended to apply to ARINC source and destination ports.
The Filter Specification value is an optional configuration item and should only be implemented
on the producer/publisher TS Library. The Filter Specification value is defined by a Structured
Query Language (SQL) string. If Object Management Group (OMG) DDS is used, then filters
are built into the transport mechanism. If OMG DDS is not used, and the Filter Specification
functionality is desired, then the TSS developer needs to implement an SQL parser and filter
inside the TS Library.
Thread List, Priority, Scheduling Policy, Thread Rate, and Thread Stack Size relate to listing the
threads and their associated attributes the TSS may require. This may be necessary if a
connection uses callbacks to provide data to a component, to separate network stack processing
for sockets, or provide different QoS Management Capabilities.
The Configuration Capability supports both static and dynamic configuration. Static
configuration requires the TSS to be configured at compilation time. This can create more
optimized code and minimize the amount of resource allocation at run-time. Dynamic
configuration requires the TSS to be configured at initialization. This is done through a call to
Initialize(). The configuration resource for the component’s connections is passed to the TSS.
2.5.2.1 Example TS Configuration File
A generic example TS Configuration File for an implementation with two connections being
configured is shown below. This example does not show the XSD for the system, but an XML
file validated against an XSD based on the FACE Technical Standard. The XML has elements
for the parameters defined in the FACE Technical Standard, Section E.12. Unneeded parameters
can be empty fields as seen in the domain and socket type when configuring a nonsocket
connection. Unneeded parameters can also be omitted as exampled by the thread-specific
parameters left out of the XML because only one thread is being used. Both connections do not
require a data transformation or a filter specification.
The first connection configuration shown is configuring a queuing port for two-way
Request/Reply communication. The queuing port does not need to configure a socket so all of
the socket associated parameters are left empty. There is only one GUID associated with this
connection and the communication is reliable so messages are guaranteed to be delivered.
The second connection configuration shown is configuring a POSIX socket connection. The
socket parameters are defined so the TS service knows the source and destination of the
connection. There are two GUIDs associated with this connection and the communication is
unreliable so messages cannot be guaranteed.
<?xml version=”1.0” encoding=”UTF-8”?>
<connection_list>
<connection>
<name>example_connection1</name>
<type>QUEUING_PORT</type>
<direction>SOURCE</direction>

<maxmessagesize>100</maxmessagesize>
<associatedMessages>
<messagedefinitionguid>10</messagedefinitionguid>
</associatedMessages>
<datatransformrequired>false</datatransformrequired>

<readwrite_behav>BUFFERING</readwrite_behav>
<domain></domain>
<sockettype</sockettype>
<receiveflag></receiveflag>
<sendflag></sendflag>
<sourceaddress></sourceaddress>
<sourceport></sourceport>
<destinationport></destinationport>
<filterspecification></filterspecification>
<threadlist>
</threadlist>
</connection>
<connection>
<name>example_connection2</name>
<type>SOCKET</type>
<direction>
TWO_WAY_REQUEST_REPLY_ASYNCHRONOUS_SOURCE
</direction>
<maxmessagesize>100</maxmessagesize>
<associatedMessages>
</associatedMessages>
<datatransformrequired>false</datatransformrequired>
<reliability>UNRELIABLE</reliability>
<readwrite_behav>BUFFERING</readwrite_behav>
<domain>INET</domain>
<sockettype>DGRAM</sockettype>
<receiveflag></receiveflag>
<sendflag></sendflag>
<sourceaddress>192.168.1.29</sourceaddress>
<sourceport>24400</sourceport>
<filterspecification></filterspecification>
<threadlist>

</threadlist>
</connection>
</connection_list>
2.5.3 Variability
A PCS or PSS component uses a TS Library to route data to the appropriate endpoints. The TS
Library can use an IPC or a central distributor. Either implementation is acceptable. System
integrators should choose the best approach to meet their requirements.
2.5.3.1 Inter-Partition Communication Data Flow
Figure 20 shows an example data flow from a PCS component to both a PCS and PSS
component through TS Libraries. The approach in Figure 20 allows for TS Libraries to
communicate directly through Inter-Partition Communication.
All data passed through Service are
address spaces
the TS API is conformant address spaces
Portable Component 8
2 Segment
6/7
3/4 PCS 1 PCS 2
4/5
TS API TS API
TS library 1 Transport Services TS library 2
OS API Segment
FACE FACE OS API
Data Data
OS API
Model Model
TS library 3
TS API
PSS 4/5
Component
6/7
Platform-Specific
8
Services Segment
Figure 20: Inter-Partition Communication
The list below describes the sequence of actions performed to send data across the TS Interface.
1. PCS populates the data structure conformant to the FACE Data Model (FACE Technical
Standard, Section 3.6).
2. PCS provides the data structure to TS Library by calling the TS API Send_Message
function (FACE Technical Standard, Section E.3.5).
3. TS Library constructs the TS Message Instance based on the TS Message and Internal
Data Structure (FACE Technical Standard, Section 3.7.5).
4. TS Library executes the Send_Message function using IPC to send the TS Message
Instance.

5. TS Library receives the TS Message Instance for the PCS and PSS components.
6. TS Library deconstructs the TS Message Instance based on the TS Message and Internal
Data Structure (FACE Technical Standard, Section 3.7.5).
7. TS Library handles the callback registered by the PCS and PSS components if required.
8. PCS and PSS components interpret the data structure using the FACE Data Model (FACE
2.5.3.2 Central Distributor Data Flow
Figure 21 shows an example data flow from a PCS component to both a PCS and PSS
component through the TS Central Distributor. The approach in Figure 21 allows for smaller
code footprint to be linked against UoPs, but can introduce latency to communications that may
interfere with correct operation of a system. This method abstracts the transport mechanism
away from the TS Library. It may make sense to package the TS Libraries and TSS Central
Distributor UoPs together to provide complete functionality as shown in Figure 21.
Service address
Different are in different
spaces
address spaces
1
Portable Component
9
Segment
2 8
All data passed 3 PCS PCS 7

through the TS
API is conformant TS API TS API
to the FACE Data TS library Transport Services TS library
Model
OS API
FACE Segment FACE OS API
Data Data
Model OS API Model
TS library
TS API
4 OS API
TSS Central
5 TS library
Distributor
6 TS API
The TS API and library is used PSS 7
here to keep the TSS Central
Distributor transport agnostic Component
8
Platform-Specific
9
Sevices Segment
Figure 21: Central Distributor
The TSS Central Distributor creates, manages, and utilizes all the connections necessary to
perform message distribution. Each TS Library only communicates with the TS Library
associated with the TSS Central Distributor. The list below describes the sequence of actions
performed to send data across the TS Interface:
1. PCS populates the data structure (TSS Message payload) conformant to the FACE Data
Architecture (FACE Technical Standard, Section 3.6).

2. PCS provides the data structure to the TS Library by calling the TS API Send_Message
function (FACE Technical Standard, Section E.8).
3. TS Library constructs a TS Message Instance based on the TS Message and Internal Data
Structure (FACE Technical Standard, Section 3.7.5) and forwards the TS Message
Instance to the TS Library associated with the TSS Central Distributor.
4. TS Library receives and deconstructs the TS Message Instance based on the TS Message
5. TS Library passes the message payload to the TS Central Distributor.
6. TSS Central Distributor routes the TSS Message payload to the correct receiving
components through the TS Library by calling the TS API Send_Message function.
7. TS Library receives and deconstructs the TS Message Instance based on the TS Message
and Internal Data Structure (FACE Technical Standard, Section 3.7.5) and forwards the
TS Message Instance to the TS Libraries associated with the PCS and PSS components.
8. TS Library passes the message payload to the PCS or PSS component using the TS API.
9. PCS and PSS components interpret the data structure using the FACE Data Architecture
(FACE Technical Standard, Section 3.6).
2.5.3.3 Inter-Processor TSS Example
Figure 22 shows an example data flow between two PSS components and a PCS component
through TS Libraries. The approach in Figure 22 allows for TS Libraries to communicate
between processors through socket calls allowed in the FACE OS API. Six different FACE
conformant data models are used in this example to show how data transformation can be on
data sent across the TS Interface. Complete pseudo-code for the example shown in Figure 22 can
be found in Appendix A.

Processor 2
Display
Manager
TS API
TS library
OS API
Processor 1 Processor 3
OS API OS API
TS API TS API
EGI GLX
Manager Server
I/O API
1553
1553 I/O
Service
1553 Driver GPU Driver
EGI MFD
Figure 22: Inter-Processor TSS Data Model Example
2.5.3.4 Message Paradigm Translation Capability
The TSS Message Paradigm Translation Capability is used to convert data messages from one
messaging paradigm to another (e.g., Request/Reply to Publish/Subscribe, Publish/Subscribe to
Request/Reply). An example implementation using a Message Paradigm Translator is shown in
Figure 23. The example includes the following:
 A PCS component communicating through the TS API, designed to use a
Publish/Subscribe message pattern
 A PCS component communicating through the TS API, designed to create a connection
using the Request/Reply message pattern
 A TS Library with a distribution capability designed to use a Message Paradigm
Translator to provide communications between the components communicating over the
confiugred transport mechanisms to adapt Publish/Subscribe message patterns to
Request/Reply message patterns
 The TS Library performs the Distribution Capability function

Differentaddress
Different address spaces
spaces
the TS API conforms to
the FACE Data Model
Portable Component
Segment
PCS 1 PCS 2
TS API TS API
DDS client Transport Services Segment CORBA client
library library
OS API OS API
FACE DDS Message CORBA FACE
Data Paradigm Data
Model client client Model
Translator OS API
CORBA client
library
TS API
PSS
Platform-Specific
Services Segment
Figure 23: Message Paradigm Translation
2.5.3.5 Protocol Paradigm Translation Capability
The TSS Protocol Paradigm Translation Capability is used to convert data messages from one
protocol paradigm to another (e.g., CORBA to DDS, DDS to CORBA). An example
implementation using a Paradigm Translator is shown in Figure 24. The example includes the
following:
 A PCS component communicating through the TS API, designed to use a DDS messaging
paradigm and protocol
 A PCS component communicating through the TS API, designed to use a CORBA
messaging paradigm and protocol
 A PSSS component communicating through the TS API, designed to use a CORBA
messaging paradigm and protocol
 A TS Library with a distribution capability designed to use a Paradigm Translator to
provide communications between the components using the DDS and CORBA messaging
paradigms and protocols
 DDS/CORBA Client library performs the Distribution Capability function

address spaces
Portable Component
PCS 1 Segment PCS 2
TS API TS API
Transport Services TS Library (UDP)

TS Library (TCP)
Segment
Protocol Paradigm
Distribution Capability Translator Distribution Capability
TCP OS OS UDP
Library API Distribution Capability API Library
FACE FACE
OS TCP UDP OS
Data Data
API Library Library API
Model Model
Platform-Specific
Services Segment
Figure 24: Protocol Paradigm Translation
2.5.3.6 TSS Protocol Translation
The TSS Protocol Translation function is an optional capability provided when more than one
transport protocol is used within the scope of a system. It provides the ability to connect
instances of the TS Library using different transport protocols. The TSS components are the only
components using data transport methods to exchange data between PCS and PSSS components.
The TSS Protocol Translation may be implemented using a centralized or distributed approach.
Figure 25 shows an example of a centralized implementation where a centralized Protocol
Translation component acts as a bridge between PCS 1 and PCS 2 TS Libraries each using
different transport protocols to exchange data. Figure 26 shows an example of a distributed
implementation between PCS 1, PCS 2, and PCS 3 TS Libraries where PCS 3 exchanges data
to/from both PCS 1 and PCS 2. The implementation of the TSS Protocol Translation shows
mediation of different protocols rather than a translation between protocols. The internal
interface to a protocol module may be standardized to enable portability.

Different Different
addressaddress
Different addressspaces
spaces spaces
Portable Component
Segment
PCS 1 PCS 2
TS API TS API
Transport Services
Segment
TS Library TS Library TS Library
Protocol Translation
FACE FACE Distribution

Distribution OS
UDP OS Data OS UDP
TCP TCP Data OS TCP
Capability
Capability API
API Model API Model API
Platform-Specific
Services Segment
Figure 25: TSS Protocol Translation (Centralized)

address spaces
Portable Component
Segment
PCS 1 PCS 3 PCS 2

TS API TS API TS API
Transport Services
Segment
Distribution
Capability
Protocol Translation
FACE FACE
Distribution OS Distribution
UDP OS Data OS UDP
TCP TCP Data OS TCP
Capability API Capability
API Model API Model API
TS Library TS Library TS Library
Platform-Specific
Services Segment
Figure 26: TSS Protocol Translation (Distributed)
2.5.3.7 TSS Message Paradigm Translation
The TSS Message Paradigm Translation function is an optional capability provided to connect
PCS and/or PSSS components using different messaging paradigms. Messaging paradigms are
the architectural patterns describing how message-passing software components interact. Each
messaging paradigm requires each side of the communication exchange to agree to and fulfill a
contract to establish communication. Software components sharing the same data, the same

transport protocols, but using different messaging paradigms are unable to communicate. Since
the TSS Message Paradigm Translation is an internal TSS component, it does not traverse the
TSS boundaries.
The TSS Message Paradigm Translation is responsible for matching the messaging patterns
between software components. The TSS Message Paradigm Translation may be implemented
using a centralized or distributed approach. Figure 27 is a depiction of a centralized message
paradigm translator, while Figure 28 shows a distributed implementation. In Figure 27, the
centralized Message Paradigm Translation component acts as a bridge between PCS 1 and PCS
2 TS Libraries, each of which uses different message paradigms when exchanging data. In
Figure 28, the PCS 1 TS Library provides a sevice to PCS 1 to translate its client-server message
paradigm to the Publish/Subscribe paradigms used by PCS 2 and PCS 3. Message paradigm
translation may require the storage of state information contained within the messages in
addition to the state information of the message. Message paradigm translation may place
additional computational and memory resource demands. These requirements may impact the
choice to use translation, and where to obtain and manage the required resources to avoid
negatively impacting system performance.
address spaces
Portable Component
PCS 1 Segment
PCS 2
(Request / Response) (Publish / Subscribe)
TS API TS API
Transport Sevices
Distribution Distribution
Capability
Segment Capability
TS Message
Paradigm Translation
Service
OS FACE OS FACE
Client API Data Server Sub OS OS
API Data Pub
Model API API
Model
Request
Message Paradigm
Response Translation
TS Library TS Library
Platform-Specific
Services Segment
Figure 27: TSS Message Paradigm Translation (Centralized)

address spaces
Portable Component
Segment
PCS 1 PCS 3 PCS 2
(Request / Response) (Publication) (Subscription)
TS API TS API TS API
Transport Services
Distribution Message Distribution
Capability Paradigm
Segment Capability
Translation
Client
TS Library
Distribution
Capability FACE
Server OS Data OS
Pub Sub
API Model API
FACE
OS OS
Sub Data
API API
Model
Platform-Specific
Services Segment
Figure 28: TSS Message Paradigm Translation (Distributed)
2.5.3.8 TSS Buffering Methodology
The TSS Buffering Methodology can be supported as a design choice when sockets are used as
an underlying transport. The Initialize(TS) function is used to establish the TS Library in a
known, determinant state and configure the Distribution Capability based on the configuration.
The configuration file supports the TSS Buffering Methodology by assigning priorities, rates,
scheduling polices, and number of threads used. The TSS Buffering Methodology approach is
shown in Figure 29.
Optimized Process High Priority

Read Using Data Periodic Re-open
Select Thread Sockets
Low Priority
Initialize Process
Periodic
Connections
Queue(s) Thread
Queue(s)
Queue
Transport
Config File Callback
Thread-based Services
Initialze() Or Read Distribution Capability Segment
TS API
Platform-Specific
PSS Services Segment
Figure 29: TSS Buffering

The use of these configuration file inputs allows the integrator to assign a high priority to the
threads processing requiring high rate or critical data, and low priority to the threads processing
low rate or non-critical data. The configuration file defines the system connections. Callbacks
can be used to retrieve data as soon as a new piece of data is stored in the corresponding buffer.
If a callback is registered for a connection, then a corresponding read call on the connection will
return an error.
Some benefits of this approach are:

 Limits the amount of logical connections necessary within an implementation by using
one logical connection to retrieve data from multiple sources and store in buffers
corresponding to the connection_id returned by the Create_Connection() call
 Provides a means to control timing, rates, and priority of I/O
 Sets the thread priority appropriately to eliminate thread starvation
 Creates an optimized TSS implementation
This approach can be used when writing data to connections and allows for maximum flexibility
and for multiple design options (synchronous and asynchronous communications) across
Department of Defense (DoD) Aviation platforms.
2.5.3.9 Resource Allocation
The resource requirement of the Distribution Capability is dependent upon the needs of the
components and system integrator. Each TS Library should have resources allocated to support
the data required by the component. At a minimum, memory is required to store underlying
transport mechanism identifiers and other connection-specific information to allow for
distribution of data.
2.5.4 TS Interface and Type Safety

Any FACE UoC utilizing the FACE TS Interface must adhere to the FACE Data Model. The
requirements in the FACE Technical Standard, Sections 3.6.2, 3.8.3, and 3.9.6 ensure all data
exchanged using the TS Interface meets the FACE Data Model requirements. To promote
portability, reusable product-line components, and reduce recertification efforts it is
recommended that TSS Type Abstraction components be used. PCS and PSSS UoCs are
required to adhere to the FACE Data Model across the TS Interface. TSS Type Abstraction
components adhere to the FACE Data Model in communication with the PCS and PSSS
components, but communicate with a TSS UoC through a non-typed interface (e.g., void *).
Although the interface is untyped, the message’s types are available at run-time through
configuration information such as the Message GUID rather than using language constructs for
compile-time data typing. This will allow for rigorous conformance testing at the UoC level
while providing for reusable TSS implementations that may not require FACE reverification or
recertification. A diagram of this architecture is shown in Figure 30.

PCS A PSSS B PCS C PSSS D
TS Interface
FACE
FACEConformance
Certification
executed
Certification
individually
executedon TSS Type TSS Type
each
individually
component
on each
(PCS, Abstraction Abstraction
component
PSSS, TSS
(PCS,
TypePSSS,
TSS
Abstraction,
Type Abstraction,
and TSS TS Type Abstraction Interface
and UoC).
TSS UoP).
TSS UoP TSS UoP
TSS UoP TSS UoP
Figure 30: FACE TSS Architecture
The following two scenarios provide a TSS Type Abstraction implementation: the PCS/PSSS
software supplier or the system integrator (acting in the role of a software supplier).
If a PCS/PSS software supplier provides a TSS Type Abstraction implementation:

1. The PCS/PSSS UoC would be provided as object code.
— It would be verified to use the TS Typed Interface.
— It would be verified to meet the other FACE requirements.
2. The TSS Type Abstraction would be provided as object code.
— It would be verified to provide the TS Typed Interface as per the FACE Data Model.
— It would be verified to only utilize the TS Untyped Interface and the FACE OSS
APIs for its profiles. (The test suite could perform this validation.)
3. The TSS Type Abstraction would be provided as a library to allow a software supplier or
system integrator flexibility in choosing their TSS implementation.
If a software supplier provides a TSS Type Abstraction implementation:

1. The TSS Type Abstraction would be provided as object code.
— It would be verified to provide the TS Typed Interface as per the FACE Data Model.
— It would be verified to only utilize the TS Untyped Interface and the FACE OSS
APIs for its profiles. (The test suite could perform this validation.)
Figure 30 identifies multiple scenarios to address portability and interoperability of TSS UoCs
across platforms.

The first and second scenarios show a PCS/PSS UoC delivered by the software supplier that did
not choose to implement the TSS Type Abstraction UoC. An alternate software supplier or a
system integrator acting as a software supplier may need to implement a TSS Type Abstraction
UoC for the PCS A and PSS B data model to support the portability of a TSS UoC. The
PCS/PSS UoC, TSS Type Abstraction UoC, and TSS UoC must go through FACE Conformance
Verification individually.
The third and fourth scenarios show the case where the PCS/PSSS UoC software supplier chose
to provide the TSS Type Abstraction UoC. Since it is provided as a library, the system integrator
(acting as a software supplier) could choose to use their own implementation or even link the
PCS/PSSS UoC with a TSS UoC that provides the TS Typed Interface (for the given data
model). The PCS/PSS UoC, TSS Type Abstraction UoC, and TSS UoC must go through FACE
Conformance Verification individually.
The fifth and sixth scenarios show a PCS/PSS UoC using a TSS implementation providing the
TS Typed Interface. This TSS UoC may not be reusable across different systems depending on
TSS UoC implementation, and may need to undergo FACE Conformance Verification when
reused.
2.6 Portable Components Segment

The Portable Components Segment (PCS) is not a deliverable container for software. Rather, it
is a logical container for FACE UoPs whose contents are entirely independent from other FACE
segments. A FACE component contains the business logic decoupled from a specific
implementation as shown in Figure 31. The FACE component has to use the TS Interface for all
communication. Any data sent over the TS Interface should be packaged using the FACE Data
Model.
Business Logic
Concerns
(all couplings to
specific h/w & s/w
Portable Component have been separated)
Segment
Portable
Component
TS API All data passed through
Transport Services TS library to the FACE Data Model
Segment
OS API
Figure 31: Portable Components

Software components are considered to be part of the PCS when they share the following
properties:
 Provides mission-level capabilities or common services
 Includes a capability which could execute on multiple varying instantiations of FACE
environments
 Interfaces exclusively to the remainder of the FACE environment through the TS Interface
for data exchanges
 Exclusively uses the FACE specified OS, run-time, or framework APIs for OS support
 Does not use the I/O Interface
 Uses graphics services directly if required; see Chapter 7 for more details on graphics
services
FACE PCS components provide the desired platform-level capabilities when executing. PCS
components are reusable software designed to allow a user to complete specific tasks.
PCS components can use configuration information to initialize parameters, or to enable/disable
certain capabilities. Configuration of PCS components is done during initialization and run-time
using either Local or Centralized Configuration Services in the PSSS. PCS components
communicate with the Centralized Configuration Services using the TS Interface. See Section 8
for more information on Centralized Configuration Services. Configuration at build or
compilation time is possible but requires re-compiling the executable containing the PCS
component.
Refer to the FACE Technical Standard, Section 3.15 for a complete set of requirements on
Configuration Services.
2.6.3 Variability
The variability of FACE components is in the developer’s design decision when developing and
packaging UoPs. FACE components should be designed and packaged to maximize reuse and
portability.
3 Functional Decomposition into UoPs
3.1 Introduction
The FACE UoP describes a set of software which provides one or more services or mission-level
capabilities required for complete and correct execution of that capability (e.g., programming
language run-times and application frameworks). Services and/or capabilities can be bundled
together into a UoP to provide a specific mission-level capability or service to a system.
UoPs are determined by the software suppliers. Multiple UoP requirements from the FACE
Technical Standard are key to helping the developer understand how to breakdown software into
UoPs:
 A UoP must reside within a single FACE segment
 A UoP must reside within a single partition
 All external interfaces of a UoP must be FACE conformant
For a complete list of UoP requirements, refer to the FACE Technical Standard, Section 3.10.2.
The following items should be considered when determining the breakdown of software into
UoPs:
 Logical functions may be combined to provide a UoP for a specific mission-level
capability or services
 External interface information must be available and provided
 UoPs should be designed for system reuse and portability
 Data rights
 Required timing characteristics between UoPs
Balance should be considered when breaking down software into UoPs to satisfy system,
portability, and timing requirements.
If a Language Run-time or Framework is contained in the UoP, then the Language Run-time or
Framework may be implemented logically across multiple UoPs within a single partition. If the
UoP is moved to another partition, computing platform, or aircraft platform, then the Language
Run-time or Framework migrates with the UoP. For more information about Language Run-time
and Frameworks see Chapter 9.

3.2 Portable Components Segment UoPs
Three UoP design examples with increasing levels of portability are shown below. The three
design examples take the software developer through the thought process of how a monolithic
UoP could be broken down into more reusable and portable UoPs providing value to the
software developer and customers. Software developers will need to decide the right level of
breakdown that provides maximum portability, while minimizing coupling, maximizing
cohesion, and considering UoP conformance/management issues.
Figure 32 shows a system-level monolithic UoP design example made up of Communication,

Navigation, and Sensor Management functions captured in one UoP. This example may only fit
a specific mission implementation of the UoP in a specific platform.
FACE UoP
FACE OS Native
Component
OFP (Comm, Nav,

Sensors)
Figure 32: System-Level Monolithic UoP
Figure 33 shows a functional breakdown into three sub-system-level UoPs: Communication,

Navigation, and Sensor Management. This example is more flexible than the example shown in
Figure 32; however, it still may only fit a specific mission implementation of the
Communication UoP, Navigation UoP, or Sensor Management UoP in a specific platform. The
portability of the UoPs in this example would be applicable to another platform only in the
instance when the Communications Suite, Navigation Suite, or Sensor Suite is identical to the
initial platform.
FACE UoP FACE UoP FACE UoP

FACE OS Native FACE OS Native FACE OS Native
Component Component Component
Comm Nav Sensors
Figure 33: Sub-System-Level UoP
Figure 34 uses the three UoPs identified in Figure 33 and decomposes them into mission-level or
service UoPs under the Communication, Navigation, and Sensor Management categories. Each
category is shown separately with multiple mission-level UoPs inside. The UoPs in this example
could be instantiated into other platforms when that platform requires one or more of the
portable mission-level capabilities or services identified.
COMM
FACE UoP FACE UoP FACE UoP FACE UoP
FACE OS Native
Component FACE OS Native FACE OS Native FACE OS Native
UHF
VHF
DataLink VMF
SATCOM HF
NAV
FACE OS Native FACE OS Native
Component Component
FACE OS Native FACE OS Native
Component Component
DAFIF
SAR Patterns
Civil FMS Digital Map
Tactical Patterns Jeppesen
Sensors
FACE UoP FACE UoP FACE UoP FACE UoP FACE UoP
FACE OS Native
Component
FACE OS Native FACE OS Native FACE OS Native FACE OS Native
FLIR
Component Component Component Component
RADAR RWR Laser Sensor Optical Sensor

Laser Designator
Figure 34: Mission-Level UoP
3.3 Transport Services Segment UoPs

Figure 35 shows examples of possible UoPs in the TSS able to be combined as needed to
perform the transport capabilities required by an implementation. Figure 35 examples show:
 TS Library providing the Distribution Capability handled by Sampling or Queuing Ports
(IPC)
 TS Library providing the Distribution Capability handled by sockets (IPC) with a Data
Conversion Capability
 UoP providing the Central Distributor (Transport Mechanism) that needs to couple with a
TS Library providing the Distribution Capability
 UoP providing the Paradigm Translation Capability that needs to couple Transport
Mechanisms

Central Distributor
Sampling/ Socket calls with Paradigm Translator
designed for DDS
Queuing Ports Data Conversion for DDS and CORBA
or CORBA

FACE OS Native FACE OS Native FACE OS Native FACE OS Native
Configuration Configuration Configuration
Routing
Configuration Conversion Paradigm
Translator
DDS
(DDS to
Routing Routing or
CORBA)
CORBA
Figure 35: TSS UoPs
3.4 Platform-Specific Services Segment UoPs

Figure 36 shows examples of how the Platform-Specific Services Segment (PSSS) components
can be broken down into UoPs. The most portable way to break up your components is to divide
them into UoPs which correspond to a hardware device. Figure 36 can be used in conjunction
with Figure 32, Figure 33, or standalone.
FACE UoP FACE UoP FACE UoP FACE UoP FACE UoP
Non-standard Non-standard Non-standard FACE OS Native FACE OS Native
Framework-based Framework-based Framework-based Component Component
or
Legacy OFP
EGI RadAlt
(Includes all ICDs)
Non-standard Non-standard Non-standard Platform-specific

ARC-210
Application Application Application Common Service
Framework Framework Framework
Figure 36: PSSS UoPs
3.5 UoP Packaging

FACE UoPs exist entirely in a single segment and single partition. With that being said, UoPs
can be packaged together to create a single software logical entity crossing segment boundaries.
A software logical entity can be binary executable, object code, or source code. See Figure 37
for a pictorial version of valid UoP packaging.
Valid UoP packages can be made of:

 UoPs residing within the PCS and TSS
 UoPs residing within the PSS and TSS
 UoPs residing within the PSS and components of the IOS
 UoPs residing within the PSS and TSS and components of the IOS
UoPs of the PCS and PSS are not allowed to reside in the same UoP package.
Valid UoP Packages
Portable
Valid Valid
Components
Segment UoP UoP
TS
Transport Valid
Valid Valid Valid
Services
Segment UoP UoP UoP UoP
TS TS
OS
Platform-Specific
Valid Valid Valid Valid
Services
Segment UoP UoP UoP UoP
IO IO
Input/Output
Services Service Service Service
Segment
OS
OS
Figure 37: Valid UoP Packages
Another important point is that conformance testing is performed on the UoP external interfaces.
Even if multiple UoPs are packaged together, conformance testing is still performed on each
UoP and not on the UoP package as a whole. UoP packaging is a business decision on how to
sell the software.
Valid UoPs may be packaged together as a Valid UoP Packages; however, this packaging does
not ensure that the Valid UoPs complete their designated function well together. UoP Packages
must be implemented intelligently to achieve the desired function.
3.6 Data Rights

More information about data rights can be found in the FACE Contract Guide.

4 FACE Profile Guidance
4.1 Introduction
The FACE architecture supports any combination of general-purpose, safety-critical, or secure
avionics capabilities through the use of profiles. Profiles affect the interfaces and functionalities
available within a FACE implementation. This section guides you through the strategies of
profile selection for a given development or migration. This section will provide insight for:
 Migration of a FACE component designed for one profile to another profile
 Migration of a non-FACE legacy component to conform to a FACE Profile
 Conversion from non-timed-based to timed-based partitioning
4.2 Strategy
It is recommended that a profile selection strategy align with the profile needs of a given
product’s short and long-term roadmaps. Component developers should select their profile based
on an understanding of the value of portability between profiles; not doing so may cause
difficulty in migrating between profiles in the future. Using APIs associated with more
restrictive FACE Profiles facilitates ease of migrating to less restrictive FACE Profiles.
Common Criteria/NSA High Robustness, Safety & Security Assurance

Security Profile:
 Uses FACE Security Interfaces
 Time/Space Partitioning Required
,
Sec ety
u Saf rity &
Pro rity c u m
file S r mi n i s
e
te “Real-Time”/Highly Deterministic Safety Assurance
De Safety Profile:
 Uses FACE Safety Interfaces
Saf &  Time/Space Partitioning Recommended
Pro ety ety
file Saf minism
ter
De No/Low Assurance Requirements
General Purpose Profile:
 Uses FACE General-Purpose
I
Ge AP Interfaces
ne ra l - l e O/S  Time/Space Partitioning Optional
b to s
orta ess face
Pur
p o se A p & acc Inter
Pro l ”
fi nta
r i zo
le
“H o
Profile Pyramid 6June12
Figure 38: FACE Profile Diagram
An example would be using the Safety Profile APIs to meet requirements of a General-Purpose
Profile component to gain value in portability for a product planned to be used in the Safety
Profile for the future based on its product roadmap.
4.3 Migration Between FACE Profiles

Component developers should clearly indicate which FACE Profile(s) the component is
designed to apply to, as well as key characteristics. At a minimum, this should include safety-
related information relative to the development assurance-level categories contained in safety-
related documents such as Radio Technical Commission for Aeronautics (RTCA) DO-178B/C,
RTCA DO-254, and ARP 4754A, as well as security-related information relative to security
assurance levels contained in documents such as ISO/IEC 15408:2009.
FACE Profiles are defined as a set of permissible APIs. More restrictive FACE Profiles are
subsets of less restrictive FACE Profiles. ARINC 653 is optional in the General-Purpose Profile.
ARINC 653 and POSIX are required in the Safety and Security profiles. A component is
portable from a more restrictive to a less restrictive profile, with the exception of moving from
ARINC 653 to a POSIX-only General-Purpose OS, because support for ARINC 653 APIs is
optional in the General-Purpose Profile.
Other key characteristics are helpful to include for purposes of migrating between FACE
Profiles. For software, this may include things such as program memory needed, dynamic
memory used, execution time on a given platform, etc. These characteristics may be further
broken down to include various usage cases.
4.4 Adaptation of Legacy Operational Flight Programs to FACE

Profiles
The following steps walk through the thought process of integrating a legacy Operational Flight
Programs (OFP) to satisfy FACE requirements for the different FACE Profiles (General-
Purpose, Safety, and Security). This section does not address the development of a USM for the
capability or the conversion into a UoP.

Flight Control Flight Control
Flight Controls
Surface System
Existing OFP
Human
Platform Device
Machine
& Networks
Interface
Capability 1 Capability 2
FACE
Infrastructure
Gray Box = Optional Blue Arrows = FACE
Component Interfaces
Blue Boxes = Avionics Capability 3 Capability ... Black Arrows = Existing
Components Interfaces
FACE Software Library
OFP = Operational Flight Program
Figure 39: Adaptation of Legacy OFPs to the FACE Architecture
1. Determine UoP granularity for the legacy system:

— Do you split the legacy system into multiple FACE functional components and
UoPs?
— Is the software still supportable? Can the software be adapted to the FACE
architecture?
— Should the software be rewritten using a FACE supported language?
2. Characterize and assess the legacy capability:
— Was the capability designed for GP, Safety, or Security?
— What other capabilities does this interface to?
— What types of interfaces and what standards were used for those interfaces?
3. Assess how capability fits into the FACE architecture:
— Have UoP(s) boundaries been defined for the capability?
— To what segment(s) do the UoP(s) belong?
— Is a more restrictive profile applicable for future use of this capability?
4. Determine how to integrate the capability into the architecture:
— Should the legacy architecture be converted to align to the FACE Reference
Architecture?
— Should the legacy architecture interface to a new FACE capability hosted within the
existing architecture?
— Should the legacy architecture interface to a new FACE capability hosted within an
architecture aligned to the FACE Reference Architecture?

5 Data Architecture Guidance
Implementation guidance for the FACE Data Architecture provides content to aid in
understanding the overall approach the FACE Consortium has taken with respect to data
management within the FACE Technical Standard. This document additionally provides insight
and guidance on how to apply the Data Architecture and data modeling techniques in the
development of a FACE UoP or a FACE component. The chapter begins by describing the
reasons for data modeling and describes the approaches that were considered and what drove the
FACE Technical Standard to the current implementation process. The chapter then defines high-
level modeling paradigms and concepts and the recommended modeling process before
presenting several data modeling examples. The chapter concludes with a list of common
questions, rationale for the chosen approach taken, and specific decisions that were made.
 Why Data Modeling?
 Overview of Modeling Concepts
 Recommended Process
 Data Modeling Example
 Considerations for Conformance
 Rationale/Common Questions
Figure 40 pictorially defines the different terminology used in the Data Architecture chapter of
this document.
Conceptual Data Logical Data Model Platform Data Model

Model (CDM) (LDM) (PDM)
Code and
Configuration
Unit of Portability
Model (UM)
(IDL, XML, Ada, C++, C,
Java)
Conceptual
Logical Views Platform Views
Views
Figure 40: Data Architecture Terms
5.1 Why Data Modeling?

Within the FACE Reference Architecture, data models are employed to provide a standard
method for data sharing between software components. Data modeling is required to enable
information sharing/interoperability between entities (e.g., FACE UoPs). A Shared Data Model
(SDM) enhances reuse by establishing a standard communication method among software
components. The FACE Data Architecture is not a traditional message-based data model, but
instead it defines the foundation necessary for capturing semantic and syntactic data modeling
information.
The FACE Technical Standard defines a data modeling language via a Meta Object Facility
(MOF) metamodel. The FACE architecture data modeling language allows a consistent approach
for capturing data model content. The semantic and syntactic information captured as data model
content is more appropriately referred to as the semantic model. The semantic model includes
the Conceptual, Logical, and portions of the Platform Models. The message model is captured
through the remainder of the Platform Models and the UoP Supplied Model (USM).
Even though Unified Modeling Language (UML) is often employed in examples, the data model
is not a UML model. The FACE Data Architecture requires a greater degree of specificity then
UML can provide. Therefore, a new MOF metamodel was created for modeling FACE UoP
interfaces. The metamodel includes the capability to represent USMs and the SDM. The FACE
metamodel approach is to define data from two perspectives: a semantic perspective and a
measurement perspective. The Conceptual Model provides a semantic description of the
message fields in a FACE Transport Services (TS) message. The Logical Model adds the
measurement description to each message field by defining type, units, measurement, and frame
of reference (through the measurement system). By providing for unambiguous semantic and
measurement system descriptions of message fields, UoP developers can specify messages with
sufficient specificity to increase interoperability of UoPs.
Another potential benefit of the FACE Data Architecture is reduced development/integration

time through reuse of the data model elements. An SDM has been established as a mechanism
for sharing data model elements. Several aspects of the design of the FACE Data Architecture
were chosen to accommodate sharing and reuse of data model elements. This includes the
division of the data model into conceptual, logical, and platform models and the design of the
metamodel elements.
By separating the semantic data model from the message model, existing components can
achieve FACE conformance with minimal change. Existing message model fields simply have to
be mapped to the semantic data model elements. This approach contrasts with more traditional
class-based designs that often require a specific class structure to be utilized for messages and
therefore would require a complete rewrite of the existing software component to support
interoperability.
In summary, the FACE Data Architecture facilitates the identification of horizontal interface
mismatches often found during development/integration of a system composed of software from
multiple suppliers. The data modeling language also enables existing components to be made
conformant to the FACE Data Architecture with minimal modification to message interfaces by
modeling the semantics captured in the existing message model. Lastly, the FACE Data
Architecture is a key component of the FACE Technical Standard and is essential to designing
systems and developing interoperable UoPs.

5.2 Overview of Modeling Concepts
The FACE Data Architecture is divided into: Conceptual, Logical, and Platform data models.
This allows for the development of ideas first then elaboration of those ideas with additional
detail over time. This division also aligns with both Model-Driven Architecture (MDA)
conventions and the Department of Defense Architecture Framework (DoDAF) metamodel.
Most importantly, this separation supports key interoperability requirements of the FACE
Technical Standard while enabling efficient transformation of existing components into FACE
UoPs. It does this through the separation of the specific information that is captured within each
USM and the relationships between them.
The Conceptual Model captures basis concepts, composition of those concepts into entities as
attributes and the associations between those entities. It also allows definition of conceptual
messages based on those entities and attributes.
The Logical Model provides a mechanism to extend each conceptual element with information
that supports particular logical processing requirements: units, measurement and coordinate
systems, value domains (e.g., Real, Natural Number), constraints, and measurement precision.
Each conceptual element can have many representations at the logical level based on the
selection of each of these additional elements of information. Also, conversion relationships
between logical elements may be specified in the Logical Data Model (LDM). This provides a
mechanism for sharing data between components that have different algorithms and therefore
different data representations. For example, the same conceptual element of altitude could be
represented as an integer number of meters above ground level and as a real number of feet
above mean sea level. The fact that these two representations are linked to the same concept
informs users that direct conversions between them are realizable. The existence of conversions
between the units, measurement and coordinate systems, value domains (e.g., Real, Natural
Number), constraints, and measurement precision define the method of performing those
conversions.
The Platform (Physical) Model takes the Logical Model a step further by allowing each logical
element to be extended to the specifics of the computing platform. The Platform Model
defines/determines the specific data type such as float or double used to represent the value type
allowing the logical type to be represented on computers with various physical architectures and
software compiled with various compiler settings and options. This capability allows
conversions between data elements represented on different computing platforms.
The FACE Data Architecture encompasses both a message model and a semantic data model to
which all data elements from each message are related. The FACE SDM is managed by the
FACE Consortium and supports interoperability between USMs that are developed by separate
software suppliers. Entities are the data elements that tie message elements to a common
meaning. Without the entities, each message stands alone with no ability to determine whether
elements in two messages having the same data types (e.g., float, double) actually share the same
meaning. This connection back to a common set of entities supports data conversion between
message sets which is critical to interoperability. Interoperability is a key requirement to support
portability and reusability due to component data dependencies.
Another paradigm expressed by the FACE Data Architecture is that of a view. A view is created
to assemble specific characteristics of one or more entities, and to preserve the context of each
characteristic. The primary utility of views is to assemble information that is necessary and
useful for a particular purpose without imposing unique specifications and requirements of that
purpose throughout the entire system, or on other systems. An example of a special purpose that
benefits from the ability to create views is message transmission over a Disadvantaged,
Intermittent, Limited (DIL) communication link. Characteristics of the DIL link place
requirements on a message that are not necessarily present on the same message when it is
transmitted within the airframe. Views allow different assemblies of characteristics to be created
while maintaining the original context, and documenting unambiguous links between the same
characteristic in different views.
Views created at the conceptual, logical, or platform level of the model have the same level of
abstraction as other data model elements. They can also have relationships from a view in the
conceptual model to one or more views in the logical data model; that is, a view in the logical
model can realize a view in the conceptual model. Similarly, a view in the logical model may
have a relationship to one or more views in the platform model; similarly, platform views may
realize logical views. It is also acceptable to have logical views that are not realizations of
conceptual views. Because it is possible to have both conditions, it is necessary to decide when a
logical view is independent, and when it is a realization of a conceptual view.
Views in the conceptual model are collections of characteristics. They specify a template of a
view that is to be realized by several corresponding logical views. It is desirable to create a
conceptual view when there are several logical views that have identical conceptual content, but
different representations of the concepts. The ability to indicate that each of the different logical
views realizes the same conceptual view clarifies the role that each logical view plays within the
system and reduces the effort needed to map between the different logical views. It is also useful
to create conceptual views to represent the conceptual interfaces of components or services. If
consumers and producers of data are modeled at the conceptual level – that is, there is a
specification of an interface – that interface is represented as a conceptual view.
It is necessary to create a logical view when a conceptual view is realized. It is also necessary to
create a logical view when there is no conceptual view, but it is necessary to assemble
characteristics from several logical entities. The most common use of such a view is as an input
or output message of a UoP.
The FACE Data Architecture describes mechanisms for defining basis elements in the
conceptual and logical models as well as mechanisms for extending those basis elements. UoPs
may extend those elements using these mechanisms and still maintain conformance to the FACE
Technical Standard and the FACE Data Architecture. There is a process in place to expand the
content captured in the SDM. The SDM is architected to enable and promote reuse and
expansion. The intent is that the SDM will evolve as elements are added. The FACE Shared
Data Model Governance Plan details the basis elements, extension elements, Object Constraint
Language (OCL) constraints, SDM conformance requirements and the process for maintaining
and updating the SDM. The process for incorporating extensions to the SDM based on user
needs are provided in the FACE Shared Data Model Governance Plan.
The SDM includes the basis elements which are managed by the FACE Shared Data Model
Configuration Control Board (CCB) as described in the FACE Shared Data Model Governance
Plan.

5.3 Data Modeling Examples
These examples are based on the SDM (FACE 2.1 SDM v2.1.30). See the FACE Shared Data
Model Governance Plan for details regarding SDM governance and conformance. The example
model in FACE XML Metadata Interchange (XMI) format is included in Appendix H: Example
USM FACE XMI.
5.3.1 Overview of Example

The presented example of the Navigation Management component and associated data model is
represented by a simplified view of functionality that is typically required on an aviation
platform with sensing and tactical management capabilities. It is not intended to be a complete
solution, but rather one that supports demonstration of common data modeling tasks and that
answers many of the common data modeling questions.
Specific modeling topics covered by the examples include:

 Definition of basic conceptual, logical, and platform model elements
 Definition of a UoP and associated message ports
 Handling of multiple instances of identical or similar components
 Creation of views of entities and compositions
 Independently constructed components
Figure 41 provides a graphical view of the PSSS and PCS components and interfaces to be
modeled. The following paragraphs provide a more detailed description of the components and
their functionality. Only the modeling of the Navigation Management portion of this system will
be discussed in detail.
Sensor Moding/Control
Aircraft Situation (position, attitude, etc.)
Radar
- Sensor
Detections
- System
Status/Health
Radar Interface Tactical Situation

Component Sensor Detections Manager
Aircraft Situation List of a variety of

tactical points
from multiple
NAV Data sensor types
Aircraft Situation
Navigation (position, attitude, etc.)
Management Tactical Display
Nav Sensor Nav Sensor Nav Sensor

1 Mgr 2 Mgr 3 Mgr
Legend
= PSSS Component
EGI 1 EGI 2 IMU
= PCS Component
= TS Interface
= IO Interface
Figure 41: Basis for Data Model Example
5.3.1.1 Navigation Management Component
The Navigation Management Component is responsible for gathering navigation data from
multiple sources and computing a single consolidated navigation solution. This function is
common on systems employing multiple navigation devices required to address safety and high
reliability concerns. This example is not specific on exact logic used to prepare the single
consolidated solution, but one should assume that it is a combination of communication status,
data validation, and source prioritization or averaging.
5.3.1.2 Navigation Sensor Manager Components
Navigation Sensor Manager components are PSS components that communicate with their
associated navigation device using I/O Services. The example portrays two types of navigation
devices, with two instances of one type installed to provide a redundant solution. Both types of
sensor managers use the TS Interface for communication with other FACE components.
5.3.1.3 Radar Interface Component
The Radar Interface Component is a PSS component that uses I/O Services to communicate with
a specific radar over a standard data bus such as MIL-STD-1553 Multiplex (MUX). This

facilitates integrating the radar into other FACE environments. It also facilitates reuse of the
UoCs interacting with the Radar Interface Component.
5.3.1.4 Tactical Situation Manager Component
The Tactical Situation Manager Component stores tactical information from one or more sources
and reports a consolidated tactical picture for use by other system components. The types of
tactical entities and types of data sources providing data to the Tactical Situation Manager are
flexible. While our example illustrates radar, practical systems may also include sonar,
electronic surveillance, data links, etc. Consequently, data reported by this component could be a
heterogeneous mix of tactical objects, with many common attributes and also a subset of type-
specific ones.
The Tactical Situation Manager is a PCS component. Its communication with other entities is
restricted to the TS Interface, and its function is one that has applicability to multiple tactical
systems.
5.3.1.5 Tactical Display Component
The Tactical Display Component is a PSS component responsible for presenting a mission
appropriate view of the tactical situation to the crew member display. It accepts a heterogeneous
mix of tactical data entities via the TS Interface and displays those using Graphics Services.
5.3.2 Model Organization

Organization of the SDM and USMs is important to enable rapid location of model elements.
The ability to rapidly locate existing model elements promotes follow-on modeling consistency
and reuse.
5.3.2.1 UoP Supplied Model
 Conceptual Model
— Individual Entities and Associations
— Conceptual Data Model containing Observables
— Conceptual Data Model containing Views
 Logical Model
— LDM containing Measurements
— LDM containing Units
— LDM containing Views
 Platform Model
— Platform Data Model containing Physical Data Types
— Platform Data Model containing Views
 UoP Supplied Model
— Individual UoPs, including their Message Ports
5.3.3 Overview of Key Data Modeling Tasks

This section describes the essential modeling tasks. It assumes that the software developer
already has a notion of the data to be exchanged and therefore focuses on modeling aspects and
not on functional requirements.
 Create/reuse existing message conceptual views.
 Create/identify existing logical model entities (built from measurements).
 Create/reuse existing message logical views.
 Create/identify existing platform model entities (built from physical data types).
 Create/reuse existing message platform views.
 Create component characterization (ports, programming language, partition type, FACE
edition).
 Associate platform views (messages) with component ports.
 Iterate using automated tools to validate model while being developed.
 Utilize automated tools to generate platform code, XMI data needed for component
conformance, etc.
 Utilization of various tool chains/approaches.
 Tip – Use labels on diagrams to communicate the model type the diagram resides within.
 Model organization tips – some examples of how to organize separate data packages are
by :
— Entities and Associations (organized by type; Conceptual, Logical, and Platform)
— Observables (Conceptual)
— Measurements (Logical)
— Measurement Systems (Logical)
— Units and ValueTypeUnits (Logical)
— Landmarks used by multiple Measurement Systems (Logical)
— Measurements (Platform)
— Corresponding Data Models for Views (Conceptual, Logical, and Platform)

5.3.4 Modeling Navigation Management
This section illustrates modeling of a single component, the Navigation Management component
identified in Figure 42.
In this section, the reader is presented with an introduction to each of the process steps and
artifacts required for component development. It illustrates the basics of conceptual, logical, and
platform areas from the perspective of the single component. Some additional but commonly
occurring topics addressed by this example include:
 Use of validity indicators and statuses
 Implementation of enumerations
 Communicating with multiple instances of the same type of component, something
common in systems with designed-in redundancy.
5.3.4.1 Conceptual Model
First, the modeler identifies the conceptual elements to be represented in the model. This
includes fundamental entities about pertinent items and any observable or informational
attributes those possess. Rather than create from scratch, the modeler should first explore the
SDM for existing model elements and import them into the model being constructed. New
elements should only be created when there exists no corresponding element in the SDM.
The Navigation Manager component obtains estimates of position, attitude, and sensor statuses
from multiple sources and computes a single consolidated estimate. A simple examination of the
example scenario yields the following entities:
 Embedded Global Positioning System/Inertial Navigation System (EGI)
 Inertial Measurement Unit (IMU)
 Navigation Management Function
These define the system entities about which data is to be exchanged. As the entities themselves
will not be exchanged, the next task is to identify the observable and informational items that are
the characteristics of these elements.
The IMU reports an estimate of air vehicle attitude. The Observable elements in the SDM that
model the concept of attitude need to be identified. If these elements are not in the SDM, they
would need to be added as an extension element according to the rules of the FACE Shared Data
Model Governance Plan. In this case, attitude is modeled as an Orientation observable.
The example EGI reports Attitude and Position, leading to identification of the Position and
Orientation observables.
Note that since Orientation was already identified as an observable, there is no need to repeat the
identification of it for the EGI.
Figure 42: Conceptual Entities Required for Navigation Management Component

Figure 43: Orientation and Position Observables
One additional entity that can be identified is the Navigation Management Function itself. This
conceptual association type represents the estimated position of the system, based on the
attributes of the EGI(s) and IMU(s) installed on the system. The characteristics of this function
are Position and Orientation.
Since we have already defined Observable elements for Position and Orientation, those are
reused and do not need to be redefined.
5.3.4.2 Logical Model
Now that the elements in the conceptual model have been established, attention can be turned to
the LDM. The following tasks need to be accomplished to construct the elements required in the
LDM:
 Create Measurements that correspond to the observables in the conceptual model.
 Create Entities that realize corresponding elements at the conceptual level.
 Create any Units, Frames of Reference, Conversions, and enumerations required to fully
specify the Logical Entities.
 Create logical views to define message contents that are to be received and transmitted by
the component.
Proceeding with the first step called out above, measurements need to be created to realize the
observables in the conceptual model. This is shown in Figure 44. Since appropriate
Measurements for both the Position and Orientation observables already exist in the SDM, the
will be reused.
Figure 44: Orientation and Position Measurements
The Orientation observable from the conceptual model is realized as a compound measurement
as it is typically described as a set of angles in three-dimensional spaces (i.e., pitch, roll, and
yaw). To fully describe Orientation, the concept of an Angle must be introduced and added to
the Conceptual Model. It is necessary to include in the Logical Model measurements for Pitch,
Roll, and Yaw which are realizations of the Angle concept as illustrated Figure 45.
Since Pitch, Roll, and Heading are not further decomposed, they are modeled as simple
measures and the attributes of frame of reference, precision, units, and value type are specified to
describe the logical representation of each.

Figure 45: Pitch, Roll and Yaw Measurements
The same concept is performed for the compound measurement of the Position observable as
shown in Figure 46.
Figure 46: Altitude, Longitude, and Latitude Measurements
Now that the measures and information items have been established, entities for Navigation
Management Function, EGI, and IMU are created to realize their conceptual equivalents as
illustrated in Figure 47. It is important to note that the characteristics of the logical entities refer
to the measures and information items just defined at the logical level. As a result, the logical
representation of each entity represents a refinement of the conceptual entity by providing
additional detail for each characteristic.
Figure 47: Logical Navigation Management Entities and Associations
Once definition of the entities has been completed, Logical Views projecting the characteristics
of entities can be constructed to describe message contents. Figure 48 shows the contents of the
“Nav_Data” message to be output by the Navigation Manager UoP. Projections from the
Nav_Data view select characteristics of the NavManagementFunction entity to be included in
the TS Interface message.
The diagram also demonstrates how one can rename a characteristic in a view. Consider the
projection of NavManagementFunction.Position. By giving the source role in the Nav_Data
view the name “pos”, the characteristic is effectively given a new name in the message.

Figure 48: Logical Views and Projections for the Navigation Manager Component
The views used for the inputs to the Navigation Manager Component are modeled similarly.
Note that only one view is created for EGI data since that view will be reused in moving EGI1
and EGI2 data.
5.3.4.3 Platform Model
The key tasks in constructing the Platform Model include:

 Create platform (physical) representations of all of the measures in the Logical Data
model.
 Create platform Entities that realize corresponding elements in the logical model.
 Create platform views that realize the corresponding views from the logical model.
To create platform representations of the measures from the logical model, the modeler must
create a new instance of an Interface Definition Language (IDL) construct that will be used to
represent the measure. The diagram below demonstrates use of an IDL Primitive with an
IDLType of double in order to realize a Latitude measure from the logical model. The same
approach is used to define the platform representation for Longitude. Representations for
Measurements utilizing multiple axes are constructed using the IDLStruct element.
Figure 49 shows an IDLStruct used to realize the Position measure from the logical model. It
defines the fields of the position and uses the Latitude and Longitude platform representations to
apply the specific representation to them.
Figure 49: Platform Data Types for the Position Measurement
The same process is followed to create physical data types for the orientation measurements and
associated structure as shown in Figure 50.
Figure 50: Physical Data Types for the Orientation Measurement

Now that the physical data types have been established, platform entities for Navigation
Management Function, EGI, and IMU are created to realize their logical equivalents as
illustrated in Figure 51. It is important to note that the characteristics of the platform entities
refer to the physical data types just defined at the platform level. As a result, the platform
representation of each entity represents a refinement of the logical entity by providing additional
detail for each characteristic.
Figure 51: Platform Navigation Management Entities and Associations
Once measures have been mapped to IDL constructs and platform entities have been created, the
platform view of messages flowing into and out of the component can be created. This process is
similar to establishing views at the logical level in that characteristics of entities are projected
into views to define message content. The primary difference with platform views is that they
project from platform model entities while logical views project from logical model entities.
Figure 52 shows an example of the platform model view for the Nav_Data message.
Figure 52: Platform Views and Projections for the Navigation Manager Component
5.3.4.4 UoP Model
The key tasks required to define a UoP model are:

 Model the UoP and specify its characteristics (rate, language, profile, etc.).
 Add ports to the UoP for each incoming and outgoing flow.
 Map Platform Views to ports to describe the information communicated using the port.
Figure 53 illustrates the component definition for the Navigation Manager component.

Figure 53: UoP Model for the Navigation Manager Component
5.4 Considerations for Conformance

Primary factors that are evaluated as part of the conformance process are:
1. If the UoP adheres to the specified FACE interfaces
2. Verifying the messages sent and received across the TS Interface match the USM
3. If the USM follows the rules from the FACE Technical Standard and the FACE Shared
Data Model Governance Plan
The USM includes the messages, represented as platform views that the UoP sends or receives
across the TS Interface, as well as some additional characterization data intended to support the
system integration process. Message definitions in the USM are used by the conformance
process to generate typed send and receive calls that are then linked to the UoP. The absence of
conformance tool errors ensures that the message is only sending and receiving information
declared in the USM.
The rules of construction of the FACE Data Architecture are based on the idea that each message
relates to elements in the platform data model, each platform element realizes an element in the
logical data model and each logical data model realizes an element in the conceptual data model.
Ultimately all elements are tied back to basis elements that are present in the SDM. USMs are
only conformant if they only utilize SDM CCB controlled elements that are present in the SDM.

6 Health Monitoring/Fault Management Guidance
6.1 Overview
Health Monitoring/Fault Management (HMFM) is responsible for monitoring and reporting
application faults and failures with the OS, application software, and hardware within a
computing module. Faults may occur at the system, computing platform, partition, application
level, or with I/O devices the computing platform is directly responsible for controlling. Fault
detection, propagation, reporting, and management require careful attention to detail and
coordination between multiple layers within a system to operate correctly. Not all of these layers
are defined by the FACE Technical Standard.
6.1.1 HMFM Areas Addressed by the FACE Technical Standard

The following areas of responsibility are addressed by the FACE Technical Standard:
 Computing platform faults such as power failure potentially impact the execution of every
application on the computing platform and thus may be reported to the application via the
FACE HMFM API. Computing platform faults may also occur during initialization or
when the system is incorrectly configured. Thus only some potential computing platform
faults will be reported via the FACE HMFM API. Those not reported via the FACE
HMFM API are specific to the OS and it is the responsibility of the system integrator to
address those with the given OS mechanisms.
 Application-level faults may be detected by either the OS or the application itself. OS-
detected faults include illegal OS requests and process execution faults (e.g., memory
access errors or numeric exceptions). The application may self-detect faults and report
them via the HMFM API.
6.1.2 HMFM Areas Beyond the FACE Technical Standard

The following areas of responsibility are not addressed by the FACE Technical Standard:
 I/O device faults may be detected by device drivers, I/O Services, communications
protocol stacks, or applications. If redundant I/O devices are available, there may be the
option to switch to a backup device. If no redundancy, and after multiple reset attempts,
the only alternative may be to turn the device off and operate with reduced capability. The
means to detect these faults and manage redundant I/O devices is beyond the scope of the
FACE Technical Standard.
 In both partitioned and non-partitioned systems, there may be faults in the OS itself. These
faults will be managed by the OS and an OS may provide capabilities for the system
integrator to extend the actions taken in response to an OS fault.
 In partitioned environments, partition-level faults may also occur from an incorrect
configuration or prior to application execution. None of these faults are reported via the
FACE HMFM API. These are also the responsibility of system integrator to address given
the OS provided mechanisms.
 System-level faults are beyond the scope of the FACE Technical Standard.
6.2 Role of Board Support Packages

In all OS environments, the microprocessor and bus interface controllers may detect erroneous
actions by software. These erroneous actions may originate in the OS, application, or hardware
interface software. Board Support Packages (BSP) and device drivers are key to the detection
and reporting of many fault types. These hardware-detected faults, along with the OS or
application-detected faults, are reported to the OS HMFM capability. The OS HMFM capability
is utilized by the system integrator and application developer to provide a well-defined set of
responses to the set of potential fault conditions. Figure 54 illustrates this architecturally:
APPLICATIONS
FACE OPERATING SYSTEM

FACE I/O SERVICES INTERFACE Applications INTERFACE
INFRASTRUCTURE
SOFTWARE
REAL-TIME OPERATING SYSTEM (RTOS) OS HMFM
Hardware
Built-In Test (BIT) Board Support Package (BSP)
Monitoring
HW
Hardware
Figure 54: HMFM Board Support Package and Real-Time Operating System Relationship
At the most fundamental level, the BSP is responsible for the exception handlers that catch faults
such as floating point errors and memory access violations. The BSP may use standard OS-
provided implementations of these processor-dependent exceptions. If the BSP is improperly
installed, the fault handling mechanisms defined by any framework will never be used.
Similarly, if device drivers do not detect and report faults in the devices they control, the faults
will never enter the health framework.
The BSP may also provide additional capabilities, such as Built-In Test (BIT). BIT may execute
continuously in the background or be executed on-demand. BIT executed on-demand may
require the associated hardware devices be taken offline and may negatively impact operational
readiness. The design of on-demand BIT may have to take into account safety considerations.
Some hardware configurations include sensors used to monitor the health-related environmental
factors. Examples include thermal sensors, humidity sensors, fan speed, and indicators that the
hardware case is open. The BSP may provide interfaces so the sensors can report faults.

6.3 HMFM Layering
HMFM requires a multi-layered view of the system in regards to fault detection, handling,
reporting, reaction, and analysis. This view extends from addressing OS-initiated faults to
application-specific faults to entire computing platform failures.
Figure 55 illustrates the breadth of HMFM in a system.
Fleet
Aircraft Central Crew Alert
Maintenance
Maintenance System
Systems
Alerts or
Maintenance Alerts or
Maintenance
Module or Module or
Partition Partition
Reset Computing Platform Reset
HM
(module)
Partition 1 Partition M
Handler Handler
Report Report
Raise Raise
OS App App OS App App
Redundant I/O
Sources
Figure 55: HMFM Layering
6.3.1 Hardware-Detected Faults

At the lowest level is the hardware. Hardware-detected application faults, such as floating point
faults, divide by zero, and illegal memory accesses, can be reported to the application. ARINC
653 Health Services and POSIX signals may be used by an application to be informed of
hardware faults.
The hardware may be the source of faults, but this is considered beyond the current scope of
FACE HMFM. The exception is when the microprocessor detects certain erroneous application
behavior and reports it via the FACE HMFM capabilities.
6.3.2 Application Detected Faults

The application itself may detect faults and report them. These faults are processed using the
same framework as hardware-detected application faults.
The application’s fault handler may report the fault to a Computing Platform Health Manager if
it is unable to process the fault.
6.3.3 Computing Platform Health Manager

The Computing Platform Health Manager may be provided by the OS or the system integrator. It
is aware of the application requirements and will perform whatever corrective or remedial action
is indicated by the fault. This may involve:
 Resetting a partition
 Sending fault information to entities outside the computing platform
 Resetting the computing platform
6.3.4 External Systems

From a systems perspective, the computing platform used by FACE software is a single
component in a complex avionics system. Some faults may be completely managed within the
computing platform and need not be reported further. However, if the fault is propagated or
needs to be reported outside the computing platform, then it could go to external systems such as
a Crew Alert System or Aircraft Central Maintenance log. The definition of these external
interfaces is beyond the scope of the FACE Technical Standard.
It is important to consider the intended audience when propagating or reporting faults outside the
computing platform. For example, a Pilot or other Crew Member is likely to need a different
level of detail than a Developer or Maintainer.
6.4 OS Configurations
The FACE Technical Standard specifies three OS configurations and the native HMFM
capabilities available:
 Pure ARINC 653 OS
 POSIX on ARINC 653 OS
 Pure POSIX OS

6.4.1 ARINC 653 OS
In an OS based upon ARINC 653, there will be configuration tables which are used to define the
desired action to take in response to specific faults (errors in ARINC 653 terminology).
An application can have an error handler process. A partition-level error mechanism is executed
if an application error handler does not exist, or the handler has an error. The OS Partition
Health Monitor Table specifies the action to take upon various faults at the partition level. If an
error occurs at the module level, the Module Health Monitor Table specifies the system action to
take based upon system mode and fault.
6.4.2 Pure ARINC 653 OS

In the pure ARINC 653 OS configuration, an application is written strictly to the ARINC 653
API. In this case, the ARINC 653 Health Services are available. From an HMFM Services
perspective, this component would be FACE conformant.
6.4.3 POSIX on ARINC 653 OS

In the POSIX on ARINC 653 OS configuration, the ARINC 653 OS supports applications
written in POSIX. The ARINC 653 Health Services are available to the application even though
they are not part of the POSIX API. If the application were evaluated as being POSIX
conformant, it would fail due to the use of ARINC 653 APIs. From an HMFM Services
perspective, this component would be FACE conformant.
6.4.4 POSIX OS
For the purposes of this discussion, a pure POSIX OS is one with no underlying ARINC 653
services. Examples in this category include GNU/Linux, LynxOS, and Solaris.
There is no standard framework for pure POSIX FACE conformant components to have an
interoperable Health Services framework. Some of the ARINC 653 fault events are similar to
those defined to generate POSIX signals (e.g., SIGFPE, SIGBUS, SIGSEGV). Some faults can
be detected and reported but there is no standard Health Services framework in POSIX to define
what happens after the user signal handler is invoked.
Programming languages with built-in exception processing, such as Ada and Java, may install
handlers for the POSIX signals. For example, the Ada programming language run-time may
install a signal handler for SIGFPE and translate that into raising a NUMERIC_ERROR
exception as defined by the Ada standard. In these cases, the fault will likely be handled within
the context of the application and not involve the HMFM services.
6.4.5 FACE HMFM Services API

The HMFM Services API provides a common HMFM API and framework available across all
of the OS configurations. It is designed to not add excessive overhead or deviate from the
accepted practice of using ARINC 653 Health Services.
The FACE HMFM API is part of the OSS and provides compatible behavior across all of the OS
configurations. It would not be an ARINC 653 compatible solution on POSIX. Table 48
illustrates how the ARINC 653 Health Service can only address two of the three configurations.
Table 48: HM Options per OS Configuration
ARINC 653 Health API Feasible? FACE HMFM API Feasible?
Pure ARINC 653 OS Yes Yes
POSIX on ARINC 653 OS Yes Yes
Pure POSIX OS No Yes
It is not a FACE component conformance requirement to use HMFM services. A component can
be conformant if it uses ARINC 653 HMFM services. Using the FACE HMFM API provides the
option for a FACE component developer to have the same HMFM API in all of the OS
configurations examined.
6.5 HMFM Event Flow

Figure 56 illustrates the event flow of a fault being handled via the HMFM API.

Fault Handler
waits for next
fault
Fault Occurs
Fault
RTOS Application
Detected
By?
Local
OS Fault Application Fault
Yes
Handler Handler
Triggered Triggered
Fault
Pass to
Handled
Application?
Locally?
Raise Application Fault
Yes
Fault Handled
Fault Handled
by OS
Locally
Figure 56: HMFM Event Flow
All fault handling and management software remains quiescent until a fault occurs. If the
application has installed a fault handler, then that handler will be blocked waiting for a fault to
occur. If the fault is detected by the OS and can be processed by a thread-level fault handler
(e.g., a numeric exception or memory access error), the OS will trigger the execution of the
application-provided fault handler if one is installed; otherwise, it will perform the default
action. Similarly, if the application detects a fault and reports it via the appropriate HMFM API
service, then the fault handling support is triggered. It is important to note that any OS-triggered
fault indicates that an unexpected and potentially serious error has occurred in the application.
In either case, if installed, the application-provided fault handler will execute. It will execute in
the context of a special thread and there will be restrictions on the OS services which may be
invoked by the fault handler. The application-provided fault handler will take action which may
include:
 Attempting to recover from the fault
 Passing fault information to a logger or partition-level health monitor
 Propagating the fault to the OS for further action
6.6 HMFM Implementation Guidance

This section contains implementation guidance for the FACE HMFM API based upon the OS
configurations defined in the previous section.
6.6.1 Implementation on ARINC 653 OS

The FACE HMFM API is intended to be a simple layer on top of the ARINC 653 Health
Services.
6.6.2 Implementation on ARINC 653 OS with POSIX APIs

In this OS configuration, the implementation would be the same as on a pure ARINC 653 OS
configuration. The FACE HMFM API implementation would directly utilize the underlying
ARINC 653 Health Services.
6.6.3 Implementation on Pure POSIX OS

The FACE HMFM API is based upon ARINC 653. There is nothing 100% comparable to these
services in POSIX. The FACE HMFM API provides a common set of services across all FACE
Profiles. Supporting HMFM in a pure POSIX environment involves technical compromises. The
following is expected regarding an implementation on a pure POSIX system:
 Provide full source compatibility with FACE HMFM API on ARINC 653 OS
 Provide a useful functionality subset of FACE HMFM API in spite of POSIX not
providing the full complement of underlying Health Services capabilities found in ARINC
653
The following are guidelines for a POSIX-based FACE HMFM implementation:

 Use the sigaction() method to install the signal handlers. This results in the signal handler
being used with the following prototype:
void Signal_Handler(
int signal,
siginfo_t *info,
void *extra
);
 The signal parameter will contain the signal which has occurred. This can be mapped to a
FACE defined fault type. The signal parameter indicates the type of signal which is being
received. The implementation will map those to ARINC 653 faults. On some of the signal
types, an OS may provide additional information in the si_code field in the siginfo_t
structure pointed to by the info parameter. If available, this information may be used to
further identify the fault. Table 49 provides a mapping from a subset of POSIX signals to
the FACE faults which are based on those defined by ARINC 653.

Table 49: POSIX Signals Mapped to FACE Errors
POSIX Signal ARINC 653 Error Comments
SIGFPE NUMERIC_ERROR
SIGILL MEMORY_VIOLATION If si_code is ILL_BADSTK.
SIGILL STACK_OVERFLOW Assume memory violation if si_code is not

ILL_BADSTK.
SIGSEGV MEMORY_VIOLATION
SIGBUS MEMORY_VIOLATION
SIGSYS ILLEGAL_REQUEST
SIGXFSZ ILLEGAL_REQUEST
SIGQUIT POWER_FAIL Integrator chooses power fail signal.
SIGTERM POWER_FAIL Integrator chooses power fail signal.
SIGABRT POWER_FAIL Integrator chooses power fail signal.
POSIX does not define a signal to indicate when a power failure has occurred. If the system
integrator desires to make this fault available to POSIX applications, then a POSIX signal is
picked to indicate this fault. Multiple signals were identified in Table 49 to indicate a power
failure. There is no FACE requirement to use a particular signal or for a hardware platform to
detect that power has failed.
 The info parameter is a pointer to an instance of a siginfo_t structure. This structure
contains the field si_addr which indicates the address of the faulting instruction. If the
signal is SIGFPE or SIGILL, the structure also contains more detailed information about
the fault.
 The extra parameter is a pointer to an implementation-defined structure. On some
GNU/Linux versions, this is a pointer to a ucontext_t structure.
The fields of the FAULT_STATUS_TYPE structure can be filled in as follows:

 The FAILED_THREAD_ID field is filled in with the ID of the thread executing the signal
handler. This is returned by pthread_self().
 The FAILED_ADDRESS field is filled in with the si_addr field of structure pointed to by
the info parameter to the signal handler.
 The MESSAGE field is filled in generically with a string such as “fault”, the signal name,
or with more detailed information based on decoding the si_code in the siginfo_t structure
pointed to by the info parameter to the signal handler. Providing detailed information via
the si_code may not be supported by the OS and there is no requirement for the
implementation to provide any detailed information via the MESSAGE field. It is not a
FACE requirement to provide any information not defined by the HMFM API and its data
structures. However, this information may be useful to system integrators in evaluating
the source of the fault and eliminating it in the future.
Some examples of more detailed information include the following using the si_code
information:
 SIGFPE could indicate multiple conditions including integer or floating point overflow,
underflow, or division by zero.
 SIGILL could indicate the execution of an illegal instruction, a privileged instruction, or a
coprocessor error.
 SIGSEGV could indicate an access of an invalid address or insufficient privileges.
 SIGBUS could indicate an access with illegal alignment or an attempt to access a non-
existent physical address.
POSIX has no concept of ARINC 653 deadline-based scheduling. Based solely upon POSIX
capabilities, the DEADLINE_MISSED fault cannot be generated.
Based upon the capabilities of the RTOS, an implementation may not be able to generate all
fault types.
Propagation of fault to a Health Manager outside of a POSIX process uses implementation-

dependent mechanisms.
The goal of the FACE HMFM API is to provide application portability across all OS profiles.
An implementation on a pure POSIX OS provides source code-level compatibility but may have
limitations on the faults which are raised by the HMFM framework.
6.7 HMFM and Non-Volatile Storage

The FACE HMFM capabilities are based on those defined in the ARINC 653 Specification.
ARINC 653 intentionally does not include non-volatile storage of faults as an OS responsibility.
The rationale that went into this decision includes the following:
 OS-detected faults are a small subset of the overall system fault and health management.
System fault management and logging was considered a system integrator/platform
provider responsibility. Different organizations that built ARINC 653-based systems had
significantly different management techniques for this.
 Not all platforms support non-volatile storage.
 There are some OS-detected faults that are for conditions where the system is in a state
that attempting to write to non-volatile storage is questionable. In certain fault scenarios,
writing to non-volatile storage could result in data corruption or potentially prevent
system recovery.
ARINC 653 does not consider non-volatile (or even volatile) storage of OS-detected faults to be
an OS vendor implementation-specific capability. Platforms that required non-volatile storage
could utilize one of the ARINC 653 Part 2 optional service categories (file system or logbooks)

to store faults in non-volatile memory. The FACE OS Safety and General-Purpose Profiles
include support for the ARINC 653 File System services (and corresponding POSIX file system
APIs) to support non-volatile requirements (when the platform provides non-volatile storage
hardware). This permits non-volatile storage to be supported via a portable means.
The ARINC 653 health monitoring includes interfaces/descriptions intended to provide support
for communicating OS fault messages to some system-level HM capability. The intent is these
capabilities would be configured to forward on OS-related faults when logging of such faults
was to be included as part of the platform.
6.8 Fault Handler Guidance

The basic structure of a user error handler is a thread body with an infinite loop around an
invocation of the FACE_HMFM_Get_Fault_Status() method. This method blocks the thread
until a fault occurs. When a fault occurs, this method will return from that blocking state with
information about the fault. The user fault hander will be able to examine the fault to determine
its type. The fault handler can look at the fault type and use that information to decide whether it
is a fault it knows how to address or whether it should be propagated to the next level.
Fault_Handler:
loop
FACE_HMFM_Get_Fault_Status()
If the fault is one handled by this handler, the
application has the option to
a) propagate the fault to the next level,
b) reset the partition,
c) stop (e.g., idle) the partition,
d) reset the offending thread,
e) stop (e.g., idle) the offending thread, or
f) clean up the error source
In cases a – c, the fault handler will not return.
In cases d – f, the fault handler will attempt to return
to the application.
Else the fault is not processed by this handler
application fault propagated to the next level via
FACE_HMFM_Raise_Application_Error()
end loop
Care must be taken when writing a fault handler. The fault handler should under no
circumstances perform a blocking action. It may invoke a non-blocking communications method
to pass information to another partition. Hopefully, that other partition is not in a fault state and
can undertake more complex actions such as logging the fault.
The fault handler can attempt thread recovery but it must be cautious in doing so. The faulting
thread has both a fault condition and a logical state which must be addressed for successful
recovery to occur. In some cases, correct fault recovery will require addressing both the fault
condition and the logical state of the faulting thread. The specific OS services available to
address the faulting thread will vary based upon whether the partition is executing a POSIX or
ARINC 653-based application.
To facilitate recovery, the fault handler must directly address the source of the fault and resolve
it. The fault handler may be designed such that a single event fault allows the application to retry
the operation. If the fault occurs again, then remedial action may be taken. For example, a fault
caused by a memory parity error may be a single event. However, if a programming error results
in a thread causing a memory violation, then the fault will occur again if the operation is retried.
In this case, in order to recover, the “pointer” that the thread is using must be corrected or the
thread will reuse the same invalid memory reference. Similarly, if the thread has a floating point
exception due to a programming error, a fault indicator will likely need to be cleared in hardware
and the faulting numeric operation will have to be corrected. In all these cases, the RTOS may
provide the fault handler with the address of the faulting instruction and faulting thread’s
context. Recovery is possible but requires processor and RTOS-specific information.
If the fault has occurred as the result of a soft or hard hardware fault, it is possible that the fault
handler can address the fault and the application recovers. This would require knowledge of the
fault, recovery actions possible, and, in some circumstances, the existence of backup devices and
how to switch to them.
Assuming that the fault is one which can be recovered from, there is still the logical state of the
faulting thread to address. In the case of a floating point exception, this might require knowledge
of the algorithm used by the faulting thread. Knowing that there was a divide by zero fault and
putting an arbitrary result into the destination register is one thing. Knowing the value to put into
that destination to correct this invalid computation and allow its algorithm to produce a
meaningful result is another matter entirely.
Other parts of the logical state of a thread include any locks held on resources, resources
allocated, partial computations, and application state information. For example, the fault may
have occurred while a thread held locks. Those locks would not automatically be released and it
would be the responsibility of the recovery actions taken or initiated by the fault handler to
release those. Similarly, if the thread has dynamically allocated any resources (e.g., RTOS
objects, memory), then those allocated resources may have to be freed or placed into a known
state.
The usual case is that an application reaches the fault handler when something has happened that
it could not foresee or avoid programmatically. This implies that the application designers did
not expect the condition, thus could not avoid it and are unlikely to know how to recover. For
example, if a divide by zero were expected by the application designers, then it would have been
trivial for them to include a test if the denominator were zero, perform an alternative
computation, and avoid the faulting operation.
In addition, all software in a system may have to be reviewed and undergo rigorous coverage
testing. In order to fully test complex fault recovery actions, there must be ways to generate the
appropriate fault conditions reliably in a testing environment. The correctness of simple fault
recovery actions is much easier to demonstrate. Thus, it is common to perform no recovery
attempt and reset or idle the partition.

7 Graphics Services Guidance
FACE Platform-Specific Graphics Services support data flows that conform to OpenGL, ARINC
739, and ARINC 661. The Platform-Specific Graphics Services used by a component (i.e.,
OpenGL, ARINC 661, and ARINC 739) are the responsibility of the component developer. The
inclusion of the necessary supporting display infrastructures (e.g., GL/EGL/GLX services,
ARINC 661 services, and ARINC 739 services) to support the system applications are the
responsibility of the platform integrator.
7.1.1 OpenGL – 2D and 3D Imaging

OpenGL is a widely adopted group of specifications defining a cross-language, cross-platform
API for writing applications that produce 2D and 3D computer graphics. Well supported
OpenGL specifications and implementations exist for operation in the FACE General-Purpose
and Safety Profiles.
7.1.1.1 OpenGL Use in the General-Purpose Profile
The following specifications shown in Table 50 define the OpenGL functional behavior and
APIs for the General-Purpose Profile. Developers are given the choice between OpenGL with
GLX to support indirect rendering or OpenGL ES with EGL to support direct rendering.
Table 50: OpenGL Functional Behavior Specifications
Direct/Indirect Direct
Function Rendering Specification Rendering Specification
2D & 3D Graphics OpenGL Graphics System: A OpenGL ES 2.0

Rendering and API Specification (Version 1.2.1)
Window Management for Khronos Group EGL 1.2 Khronos Group EGL 1.2
Local Display Support
Window Management and GLX 1.3 with the X Window System

Remote Display Support X11R 6.0
X11 Byte Stream GLX Extensions for the OpenGL

Encoding Protocol Specification (Version 1.3)
There are a several standards supporting variations of OpenGL, each with its own set of
associated versions. The OpenGL version selected for this profile was chosen to maximize
application portability between the Safety and the General-Purpose Profiles, without
significantly impacting imaging capabilities in an avionics environment. Software application
portability between the FACE Profiles is enhanced by the fact that OpenGL has a safety-critical
specification discussed in upcoming sections.
7.1.1.2 OpenGL Use in the Safety Profile
The FACE Safety Profile supports a subset of the graphics commands and capabilities of the
General-Purpose Profile. Table 51 lists the specifications defining OpenGL functional behavior
and APIs for the Safety Profile.
Table 51: OpenGL Safety Profile Specifications
Function Specification
2D & 3D Graphics Rendering and API OpenGL SC Safety-Critical Profile Specification

(Version 1.0.1), Khronos Group (OpenGL SC)
7.1.1.3 OpenGL Use in the Security Profile
The FACE Security Profile does not support Platform-Specific Graphics Services
Implementations.
7.1.2 ARINC 739 and 739A-1

ARINC 739 defines an interface between a system and a Control and Display Unit (CDU). The
interface is a message-oriented description and protocol that makes use of the TS Interface.
The following specifications shown in Table 52 define the ARINC 739 functional behavior and
protocol.
Table 52: ARINC 739 Functional Behavior Specifications
Single MCDU Specification ARINC 739: Multi-purpose Control and Display Unit
(MCDU))
Dual MCDU Specification ARINC 739A-1: Multi-purpose Control and Display Unit
(MCDU)
The General-Purpose, Safety, and Security Profile implementations of the ARINC 739 graphics
interface are identical.
7.1.3 ARINC 661

ARINC 661 defines the cockpit display using a markup language similar in style to XML. The
cockpit display is compiled into a standard binary Definition File (DF) that is interpreted by an
embedded run-time, the Cockpit Display System (CDS). The CDS generates the display using
the graphics infrastructure available on the host system.
Table 53 lists the specifications defining ARINC 661 functional behavior and protocol.

Table 53: ARINC 661-4 Functional Behavior Specifications
Cockpit Display System Interface and ARINC 661: Cockpit Display System Interfaces to User
Functional Specification System
The General-Purpose, Safety, and Security Profile implementations of the ARINC 661 graphics
interface are identical.
7.1.3.1 Recommendations for Enhanced Portability
Because ARINC 661 defines a User Application (UA) that must know certain parameters of the
CDS, this section focuses on guidance to provide standards methods or values for the CDS-
specific configuration items that are left non-standardized by ARINC 661.
Points of focus will be Font, Color, and Style Indexing, and use of configuration parameters in
both the UA and the CDS to enhance portability in the FACE architecture.
UAs are only portable if a system integrator knows how it should communicate to the CDS. This
means that UA developers should provide some documentation on what and how widgets are
controlled; an example Definition File (DF) file specific to the UA should be enough to show
this.
7.1.3.1.1 Configuration Parameters
The CDS should provide configuration options for the following items. It is suggested that these
be put in a file that is loaded by the CDS upon start-up:
 Screen size in pixels
 Pixels per inch
 Pointers to graphical DF files; e.g., filenames
 MaskContainer regions
 Fonts, the ability to specify the font, its sizing, and indices for each size
 Colors as mentioned in Appendix D: Standard Color Index
 Style sets
The UA should add the ability to have its Layer ID(s), Context ID(s) set external to the UA. The
UA may also provide the ability to set a base widget ID offset; this allows for a UA to be created
controlling widgets 0 – 1000, but when the creator of the DF file puts those widgets at 23000 –
24000, the UA can adjust accordingly without any change to the UA, thus removing a hurdle for
the system integrators trying to reuse components working in an ARINC 661 system. A similar
base font offset is also suggested for font indexing. See Section 7.1.3.1.1 (Font Indexing) for
further discussion. The UA should provide configuration options for the following items. It is
suggested that these be put in a file that is loaded by the CDS upon start-up:
 Layer ID
 Context ID
 Base Widget ID
 Base Font Index
Font Indexing
A basic scheme is adopted for font indexing. Font indices will be based on size where font index
1 has a smaller point size then font index 2, and font index 3 is larger than font index 2. For
example, if font index 0 is defined for a specific CDS as 12 point, font index 1 could be 14 point,
and font index 2 could be 16 point.
Therefore, a UA simply has to increment the font index by one (1) to increase the font size.
Likewise, the UA decrements the font index by one (1) to decrease the font size. Using this
method, the system integrator can determine the font used by the system, but the UA has some
basic knowledge of which fonts it would be using.
 Font Indices 0 – 9 are defined as system basic fonts.
 Font Indices 10 – 19 are defined the same way but as bold fonts.
 Font Indices 20 – 29 are defined the same way but as underline fonts.
All other indices (30 – 255) would be system integrator-defined, so the UAs that require other
types of fonts should allow the system integrator to associate the other types of fonts with those
defined by the system integrator.
This method allows the UA a way to use a bold, underline, or basic font with some knowledge
that by simply adding or subtracting 10 it can change the font style in a uniform way and reduce
integration issues because each UA from separate suppliers using different font indices that were
hard-coded and certified that way.
It is encouraged that the UA configuration include a means to provide a base offset such that
font bases can be changed such that the system integrator may increase/decrease the font size by
simply adding a font index base offset in the UA configuration file. This offset would have to be
applied to each range of fonts separately. This also encourages that UA authors start with index
5 as the default font and size appropriately from there, based on relative font sizing, knowing
that the system integrator may change the font index base offset to match the size as required by
the system.
Colors
As with fonts, color indices in ARINC 661 have been left non-standardized. To increase
portability this guide suggests that FACE portable UA and CDS that are integrated into a system
containing FACE conformant UoCs use a named color approach. The UA will use a color index
as associated with a color name; this way the UA can be guaranteed that when it changes from
Green to Red the CDS changes from Green to Red.
The FACE Technical Standard does not define required Red/Green/Blue (RGB) values for each
color as any color may need to be adjusted to display correctly on specific display hardware. As

such, part of the CDS configuration should allow that any named color be assigned an arbitrary
RGB color for that specific hardware.
Appendix D is a table containing a mapping of HTML standard Color Name to the

corresponding Color Index with a default hexadecimal value for each color. The default color
value can be overridden by a CDS configuration file option, as needed by the system integrator.
However, the system integrator should try not to vary the colors outside a reasonable margin,
meaning that the name Green should stay visibly green and not be changed to a visible yellow or
blue.
Style Sets Indexing
ARINC 661 leaves the use of style indices up to the CDS integrator. When developing UAs that
change the style set indices at run-time, care should be taken to have those styles standardized in
some way between UA suppliers and CDS integrators. Styles for graphical primitive widgets and
label widgets may be standardized in later versions of the Reference Implementation Guide. For
now, when creating reusable UAs that change the style set index, best practice suggests that style
set indices are configurable from an external file. This allows the system integrator to set the
style set indices matching those defined in the CDS. This is similar to the approach taken for the
color indices.
7.1.4 Variability
7.1.4.1 OpenGL (Using GLX Server) in a Distributed Environment
Figure 57 shows an example data flow in an OpenGL distributed environment. This example
shows two client applications using the same GLX Server.
All data passed through Service are in different
Different address spaces
Portable Component
Segment 1
1
OpenGL OpenGL
Graphics Client Graphics Client
Application Application
2
TS API TS API
TS library Transport Services TS library
2
Segment
X11 Byte Stream
3
TS library
TS API
4
GLX Server
5
Platform-Specific
Services Segment
GPU
Driver
Graphics
Processor
Figure 57: GLX Server Distributed Graphics Communication
The list below describes the sequence of actions performed to send OpenGL data across the TS
Interface to a GLX Server:
1. OpenGL graphics client application uses OpenGL APIs natively as part of the TS
Interface.
2. TS Library sends the OpenGL commands using the X11 Byte Stream.
3. TS Library receives the X11 Byte Stream then provides it to the GLX Server.
4. TS Library handles the callback registered by the GLX Server if required.
5. GLX Server communicates natively with the GPU Driver to control the Graphics
Processor.
7.1.4.2 OpenGL in a Non-Distributed Environment
Figure 58 shows an example data flow in an OpenGL non-distributed environment. The example
shows a client application using a TS Library to communicate with a GPU Driver.

Portable Component
Segment
OpenGL 1
Graphics Client
Application
TS API
Transport Services
Segment
2
GPU
Driver
Graphics
Processor
Figure 58: OpenGL Non-Distributed Graphics Communication
The list below describes the sequence of actions performed to use OpenGL commands across the
TS Interface:
1. OpenGL graphics client application uses OpenGL APIs natively as part of the TS
Interface.
2. The TSS provides access to the OpenGL driver.
7.1.4.3 ARINC 739 in a Distributed Environment
Figure 59 shows an example data flow in an ARINC 739 distributed environment. This example
shows two CDU-based client applications communicating with two ARINC 739 servers.
address spaces
Portable Components
Segment
1
1
CDU-Based CDU-Based 2
Client Application Client Application
TS API TS API
2 TS library TS library
3
ARINC 739 Command Stream
3
Transport Services
Segment TS library TS library
TS API TS API 4
4
ARINC 739 ARINC 739 5
5 Server Server
Platform-Specific
Services Segment 6
6 IO API IO API
I/O Services IO library IO library
Segment IO API IO API
7
7 ARINC 429 ARINC 429
Service Service

ARINC 429 here is not mandated by ARINC 429
Driver the FACE Standard. For Driver
Operating Systems this example, it was a
Services Segment design decision to
the I/O Component.
CDU1 CDU2
Figure 59: ARINC 739 Server Distributed Graphics Communication
The list below describes the sequence of actions performed to send ARINC 739 data across the
TS Interface to multiple CDUs:
1. CDU-based client application packs the ARINC 739 command stream data using the
FACE Data Model (FACE Technical Standard, Section 3.6).
2. CDU-based client application provides packed data to TS Library by calling the TS API
Send_Message function (FACE Technical Standard, Section E.8).
3. TS Library executes the Send_Message function using IPC to send the ARINC 739
command stream.
4. TS Library receives the ARINC 739 command stream for the ARINC 739 server.
5. TS Library handles the callback registered by the ARINC 739 server if required.
6. ARINC 739 servers send the ARINC 739 data by using the I/O API (ARINC 739
protocol) I/O Interface and I/O Library to the ARINC 429 service (see Section 2.3.3.1 for
more information on I/O communication).
7. ARINC 429 service communicates with the non-standardized ARINC 429 drivers to
control the CDUs.

7.1.4.4 ARINC 661 in a Distributed Environment
Figure 60 shows an example data flow in an ARINC 661 distributed environment. This example
shows two CDS-based client applications using the same ARINC 661 server.
address spaces
Portable Component 1
ARINC 661 Segment ARINC 661

1 Graphics Client Graphics Client
2
Application Application
TS API TS API
3
2
TS library Transport Services TS library
Segment
3
TS library
4 TS API
ARINC 661
Server
5
Platform-Specific
Services Segment
6
GPU
Driver
Graphics
Processor
Figure 60: ARINC 661 Server Distributed Graphics Communication
The list below describes the sequence of actions performed to send OpenGL data across the TS
Interface to a GLX Server:
1. ARINC 661 graphics client application packs the ARINC 661 command stream data using
the FACE Data Model (FACE Technical Standard, Section 3.6).
2. ARINC 661 graphics client application provides packed data to TS Library by calling the
TS API Send_Message function (FACE Technical Standard, Section E.8).
3. TS Library executes the Send_Message function using IPC to send the ARINC 661
command stream.
4. TS Library receives the ARINC 661 command stream for the ARINC 661 server.
5. TS Library handles the callback registered by the ARINC 661 server if required.
6. ARINC 661 server communicates natively with the non-standardized GPU Driver which
controls the Graphics Processor.
8 Configuration Services Guidance
8.1 Introduction
Configuration allows modification of a FACE component’s run-time behavior from input stored
on configuration media (e.g., files, shared memory, hardware strapping) without modifying the
component’s executable object code. For any given capability, the selection and interconnection
of components could be performed in multiple ways. Configurable components have the
potential for greater portability than components designed for a single platform or mission.
8.2 FACE Configuration Categories

FACE configuration implementations fall into one of the four following categories:
1. No Software Configurability Available
2. Legacy Local Configuration
3. API-based Configuration
4. Hybrid Configuration
8.2.1 No Software Configurability Available

The No Software Configurability Available category is defined as component behavior and must
be handled through software modification.
8.2.2 Legacy Local Configuration

The Legacy Local Configuration category is defined as configuring a component by direct
access to configuration media. The media’s properties (e.g., name, location, content, format) are
tightly coupled to the configurable component. The configurable component processes the data
to modify the component’s behavior without modifying its executable object code. Alternatively,
behavior can be altered through physical mechanisms such as hardware strapping. The validity
of the configuration data (including its format, structure, type fidelity, boundary checking, and
allowable enumeration values) is typically enforced by the configuration parser within the
component.
Figure 61 depicts two entities involved in this exchange: the configurable component and the
configuration media. These entities are directly related by operating system calls (e.g., open(),
read(), close()). Processing of configuration data occurs within the component. To avoid driving
cost, effort, and recertification into legacy components, the API-based Configuration approach,
defined in Section 8.2.3, should be considered over the Legacy Local Configuration approach.

O/S File APIs
Configuration (e.g. open(), read(), close() )
Client
Configuration
Configuration
Configuration
Parser
File
File
Operating
System
Figure 61: Legacy Local Configuration
When the software supplier identifies that Legacy Local Configuration is used, component
characterization, such as hard-coded configuration expectations, must be documented.
8.2.3 API-Based Configuration

To support the portability of FACE components, the configuration of those components must be
portable as well. The Configuration API is provided by a Configuration Library as depicted in
Figure 62.
The Configuration Library may be supplied by the Avionics Supplier/System Integrator. This
division of labor provides the Avionics Supplier/System Integrator flexibility regarding where
the configuration data is stored and how it is accessed. The Avionics Supplier/System Integrator
selects or creates an implementation of a Configuration Library for each configurable
component. The intention is for a single Configuration Library (similar to TSS
implementations). No effort is required by software suppliers when changes in configuration
location, media, or access methods are made.
Linked into a single deliverable Configuration APIs have

familiar semantics
Configuration (e.g., open(), read(), close() )
Client
Configuration
Parser
Configuration
Configuration
Configuration File
File
The Configuration Library Library
is supplied by the
Avionics Supplier/
System Integrator
Figure 62: FACE API-Based Local Configuration
The software supplier is encouraged to use the anticipated Configuration API (future FACE
Technical Standard update) as provided in Appendix C of this Guide. Using this API enables the
Avionics Supplier/System Integrator to supply an appropriate Configuration Library for linking
to configurable software components.
The benefit to the software supplier is that a single standardized API for configuration tasks with
a defined behavior may now be used in components targeted for any FACE segment. There is
also no need to modify the component for new environments because the implementation
requiring the change is now supplied by the Avionics Supplier/System Integrator.
The benefit to the Avionics Supplier/System Integrator is the ability to control where the
configuration data is stored. It allows the creation of a library which maps the location-agnostic
Configuration API calls to a platform and transport-appropriate implementations. It does all this
without the need for the software supplier (which could very likely be another vendor) to modify
the component.
One point should be made explicit: under Edition 2.1 of the Technical Standard, the library must
be linked in with the UoP with the implementation treated like a framework outside of the FACE
architecture from a conformance point of view. Once defined in the Technical Standard, the API
will be allowed to be externally provided by the OSS Configuration API.
8.2.3.1 Migration from Legacy Local Configuration to FACE API-Based Configuration
Legacy Local Configuration has the drawback of limiting the potential for portability of a
component to other systems. Two examples illustrating this point are:
1. Secure operating systems having no file system to hold a configuration file
2. A need to relocate the configuration file without modifying the configurable component
The Configuration API supports a migration path for legacy components by providing data
movement and API usage behaviors similar to the operating system API used to access files;
e.g., open(), read(), and close(). The Configuration API has a few additional and required formal
parameters in their API calls to distinguish them from the standard OS APIs.
The migration of a FACE component from Legacy Local Configuration to API-based

Configuration requires the software supplier to use the Configuration API rather than the OS
API. This is accomplished by substituting the OS API with the Configuration API and
incorporating the relevant OS API functions in the Configuration Library. For example, using
Open(CONFIG), Read(CONFIG), and Close(CONFIG) instead of open(), read(), and close()
from the OS. These OS calls are then incorporated into the Configuration Library. This allows
the software supplier to test the configuration of their component and also allows the
component’s configuration information to be provided on multiple platforms implementing the
FACE architecture.
8.2.4 Hybrid Configuration

Hybrid Configuration is accomplished by using a combination of Legacy Local Configuration
and API-based Configuration.
8.3 Recommended Configuration Services Artifacts

The configuration of a component is expressed in three (3) artifacts:

1. An XML Schema Definition (XSD) documenting the form of the configuration data,
known as the Component Configurability Definition (CCD)
2. An XML file containing the configuration data for a component, called the Configuration
Set Identifier List (CSIL)
3. A transformation process for converting the XML file to a format readable by the
configuration library on the target hardware, also referred to as the Configuration Set
Encoding Package (CSEP)
Note: Step 3 may be unnecessary if the target system implementation natively supports
XML.
Each of these items is specifically addressed in the following sections.
8.3.1 Component Configurability Definition

The Component Configurability Definition (CCD) is expressed in an XSD document and
describes the following FACE component characteristics:
1. Identification of configurable parameters
2. Ranges of valid configurable parameter values
3. Behavioral impact associated with each configuration value
4. Default values for configurable parameters
5. Disallowed combinations of configuration values
8.3.1.1 Identification of Configurable Parameters
Configurable Parameters are the named attributes of configurable components that effect
behavioral modification of the component without alteration of its executable object code. These
named attributes are called Configuration Parameter IDentifiers (CPIDs). The act of assigning
values to configurable parameters may be accomplished with a configuration data file containing
the CPIDs and their associated values.
The actual configurable parameter names, valid values, and file formats are defined and
documented by the software supplier. For any given capability provided by a FACE component,
various algorithms and feature sets may be selectable to configure the component. The values
assigned to the configurable parameters determine which algorithm or feature set is used by the
FACE component.
8.3.1.2 Ranges of Valid Values for Configurable Parameters
The range of valid values for each configurable parameter should be specified in the CCD to
provide the ability to validate the component configuration files.
8.3.1.3 Behavioral Impacts Associated with Each Configuration Value
Each behavioral alternative must be defined for each valid value (or range of values) for each
CPID associated with each configurable parameter. The range of valid values of the CPID
TACAN_MODE is 0 through 4 with behavioral impacts as provided in Table 54.
Table 54: Configuration Parameter Example
CPID Value Behavioral Impact
TACAN_MODE 0 Power is OFF, Tactical Air Navigation

(TACAN) is not operational
1 Receive mode, TACAN operates in Air-to-

Ground Receive mode only
2 (default) T/R mode, TACAN operates in Air-to-

Ground mode with simultaneous Transmit
and Receive mode
3 A/A_RECEIVE mode, Air-to-Air Receive

only mode
4 A/A_T/R mode, Air-to-Air mode with

simultaneous Transmit/Receive
8.3.1.4 Default Values
Software suppliers should identify the default value for all configurable parameters.
Configurable parameters are not required to be explicitly set if the default value is the desired
configuration value. In the example of Table 54, the default value is specified as 2 (T/R Mode).
8.3.1.5 Disallowed Combinations
There are cases where selections of valid values for CPIDs are invalid as a group for the
component. The example in Section 8.3.1.6 shows the case where “InPrecision” is set to
“Single” and “OutPrecision” is set to “Double”. The significance of this example is that “Single”
is normally a valid value for “InPrecision” and “Double” is normally a valid value for
“OutPrecision”. However, these values are now an invalid combination for “InPrecision” and
“OutPrecision” as indicated using the xs:assert tag in the XSD in Section 8.3.1.6.
8.3.1.6 CCD Example
The example CCD defines two CPIDs: “InPrecision” and “OutPrecision”. For each CPID, the
attribute type=“PrecisionType” is a reference to a type definition which enumerates the range of
valid values (“Single” and “Double”). The behavior of each value is described in the comments
containing the word “BEHAVIOR”. The attribute specification of “default="Double"” informs
the reader that, if not otherwise specified, the value assigned to “InPrecision” will be “Double”.
The assertion line disallows setting “InPrecision” to “Single” and “OutPrecision” to “Double”.

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:vc=http://www.w3.org/2007/XMLSchema-versioning
elementFormDefault="qualified" attributeFormDefault="unqualified"
vc:minVersion="1.1">
<xs:element name="ExampleComponentConfiguration">
<xs:annotation>
<xs:documentation>This XML Schema Definition File describes
valid configuration sets for the Example Component
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="InPrecision" type="PrecisionType"
default="Double">
<xs:annotation>
<xs:documentation>The CPID "InPrecision" must be
assigned a value of the type "PrecisionType”.
If not specified, InPrecision will take on the
default value of "Double".
BEHAVIOR: Selecting "Single" performs input
calculations in single precision math.
BEHAVIOR: Selecting "Double" performs input
calculations in double precision math
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="OutPrecision" type="PrecisionType">
<xs:annotation>
<xs:documentation>The CPID "OutPrecision" must be
assigned a value of the type "PrecisionType".
If not specified, OutPrecision will take on the
same value as “InPrecision”.
BEHAVIOR: Selecting "Single" performs output
reporting in single precision math.
BEHAVIOR: Selecting "Double" performs output
reporting in double precision math
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:assert test="not ((InPrecision eq 'Single') and
(OutPrecision eq 'Double'))">
<xs:annotation>
<xs:documentation>This assertion ensures that the case
where InPrecision = Single and OutPrecision = Double
does not successfully validate against this XML schema.
</xs:documentation>
</xs:annotation>
</xs:assert>
</xs:complexType>
</xs:element>
<xs:simpleType name="PrecisionType">
<xs:annotation>
<xs:documentation>This is the definition of the simpleType
named "PrecisionType". Please notice that both
InPrecision and OutPrecision use this type.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="Single">
<xs:annotation>
<xs:documentation>This value selects Single Precision
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="Double">
<xs:annotation>
<xs:documentation>This value selects Double Precision
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:schema>
8.3.2 Component Configuration Set

A Component Configuration Set (CCS) is an XML document created by the Avionics
Supplier/System Integrator that is valid with respect to the CCD supplied by the software
supplier. The CCS is scoped to a single component and captures a set of configuration value
choices for a subset of the component’s CPIDs.
8.3.2.1 Component Configuration Set Example
The following example CCS is valid with respect to the CCD as shown in Section 8.3.1.6
containing the “ExampleComponentConfiguration” element. Within that XML element, two
other elements are found. The “InPrecision” element is given a value of “Double” as allowed by
the CCD with a type named “PrecisionType”. The “OutPrecision” element is optional in this
CCS. The “OutPrecision” parameter is given a value of “Single” by the System Integrator as is
allowed by the CCD.
<ExampleComponentConfiguration>
<InPrecision>Double</InPrecision>
<OutPrecision>Single</OutPrecision>
</ExampleComponentConfiguration>
8.3.3 Configuration Set Identifier List

The Configuration Set Identifier List (CSIL) is delivered to the Avionics Supplier/System
Integrator as an explicit description of the configurability of the component, listing named sets
of configurable parameters. A CSIL is an XML document that validates against the CSIL XSD.
There may be more than one CSIL per component. Table 55 defines the Container Name and
Container Content of the CSIL.

Table 55: Configuration Container Terminology
Container Name Container Content
ContainerID A token supplied at run-time by the configurable component to the

Open(CONFIG) service which is mapped to a storage mechanism of
configuration data.
CSID A token supplied at run-time by the configurable component to the

Read(CONFIG) service which is mapped to a mechanism identifying
a configuration entity group within the scope of the current
ContainerID.
CPID The Configurable Parameter IDentifier(s) detail the content of a

configuration entity group, specifying the configuration content for
each CSID.
8.3.3.1 Configuration Set Identifier List Schema
Figure 63 provides a pictorial representation of the XSD. Following the figure is the XSD used
for validation of the CSIL.
Figure 63: CSIL Schema Pictorial Representation

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:documentation>Configuration-Set Identifier List (CSIL)
describes the "data_set" names that may be requested by
the configurable component and the set of configurable
parameters to be supplied when that CSIL-ID is requested
</xs:documentation>
</xs:annotation>
<xs:element name="CSID">
<xs:complexType mixed="false">
<xs:all>
<xs:element ref="CPID" maxOccurs="unbounded"/>
</xs:all>
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="CPID" nillable="false">
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="CSIL">
<xs:all>
<xs:element name="ContainerID" minOccurs="0"
maxOccurs="unbounded">
<xs:all>
<xs:element ref="CSID" maxOccurs="unbounded"/>
</xs:all>
<xs:attribute name="name" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:all>
<xs:attribute name="UoP-Conformance" type="xs:date"
use="required"/>
<xs:attribute name="UoP-ID" type="xs:string" use="required"/>
<xs:attribute name="UoP-Version" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>

8.3.3.2 Configuration Set Identifier List Examples
8.3.3.2.1 Configurable Component CSIL Example
The example CSIL shown below consists of a single root element named “CSIL” containing
information for two configuration data containers named “MyStuff” and
“C:\FACE\NavigationComponent\Config\Mypdi.pdi”. The Configuration Set Identifier (CSID)
“all” is defined for the “MyStuff” container and the CSID “compact” is defined for the
“C:\FACE\NavigationComponent\Config\Mypdi.pdi” container. Each configuration data
container enumerates the names of applicable CPIDs.
<CSIL xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="FACE_CSIL_V1.xsd"
UoP-Conformance="2014-06-05"
UoP-ID="TrackCorrelator"
UoP-Version="3.0a">
<ContainerID name="MyStuff">
<CSID name="all">
<CPID name="InPrecision"/>
<CPID name="OutPrecision"/>
</CSID>
</ContainerID>
<ContainerID name="C:\FACE\NavigationComponent\Config\Mypdi.pdi">
<CSID name="compact">
<CPID name="InPrecision"/>

</CSID>
</ContainerID>
</CSIL>
8.3.3.2.2 Non-Configurable Component (Empty) CSIL Example
In the case of a non-configurable component, the document is empty except for the CSIL open
tag, required attributes, and close tag. A CSIL describing a non-configurable component is
shown below:
<CSIL xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="FACE_CSIL_V1.xsd"
UoP-Conformance="2014-06-05"
UoP-ID="TrackCorrelator"
UoP-Version="3.0a">
</CSIL>
8.3.4 Configuration Set Encoding Package

The Configuration Set Encoding Package (CSEP) is the documented approach of converting
configuration parameters into a component’s encoded format for deployment. The CSEP
consists of a document identifying the transformation process, any necessary tools to facilitate
the process, and example input and output files.
The documented process for transforming the artifacts into the component encoded format is
necessary for all components. The documented process must include sufficient detail for the
Avionics Supplier/System Integrator to create configuration files to be consumed by the
component. If the process requires tool(s), platform-independent tool(s) must be provided.
Example input (CCS and CSIL) and corresponding output file(s) must accompany the CSEP to
assist the System Integrator in validating that the process is being executed correctly.
8.3.5 Configuration Services API

The IDL description of the Configuration Services API is provided in Section C.2. The services
provided by the Configuration Services API closely mimic the operating system’s file API and
behaviors in an effort to mitigate the impact of replacing the OS system calls. For example,
variants of the open() OS call (e.g., fopen(), mqopen()) would be replaced by Open(CONFIG).
Initialize(CONFIG) is an optional call that prepares the Configuration Services for use by the
component. See Section C.3 for a full description of the parameters, return codes, and behaviors.
Open(CONFIG) establishes a session with the Configuration Services implementation. The

component passes in the container name and a handle is returned for future access using services
such as Read(CONFIG), Seek(CONFIG), and Close(CONFIG). See Section C.4 for a full
description of the call parameters, return codes, and behaviors.
Read(CONFIG) retrieves configuration information. A particular data set from the container is
specified through the set_name parameter. See Section C.5 for a full description of the
parameters, return codes, and behaviors.
Seek(CONFIG) determines where data should be read from by specifying an origin and offset. It
supports stream and file access in implementations using variants of the OS call to seek() (e.g.,
fseek(), lseek()). Seek(CONFIG) may not be meaningful for a particular target system encoding.
See Section C.6 for a full description of the parameters, return codes, and behaviors.
Close(CONFIG) is used at the conclusion of configuration operations to clean up resources no

longer needed. See Section C.7 for a full description of the parameters, return codes, and
behaviors.
The Open(CONFIG) API has an input parameter container_name used by the Configuration
Library to identify the desired configuration data resource. The API’s container_name parameter
is a unique identifier allowing the library to unambiguously resolve the configuration data
resource; be it a file, database, or any other media as determined by the Avionics
Supplier/System Integrator. Some possible options for identifying a configuration data resource
through container_name are:
1. Using the actual name of a configuration path and file for the library to directly access the
named file
2. Using the supplied path and filename as an indirect mapping to a differently named or
located resource
3. Using a string such as “MyStuff” which the library would resolve to access the
appropriate configuration resource
The container_name parameter to the Open(CONFIG) service refers to the storage of the
configuration data as depicted in Figure 64. Access to the configuration data container is in

contrast to accessing the configuration data itself, which is achieved by specifying the set_name
in the Read(CONFIG) service.
FACE::Configuration::Open( …, container_name, …) FACE::Configuration::Read( …, set_name, …)
Container
Parameter Value
{File,
Database,
Parameter Value
Etc.}
Parameter Value
Parameter Value
Figure 64: Configuration Data Container
The Read(CONFIG) service has an input parameter set_name specifying the desired set of
encoded configuration data items and their assigned values. A configuration entity is composed
of a named parameter (CPID) and an assigned value. The configuration entity could be used
alone or in a group of configuration entities. The configuration entity is encoded in the format of
the configurable component. The set_name parameter is used to identify the desired
configuration entity. The set_name parameter may not directly address the configuration entity,
which is similar to the container_name parameter of the Open(CONFIG) service. In both the
Open(CONFIG) and Read(CONFIG) services, the Configuration Library maps the input
parameters to the desired container and configuration entity.
9 Language Run-Time Guidance
9.1 Introduction
Components are designated as portable when they can be redeployed on different computing
hardware and/or FACE software environments without technically requiring more than a
recompilation of the component and a re-linking of software libraries, language run-times,
and/or frameworks.
A language run-time is an executable object code library used by a compiler (and linker) to
implement features and capabilities of a software programming language such as C, C++, Ada,
or Java. If a non-standard run-time is selected, it must be included in a UoP. If a FACE
recognized standard run-time is selected, it may be included within the UoP, or it may reside in a
software library the UoP is linked against, as shown in Figure 65.
FACE Portable Components Segment
Standard Non-stAndard Non-standard Standard

Run-time-based Run-time-based Framework-based Framework-based
Mission-level Mission-level Mission-level Mission-level

Capability Capability Capability Capability
Non-standard Non-standard
Programming Application
Language Run-time Framework
RT OS OS OS OS FW
Portability between
Interfaces Interfaces Interfaces
the Run-time and the Interfaces Interfaces Interfaces
Operating System
Interface
Standard Standard
Portability Operating System Portability
Programming Application
between the between the
Language Run-time Framework
Component and Component and
the Run-time Operating System Segment the Framework
Figure 65: Language Run-Time Options
Language run-times generally consist of two interfaces, explicit and implicit:

 Explicit interfaces are defined as part of a programming language standard and invoked
directly by a component.

Example: C: Math library for Sin() Cos().
 Implicit interfaces are known and invoked by the compiler in order to implement specific
language features or to abstract common differences in capabilities supported across a
processor family. The implicit interfaces are usually unique to each compiler.
Example: Internally generated calls to compiler built-in functions simplifying code
conversion or math operation not necessarily supported by the hardware such as a long
floating operation.
9.2 Compiler Tools

A FACE OSS implementation has dependencies on the vendor-supplied compilation and system
build tools. These compiler and system build tools generally are coupled to specific language
run-times. Using compilation tools with a different language run-time may not be feasible. This
may require the language run-time to be coupled within the FACE UoP.
If moving a component from one FACE OS to another, the component should be compiled using
system build tools for the target FACE OS.
Source code developed to a strict programming language definition should be able to be

compiled by multiple compilers without changing the source code. Using programming language
extensions (permitted by programming language standards) decreases the possibility of
successful recompilation due to unique vendor extension capabilities. Using a language
framework (e.g., Ada Ravenscar profile, Embedded C++) tends to make a component more
portable across different compilers.
9.3 Additional Considerations

Commercially available language run-times may not be FACE conformant (i.e., may have
dependencies on interfaces not included in the FACE Technical Standard). Language run-times
that are not FACE conformant need to be combined with a FACE conformant interface
component in a UoP so all external interfaces are FACE conformant.
Using a FACE recognized standard run-time may increase the flexibility to manage
obsolescence, but may require optimization in performance efforts to mitigate integration risks.
Integration of the run-times and OS can be beneficial as the integration risks have already been
eliminated and may include optimizations that improve performance, but may limit portability.
The language run-time may include language features that compete with features in the FACE
conformant OS (e.g., threading model). These features may have different operational
assumptions (e.g., when and how a thread is initially started) than the same feature in the FACE
conformant OS.
Language run-times are typically used to support a General-Purpose Profile environment. For
the Security and Safety Profiles, assurance activities and/or qualification concerns may restrict
the language features that can be used and/or supported. Many language run-times completely
implement an entire programming language standard. In these cases, the supported programming
language syntax is sufficiently complete that APIs from a FACE OSS do not have to be invoked
in order for the component to perform its intended function. These components are portable to
OSSs with the same level of language support.
The language run-time may require features that cannot be implemented by using the interfaces
defined in a FACE OS environment.
A no-run-time solution is not always a good solution. It may provide too few language features
or result in excessive object code that complicates structural coverage verification activities.

10 Safety Guidance
A formal safety program may require Configuration Management (CM) of all software lifecycle
artifacts including requirements, design, code, test reports, and supporting documents. This
requirement is driven by the Airworthiness Authority. Safety is assessed at the system level.
Safety certifications are not given to FACE components, services, UoPs, or packages. The
cognizant Airworthiness Authority should be involved during all stages of safety-critical
software development and test.
The design assurance level of the OSS must be equal to or greater than the highest design
assurance level required by the system. Any component in a safety-critical partition should have
artifacts for certification at the level of the partition. FACE components use APIs defined in the
FACE Safety Profile to support system-level safety requirements.
The FACE Safety Profile, as described in the FACE Technical Standard, Section 2.8.2, is a
constrained subset of the FACE General-Purpose Profile. Specific details on the APIs and other
restrictions imposed by the FACE Safety Profile are provided in the FACE Technical Standard,
Appendix A.
The FACE Safety Profile is defined for all the FACE segments: OSS, IOS, PSSS, TSS, and PCS.
For each of the segments, the Safety Profile limits the set of APIs necessary in developing
safety-related software components.
Refer to Appendix F for additional safety guidance considerations.
11 Security Guidance
The following sections include guidance, clarification and examples of security considerations
associated with implementing the FACE Technical Standard. While this information is targeted
to all the security stakeholders, it is not intended to address all potential conformant FACE
implementations of the Security Profile.
This guidance may be supplemented by separate security addendum(s) provided by specific

service branches or program offices.
11.1 Introduction
Security is a core consideration in developing robust tactical avionics systems. While security
enforcing functions can span all segments of the FACE architecture, a large portion of the
critical security functions reside in the OSS and one or more high-assurance partitions per
processor core (e.g., data flow policy enforcement and time/space isolation). The FACE Security
Profile provides a minimal API subset that facilitates evaluation to a high assurance level.
While the Security Profile can provide a framework for all assurance levels, given the
restrictions of the available APIs it is intended to be used primarily for high-assurance
components that provide security enforcing functions. Other FACE Profiles may provide similar
assurance but a separate Security Profile is needed to enable systems that require a minimal API
subset for security analysis and certification purposes. For systems with lower security assurance
requirements, it is possible to use either of the other FACE Profiles as long as the associated
process and assurance requirements are satisfied.
It is also important to reiterate that conformance to the Security Profile APIs does not guarantee
a FACE software component is certifiable to any security standard. Depending on the target
assurance level and certification process for the air platform as defined by the Designated
Approving Authority (DAA), the design may not support the security requirements and
subsequently may need modifications. Additional design artifacts may be needed to achieve
certification.
While the certification process and target assurance levels will vary between air platforms, the
FACE Technical Standard provides a common architectural framework that can be leveraged to
help lower the lifecycle costs associated with security certification. While there will always be
costs associated with certifying a system for each air platform, the FACE architecture helps
minimize this by enabling software reuse and portability between platforms. Additionally, this
architecture minimizes the impact of hardware obsolescence while providing competitive
lifecycle costs without sacrificing security. Because FACE requirements do not explicitly
specify hardware components, it is the responsibility of the system integrator to ensure
appropriate hardware is used to support the security controls of the composed system including
partitions, if any.

11.1.1 Basic Security
The FACE Security Profile is focused on security-relevant software components targeted for
high-assurance designs. However, all software components in a secure system should meet a
basic level of security assurance unless they can be explicitly shown to not interfere with or
compromise the correct operation of system security. The following is a minimum set of data
that should be generated for each software component that may support or contribute to the
system security. Since one of the primary goals of the FACE Technical Standard is to enable
portability of software between computing platforms, the following items should be applied to
all profiles if they are to be reused in a secure environment:
 Functional requirements associated with the software component
 Description of all data flows into and out of the software component
 Description of the computing resources required for the software component to operate
 Description of design and test artifacts for the software component
 Description of software component development history
11.2 Security Architecture

Security is not an afterthought. Failure to understand and define the security functions of a
system will lead to a wide range of issues that may pose significant if not impossible barriers to
security certification. While the specifics will vary between implementations, documenting the
security architecture for each security function is a critical process step common for all secure
systems.
As per the FACE Technical Standard, the FACE Security Profile provides a wide range of
security enabling functions and attributes. These functions and attributes provide support for
implementations of single and multi-level security functions, protecting data in process, transit,
and at rest, isolation, failure recovery and reporting, and trusted information flows while
guaranteeing non-interference between the portable software components and the operating
environment and external interfaces. To reinforce a statement from the FACE Technical
Standard, these enablers do not in themselves satisfy the system-level characteristics of
Confidentiality, Integrity, and Availability. However, they do provide the necessary framework
to achieve these.
A large volume of guidance can be found in published security documents and is not repeated
herein. As stated previously, the Security Profile APIs do not inherently make a secure system;
additional data and context must be provided. The following list provides some examples of
high-level questions that should be answered and captured as design artifacts when
implementing a secure system.
Procurement Representative Questions
 What are the system functional requirements?

 What are the target controls and assurance level for the system?
 What are the certification requirements?
 Who is the DAA?
 Who is the certification authority?
Security-Relevant Portable Component Developer Questions
 What are the functional requirements associated with the software component?
 What security functions does the software component provide?
 What are the data flows into and out of the software component?
 What protections are provided for data at rest and data in transit?
 What computing resources does your software component need to operate?
 What design and test artifacts are required for the software component?
System Integrator Questions
 How are system requirements satisfied?

 What are the different security enclaves and associated data classifications?
 What are the policy rules for the data flows between enclaves?
 What are the threats and associated risks for the target assurance levels?
 What protections and mitigation strategies are employed to address these threats?
 What protections are provided for data at rest and data in transit?
 Is there any critical technology or information that requires protection?
 How is the trusted computing environment established, verified, and maintained?
 Who are the users and associated roles with access to the system and how are they
identified and authenticated?
 What design and test artifacts are available for the system?
11.3 Process
The intent of this section is to brief the reader on the various security processes that may be
required during the development, certification, and validation of software applications. For
systems intended for high-assurance use, various laws and regulations define the security
requirements that must be met. The documents referenced below provide an understanding of the
typical requirements associated with the development, certification, and accreditation of systems
and should be reviewed in that context.

The Clinger-Cohen Act of 1996 defines National Security Systems (NSS) as information
systems operated by the US Government.
The Federal Information Security Management Act (FISMA) of 2002 provides a comprehensive
framework for ensuring the effectiveness of information security controls, requires Information
Assurance (IA) oversight by the Secretary of Defense and the Director of National Intelligence,
and authorizes NIST and the NSA to issue guidance, including mandatory requirements for US
Government information systems.
Department of Defense Instruction (DoDI) 8500.1 establishes the DoD IA program.
NSTISSP No. 11 requires that acquisition, evaluation/validation of Commercial Off-The-Shelf

(COTS) IA and IA-enabled IT to be used on NSS is limited only to those which have been
evaluated and validated in accordance with the criteria, schemes, or programs specified in one
of:
 The International Common Criteria for Information Security Technology Evaluation
Mutual Recognition Arrangement
 The NSA/NIST National Information Assurance Partnership (NIAP) Evaluation and
Validation Program
 The NIST Federal Information Processing Standard (FIPS) validation program
11.3.1 Risk Management

Security Risk Management is the responsibility of each Aircraft Platform Program Security team
whether IA/AT or Program Office Protection Lead to use the applicable risk tool to address
risk/issues and opportunities which cover security-specific topics. Each OEM will have the
responsibility to analyze the subsystem architecture design with the Aircraft Platform System
Architecture and Security Engineering team.
11.3.2 Software Assurance

Security Assurance (SwA) relies upon the quality of the system. This section addresses
assurance for FACE software components that implement security functions, but is useful
reference data for all software development efforts. The CNSS 4009 IA Glossary defines SwA
as: “the level of confidence that software is free from vulnerabilities, either intentionally
designed into the software or accidentally inserted at any time during its lifecycle, and that the
software functions in the intended manner”. Software assurance is attained through a
combination of activities performed during development, procurement, implementation,
verification, test, and maintenance.
Software assurance of FACE components will be a part of the overall system security assurance.
As systems are integrated, components and FACE UoPs are assembled onto platforms that
comply with the FACE Technical Standard. These integrated systems are subject to security
certification processes as outlined in the next section. The system-level controls, and the
acquisition policies that drive them, create requirements for the system that ultimately flow to
the software components.
The source for system-level controls, and the rationale behind their elaboration into security
requirements for software components, are derived from the threats, information classifications,
and anticipated vulnerabilities for a system. These controls and requirements provide the
foundation for SwA.
The processes governing approval of systems for use in security-sensitive environments not only
specify security requirements (that can be addressed by the FACE software components), but
they also specify verification of those requirements so that SwA is achieved with confidence.
Figure 66 shows the flow of requirements from the high level (DoDI 8500.2 security controls) to
software components under one of two different paradigms – Common Criteria or Defense
Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs).
Requirements flow from the top-level IA controls to requirements specified in either Common
Criteria Protection Profiles (PPs) or Security Requirements Guides (SRGs). Though some
Common Criteria PPs were discontinued by the NSA, they are still good reference documents to
utilize as a foundation for IA requirements flow down. Those requirements are further elaborated
for specific products through the STIGs. The implementation of products is then verified against
the requirements, and a package of verification data and reports is created that attests to the
satisfaction of the security requirements.
Figure 66: Software Assurance Security Requirements Flow
Figure 67 shows a specific example of the elaboration of IA controls to security requirements

using the DISA STIG paradigm.

Figure 67: Security Requirement Elaboration Example
Platform IA controls may be addressed by FACE components spanning multiple segment layers.
The elaboration of a specific control would then create security requirements in one or more
PP/SRG as well as one or more FACE components. When security evaluators determine whether
a given control is satisfied, they would then use the aggregation of evidence provided by each of
the components to satisfy the control requirements mapping.1
11.4 Certification2
11.4.1 Methodology
For systems intended for use by the US government, various regulations define the IA
accreditation requirements that should be met. The following methodology is a specific example,
but it is not intended to reflect the only methodology that the FACE Technical Standard
supports. A specific system developed for a specific customer may have different requirements
than these.
Within the FACE Security Profile it is key to identify what items are needed for DoD
certification of IA systems across all branches. A critical starting point is the identification of the
Mission Assurance Category (MAC), Confidentiality Level (CL), which is in accordance with
the DoDI 8500.2 and identifies all IA Controls appropriate to the MAC and CL. The Program
Protection Plan (PPP) is a living-document incorporating security requirements created and
maintained at the platform level by Program Office Protection Lead (POPL) and not at the
FACE level.
1
The SwA Pocket Guide Series is available from the Department of Homeland Security (DHS): Build Security In
(https://buildsecurityin.us-cert.gov).
2
In this context, “Certification” refers to security certification to distinguish it from FACE certification mentioned elsewhere.
11.4.2 Certification Example
The intent of this section is to brief the reader on the various security processes that may be
required during the development, certification, and validation of software applications.
In accordance with Naval Air Systems Command (NAVAIR) Instruction 4355.19D, all
NAVAIR and Aviation Program Executive Officer (PEO) programs involved with the design,
development, test and evaluation, certification, acquisition, and in-service support are required to
follow the Systems Engineering Technical Review (SETR) Process.
Figure 68 illustrates the SETR and DIACAP process.
DIACAP Alignment & Activities
DODI 5000.02
MS-A MS-B MS-C
Concept Technology System Production & Operations &
Refinement Development Development Deployment Support
&
Demostration
SRR SFR PDR CDR OTRR FRP DR KEY:
ATO = Authority To Operate
IATT IATO ATO CDR = Critical Design Review
DR = Decision Review
FRP = Full Rate Production
IATO = Interim Authority To Operate
IATT = Interim Authority To Test
DIACAP MS = Milestone
OTRR = Operational Test Readiness
Review
Implement & Certify & Maintain & PDR = Preliminary Design Review
Concept Ref
Validate Accredit Conduct SFR = System Functional Review
Initiate & Plan SRR = System Readiness Review
Reviews
Registration; Make C&A Maintain

Execute Plan;
IA Control Determination; Awareness;
Validate Controls;
Assignment; Issue Decision Annual
Compile Results;
Assemble Team; Reviews;
DIACAP Implementation
SIP; Maintain
Plan, Certification
Initiate DIACAP Posture
Documentation, DIACAP
Implementation
Scorecard
Plan
Figure 68: DIACAP Alignment and Activities
11.5 Example Scenario

The following example is based on Scenario B from the NSA SSE-100-1 (see Referenced
Documents). This document is used to illustrate the security implications of the FACE Profiles
against a publically available document. It is recommended that NSA SSE-100-1 be referenced
for further details not provided in the sections below.
NSA SSE-100-1 describes four operational scenarios utilizing a separation kernel-based RTOS
and IA guidance for security-critical functions. For the purposes of our FACE implementation
discussion, we have elected to only present one of the four given the potential applicability to
avionics platforms. Scenario B is utilized because it describes an embedded system with multiple
processors such as an airborne system with limited network connectivity. The system is
comprised of four processors operating on a partitioned RTOS and show the horizontal

communication between each partition. The partitions are operating from a single domain to
multiple domains requiring varying levels of Robustness from Basic to High. The components
for which High Robustness is recommended are all components where a failure within that
component alone could result in the compromise of classified data (a breach in confidentiality).
High Robustness is appropriate for this scenario because the highest classification of the data is
identified as Top Secret and restricts user access in the system.
11.5.1 Scenario B
The example system provides Top Secret cleared users with fused situational awareness using
data from within the system and from external input. The system is comprised of four
independent processors each utilizing a partitioned RTOS and communicating via a COTS
Ethernet switch. The RTOS instance provides partitions supporting both single domain and
multiple-domains with varying levels of Robustness from Basic to High, as shown in Figure 69.
Basic to High Robustness for these components would require partition isolation and
information flow control between partitions on a processor, with the necessary monitoring
controls to prevent failures that result in Top Secret data being available to unclassified users.
Within Scenario B the cross-domain guard (identified in partition 1B) should achieve High
Robustness.
Figure 69: Scenario B Component Robustness Levels
To reiterate, the focus of the FACE Security Profile is to address the security-critical functions
of the architecture that require High Robustness.
11.6 Encryption/Decryption
While there are many technical approaches for handling encryption/decryption, some are not
viable due to FACE architecture requirements. Specifically, data modeling is required to enable
information sharing and interoperability between FACE UoPs. This requirement prevents
opaque/encrypted data to be passed via the TSS APIs. However, there are options to satisfy
protection of Data at Rest and Data in Transit requirements.
The following are some potential implementations for encryption/decryption supported by the
FACE Technical Standard. See Figure 70 for an example of Encryption/Decryption.
Data in Transit:

 Internal TSS encryption/decryption transformation (shown in Scenario 12.4)
 Encryption/decryption interfacing with external entities:
— Ingress/egress FACE UoC (PSS/IOS) via IPSEC, SSL, SSH, SFTP, etc.
— PSS/IOS utilizing a locally accessible security engine hardware (e.g., HAIPE, Secure
Hash)
Data at Rest:
 Internal TSS encryption/decryption coupled with file I/O via the OSS
 Encryption/decryption interfacing with external entities:
— PSS/IOS interfacing with local storage device (shown in Scenario 12.4)
— PSS/IOS interfacing with locally accessible security engine hardware (e.g., DES,
Secure Hash) connected to a storage device
Partition C Partition Z Partition A Partition Z

Single Level Partition Multi-Level Partition Single Level Partition Multi-Level Partition
General Purpose Partition Security Partition General Purpose Partition Security Partition
Platform
Platform
Specific
Specific
Platform Platform
Common Common
Platform Services Services
Specific
Labeling Labeling
Platform
Information Flow Information Flow
I/O Device Portable Portable Control Policy
Control Policy
Data Module
Services Component Component
Security Security
Service
Data Control Verification User Verification
Data Logger
Manager Application
Transformation Services Transformation Services

FACE FACE FACE
FACE Transport Services Encryption/ FACE Transport Services Encryption/
I/O
Data Transport Services Lib Decryption Lib Transport Services Lib Decryption Lib
Interface
Module Lib Lib
Lib
Device
Driver
POSIX POSIX POSIX POSIX POSIX POSIX
General Purpose Profile Security Profile General Purpose Profile Security Profile
Operating System Segment – Secure Hypervisor Operating System Segment – Secure Hypervisor
Processor 1 Processor 2
Ethernet
Data Module
Switch
Figure 70: Encryption/Decryption Example
12 Implementation Scenario Examples
12.1 Communications Manager Scenario

12.1.1 Introduction
Communications Management (COMM) is the management and control system for all of the
communications equipment on-board the air platform. For the purposes of this implementation
scenario, the COMM function receives control information (i.e., frequencies, channels, presets,
keys) from the CDU and displays communications information back on the CDU. The COMM
function also manages the communications devices. This scenario begins after the Data Transfer
Device (DTD) has already been loaded onto the aircraft. This scenario excludes the pre-flight
and post-flight mission-planning activities.
12.1.2 Scope
12.1.2.1 Operational View
Figure 71: Communication Manager Operational View
The user (Pilot/Co-Pilot) interfaces with the radio by interactions with the User Interface Device.
The user is capable of changing channels, frequencies, presets, and antenna selection of the radio
using this user input device.
The user interfaces through the User Interface Device with the DTD by loading presets, and
operational configuration files. The user interfaces through the user interface device with the
data transfer device to save presets, and operational configuration files.

12.1.2.2 Functional View
We start this view from the point after the DTD has already been loaded onto the aircraft. This
excludes the pre-flight and post-flight actions.
Pilotinterfaces
Pilot uploads comm
DTD Pilot
Pilot makes in-flight
makes in-flight Pilot
Pilot saves
saves comm
comm data
data from DTD to the
comm data through changes
changes to comm
to comm data datatoback
back DTDto DTD
through
COMM Manager
the User the
Interface through User Interface
data through user the User the
through Interface
user
through User
Device Device
interface device Device
interface device
Interface Device
COMM Manager
Radio
Figure 72: Communication Manager Functional View
12.1.2.3 Physical View
Portable Components Segment 20June13
Portable Components Common Services
UHF/VHF LOS UHF VHF BLOS UIS

TS Lib TS Lib TS Lib

TS Lib TS Lib TS Lib TS Lib TS Lib TS Lib
DTD ARINC 739 Configuration System Level

UHF/VHF Pilot Controls
Manager Manager Service HMFM
Manager Manager I/O Lib
I/O Lib I/O Lib
I/O Lib I/O Lib
Platform Device Services Graphics Services Platform Common Services
I/O Services Segment I/O Lib I/O Lib I/O Lib
MIL-STD-1553 ARINC 429 Analog / Discrete

Service Service Service
OS
BSP /
Device Drivers
RTOS
Interface Hardware
(i.e. MIL-STD-1553, Ethernet)
UHF/VHF Pilot
DTD CDU
Radio Controls
Figure 73: Communication Manager Physical View
12.1.3 Assumptions
The devices that are depicted in this scenario are a DTD, Ultra High Frequency (UHF)/Very
High Frequency (VHF) Radio, Pilot Controls, and CDU. The CDU uses the ARINC 739
protocol and is connected over an ARINC 429 bus. A UHF/VHF Radio is connected over a
MIL-STD-1553 bus. The Pilot Controls use analog and discrete inputs. The DTD is connected
over Ethernet.
12.1.3.1 Profile
The software is run on a single processor in eight different partitions. The General-Purpose
Profile is being used with both ARINC 653 (APEX) partitions and POSIX partitions.
12.1.3.2 Performance
No strict real-time requirements. User Interface Service (UIS) must provide suitable human
response times.

12.1.4 Environment
12.1.4.1 Operating System (OS) Segment
12.1.4.1.1 POSIX
The OSS implements the FACE General-Purpose Profile for POSIX as defined in the FACE
Technical Standard, Section 3.11.3.
12.1.4.1.2 ARINC 653
The OSS implements the FACE General-Purpose Profile for ARINC 653 (APEX) as defined in
12.1.4.1.3 Board Support Package/Device Drivers
The OSS provides the appropriate BSP and/or device drivers for the MIL-STD-1553, ARINC
429, Ethernet, and discrete I/O interfaces.
12.1.4.2 I/O Services Segment
The IOSS provides a common interface for I/O devices using the FACE standardized API.
12.1.4.2.1 MIL-STD-1553 Service
The MIL-STD-1553 service normalizes the interface between the BSP and software
component(s) communicating with the platform device over the MIL-STD-1553 bus.
12.1.4.2.2 ARINC 429 Service
The ARINC 429 service normalizes the interface between the BSP and software component(s)
communicating with the platform device over ARINC 429.
12.1.4.2.3 Discrete Service
The Discrete service normalizes the interface between the BSP and software component(s)
requiring the discrete inputs over the corresponding discrete connections.
12.1.4.3 Platform-Specific Services Segment
The PSSS allows for platform-unique software component combinations corresponding to the
specific platforms requirements.
12.1.4.3.1 Platform-Specific Device Services
The Platform-specific Device Services (PDS) include components that provide control for,
receive data from, and send data to platform devices or external systems.
UHF/VHF Manager
 Communicates with the UHF/VHF device over the FACE I/O Interface according to the
UHF/VHF device’s ICD.
 Receives data from the other FACE components and translates the data from the FACE
Data Model into messages the UHF/VHF device can understand.
 Translates the ICD-defined data into the FACE Data Model for communication with other
FACE components:
— Provides health and status of the UHF/VHF device (Periodic Built-In Test (PBIT),
Continuous Built-In Test (CBIT), Initiated Built-In Test (IBIT)
— Provides command and control of the UHF/VHF device
Pilot Controls Manager
 Communicates with the Pilot Controls (e.g., stick, throttle, collective, cyclic) using
discrete inputs over the FACE I/O Interface.
Data Model into messages the Pilot Controls device can understand.
 Translates inputs made from the Pilot Controls device into the FACE Data Model for
communication to other software components in the FACE environment:
— Provides health and status of the Pilot Controls device (PBIT, CBIT, IBIT)
— Provides command and control of the Pilot Controls device
DTD Manager
 Communicates with the DTD using Ethernet.

Data Model into messages the DTD can understand.
 Translates inputs from the DTD into the FACE Data Model for communication to other
software components in the FACE environment:
— Provides health and status of the DTD (PBIT, CBIT, IBIT)
— Provides command and control of the DTD device
12.1.4.3.2 Platform-Specific Graphic Services
ARINC 739 Manager
 Provides a standardized interface for client software components to display text-based

information on a CDU.
 Manages the currently active subsystems.

 Controls the subsystem menu display.
 Provides subsystem fault detection.
 Provides an abstraction for non-standard ARINC 739 hardware.
12.1.4.3.3 Platform-Specific Common Services
The Platform-Specific Common Services provides common services to other FACE segments
per system requirements. The Platform-Specific Common Services support Configuration
Services and System-Level Health Monitoring for this implementation as defined in the FACE
Technical Standard, Sections 3.15 and 3.16.2, respectively.
12.1.4.4 Transport Services Segment
12.1.4.4.1 Components
In this implementation, there are no stand-alone services needed to handle the TS. The TS
Interface is instantiated within a TS Library which contains the business logic for the specific
transport mechanism. Refer to Section 12.1.4.7 for more implementation-specific details.
12.1.4.5 Portable Components Segment
The PCS is a portion of a FACE solution whose contents are entirely independent from other
FACE segments. PCS components exclusively use the TS Interface for data exchanges.
12.1.4.5.1 Common Services
The User Interface Service (UIS) is a configurable ARINC 739 client software component which
provides a service for software components to display and format information on the CDU. The
UIS communicates with the ARINC 739 Graphics Service (in PSS) using the ARINC 739
command stream over the TS Interface, as described in the FACE Technical Standard, Section
3.14.2. In addition to ARINC 739, the UIS can also communicate with other PSS Services (e.g.,
Pilot Controls Manager) to be provided user inputs from other sources. The UIS communicates
with other FACE components over the TS Interface. The actual information (e.g., menus, text
fields, options) which is displayed on the UIS is exchanged with other FACE components and is
retrieved using the FACE Configuration Services. The data configuring the display is retrieved
using FACE Configuration Services using the TS Interface and then provided to the ARINC 739
manager using the TS Interface.
12.1.4.5.2 Portable Applications
Two similar portable applications are included in the example. They could be combined into a
single UoP, but have been separated to demonstrate the potential for additional reusability. If one
of the components was useful in a future FACE environment, it could be reused without
requiring modification.
UHF/VHF Line of Sight (LOS)
The UHF/VHF Line of Sight (LOS) portable application manages frequency data, channel
information, and radio status for UHF/VHF LOS radios on the platform. It communicates with
actual radios through a UHF/VHF Manager located in PSS over the TS Interface using the
FACE Data Model. The UHF/VHF Manager provides any necessary translation between the
FACE Data Model and the specific UHF/VHF Radio ICD. The UHF/VHF LOS portable
application also provides information to be displayed by the UIS over the TS Interface.
UHF/VHF Beyond Line of Sight (BLOS)
The UHF/VHF Beyond Line of Sight (BLOS) portable application manages frequency data,
channel information, and radio status for UHF/VHF BLOS radios on the platform. It
communicates with actual radios through a UHF/VHF Manager located in PSS over the TS
Interface using the FACE Data Model. The UHF/VHF Manager provides any necessary
translation between the FACE Data Model and the specific UHF/VHF Radio ICD. The
UHF/VHF BLOS portable application also provides information to be displayed by the UIS over
the TS Interface.
12.1.4.6 I/O Interface
The I/O Interface is instantiated within an IOS library which contains the business logic for the
specific transport mechanism. This is only used between IOS and PSSS.
12.1.4.6.1 Analog/Discrete Service to Pilot Controls Manager
The Analog/Discrete I/O Service requests data from the device driver included in the BSP. The
Analog/Discrete I/O Service then sends the command to the Pilot Control Manager, which then
makes those inputs available to the rest of the FACE environment via the TS Interface using
standardized FACE data formats.
12.1.4.6.2 ARINC 429 Service to ARINC 739 Manager
The ARINC 429 I/O Service sends/receives ARINC 739 command stream data to/from the
ARINC 429 device driver included in the BSP. The ARINC 429 I/O Service then sends/receives
the data to the ARINC 739 manager, which then makes the ARINC 739 interface available to
other FACE software components over the TS Interface using the FACE Data Model.
12.1.4.6.3 MIL-STD-1553 Service to Radio Manager
The MIL-STD-1553 I/O Service sends/receives radio data, per the radio ICD, to/from the MIL-
STD-1553 device driver included in the BSP. The MIL-STD-1553 I/O Service then
sends/receives the data to the UHF/VHF Manager, which then makes the radio data available to
other FACE software components over the TS Interface using the FACE Data Model.
12.1.4.6.4 System-Level HMFM ↔ *
All services in the IOS communicate their health status to the System-Level HMFM through the
I/O Interface. Figure 73 does not show the communication lines between Configuration Services
and all other components. This was done on purpose to minimize the complexity of the diagram.
12.1.4.6.5 Configuration Services ↔ *
I/O Services are configured locally, either through direct file access or compiled in data.

12.1.4.7 TS Interface
The TS Interface is instantiated within a TS Library which contains the business logic for the
specific transport mechanism. This is only used between PCS and PSS. All data passed through
the TS Interface uses the FACE Data Model.
The source and destination for connections are used by the TS Library and are defined in the TS
Library configuration data; refer to the FACE Technical Standard, Section 3.7.
12.1.4.7.1 PSSS ↔ PCS
System-Level HMFM ↔ *
All Portable Applications, Managers, and Services in the PCS and PSSS communicate their
health status to the System-Level HMFM through the TS Interface. Figure 73 does not show the
communication lines between Configuration Services and all other components. This was done
on purpose to minimize complexity of the diagram.
Configuration Services ↔ *
All Portable Applications, Managers, and Services in the PCS and PSSS receive configuration
data from Configuration Services through the TS Interface. Figure 73 does not show the
on purpose to minimize the complexity of the diagram.
DTD Manager ↔ UHF/VHF LOS
The UHF/VHF LOS component communicates with the DTD Manager to send/receive preset
data, frequency data, and radio data to be written to and/or read from the DTD using the TS
Interface. The DTD Manager then communicates the data directly to the DTD using the OS
Interface (Ethernet).
DTD Manager ↔ UHF/VHF BLOS
The UHF/VHF BLOS component communicates with the DTD Manager to send/receive preset
data, frequency data, and radio data to be written to and/or read from to the DTD using the TS
Interface. The DTD Manager then communicates the data directly to the DTD using the OS
Interface (Ethernet).
UHF/VHF Manager ↔ UHF/VHF LOS
The UHF/VHF LOS component sends/receives frequency data, channel information, and radio
status to/from the UHF/VHF Manager through the TS Interface.
UHF/VHF Manager ↔ UHF/VHF BLOS
The VHF/UHF BLOS component sends/receives frequency data, channel information, and radio
status to/from the UHF/VHF Manager through the TS Interface.
Pilot Controls Manager → UIS
The UIS component receives information about Pilot Controls inputs from the Pilot Controls
Manager through the TS Interface. These Pilot Controls inputs are used to perform actions which
are available through the CDU user interface, such as selecting a radio preset.
ARINC 739 Manager ↔ UIS
The UIS component communicates with the ARINC 739 using an ARINC 739 command stream
over the TS Interface.
12.1.4.7.2 PCS ↔ PCS
UIS ↔ UHF/VHF BLOS
The UIS common service communicates with the UHF/VHF BLOS portable application to
send/receive radio configuration data, frequency data, and preset data through the TS Interface.
This data is sent to the UHF/VHF BLOS portable application from the UIS common service
when a user input is made on the CDU or Pilot Controls. This data is sent from the UHF/VHF
BLOS portable application to the UIS common service in order to populate the CDU with
accurate UHF/VHF BLOS information.
UIS ↔ UHF/VHF LOS
The UIS common service communicates with the UHF/VHF LOS portable application to
send/receive radio configuration data, frequency data, and preset data through the TS Interface.
This data is sent to the UHF/VHF LOS portable application from the UIS common service when
a user input is made on the CDU or Pilot Controls. This data is sent from the UHF/VHF LOS
portable application to the UIS common service in order to populate the CDU with accurate
UHF/VHF LOS information.

12.1.4.8 Notional Partition View
Partition 0 Partition 1 Partition 2 Partition 3 Partition 4 Partition 5 Partition 6 Partition 7
Portable
Component
Portable
Portable
ARINC 429 Component Graphics
Platform Service Platform Platform Components Platform
Services
Common Device Device UHF/VHF Device
MIL-STD-1553
Common LOS
Services Services Services Services
Service Services
UHF/VHF
System Level DTD UHF/VHF ARINC 739 Configuration
Analog / Discrete BLOS
HMFM Manager UIS Manager Manager Services
Service
FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE
Transport I/O I/O Transport I/O Transport Transport I/O Transport Transport I/O Transport I/O
Services Interface Interface Services Interface Services Services Interface Services Services Interface Services Interface
Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib
Device
Driver APEX
SP/QP
APEX APEX APEX APEX APEX APEX APEX
and
POSIX
Processor 0
Comm Device Partitioned FACE Environment 20June13
Figure 74: Communications Manager Partition View
12.2 Digital Map Manager Scenario

12.2.1 Introduction
The Digital Map (DigMap) is an application that provides a digital image of a map or terrain at a
given position. It is used by the pilot for Situational Awareness (SA). For the purposes of this
implementation, the DigMap application receives Digital Terrain Elevation Data (DTED) data
and Navigation Data (i.e., Altitude, Heading, Airspeed, Lat/Long) and provides a digital map
image on the CDS. This scenario begins after the DTD has already been loaded onto the aircraft.
This excludes the pre-flight and post-flight actions.
12.2.2 Scope
Data Transfer
Pilot / Co-Pilot
Device
Changes configuration (map and waypoint data of the Pre-flight: loads configuration (map and waypoint data
avionics systems) using the User Interface device of the avionics systems) onto the DTD
User Interface
Device
Pilot / Co-Pilot
Figure 75: Digital Map Operational View
The user (Pilot/Co-Pilot) interfaces with the EGI by interactions with the User Interface Device.
The user is capable of changing EGI operational configuration and source selection using this
user input device.
The user (Pilot/Co-Pilot) interfaces with the Air Data Computer by interactions with the User
Interface Device. The user is capable of changing Air Data Computer operational configuration
and source selection using this user input device.
The user (Pilot/Co-Pilot) interfaces with the VHF Omni-directional Radio-Range

(VOR)/Distance Measuring Equipment (DME)/Instrument Landing System (ILS) by interactions
with the User Interface Device. The user is capable of changing VOR/DME/ILS operational
configuration data and source, channel, and frequency selection using this user input device.
The user (Pilot/Co-Pilot) interfaces with the Tactical Air Navigation (TACAN) by interactions
with the User Interface Device. The user is capable of changing TACAN operational
configuration data and source, channel, and frequency selection using this user input device.
The user (Pilot/Co-Pilot) interfaces with the Radar Altimeter by interactions with the User
Interface Device. The user is capable of changing Radar Altimeter operational configuration data
and source, channel, and frequency selection using this user input device.
The user (Pilot/Co-Pilot) interfaces through the User Interface Device with the DTD by loading
presets, and configuration files. The user interfaces through the user interface device with the
data transfer device to save presets, and operational configuration files.
The user (Pilot/Co-Pilot) controls overlays, digital map source, map type, and configuration
through the bezels on the display.

We start this view from the point after the DTD has already been loaded onto the aircraft. This
excludes the pre-flight and post-flight actions.
Pilot interfaces DTD Pilot makes in-flight Pilot saves avionics

avionics system data changes to avionics system data back to
through the User system data through DTD through the user
Interface Device user interface device interface device
Figure 76: Digital Map Functional View

Common Services
Portable Components DAFIF
TS Lib
DigMap Ovrly Mgr Terrain

GPS Aiding Nav Utils UIS
TS Lib TS Lib Server
TS Lib TS Lib TS Lib TS Lib

TS Lib TS Lib
TS Lib
Air Data VOR/DME/ TACAN Configuration System Level
EGI Manager
Manager ILS Manager Manager GLX Server Services HMFM
I/O Lib I/O Lib I/O Lib I/O Lib I/O Lib I/O Lib
RadAlt DTD Bezel Graphics Services Platform Common Services

Manager Manager Manager
I/O Lib I/O Lib
Platform Device Services
I/O Services Segment I/O Lib I/O Lib

I/O Lib I/O Lib
MIL-STD-1553 ARINC 429 Serial Analog / Discrete
Service Service Service Service
OS
BSP /
Device Drivers
RTOS
Interface Hardware
(i.e. MIL-STD-1553, Ethernet)
VOR/
Air Data Radar
EGI DME/ILS TACAN DTD CDS
Computer Altimeter
Sensor
Figure 77: Digital Map Physical View
12.2.3 Assumptions
The devices that are depicted in this scenario are a CDS, an EGI, an Air Data Computer, a
VOR/DME/ILS sensor, a TACAN sensor, and a Radar Altimeter. The CDS uses the OpenGL
protocol and is connected over an Ethernet bus. Inputs from the bezels on the display are
provided over a serial service. An EGI is connected over a MIL-STD-1553 and ARINC 429 bus.
An Air Data Manager is connected over an ARINC 429 bus. Both the EGI and Air Data
Manager receive discrete inputs provided over analog connections. VOR/DME/ILS and TACAN
sensors are connected over a MIL-STD-1553 bus. A Radar Altimeter is connected over an
ARINC 429 bus.
12.2.3.1 Profile
The software is run on two processors in eleven different partitions. The empty partitions could
be used for expansion and future development.
This scenario could be implemented with the Safety Profile or the General-Purpose Profile. This
implementation assumes the General-Purpose Profile is being used with both ARINC 653
(APEX) partitions and POSIX partitions.
EGI and ILS have real-time requirements. UIS must provide suitable human response times.
12.2.4 Environment
12.2.4.1 Operating System (OS) Segment
12.2.4.1.1 POSIX
12.2.4.1.2 ARINC 653
The OSS implements the FACE General-Purpose Profile for ARINC 653 (APEX) as defined in
12.2.4.1.3 Board Support Package (BSP)/Device Drivers
429, Ethernet, and discrete I/O interfaces.
The IOSS provides a common interface for I/O devices using the standardized API.
12.2.4.2.1 MIL-STD-1553
12.2.4.2.2 ARINC 429
communicating with the platform devices over ARINC 429.

12.2.4.2.3 Serial
The Serial service normalizes the interface between the BSP and software component(s)
communicating with the platform device using the serial bus.
12.2.4.2.4 Analog/Discrete
The Analog/Discrete service normalizes the interface between the BSP and software
component(s) requiring the discrete inputs over the corresponding analog/discrete connections.
specific platform requirements.
The PDS include components that provide control for, receive data from, and send data to
platform devices or external systems.
EGI Manager
 Communicates with the EGI device over the FACE I/O Interface according to the EGI
device’s ICD
Data Model into messages the EGI device can understand
FACE components:
— Provides health and status of the EGI device (PBIT, CBIT, IBIT)
— Provides command and control of the EGI device
Air Data Manager
 Communicates with the Air Data Computer device over the FACE I/O Interface according
to the Air Data Computer device’s ICD
 Receives data from the other FACE software components and translates the data into data
formats and messages the Air Data Computer can understand
 Translates the ICD-defined data into data formats and messages that the other FACE
software components can understand:
— Provides health and status of the Air Data Computer (PBIT, CBIT, IBIT)
— Can provide command and control of the Air Data Computer and managed device
states
Radar Altimeter Manager
 Communicates with the Radar Altimeter device over the FACE I/O Interface according to
the Radar Altimeter device’s ICD
Data Model into messages the Radar Altimeter device can understand
FACE components:
— Provides health and status of the Radar Altimeter device (PBIT, CBIT, IBIT)
— Provides command and control of the Radar Altimeter device
TACAN Manager
 Communicates with the TACAN device over the FACE I/O Interface according to the
TACAN device’s ICD
Data Model into messages the TACAN device can understand
FACE components:
— Provides health and status of the TACAN device (PBIT, CBIT, IBIT)
— Provides command and control of the TACAN device
VOR/ILS/DME Manager
 Communicates with the VOR/ILS/DME device over the FACE I/O Interface according to
the VOR/ILS/DME device’s ICD
Data Model into messages the VOR/ILS/DME device can understand
FACE components:
— Provides health and status of the VOR/ILS/DME device (PBIT, CBIT, IBIT)
— Provides command and control of the VOR/ILS/DME device
DTD Manager
 Communicates with the DTD using Ethernet

Data Model into messages the DTD can understand

— Provides command and control of the DTD and managed device states
Bezel Manager
 Is the gateway to the CDS for software components

 Understands the data specifications for the platform CDS
 Provides a common interpretation of the data to software components
 Handles health and status for the CDS (PBIT, CBIT, IBIT)
 Communicates to other software components through the TS Interface
12.2.4.3.2 Platform-Specific Graphics Services
The OpenGL Extension to the X Window System (GLX) Server provides a standardized
interface for client software components to display OpenGL-based information on a CDS. The
GLX Server allows for separation of the CDS display from the PCS components. OpenGL
commands are serialized and transmitted as packets to the remote display network location.
When received by the target display manager, those commands are de-serialized and passed to
the local display drivers.
Services and System-Level Health Monitoring for this implementation as defined in the FACE
Technical Standard, Sections 3.15 and 3.16.2, respectively.
In this implementation, there are no components needed to handle the TS. The TS Interface is
instantiated within a TS Library which contains the business logic for the specific transport
mechanism. Refer to Section 12.2.4.7 for more implementation-specific details.
Digital Map
The DigMap is a portable application that renders a map to send to the GLX Server given terrain
and Global Positioning System (GPS) data as inputs.
Overlay Manager
The Overlay Manager is a portable application that provides navigation and sensor data given
terrain and GPS data as inputs.
Digital Aeronautical Flight Information File Service
The Digital Aeronautical Flight Information File (DAFIF) service provides airport and navaid
data given ownship position and inputs from the DTD Manager.
Terrain Server
The Terrain Server is a service that provides conversion utilities and processed DTED data
needed by the portable applications.
GPS Aiding Service
The GPS Aiding service provides heading and airspeed smoothing of the background GPS data
provided by the EGI. This utility receives background GPS data, heading, airspeed, altitude,
groundspeed, etc. from the PSS and creates a smoothed solution for use by other common
services or portable applications.
Navigation Utilities (Nav Utils)
The Navigation Utilities (Nav Utils) are services that provide conversion utilities, and
calculations for ownership position amongst other utilities needed by the portable applications.
User Interface Service
The User Interface Service (UIS) communicates to the DTD Manager what data is needed from
the DTD.
specific transport mechanism. This is only used between IOS and PSS.
12.2.4.6.1 MIL-STD-1553 Service to EGI, VOR/DME/ILS, and TACAN Managers
The MIL-STD-1553 I/O Service sends/receives EGI, VOR/DME/ILS, and TACAN data, per the
pertinent MIL-STD-1553 ICD, to/from the MIL-STD-1553 device driver included in the BSP.
The MIL-STD-1553 I/O Service then sends/receives the data to the respective managers, which
then make the data available to other FACE software components over the TS Interface using
the FACE Data Model. The MIL-STD-1553 Service is configured by Configuration Services to
support the devices for the given implementation.

12.2.4.6.2 ARINC 429 Service to EGI, Radar Altimeter, and Air Data Managers
The ARINC 429 I/O Service sends/receives EGI, Air Data, and Radar Altimeter data to/from the
ARINC 429 device driver included in the BSP. The ARINC 429 I/O Service then sends/receives
the data to the respective managers, which then make the data available to other FACE software
components over the TS Interface using the FACE Data Model. The ARINC 429 service is
configured by Configuration Services to support the devices for the given implementation.
12.2.4.6.3 Serial Service to Bezel Manager
The Serial connection sends the Bezel commands to the Serial I/O Service. The Serial I/O
Service then sends the command to the Bezel Manager, which then makes those inputs available
to the rest of the FACE environment via the TS Interface using the FACE Data Model. The
Serial Service is configured by Configuration Services to support the device for the given
implementation.
12.2.4.6.4 Analog/Discrete Service to EGI and Air Data Managers
The Analog/Discrete I/O Service requests data from the analog and discrete device drivers
included in the BSP. The Analog/Discrete I/O Service then sends the command to the EGI and
Air Data Managers, which then makes those inputs available to the rest of the FACE
environment via the TS Interface using the FACE Data Model. The Analog/Discrete Service is
configured by Configuration Services to support the devices for the given implementation.
I/O Interface. Figure 77 does not show the communication lines between System-Level HMFM
I/O Services are configured locally, either through direct file access or compiled in data.
Library configuration data. Please refer to the FACE Technical Standard, Section 3.7.
12.2.4.7.1 PSSS ↔ PCS
All Portable Applications, Managers, and Services in the PCS and PSSS pass health status to the
System-Level HMFM through the TS Interface. Figure 77 does not show the communication
lines between the System-Level HMFM and all other components. This was done on purpose to
minimize the complexity of the diagram.
GLX Server ↔ DigMap
The DigMap component communicates with the GLX Server using an X11 Byte Stream over the
TS Interface.
GLX Server ↔ Overlay Manager
The Overlay Manager component communicates with the GLX Server using an X11 Byte
Stream over the TS Interface.
TACAN Manager ↔ Navigation Utilities
The Navigation Utilities component communicates information about TACAN inputs to/from
the TACAN Manager through the TS Interface.
Bezel Manager → Overlay Manager
The Overlay Manager component receives information about bezel inputs from the Bezel
Manager through the TS Interface.
VOR/DME/ILS Manager ↔ Navigation Utilities
The Navigation Utilities component communicates information about VOR/DME/ILS inputs

to/from the VOR/DME/ILS Manager through the TS Interface.
DTD Manager ↔ UIS
The UIS component communicates with the DTD Manager to send/receive data to be written to
and/or read from the DTD using the TS Interface. The DTD Manager then communicates the
data directly to the DTD using the OS Interface (Ethernet).
DTD Manager ↔ DAFIF
The DAFIF component communicates with the DTD Manager to send/receive data to be written
to and/or read from the DTD using the TS Interface. The DTD Manager then communicates the
data directly to the DTD using the OS Interface (Ethernet).
DTD Manager ↔ Terrain Server
The Terrain Server component communicates with the DTD Manager to send/receive data to be
written to and/or read from the DTD using the TS Interface. The DTD Manager then
communicates the data directly to the DTD using the OS Interface (Ethernet).

DTD Manager → DigMap
The DigMap component receives data from the DTD Manager to render data to send to the GLX
Server using the TS Interface.
Air Data Manager → Terrain Server
The Terrain Server component receives airspeed and altitude data from the Air Data Manager
using the TS Interface.
Air Data Manager → Navigation Utilities
The Navigation Utilities component receives airspeed and altitude data from the Air Data
Manager using the TS Interface.
Radar Altimeter Manager → Terrain Server
The Terrain Server component receives height above terrain data from the Radar Altimeter
Radar Altimeter Manager → Navigation Utilities
The Navigation Utilities component receives height above terrain data from the Radar Altimeter
EGI Manager → Terrain Server
The Terrain Server component receives navigation data from the EGI Manager using the TS
Interface.
EGI Manager → Navigation Utilities
The Navigation Utilities component receives navigation data from the EGI Manager using the
TS Interface.
EGI Manager → GPS Aiding
The GPS Aiding component receives navigation data from the EGI Manager using the TS
Interface.
12.2.4.7.2 PCS ↔ PCS
Terrain Server → DigMap
The DigMap component receives terrain data from the Terrain Server component using the TS
Interface.
GPS Aiding → Terrain Server
The Terrain Server component receives navigation data from the GPS Aiding component using
the TS Interface.
Terrain Server → Overlay Manager
The Overlay Manager component receives terrain data from the Terrain Server component using
the TS Interface.
GPS Aiding → DigMap
The DigMap component receives navigation data from the GPS Aiding component using the TS
Interface.
GPS Aiding → Navigation Utilities
The Navigation Utilities component receives navigation data from the GPS Aiding component
DAFIF → Navigation Utilities
The Navigation Utilities component receives navaid data from the DAFIF component using the
TS Interface.

Platform
Device
Services
Portable Portable
Serial Service TACAN
Manager Component Component
Analog/Discrete VOR/DME/ Common

Service ILS Manager Portable Platform Services Platform
RadAlt Components Common Device
ARINC 429
Manager Services Nav Utils Services
Service
Air Data Overlay
System Level
MIL-STD-1553 Manager GPS Aiding EGI Manager
Manager HMFM
Service
FACE FACE FACE FACE FACE FACE FACE FACE FACE

I/O Transport I/O Transport Transport I/O Transport Transport I/O
Interface Services Interface Services Services Interface Services Services Interface
Lib Lib Lib Lib Lib Lib Lib Lib Lib
Device
Driver
APEX APEX APEX APEX APEX APEX
Processor 0
Portable
Component
Portable Common
Component Platform Services
Platform Device
Common Graphics Services DAFIF
Portable Services Services

Bezel UIS
Components Manager
DigMap Configuration DTD Terrain Server

GLX Server
Services Manager
FACE FACE FACE FACE FACE FACE FACE

FACE
Transport Transport I/O Transport I/O Transport I/O
Transport Services
Services Services Interface Services Interface Services Interface
Lib
Lib Lib Lib Lib Lib Lib Lib
APEX
APEX APEX APEX and APEX
POSIX
Processor 1
Digital Map Partitioned FACE Environment 20June13
Figure 78: Digital Map Partition View
12.3 Required Navigation Performance Manager Scenario

12.3.1 Introduction
Required Navigation Performance (RNP) is performance-based navigation that allows an aircraft
to fly a specific path between two three-dimensionally defined points in space. For the purposes
of this implementation, the RNP application receives Navigation Data (i.e., Altitude, Heading,
Airspeed, Lat/Lon), and provides a flight plan vector and navigation alerts to the pilot through a
CDS and CDU. This scenario begins after the DTD has already been loaded onto the aircraft.
This excludes the pre-flight and post-flight actions.
12.3.2 Scope
Data Transfer
Pilot/Co-Pilot
Device
Changes configuration (GPS Almanac data, flight

plans, etc. of the avionics systems) using the User Pre-flight: Loads configuration (GPS Almanac data,
Interface device flight plans, etc. of the avionics systems) onto the DTD
Post-flight: Saves configuration (GPS Almanac data,

flight plans, etc. of the avionics systems) onto the DTD
User Interface
Device
Pilot/Co-Pilot
Figure 79: Required Navigation Performance Operational View
The user (Pilot/Co-Pilot) interfaces with the EGI by interactions with the User Interface Device.
The user is capable of changing EGI configuration and source selection using this user input
device.
The user (Pilot/Co-Pilot) interfaces with the Air Data Computer by interactions with the User
Interface Device. The user is capable of changing Air Data Computer operational configuration
and source selection using this user input device.
The user (Pilot/Co-Pilot) interfaces with the VOR/DME/ILS by interactions with the User
Interface Device. The user is capable of changing VOR/DME/ILS operational configuration data
The user (Pilot/Co-Pilot) interfaces with the TACAN by interactions with the User Interface
Device. The user is capable of changing TACAN operational configuration data and source,
channel, and frequency selection using this user input device.
The user (Pilot/Co-Pilot) interfaces with the Radar Altimeter by interactions with the User
Interface Device. The user is capable of changing Radar Altimeter operational configuration data
The user (Pilot/Co-Pilot) interfaces through the User Interface Device with the DTD by loading
presets, and operational configuration files. The user interfaces through the user interface device
with the data transfer device to save presets, and configuration files.
The user (Pilot/Co-Pilot) controls overlays, digital map source, map type, and operational
configuration through the bezels on the display.

Pilot interfaces DTD Pilot makes in-flight Pilot saves avionics

avionics system data changes to avionics system data back to
through the User system data through DTD through the
Interface Device User Interface Device User Interface Device
Figure 80: Required Navigational Performance Functional View

Portable Components Common Services
Flight Plan
RNP Flight Mgmt DAFIF UIS GPS Aiding NAV Util
Utils

TS Lib TS Lib TS Lib TS Lib TS Lib TS Lib TS Lib
TS Lib TS Lib
Air Data Rad Alt VOR/DME/ILS ARINC 661 ARINC 739 Configuration System-Level
DTD Manager Manager EGI Manager Manager Manager Services HMFM
Server Server I/O Lib I/O Lib
I/O Lib I/O Lib I/O Lib I/O Lib
I/O Lib
TS Lib TS Lib
Graphics Services Platform Common Services
FCS TACAN
Manager Manager
Platform Device Services I/O Lib I/O Lib

I/O Lib I/O Lib
MIL-STD-1553 ARINC 429

Service Service
OS
BSP/Device
Drivers
RTOS
Interface Hardware
(i.e., MIL-STD-1553, Ethernet)
VOR/
Air Data Radar
FCS EGI DME/ILS TACAN DTD CDS CDU
Computer Altimeter
Sensor
Figure 81: Required Navigational Performance Physical View
12.3.3 Assumptions
The devices that are depicted in this scenario are a CDU, CDS, an EGI, an Air Data Computer, a
VOR/DME/ILS sensor, a TACAN sensor, a Radar Altimeter, and a Flight Control System
(FCS). The CDU uses the ARINC 739 protocol and is connected over an ARINC 429 bus. The
CDS uses the ARINC 661 protocol and is connected over Ethernet. An EGI is connected over a
MIL-STD-1553 and ARINC 429 bus. An Air Data Manager is connected over an ARINC 429
bus. A VOR/DME/ILS and a TACAN sensor are connected over a MIL-STD-1553 bus. A Radar
Altimeter and FCS System are connected over an ARINC 429 bus.
12.3.3.1 Profile
The software is all run on two processors in 13 different partitions. The FACE Safety Profile is
being used with both ARINC 653 (APEX) partitions and POSIX partitions.
The FCS has real-time requirements. UIS must provide suitable human response times.
12.3.4 Environment
12.3.4.1 Operating System Segment
12.3.4.1.1 POSIX
The OSS implements the FACE Safety Profile for POSIX as defined in the FACE Technical
Standard, Section 3.11.2.
12.3.4.1.2 ARINC-653
The OSS implements the FACE Safety Profile for ARINC 653 (APEX) as defined in the FACE
429 I/O, and Ethernet interfaces.
12.3.4.2.1 MIL-STD-1553 Service
12.3.4.2.2 ARINC 429 Service
communicating with the platform device over ARINC 429.

EGI Manager
The EGI manager:

 Communicates with the EGI device over the FACE I/O Interface according to the EGI
device’s ICD
Data Model into messages the EGI device can understand
FACE components:
— Provides health and status of the EGI device (PBIT, CBIT, IBIT)
— Provides command and control of the EGI device
Air Data Manager
The Air Data manager:

 Communicates with the Air Data Computer device over the FACE I/O Interface according
to the Air Data Computer device’s ICD
Data Model into messages the Air Data Computer device can understand
FACE components:
— Provides health and status of the Air Data Computer device (PBIT, CBIT, IBIT)
— Provides command and control of the Air Data Computer device
Radar Altimeter Manager
The Radar Altimeter manager:

 Communicates with the Radar Altimeter device over the FACE I/O Interface according to
the Radar Altimeter device’s ICD
Data Model into messages the Radar Altimeter device can understand
FACE components:
— Provides health and status of the Radar Altimeter device (PBIT, CBIT, IBIT)
— Provides command and control of the Radar Altimeter device
TACAN Manager
The TACAN manager:

 Communicates with the TACAN device over the FACE I/O Interface according to the
Data Model into messages the TACAN device can understand
FACE components:
— Provides health and status of the TACAN device (PBIT, CBIT, IBIT)
— Provides command and control of the TACAN device
VOR/ILS/DME Manager
The VOR/ILS/DME manager:

 Communicates with the VOR/ILS/DME device over the FACE I/O Interface according to
the VOR/ILS/DME device’s ICD
Data Model into messages the VOR/ILS/DME device can understand
FACE components:
— Provides health and status of the VOR/ILS/DME device (PBIT, CBIT, IBIT)
— Provides command and control of the VOR/ILS/DME device
Flight Control System Manager
The Flight Control System (FCS) manager:

 Communicates with the FCS device over the FACE I/O Interface according to the
Data Model into messages the FCS device can understand
FACE components:
— Provides health and status of the FCS device (PBIT, CBIT, IBIT)
— Provides command and control of the FCS device

DTD Manager
The DTD manager:

 Communicates with the DTD using discrete inputs over the FACE I/O Interface
Data Model into messages the DTD can understand
— Provides command and control of the DTD device
12.3.4.3.2 Platform-Specific Graphics Services
ARINC 739 Manager
The ARINC 739 manager:

 Provides a standardized interface for client software components to display text based info
on a CDU
 Manages the currently active subsystems
 Controls the subsystem menu display
 Provides subsystem fault detection
 Provides an abstraction for non-standard ARINC 739 hardware
ARINC 661 Manager
The ARINC 661 manager:

 Provides a standardized interface for client software components to display graphic info
on an CDS
 Manages the currently active subsystems
 Controls the subsystem display
 Provides subsystem fault detection
 Provides an abstraction for non-standard ARINC 661 hardware
Services, Logging, DPM Services, Streaming Media Services, and System-Level Health
Monitoring as defined in the FACE Technical Standard, Sections 3.15, 3.5.3.1, 3.5.3.2, 3.5.3.3,
and 3.16.2, respectively.
In this implementation, there are no stand-alone services needed to handle the TS. The TS
Interface is instantiated within a TS Library which contains the business logic for the specific
transport mechanism. Refer to Section 12.3.4.7 for more implementation-specific details.
Required Navigation Performance Manager
The Required Navigation Performance (RNP) Manager is a portable application designed to

calculate the changes needed for the FCS to fly a specific path given current control system,
GPS, flight plan, and navigation data as inputs. The RNP Manager provides data to the FCS
Manager to control the aircraft and to the UIS to be displayed.
Flight Management
The Flight Management is a portable application designed to manage the flight plan and provide
output to the UIS to be displayed given flight plan data as input.
DAFIF Service
The DAFIF Service provides airport and navaid data given ownership position and inputs from
the DTD Manager.
User Interface Service
The UIS is a configurable ARINC 739 client software component which provides a service for
capability-based software components to display and format information on MCDU displays.
The UIS communicates with a ARINC 739 Graphics Service (in PSS) using the an ARINC 739
command stream over the TS Interface, as described in the FACE Technical Standard, Section
3.14.2. The UIS also communicates to the DTD Manager what data is needed from the DTD.
The UIS communicates with other FACE components over the TS Interface using the FACE
Data Model. The actual information (e.g., menus, text fields, options) which is displayed on the
CDU and the associated name/value pairs which are exchanged with other FACE components
are fully configurable, and are stored/retrieved using the FACE Configuration Services.

Flight Planning Utilities
The flight planning utilities are services that provide conversion utilities and generated flight
plans amongst other utilities needed by the portable applications.
GPS Aiding
The GPS Aiding service provides heading and airspeed smoothing of the background GPS data
provided by the EGI. This utility receives background GPS data, heading, airspeed, altitude,
groundspeed, etc. from the PSS and creates a smoothed solution for use by other common
services or portable applications.
Navigation Utilities (Nav Utils)
The Navigation Utilities are services that provide conversion utilities, and calculations for
ownership position amongst other utilities needed by the portable applications.
specific transport mechanism. This is only used between IOS and PSS.
12.3.4.6.1 MIL-STD-1553 Service to EGI, VOR/DME/ILS, and TACAN Managers
The MIL-STD-1553 I/O Service sends/receives EGI, VOR/DME/ILS, and TACAN data, per the
specific ICDs, to/from the MIL-STD-1553 device driver included in the BSP. The MIL-STD-
1553 I/O Service then sends/receives the data to the respective managers, which then make the
data available to other FACE software components over the TS Interface using the FACE Data
Model. The MIL-STD-1553 Service is configured by Configuration Services to support the
devices for the given implementation.
12.3.4.6.2 ARINC 429 Service to FCS, EGI, Radar Altimeter, Air Data, and ARINC 739 Managers
The ARINC 429 I/O Service sends/receives FCS, EGI, Radar Altimeter, Air Data, and ARINC
739 data to/from the ARINC 429 device driver included in the BSP. The ARINC 429 I/O
Service then sends/receives the data to the respective managers, which then make the data
available to other FACE software components over the TS Interface using the FACE Data
Model. The ARINC 429 service is configured by Configuration Services to support the devices
for the given implementation.
I/O Interface. Figure 81 does not show the communication lines between Configuration Services
I/O Services are configured locally.
Library configuration data. Please see the FACE Technical Standard, Section 3.7.
12.3.4.7.1 PSSS ↔ PCS
All Portable Applications, Managers, and Services in the PCS and PSSS pass health status to the
System-Level HMFM through the TS Interface. Figure 81 does not show the communication
lines between the System-Level HMFM and all other components. This was done on purpose to
minimize the complexity of the diagram.
ARINC 739 Server↔ UIS
The UIS communicates with the ARINC 739 server using an ARINC 739 command stream over
the TS Interface.
ARINC 661 Server ↔ RNP Manager
The RNP Manager communicates with the ARINC 661 server using an ARINC 611-4 command
stream over the TS Interface. The ARINC 661 server communicates directly with the GPU using
the OS Interface.
VOR/DME/ILS Manager ↔ Flight Plan Utilities
The Flight Plan Utilities component communicates information about VOR/DME/ILS inputs
to/from the VOR/DME/ILS Manager through the TS Interface.
TACAN Manager ↔ Flight Plan Utilities
The Flight Plan Utilities component communicates information about TACAN inputs to/from
the TACAN Manager through the TS Interface.

Radar Altimeter Manager → Flight Plan Utilities
The Flight Plan Utilities component receives height above terrain data from the Radar Altimeter
EGI Manager → Flight Plan Utilities
The Flight Plan Utilities component receives navigation data from the EGI Manager using the
TS Interface.
Air Data Manager → Flight Plan Utilities
The Flight Plan Utilities component receives airspeed and altitude data from the Air Data
FCS Manager ↔ RNP Manager
The RNP Manager communicates information about FCS inputs to/from the FCS Manager
through the TS Interface.
EGI Manager → GPS Aiding
The GPS Aiding component receives navigation data from the EGI Manager using the TS
Interface.
DTD Manager ↔ UIS
The UIS component communicates with the DTD Manager to send/receive data to be written to
and/or read from the DTD using the TS Interface. The DTD Manager then communicates the
data directly to the DTD.
DTD Manager ↔ DAFIF
The DAFIF component communicates with the DTD Manager to send/receive data to be written
to and/or read from the DTD using the TS Interface. The DTD Manager then communicates the
data directly to the DTD.
12.3.4.7.2 PCS ↔ PCS
DAFIF → Flight Plan Utilities
The Flight Plan Utilities component receives navaid data from the DAFIF component using the
TS Interface.
GPS Aiding → Flight Plan Utilities
The Flight Plan Utilities component receives navigation data from the GPS Aiding component
Navigation Utilities → Flight Plan Utilities
The Flight Plan Utilities component receives navigation data from the Navigation Utilities
component using the TS Interface.
Flight Plan Utilities → Flight Management
This Flight Management component receives flight plan information from the Flight Plan
Utilities component using the TS Interface.
DAFIF → RNP
The RNP component receives navaid data from the DAFIF component using the TS Interface.
Flight Plan Utilities → RNP
The RNP component receives flight plan data from the Flight Plan Utilities component using the
TS Interface.
GPS Aiding → RNP
The RNP component receives navigation data from the GPS Aiding component using the TS
Interface.
Navigation Utilities → RNP
The RNP component receives navigation data from the Navigation Utilities component using the
TS Interface.
RNP → UIS
The UIS component receives display and format information from the RNP component using the
TS Interface.
Flight Management → UIS
The UIS component receives display and format information from the Flight Management
component using the TS Interface.

Platform
Device
Services
Portable Portable
TACAN
Manager Component Component
VOR/DME/ Portable Common Graphics

ILS Manager Components Platform Services Platform
Services
RadAlt Common Device
ARINC 429
Manager Services Nav Utils Services
Service
Air Data RNP System Level ARINC 661
MIL-STD-1553 GPS Aiding EGI Manager
Manager HMFM Manager
Service
FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE
I/O Transport I/O Transport Transport I/O Transport Transport I/O Transport I/O
Interface Services Interface Services Services Interface Services Services Interface Services Interface
Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib
Device
Driver
APEX APEX APEX APEX APEX APEX APEX
Processor 0
Portable
Component
Portable Common
Component Services
Platform
Common Graphics DAFIF
Platform Platform
Portable Services Services
Device Device
Components UIS
Services Services
Flight Flight Plan
Configuration ARINC 739 DTD FCS
Management Utils
Services Manager Manager Manager
FACE FACE FACE FACE FACE FACE FACE FACE FACE FACE
Transport Transport I/O Transport I/O Transport I/O Transport Transport I/O
Services Services Interface Services Interface Services Interface Services Services Interface
Lib Lib Lib Lib Lib Lib Lib Lib Lib Lib
APEX
APEX APEX APEX and APEX APEX
POSIX
Processor 1
20June13
RNP Partitioned FACE Environment
Figure 82: Required Navigational Performance Partition View
12.4 Secure Reporting Status Scenario

12.4.1 Introduction
The following example is based on Scenario B from the NSA SSE-100-1. This document is
publically available and provides useful notional architectures and scenarios that reflect security
considerations for real time systems. While this document contains a wide range of scenarios,
the Scenario B Reporting Status example was selected to illustrate the security implications of
the FACE Profiles against an identified use-case in the public domain. It is recommended that
NSA SSE-100-1 be referenced for further details not provided in the sections below.
NSA SSE-100-1 Figure 15 (as replicated below in Figure 83) depicts a Reporting-Status use-
case where a TS User Application on Processor #2 provides basic status log information to a TS
removable memory device connected to Processor #1.
Figure 83: NSA SSE-100-1 Scenario B Reporting Status
The NSA SSE-100-1 Scenario B Reporting Status scenario reflects sending basic status log
information from the TS User Application to the Data Module (NSA SSE-100-1, Section
8.3.3.6). This scenario begins after the TS User Application has created fused/composed a TS
situational awareness picture for the user.

12.4.2 Scope
Figure 84: Secure Reporting Status Operational View
The TS User Applications provides basic status log information to the Data Module without user
inputs. The user is capable of storing a TS report on the Data Module to be extracted and
analyzed at a later time.
We start this view after the TS User Application has fused a situational awareness picture.
TS User
Pilot Application
interfaces DTD Pilot makes in-flight Pilot saves comm
creates
comm datafused/
through TS User Application
changes to comm TS report
data backstored on
to DTD
combined
the User situational
Interface creates
data TS report
through user Data Module
through the user
awareness
Devicepicture interface device interface device
Figure 85: Secure Reporting Status Functional View
Portable Components Segment Portable Components Segment

Common Services Portable Applications Common Services
Data Logger User Application Labeling Encryption

TSS Lib TSS Lib TSS Lib
TSS Lib
Platform-Specific Services
Segment
TSS Lib
TSS Lib
Information Flow
Data Control Manager Control Policy
Platform Device Services TSS Lib
Security Verification
IO
Platform Common Services
Data Module
Service
OS OS
BSP/Device
BSP/Device Drivers
Operating System Segment: Drivers Operating System Segment:
General-Purpose Profile Security Profile
RTOS RTOS
Operating System Segment:

Secure Hypervisor
Interface Hardware
(i.e,. MIL-STD-1553, Ethernet)
Ethernet Data
Switch Module
Figure 86: Secure Reporting Status Physical View
12.4.3 Assumptions
The system has reached a trusted state.
12.4.3.1 Profile
The software executes within two partitions per processor. The FACE Security Profile (POSIX)
is being used on the inter/intra-processor communications and a FACE General-Purpose Profile
(POSIX) partition is being used for the host applications.
No strict real-time requirements.

12.4.4 Environment
12.4.4.1 Operating System Segment
12.4.4.1.1 POSIX
Technical Standard, Section 3.11.3 for the single security-level partitions used for host
applications. Additionally, the OSS implements the FACE Security Profile for POSIX as defined
in the FACE Technical Standard, Section 3.11.1 for the multi-level secure partitions that perform
security enforcing and/or relevant functions.
The OSS provides the appropriate BSP and/or device drivers for the data storage device I/O, and
Ethernet interfaces.
12.4.4.2.1 Data Module Service
The Data Module service normalizes the interface between the BSP and software component(s)
communicating with the platform storage device over the data bus. While NSA SSE-100-1 is not
explicit, we are assuming the storage device is connected to the platform through a standard
serial (e.g., SATA) or other common avionics bus (e.g., MIL-STD-1553).
Data Control Manager
The Data Control Manager:

 Communicates with the Data Module Service over the FACE I/O Interface
Data Model into messages the Data Module Service can understand
FACE components:
— Provides health and status of the Data Module device (PBIT, CBIT, IBIT)
— Provides command and control of the Data Module device
per system requirements.
Information Flow Control Policy
The Information Flow Control Policy component authorizes the message flow between
applications on different partitions/devices.
Security Verification
The Security Verification component ensures the message was unaltered through the Ethernet
switch and that the data was not compromised.
The TS Interface is only instantiated within a TS Library which contains the business logic for
the specific transport mechanism. This is only used between PCS and PSS.
12.4.4.4.1 PSSS ↔ PCS
Information Flow Control Policy ↔ *
The Information Flow Control Policy component communicates with any application passing
messages between partitions/devices to receive the source and destination of any messages
through the TS Interface.
Security Verification ↔ *
The Security Verification component communicates with any application passing messages
between partitions/devices to receive message information through the TS Interface.
Data Control Manager ← *
The Data Logger component receives TS reports and basic status log information to be written to
the Data Module using the TS Interface. The Data Control Manager then communicates the data
to the Data Module Device using the I/O Interface.
12.4.4.4.2 PCS ↔ PCS
Data Logger ← *
The Data Logger component receives basic status log information from any application through
the TS Interface.

Data Logger ← User Application
The Data Logger component receives a TS Report from the User Application through the TS
Interface.
Labeling ↔ *
The Labeling component communications with any application to apply or remove labels to a
message using the TS Interface.
Encryption ↔ *
The Encryption component communicates with any application to encrypt or decrypt a message
The PCS is part of a FACE architecture whose contents are entirely independent from other
Encryption Service
The Encryption Service (ES) is a Security Verification component which provides a service for
User Application data (Data in Transit) that moves from a General-Purpose Profile partition
flowing horizontally into a Security Profile partition through a High Robustness/Secure
Hypervisor OSS Partition, and then Encrypted based on required Confidential Level.
Labeling Service
The Labeling Service (LS) is a Security Verification component which provides a service to
ensure data confidentiality and integrity is enforced through Mandatory access controls labeling.
Data Logger Service
The Data Logger Service (DLS) is a PCS component with the responsibility of time stamping
and logging User Application data received via the TS Interface from Common Services
components and transferring the Application data at specified time intervals via the TS Interface
to the PSSS Data Control Manager.
User Application
The User Application (UA) manages various types of data that have been designated to be
moved from the General-Purpose Profile partition into a Security Profile partition via the FACE
TS Interface where the ES component will execute the data encryption process.
The I/O Interface is only instantiated within an IOS library which contains the business logic for
the specific transport mechanism. This is only used between IOS and PSSS.
12.4.4.6.1 Data Module Service
The Data Module I/O Service sends encrypted data from the Data Control Manager, a Platform
Device Services component, to the Data Module device driver included in the BSP. The Data
Module device driver at specified intervals will send encrypted data to the Data Module.
The TS Interface is only instantiated within a TS Library which contains the business logic for
the specific transport mechanism. This is only used between PCS and PSS.
12.4.4.7.1 PCS ↔ PCS
User Application ↔ Common Services
User Application data from Partition A (Single Level/General-Purpose Partition) is transferred

via the TS Interface to Partition Z (Multi-Level/Security Partition) PCS Common Services.
Figure 56 does not show the communication lines between Partition Z PCS Common Services
components. This was done on purpose to minimize complexity of the diagram.
12.4.4.7.2 PCS ↔ PSS
Common Services ↔ Platform Common Services
Application data from Partition Z PCS Common Services is transferred via TS Interface to PSS
Platform Common Services. Figure 88 shown in a subsequent notional data flow section below
does not show the communication lines between Partition Z PCS Common Services components
and PSS Platform Common Services components. This was done on purpose to minimize
complexity of the diagram.
12.4.4.7.3 PSS ↔ Ethernet Device Driver
Platform Common Services ↔ Ethernet Device
Application data is transferred via the TS Interface to the Ethernet Device Driver BSP. Per
specified interval, the Application data will be sent via the TS Interface to Partition C (Single
Level/General-Purpose Partition) PCS.

12.4.4.7.4 PCS ↔ PSS
Data Logger ↔ Platform Device Services
Application data transferred via the TS Interface to the PCS Data Logger component is time-
stamped and logged before being transferred via the TS to Platform Device Services. Figure 88
does not show the communication lines between Partition C PCS Data Logger and Platform
Device Services components. This was done on purpose to minimize complexity of the diagram.
Figure 87: Secure Reporting Status Partition View
12.4.4.9 Notional Data Flow View
To further describe this FACE Secure Reporting Status example scenario, Figure 88 depicts the
partitions and data flow within Processor & Hardware #2, flowing between OSSs from partition
A to partition Processor & Hardware #1. Partitions are represented by the vertical barriers
between OSSs and the classification of the partitions is included within the components in each
FACE segment. The partitions that support the movement of data within a segment are shown at
different classification levels at the beginning of their name, as well as symbols to denote the
direction in which the data is flowing.
On Processor & Hardware #2, the OSS for Partition A provides the data flow from a User
Application (TS) through the TSS to Partition Z. The data moves from a General-Purpose Profile
partition flowing horizontally into a Security Profile partition through a High Robustness/Secure
Hypervisor Operating System (OSS Partition Z). After proper hardening of data (labeling and/or
encryption through the Security Verification component) the TS-level information can then
travel through a COTS Ethernet switch to Processor & Hardware #1.
The check between Security Verification components on the separate processor hardware is
needed to ensure the data was properly routed and unaltered through the Ethernet switch and that
the TS data was not compromised. Processor & Hardware #1 then reverses the process through
the TSS in the High Robustness Partition Z which subsequently sends the validated data via the
TSS and OSS to a Data Logger application in Partition C. The Data Logger application then
utilizes a platform-specific Data Control Manager to send the data to the external Data Module
using a Data Module Service in the IOSS of Partition C.
Figure 88: Secure Reporting Status Data Flow View

A Example of a FACE Conformant Implementation
A.1 Common Operating Picture Demo

This appendix uses the software from the Common Operating Picture (COP) Demo provided
with the FACE Modeling Tools Version 2.1.2 suite (examples and infrastructure subdirectories).
The IDL definitions for the I/O and TS Interfaces are found in the FACE Technical Standard
Sections D.2 and E.2.3, respectively. The code excerpts provided in this document are a C++
implementation utilizing a UDP transport service (other language implementations of the COP
Demo are provided in the modeling tools). Variations exist in formatting with the source code in
the Modeling Tools files to accommodate the space provided in this document.
The data flow provided in this example code is for a PSSS process (GPS process) that polls a
hardware device for position data using the IOSS (Serial Device Service). The PSSS then sends
that data to a PCS (Guidance Service) service using the TSS. The entire COP Demo project is
provided with the modeling tools. Refer to Figure 89 for a diagram.
This is one example of a FACE conformant implementation.
A.1.1 COP Demo Architecture
OS API OS API
TS API TS API
GPS Process Guidance

System
IO API
Serial Device
Service
Figure 89: COP Demo Architecture
A.2 Code Excerpts

A.2.1 Data Structures
The primary data structure referenced is in the example below. The altitude, latitude, and
longitude types resolve to FACE::Double which maps to the primitive double type. See the
subsections in Section 3.6.4.1.2 of the FACE Technical Standard for the IDL-to-programming
language mappings of data types.
struct BSOLocation
{
FACE::DM::Location_alt_lat_long bso_location;
};
struct Location_alt_lat_long
{
FACE::DM::WGS84PositionHeightMeasurementAxis altitude;
FACE::DM::WGS84PositionLatitudeMeasurementAxis latitude;
FACE::DM::WGS84PositionLongitudeMeasurementAxis longitude;
};
typedef FACE::Double WGS84PositionHeightMeasurementAxis;
typedef FACE::Double WGS84PositionLatitudeMeasurementAxis;
typedef FACE::Double WGS84PositionLongitudeMeasurementAxis;
A.2.2 Platform-Specific Services Code (GPS Sensor)

The main() function of the PSS component is divided into three primary functions:
INITIALIZE(), STARTUP(), and FINALIZE(). These functions invoke other functions of the
same names in the GPS_SENSOR_PSS namespace which perform minimal processing, reserving
most of the custom behavior for the functions BEHAV_INITIALIZE(), BEHAV_STARTUP(), and
BEHAV_FINALIZE(). The GPS Sensor makes use of an instance of the BSOLocationWriter
class. This class establishes connections to a hardware device through the IOSS and to a PCS
process through the TSS. The example discussed here utilizes UDP as the protocol for the TS
Interface.
The GPS_SENSOR::INITIALIZE() function initializes the BSOLocationWriter instance by

stepping through the Initialize(TS) and Create_Connection(TS) calls and the Initialize(I/O) and
Open(I/O) calls to effect the TSS and IOS connections, respectively. The BEHAV_INITIALIZE()
call currently does nothing, but could be used for process-specific logic.
The following excerpts illustrate the opening sequences for the TSS and IOS. The TSS begins
with the Initialize(TS)/Create_Connection(TS) sequence in the INITIALIZE() function. The IOS
starts with the Initialize(I/O)/Open(I/O) sequence as implemented in the BEHAV_INITIALIZE()
function. Though the sequences are performed in the order presented for each segment interface,
the IOS and TS Interfaces are configured and started independently of each other. As an
alternative, the Initialize(I/O) could be called first, then the Initialize(TS), then the Open(I/O),
and finally the Create_Connection(TS). The developer should do whatever makes sense for their
specific implementation. The file referenced in the Initialize(I/O) call, ios_configuration.xml,
exists within the example and contains the parameters necessary for configuring the interface.
GPS_SENSOR_PSS::INITIALIZE() – GPS_Sensor_PSS.cpp
::FACE::CONNECTION_NAME_TYPE platform_gps_name = "PLATFORM_GPS";

BSOLocationWriter platform_gps_writer (
(::FACE::CONNECTION_NAME_TYPE *) &platform_gps_name);

void INITIALIZE (void)
{
printf ("FACE Application 'GPS_Sensor_PSS' initialize...\n");
::FACE::RETURN_CODE_TYPE face_return_code;
face_return_code = platform_gps_writer.Initialize ();

if (face_return_code == ::FACE::NO_ACTION ||
face_return_code == ::FACE::NO_ERROR) {
fprintf (stderr, "initialize writer (%s) successful with
return_code %u\n", platform_gps_name, face_return_code);
face_return_code = platform_gps_writer.Create_Connection ();

if (face_return_code != ::FACE::NO_ERROR) {
fprintf (stderr, "create writer (%s) failed with return_code
%u\n", platform_gps_name, face_return_code);
}
else {
fprintf (stderr, "create writer (%s) successful with return_code
}
}
else {
fprintf (stderr, "initialize writer (%s) failed with return_code
}
BEHAV_INITIALIZE ();
}
The BSOLocationWriter::Initialize() function calls Initialize(TS) with a connection name and

returns the FACE return code for evaluation by the calling function. The demo implementation
returns NO_ACTION. It is prudent, however, to always call Initialize(TS) in case initialization is
required to place the TSS in a known state for the subsequent Create_Connection(TS) call to not
fail.
BSOLocationWriter::Initialize () – BSOLocation_writer.cpp
::FACE::RETURN_CODE_TYPE BSOLocationWriter::Initialize ()
{
::FACE::RETURN_CODE_TYPE return_code;
::FACE::CONFIGURATION_RESOURCE gpsConnectionName =
"GPS_SENSOR_WRITER";
::FACE::TS::Initialize (gpsConnectionName, return_code);
return return_code;
}
GPS_SENSOR_PSS::BEHAV_INITIALIZE() – GPS_Sensor_PSS_behav.cpp
::FACE::INTERFACE_NAME_TYPE GPS_IO_name = "GPS_IO";
::FACE::INTERFACE_HANDLE_TYPE GPS_IO_handle = NULL;
void BEHAV_INITIALIZE (void)

{
printf ("FACE Application 'GPS_Sensor_PSS' behavior
initialize...\n");
::FACE::RETURN_CODE_TYPE face_return_code;
// initialize IO
::FACE::INTERFACE_NAME_TYPE config = "ios_configuration.xml";
::FACE::IO::Initialize (config, face_return_code);
if (face_return_code != ::FACE::NO_ERROR)
fprintf (stderr, "initialize IO (%s) failed with return_code %u\n",
"PLATFORM_GPS", face_return_code);
// open IO destination port

::FACE::IO::Open (GPS_IO_name, 0, GPS_IO_handle, face_return_code);
if (face_return_code != ::FACE::NO_ERROR)
fprintf (stderr, "open io (%s) failed with return_code %u\n",
GPS_IO_name, face_return_code);
}
The connection name is the key component to the Create_Connection(TS) call. The
Initialize(TS) call accepts an argument of type CONNECTION_NAME_TYPE (which resolves to
a type of char [256]), the implied operation is to access a configuration file or, possibly, a data
set. That data will contain the connection parameters for the various connections the service is
expected to make, each one referenced by a unique connection name. Upon successful
completion of Create_Connection(TS), a connection identifier is passed back to the calling
function for use in subsequent Send_Message(TS) and Receive_Message(TS) calls to identify
the connection to use for the specified transaction.
BSOLocationWriter::Create_Connection() – BSOLocation_writer.cpp
::FACE::RETURN_CODE_TYPE BSOLocationWriter::Create_Connection ()
{
::FACE::TS::Create_Connection (*name, pattern, connid,
direction, size, 0, return_code);
if (return_code != ::FACE::NO_ERROR) {
fprintf (stderr, "Create_Connection (%s) failed with return_code
%u\n", *name, return_code);
}
else if (size != sizeof(FACE::DM::BSOLocation)) {
fprintf (stderr, "size from Create_Connection (%u bytes) does
not match sizeof FACE::DM::BSOLocation (%u bytes)\n",
(unsigned int) size, sizeof (FACE::DM::BSOLocation));
}
else {
printf ("Create_Connection (%s) successful\n", *name);
}
return return_code;
}

FACE::TS::Create_Connection() – TS.cpp […\cpp\tss\GuidanceDemoUDP\GPSProcess]
void Create_Connection (
/* in */ const FACE::CONNECTION_NAME_TYPE connection_name,
/* in */ FACE::MESSAGING_PATTERN_TYPE pattern,
/* out */ FACE::CONNECTION_ID_TYPE &connection_id,
/* out */ FACE::CONNECTION_DIRECTION_TYPE &connection_direction,
/* out */ FACE::MESSAGE_SIZE_TYPE &max_message_size,
/* in */ FACE::TIMEOUT_TYPE timeout,
/* out */ FACE::RETURN_CODE_TYPE &return_code)
{
FACE::TypeAbstractionTS::Create_Connection (
connection_name,
pattern,
connection_id,
connection_direction,
max_message_size,
timeout,
return_code);
}
FACE::TypeAbstractionTS::Create_Connection() – TypeAbstraction_TS.cpp
[…\cpp\tss\GuidanceDemoUDP\GPSProcess]
// POSIX transport variables

// platform_gps_udp POSIX udp variables
::FACE::POSIX_TRANSPORT::UDPMulticastPublisher
*platform_gps_udp_publisher = NULL;
std::string platform_gps_udp_group = "225.1.1.10";
unsigned int platform_gps_udp_port = 65535;
void Create_Connection (
/* in */ const FACE::CONNECTION_NAME_TYPE connection_name,
/* in */ FACE::MESSAGING_PATTERN_TYPE pattern,
/* out */ FACE::CONNECTION_ID_TYPE &connection_id,
/* out */ FACE::CONNECTION_DIRECTION_TYPE &connection_direction,
/* out */ FACE::MESSAGE_SIZE_TYPE &max_message_size,
{
if (strcmp ((const char *) connection_name, "PLATFORM_GPS") == 0) {
platform_gps_udp_publisher =
new :FACE::POSIX_TRANSPORT::UDPMulticastPublisher (
platform_gps_udp_group, platform_gps_udp_port);
if (!platform_gps_udp_publisher) {
return_code = ::FACE::NOT_AVAILABLE;
return;
}
return_code = ::FACE::NO_ERROR;
connection_id = 1;
max_message_size = sizeof (FACE::DM::BSOLocation);
connection_direction = ::FACE::SOURCE;
}
else {
return_code = ::FACE::INVALID_CONFIG;
}
}
Once initialization is complete, execution transitions to the STARTUP() function which calls
BEHAV_STARTUP(). The BEHAV_STARTUP() function activates the GPS_THREAD() function
to loop continuously to:
 Retrieve data from the device via the Read(I/O) function
 Confirm the return code indicates no error
 Forward data to the Guidance System process using the BSOLocationWriter::send()
function
If an error is encountered when reading from the device, the process bypasses sending data to the
TSS.
GPS_SENSOR_PROCESS::GPS_THREAD() – GPS_Sensor_PSS_behav.cpp
void GPS_THREAD (void)

{
while (1)
{
::FACE::MESSAGE_LENGTH_TYPE message_length = 1024;
unsigned char buffer[message_length];
::FACE::MESSAGE_ADDR_TYPE buffer_addr = &buffer;
::FACE::DM::BSOLocation location;
location.bso_location.latitude = 0.0;
location.bso_location.longitude = 0.0;
// TIMEOUT_TYPE has a 1 nanosecond resolution
::FACE::TIMEOUT_TYPE timeout = 1000000000;
::FACE::IO::Read (GPS_IO_handle, timeout, message_length,
buffer_addr, return_code);
if (return_code == ::FACE::NO_ERROR) {
bool success = parse_nmea_sentence ((char *) buffer, location);
if (success) {
printf ("GPS_THREAD: Data received from IO:
latitude: %f longitude: %f\n",
location.bso_location.latitude,
location.bso_location.longitude);
printf ("GPS_THREAD: Packing IO data in FACE::DM::BSOLocation

and sending to GuidanceSystem...\n");
platform_gps_writer.send (location);
}
}
else
printf ("Error FACE::IO::Read\n");

sleep (1);
}
}
Read(I/O) calls a function defined in the SerialDevice class, which calls a device-specific
function to retrieve data from the hardware. A surrogate serial device class is included for testing
the code without the need of actual hardware.
IO::Read() – IOS.cpp
void Read (
/* in */ FACE::INTERFACE_HANDLE_TYPE handle,
/* inout */ FACE::MESSAGE_LENGTH_TYPE & message_length,
/* in */ FACE::MESSAGE_ADDR_TYPE data_buffer_address,
/* out */ FACE::RETURN_CODE_TYPE & return_code)
{
if (handle != NULL) {
SerialDevice *device = (SerialDevice *) handle;
// timeout for following read()is in millisecs
return_code = device->read (timeout, message_length,
data_buffer_address);
}
else {
}
}
The serial device read() function performs the device-specific access function. Notice that the
timeout used in the device-specific read() function is expressed in microseconds. The input
timeout is of TIMEOUT_TYPE, expressed in nanoseconds. Therefore, the implementor knows
this value must be scaled to behave appropriately. Also, note that the device-specific function
maps low-level return codes to the return codes defined in the FACE Technical Standard,
Section B.2 for proper interpretation by the calling function.
SerialDevice::read() – serial_device.cpp
::FACE::RETURN_CODE_TYPE SerialDevice::read (
::FACE::TIMEOUT_TYPE timeout,
::FACE::MESSAGE_LENGTH_TYPE &message_length,
const ::FACE::MESSAGE_ADDR_TYPE &buffer)
{
fd_set fds;
struct timeval tv;
int retval;
FD_ZERO (&fds);
FD_SET (fd, &fds);
// 1 second timeout
tv.tv_sec = 0;
tv.tv_usec = (long) timeout/1000;
retval = select (fd+1, &fds, NULL, NULL, &tv);
if (retval == -1) {
return ::FACE::NO_ACTION;
}
else if (retval == 0) {
return ::FACE::TIMED_OUT;
}
else if (FD_ISSET(fd, &fds)) {
char buffer[message_length];
int ret = ::read (fd, &buffer, sizeof(buffer));
if (ret == -1) {
perror ("Failed to read from serial port");
return ::FACE::NOT_AVAILABLE;
}
else {
//printf ("Read %d bytes: %s\n", ret, buffer );
return ::FACE::NO_ERROR;
}
}
else {
return ::FACE::NOT_AVAILABLE;
}
}
The BSOLocationWriter::send() function called from the thread invokes the Send_Message(TS)
function to forward the data read from the device to the PCS component. The value for the
connection_id argument was returned in the Create_Connection(TS) call and is used to identify
to the TSS the connection to be used for data transmission.
BSOLocationWriter::send() – BSOLocation_writer.cpp
::FACE::RETURN_CODE_TYPE BSOLocationWriter::send (
const FACE::DM::BSOLocation &data)
{
::FACE::TRANSACTION_ID_TYPE transaction_id;
FACE::DM::BSOLocation tmpdata;
memcpy ((void *) &tmpdata, (const void *) &data,
sizeof (FACE::DM::BSOLocation));
::FACE::TS::Send_Message (connid, 0, transaction_id, tmpdata,

size, return_code);
return return_code;
}
The Send_Message(TS) function casts the data to type pointer to void and invokes the
TypeAbstraction_TS::Send_Message() which provides the desired method of delivery to the
specified recipient or recipients. The system-specific return codes are mapped to the return codes
defined Section B.2 of the FACE Technical Standard for proper interpretation by the calling
functions.

TS::Send_Message() – …\cpp\tss\GuidanceDemoUDP\GPSProcess\TS.cpp
void Send_Message (
/* in */ FACE::CONNECTION_ID_TYPE connection_id,
/* inout */ FACE::TRANSACTION_ID_TYPE &transaction_id,
/* inout */ FACE::DM::BSOLocation &message,
/* inout */ FACE::MESSAGE_SIZE_TYPE &message_size,
{
// serialization logic here...
void* typeAbstraction_message = (void *) &message;

FACE::MESSAGE_TYPE_GUID guid = 0;
MESSAGE_SIZE_TYPE tmpMsgSize =
(MESSAGE_SIZE_TYPE) sizeof (FACE::DM::BSOLocation);
// send serialized bytes

FACE::TypeAbstractionTS::Send_Message (
connection_id,
timeout,
transaction_id,
typeAbstraction_message,
guid,
message_size,
return_code);
}
TypeAbstractionTS::Send_Message() – …\cpp\tss\GuidanceDemoUDP\GPSProcess\
TypeAbstraction_TS.cpp
void Send_Message (
/* in */ void *message,
/* in */ FACE::MESSAGE_TYPE_GUID message_type_id,
/* in */ FACE::MESSAGE_SIZE_TYPE message_size,
{
if (connection_id == 1) {
if (!platform_gps_udp_publisher) {
return;
}
std::vector<unsigned char> v;
unsigned int i = 0;
while (i < message_size) {
v.push_back (((unsigned char *) message)[i]);
i++;
}
bool writeSuccess = platform_gps_udp_publisher->writePayload (v);
if (!writeSuccess) {
return;
}
}
else {
}
}
A.2.3 Portable Component Code (Guidance System)

The Guidance System operates in a manner similar to the GPS process, so the initial startup and
Create_Connection(TS) discussion will not be repeated here. There is no IOS component for the
Guidance System. The Guidance System thread performs a Receive_Message(TS) instead of a
Send_Message(TS) as executed in the GPS process in the previous section.
The BEHAV_STARTUP() activates the GUIDANCE_THREAD() function to act as a continuous

loop to retrieve data from the TSS via the BSOLocationWriter::receive() function, confirm the
return code indicates no error, and print the data to the console. Otherwise, it prints an error
message.
GUIDANCESYSTEM::GUIDANCE_THREAD() – GuidanceSystem_behav.cpp
void GUIDANCE_THREAD (void)

{
while (1) {
::FACE::DM::BSOLocation location;
::FACE::SYSTEM_TIME_TYPE timeout = 0;
::FACE::RETURN_CODE_TYPE return_code =
guidance_bso_location_reader.receive (location, timeout);
if (return_code == ::FACE::NO_ERROR) {
printf ("GUDIANCE_THREAD: Data received from GPS_Sensor_PSS:
latitude: %f longitude: %f\n",
location.bso_location.latitude,
location.bso_location.longitude);
}
else
printf ("GUIDANCE_THREAD: Error receiving TSS message
BSOLocation\n");
sleep (1);
}
}
The BSOLocationReader::receive() function calls TS::Receive_Message() which calls the

TypeAbstractionTS::Receive_Message() function.
BSOLocationReader::receive() – BSOLocation_reader.cpp
::FACE::RETURN_CODE_TYPE BSOLocationReader::receive (
FACE::DM::BSOLocation &data,
::FACE::TIMEOUT_TYPE timeout)

{
::FACE::MESSAGE_SIZE_TYPE received_size;
::FACE::TRANSACTION_ID_TYPE transaction_id;
::FACE::TS::Receive_Message (connid, timeout, transaction_id, data,

received_size, return_code);
return return_code;
}
The Receive_Message(TS) call, like Send_Message(TS), uses the connection_id parameter to

refer to the connection made earlier with Create_Connection(TS).
TS::Receive_Message() – TS.cpp […\cpp\tss\GuidanceDemoUDP\GuidanceSystem]
void Receive_Message (
/* inout */ FACE::DM::BSOLocation &message,
/* in */ FACE::MESSAGE_SIZE_TYPE message_size,
{
void* typeAbstraction_message = (void *) &message;
FACE::MESSAGE_TYPE_GUID guid = 0;
// receive serialized bytes

FACE::TypeAbstractionTS::Receive_Message (
connection_id,
timeout,
transaction_id,
typeAbstraction_message,
guid,
message_size,
return_code);
// deserialization logic here...

}
The TypeAbstractionTS version of Receive_Message() invokes the transport-specific calls to

receive the data sent by the GPS process using the TSS.
TypeAbstractionTS::Receive_Message() – TypeAbstraction_TS.cpp
[…\cpp\tss\GuidanceDemoUDP\GuidanceSystem]
/* in */ void *message,
/* inout */ FACE::MESSAGE_TYPE_GUID &message_type_id,
/* inout */ FACE::MESSAGE_SIZE_TYPE &message_size,
{
if (connection_id == 2) {
if (!guidance_bso_location_udp_subscriber) {
return;
}
std::vector<unsigned char> msg;

if (guidance_bso_location_udp_subscriber->readMessage (msg) > 0) {
unsigned int payload_size = msg.size ();
message_size = payload_size –
::FACE::POSIX_TRANSPORT::UDPMulticastSubscriber::HEADER_SIZE;
if (message_size < 0) {
return;
}
unsigned int i = 0;
while (i!=message_size) {
((unsigned char *) message)[i] = msg[i+4];
i++;
}
}
else {
return;
}
}
else {
}
}

B FACE Data Model UML Profile
This appendix contains the FACE Data Model UML Profile Description, which is based on the
FACE Technical Standard.
B.1 FACE Data Model UML Profile Overview

The FACE Data Model UML Profile is based solely on the FACE Data Model MOF metamodel
that is defined in the FACE Technical Standard. The FACE Data Model UML Profile (UML
Profile) is a software customization that allows software developers targeting conformance with
the FACE Technical Standard to utilize commercial UML tools to construct conformant FACE
Data Models.
UML Profiles allow for the extension and customization of the UML language to target specific
domains. UML Profiles are only additive: they cannot contradict standard semantics. They are
allowed to refine semantics by defining or extending the domain the UML Profile applies to.
There are several standard UML Profiles used in government and industry today, such as for
building Systems Modeling Language (SysML) models.
Purpose
This document is intended to describe the FACE Data Model UML Profile in sufficient detail to
allow it to be customized for other UML modeling tools. The overarching intent is to provide
semantic equivalence between the UML and MOF representations of FACE Data Model content.
Section B.2 details the concepts captured in the profile. Appendices A and B contain the XMI
representation of the UML Profile as used by SparxSystem’s Enterprise Architect and the
Eclipse Foundation’s Eclipse. Unfortunately, the UML Profile requires slight customizations to
operate with specific UML modeling tools.
Lineage of the FACE Data Model UML Profile
The FACE Technical Standard defines the FACE Data Model language as a MOF metamodel.
The MOF metamodel is an unambiguous, rigorous definition of the FACE Data Model language.
However, directly constructing Data Model content directly with the MOF metamodel is not
supported by a great number of available tools. The FACE Consortium identified the need for
greater tool support; this drove the development of the FACE Data Model UML Profile.
The concepts captured in the FACE Data Model UML Profile map directly to the concepts
defined in the FACE Data Model MOF metamodel. The UML Profile simply provides
customization of commercial tools to allow for the construction of FACE Data Model content.
No additional concepts or materials were used in developing the FACE Data Model UML
Profile.
B.2 FACE Data Model UML Profile Detail
This document provides a complete overview of all element details. For simpler and more
focused reports, simply copy this initial template and turn off the sections not required.
FACE Data Model Profile
Type: Package
Status: Proposed. Version 1.0. Phase 1.0.
Package: Model
Detail: Created on 5/18/2012. Last modified on 11/6/2012
GUID: {E0F0D380-D722-4c67-B168-BA1F7A0D65E6}
FACE Data Model Profile – (Package diagram)

Created By: sfrerking on 5/18/2012
Last Modified: 7/26/2012
Version: 1.0. Locked: False
GUID: {27CE4472-50DD-4e6b-9AC8-90953C28E366}
RedefinedToolbox=UML::Class;Alias=FACE Data Model Profile;Notes=FACE
Data Model Profile;

FaceDM
Type: Package «profile»

Package: FACE Data Model Profile
Detail: Created on 6/22/2012. Last modified on 11/21/2012
GUID: {A06BA04D-1322-48c3-8A48-1B195460ECC1}
RedefinedToolbox=UML::Class;Alias=FaceDM;Notes=FaceDM;
face - (Class diagram)

GUID: {128C77D6-3772-4bd9-B7DE-3EFA86A4BF3A}
conceptual - (Class diagram)

GUID: {0A0916DD-D900-47d3-949D-87AB07A98891}
logical - (Class diagram)
GUID: {9F571D46-660A-4682-AA1B-F56E100E1408}

logical_basis - (Class diagram)
GUID: {511E5378-6319-4cbd-AFD8-2F019AEF9D6E}
class logical_basis
«metaclass»
Class
- _Tag :Integer = 1
+ isActive :Boolean
AffineConv ersion
«enumeration» - conversionFactor :Real

ValueType - offset :Real
Boolean
Integer
Natural
Real +source ConvertibleElement
Conv ersion
NonNegativeReal
«taggedValue»
Character - description :String [0..1] - isDeprecated :Boolean = False
String - isDeprecated :Boolean = False +target - _faceUUID :String [0..1]
Enumeration - _faceUUID :String [0..1] «taggedValue» - description :String [0..1]
ValueElement
Unit
- valueType :ValueType = Boolean +unit
- description :String [0..1]
- _valueTypeFaceUUID :String [0..1] «taggedValue»
- _faceUUID :String [0..1]
LogicalInformation SimpleMeasurement FrameOfReference CompositeMeasurement

+frameOfReference +frameOfReference
- isDeprecated :Boolean = False - description :String [0..1]
- precision :Real «taggedValue» «taggedValue» - isDeprecated :Boolean = False
«metaclass»
Attribute
MeasurementComposition
logical_value_constraints - (Class diagram)

GUID: {7C5FB010-50D8-4e37-BB8A-8408A49DD9D2}

platform - (Class diagram)
GUID: {236BA3D1-66D0-4df7-9E5D-6DD81B51045E}
uop - (Class diagram)
GUID: {43A30176-E8B2-4bd7-92A5-03332E2B660B}

class uop
«enumeration» «enumeration»
FaceEdition PartitionType
_1_0 POSIX UnitOfPortability

_2_0 ARINC653
- componentType :ComponentType = Portable
«enumeration» «enumeration» - faceEdition :FaceEdition = _1_0
FaceProfile ComponentType - faceProfile :FaceProfile = GeneralPurpose
- notes :String [0..1]
GeneralPurpose Portable - partitionType :PartitionType = POSIX
Security PlatformSpecific - description :String [0..1]
SafetyBase TransportService - _aliasSetFaceUUID :String [0..1]
SafetyExtended - _faceUUID :String [0..1]
MessagePort
- communicationStyle :CommunicationStyle = Queuing «metaclass»

- messageExchangeType :MessageExchangeType = InboundMessage
Class
- period :Real
- programmingLanguage :ProgrammingLanguage = C - _Tag :Integer = 1
- synchronizationStyle :SynchronizationStyle = Blocking + isActive :Boolean
- description :String [0..1]
«enumeration» «enumeration»
CommunicationStyle MessageExchangeType
Queuing InboundMessage ApplicationFramew ork LanguageRunTime

SingleInstanceMessaging OutboundMessage
- version :String - version :String
- _faceUUID :String [0..1] - _faceUUID :String [0..1]
«enumeration» «enumeration» - description :String [0..1] - description :String [0..1]
ProgrammingLanguage SynchronizationStyle
C Blocking
CPP NonBlocking
Java
Ada
«metaclass»
Association
+ direction :Direction = Source -> Desti...
TransportEndpoint Alias MessageType SupportingComponent
Attribute
Type: Metaclass
Package: FaceDM Keywords:
Detail: Created on 2/14/2013. Last modified on 4/13/2013.
GUID: {3A5F660C-42D8-469e-81A0-7E1B2C08E222}
Custom properties:
 isActive = False
Connections:
Connector Source Target Notes
Extension Public Composition Public Attribute

Source -> Destination
Extension Public IDLComposition Public Attribute

Extension Public EnumLiteral Public Attribute

Extension Public MeasurementComposition Public Attribute

Association
Type: Metaclass
GUID: {08CCD31F-CC6C-4ea4-AC39-7F0DF623CC74}
Custom properties:
Connections:
Extension Public Projection Public Association

Extension Public AssociatedEntity Public Association

Extension Public Realize Public Association

Extension Public ValueConstraint Public Association

Extension Public TransportEndpoint Public Association

Extension Public Alias Public Association

Extension Public MessageType Public Association

Extension Public SupportingComponent Public Association


Attributes:
Attribute Notes Constraints and Tags
Direction Direction Default: Source -> Destination

Public
Class
Type: Metaclass
GUID: {F8121481-F28F-4c3c-B457-C6FA9D4BF161}
Custom properties:
Connections:
Extension Public ViewType Public Class

Extension Public AssociationType Public Class

Extension Public EntityType Public Class

Extension Public ConceptualInformation Public Class

Extension Public Observable Public Class

Extension Public ConvertibleElement Public Class

Extension Public Conversion Public Class

Extension Public ValueElement Public Class

Extension Public CompositeMeasurement Public Class

Extension Public Public Class

Source -> Destination RegularExpressionConstraint
Extension Public IntegerRangeConstraint Public Class

Extension Public RealRangeConstraint Public Class

Extension Public LogicalEnumeration Public Class

Extension Public EnumerationSelector Public Class

Extension Public IDLStruct Public Class

Extension Public IDLPrimitive Public Class

Extension Public MessagePort Public Class

Extension Public UnitOfPortability Public Class

Extension Public ApplicationFramework Public Class

Extension Public LanguageRunTime Public Class

Attributes:
_Tag Integer Default: 1

Private
isActive Boolean Default:

Public
Package
Type: Metaclass
GUID: {6204933D-5CEC-4c6f-A42C-9E97A1166C1B}
Custom properties:

Connections:
Extension Public UoPModel Public Package

Extension Public PlatformModel Public Package

Extension Public LogicalModel Public Package

Extension Public ConceptualModel Public Package

Extension Public FACEDataModel Public Package

Attributes:
_defaultDiagramType Default: UML Structural::Class

String
Private
_makeComposite Default: true

Boolean
Private
URI String Default:

Public
FACEDataModel
Type: Stereotype
GUID: {6463DA63-4398-40a3-B592-42E1522A226C}
Custom properties:
Connections:
Extension Public FACEDataModel Public Package

Attributes:
description String Default:

Private
[0..1]
_faceUUID String Default:

Private
[0..1]
EntityType
Type: Stereotype
GUID: {9A508B0E-1F23-44b5-BF1E-F373EF6D7681}
Custom properties:
Connections:
Extension Public EntityType Public Class

Attributes:

Private
[0..1]

Private
[0..1]
Composition
Type: Stereotype
GUID: {454FF94B-FA3F-42c5-B56E-22910CC305C8}

Custom properties:
Connections:
Extension Public Composition Public Attribute

Attributes:
realizedComposition Default:
String
Private
[0..1]

Private
[0..1]
AssociationType
Type: Stereotype
GUID: {7397D2CB-6339-41f0-A087-FCABA0A6BE5A}
Custom properties:
Connections:
Extension Public AssociationType Public Class

Attributes:

Private
[0..1]

Private
[0..1]
ViewType
Type: Stereotype
GUID: {A0065C8D-C0E5-4b9e-A93D-B6D31D2E7DD6}
Custom properties:
Connections:
Extension Public ViewType Public Class

Attributes:

Private
[0..1]

Private
[0..1]
AssociatedEntity
Type: Stereotype
GUID: {A8773D69-D55D-40f8-9142-E3A9DCC5FE8E}
Custom properties:

Connections:
Extension Public AssociatedEntity Public Association

Attributes:
realizedAssociatedEntity Default:
String
Private

Private
[0..1]
Projection
Type: Stereotype
GUID: {66B6AA38-D9E8-4253-85F1-3F5A43CEFDB3}
Custom properties:
Connections:
Extension Public Projection Public Association

Attributes:
realizedProjection Default:
String
Private
[0..1]
positionInView Integer Default:

Private

Private
[0..1]
Realize
Type: Stereotype
GUID: {C17C7927-8044-4c65-973A-B8ADFF095128}
Custom properties:
Connections:
Extension Public Realize Public Association

ConceptualModel
Type: Stereotype
GUID: {7A0B269F-046F-476d-8D99-47C923BDE0FB}
Custom properties:
Connections:
Extension Public ConceptualModel Public Package

Attributes:

Private
[0..1]


Private
[0..1]
ConceptualInformation
Type: Stereotype
GUID: {A1FC98C2-45CF-41df-95F4-069F012F3E2D}
Custom properties:
Connections:
Extension Public ConceptualInformation Public Class

Attributes:
isDeprecated Boolean Default: False

Private

Private
[0..1]

Private
[0..1]
Observable
Type: Stereotype
GUID: {49783F61-7A37-4783-B728-62C1BBDA005B}
Custom properties:
Connections:
Extension Public Observable Public Class

Attributes:

Private

Private
[0..1]

Private
[0..1]
LogicalModel
Type: Stereotype
GUID: {A5FEEDD1-89AE-4185-98E5-CBECCF5D6DD3}
Custom properties:
Connections:
Extension Public LogicalModel Public Package

Attributes:

Private
[0..1]

Private
[0..1]

ConvertibleElement
Type: Stereotype
GUID: {AFC80583-0593-45c3-81C6-CFC6057EBDA3}
Custom properties:
Connections:
Generalization Public FrameOfReference Public

Source -> Destination ConvertibleElement
Generalization Public Unit Public

Association Public Conversion Public source

Association Public Conversion Public target

Extension Public ConvertibleElement Public Class

Attributes:

Private

Private
[0..1]

Private
[0..1]
Unit
Type: Stereotype ConvertibleElement

GUID: {09E35FB4-A574-45b4-BEF0-407FC84EF3F5}
Custom properties:
Connections:
Association Public SimpleMeasurement Public unit

Source -> Destination Unit
Generalization Public Unit Public

FrameOfReference
Type: Stereotype ConvertibleElement

GUID: {ECCA7C83-EB36-4605-AF70-5CB8D724AA35}
Custom properties:
Connections:
Association Public CompositeMeasurement Public frameOfReference

Source -> Destination FrameOfReference
Association Public SimpleMeasurement Public frameOfReference

Generalization Public FrameOfReference Public

LogicalEnumeration
Type: Stereotype
GUID: {29A0EA0A-97D0-462e-A75A-978F56E194EF}
Custom properties:

Connections:
Association Public EnumerationSelector Public sourceEnumeration

Source -> Destination LogicalEnumeration
Extension Public LogicalEnumeration Public Class

Attributes:

Private

Private
[0..1]

Private
[0..1]
EnumLiteral
Type: Stereotype
GUID: {7F118B38-1804-49a4-A4B5-FF41815D3C22}
Custom properties:
Connections:
Extension Public EnumLiteral Public Attribute

Attributes:

Private
[0..1]

Private
[0..1]
ValueElement
Type: Stereotype
GUID: {55F653D4-82C0-4de7-A83C-56EDEDC4B0F1}
Custom properties:
Connections:
Generalization Public SimpleMeasurement Public ValueElement

Generalization Public LogicalInformation Public ValueElement

Extension Public ValueElement Public Class

Attributes:
valueType ValueType Default: Boolean

Private

Private
[0..1]
_valueTypeFaceUUID Default:
String
Private
[0..1]

Private
[0..1]

LogicalInformation
Type: Stereotype ValueElement

GUID: {6CE8B731-9BDD-4b56-A361-2EC7AAF6CE91}
Custom properties:
Connections:
Generalization Public LogicalInformation Public ValueElement

SimpleMeasurement
Type: Stereotype ValueElement

GUID: {148931C6-A8D5-4cd9-848E-29103F8E60CD}
Custom properties:
Connections:
Association Public SimpleMeasurement Public frameOfReference

Association Public SimpleMeasurement Public unit

Source -> Destination Unit
Generalization Public SimpleMeasurement Public ValueElement

Attributes:

Private
precision Real Default:

Private
CompositeMeasurement
Type: Stereotype
GUID: {8B604060-9BD4-405e-BF3C-3336E9C36845}
Custom properties:
Connections:
Association Public CompositeMeasurement Public frameOfReference

Extension Public CompositeMeasurement Public Class

Attributes:

Private
[0..1]

Private

Private
[0..1]
MeasurementComposition
Type: Stereotype
GUID: {F63A7123-C439-4ed6-882D-70723E79C2A9}
Custom properties:

Connections:
Extension Public MeasurementComposition Public Attribute

Attributes:

Private
[0..1]
ValueConstraint
Type: Stereotype
GUID: {6E6871DB-15DF-485d-AA11-34BFF28EDD64
Custom properties:
Connections:
Extension Public ValueConstraint Public Association

IntegerRangeConstraint
Type: Stereotype
GUID: {FBDAC323-55DC-4951-A459-09B13F1BC99E}
Custom properties:
Connections:
Extension Public IntegerRangeConstraint Public Class

Attributes:
lowerBound Integer Default:

Private
upperBound Integer Default:

Private

Private
[0..1]

Private
[0..1]
RealRangeConstraint
Type: Stereotype
GUID: {BD89653E-EE23-4200-A818-7220BC1CF7A5
Custom properties:
Connections:
Extension Public RealRangeConstraint Public Class

Attributes:
lowerBound Real Default:

Private
lowerBoundInclusive Default: true

Boolean
Private
upperBound Real Default:

Private
upperBoundInclusive Default: true

Boolean
Private


Private
[0..1]

Private
[0..1]
RegularExpressionConstraint
Type: Stereotype
GUID: {59CAD5BD-990F-4b68-8F0C-500A4CA503FE}
Custom properties:
Connections:
Extension Public Public Class

Source -> Destination RegularExpressionConstraint
Attributes:
expression String Default:

Private

Private
[0..1]

Private
[0..1]
EnumerationSelector
Type: Stereotype
GUID: {B9D5A11D-2129-4c20-B233-FB037A5EC57E}
Custom properties:
Connections:
Association Public EnumerationSelector Public sourceEnumeration

Source -> Destination LogicalEnumeration
Extension Public EnumerationSelector Public Class

Conversion
Type: Stereotype
GUID: {E3073A95-33DE-44c3-BBEE-B10A9B772691}
Custom properties:
Connections:
Association Public Conversion Public source

Association Public Conversion Public target

Generalization Public AffineConversion Public Conversion

Extension Public Conversion Public Class

Attributes:

Private
[0..1]

Private


Private
[0..1]
AffineConversion
Type: Stereotype Conversion

GUID: {4E368E61-CA1E-43af-8785-CE5A3787A3AE}
Custom properties:
Connections:
Generalization Public AffineConversion Public Conversion

Attributes:
conversionFactor Real Default:

Private
offset Real Default:

Private
PlatformModel
Type: Stereotype
GUID: {120F121F-3A13-4bbd-8711-8B614372ED49}
Custom properties:
Connections:
Extension Public PlatformModel Public Package

Attributes:

Private
[0..1]

Private
[0..1]
IDLPrimitive
Type: Stereotype
GUID: {4FA6F5E5-0163-45f5-91D3-EBFE65C1CEE7}
Custom properties:
Connections:
Extension Public IDLPrimitive Public Class

Attributes:
IDLType IDLType Default: Boolean

Private
fixedDigits Integer Default:

Private
fixedScale Integer Default:

Private

Private
[0..1]
Private
[0..1]

IDLStruct
Type: Stereotype
GUID: {E173EC2F-6B65-4ecd-AD65-00A188BBDA3E}
Custom properties:
Connections:
Extension Public IDLStruct Public Class

Attributes:

Private
[0..1]

Private
[0..1]
IDLComposition
Type: Stereotype
GUID: {E443D9E1-AE51-4068-9705-77F9852945C1}
Custom properties:
Connections:
Extension Public IDLComposition Public Attribute

Attributes:
realizedMeasurement Default:
Composition String
Private
[0..1]

Private
[0..1]
UoPModel
Type: Stereotype
GUID: {38304E20-338B-406c-B76E-798EC08F21E9}
Custom properties:
Connections:
Extension Public UoPModel Public Package

Attributes:

Private
[0..1]

Private
[0..1]
UnitOfPortability
Type: Stereotype
GUID: {0E3A82C9-91C9-4f20-9BF9-6B3BEAA51F3F}

Custom properties:
Connections:
Extension Public UnitOfPortability Public Class

Attributes:
componentType Default: Portable

ComponentType
Private
faceEdition Default: _1_0

FaceEdition
Private
faceProfile FaceProfile Default: GeneralPurpose

Private
notes String Default:

Private
[0..1]
partitionType Default: POSIX

PartitionType
Private

Private
[0..1]
_aliasSetFaceUUID Default:
String
Private
[0..1]

Private
[0..1]
TransportEndpoint
Type: Stereotype
Package: FaceDM Keywords
GUID: {D04AF2ED-F7C5-4d0b-A6A5-111EE0F2FB3F}
Custom properties:
Connections:
Extension Public TransportEndpoint Public Association

MessagePort
Type: Stereotype
GUID: {0F35DB7E-9216-45b6-A03B-6B66109C8091}
Custom properties:
Connections:
Extension Public MessagePort Public Class

Attributes:
communicationStyle Default: Queuing

CommunicationStyle
Private
messageExchangeType Default: InboundMessage

MessageExchangeType
Private
period Real Default:

Private
programmingLanguage Default: C
ProgrammingLanguage
Private
synchronizationStyle Default: Blocking

SynchronizationStyle
Private


Private
[0..1]

Private
[0..1]
MessageType
Type: Stereotype
GUID: {429F0E38-92A5-4afb-BC41-52C3E43264C2}
Custom properties:
Connections:
Extension Public MessageType Public Association

ApplicationFramework
Type: Stereotype
GUID: {F35DC8E4-1916-4cee-9428-733ABFF2BEB6}
Custom properties:
Connections:
Extension Public ApplicationFramework Public Class

Attributes:
version String Default:

Private

Private
[0..1]

Private
[0..1]
LanguageRunTime
Type: Stereotype
GUID: {20D34CC7-7000-4076-807F-70F8BBEB375C}
Custom properties:
Connections:
Extension Public LanguageRunTime Public Class

Attributes:
version String Default:

Private

Private
[0..1]

Private
[0..1]
SupportingComponent
Type: Stereotype

GUID: {3457E225-B0E3-4cb3-9430-BF72C5DE6EFC}
Custom properties:
Connections:
Extension Public SupportingComponent Public Association

Alias
Type: Stereotype
GUID: {15DAD148-10CB-4f75-8910-F013685B0AED}
Custom properties:
Connections:
Extension Public Alias Public Association

Attributes:

Private
[0..1]
CommunicationStyle
Type: Enumeration
GUID: {E471597A-FDD5-455f-833D-D417CE9BE28D}
Custom properties:
Attributes:
Queuing Default:
Public
«enum»
SingleInstanceMessaging Default:
Public
ComponentType
Type: Enumeration
GUID: {CA658222-098D-4e78-9BB1-4B4B62F9D69E}
Custom properties:
Attributes:
Portable Default:
Public
«enum»
PlatformSpecific Default:
Public
«enum»
TransportService Default:
Public
«enum»
FaceEdition
Type: Enumeration
GUID: {ACC77E1D-A9A9-4954-BF99-35CC1CBE8A15}
Custom properties:

Attributes:
_1_0 Default:
Public
«enum»
_2_0
Public
«enum»
FaceProfile
Type: Enumeration
GUID: {2D098B6B-AB4E-4635-B243-F6B8E3625883}
Custom properties:
Attributes:
GeneralPurpose Default:
Public
«enum»
Security Default:
Public
«enum»
SafetyBase Default:
Public
«enum»
SafetyExtended Default:
Public
«enum»
IDLType
Type: Enumeration
GUID: {E521CA08-B46E-4185-A649-F3D5CC00F153}
Custom properties:
Attributes:
Boolean Default:
Public
«enum»
Char Default:
Public
«enum»
WChar Default:
Public
«enum»
Octet Default:
Public
«enum»
String Default:
Public
«enum»
WString Default:
Public
«enum»
Enumeration Default:
Public
«enum»
Float Default:
Public
«enum»
Double Default:
Public
«enum»
LongDouble Default:
Public
«enum»
Fixed Default:
Public
«enum»

Short Default:
Public
«enum»
Long Default:
Public
«enum»
LongLong Default:
Public
«enum»
UShort Default:
Public
«enum»
ULong Default:
Public
«enum»
ULongLong Default:
Public
«enum»
MessageExchangeType
Type: Enumeration
GUID: {3E6CE92C-1FC4-4961-ABFC-3433F62C5B28}
Custom properties:
Attributes:
InboundMessage Default:
Public
«enum»
OutboundMessage Default:
Public
«enum»
PartitionType
Type: Enumeration
GUID: {22717EF2-3F80-4cdd-ADDA-068EA5DBFB8E}
Custom properties:
Attributes:
POSIX Default:
Public
«enum»
ARINC653 Default:
Public
«enum»
ProgrammingLanguage
Type: Enumeration
GUID: {E2020221-BDA8-453f-B989-358A91A7947F}
Custom properties:
Attributes:
C Default:
Public
«enum»
CPP Default:
Public
«enum»
Java Default:
Public
«enum»

Ada Default:
Public
«enum»
SynchronizationStyle
Type: Enumeration
GUID: {62E0A13A-1E74-495e-A09C-2AFB56B69071}
Custom properties:
Attributes:
Blocking Default:
Public
«enum»
NonBlocking Default:
Public
«enum»
ValueType
Type: Enumeration
GUID: {DFF726B3-B233-429d-A009-6F0E34348508}
Custom properties:
Attributes:
Boolean Default:
Public
«enum»
Integer Default:
Public
«enum»
Natural Default:
Public
«enum»
Real Default:
Public
«enum»
NonNegativeReal Default:
Public
«enum»
Character Default:
Public
«enum»
String Default:
Public
«enum»
Enumeration Default:
Public
«enum»
B.3 FACE Data Model UML Profile for Enterprise Architect (XMI
Format)

<UMLProfile profiletype="uml2">
<Documentation id="A06BA04D-1" name="FaceDM" version="2.0"
notes="RedefinedToolbox=UML::Class;Alias=FaceDM;Notes=FaceDM;"/>
<Content>
<Stereotypes>
<Stereotype name="FACEDataModel" notes="">
<AppliesTo>
<Apply type="Package">
<Property name="_defaultDiagramType" value="UML Structural::Class"/>
<Property name="_makeComposite" value="true"/>
<Property name="URI" value=""/>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="description" type="String" description="" unit="" values="" default=""/>
<Tag name="_faceUUID" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="EntityType" notes="">

<AppliesTo>
<Apply type="Class">
<Property name="_Tag" value="1"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="Composition" notes="">
<AppliesTo>
<Apply type="Attribute"/>
</AppliesTo>
<TaggedValues>
<Tag name="realizedComposition" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="AssociationType" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="ViewType" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="AssociatedEntity" notes="">
<AppliesTo>
<Apply type="Association">
<Property name="direction" value="Source -> Destination"/>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="realizedAssociatedEntity" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="Projection" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="realizedProjection" type="String" description="" unit="" values="" default=""/>
<Tag name="positionInView" type="Integer" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="Realize" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="ConceptualModel" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="ConceptualInformation" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="isDeprecated" type="Boolean" description="" unit="" values="True,False" default="False"/>
</TaggedValues>
</Stereotype>
<Stereotype name="Observable" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="LogicalModel" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="ConvertibleElement" notes="" isAbstract="true">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>

</TaggedValues>
</Stereotype>
<Stereotype name="Unit" notes="" generalizes="ConvertibleElement" baseStereotypes="ConvertibleElement"/>
<Stereotype name="FrameOfReference" notes="" generalizes="ConvertibleElement"
baseStereotypes="ConvertibleElement"/>
<Stereotype name="LogicalEnumeration" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="EnumLiteral" notes="">
<AppliesTo>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="ValueElement" notes="" isAbstract="true">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="valueType" type="enumeration" description="" unit=""
values="Boolean,Integer,Natural,Real,NonNegativeReal,Character,String,Enumeration"
default="Boolean"/>
<Tag name="_valueTypeFaceUUID" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="LogicalInformation" notes="" generalizes="ValueElement" baseStereotypes="ValueElement"/>
<Stereotype name="SimpleMeasurement" notes="" generalizes="ValueElement" baseStereotypes="ValueElement">
<TaggedValues>
<Tag name="precision" type="Real" description="" unit="" values="" default=""/>
<Tag name="frameOfReference"/>
<Tag name="unit"/>
</TaggedValues>
</Stereotype>
<Stereotype name="CompositeMeasurement" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="frameOfReference"/>
</TaggedValues>
</Stereotype>
<Stereotype name="MeasurementComposition" notes="">
<AppliesTo>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="ValueConstraint" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="IntegerRangeConstraint" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="lowerBound" type="Integer" description="" unit="" values="" default=""/>
<Tag name="upperBound" type="Integer" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="RealRangeConstraint" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="lowerBound" type="Real" description="" unit="" values="" default=""/>
<Tag name="lowerBoundInclusive" type="Boolean" description="" unit="" values="True,False"
default="True"/>
<Tag name="upperBound" type="Real" description="" unit="" values="" default=""/>
<Tag name="upperBoundInclusive" type="Boolean" description="" unit="" values="True,False"
default="True"/>
</TaggedValues>
</Stereotype>
<Stereotype name="RegularExpressionConstraint" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="expression" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="EnumerationSelector" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="sourceEnumeration"/>

</TaggedValues>
</Stereotype>
<Stereotype name="Conversion" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="source"/>
<Tag name="target"/>
</TaggedValues>
</Stereotype>
<Stereotype name="AffineConversion" notes="" generalizes="Conversion" baseStereotypes="Conversion">
<TaggedValues>
<Tag name="conversionFactor" type="Real" description="" unit="" values="" default=""/>
<Tag name="offset" type="Real" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="PlatformModel" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="IDLPrimitive" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="IDLType" type="enumeration" description="" unit="" values="Boolean,Char,WChar,Octet,String,
WString,Enumeration,Float,Double,LongDouble,Fixed,Short,Long,LongLong,UShort,ULong,ULongLong"
default="Boolean"/>
<Tag name="fixedDigits" type="Integer" description="" unit="" values="" default=""/>
<Tag name="fixedScale" type="Integer" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="IDLStruct" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="IDLComposition" notes="">
<AppliesTo>
</AppliesTo>
<TaggedValues>
<Tag name="realizedMeasurementComposition" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="UoPModel" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
<Stereotype name="UnitOfPortability" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="componentType" type="enumeration" description="" unit="" values="Portable,PlatformSpecific,
TransportService" default="Portable"/>
<Tag name="faceEdition" type="enumeration" description="" unit="" values="_1_0,_2_0" default="_1_0"/>
<Tag name="faceProfile" type="enumeration" description="" unit="" values="GeneralPurpose,Security,
SafetyBase,SafetyExtended" default="GeneralPurpose"/>
<Tag name="notes" type="String" description="" unit="" values="" default=""/>
<Tag name="partitionType" type="enumeration" description="" unit="" values="POSIX,ARINC653"
default="POSIX"/>
<Tag name="_aliasSetFaceUUID" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="TransportEndpoint" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="MessagePort" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="communicationStyle" type="enumeration" description="" unit=""
values="Queuing,SingleInstanceMessaging" default="Queuing"/>
<Tag name="messageExchangeType" type="enumeration" description="" unit=""
values="InboundMessage,OutboundMessage" default="InboundMessage"/>
<Tag name="period" type="Real" description="" unit="" values="" default=""/>
<Tag name="programmingLanguage" type="enumeration" description="" unit="" values="C,CPP,Java,Ada"
default="C"/>
<Tag name="synchronizationStyle" type="enumeration" description="" unit=""
values="Blocking,NonBlocking" default="Blocking"/>
</TaggedValues>
</Stereotype>

<Stereotype name="MessageType" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="ApplicationFramework" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="version" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="LanguageRunTime" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
<Tag name="version" type="String" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="SupportingComponent" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="Alias" notes="">
<AppliesTo>
</Apply>
</AppliesTo>
<TaggedValues>
</TaggedValues>
</Stereotype>
</Stereotypes>
<TaggedValueTypes>
<TaggedValueType property="frameOfReference" description=""
notes="Type=RefGUID;Stereotypes=FrameOfReference;"/>
<TaggedValueType property="unit" description="" notes="Type=RefGUID;Stereotypes=Unit;"/>
<TaggedValueType property="sourceEnumeration" description=""
notes="Type=RefGUID;Stereotypes=LogicalEnumeration;"/>
<TaggedValueType property="source" description="" notes="Type=RefGUID;Stereotypes=ConvertibleElement;"/>
<TaggedValueType property="target" description="" notes="Type=RefGUID;Stereotypes=ConvertibleElement;"/>
</TaggedValueTypes>
</Content>
</UMLProfile>
B.4 FACE Data Model UML Profile for Eclipse (XMI Format)
<uml:Profile xmi:version="20110701" xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:uml="http://www.eclipse.org/uml2/4.0.0/UML" xmi:id="_cvS1IDNWEeKNpLyJrThh0g" name="FaceDM"
metaclassReference="_362ngDNWEeKNpLyJrThh0g _362ngTNWEeKNpLyJrThh0g _363OkDNWEeKNpLyJrThh0g
_4ZydkHayEeKusumcOLyDqw" metamodelReference="_cvS1ITNWEeKNpLyJrThh0g">
<eAnnotations xmi:id="_6-VKIDNXEeKNpLyJrThh0g" source="http://www.eclipse.org/uml2/2.0.0/UML">
<contents xmi:type="ecore:EPackage" xmi:id="_lHNzkD4xEeK4XOnfNZo-Zg" name="FaceDM"
nsURI="http:///schemas/FaceDM/_lHECkD4xEeK4XOnfNZo-Zg/18" nsPrefix="FaceDM">
<eAnnotations xmi:id="_lH9acT4xEeK4XOnfNZo-Zg" source="PapyrusVersion">
<details xmi:id="_lH9acj4xEeK4XOnfNZo-Zg" key="Version" value="2.0.0"/>
<details xmi:id="_lH9acz4xEeK4XOnfNZo-Zg" key="Comment" value=""/>
<details xmi:id="_lH9adD4xEeK4XOnfNZo-Zg" key="Copyright" value="DISTRIBUTION STATEMENT A. Approved for
public release; distribution is unlimited..

"/>
<details xmi:id="_lH9adT4xEeK4XOnfNZo-Zg" key="Date" value="2013-04-19"/>
<details xmi:id="_lH9adj4xEeK4XOnfNZo-Zg" key="Author" value="Stuart Frerking"/>
</eAnnotations>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzkT4xEeK4XOnfNZo-Zg" name="FACEDataModel">
<eAnnotations xmi:id="_lHNzkj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_6oyNYDNWEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzkz4xEeK4XOnfNZo-Zg" name="base_Package"
ordered="false" lowerBound="1">
<eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/4.0.0/UML#//Package"/>
</eStructuralFeatures>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7G5XVnEeKRBpo1mzOWtA" name="description"
ordered="false">
<eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/4.0.0/Types#//String"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzlT4xEeK4XOnfNZo-Zg" name="EntityType">
<eAnnotations xmi:id="_lHNzlj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_Fzd9IDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzlz4xEeK4XOnfNZo-Zg" name="base_Class"
<eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/4.0.0/UML#//Class"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7G63VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_RI7XOXa7EeKusumcOLyDqw" name="Composition">
<eAnnotations xmi:id="_RI7XOna7EeKusumcOLyDqw" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_M0AfAHazEeKusumcOLyDqw"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_RI7XO3a7EeKusumcOLyDqw"
name="realizedComposition" ordered="false">
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_RI7XPXa7EeKusumcOLyDqw" name="base_Property"
<eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/4.0.0/UML#//Property"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzmT4xEeK4XOnfNZo-Zg" name="AssociationType">
<eAnnotations xmi:id="_lHNzmj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_TelpUDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzmz4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7G8XVnEeKRBpo1mzOWtA" name="description"
ordered="false">

</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNznT4xEeK4XOnfNZo-Zg" name="ViewType">
<eAnnotations xmi:id="_lHNznj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_WE0rwDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNznz4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7G93VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzoT4xEeK4XOnfNZo-Zg" name="AssociatedEntity">
<eAnnotations xmi:id="_lHNzoj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_gZmuQDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzoz4xEeK4XOnfNZo-Zg"
name="base_Association" ordered="false" lowerBound="1">
<eType xmi:type="ecore:EClass" href="http://www.eclipse.org/uml2/4.0.0/UML#//Association"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_RI6wPXa7EeKusumcOLyDqw"
name="realizedAssociatedEntity" ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzpT4xEeK4XOnfNZo-Zg" name="Projection">
<eAnnotations xmi:id="_lHNzpj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_iSBocDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzpz4xEeK4XOnfNZo-Zg"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_rz-4GXeUEeKusumcOLyDqw"
name="realizedProjection" ordered="false">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_-DfB64acEeKX0oIor3uNag" name="positionInView"
<eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/4.0.0/Types#//Integer"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzqT4xEeK4XOnfNZo-Zg" name="Realize">
<eAnnotations xmi:id="_lHNzqj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_wESecDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzqz4xEeK4XOnfNZo-Zg"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzrT4xEeK4XOnfNZo-Zg" name="ConceptualModel">
<eAnnotations xmi:id="_lHNzrj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_2vqKQDNXEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzrz4xEeK4XOnfNZo-Zg" name="base_Package"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HCXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzsT4xEeK4XOnfNZo-Zg" name="ConceptualInformation">
<eAnnotations xmi:id="_lHNzsj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_3GG-kDNbEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzsz4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNztT4xEeK4XOnfNZo-Zg" name="isDeprecated"
ordered="false" lowerBound="1" defaultValueLiteral="false">
<eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/4.0.0/Types#//Boolean"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HEXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNztz4xEeK4XOnfNZo-Zg" name="Observable">
<eAnnotations xmi:id="_lHNzuD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_7kyJUDNbEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzuT4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNzuz4xEeK4XOnfNZo-Zg" name="isDeprecated"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HGXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzvT4xEeK4XOnfNZo-Zg" name="LogicalModel">
<eAnnotations xmi:id="_lHNzvj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_Mv1EUDPxEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNzvz4xEeK4XOnfNZo-Zg" name="base_Package"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HH3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_GqVPkV5nEeK8qagMtO7Vdg" name="ConvertibleElement"
abstract="true">
<eAnnotations xmi:id="_GqVPkl5nEeK8qagMtO7Vdg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_lFFhEF34EeK8qagMtO7Vdg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_GqVPk15nEeK8qagMtO7Vdg" name="isDeprecated"
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_GqVPlV5nEeK8qagMtO7Vdg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HJ3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzwT4xEeK4XOnfNZo-Zg" name="Unit"
eSuperTypes="_GqVPkV5nEeK8qagMtO7Vdg">
<eAnnotations xmi:id="_lHNzwj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_mlBgsDPxEeKNpLyJrThh0g"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzxz4xEeK4XOnfNZo-Zg" name="FrameOfReference"
eSuperTypes="_GqVPkV5nEeK8qagMtO7Vdg">
<eAnnotations xmi:id="_lHNzyD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_oeSvcDPxEeKNpLyJrThh0g"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_FC23vVahEeK1kcktCzck8w" name="LogicalEnumeration">
<eAnnotations xmi:id="_FC23vlahEeK1kcktCzck8w" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_DAq5AFW_EeK1kcktCzck8w"/>

<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_FC23v1ahEeK1kcktCzck8w" name="isDeprecated"
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_FC23wVahEeK1kcktCzck8w" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HNXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_rz_fA3eUEeKusumcOLyDqw" name="EnumLiteral">
<eAnnotations xmi:id="_rz_fBHeUEeKusumcOLyDqw" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_Iym_4HeUEeKusumcOLyDqw"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_rz_fBXeUEeKusumcOLyDqw" name="description"
ordered="false">
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_rz_fB3eUEeKusumcOLyDqw" name="base_Property"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_GqVPo15nEeK8qagMtO7Vdg" name="ValueElement"
abstract="true">
<eAnnotations xmi:id="_GqVPpF5nEeK8qagMtO7Vdg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_DsMToF4BEeK8qagMtO7Vdg"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_GqVPpV5nEeK8qagMtO7Vdg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNz0T4xEeK4XOnfNZo-Zg" name="valueType"
ordered="false" lowerBound="1" eType="_lHNz0z4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7HPXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_QIs7saRYEeKnVLeajH9I4w"
name="_valueTypeFaceUUID" ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHNz0z4xEeK4XOnfNZo-Zg" name="ValueType">
<eAnnotations xmi:id="_lHNz1D4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_gIDXwDfXEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHNz1T4xEeK4XOnfNZo-Zg" name="Boolean"/>
<eLiterals xmi:id="_lHNz1j4xEeK4XOnfNZo-Zg" name="Integer" value="1"/>
<eLiterals xmi:id="_lHNz1z4xEeK4XOnfNZo-Zg" name="Natural" value="2"/>
<eLiterals xmi:id="_lHNz2D4xEeK4XOnfNZo-Zg" name="Real" value="3"/>
<eLiterals xmi:id="_lHNz2T4xEeK4XOnfNZo-Zg" name="NonNegativeReal" value="4"/>
<eLiterals xmi:id="_lHNz2j4xEeK4XOnfNZo-Zg" name="Character" value="5"/>
<eLiterals xmi:id="_lHNz2z4xEeK4XOnfNZo-Zg" name="String" value="6"/>
<eLiterals xmi:id="_lHNz3D4xEeK4XOnfNZo-Zg" name="Enumeration" value="7"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNzzT4xEeK4XOnfNZo-Zg" name="LogicalInformation"
eSuperTypes="_GqVPo15nEeK8qagMtO7Vdg">
<eAnnotations xmi:id="_lHNzzj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_BeXhsDPyEeKNpLyJrThh0g"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNz3T4xEeK4XOnfNZo-Zg" name="SimpleMeasurement"
eSuperTypes="_GqVPo15nEeK8qagMtO7Vdg">
<eAnnotations xmi:id="_lHNz3j4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_Gk59sDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNz4T4xEeK4XOnfNZo-Zg" name="precision"
<eType xmi:type="ecore:EDataType" href="http://www.eclipse.org/uml2/4.0.0/Types#//Real"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNz5T4xEeK4XOnfNZo-Zg"
name="frameOfReference" ordered="false" lowerBound="1" eType="_lHNzxz4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNz5z4xEeK4XOnfNZo-Zg" name="unit"
ordered="false" lowerBound="1" eType="_lHNzwT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_MEmgA16MEeKACaBMOTakOg" name="isDeprecated"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNz6T4xEeK4XOnfNZo-Zg" name="CompositeMeasurement">
<eAnnotations xmi:id="_lHNz6j4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_IjtzwDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNz6z4xEeK4XOnfNZo-Zg" name="base_Class"
name="frameOfReference" ordered="false" lowerBound="1" eType="_lHNzxz4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_MEmgDF6MEeKACaBMOTakOg" name="isDeprecated"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7t_XVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_QIs71aRYEeKnVLeajH9I4w" name="MeasurementComposition">
<eAnnotations xmi:id="_QIs71qRYEeKnVLeajH9I4w" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_GbZP0KRVEeKnVLeajH9I4w"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_QIs716RYEeKnVLeajH9I4w" name="base_Property"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNz7z4xEeK4XOnfNZo-Zg" name="ValueConstraint">
references="_VHp1cDPyEeKNpLyJrThh0g"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNz8z4xEeK4XOnfNZo-Zg" name="IntegerRangeConstraint">
references="_atk8IDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNz9T4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNz9z4xEeK4XOnfNZo-Zg" name="lowerBound"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNz-T4xEeK4XOnfNZo-Zg" name="upperBound"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uC3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHNz-z4xEeK4XOnfNZo-Zg" name="RealRangeConstraint">
<eAnnotations xmi:id="_lHNz_D4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_c-LFwDPyEeKNpLyJrThh0g"/>

<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHNz_T4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHNz_z4xEeK4XOnfNZo-Zg" name="lowerBound"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0AT4xEeK4XOnfNZo-Zg"
name="lowerBoundInclusive" ordered="false" lowerBound="1" defaultValueLiteral="true">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Az4xEeK4XOnfNZo-Zg" name="upperBound"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0BT4xEeK4XOnfNZo-Zg"
name="upperBoundInclusive" ordered="false" lowerBound="1" defaultValueLiteral="true">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uGXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0Bz4xEeK4XOnfNZo-Zg" name="RegularExpressionConstraint">
<eAnnotations xmi:id="_lHN0CD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_fYZFcDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0CT4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Cz4xEeK4XOnfNZo-Zg" name="expression"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uIXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0DT4xEeK4XOnfNZo-Zg" name="EnumerationSelector">
<eAnnotations xmi:id="_lHN0Dj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_kq12gDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0Dz4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_tWHFN1raEeKntuI5-KkrnQ"
name="sourceEnumeration" ordered="false" lowerBound="1" eType="_FC23vVahEeK1kcktCzck8w"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0ET4xEeK4XOnfNZo-Zg" name="Conversion">
<eAnnotations xmi:id="_lHN0Ej4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_x6B0oDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0Ez4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_FC24DVahEeK1kcktCzck8w" name="isDeprecated"
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_GqVP715nEeK8qagMtO7Vdg" name="source"
ordered="false" lowerBound="1" eType="_GqVPkV5nEeK8qagMtO7Vdg"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_GqVP8V5nEeK8qagMtO7Vdg" name="target"
ordered="false" lowerBound="1" eType="_GqVPkV5nEeK8qagMtO7Vdg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uM3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0FT4xEeK4XOnfNZo-Zg" name="AffineConversion"
eSuperTypes="_lHN0ET4xEeK4XOnfNZo-Zg">
<eAnnotations xmi:id="_lHN0Fj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_zfKmcDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0GT4xEeK4XOnfNZo-Zg"
name="conversionFactor" ordered="false" lowerBound="1">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Gz4xEeK4XOnfNZo-Zg" name="offset"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0HT4xEeK4XOnfNZo-Zg" name="PlatformModel">
<eAnnotations xmi:id="_lHN0Hj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_87wcsDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0Hz4xEeK4XOnfNZo-Zg" name="base_Package"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uQHVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0IT4xEeK4XOnfNZo-Zg" name="IDLPrimitive">
<eAnnotations xmi:id="_lHN0Ij4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="__pMTUDPyEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0Iz4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0JT4xEeK4XOnfNZo-Zg" name="IDLType"
ordered="false" lowerBound="1" eType="_lHN0Kz4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Jz4xEeK4XOnfNZo-Zg" name="fixedDigits"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0KT4xEeK4XOnfNZo-Zg" name="fixedScale"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uTHVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0Kz4xEeK4XOnfNZo-Zg" name="IDLType">
<eAnnotations xmi:id="_lHN0LD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_dc-4oDfXEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0LT4xEeK4XOnfNZo-Zg" name="Boolean"/>
<eLiterals xmi:id="_lHN0Lj4xEeK4XOnfNZo-Zg" name="Char" value="1"/>
<eLiterals xmi:id="_lHN0Lz4xEeK4XOnfNZo-Zg" name="WChar" value="2"/>
<eLiterals xmi:id="_lHN0MD4xEeK4XOnfNZo-Zg" name="Octet" value="3"/>
<eLiterals xmi:id="_lHN0MT4xEeK4XOnfNZo-Zg" name="String" value="4"/>
<eLiterals xmi:id="_lHN0Mj4xEeK4XOnfNZo-Zg" name="WString" value="5"/>
<eLiterals xmi:id="_lHN0Mz4xEeK4XOnfNZo-Zg" name="Enumeration" value="6"/>
<eLiterals xmi:id="_lHN0ND4xEeK4XOnfNZo-Zg" name="Float" value="7"/>
<eLiterals xmi:id="_lHN0NT4xEeK4XOnfNZo-Zg" name="Double" value="8"/>
<eLiterals xmi:id="_lHN0Nj4xEeK4XOnfNZo-Zg" name="LongDouble" value="9"/>
<eLiterals xmi:id="_lHN0Nz4xEeK4XOnfNZo-Zg" name="Fixed" value="10"/>
<eLiterals xmi:id="_lHN0OD4xEeK4XOnfNZo-Zg" name="Short" value="11"/>
<eLiterals xmi:id="_lHN0OT4xEeK4XOnfNZo-Zg" name="Long" value="12"/>
<eLiterals xmi:id="_lHN0Oj4xEeK4XOnfNZo-Zg" name="LongLong" value="13"/>
<eLiterals xmi:id="_lHN0Oz4xEeK4XOnfNZo-Zg" name="UShort" value="14"/>

<eLiterals xmi:id="_lHN0PD4xEeK4XOnfNZo-Zg" name="ULong" value="15"/>
<eLiterals xmi:id="_lHN0PT4xEeK4XOnfNZo-Zg" name="ULongLong" value="16"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0Pj4xEeK4XOnfNZo-Zg" name="IDLStruct">
<eAnnotations xmi:id="_lHN0Pz4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_BQExkDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0QD4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uZXVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_RI7XQ3a7EeKusumcOLyDqw" name="IDLComposition">
<eAnnotations xmi:id="_RI7XRHa7EeKusumcOLyDqw" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_rk9qwHazEeKusumcOLyDqw"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_RI7XRXa7EeKusumcOLyDqw" name="base_Property"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_RI7XR3a7EeKusumcOLyDqw"
name="realizedMeasurementComposition" ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0Qj4xEeK4XOnfNZo-Zg" name="UoPModel">
<eAnnotations xmi:id="_lHN0Qz4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_MG4jEDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0RD4xEeK4XOnfNZo-Zg" name="base_Package"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7ua3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0Rj4xEeK4XOnfNZo-Zg" name="UnitOfPortability">
<eAnnotations xmi:id="_lHN0Rz4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_SItioDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0SD4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Sj4xEeK4XOnfNZo-Zg" name="componentType"
ordered="false" lowerBound="1" eType="_lHN0VD4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0TD4xEeK4XOnfNZo-Zg" name="faceEdition"
ordered="false" lowerBound="1" eType="_lHN0WT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Tj4xEeK4XOnfNZo-Zg" name="faceProfile"
ordered="false" lowerBound="1" eType="_lHN0XT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0UD4xEeK4XOnfNZo-Zg" name="notes"
ordered="false">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0Uj4xEeK4XOnfNZo-Zg" name="partitionType"
ordered="false" lowerBound="1" eType="_lHN0Yz4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7ue3VnEeKRBpo1mzOWtA" name="description"
ordered="false">
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_QIs8XaRYEeKnVLeajH9I4w"
name="_aliasSetFaceUUID" ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0VD4xEeK4XOnfNZo-Zg" name="ComponentType">
<eAnnotations xmi:id="_lHN0VT4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_yFMdUDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0Vj4xEeK4XOnfNZo-Zg" name="Portable"/>
<eLiterals xmi:id="_lHN0Vz4xEeK4XOnfNZo-Zg" name="PlatformSpecific" value="1"/>
<eLiterals xmi:id="_lHN0WD4xEeK4XOnfNZo-Zg" name="TransportService" value="2"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0WT4xEeK4XOnfNZo-Zg" name="FaceEdition">
<eAnnotations xmi:id="_lHN0Wj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_wAR_QDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0Wz4xEeK4XOnfNZo-Zg" name="_1_0"/>
<eLiterals xmi:id="_lHN0XD4xEeK4XOnfNZo-Zg" name="_2_0" value="1"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0XT4xEeK4XOnfNZo-Zg" name="FaceProfile">
<eAnnotations xmi:id="_lHN0Xj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_u_U4kDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0Xz4xEeK4XOnfNZo-Zg" name="GeneralPurpose"/>
<eLiterals xmi:id="_lHN0YD4xEeK4XOnfNZo-Zg" name="Security" value="1"/>
<eLiterals xmi:id="_lHN0YT4xEeK4XOnfNZo-Zg" name="SafetyBase" value="2"/>
<eLiterals xmi:id="_lHN0Yj4xEeK4XOnfNZo-Zg" name="SafetyExtended" value="3"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0Yz4xEeK4XOnfNZo-Zg" name="PartitionType">
<eAnnotations xmi:id="_lHN0ZD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_zL2jYDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0ZT4xEeK4XOnfNZo-Zg" name="POSIX"/>
<eLiterals xmi:id="_lHN0Zj4xEeK4XOnfNZo-Zg" name="ARINC653" value="1"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_ibe8d0nuEeKfEobJ8kN6MA" name="TransportEndpoint">
<eAnnotations xmi:id="_ibe8eEnuEeKfEobJ8kN6MA" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_GrI-AEnqEeKhaI6O2M8CXg"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_ibe8eUnuEeKfEobJ8kN6MA"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0Zz4xEeK4XOnfNZo-Zg" name="MessagePort">
<eAnnotations xmi:id="_lHN0aD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_UrXsoDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0aT4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0az4xEeK4XOnfNZo-Zg"
name="communicationStyle" ordered="false" lowerBound="1" eType="_lHN0dT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0bT4xEeK4XOnfNZo-Zg"
name="messageExchangeType" ordered="false" lowerBound="1" eType="_lHN0eT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0bz4xEeK4XOnfNZo-Zg" name="period"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0cT4xEeK4XOnfNZo-Zg"
name="programmingLanguage" ordered="false" lowerBound="1" eType="_lHN0fT4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_lHN0cz4xEeK4XOnfNZo-Zg"
name="synchronizationStyle" ordered="false" lowerBound="1" eType="_lHN0gz4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uonVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0dT4xEeK4XOnfNZo-Zg" name="CommunicationStyle">
<eAnnotations xmi:id="_lHN0dj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_nrBkgDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0dz4xEeK4XOnfNZo-Zg" name="Queuing"/>
<eLiterals xmi:id="_lHN0eD4xEeK4XOnfNZo-Zg" name="SingleInstanceMessaging" value="1"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0eT4xEeK4XOnfNZo-Zg" name="MessageExchangeType">
<eAnnotations xmi:id="_lHN0ej4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_lvgTADfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0ez4xEeK4XOnfNZo-Zg" name="InboundMessage"/>

<eLiterals xmi:id="_lHN0fD4xEeK4XOnfNZo-Zg" name="OutboundMessage" value="1"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0fT4xEeK4XOnfNZo-Zg" name="ProgrammingLanguage">
<eAnnotations xmi:id="_lHN0fj4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_rl9wEDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0fz4xEeK4XOnfNZo-Zg" name="C"/>
<eLiterals xmi:id="_lHN0gD4xEeK4XOnfNZo-Zg" name="CPP" value="1"/>
<eLiterals xmi:id="_lHN0gT4xEeK4XOnfNZo-Zg" name="Java" value="2"/>
<eLiterals xmi:id="_lHN0gj4xEeK4XOnfNZo-Zg" name="Ada" value="3"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EEnum" xmi:id="_lHN0gz4xEeK4XOnfNZo-Zg" name="SynchronizationStyle">
<eAnnotations xmi:id="_lHN0hD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_plyoEDfYEeKh4ss6R8mSnA"/>
<eLiterals xmi:id="_lHN0hT4xEeK4XOnfNZo-Zg" name="Blocking"/>
<eLiterals xmi:id="_lHN0hj4xEeK4XOnfNZo-Zg" name="NonBlocking" value="1"/>
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0hz4xEeK4XOnfNZo-Zg" name="MessageType">
<eAnnotations xmi:id="_lHN0iD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_YspwwDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0iT4xEeK4XOnfNZo-Zg"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0iz4xEeK4XOnfNZo-Zg" name="ApplicationFramework">
<eAnnotations xmi:id="_lHN0jD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_w5HUwDPzEeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0jT4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_JFYZdGmSEeKdKM9sFJQ3qA" name="version"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uwHVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0jz4xEeK4XOnfNZo-Zg" name="LanguageRunTime">
<eAnnotations xmi:id="_lHN0kD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_MM0EkDP2EeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0kT4xEeK4XOnfNZo-Zg" name="base_Class"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_JFYZemmSEeKdKM9sFJQ3qA" name="version"
<eStructuralFeatures xmi:type="ecore:EAttribute" xmi:id="_wP7uyHVnEeKRBpo1mzOWtA" name="description"
ordered="false">
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0kz4xEeK4XOnfNZo-Zg" name="SupportingComponent">
<eAnnotations xmi:id="_lHN0lD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_RwnEUDP2EeKNpLyJrThh0g"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0lT4xEeK4XOnfNZo-Zg"
</eClassifiers>
<eClassifiers xmi:type="ecore:EClass" xmi:id="_lHN0mz4xEeK4XOnfNZo-Zg" name="Alias">
<eAnnotations xmi:id="_lHN0nD4xEeK4XOnfNZo-Zg" source="http://www.eclipse.org/uml2/2.0.0/UML"
references="_hqIosD4xEeK4XOnfNZo-Zg"/>
<eStructuralFeatures xmi:type="ecore:EReference" xmi:id="_lHN0nT4xEeK4XOnfNZo-Zg"
</eClassifiers>
</contents>
</eAnnotations>
<elementImport xmi:id="_362ngDNWEeKNpLyJrThh0g" alias="Package">
<importedElement xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Package"/>
</elementImport>
<elementImport xmi:id="_362ngTNWEeKNpLyJrThh0g" alias="Class">
<importedElement xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</elementImport>
<elementImport xmi:id="_363OkDNWEeKNpLyJrThh0g" alias="Association">
<importedElement xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Association"/>
</elementImport>
<elementImport xmi:id="_4ZydkHayEeKusumcOLyDqw" alias="Property">
<importedElement xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Property"/>
</elementImport>
<packageImport xmi:id="_cvS1ITNWEeKNpLyJrThh0g">
<importedPackage xmi:type="uml:Model" href="pathmap://UML_METAMODELS/UML.metamodel.uml#_0"/>
</packageImport>
<packageImport xmi:id="_cvS1IjNWEeKNpLyJrThh0g">
<importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/>
</packageImport>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_6oyNYDNWEeKNpLyJrThh0g" name="FACEDataModel">
<ownedAttribute xmi:id="_-qJKADNWEeKNpLyJrThh0g" name="base_Package" association="_-qJKATNWEeKNpLyJrThh0g">
<type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Package"/>
</ownedAttribute>
<ownedAttribute xmi:id="_sGBBUHVeEeKRBpo1mzOWtA" name="description" visibility="public">
<type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_s76HgHVeEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_s778sHVeEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_-qJKATNWEeKNpLyJrThh0g" name="E_FACEDataModel_Package1"
memberEnd="_-qJKAjNWEeKNpLyJrThh0g _-qJKADNWEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_-qJKAjNWEeKNpLyJrThh0g" name="extension_FACEDataModel"
type="_6oyNYDNWEeKNpLyJrThh0g" aggregation="composite" association="_-qJKATNWEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_Fzd9IDNXEeKNpLyJrThh0g" name="EntityType">
<ownedAttribute xmi:id="_NOTXADNXEeKNpLyJrThh0g" name="base_Class" association="_NOTXATNXEeKNpLyJrThh0g">
<type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</ownedAttribute>
<ownedAttribute xmi:id="_K_6bwHVhEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_LU83oHVhEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_LU9esHVhEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_NOTXATNXEeKNpLyJrThh0g" name="E_EntityType_Class1"
memberEnd="_NOTXAjNXEeKNpLyJrThh0g _NOTXADNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_NOTXAjNXEeKNpLyJrThh0g" name="extension_EntityType"
type="_Fzd9IDNXEeKNpLyJrThh0g" aggregation="composite" association="_NOTXATNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_M0AfAHazEeKusumcOLyDqw" name="Composition">
<ownedAttribute xmi:id="_aOcD0HazEeKusumcOLyDqw" name="realizedComposition">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_nJ-yoH_GEeKvL4Vdnc9d5g"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_nKAAwH_GEeKvL4Vdnc9d5g" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_ihAW8HazEeKusumcOLyDqw" name="base_Property" association="_ihAW8XazEeKusumcOLyDqw">
<type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Property"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_ihAW8XazEeKusumcOLyDqw" name="E_Composition_Property1"
memberEnd="_ihAW8nazEeKusumcOLyDqw _ihAW8HazEeKusumcOLyDqw">

<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_ihAW8nazEeKusumcOLyDqw" name="extension_Composition"
type="_M0AfAHazEeKusumcOLyDqw" aggregation="composite" association="_ihAW8XazEeKusumcOLyDqw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_TelpUDNXEeKNpLyJrThh0g" name="AssociationType">
<ownedAttribute xmi:id="_VuZv0DNXEeKNpLyJrThh0g" name="base_Class" association="_VuZv0TNXEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_WQkQoHVhEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_WkvJ0HVhEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_WkwX8HVhEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_VuZv0TNXEeKNpLyJrThh0g" name="E_AssociationType_Class1"
memberEnd="_VuZv0jNXEeKNpLyJrThh0g _VuZv0DNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_VuZv0jNXEeKNpLyJrThh0g" name="extension_AssociationType"
type="_TelpUDNXEeKNpLyJrThh0g" aggregation="composite" association="_VuZv0TNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_WE0rwDNXEeKNpLyJrThh0g" name="ViewType">
<ownedAttribute xmi:id="_YWQi4DNXEeKNpLyJrThh0g" name="base_Class" association="_YWQi4TNXEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_eRtckHVhEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_ejcs0HVhEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_ejdT4HVhEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_YWQi4TNXEeKNpLyJrThh0g" name="E_ViewType_Class1"
memberEnd="_YWQi4jNXEeKNpLyJrThh0g _YWQi4DNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_YWQi4jNXEeKNpLyJrThh0g" name="extension_ViewType"
type="_WE0rwDNXEeKNpLyJrThh0g" aggregation="composite" association="_YWQi4TNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_gZmuQDNXEeKNpLyJrThh0g" name="AssociatedEntity">
<ownedAttribute xmi:id="_hxNaYDNXEeKNpLyJrThh0g" name="base_Association"
association="_hxNaYTNXEeKNpLyJrThh0g">
<type xmi:type="uml:Class" href="pathmap://UML_METAMODELS/UML.metamodel.uml#Association"/>
</ownedAttribute>
<ownedAttribute xmi:id="_26-EQHa0EeKusumcOLyDqw" name="realizedAssociatedEntity" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_3VNwQHa0EeKusumcOLyDqw"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_3VOXUHa0EeKusumcOLyDqw" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_hxNaYTNXEeKNpLyJrThh0g"
name="E_AssociatedEntity_Association1" memberEnd="_hxNaYjNXEeKNpLyJrThh0g _hxNaYDNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_hxNaYjNXEeKNpLyJrThh0g" name="extension_AssociatedEntity"
type="_gZmuQDNXEeKNpLyJrThh0g" aggregation="composite" association="_hxNaYTNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_iSBocDNXEeKNpLyJrThh0g" name="Projection">
<ownedAttribute xmi:id="_jflAsDNXEeKNpLyJrThh0g" name="base_Association"
association="_jflAsTNXEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_-KkDIHeTEeKusumcOLyDqw" name="realizedProjection">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_BE_M4HeUEeKusumcOLyDqw"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_BE_z8HeUEeKusumcOLyDqw" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_T6zIwIacEeKX0oIor3uNag" name="positionInView" visibility="public">
<type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Integer"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_UxYLcIacEeKX0oIor3uNag" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_UxZZkIacEeKX0oIor3uNag" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_UxbOwIacEeKX0oIor3uNag">
<value xsi:nil="true"/>
</defaultValue>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_jflAsTNXEeKNpLyJrThh0g" name="E_Projection_Association1"
memberEnd="_jflAsjNXEeKNpLyJrThh0g _jflAsDNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_jflAsjNXEeKNpLyJrThh0g" name="extension_Projection"
type="_iSBocDNXEeKNpLyJrThh0g" aggregation="composite" association="_jflAsTNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_wESecDNXEeKNpLyJrThh0g" name="Realize">
<ownedAttribute xmi:id="_xsE7oDNXEeKNpLyJrThh0g" name="base_Association"
association="_xsE7oTNXEeKNpLyJrThh0g">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_xsE7oTNXEeKNpLyJrThh0g" name="E_Realize_Association1"
memberEnd="_xsE7ojNXEeKNpLyJrThh0g _xsE7oDNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_xsE7ojNXEeKNpLyJrThh0g" name="extension_Realize"
type="_wESecDNXEeKNpLyJrThh0g" aggregation="composite" association="_xsE7oTNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_2vqKQDNXEeKNpLyJrThh0g" name="ConceptualModel">
<ownedAttribute xmi:id="_5EsvADNXEeKNpLyJrThh0g" name="base_Package" association="_5EsvATNXEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_t0zB4HVfEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_yZq7QHVfEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_yZsJYHVfEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_5EsvATNXEeKNpLyJrThh0g" name="E_ConceptualModel_Package1"
memberEnd="_5EsvAjNXEeKNpLyJrThh0g _5EsvADNXEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_5EsvAjNXEeKNpLyJrThh0g" name="extension_ConceptualModel"
type="_2vqKQDNXEeKNpLyJrThh0g" aggregation="composite" association="_5EsvATNXEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_3GG-kDNbEeKNpLyJrThh0g" name="ConceptualInformation">
<ownedAttribute xmi:id="_57Sb8DNbEeKNpLyJrThh0g" name="base_Class" association="_57Sb8TNbEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_LWqGoDNcEeKNpLyJrThh0g" name="isDeprecated" visibility="public">
<type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Boolean"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_LznvcDNcEeKNpLyJrThh0g" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_LzoWgDNcEeKNpLyJrThh0g" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_rdueYDi6EeKcXdUi8X0jpw"/>
</ownedAttribute>
<ownedAttribute xmi:id="_vIpZ8HVgEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_vfB5oHVgEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_vfCgsHVgEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_57Sb8TNbEeKNpLyJrThh0g"
name="E_ConceptualInformation_Class1" memberEnd="_57Sb8jNbEeKNpLyJrThh0g _57Sb8DNbEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_57Sb8jNbEeKNpLyJrThh0g"
name="extension_ConceptualInformation" type="_3GG-kDNbEeKNpLyJrThh0g" aggregation="composite"
association="_57Sb8TNbEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_7kyJUDNbEeKNpLyJrThh0g" name="Observable">
<ownedAttribute xmi:id="_9FOBUDNbEeKNpLyJrThh0g" name="base_Class" association="_9FOBUTNbEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_IkoD4DNcEeKNpLyJrThh0g" name="isDeprecated" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_JgZvoDNcEeKNpLyJrThh0g" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_JgZvoTNcEeKNpLyJrThh0g" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_o2q8kDi6EeKcXdUi8X0jpw"/>
</ownedAttribute>
<ownedAttribute xmi:id="_zUTiEHVgEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_zmtgsHVgEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_zmuHwHVgEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>

</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_9FOBUTNbEeKNpLyJrThh0g" name="E_Observable_Class1"
memberEnd="_9FOBUjNbEeKNpLyJrThh0g _9FOBUDNbEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9FOBUjNbEeKNpLyJrThh0g" name="extension_Observable"
type="_7kyJUDNbEeKNpLyJrThh0g" aggregation="composite" association="_9FOBUTNbEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_Mv1EUDPxEeKNpLyJrThh0g" name="LogicalModel">
<ownedAttribute xmi:id="_O3DPgDPxEeKNpLyJrThh0g" name="base_Package" association="_O3DPgTPxEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_JCSt8HVgEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_JmJo8HVgEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_JmK3EHVgEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_O3DPgTPxEeKNpLyJrThh0g" name="E_LogicalModel_Package1"
memberEnd="_O3DPgjPxEeKNpLyJrThh0g _O3DPgDPxEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_O3DPgjPxEeKNpLyJrThh0g" name="extension_LogicalModel"
type="_Mv1EUDPxEeKNpLyJrThh0g" aggregation="composite" association="_O3DPgTPxEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_lFFhEF34EeK8qagMtO7Vdg" name="ConvertibleElement"
isAbstract="true">
<ownedAttribute xmi:id="_ufgNEF34EeK8qagMtO7Vdg" name="isDeprecated">
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_18hi0F35EeK8qagMtO7Vdg"/>
</ownedAttribute>
<ownedAttribute xmi:id="_VcSx0F35EeK8qagMtO7Vdg" name="base_Class" association="_neA-MTPxEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_Hexa0HViEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_H32CIHViEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_H32pMHViEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_neA-MTPxEeKNpLyJrThh0g" name="E_ConvertibleElement_Class1"
memberEnd="_neA-MjPxEeKNpLyJrThh0g _VcSx0F35EeK8qagMtO7Vdg">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_neA-MjPxEeKNpLyJrThh0g" name="extension_ConvertibleElement"
type="_lFFhEF34EeK8qagMtO7Vdg" aggregation="composite" association="_neA-MTPxEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_mlBgsDPxEeKNpLyJrThh0g" name="Unit">
<generalization xmi:id="_k0aLUF35EeK8qagMtO7Vdg" general="_lFFhEF34EeK8qagMtO7Vdg"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_oeSvcDPxEeKNpLyJrThh0g" name="FrameOfReference">
<generalization xmi:id="_lVllwF35EeK8qagMtO7Vdg" general="_lFFhEF34EeK8qagMtO7Vdg"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_DAq5AFW_EeK1kcktCzck8w" name="LogicalEnumeration">
<ownedAttribute xmi:id="_HWg34FW_EeK1kcktCzck8w" name="isDeprecated">
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_QGlmYFW_EeK1kcktCzck8w"/>
</ownedAttribute>
<ownedAttribute xmi:id="_SnYvMFW_EeK1kcktCzck8w" name="base_Class" association="_SnYvMVW_EeK1kcktCzck8w">
</ownedAttribute>
<ownedAttribute xmi:id="_UKiGUHVjEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_WNzloHVjEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_WN0MsHVjEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_SnYvMVW_EeK1kcktCzck8w" name="E_LogicalEnumeration_Class1"
memberEnd="_SnYvMlW_EeK1kcktCzck8w _SnYvMFW_EeK1kcktCzck8w">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_SnYvMlW_EeK1kcktCzck8w" name="extension_LogicalEnumeration"
type="_DAq5AFW_EeK1kcktCzck8w" aggregation="composite" association="_SnYvMVW_EeK1kcktCzck8w"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_Iym_4HeUEeKusumcOLyDqw" name="EnumLiteral">
<ownedAttribute xmi:id="_MXFMMHeUEeKusumcOLyDqw" name="description">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_ROXEMHeUEeKusumcOLyDqw"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_ROYSUHeUEeKusumcOLyDqw" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_UkcPMHeUEeKusumcOLyDqw" name="base_Property" association="_UkcPMXeUEeKusumcOLyDqw">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_UkcPMXeUEeKusumcOLyDqw" name="E_EnumLiteral_Property1"
memberEnd="_UkcPMneUEeKusumcOLyDqw _UkcPMHeUEeKusumcOLyDqw">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_UkcPMneUEeKusumcOLyDqw" name="extension_EnumLiteral"
type="_Iym_4HeUEeKusumcOLyDqw" aggregation="composite" association="_UkcPMXeUEeKusumcOLyDqw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_DsMToF4BEeK8qagMtO7Vdg" name="ValueElement"
isAbstract="true">
<ownedAttribute xmi:id="_TmqzUF4BEeK8qagMtO7Vdg" name="base_Class" association="_IMAeYTPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_Q-MWwF5lEeK8qagMtO7Vdg" name="valueType" visibility="public"
type="_gIDXwDfXEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_RxyW4F5lEeK8qagMtO7Vdg" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_RxzlAF5lEeK8qagMtO7Vdg" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_Rx1aMF5lEeK8qagMtO7Vdg">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_yPCRMHViEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_ylqBcHViEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_ylqogHViEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_fkE2YKRTEeKnVLeajH9I4w" name="_valueTypeFaceUUID">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_o6qyUKRTEeKnVLeajH9I4w"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_o6sAcKRTEeKnVLeajH9I4w" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_IMAeYTPyEeKNpLyJrThh0g" name="E_ValueElement_Class1"
memberEnd="_IMAeYjPyEeKNpLyJrThh0g _TmqzUF4BEeK8qagMtO7Vdg">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_IMAeYjPyEeKNpLyJrThh0g" name="extension_ValueElement"
type="_DsMToF4BEeK8qagMtO7Vdg" aggregation="composite" association="_IMAeYTPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_BeXhsDPyEeKNpLyJrThh0g" name="LogicalInformation">
<generalization xmi:id="_WM5OsF4BEeK8qagMtO7Vdg" general="_DsMToF4BEeK8qagMtO7Vdg"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_Gk59sDPyEeKNpLyJrThh0g" name="SimpleMeasurement">
<generalization xmi:id="_XRcb8F4BEeK8qagMtO7Vdg" general="_DsMToF4BEeK8qagMtO7Vdg"/>
<ownedAttribute xmi:id="_W90VcDfaEeKh4ss6R8mSnA" name="precision" visibility="public">
<type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Real"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_XPRR0DfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_XPRR0TfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_XPTHADfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_f20WcDfaEeKh4ss6R8mSnA" name="frameOfReference" visibility="public"
type="_oeSvcDPxEeKNpLyJrThh0g">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_gOoZgDfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_gOpAkDfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_gOq1wDfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_ioEWEDfaEeKh4ss6R8mSnA" name="unit" visibility="public"
type="_mlBgsDPxEeKNpLyJrThh0g">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_i8E3MDfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_i8FeQDfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_i8HTcDfaEeKh4ss6R8mSnA">

</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_TUDloF6LEeK8qagMtO7Vdg" name="isDeprecated" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_U-K-EF6LEeK8qagMtO7Vdg" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_U-MMMF6LEeK8qagMtO7Vdg" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_e0pT8F6LEeK8qagMtO7Vdg"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_IjtzwDPyEeKNpLyJrThh0g" name="CompositeMeasurement">
<ownedAttribute xmi:id="_KblUUDPyEeKNpLyJrThh0g" name="base_Class" association="_KblUUTPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_RQbU0DfaEeKh4ss6R8mSnA" name="frameOfReference" visibility="public"
type="_oeSvcDPxEeKNpLyJrThh0g">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_RkuJ0DfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_Rkuw4DfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_Rkv_ADfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_leA0oF6LEeK8qagMtO7Vdg" name="isDeprecated" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_mepLMF6LEeK8qagMtO7Vdg" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_mepyQF6LEeK8qagMtO7Vdg" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_vCEk0F6LEeK8qagMtO7Vdg"/>
</ownedAttribute>
<ownedAttribute xmi:id="_6HMgQHViEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_6hugIHViEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_6hvuQHViEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_KblUUTPyEeKNpLyJrThh0g"
name="E_CompositeMeasurement_Class1" memberEnd="_KblUUjPyEeKNpLyJrThh0g _KblUUDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_KblUUjPyEeKNpLyJrThh0g" name="extension_CompositeMeasurement"
type="_IjtzwDPyEeKNpLyJrThh0g" aggregation="composite" association="_KblUUTPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_GbZP0KRVEeKnVLeajH9I4w" name="MeasurementComposition">
<ownedAttribute xmi:id="_LS9bsKRVEeKnVLeajH9I4w" name="base_Property" association="_LS9bsaRVEeKnVLeajH9I4w">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_LS9bsaRVEeKnVLeajH9I4w"
name="E_MeasurementComposition_Property1" memberEnd="_LS9bsqRVEeKnVLeajH9I4w _LS9bsKRVEeKnVLeajH9I4w">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_LS9bsqRVEeKnVLeajH9I4w"
name="extension_MeasurementComposition" type="_GbZP0KRVEeKnVLeajH9I4w" aggregation="composite"
association="_LS9bsaRVEeKnVLeajH9I4w"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_VHp1cDPyEeKNpLyJrThh0g" name="ValueConstraint">
<ownedAttribute xmi:id="_aGj_cDPyEeKNpLyJrThh0g" name="base_Association"
association="_aGj_cTPyEeKNpLyJrThh0g">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_aGj_cTPyEeKNpLyJrThh0g"
name="E_ValueConstraint_Association1" memberEnd="_aGj_cjPyEeKNpLyJrThh0g _aGj_cDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_aGj_cjPyEeKNpLyJrThh0g" name="extension_ValueConstraint"
type="_VHp1cDPyEeKNpLyJrThh0g" aggregation="composite" association="_aGj_cTPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_atk8IDPyEeKNpLyJrThh0g" name="IntegerRangeConstraint">
<ownedAttribute xmi:id="_cLtuEDPyEeKNpLyJrThh0g" name="base_Class" association="_cLtuETPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_54tngDfZEeKh4ss6R8mSnA" name="lowerBound" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_6O89QDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_6O9kUDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_6O-ycDfZEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_7FfjsDfZEeKh4ss6R8mSnA" name="upperBound" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_7aHI0DfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_7aHv4DfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_7aI-ADfZEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_Nhm1EHVkEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_PHNg8HVkEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_PHOIAHVkEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_cLtuETPyEeKNpLyJrThh0g"
name="E_IntegerRangeConstraint_Class1" memberEnd="_cLtuEjPyEeKNpLyJrThh0g _cLtuEDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_cLtuEjPyEeKNpLyJrThh0g"
name="extension_IntegerRangeConstraint" type="_atk8IDPyEeKNpLyJrThh0g" aggregation="composite"
association="_cLtuETPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_c-LFwDPyEeKNpLyJrThh0g" name="RealRangeConstraint">
<ownedAttribute xmi:id="_ekSH8DPyEeKNpLyJrThh0g" name="base_Class" association="_ekSH8TPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_lablcDfZEeKh4ss6R8mSnA" name="lowerBound" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_mKSVEDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_mKS8IDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_mKUKQDfZEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_ntPVkDfZEeKh4ss6R8mSnA" name="lowerBoundInclusive" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_oE1WMDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_oE19QDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_LRKa0Di7EeKcXdUi8X0jpw" name="" value="true"/>
</ownedAttribute>
<ownedAttribute xmi:id="_pziTsDfZEeKh4ss6R8mSnA" name="upperBound" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_qFPHsDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_qFPuwDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_qFRj8DfZEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_rJR-oDfZEeKh4ss6R8mSnA" name="upperBoundInclusive" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_rgQUMDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_rgQ7QDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_Ox59sDi7EeKcXdUi8X0jpw" value="true"/>
</ownedAttribute>
<ownedAttribute xmi:id="_WzLuIHVkEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_XHg_YHVkEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_XHhmcHVkEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_ekSH8TPyEeKNpLyJrThh0g" name="E_RealRangeConstraint_Class1"
memberEnd="_ekSH8jPyEeKNpLyJrThh0g _ekSH8DPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_ekSH8jPyEeKNpLyJrThh0g" name="extension_RealRangeConstraint"
type="_c-LFwDPyEeKNpLyJrThh0g" aggregation="composite" association="_ekSH8TPyEeKNpLyJrThh0g"/>
</packagedElement>

<packagedElement xmi:type="uml:Stereotype" xmi:id="_fYZFcDPyEeKNpLyJrThh0g"
name="RegularExpressionConstraint">
<ownedAttribute xmi:id="_hpYQoDPyEeKNpLyJrThh0g" name="base_Class" association="_hpYQoTPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="__gxcMDfZEeKh4ss6R8mSnA" name="expression" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="__wi9kDfZEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="__wjkoDfZEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="__wkywDfZEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_S4zjQHVkEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_TP9fAHVkEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_TP-GEHVkEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_hpYQoTPyEeKNpLyJrThh0g"
name="E_RegularExpressionConstraint_Class1" memberEnd="_hpYQojPyEeKNpLyJrThh0g _hpYQoDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_hpYQojPyEeKNpLyJrThh0g"
name="extension_RegularExpressionConstraint" type="_fYZFcDPyEeKNpLyJrThh0g" aggregation="composite"
association="_hpYQoTPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_kq12gDPyEeKNpLyJrThh0g" name="EnumerationSelector">
<ownedAttribute xmi:id="_mbIvcDPyEeKNpLyJrThh0g" name="base_Class" association="_mbJWgDPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_FCQ5IFXGEeK1kcktCzck8w" name="sourceEnumeration" type="_DAq5AFW_EeK1kcktCzck8w"/>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_mbJWgDPyEeKNpLyJrThh0g" name="E_EnumerationSelector_Class1"
memberEnd="_mbJWgTPyEeKNpLyJrThh0g _mbIvcDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_mbJWgTPyEeKNpLyJrThh0g" name="extension_EnumerationSelector"
type="_kq12gDPyEeKNpLyJrThh0g" aggregation="composite" association="_mbJWgDPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_x6B0oDPyEeKNpLyJrThh0g" name="Conversion">
<ownedAttribute xmi:id="_zLYHwDPyEeKNpLyJrThh0g" name="base_Class" association="_zLYHwTPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_B6CIcFW8EeK1kcktCzck8w" name="isDeprecated" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_CsjKgFW8EeK1kcktCzck8w" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_CsjxkFW8EeK1kcktCzck8w" value="1"/>
<defaultValue xmi:type="uml:LiteralBoolean" xmi:id="_lDFV0FW8EeK1kcktCzck8w"/>
</ownedAttribute>
<ownedAttribute xmi:id="_vw7FwF4FEeK8qagMtO7Vdg" name="source" visibility="public"
type="_lFFhEF34EeK8qagMtO7Vdg">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_wfk7gF4FEeK8qagMtO7Vdg" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_wfmJoF4FEeK8qagMtO7Vdg" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_wfn-0F4FEeK8qagMtO7Vdg">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_NZaNkF4GEeK8qagMtO7Vdg" name="target" visibility="public"
type="_lFFhEF34EeK8qagMtO7Vdg">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_RGe8QF4GEeK8qagMtO7Vdg" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_RGgKYF4GEeK8qagMtO7Vdg" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_RGjNsF4GEeK8qagMtO7Vdg">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_izQDMHVjEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_jIlaAHVjEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_jImBEHVjEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_zLYHwTPyEeKNpLyJrThh0g" name="E_Conversion_Class1"
memberEnd="_zLYHwjPyEeKNpLyJrThh0g _zLYHwDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_zLYHwjPyEeKNpLyJrThh0g" name="extension_Conversion"
type="_x6B0oDPyEeKNpLyJrThh0g" aggregation="composite" association="_zLYHwTPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_zfKmcDPyEeKNpLyJrThh0g" name="AffineConversion">
<generalization xmi:id="_RcZYUF36EeK8qagMtO7Vdg" general="_x6B0oDPyEeKNpLyJrThh0g"/>
<ownedAttribute xmi:id="_OQy3wDfWEeKh4ss6R8mSnA" name="conversionFactor" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_O1QPsDfWEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_O1SE4DfWEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_O1T6EDfWEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_URt4YDfWEeKh4ss6R8mSnA" name="offset" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_UnAL4DfWEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_UnAy8DfWEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_UnCBEDfWEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_87wcsDPyEeKNpLyJrThh0g" name="PlatformModel">
<ownedAttribute xmi:id="_-TGDEDPyEeKNpLyJrThh0g" name="base_Package" association="_-TGDETPyEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_R6OX8HVgEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_SUyNAHVgEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_SUy0EHVgEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_-TGDETPyEeKNpLyJrThh0g" name="E_PlatformModel_Package1"
memberEnd="_-TGDEjPyEeKNpLyJrThh0g _-TGDEDPyEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_-TGDEjPyEeKNpLyJrThh0g" name="extension_PlatformModel"
type="_87wcsDPyEeKNpLyJrThh0g" aggregation="composite" association="_-TGDETPyEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="__pMTUDPyEeKNpLyJrThh0g" name="IDLPrimitive">
<ownedAttribute xmi:id="_A9fMwDPzEeKNpLyJrThh0g" name="base_Class" association="_A9fz0DPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_wwnh8DfWEeKh4ss6R8mSnA" name="IDLType" visibility="public" type="_dc-
4oDfXEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_xBpnkDfWEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_xBqOoDfWEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_xBrcwDfWEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_21AGQDfWEeKh4ss6R8mSnA" name="fixedDigits" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_3L1R4DfWEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_3L1R4TfWEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_3L2gADfWEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_7L-GgDfWEeKh4ss6R8mSnA" name="fixedScale" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_7qDJoDfWEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_7qDwsDfWEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_7qE-0DfWEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="__70fYHVkEeKRBpo1mzOWtA" name="description" visibility="public">

<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_BhFNAHVlEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_BhGbIHVlEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_A9fz0DPzEeKNpLyJrThh0g" name="E_IDLPrimitive_Class1"
memberEnd="_A9fz0TPzEeKNpLyJrThh0g _A9fMwDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_A9fz0TPzEeKNpLyJrThh0g" name="extension_IDLPrimitive"
type="__pMTUDPyEeKNpLyJrThh0g" aggregation="composite" association="_A9fz0DPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_BQExkDPzEeKNpLyJrThh0g" name="IDLStruct">
<ownedAttribute xmi:id="_Csz1UDPzEeKNpLyJrThh0g" name="base_Class" association="_Csz1UTPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_qF3fwHVkEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_ruKTQHVkEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_ruLhYHVkEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_Csz1UTPzEeKNpLyJrThh0g" name="E_IDLStruct_Class1"
memberEnd="_Csz1UjPzEeKNpLyJrThh0g _Csz1UDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_Csz1UjPzEeKNpLyJrThh0g" name="extension_IDLStruct"
type="_BQExkDPzEeKNpLyJrThh0g" aggregation="composite" association="_Csz1UTPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_rk9qwHazEeKusumcOLyDqw" name="IDLComposition">
<ownedAttribute xmi:id="_uQyX0HazEeKusumcOLyDqw" name="base_Property" association="_uQyX0XazEeKusumcOLyDqw">
</ownedAttribute>
<ownedAttribute xmi:id="_1_6msHazEeKusumcOLyDqw" name="realizedMeasurementComposition">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_lwMVMH_GEeKvL4Vdnc9d5g"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_lwM8QH_GEeKvL4Vdnc9d5g" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_uQyX0XazEeKusumcOLyDqw" name="E_IDLComposition_Property1"
memberEnd="_uQy-4HazEeKusumcOLyDqw _uQyX0HazEeKusumcOLyDqw">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_uQy-4HazEeKusumcOLyDqw" name="extension_IDLComposition"
type="_rk9qwHazEeKusumcOLyDqw" aggregation="composite" association="_uQyX0XazEeKusumcOLyDqw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_MG4jEDPzEeKNpLyJrThh0g" name="UoPModel">
<ownedAttribute xmi:id="_Pk6JIDPzEeKNpLyJrThh0g" name="base_Package" association="_Pk6JITPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_kceLIHVgEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_kyAWQHVgEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_kyBkYHVgEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_Pk6JITPzEeKNpLyJrThh0g" name="E_UoPModel_Package1"
memberEnd="_Pk6JIjPzEeKNpLyJrThh0g _Pk6JIDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_Pk6JIjPzEeKNpLyJrThh0g" name="extension_UoPModel"
type="_MG4jEDPzEeKNpLyJrThh0g" aggregation="composite" association="_Pk6JITPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_SItioDPzEeKNpLyJrThh0g" name="UnitOfPortability">
<ownedAttribute xmi:id="_TNDUgDPzEeKNpLyJrThh0g" name="base_Class" association="_TNDUgTPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_39Ab0Di1EeKzGuILjx9cFw" name="componentType" visibility="public"
type="_yFMdUDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_4W1REDi1EeKzGuILjx9cFw" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_4W3GQDi1EeKzGuILjx9cFw" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_4W6JkDi1EeKzGuILjx9cFw">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_CqqRUDi2EeKzGuILjx9cFw" name="faceEdition" visibility="public"
type="_wAR_QDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_DNzaoDi2EeKzGuILjx9cFw" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_DN0owDi2EeKzGuILjx9cFw" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_DN2d8Di2EeKzGuILjx9cFw">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_V8EvIDfbEeKh4ss6R8mSnA" name="faceProfile" visibility="public"
type="_u_U4kDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_WXNzADfbEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_WXOaEDfbEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_WXQPQDfbEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_ZChisDfbEeKh4ss6R8mSnA" name="notes" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_ZRhoADfbEeKh4ss6R8mSnA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_ZRiPEDfbEeKh4ss6R8mSnA" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_eUd9cDfbEeKh4ss6R8mSnA" name="partitionType" visibility="public"
type="_zL2jYDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_epUzIDfbEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_epVaMDfbEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_epWoUDfbEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_oWcUEHVlEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_os99sHVlEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_os-kwHVlEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_jPyIkKRSEeKnVLeajH9I4w" name="_aliasSetFaceUUID">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_uYGg0KRSEeKnVLeajH9I4w"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_uYI9EKRSEeKnVLeajH9I4w" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_TNDUgTPzEeKNpLyJrThh0g" name="E_UnitOfPortability_Class1"
memberEnd="_TNDUgjPzEeKNpLyJrThh0g _TNDUgDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_TNDUgjPzEeKNpLyJrThh0g" name="extension_UnitOfPortability"
type="_SItioDPzEeKNpLyJrThh0g" aggregation="composite" association="_TNDUgTPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_GrI-AEnqEeKhaI6O2M8CXg" name="TransportEndpoint">
<ownedAttribute xmi:id="_i6w1cEnqEeKhaI6O2M8CXg" name="base_Association"
association="_i6xcgEnqEeKhaI6O2M8CXg">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_i6xcgEnqEeKhaI6O2M8CXg"
name="E_TransportEndpoint_Association1" memberEnd="_i6xcgUnqEeKhaI6O2M8CXg _i6w1cEnqEeKhaI6O2M8CXg">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_i6xcgUnqEeKhaI6O2M8CXg" name="extension_TransportEndpoint"
type="_GrI-AEnqEeKhaI6O2M8CXg" aggregation="composite" association="_i6xcgEnqEeKhaI6O2M8CXg"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_UrXsoDPzEeKNpLyJrThh0g" name="MessagePort">
<ownedAttribute xmi:id="_WKQFcDPzEeKNpLyJrThh0g" name="base_Class" association="_WKQFcTPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_5Iw70DfaEeKh4ss6R8mSnA" name="communicationStyle" visibility="public"
type="_nrBkgDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_5ZZY0DfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_5ZZ_4DfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_5ZbOADfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>

<ownedAttribute xmi:id="_5jH8kDfaEeKh4ss6R8mSnA" name="messageExchangeType" visibility="public"
type="_lvgTADfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_5vFU8DfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_5vF8ADfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_5vHKIDfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_537u8DfaEeKh4ss6R8mSnA" name="period" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_6HOvMDfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_6HPWQDfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_6HQkYDfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_6OueUDfaEeKh4ss6R8mSnA" name="programmingLanguage" visibility="public"
type="_rl9wEDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_6ZGiUDfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_6ZHJYDfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_6ZIXgDfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_687oIDfaEeKh4ss6R8mSnA" name="synchronizationStyle" visibility="public"
type="_plyoEDfYEeKh4ss6R8mSnA">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_7GqL4DfaEeKh4ss6R8mSnA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_7Gqy8DfaEeKh4ss6R8mSnA" value="1"/>
<defaultValue xmi:type="uml:LiteralString" xmi:id="_7GsBEDfaEeKh4ss6R8mSnA">
</defaultValue>
</ownedAttribute>
<ownedAttribute xmi:id="_iBJl8HVlEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_kntYgHVlEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_knt_kHVlEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_WKQFcTPzEeKNpLyJrThh0g" name="E_MessagePort_Class1"
memberEnd="_WKQFcjPzEeKNpLyJrThh0g _WKQFcDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_WKQFcjPzEeKNpLyJrThh0g" name="extension_MessagePort"
type="_UrXsoDPzEeKNpLyJrThh0g" aggregation="composite" association="_WKQFcTPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_YspwwDPzEeKNpLyJrThh0g" name="MessageType">
<ownedAttribute xmi:id="_rqALkDPzEeKNpLyJrThh0g" name="base_Association"
association="_rqALkTPzEeKNpLyJrThh0g">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_rqALkTPzEeKNpLyJrThh0g" name="E_MessageType_Association1"
memberEnd="_rqALkjPzEeKNpLyJrThh0g _rqALkDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_rqALkjPzEeKNpLyJrThh0g" name="extension_MessageType"
type="_YspwwDPzEeKNpLyJrThh0g" aggregation="composite" association="_rqALkTPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_w5HUwDPzEeKNpLyJrThh0g" name="ApplicationFramework">
<ownedAttribute xmi:id="_x-oyYDPzEeKNpLyJrThh0g" name="base_Class" association="_x-oyYTPzEeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_W6Q6AGmREeKdKM9sFJQ3qA" name="version" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_XmTgoGmREeKdKM9sFJQ3qA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_XmUuwGmREeKdKM9sFJQ3qA" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_wu7B8HVlEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_yXrvgHVlEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_yXs9oHVlEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_x-oyYTPzEeKNpLyJrThh0g"
name="E_ApplicationFramework_Class1" memberEnd="_x-oyYjPzEeKNpLyJrThh0g _x-oyYDPzEeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_x-oyYjPzEeKNpLyJrThh0g" name="extension_ApplicationFramework"
type="_w5HUwDPzEeKNpLyJrThh0g" aggregation="composite" association="_x-oyYTPzEeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_MM0EkDP2EeKNpLyJrThh0g" name="LanguageRunTime">
<ownedAttribute xmi:id="_NK1MADP2EeKNpLyJrThh0g" name="base_Class" association="_NK1zEDP2EeKNpLyJrThh0g">
</ownedAttribute>
<ownedAttribute xmi:id="_l7s44GmREeKdKM9sFJQ3qA" name="version" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_mVaZYGmREeKdKM9sFJQ3qA" value="1"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_mVbngGmREeKdKM9sFJQ3qA" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_s6V9EHVlEeKRBpo1mzOWtA" name="description" visibility="public">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_tVaIcHVlEeKRBpo1mzOWtA"/>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_tVavgHVlEeKRBpo1mzOWtA" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_NK1zEDP2EeKNpLyJrThh0g" name="E_LanguageRunTime_Class1"
memberEnd="_NK1zETP2EeKNpLyJrThh0g _NK1MADP2EeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_NK1zETP2EeKNpLyJrThh0g" name="extension_LanguageRunTime"
type="_MM0EkDP2EeKNpLyJrThh0g" aggregation="composite" association="_NK1zEDP2EeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_RwnEUDP2EeKNpLyJrThh0g" name="SupportingComponent">
<ownedAttribute xmi:id="_SyILsDP2EeKNpLyJrThh0g" name="base_Association"
association="_SyIywDP2EeKNpLyJrThh0g">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_SyIywDP2EeKNpLyJrThh0g"
name="E_SupportingComponent_Association1" memberEnd="_SyIywTP2EeKNpLyJrThh0g _SyILsDP2EeKNpLyJrThh0g">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_SyIywTP2EeKNpLyJrThh0g" name="extension_SupportingComponent"
type="_RwnEUDP2EeKNpLyJrThh0g" aggregation="composite" association="_SyIywDP2EeKNpLyJrThh0g"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype" xmi:id="_hqIosD4xEeK4XOnfNZo-Zg" name="Alias">
<ownedAttribute xmi:id="_jSRrMD4xEeK4XOnfNZo-Zg" name="base_Association" association="_jSRrMT4xEeK4XOnfNZo-
Zg">
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension" xmi:id="_jSRrMT4xEeK4XOnfNZo-Zg" name="E_Alias_Association1"
memberEnd="_jSRrMj4xEeK4XOnfNZo-Zg _jSRrMD4xEeK4XOnfNZo-Zg">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_jSRrMj4xEeK4XOnfNZo-Zg" name="extension_Alias"
type="_hqIosD4xEeK4XOnfNZo-Zg" aggregation="composite" association="_jSRrMT4xEeK4XOnfNZo-Zg"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_dc-4oDfXEeKh4ss6R8mSnA" name="IDLType">
<ownedLiteral xmi:id="_8-ySgDfXEeKh4ss6R8mSnA" name="Boolean"/>
<ownedLiteral xmi:id="__jK60DfXEeKh4ss6R8mSnA" name="Char"/>
<ownedLiteral xmi:id="_HJmgsDfYEeKh4ss6R8mSnA" name="WChar"/>
<ownedLiteral xmi:id="_H9GaMDfYEeKh4ss6R8mSnA" name="Octet"/>
<ownedLiteral xmi:id="_KA5d8DfYEeKh4ss6R8mSnA" name="String"/>
<ownedLiteral xmi:id="_KrnO4DfYEeKh4ss6R8mSnA" name="WString"/>
<ownedLiteral xmi:id="_LTfuQDfYEeKh4ss6R8mSnA" name="Enumeration"/>
<ownedLiteral xmi:id="_Nw3IkDfYEeKh4ss6R8mSnA" name="Float"/>
<ownedLiteral xmi:id="_OfJK4DfYEeKh4ss6R8mSnA" name="Double"/>
<ownedLiteral xmi:id="_PG9_4DfYEeKh4ss6R8mSnA" name="LongDouble"/>
<ownedLiteral xmi:id="_P1WI0DfYEeKh4ss6R8mSnA" name="Fixed"/>
<ownedLiteral xmi:id="_QaNwcDfYEeKh4ss6R8mSnA" name="Short"/>
<ownedLiteral xmi:id="_RHa0sDfYEeKh4ss6R8mSnA" name="Long"/>
<ownedLiteral xmi:id="_RoUiUDfYEeKh4ss6R8mSnA" name="LongLong"/>
<ownedLiteral xmi:id="_TPEdsDfYEeKh4ss6R8mSnA" name="UShort"/>
<ownedLiteral xmi:id="_UHsu0DfYEeKh4ss6R8mSnA" name="ULong"/>
<ownedLiteral xmi:id="_UuaJgDfYEeKh4ss6R8mSnA" name="ULongLong"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_gIDXwDfXEeKh4ss6R8mSnA" name="ValueType">

<ownedLiteral xmi:id="_Wh2dEDfYEeKh4ss6R8mSnA" name="Boolean"/>
<ownedLiteral xmi:id="_YAhagDfYEeKh4ss6R8mSnA" name="Integer"/>
<ownedLiteral xmi:id="_ZDjk0DfYEeKh4ss6R8mSnA" name="Natural"/>
<ownedLiteral xmi:id="_Zu62ADfYEeKh4ss6R8mSnA" name="Real"/>
<ownedLiteral xmi:id="_cUvBsDfYEeKh4ss6R8mSnA" name="NonNegativeReal"/>
<ownedLiteral xmi:id="_dvAnUDfYEeKh4ss6R8mSnA" name="Character"/>
<ownedLiteral xmi:id="_fs1l8DfYEeKh4ss6R8mSnA" name="String"/>
<ownedLiteral xmi:id="_grzIkDfYEeKh4ss6R8mSnA" name="Enumeration"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_lvgTADfYEeKh4ss6R8mSnA" name="MessageExchangeType">
<ownedLiteral xmi:id="_4BW5wDfYEeKh4ss6R8mSnA" name="InboundMessage"/>
<ownedLiteral xmi:id="_5-918DfYEeKh4ss6R8mSnA" name="OutboundMessage"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_nrBkgDfYEeKh4ss6R8mSnA" name="CommunicationStyle">
<ownedLiteral xmi:id="_9jwLUDfYEeKh4ss6R8mSnA" name="Queuing"/>
<ownedLiteral xmi:id="_-vx5kDfYEeKh4ss6R8mSnA" name="SingleInstanceMessaging"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_plyoEDfYEeKh4ss6R8mSnA" name="SynchronizationStyle">
<ownedLiteral xmi:id="_A8Q_QDfZEeKh4ss6R8mSnA" name="Blocking"/>
<ownedLiteral xmi:id="_Bq2jkDfZEeKh4ss6R8mSnA" name="NonBlocking"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_rl9wEDfYEeKh4ss6R8mSnA" name="ProgrammingLanguage">
<ownedLiteral xmi:id="_DzwJwDfZEeKh4ss6R8mSnA" name="C"/>
<ownedLiteral xmi:id="_EeVX0DfZEeKh4ss6R8mSnA" name="CPP"/>
<ownedLiteral xmi:id="_FDRQ4DfZEeKh4ss6R8mSnA" name="Java"/>
<ownedLiteral xmi:id="_FrxbUDfZEeKh4ss6R8mSnA" name="Ada"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_u_U4kDfYEeKh4ss6R8mSnA" name="FaceProfile">
<ownedLiteral xmi:id="_HaniwDfZEeKh4ss6R8mSnA" name="GeneralPurpose"/>
<ownedLiteral xmi:id="_I82KgDfZEeKh4ss6R8mSnA" name="Security"/>
<ownedLiteral xmi:id="_L8BRYDfZEeKh4ss6R8mSnA" name="SafetyBase"/>
<ownedLiteral xmi:id="_M2fVkDfZEeKh4ss6R8mSnA" name="SafetyExtended"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_wAR_QDfYEeKh4ss6R8mSnA" name="FaceEdition">
<ownedLiteral xmi:id="_N_T-0DfZEeKh4ss6R8mSnA" name="_1_0"/>
<ownedLiteral xmi:id="_O7FqkDfZEeKh4ss6R8mSnA" name="_2_0"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_yFMdUDfYEeKh4ss6R8mSnA" name="ComponentType">
<ownedLiteral xmi:id="_QqucMDfZEeKh4ss6R8mSnA" name="Portable"/>
<ownedLiteral xmi:id="_RUo74DfZEeKh4ss6R8mSnA" name="PlatformSpecific"/>
<ownedLiteral xmi:id="_SkSl4DfZEeKh4ss6R8mSnA" name="TransportService"/>
</packagedElement>
<packagedElement xmi:type="uml:Enumeration" xmi:id="_zL2jYDfYEeKh4ss6R8mSnA" name="PartitionType">
<ownedLiteral xmi:id="_VNVrwDfZEeKh4ss6R8mSnA" name="POSIX"/>
<ownedLiteral xmi:id="_WB-NsDfZEeKh4ss6R8mSnA" name="ARINC653"/>
</packagedElement>
</uml:Profile>
C Configuration Services API
C.1 Introduction
The Configuration Services API provides a normalized interface for PSSS components and other
UoPs to obtain configuration information from either a local or centralized configuration service
in a portable manner. The Configuration Services API is part of the OSS.
In cases where the IDL differs from the example source code, the IDL takes precedence.
Note: All IDLs have an identical accompanying source code file that can be downloaded and
used for compilation. The code in this document is formatted to align within Microsoft
Word document formatting constraints.
C.2 Configuration Services API and Message Definitions
FACE_Configuration.idl
#include <FACE_common.idl>
module FACE {
//! This defines the Configuration Application Programming Interface.

interface Configuration {
//! This type is used to represent the handle used during a session
//! with a configuration container.
typedef long HANDLE_TYPE;
//! This type is used to pass implementation specific initialization

//! information to a Configuration API implementation.
typedef string INITIALIZATION_TYPE;
//! This type is used to represent the name of a configuration

//! container.
//! The contents of a configuration container are accessed during a
//! session.
typedef string CONTAINER_NAME_TYPE;
//! This type is used to represent the name of an configuration set

//! within a configuration container.
typedef string SET_NAME_TYPE;
//! This type is for buffers used to obtain configuration items.

typedef SYSTEM_ADDRESS_TYPE BUFFER_TYPE;

//! This type is used to represent the length of the buffer or
//! amount of data returned by Read().
typedef long BUFFER_SIZE_TYPE;
//! This type is used to represent the desired offset used with
//! Seek().
typedef long OFFSET_TYPE;
//! This type is used to represent the specify the whence parameter to
//! Seek(). It indicates the manner in which the offset is to be
//! interpreted.
enum WHENCE_TYPE {
//! This indicates that the offset value is to be interpreted as an
//! offset from the beginning of the file. The offset should be a
//! positive number and represent a position in the file.
SEEK_FROM_START,
//! offset from the current position in the file. The offset may be
//! a positive or negative number to seek backward or forward in the
//! in the file.
SEEK_FROM_CURRENT,
//! offset from the end of the file. The offset should be a
//! negative number and represent how many bytes to back up.
SEEK_FROM_END
};
//! The Initialize method is used to initialize the Configuration

//! implementation.
//!
//! @param[in] initialization_information provides implementation
//! specific information which assists in the initialization of
//! a Configuration API implementation.
//! @param[out] return_code contains a status code indicating success
//!
//! @return NO_ERROR is returned in @a return_code to indicate
//! successful completion of the operation.
//! @return INVALID_PARAM to indicate that the @a return_code pointer
//! (in appropriate languages) is invalid.
void Initialize
( in INITIALIZATION_TYPE initialization_information,
out RETURN_CODE_TYPE return_code);
//! The @a Open method is used to establish a session with the

//! Configuration implementation.
//!
//! @param[in] container_name is the name of the configuration
//! container to open a session with.
//! @param[out] handle contains a handle to be used on subsequent
//! calls during this session.
//! or failure
//!
//! @return INVALID_CONFIG is returned in @a return_code to indicate
//! that the @a configuration container specified is invalid.
//! @return INVALID_PARAM is returned in @a return_code to indicate
//! that the @a handle pointer (in appropriate languages) is
//! invalid.
//! @return INVALID_MODE is returned in @a return_code to indicate
//! the caller does not have permission to access the
//! @a configuration container.
void Open
( in CONTAINER_NAME_TYPE container_name,
out HANDLE_TYPE handle,
//! The @a Read method is used to obtain configuration information

//! from the configuration container associated with this session.
//!
//! @param[in] handle indicates the current session.
//! @param[in] set_name indicates the name of the configuration
//! set to obtain the value of.
//! @param[inout] buffer points to the buffer to be filled in with
//! configuration information.
//! @param[in] buffer_size indicates the size of the @a buffer and
//! the maximum number of bytes which can be returned.
//! @param[out] bytes_read contains the number of bytes read on
//! a successful read.
//! or failure
//!
//! that the @a handle is invalid.
//! that one of the pointer arguments (in the appropriate
//! languages) is invalid.
//! @return NOT_AVAILABLE is returned in @a return_code to indicate
//! that the entire data stream associated with this configuration
//! set has been read.
//!
//! @note For streaming configuration information sources, the
//! @a set_name parameter should be set to "all"
void Read
( in HANDLE_TYPE handle,
in SET_NAME_TYPE set_name,
inout BUFFER_TYPE buffer,
in BUFFER_SIZE_TYPE buffer_size,
out BUFFER_SIZE_TYPE bytes_read,
//! The @a Seek method is used to set the current position indicator
//! in the configuration session.
//!
//! @param[in] handle indicates the current session.

//! @param[in] whence indicates how to interpret the offset parameter.
//! @param[in] offset indicates the desired offset.
//! or failure
//!
//! that the whence @a parameter is invalid, the offset is invalid
//! for the specified value of @a whence, or that the
//! @a return_code pointer (in the appropriate languages)
//! is invalid.
//!
//! @note For some configuration media implementations, the @a Seek
//! operation may not be applicable.
void Seek
in WHENCE_TYPE whence,
in OFFSET_TYPE offset,
//! The Close method is used to conclude a sequence of operations

//! on a configuration handle. It will free any resources allocated
//! during open based on the specific configuration being accessed.
//!
//! @param[in] handle is the session to close
//! @param[out] return_code indicates success or failure
//!
//! that the @a handle is invalid.
void Close
};
};
C.3 Configuration Initialization Service

The Initialize(CONFIG) is used to initialize the Configuration implementation.
/* IDL declaration */
module FACE
{
interface Configuration
{
void Initialize
( in INITIALIZATION_TYPE initialization_information,
};
};
The parameters to this method are as follows:
 initialization_information – provides implementation-specific information which assists in
the initialization of a Configuration API implementation.
 return_code – upon return contains a status code indicating success or failure.
The return_code output parameter contains a value indicating that the method executed
successfully or failed for a specific reason. The return code value returned from
Initialize(CONFIG) is one of the following:
 FACE_NO_ERROR to indicate successful completion of the operation.
 FACE_INVALID_PARAM to indicate that the return_code pointer (in appropriate
languages) is invalid.
C.4 Configuration Open Service

The Open(CONFIG) method is used to establish a session with the Configuration
implementation.
module FACE
{
{
void Open
( in CONTAINER_NAME_TYPE container_name,
out HANDLE_TYPE handle,
};
};

 container_name – the name of the configuration container to open a session with.
 handle – upon return, contains an identifier to be used in future configuration operations
upon this configuration container.
successfully or failed for a specific reason. The return code value returned from Open(CONFIG)
is one of the following:
 FACE_INVALID_CONFIG to indicate that the configuration container specified is
invalid.

 FACE_INVALID_PARAM to indicate that the handle or return_code pointer (in
appropriate languages) is invalid.
 FACE_INVALID_MODE to indicate that the caller does not have permission to access
the configuration container.
C.5 Configuration Read Service

The Read(CONFIG) method is used to obtain configuration information from the configuration
container associated with this session.
module FACE
{
{
void Read
in SET_NAME_TYPE set_name,
inout BUFFER_TYPE buffer,
in BUFFER_SIZE_TYPE buffer_size,
out BUFFER_SIZE_TYPE bytes_read,
};
};

 handle – specifies the configuration session.
 set_name – indicates the name of the configuration set to obtain the value of.
 buffer – points to the buffer to be filled in with configuration information.
 buffer_size – indicates the size of the buffer and the maximum number of bytes which can
be returned.
 bytes_read – contains the number of bytes read on a successful read.
 return_code – upon return contains a status code indicating success or failure
The handle parameter must contain the session handle returned by a previous call to
Open(CONFIG).
The element parameter must contain the name of the configuration element to obtain the value of
or one of the following special configuration element names:
 “all” to indicate that the intent is to read all data from the configuration container as a
stream.
Upon successful return, the memory specified by buffer contains the contents of the requested
configuration element. This value will be bytes_read octets in length. When reading the special
set_name “all” to indicate that the data is to be read as a stream, it is possible that the entire
contents can not be read into the buffer provided. In the event, the size of the buffer provided is
not large enough to contain the entire value and bytes_read will be equal to buffer_size and
subsequent Read() operations may be performed to obtain the remainder of the data. When there
is no more data to obtain, bytes_read may contain zero or larger up to buffer_size and the
return_code will be set to FACE_NOT_AVAILABLE.
successfully or failed for a specific reason. The return code value returned from Read(CONFIG)
 FACE_INVALID_CONFIG to indicate that the handle specified is invalid.
 FACE_INVALID_PARAM to indicate that either the buffer or return_status pointer (in
 FACE_NOT_AVAILABLE to indicate that there is no more data to be read in the
configuration stream “all.” There may be zero or more bytes returned in this case.
C.6 Configuration Seek Service

The Seek(CONFIG) method is used to set the current position indicator for the specified
configuration session.
module FACE
{
{
void Seek
in WHENCE_TYPE whence,
in OFFSET_TYPE offset,
};
};

 handle – specifies the configuration session.
 whence – indicates how the offset parameter is to be interpreted.
 offset – indicates the desired offset within the configuration session.
The whence parameter is used to indicate whether the offset parameter is to be relative to the
beginning of the configuration session, an arbitrary position, or relative to the end of the
configuration session. The whence parameter is of an enumerated type which can have the
following values:

 SEEK_FROM_START – This indicates that the offset value is to be interpreted as an
offset from the beginning of the file. The offset should be a positive number and represent
a position in the file.
 SEEK_FROM_CURRENT – This indicates that the offset value is to be interpreted as an
offset from the current position in the file. The offset may be a positive or negative
number to seek backward or forward in the in the file.
 SEEK_FROM_END – This indicates that the offset value is to be interpreted as an offset
from the end of the file. The offset should be a negative number and represent how many
bytes to back up.
successfully or failed for a specific reason. The return code value returned from Seek(CONFIG)
 FACE_INVALID_PARAM to indicate that the whence parameter is invalid, the offset is
invalid for the specified value of whence, or that the return_code pointer (in the
Note: This method may not be supported by all underlying configuration media.
C.7 Configuration Close Service

The Close(CONFIG) method is used to terminate a session with the Configuration
implementation.
module FACE
{
{
void Close
};
};

 handle – upon return, contains an identifier to be used in future configuration operations
upon this configuration container.
successfully or failed for a specific reason. The return code value returned from Close(CONFIG)

D Standard Color Index
Color names and values are taken from www.w3.org/TR/css3-color.
Color Index Color Name Default Color Value
0 Black 0x000000
1 White 0xFFFFFF
2 AliceBlue 0xF0F8FF
3 AntiqueWhite 0xFAEBD7
4 Aqua 0x00FFFF
5 Aquamarine 0x7FFFD4
6 Azure 0xF0FFFF
7 Beige 0xF5F5DC
8 Bisque 0xFFE4C4
9 BlanchedAlmond 0xFFEBCD
10 Blue 0x0000FF
11 BlueViolet 0x8A2BE2
12 Brown 0xA52A2A
13 BurlyWood 0xDEB887
14 CadetBlue 0x5F9EA0
15 Chartreuse 0x7FFF00
16 Chocolate 0xD2691E
17 Coral 0xFF7F50
18 CornflowerBlue 0x6495ED
19 Cornsilk 0xFFF8DC
20 Crimson 0xDC143C
21 Cyan 0x00FFFF
22 DarkBlue 0x00008B
23 DarkCyan 0x008B8B
24 DarkGoldenRod 0xB8860B
25 DarkGray 0xA9A9A9
26 DarkGreen 0x006400
27 DarkKhaki 0xBDB76B
28 DarkMagenta 0x8B008B
29 DarkOliveGreen 0x556B2F
30 Darkorange 0xFF8C00
31 DarkOrchid 0x9932CC
32 DarkRed 0x8B0000
33 DarkSalmon 0xE9967A
34 DarkSeaGreen 0x8FBC8F
35 DarkSlateBlue 0x483D8B
36 DarkSlateGray 0x2F4F4F
37 DarkTurquoise 0x00CED1
38 DarkViolet 0x9400D3
39 DeepPink 0xFF1493
40 DeepSkyBlue 0x00BFFF
41 DimGray 0x696969
42 DimGrey 0x696969
43 DodgerBlue 0x1E90FF
44 FireBrick 0xB22222
45 FloralWhite 0xFFFAF0
46 ForestGreen 0x228B22
47 Fuchsia 0xFF00FF

48 Gainsboro 0xDCDCDC
49 GhostWhite 0xF8F8FF
50 Gold 0xFFD700
51 GoldenRod 0xDAA520
52 Gray 0x808080
53 Green 0x008000
54 GreenYellow 0xADFF2F
55 HoneyDew 0xF0FFF0
56 HotPink 0xFF69B4
57 IndianRed 0xCD5C5C
58 Indigo 0x4B0082
59 Ivory 0xFFFFF0
60 Khaki 0xF0E68C
61 Lavender 0xE6E6FA
62 LavenderBlush 0xFFF0F5
63 LawnGreen 0x7CFC00
64 LemonChiffon 0xFFFACD
65 LightBlue 0xADD8E6
66 LightCoral 0xF08080
67 LightCyan 0xE0FFFF
68 LightGoldenRodYellow 0xFAFAD2
69 LightGray 0xD3D3D3
70 LightGreen 0x90EE90
71 LightPink 0xFFB6C1
72 LightSalmon 0xFFA07A
73 LightSeaGreen 0x20B2AA
74 LightSkyBlue 0x87CEFA
75 LightSlateGray 0x778899
76 LightSteelBlue 0xB0C4DE
77 LightYellow 0xFFFFE0
78 Lime 0x00FF00
79 LimeGreen 0x32CD32
80 Linen 0xFAF0E6
81 Magenta 0xFF00FF
82 Maroon 0x800000
83 MediumAquaMarine 0x66CDAA
84 MediumBlue 0x0000CD
85 MediumOrchid 0xBA55D3
86 MediumPurple 0x9370DB
87 MediumSeaGreen 0x3CB371
88 MediumSlateBlue 0x7B68EE
89 MediumSpringGreen 0x00FA9A
90 MediumTurquoise 0x48D1CC
91 MediumVioletRed 0xC71585
92 MidnightBlue 0x191970
93 MintCream 0xF5FFFA
94 MistyRose 0xFFE4E1
95 Moccasin 0xFFE4B5
96 NavajoWhite 0xFFDEAD
97 Navy 0x000080
98 OldLace 0xFDF5E6
99 Olive 0x808000

100 OliveDrab 0x6B8E23
101 Orange 0xFFA500
102 OrangeRed 0xFF4500
103 Orchid 0xDA70D6
104 PaleGoldenRod 0xEEE8AA
105 PaleGreen 0x98FB98
106 PaleTurquoise 0xAFEEEE
107 PaleVioletRed 0xDB7093
108 PapayaWhip 0xFFEFD5
109 PeachPuff 0xFFDAB9
110 Peru 0xCD853F
111 Pink 0xFFC0CB
112 Plum 0xDDA0DD
113 PowderBlue 0xB0E0E6
114 Purple 0x800080
115 Red 0xFF0000
116 RosyBrown 0xBC8F8F
117 RoyalBlue 0x4169E1
118 SaddleBrown 0x8B4513
119 Salmon 0xFA8072
120 SandyBrown 0xF4A460
121 SeaGreen 0x2E8B57
122 SeaShell 0xFFF5EE
123 Sienna 0xA0522D
124 Silver 0xC0C0C0
125 SkyBlue 0x87CEEB
126 SlateBlue 0x6A5ACD
127 SlateGray 0x708090
128 Snow 0xFFFAFA
129 SpringGreen 0x00FF7F
130 SteelBlue 0x4682B4
131 Tan 0xD2B48C
132 Teal 0x008080
133 Thistle 0xD8BFD8
134 Tomato 0xFF6347
135 Turquoise 0x40E0D0
136 Violet 0xEE82EE
137 Wheat 0xF5DEB3
138 WhiteSmoke 0xF5F5F5
139 Yellow 0xFFFF00
140 YellowGreen 0x9ACD32

E XSD Schema for Configuration File
This appendix contains the schema definition supporting the description of the I/O and TS
configuration data as given in the FACE Technical Standard, Edition 2.1, Sections D.12 and E.5,
respectively.
E.1 Schema
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="connection_list">
<xs:complexType>
<xs:sequence>
<xs:element name="connection" type="connection_Type" maxOccurs="unbounded"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="connection_Type">
<xs:sequence>
<xs:element name="name" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="type" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="direction" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="createconnection" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="portname" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="messagesize" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="messagerange" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="refreshperiod" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="reliability" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="readwrite_behav" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="queue_discipline" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="domain" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="sockettype" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="receiveflag" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="sendflag" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="sourceaddress" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="destinationaddress" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="sourceport" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="destinationport" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="iotype" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="threadlist" type="threadlist_Type" maxOccurs="1" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="threadlist_Type">
<xs:sequence>
<xs:element name="priority" type="xs:integer" maxOccurs="1" minOccurs="0"/>
<xs:element name="schedulingpolicy" type="xs:string" maxOccurs="1" minOccurs="0"/>
<xs:element name="threadrate" type="xs:integer" maxOccurs="1" minOccurs="0"/>
<xs:element name="threadstacksize" type="xs:integer" maxOccurs="1" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

F Safety Guidance
While software itself is an abstraction, and thus has no substance and cannot directly harm
people, property, or the environment – it is the nature of the software’s sensing and control of
physical components within a system and its environment that render that system safe or not.
Safety of software, then, depends on the combined interactions of the software with hardware,
system operator, and external factors. Leveson’s definition3 of software system safety, while
consistent with the Naval Sea Systems Command (NAVSEA) definition of software safety, is
more explicit about this dependency:
“Software System Safety implies that the software will execute within a system context without
contributing to hazards.”
F.1 Safety Overview

In very general terms, system developers must convince a qualification authority that they
achieve a level of safety appropriate to the potential hazards inherent in the system in order to
attain authorization to field avionics that include a software base. A developer must establish the
following at a level of detail that matches the criticality established through safety analysis:
The system software results from the correct set of high-level requirements, decomposed into
lower-level requirements, from which code was generated to implement the functions defined
thereby. Further, no functionality is implemented in the software that is not described by the
requirements. The requirements must (all) be shown to be represented by a set of test
procedures, execution of which verifies that the software correctly implements the requirements;
it must be documented that the tests were executed with acceptable results. The software must be
proven to produce exactly one result when presented with a given set of inputs. Traceability of
the requirements to the software and to the tests must be documented in a manner conducive to
evaluation of these concerns.
Additionally, a developer must provide documentation showing that proper development

procedure, CM, and Quality Assurance (QA) are incorporated into the program, and that a plan
is established to address software maintenance and revision procedures that protects the integrity
of the aforementioned considerations.
The documentation artifacts required by an Airworthiness Authority are not goals in and of
themselves; they are documentation showing that the proper goals were achieved during the
program. Early generation of the appropriate plans and coordination of their content with the
cognizant Airworthiness Authority increases the likelihood of efficient achievement.
3
Taken from SafeWare: System Safety and Computers, Nancy Leveson, Addison-Wesley, 1995.
It is absolutely impractical to properly achieve the goals associated with this documentation in
retrospect at the program's end. Early, in-depth involvement of the qualifying authority is key to
achieving efficiency in this process through:
 Providing engineering cognizance of the various development processes
 Establishing agreement as to task requirements that lead most directly to qualification
 Agreement that goals are achieved at the appropriate program phase
Conformance to the FACE Safety Profile is intended to impose the following key attributes that
support qualification, depending on the evaluated criticality level:
 Non-interference between applications
 Non-interference between applications and the operational environment
 Non-interference between applications and external interfaces
 Software fault isolation
 Software fault recovery
 Reliable information flow between applications
 Reliable information flow between applications and the external interfaces
 Integrated health monitoring and management
 Standards-based system configuration data
F.2 Purpose
This text applies to reuse of portable software components, particularly those developed
specifically for reuse. Integrators accept the software component, and its associated
documentation plan, and perform the technical work to integrate that software component into a
software system. Integrators then seek a certification of airworthiness from the appropriate
Airworthiness Authority, based on the evaluation of a documented qualification effort. To make
the case for qualification of the software system that incorporates the component, the integrator
offers documentation that was delivered with the software component, and also provides
substantiation that all additional qualification objectives have been satisfied.
F.3 Applicability
In addition to the airworthiness qualification requirements defined by the cognizant military
authority, systems incorporating FACE software components may fall under the requirements
applied by Civil authorities. DoD aircraft operating in the National Airspace (NAS) must
consider those requirements, and similarly must address the requirements of international
regulatory authorities for airspace in which they operate; e.g., International Civil Aviation
Organization (ICAO), etc.

In general, these Civil requirements are more stringent than those imposed by DoD agencies,
although, for obvious reasons, they are somewhat in alignment.
F.4 Safety Assessment and Design Assurance Level

Safety-related software components are those for which a safety analysis has determined that a
high level of criticality exists, requiring achievement of qualification tasks and documentation of
development practices consistent with a high level of rigor. Since this qualification potentially
represents significant impact in terms of cost and schedule, it is important that criticality be
properly established for prioritization and planning of qualification early during the program. At
a high level, the following sections address safety concerns for software.
F.4.1 Start Assessment Very Early and Update as the Program Progresses
Every system development must include a safety program, which necessarily includes a Safety
Assessment Process.
The Safety Assessment (SA) process provides a methodology to evaluate aircraft functions and
the design of systems performing these functions, and seeks to establish that the associated
hazards have been addressed.
The SA process for a system must establish that all failure conditions and significant
combinations failures have been considered, including additional complexities arising from
integrated system architectures.
At a top level, stated in common terminology, the SA process comprises a Functional Hazard
Assessment (FHA), a Preliminary System Safety Assessment (PSSA), and a final System Safety
Assessment (SSA). The SA process is iterative, tracking the system development as it
progresses, and should be executed as an inherent part of this process. As the program
progresses, it is expected that each analysis will be revised. The software development plan can
be used to document this strategy.
The SA process begins with concept design, and derives any safety requirements for the design.
These derived safety requirements are documented as part of the software requirements, and are
expected to trace directly to source code and test cases for verification of implementation.
The endpoint of the SA process is definition of the safety and safety-related requirements as
input to evaluation of criticality for software components. The SA process concludes with
verification that the design meets the safety requirements.
The FHA identifies and classifies the failure conditions associated with the aircraft functions
(and combinations thereof) at the beginning of the development cycle. Classification of failure
conditions (establishing criticality) establishes the safety objectives.
The output of the FHA is input to the PSSA.
The PSSA is a systematic examination of the proposed system architecture(s) to determine how
failures can cause the functional hazards identified by the FHA. The goal is to establish system
safety requirements; these are derived requirements (not traced directly from higher-level
requirements), that require verification as part of qualification to determine compliance with the
system safety plan.
The SSA is a systematic, comprehensive evaluation of the implemented system to show that
safety objectives from the FHA and derived safety requirements from the PSSA are met.
Requirements at all levels that trace to safety-related functionality must be identified, since they
impact criticality evaluations, engineering trade space decisions, and regression testing required
by software maintenance and revision.
A software Failure Modes Effects Analysis (FMEA) is also a systematic and comprehensive
evaluation from a bottom-up view of the system. The effects of failures within the system on the
end result are determined. An FMEA is encouraged to understand the ramifications of such
errors.
F.5 Design Assurance Level and Qualification Cost are Directly

Proportional
F.5.1 Assess Criticality During First Application, or as Part of a Notional
Application
Limitations of cost and schedule drive software developers to plan and execute qualification at
the lowest practical level of criticality. For that reason, proper assessment of criticality is key to
integrating the proper processes, qualification activities, and documentation into the engineering
effort from the start (refer, for example, to the qualification objectives listed for criticality levels
A through E in the RTCA DO-178B/C). Developers face the challenge of cost-effectively
engineering and marketing portable software for integration into systems where the criticality
level is not known. If it is not practical for a developer to work for qualification at the highest
level of criticality, then a software component must be developed as part of some real or notional
system of “typical” criticality.
It is not possible to demonstrate some aspects of qualification in the absence of a supporting

system. In fact, it is not likely that all of the development can be done without some notion of a
system around a component (e.g., debugging logic, unit testing).
Although most FACE components might be developed as part of complete systems, the context
of FACE does open up a market for software developed specifically as portable components, and
suppliers should consider the qualification implications for the integrators of their software to
maximize reuse.
F.5.2 Plan for Future Use of Functionality at a Higher Design Assurance Level
The expense associated with qualification varies significantly (~25%-150% of the project cost)
with the assessed criticality of the functionality provided by software. The immediate benefits of
qualification at the initially assessed level of criticality may be outweighed, however, by the
long-term benefit of increased use of one’s software if accompanied by artifacts that support
qualification at higher levels. Therefore, suppliers of FACE software components should
consider achievement of a higher level of qualification than immediately necessary, and to
reflect a higher level of documentation in the FACE Registry.

F.5.3 Safety Assessment May Vary by Context
Integrators of FACE software components should be aware that the hazard evaluation of
functionality in their system may result in the need to qualify those components at a higher level
of criticality than can be substantiated by the artifacts available from the component supplier.
This situation represents a significant risk in terms of cost and schedule if artifacts to support
qualification at a higher level must be reverse engineered, or if increased levels of test or
structural/coverage analysis are necessary. If significant particular artifacts are not available, it
may not be possible to generate them, leaving a significant deficit in an integrator’s qualification
picture when seeking Airworthiness Release (AWR). Suppliers of FACE components and
subsequent integrators should cooperate early to guard against this, and should coordinate with
Airworthiness Authorities to document and execute a qualification program that leads to
successful flight release and fielding.
F.5.4 Plan for the Most Critical Application

Portable software components are particularly likely to see use in new contexts that were not
foreseen by their developers. This is likely to be true when software components provide support
elements or generic services. It is also possible that a software component provides functionality
that has safety implications in a new integration that are higher than those provided in the initial
system. The functionality provided by portable software components could be evaluated to have
a higher criticality by a different Airworthiness Authority considering a subsequent integration.
To ensure the broadest audience for FACE software components, a developer should consider,
and evaluate the expense of, qualifying their software at higher levels of rigor if they intend to
provide qualification artifacts to aid subsequent integrators when they seek qualification for their
systems.
F.5.5 Safety Assessment of Configurable Software

Implications of configurable software require special consideration during safety assessment to
ensure that consequences of incorrect operation are considered.
The qualification strategy for complex software may include the concept of configurability at
run-time. This configurability is usually based on the contents of small configuration files, read
by the software during start-up, that cause operation to take a variety of configurations. This
alleviates the generation and maintenance of many different software loads, rather than one
larger application that can accommodate these configurations, although the qualification effort
may be somewhat greater because of the increased complexity. Other methods of configurability
include hardware strapping and user interface via entry of codes or option selections while the
software is in maintenance mode; particular attention to allowances for “dead and deactivated”
code is advised, and early coordination of approach is key to efficiency in development and
qualification.
Developers and users of software components may need to address configurability as they seek
flight release for their systems in their plan for qualification, which must address the variability
associated with configurability. Application of this concept is likely to result in a code base that
includes “deactivated code” that traces to software requirements, is documented, tested, and
managed with the rest of the software, but which is not always executed for specific operational
configurations. Consensus with the Airworthiness Authority for this approach is required. Also,
additional testing must verify the proper operation of the configuration mechanisms of the
software, and must include robustness testing that proves the fault tolerance of the final product.
Response of the software to invalid configuration information (out-of-bounds and incorrect
values, etc.) must be shown to be in conformance with formal requirements, with no adverse
effects.
Qualification of an integration that includes configurable software components can become a

complex issue that requires careful coordination. Careful design is required to achieve the
perceived benefits.
F.6 Qualification Advantage of Various Software Reuse Strategies

F.6.1 Basic Principles of Software Qualification
In order to ensure safety in Civil aviation, the Federal Aviation Administration (FAA) evaluates
a supplier’s plans, execution, and documentation of their processes for the development,
verification, CM, and maintenance of software in their products. Suppliers of software used in
military avionics must consider more than safety, including items relevant to ensuring mission
support. This results in the imposition of more qualification requirements. Suppliers of software
who participate in military acquisitions will be subject to a mix of these requirements, based on
situation, including Civil applicability, Airworthiness Authority agreements, etc.
As technology progresses, the tools available to generate software improve, resulting in an

exponential growth in the volume and complexity of software systems. Consequently, it has
become impractical or impossible to generate a complete set of tests to verify an implementation
in every respect. Therefore, the evaluation of criticality, imposition of various levels of rigor in
verification, and additional focus on QA, configuration control, tool quality, requirements
traceability, and documentation is necessary to achieve acceptable levels of safety and to ensure
mission capability to the appropriate level of rigor.
Core elements that comprise the qualification picture include:

 Definition of user need
 Definition of system requirements
 Functional and hazard analyses to establish criticality and therefore required level of rigor
(Design Assurance Level (DAL), or whatever the relevant evaluation is called)
 Identification of safety-related requirements
 Decomposition of system requirements into detailed software requirements
 Generation of software source code that implements the software requirements
 Generation of a sufficient set of tests to show that the software implements its
requirements
 Test report proving that the software implements its requirements (“pass”)

 Traceability document(s) showing the mapping of 1 to 2 to 4 to 6 and 7 (including proof
that the software doesn’t implement anything not in 2 and 5, which proves “bidirectional
traceability”)
 Version description/CM
 Lifecycle support plan (error collection/correction and distribution)
 All other artifacts that provide the details required by the cognizant Airworthiness
Authority
The level of rigor defines the set of particular artifacts that are required, and definition of the
circumstances under which they must be developed, verified, delivered, and maintained.
Achievement of proof of qualification represents a significant expense in terms of cost and
schedule that can increase dramatically with increasing level of criticality. It is therefore
important to properly perform functional and hazard analyses early in the development cycle to
establish the qualification objectives that must be achieved, since many of the requirements are
best executed at the appropriate stages of development (early) rather than by post-documentation
at later program stages. Some artifacts are effectively useless if written late in a program simply
to satisfy documentation requirements (i.e., a software development plan).
The qualification effort should consist of executing a valid engineering process to generate
system software and documenting that process, and its achievements. Therefore, this effort is
best executed according to a formal agreement, established early with the correct qualification
authority and maintained at each phase, rather than through a flurry of document generation
immediately before seeking a flight release. The latter approach is less efficient, less accurate,
and more expensive.
For FACE software components, the qualification process is complicated by the intent to
generate software components that can be integrated into many software systems. In order to
achieve the stated goal of reducing development effort, integration costs, and time-to-field
avionics capabilities, suppliers of FACE conformant software components should consider the
qualification implications of their products, and coordinate with the appropriate release authority
in the initial stages of software development or execution of programs that incorporate FACE
conformant software components into the software (i.e., “reuse”).
F.6.2 Additional Qualification Considerations
F.6.3 Memory Management

Proper memory management of code requires ensuring any memory allocated is properly
deallocated to return memory to the heap. If dynamic memory allocation is used, improper
management of memory may result in memory leaks, resulting in anomalous behavior. For
safety-critical code, static allocation of memory should be employed so that memory
requirements are defined before, during, and after program execution. Stack and heap areas of
memory cannot be allowed to overflow the memory space allocated, which often propagates
execution errors.
Proper pointer management is also critical to ensure correct operation. Use of dynamic memory
allocation is not recommended due to possible access conflicts (although mechanisms can be
incorporated and qualified to alleviate this concern). Proper management of cache use must be
substantiated (it is likely that this issue will present qualification challenges in multi-core
applications in the future).
In this regard (and others), the guidelines for restricting use of specific high-level languages
should be applied to support qualification at the level of rigor associated with the FHA.
Examples would be: adherence to the Motor Industry Software Reliability Association (MISRA)
restrictions for C, the Ravenscar restrictions for Ada, and similar restrictions for C++ and Java
(if available, and useful in safety-related qualifications, per the cognizant Airworthiness
Authority).
Some level of requirements-based and robustness testing should be done to assure proper
memory management.
F.6.4 File Management

File system management is also critical to proper operation when opening, read/write locking
access, and closing files. If a file is opened for operations then it must be closed properly. If
multiple readers and writers are operating on the file then proper locking mechanisms should be
managed to prevent corrupting the files. Inadvertent closure of files during operation should be
prevented or handled properly by exception processing. The integrity of data within the file
should be ensured via a cyclic redundancy check or checksum. Some level of requirements-
based and robustness testing should be done to assure proper file handling (this implies that there
should be requirements defining the system’s characteristics in these areas).
F.6.5 Concurrency Management (Semaphores, Mutexes)

The spurious effects of a multiple threaded system without proper concurrency management can
lead to entrance into indeterminate states. Mutexes and semaphores must be properly employed.
Some level of requirements-based and robustness testing should be done to assure proper
concurrency handling, implying that detailed requirements should exist to define these aspects of
the software.
F.7 Overview of the Principles of Portable Software

Given the qualification overview above, the reuse of software at any criticality level where
artifacts are to be reused or any qualification credit is sought requires special attention to
qualification when selecting components for reuse and when engineering a solution that includes
them. The following key concepts apply:
F.7.1 Documentation of Early Agreement

As with any software qualification, but especially true when a reuse strategy includes flight
release requirements, early coordination of a reuse approach amongst the stakeholders is key to
achieving an efficient qualification. Stakeholders include the developer, first integrator (if
different), the cognizant Airworthiness Authority, and any other entity involved in the
qualification effort.

F.7.2 Specific Achievements for Portable Software during the First Qualification
Developers of software components can significantly impact the marketability of their
components by planning a qualification effort that includes the precepts of reuse that apply to
their organization. Since these vary by service and situation, a developer should have a plan and
seek coordination early, adjusting course as necessary to maximize effective reuse. Developers
should also document reusable components separately and coordinate “qualification with reuse”
as a specific goal.
F.7.3 Achievements Remaining for Re-Application of Portable Software

Developers should evaluate the qualification objectives that cannot be met during qualification
of their component(s), and document these for use by subsequent integrators (e.g., customers).
Prudent integrators will insist on the existence of proper artifacts to ensure their success in their
own qualification efforts, and savvy suppliers of FACE components will work to accommodate
them.
F.7.4 Qualification of Portable Software as Part of a System Qualification

Civil guidance for qualification of software components with the intent of reuse includes
qualification of the software components first as part of a software system. This seemingly
prohibitive requirement makes sense when one considers that the nature of qualification
pervasively concerns itself with verification of implementation of all software requirements, and
this implies testing the implementation of the requirements that define the interfaces of the
software component. Without qualification of the interfaces, the operation of the software cannot
be fully verified and, therefore, the qualification would be significantly deficient without it.
Suppliers who do not qualify their FACE components before posting to the FACE Registry for
consumption should plan to support the qualification efforts of the integrators of their software,
and integrators should be aware of the significant qualification implications of using software
with no qualification pedigree.
The FACE Conformance Policy allows a software supplier to decide to list a software
component in the FACE Registry at any time after achieving FACE Conformance Certification.
Therefore, suppliers who wish to complete the FACE Conformance Certification process may do
so in advance of completing qualification of the components as part of a system, and then list the
components in the FACE Registry with the qualification pedigree. Considerations for the extent
of qualification credit are subject to terms that are discussed elsewhere in this section.
Separate Documentation Requirements for Portable Software
Software components that are first qualified as part of a complete software system should be
separately documented. Submission of system qualification artifacts with a FACE software
component to the FACE Registry puts the integrators of those software components at risk by
requiring that they disentangle the qualification picture for the software components from the
documentation of the entire system of which they were originally a part.
Those who reuse existing software components in subsequent system developments must
consider installation, safety, security, operational, functional, and performance issues for each
project; the integration of software components into new applications has technical and
qualification implications. Integrators should expect that their airworthiness certification
agencies will require them to substantiate not only the qualification of the FACE software
components they integrate, but the quality of the integration, and the suitability of the reuse
components, from both a functional and a safety perspective, to application in their systems.
Analysis of performance may also be required to show suitability in a given integration.
F.8 Types of Reuse

F.8.1 Binary Reuse
Reuse of binary software modules, while offering the greatest qualification advantage, imposes
stringent documentation of configuration and satisfaction of qualification objectives, and
restricts use to those software operating environments that match those present when the
software component was originally qualified. Alteration of the binary of this type of software
reuse module tends to negate the stated qualification advantages, and is subject to review and
concurrence by the appropriate authority. Software reuse at a binary level requires careful
coordination with the certifying Airworthiness Authority.
F.8.2 Source Code Reuse

Probably a more common mode of software reuse is the integration of previously developed
source code. Reuse of code at this level broadens the range of reuse by accommodating
additional hardware configurations, software environments, compilers, libraries, frameworks,
and virtual machines. While qualification of the final binary is required, great advantage is
available through reuse of artifacts such as high and low-level requirements, development
documentation, algorithmic verifications, and particularly reuse of traceability information that
substantiates the decomposition of the design requirements as they relate to the software
functions. If properly developed and documented, and especially when properly automated, the
verification test suite can be made reusable as well.
F.8.3 Reuse of Artifacts

Reuse of software at any level lends itself to the reuse of documentation artifacts that
substantiate the engineering and qualification process. For software developments where the
component is intended for reuse, developers should generate these artifacts separately for the
reusable component(s). This allows them to be part of the delivery, and clarifies the parts of each
artifact that apply to the reuse case. Reuse of artifacts that describe the whole software
development that were used during initial qualification are not specific to the reusable
component, and the extra content would lead to confusion.
F.9 Types of Artifacts

F.9.1 Requirements
Well-written requirements are the basis for the development, documentation, and qualification
efforts of software components. Reuse increases the importance of quality requirements, in that
subsequent integrators must rely on the requirements to communicate the characteristics of the
software component for their own use, and for use in their qualification efforts.

Attributes of quality requirements are:
 Testable (verifiable)
 Code-able (all requirements must trace to code)
 Singular (one “shall” per paragraph)
 Self-contained (requirements do not inherit requirements from referenced sources, nor do
they depend on definitions nor specifications stated elsewhere)
 Imposes requirements (“system shall have as a goal” is not a meaningful requirement)
 Consistent (requirements aren’t conflicting)
 Complete (all software traces to specific requirements, and all requirements are
implemented in code)
 Unambiguous (specific enough to be testable and useful in established test coverage – for
example, “system X shall operate when the landing gear are down” may mean that a
positive gear down indication is read from the hardware, but could be misconstrued as: the
“gear up and locked” indicator is “off”. These are two distinctly different conditions if the
gear didn’t fully deploy). Accurate coding absolutely depends on the quality of the
requirements.
 Positive (i.e., “not negative”; “diagnostics shall not impact system performance” is both
vague and untestable, in that one cannot prove that there will never be an impact, and it is
not specified what an “impact” consists of)
Consequences of poorly written requirements:

 Poor product quality
 Not meeting customer needs
 Increased development/rework cost
 Requirements volatility
 Program delays (rework, retest, field maintenance)
 Incomplete/wrong validation and verification (rework, retest, reduced safety,
functionality)
 Increased rework/maintenance cost
Analysis has shown that the cost to fix a software problem increases exponentially as it is
discovered later in the lifecycle. Good requirements result in better unit testing and earlier
problem resolution.
In order to properly reuse a software component, detailed information must be available as to the
functionality that it provides. When qualifying a software system that incorporates a particular
portable software component, the requirements for the portable component will be central to the
verification of the implementation in software for that component. Each requirement must have a
program-unique identifier for use in establishing traceability from high to low-level
requirements, from requirements to verification, and from requirements to code. Also, each
requirement involved in the implementation of safety-critical functionality must be so identified.
During regression testing, the software that implements safety-critical functionality must be
retested.
A key characteristic of FACE software components that are engineered for reuse is that their set
of requirements can be used to document the component in the context of a new integration with
no modification, or possibly with little modification.
F.9.2 Tests
Test documentation typically consists of a test plan and a test description. In general, the test
plan provides an overview and the general terms of verification testing, and the test description
gives the specific details of the tests that will be executed to verify the software implementation.
The test plan may be generic enough to describe testing for the portable software component as
well as for the entire software suite (during initial qualification), but the test description must
separately detail the test steps defined to verify the implementation of each requirement in the
portable software component.
The test plan should document the procedure for recording red-line changes to the test sequence
discovered during testing, and the procedure for feeding these changes back into the test
sequence to ensure accurate testing in the future. This is particularly critical to test plans and
descriptions that accompany portable software components for integration testing or verification
of compiled code during the qualification activities for subsequent Integrations.
Testing that verifies the operation of interfaces to the portable software component must also be
detailed in the test description or in other documentation. This is critical to the qualification of
the new integration of a software component into a new software system, and represents a
critical component of the qualification objectives that remain to be done by an integrator.
A key characteristic of FACE software components is that they have a set of tests that can be
used and reused, to verify that an executable implements the detailed requirements for the
component.
F.9.3 Traceability
Traceability refers to an evaluator’s ability to analytically establish the following:
A User Need resulted in definition of a set of System Requirements that were decomposed into a
set of detailed Software Requirements, from which software source code was generated. To
verify this, a sufficient set of accurate tests were defined and executed to establish that all of the
software requirements were correctly implemented.
Bi-directional traceability exists when no software was generated that did not originate from the
defined software requirements. Software that does not trace to requirements will not be traceable
to tests that verify its implementation (unless there are tests that don’t trace to requirements,
which further complicates the qualification picture).

In order to evaluate qualification status for a certification decision, an evaluator must be able to
establish traceability using the documentation provided with the software. Reusable software
components must be provided with traceability documentation specific to the software
component, not documentation of the entire system of which the component was originally a
part.
In order for a qualification analysis to include substantiation that a test suite has been executed
that verifies the implementation of a FACE software component’s detailed requirements, the
traceability of the requirements to the software and to the set of tests must be provided.
Again, each requirement must have a program-unique identifier for use in establishing
traceability from high to low-level requirements, from requirements to verification, and from
requirements to code, and each requirement involved in the implementation of safety-critical
functionality must be so identified.
F.9.4 IRS/IDD/ICD
Key documentation for reuse of software components is the interface description, including
Interface Requirements Specifications (IRS), Interface Design Descriptions (IDD), and Interface
Control Documents (ICD). The Data Item Descriptions (DIDs) referenced by the Contract Data
Requirements Lists (CDRLs) commonly found in DoD acquisitions describe various formats for
the content required to define the interfaces in a system. Documentation of interfaces is key to
the successful reuse of FACE software components, as they provide value through the
capabilities they provide to the systems into which they are integrated. Interface definition must
accurately depict not only the capability provided by a software component, but the format in
which it is provided. As is the case with software requirements, a software component has little
value unless accompanied by formal documentation that specifies its interfaces. Innovations in
acquisition methodology may rely on complete definition of a component’s interfaces, especially
if that interface is properly modeled in a format that can be used to accurately specify, and
perhaps validate, its interface characteristics.
F.9.5 Software Accomplishment Summary

The Software Accomplishment Summary (SAS) describes the developer’s evaluation of the
qualification objectives that were met during qualification of the system software for the
portable software component in particular. The SAS for the portable component is separate from
the SAS for the system. The terms under which a certification authority will consider
qualification of a software system that integrates a software component (or multiple
components) must be established by consensus. This evaluation is based in part on the content of
the SAS. Given that the developer has the best technical appreciation for the software’s
functionality, implementation, and for the qualification activities, the developer must also
document the qualification objectives that were considered to have been partially met during the
initial qualification, and those that are considered to be required for completion by each
integrator. In addition, a description of the activities necessary to complete the objectives must
be included. Also, the qualification objectives not addressed for the software component during
the initial qualification must be listed, with any completion information that can be provided.
Documentation of these details by the developer and their evaluation by the certification
authority will be essential to evaluation of the qualification merits of a software reuse component
during assessment of each subsequent integration. If the same Airworthiness Authority evaluates
a subsequent integration, the qualification picture is clearer than in cases where a different
Airworthiness Authority considers the merits of software reuse; careful documentation is
necessary to maximize the benefits of software reuse in the latter case. Coordination between
Airworthiness Authorities is advantageous if possible.
FACE software components should be accompanied with documentation that definitively frames
the conditions for their reuse, which should be coordinated in advance with the qualification
authority for a system that integrates these components.
F.10 Reuse of Tests

As alluded to before, reuse of tests can be advantageous for software efforts – having a known
set of tests that can be conducted again on code in association with changes, or when it is
integrated into new environments. This is applicable to manual or automated test cases.
F.10.1 Reuse of Manual Tests

Quality sets of requirements-based and robustness tests that are well documented and accepted
for qualification establishes repeatable procedures for qualifying software as the lifecycle
progresses. While the labor of manual tests is not reduced, the existence of well-documented,
traceable procedures is beneficial for testing in that these procedures need not be recreated.
These tests can also be used as the basis for creating automated tests. Making reusable tests
available to subsequent system integrators is advantageous for inclusion in the system-level tests
to ensure that the functionality has not be altered by the integration, and suppliers of FACE
components should consider this in association with their offerings.
F.10.2 Reuse of Automated Tests

After a proven set of manually conducted tests are established, the efficiency with which those
tests can be conducted may be increased by converting the manual tests into automated tests.
The initial costs of automation may be significant, and must be analyzed for feasibility.
However, consideration of long-term benefits for use in regression testing and for system
integration testing should be considered. Automation typically removes the randomness of
human-conducted tests and allows the verification engineers to converge on determining the
continued airworthiness merits of the software.
Developers seeking flight release for their software should remain aware that automated testing
must be documented in sufficient detail that an evaluator can ascertain that the test sequence
properly verifies implementation of the requirements in software. Automated testing has little
qualification merit if the test procedure merely lists the title of the automated test script that
purports to verify a specific requirement is properly implemented in code. Technical details must
be available to show that the verification is sufficient. This visibility is particularly important in
the reuse case, where the tests are also reused.

F.11 Consideration of Archival of Artifacts in the FACE Repository or
Reference
Suppliers of FACE components should consider maximizing the availability of qualification
artifacts when deciding the terms under which their components will be offered through the
FACE Registry.
In order to achieve the FACE goal of reduction of development and integration costs and time-
to-field new avionics capabilities, the cognizant qualification authority must have access to
documentation that substantiates achievement of qualification tasks (refer to the FACE
Technical Standard, Chapter 5) that are of useful in evaluating a qualification decision.
The following general categories of artifacts are typically required by an authority responsible
for flight release:
 Planning Documents
 CM/QA Artifacts
 Design and Specifications
 Source and Executable Object Code
 Traceability Artifacts
 Safety Analysis/Hazard Assessment
 Review Artifacts
 Test and Coverage Artifacts (including manual and automated tests)
 Analysis Artifacts
Availability of artifacts (and the specifics of their content) may significantly impact the cost and
schedule associated with reuse of software components and, once again, early coordination of a
qualification approach with the integrator’s Airworthiness Authority is advisable to achieve
reuse goals.
F.12 Coordination of Qualification

F.12.1 Early Agreement and Documentation Facilitates Efficient Qualification
Agreement on Credit Sought
A plan that includes reuse of FACE software components should include early coordination with
the Airworthiness Authority to achieve consensus as to any qualification credit that will be
sought for that reuse, and the documentation that will be required to substantiate that credit.
Also, agreement as to the extent of verification that will be necessary for the balance of the
qualification is important to efficient qualification and flight release. If no credit is sought, early
consensus as to the type, number, and content of artifacts that must be available for review
during airworthiness qualification of the resulting system should be established to avoid
potential conflicts over documentation requirements for that portion of the software
implementation. Description of the credit sought should appear in an Airworthiness
Qualification Specification (AQS) or Plan for Software Aspects of Certification (PSAC).
Agreement on Completion Tasks
The supplier of FACE software components should provide documentation to support the extent
to which qualification objectives have been met, and be able to provide artifacts as evidence. Of
equal importance is a statement of the qualification tasks that remain to be accomplished by
subsequent users, and any definition of those tasks offered. These should be used by integrators
when presenting qualification evidence for their composite system software in an SAS, an
Airworthiness Qualification Substantiation Report (AQSR), or similar documentation.
Documentation of Results
Integrators of FACE software components should perform and document the completion tasks as
indicated by the component supplier when seeking airworthiness release, and any other
qualification tasks identified during the early coordination with their certifying authority.
F.13 Segregation of Software Components

When designing a software architecture based on ARINC 653 partitioning, the engineering
trade-offs of timing, resource sharing, latency, etc. should be considered. If substantial variation
of criticality exists in significant portions of a software application, or if whole applications
having broadly different levels of criticality are to reside on a single processing platform, an
analysis should be performed to evaluate whether potential savings in qualification of the code
segment having the lower criticality outweigh the expense and complexity associated with the
use of an OS that can provide formal time and space partitioning of the software.
Even though qualification at higher levels of rigor can imply significant increase in cost and
schedule (possibly amounting to a significant increase in the cost of a project), many factors
enter into the decision regarding use of a partitioning OS. This is an engineering decision that
should be based on analysis. Partitioning, in and of itself, does not imply an increase in system
safety or reliability, and could result in a decrease in either or both of these if partitioning is not
properly implemented (considering balance of resources, interfaces, etc.). On the other hand,
partitioning is the only way to segregate software components within a single computing
environment in order to achieve qualification at different criticality levels; without formal
partitioning, a lower-level criticality application may interfere with a higher-level application.
Memory, hardware resources, and processing requirements for applications that share a
computing platform are significant factors in the decision to partition, and in balancing the use of
resources if partitioning is implemented.
In order to achieve credit for segregation of software components with regard to qualification at
varying levels of criticality, a partitioning system must possess the following key attributes:
 Temporal Separation (schedule control)
 Spatial Separation (memory control)

 Resource Separation
 Controlled Interfaces
The mechanisms that supply this segregation must be qualified to the highest level of criticality
that applies to any software application they protect.
F.13.1 Segregation for Variability

DoD acquisition of material that incorporates software commonly follows an incremental
development process wherein periodic formal releases incorporate change requests and
implementation of additional functionality. Given typical release schedules and frequencies, full
qualification test of that software is not generally considered necessary. Qualification of
incremental releases is typically achieved by Regression Testing, which should consist of the
following tests for all software that executes within the same processing environment (i.e.,
formal partition):
1. Test of software that implements new functionality
2. Test of software that is impacted by new functionality
3. Test of software that implements requirements that have been identified as safety-related
(during the Safety Assessment)
Test of software described by (1) is implicit, because the software has changed. Testing of
software of types (2) and (3) is a consequence of the fact that the new/altered software could
impact previously qualified software; this is particularly important in the case of software that
implements safety-related functionality, which drives qualification of all software executing
within a particular computing space (partition or processor) to the level of rigor of equivalent to
the level of the most critical software function. Therefore, the extent of Regression Testing in an
incremental software development plan is a cost consideration in architecting a partitioning
design.
F.13.2 Segregation for Criticality
Multiple Levels of Safety Qualification
Qualification Rigor has significant programmatic impact with regard to cost and schedule.
Software should be engineered to achieve a proper balance between qualification requirements
and the additional complexity and cost of segregation (partitioning) of software components,
selection and availability of Application Programming Interface (API) calls, and other factors, as
these impact the portability of software and, therefore, attainment of the goals of the FACE
architecture. These decisions should be based on evaluation of hazards using a process
appropriate to the situation (i.e., Joint or Service-specific).
FACE Profiles and Criticality Level
Software that is evaluated to have no airworthiness qualification requirements is consistent with

the definition of RTCA DO-178B Level E (possibly Level D in some cases). This software may
conform to the FACE architecture by meeting the requirements of the FACE General-Purpose
Profile.
Software evaluated to have any higher criticality must conform to the FACE Safety Profile,
requirements for which are defined in the FACE Technical Standard. Meeting any FACE Safety
Profile does not imply that any airworthiness qualification requirements are met; these are
specified by the cognizant qualification authority. Terms for meeting qualification requirements
should be coordinated early with the authority.
The FACE Technical Standard, Section 3.9.2 describes two sub-profiles for the use of POSIX in
conformance with the FACE Safety Profile: the Base and Extended Sub-profiles. The Extended
Sub-profile is a superset of the Base Sub-profile, and includes POSIX API calls that require
special review by a program's safety qualification authority, as the calls may not be considered a
candidate for qualification in some contexts. Refer to the FACE Technical Standard, Section
3.9.2 and Appendix A for more specific information before choosing to use the Extended Sub-
profile. Any component using the API calls specified for any FACE Profile is subject to the
qualification requirements established by the cognizant authority. The implementation of the
APIs themselves is also subject to qualification.
Other FACE OS Interfaces
The FACE Technical Standard includes five other types that include language run-times (C,
C++, Ada, Java) and frameworks (currently OSGi). These are specified for use in the various
FACE Profiles, and, like the ARINC 653 and POSIX interfaces already described, may impact
the partitioning strategy in a FACE implementation.
When used with run-times or frameworks, C and C++, standard Java, and OSGi as specified in
the FACE Technical Standard may not be considered a candidate for qualification by particular
Airworthiness Authorities, and may require isolation through partitioning.
F.13.3 Spatial/Temporal Partitioning (ARINC 653)

In order to achieve credit for segregation of software components with regard to qualification at
varying levels of criticality, a partitioning system must possess key attributes:
 Time Separation (schedule control)
 Spatial Separation (memory control)
 Resource Separation
 Controlled Interfaces
The OS, hardware, and support elements that provide the formal segregation on which
qualification to different levels of criticality is based must be shown to provide this to a level of
criticality equivalent to, or greater than, the highest level of criticality of the software
functionality it supports. Users of partitioning mechanisms must be aware of the qualification
implications of any given configuration.

Selection, implementation, and qualification of the partitioning mechanisms are particularly
relevant to achievement of the FACE Safety and Security Profile attributes (refer to the FACE
Technical Standard sections):
 Non-interference between applications
 Non-interference between applications and the operational environment
 Non-interference between applications and external interfaces
 Software Fault Isolation
 Software Fault Recovery
 Reliable Information Flow between applications
 Reliable Information Flow between applications and external interfaces
 Integrated health monitoring and management
 Standards-based system configuration data
 Non-interference with safety-related functions
 Security Function Isolation
 Security Function Recovery
 Security Function Safe Failure
 Trusted Information Flow between applications
 Trusted Information Flow between applications and external interfaces
 Protection of Data in Processing
 Protection of Data in Transit
 Protection of Data at Rest
F.14 Limiting Qualification Impacts Through Configurability

F.14.1 Safety and Configuration Files (using Deactivated Code)
Software that configures itself based on the contents of a simply formatted, user-editable
external file, either at start-up or at specific times during operation, allows a system to operate in
various configurations which can be qualified as safe and reliable. While this can make software
more versatile in various deployments, it leads to special considerations with regard to
qualification. Functionality of the software must be proven accurate, deterministic, and robust, at
a level commensurate with the functionality that it ultimately controls in the system.
For information regarding Civil policy relating to Safety-identified requirements, see RTCA
DO-178B, Section 2.4 item e, User Selectable Option Software, and 5.2.3, as a suggestion of the
types of considerations an Airworthiness Authority is likely to evaluate.
 Implications of configurable software require special consideration during safety
assessment to ensure that consequences of incorrect operation are considered.
 Software that modifies behavior based on an external configuration file must implement
that functionality in accordance with stated requirements, and must be verified by test
cases that trace to those requirements.
F.14.2 Pre-Qualified Selection of Options at Run-Time (including Initialization)

The concept of deactivated code makes possible the development of software that can be
configured in various ways, with code segments remaining unused in varying application
environments, hardware/software configurations, missions, etc. This allows software
applications to read simply formatted external configuration files to alter their behavior without
recompilation from source. When the software is qualified to operate in this manner, the
broadest application of software components is facilitated. The best way to avoid cost in the
qualification of modified code is to minimize the exposure of changes to the software base.
Another benefit of this strategy is that software fixes in the “common code” are automatically
included for every configuration represented, rather than requiring implementation in separate
software versions that support various configurations. This single advantage can represent
significant programmatic savings with regard to regression testing, although caution is warranted
to ensure that changes made to support one configuration do not degrade operation for any other
configuration.
F.14.3 Dead Code versus Deactivated Code

Most qualification guidance for software prohibits the existence of code segments that do not
implement functionality relevant to the application. Referred to as “dead code”, these code
segments represent a risk of reduced safety and reliability in software systems for several
reasons:
 If accidentally executed, system operational impact is unpredictable
 Dead code consumes valuable system resources (e.g., memory and its protection
mechanisms, data transfer systems, load times)
 Dead code remains untested, since it doesn’t trace to requirements (or, therefore, tests)
Deactivated code is software that is traceable to requirements and, by design, is either not
intended to be executed, or is only executable in certain configurations of the current system.
Existence of deactivated code that is not intended for use in the current application is subject to
additional qualification activities, including proof of the mechanisms that prevent its execution.
Application of Qualification Requirements to Configuration Mechanisms
A possible drawback of this strategy is additional qualification effort for configurable software.
It must be demonstrated that the mechanisms that read and use the configuration information
operate reliably, and protect both the used and unused functionality. The software that
implements the configuration functionality must trace to detailed requirements and be covered

by tests that verify the implementation, and which include robustness testing that verifies correct
operation when the content of the configuration file contains errors.
Safeguards must be incorporated when implementing configurable software:

 Verification of proper design of error handling algorithms in software that reads the
configuration
 Verification of proper execution of error handling algorithms, per the design requirements
(through test and analysis)
 Qualification of the system configuration algorithms that use the configuration file
content, at a criticality level commensurate with that of the system, and of the functions
implemented by the software being configured
Run-time configuration of software requires generation of source code to implement the

configuration function; the software design must incorporate these derived requirements, and the
software implementation must trace to those requirements and to test sequences that verify
correctness.
F.15 Test Programs

Advanced test programs may seek to automate testing, thus making regression testing more
efficient, accurate, and possibly applicable to subsequent integrations. Key points to consider
are:
 Qualification and CM of the test environment is important to ensure confidence in the
validity of testing of the software.
 Dry run of the test cases before the official run-for-record testing is needed to assure a
clean run-for-record with valid, robust test procedures.
 Demonstration (and documentation) of the extent of test coverage of requirements and test
coverage of software elements (two types of coverage analysis).
 Generation of documentation that clearly and fully exposes the details of testing,
necessary for evaluation of sufficiency of the test suite to establish verification –
automated test scripts must be fully documented and verifiable.
 Accuracy in the test sequence; “pass” without redline changes during test execution, and
without multiple execution of steps (an indication of determinism).
F.15.1 Requirements-Based Testing

In order to verify implementation of requirements in software, analysis and mapping of
requirements to the detailed test cases and the test steps they comprise must be achieved. This
allows a qualification consideration to include evaluation of the extent to which the test suite
verifies the implementation. The default metric for coverage is 100%.
F.15.2 Low-Level Software Requirements Testing
High-level requirements are traceable to low-level (detailed implementation) requirements. Low-
level requirements testing ensures that the lowest level of operation has been tested to properly
implement the low-level requirements. This may require white box testing in which the
developer has to connect a debugger to invoke non-reachable states. Also, depending on the
level of criticality, the code may require instrumentation to perform structural coverage analysis.
F.15.3 High-Level Software Requirements Testing

High-level software requirements are derived from system-level requirements. These are
typically used to test or demonstrate that the software’s functionality meets the intent of the
high-level requirements. Usually, this involves testing at the interface level, through black box
type testing of the software. Some high-level testing may be achieved via hardware integration
testing; collectively, the various test regimes must add up to a complete qualification suite.
Programs may also claim credit for aspects of production acceptance testing, where those test
steps verify specific software components’ functionality sufficiently (subject to approval).
F.15.4 System Integration Testing

System integration testing seeks to verify that all components operate correctly with respect to
each other, and so is especially relevant to the incorporation of software components into
avionics systems. Implementation of their interfaces, timing, performance, integrity, fault
tolerance, robustness, and defined segregation requirements must be verified as correct. It is the
responsibility of the integrator to engineer a composite solution that achieves these attributes and
provides the required functionality, even if the integration uses software components that have
been part of software systems that have previously achieved qualification.
Integration of Applications with Software Operating Environment
A specialized form of integration testing applies to the interaction of the application software
with the infrastructure that supports its execution. Suppliers of software that is part of the
support infrastructure should plan and execute an appropriate approach to qualification of these
components, including documentation that helps subsequent users engineer solutions based on
them, and that supports their efforts to establish qualification. Depending on the requirements of
the certification authority, full documentation may be required for these elements. It is unlikely
that missing documentation can be reverse-engineered by an integrator, especially in the case of
planning documents that are intended to guide the software engineering process.
Integration of Applications with Support Components (Run-Times, Frameworks)
Testing (beyond requirements-based testing of applications) is likely to be required to ensure

correct operation of applications when supported by elements of the software infrastructure. The
more complex these support elements are, the more effort will be required to verify their
operation at the level of criticality required by the functions supported. Various analyses may
apply, as described in ARP 4754A/4761, for example.
Not only must the integration of the application with the run-time or framework be verified, but
the implementation of the run-time or framework is subject to qualification. While any particular

run-time or framework may have an established history of correct operation, the implementation
for a particular system (processor, resources, configuration, etc.) has a bearing on qualification,
and must be verified for flight release. If qualification artifacts are not available for these
Operating Environment (OE) elements, it is unlikely that they can be reverse-engineered. If it is
widely acknowledged that a given run-time or framework presents qualification challenges, an
integrator must exercise caution when basing a computing architecture on these.
Partial Qualification Credit for Bundled Applications
The FACE concept of a UoP seeks, in part, to foster integrity by allowing suppliers to combine
software support elements with the applications that need them. Presumably, prudent suppliers
will perform verification of the interactions between the application and these support elements,
and will offer documentation with the UoP that assists integrators with their qualification efforts
for the resulting system. To achieve FACE conformance, a UoP must implement FACE allowed
interfaces for its integration into a FACE OE; if a supplier provides qualification evidence for
the application and for the interface to the FACE OE, the qualification case for a system having
previously qualified FACE interfaces is strengthened. Airworthiness evaluation is likely to
include the merits of both the FACE UoP and the OE supporting it.
F.15.5 Hardware Integration Testing

Software to hardware integration testing is conducted in an environment equivalent to the
intended target hardware. While a software vendor creating FACE conformant software may not
know hardware context where their software will be applied, they do know the limitations and
resources required by their software. Therefore, they should test the software in some
representative hardware environment. The true software to hardware integration is the
responsibility of each subsequent integrator of the FACE components.
F.15.6 Configuration and Setup Testing

It is important that the initialization and run-time configuration of software be tested to ensure
proper operation. These test cases must appear as part of the qualification test suite.
Default Configuration Setup After Power-Up
The requirements should clearly indicate the initial state of all parameters so that a known state
is achieved upon power-up. The initial states of the variables should be verified to meet these
requirements during qualification testing.
Nominal and Out of Boundary Configuration Verification (Robustness)
Any configuration of parameters within the valid range for each parameter should be checked.
Also, values outside the range should be tested to ensure proper handling by the software.
Data Parameter Configuration Testing
External database load files that determine the run-time configuration of the software should be
tested within bounds and out of bounds.
F.15.7 Information Interface Testing
All interfaces should be well defined in the requirements with their proper protocol, data types,
and little/big endian configuration. Also, data integrity and checking of the data transferred by
the interface should be tested.
F.15.8 Type Consistency Testing

The data that is exchanged over the interface should be tested for type consistency (booleans,
integers, reals, etc.). Also, robustness testing must be included to check for proper (per
requirements) system response when type inconsistencies occur.
F.15.9 Protocol Header Testing

The protocols used on the interface should be clearly defined on the interface and tested for
nominal and off-nominal conditions.
F.15.10 Data Integrity Testing

The data that is exchanged on an interface should be tested for integrity by an application
through some defined mechanism (e.g., Cyclical Redundancy Checking (CRC), Error Checking
and Correction (ERCC), checksum). Nominal and corrupted non-nominal testing should occur to
detect proper data flow operation. Sequencing of data should also be checked with out of order,
delayed, and variable delayed conditions tested as robustness test cases.
F.15.11 Robustness Testing

Qualification testing must include not only normative test cases that show correctness in the
expected realm of operation, but also test cases that verify a software system’s response to out-
of-bounds conditions. Due to challenges relating to the qualification of complex software, an
argument cannot be made that any given software component will only receive the expected
range of inputs (unless ensured by other aspects of the system, which are then subject to
qualification), nor can it be stated that operation outside the designed operating space will not
occur, without definitive proof. Testing must therefore expand beyond normal cases, especially
for software that implements functionality evaluated to have a high level of criticality.
Boundary Conditions
Inability to exhaustively test the operation of software elements where ranges of input values
may occur can be mitigated by selecting test cases where values both just inside, just outside,
and exactly on the defined boundaries demonstrate correct operation (e.g., per requirements).
Intelligent selection of other input values can provide verification evidence without exhaustive
testing; the supplier or integrator should document the strategy used.
Error Checking (in the Config Files, in Messages, Data Exchanges, Message Order, Checksum/CRC
failures, etc.)
In addition to boundary value checking, error checking provides robustness. This will be
particularly true with regard to configuration file content where modes of operation are based on

the values read; errors in format and range should be verified for proper system response, per
specific requirements (presuming that derived requirements were formulated to define this
functionality).
Exception Processing (Health Monitoring/Fault Management)
The FACE Technical Standard requires health monitoring and fault management at the OS level
and at higher levels (see the FACE Technical Standard). Verification of the operation of these
strengthen the qualification case for software systems seeking flight release, and may offer
mitigations that increase the calculated system reliability, depending on their coverage and
verification. Suppliers should document these features and the associated verifications as part of
the artifact set for consideration of qualification.
The following tests should be considered in testing:

 Load testing: The behavior of software in a system with a nominal loading of processor,
memory, or data bus is expected to be tested for verification. It is when the component or
system is under a load that anomalous behavior may occur.
 Duration testing: Long duration testing of software can be useful in determining whether
memory leaks or file mismanagement generate errors over time. It is advisable that
automated testing be employed to stress the system (load test) be conducted over a
sufficient duration to reveal effects over time.
 Memory leak testing: Conducting tests to cause the system to make multiple memory
allocations is important to ensure that memory is properly managed. It is encouraged that
testing be automated to cause software to generate latent errors that might manifest after
multiple allocations, extensive cache accesses, etc.
 Fixed/variable delay (jitter) testing: Delaying information at an interface can be
detrimental to operation of a software component or system. Varying this delay can
produce additional errors in some applications (such as data-intensive real-time video or
voice operations).
 Configuration testing (e.g., attempts to configure for illegal values and verifies correct
response): User configuration through a user interface or through an external
configuration parameter file should be performed under test conditions to ensure that
proper error checking is done to prevent anomalous operation. System response to these
conditions should be verified to be conformant to the stated requirements.
F.16 Lifecycle Support

Given a current definition of “complex” software (that for which each and every execution path
and range of input values cannot be exhaustively tested), the likelihood that fielded software
incorporates problems is high. While verification programs seek to ensure functionality and
safety, the focus must be on areas of high criticality, and those seeking qualification must
acknowledge that complete coverage cannot be achieved through exhaustive testing. Since
problems are likely to surface after deployment, military programs must plan and execute
procedures for problem reporting, tracking, and correction that address the requirements of the
Airworthiness Authorities, security, and satisfy the conditions for continued airworthiness.
F.16.1 Distribution of Software Maintenance Releases

The lifecycle support picture becomes complicated where portable software components are part
of systems that are developed and deployed by multiple integrators. It is necessary to have a plan
that maintains the acceptable level of safety established during the qualification of a system that
incorporates FACE components. The original supplier of a software component could act as the
hub of a network of users that gathers problem reports, generates or receives “fixes”, and
distributes corrected software to all users. This parallels the guidance stated for Civil software
reuse (refer to AC 20-148). An example of this is where suppliers of OS software accept input
and provide updates. For suppliers of FACE components, lifecycle support may involve
contractual complications that must be solved, but ultimately it will be up to the integrators of
FACE components to address this aspect of system qualification with their respective
Airworthiness Authorities.
F.16.2 Collection of Problem Reports

The success of lifecycle software support is based on the collection of problem information from
fielded systems. Whether formal or informal, this process is simplified when software is
deployed within an organization, and is more complex in the context of systems comprising
FACE components. Both suppliers and consumers of FACE components should address the
issue of feedback as part of the engineering process to maximize efficiency in this area.
F.16.3 Dissemination of Problem Reports

In addition to distribution of software updates, a process should be established by which
notification of problem reports takes place rapidly and pervasively, especially for software issues
that have been shown by safety analysis to impact system safety and security. Application of
FACE components in multiple integrations and various contexts makes distribution of problem
reports both more complicated and more important, and a formal statement of a support plan
should represent a distribution advantage for FACE suppliers.
F.16.4 Software Loading Instructions

The integrator is responsible for integrating FACE software components and setting up the
software. Guidelines provided with the software ensure a successful integration.
F.16.5 Software Compilation Instructions

Any special tools, preprocessing, or compilation instructions should be clearly spelled out in
documentation accompanying software components. Any advice concerning optimization
parameters or particulars of the compiler, target processor environment, and memory
requirements should be provided.
F.16.6 Software Users Manual

All of the instructions for software loading, compilation, and any other environmental aspects
should be contained in a Software Users Manual.

F.17 Documentation
Qualification artifacts are critical to the evaluation of airworthiness, and cognizant certification
authorities are likely to base their evaluation on those available for FACE components within
avionics systems based on software. Suppliers should evaluate the merits of making these
artifacts available to system integrators of their products to support qualification. Whether the
actual artifacts are available through the FACE Registry, or only listed for evaluation and
subsequent acquisition, these artifacts will be key to qualification of systems that incorporate
them.
These general categories and types of artifacts are typically required by an authority responsible
for flight releases:
 Technical Planning Documents:
— Design and Specification Documents
— Requirements
 Programmatic Planning Documents:
— Process Descriptions
— CM Plans
— QA Plans
— Reviews
 Safety Analyses:
— Hazard Analyses
— Functional Analyses
— Failure Mode Effects and Criticality
 Test Artifacts:
— Test Procedures/Plans
— Test Results
— Robustness Verification and Documentation of Supporting Elements
— Test Coverage Reporting
— Traceability
More information on the specifics of the artifact listing and content is available in MIL-STD-498
(cancelled 1998), the subsequent Electronic Industries Alliance (EIA) J-STD-016-1995, and the
RTCA DO-178B, et al. Suppliers and integrators of FACE components should refer to the
appropriate Airworthiness Authorities for definitive guidance for their particular situations.
F.18 Model-Based Engineering of Software
The use of Model-Based Engineering (MBE) potentially enhances the integrity and safety of a
software product, as well as presenting opportunities to improve efficiency in the areas of
development and qualification. Other benefits such as succinct communication of requirements
and verification of design before implementation may be available as well. Successful
approaches will carefully consider the benefits of a tool chain that facilitates each phase of the
software engineering process from requirements management to model development, to
generation of source code, and formulation of a set of tests that verify the implementation.
Effective tools will produce output that is useful for evaluation of qualification, including
traceability data that substantiates the integrity of the system, and coverage of the test suite.
In cases where qualification credit for an application is sought due to the use of software tools,
such tools must be qualified according to the level of rigor associated with the software
functions they are used to implement or verify. Many tools have not been qualified. Those that
have been qualified must still be proven to operate effectively for the development under
consideration, and so users of these tools should plan for additional effort. To aid in this, the tool
supplier may offer a set of resources to support qualification of the tools for a particular use (at a
possibly substantial price).
In cases where no qualification credit is sought due to the use of specific tools, the tool set
should be planned and used in such a way that typical qualification artifacts will be produced
that support evaluation of qualification according to the appropriate established processes. The
development approach should be accurately documented so that a qualification evaluation can
consider the merits of the tool chain and the documentation produced.
F.19 Special Considerations for the Use of Run-Times and

Frameworks
F.19.1 Language Run-Times
Like any other software components that comprise a complex avionic system, language run-
times that are part of a qualification consideration are subject to the terms of qualification as
determined by the cognizant Airworthiness Authority.
Refer to the FACE Technical Standard, Section 3.12.1 for detailed information regarding the use
of language run-times within the definition of the FACE architecture.
Definition of a subset of API titles does not constitute qualification, which includes verification
of the implementation of those functions on the particular processing engine/electronic
hardware, and within the software environment, that supports execution of an application that
relies on them. Verification of the API’s executable code is required to establish the FACE
software quality attributes listed in the FACE Technical Standard, Sections 4.3 and 5.3, and
Chapter 10 herein, and other qualities as required for airworthiness release.
Credit for service history must be based on documented service records showing that the
software possesses the necessary quality attributes, and evidence supporting the claim that the

operating environment for the system seeking certification is equivalent to the environment(s) on
which the service history was established.
It is commonplace that restrictions have been defined for the use of language run-times that
improve the qualification picture by seeking to limit violation of the FACE software quality
attributes. Applicability of these restrictions should be coordinated early with the Airworthiness
Authority prior to implementation or integration of existing software components to avoid
expensive and time-consuming re-qualifications. Use of some languages and their run-time
libraries without these restrictions may make qualification problematic.
Implementations that disregard these limiting definitions should carefully evaluate this strategy
before placing limitations on the applicability of their products.
F.19.2 Frameworks
The FACE Technical Standard allows frameworks as part of the OSS of a FACE conformant
UoC.
For a description of the FACE concepts that apply to use of frameworks, refer to the FACE
Technical Standard, Section 3.13.1. In short, the distinction between language run-times and
frameworks is made:
“With libraries, applications instantiate and invoke the functions and objects provided by the
library, but with frameworks, developers implement functions and objects specific to their
component which are then instantiated and invoked by the framework.”
Put another way, run-time libraries are called (and instantiated) by the applications they support,
but a framework calls the applications as the arbitrator of execution.
Within the definition of the FACE Technical Standard use of frameworks in both the General-
Purpose and Safety Profiles consists of framework features described in OSGi Service Platform,
Release 4, Version 4.3 (Core).
In addition to qualification of application software that provides aviation-specific functionality,

military acquisitions require qualification of the software infrastructure that supports those
applications. A framework that arbitrates execution of avionics applications is of particular
interest to an airworthiness qualification agency, since this software directly affects the areas
listed in Chapter 10, and other concerns relevant to integrity, determinism, robustness, etc. as
described extensively herein. Depending on the evaluated criticality of the functions that are
implemented, qualification of software may require demonstration of determinism by complete
decision path testing, with documented evidence of coverage. This testing and analysis
represents a significant investment (e.g., cost and schedule), and should be carefully considered
when an architecture is engineered to include a framework. Once the implementation of such an
infrastructure is qualified and documented, it may be possible to leverage that qualification for
future systems, provided the hardware and software environment can be proven to be exactly
equivalent, and documentation is provided. As with any software, a qualification authority is
likely to require proof of correct operation of any new integration, as well, including proof of
correct functionality, hard real-time scheduling where required, singularity of outcome
(determinism), robustness (edge conditions), fault-tolerance, and other characteristics as required
by the certification authority.
Frameworks that arbitrate the execution of applications, or bundles of applications, must be
proven to provide the separation necessary to ensure their correct and timely operation,
especially frameworks that seek to build systems that emerge from joining different components
that have no pre-existing knowledge of each other, and systems which arise dynamically by
combining the available applications and services as needed. Further attention must be applied to
frameworks that arbitrate the provision of services from one application or group to another, and
removes them asynchronously, requiring the consumers of those services to adjust their
operation. The goal of integration testing in military avionics qualification programs is to ensure
that systems comprising various applications function correctly in every operant configuration;
therefore, dynamic configuration of software components in avionics is only acceptable if every
configuration is qualified, and every schedule of dynamic configuration is tested and proven to
meet real-time determinism and reliability. The mechanisms that provide this functionality are
also subject to qualification.
An Airworthiness Authority will seldom base a qualification decision solely on the fact that a
given software component (whether application software providing mission capability, or OS,
language run-time, or framework) has been previously used, is said to have been qualified
elsewhere, or has an established service record, without artifacts that document its quality, and
the conditions under which these achievements were attained. Equivalence of the conditions of
application (including operating environment), as well as documented service history, will be
required by a certification authority to consider qualification credit for previous use in lieu of
other artifacts; early coordination with the appropriate agency is advisable to establish consensus
as to the plan for certification.
F.20 Conclusion
Engineering of software components for reuse represents enhanced market availability. Reuse of
such software components presents opportunities for savings in terms of cost and schedule. Each
strategy, however, has some associated cost and schedule implications of its own to consider.
All parts of a software product are subject to qualification, and an integration program that
incorporates existing software components will at least be required to verify correct integration
and operation of that system, and at most will be required to re-qualify those reused components,
especially if the components are not properly documented.
Execution of a Safety Program is required, including analyses to establish the criticality of all
software that comprises an avionic system, which then defines the level of rigor to which that
software must be qualified.
Review of documentation of the software engineering effort by an Airworthiness Authority is

key to a qualification evaluation for flight release. Documentation should journal the work, not
historically report its accomplishments.
Early coordination with the cognizant Airworthiness Authority is advisable in any development
or acquisition of avionics where flight release is required, so that an agreeable course is taken to
substantiate a case for qualification. This will result in the most efficient qualification possible.
Software without lifecycle support is not effective in the long term.

G FACE Framework Interface
One of the functions of the RIG is to provide notification of content expected in a future
Technical Standard. The content of this appendix is provided in anticipation of release of the
FACE Technical Standard Edition 3.0 and supplies readers with advanced notice of new
material. The specifics of this section may change between the publication of this document and
the next Technical Standard, but the reader can gain familiarity with new concepts and
technologies before official release.
G.1 Component/Conatainer to FACE API Mappings

To provide a consistent abstraction of the specific interfaces of multiple component frameworks,
it is necessary to map categories of Component/Container infrastructure functionality to specific
FACE abstraction interfaces.
G.1.1 PCS Interface Mapping

 The FACE Transport Services (TS) Interface proxies framework data exchange
mechanisms/interfaces including Request/Reply, Publish/Subscribe, and events-based
APIs.
— All data is modeled in the FACE Data Model.
 The FACE TS Interface proxies the framework persistent storage interfaces.
 The FACE TS Interface proxies the framework lifecycle API.
— Lifecycle States are modeled in the FACE Data Model.
 The FACE TS Interface proxies the framework time API.
— Time messages are modeled in the FACE Data Model.
 The FACE TS Interface proxies the framework error and logging APIs.
 The proposed FACE Configuration API will proxy the framework configuration API.
TS API
FACE HMFM API
FACE TS Syntactic Interface and
FACE Semantic Data Model
FACE Config API
Runtime Lifecycle Messages FACE PCS UoP
(FACE Data Model)
Messaging Time Service
Get/Set Time Message Framework Adaptation
Runtime Lifecycle
Adaptation HMFM Config
Adaptation Library
(FACE Data Model) Module Library Library
Framework request
response, publish subscribe,
persistence storage and Framework
event based APIs Configuration API
Framework runtime Framework error

lifecycle API and logging APIs
Framework Get/Set
Time API
Figure 90: FACE PCS UoP as Framework Module
Figure 90 depicts the mapping of the FACE PCS UoP abstraction interfaces to the Framework
Module Container interfaces.
G.1.2 Platform-Specific Services Segment Interface Mapping

For PSS components all of the same mappings will be used but the FACE IOSS and I/O Services
Interface will be used to communicate with device drivers. This is depicted in Figure 91.
 The FACE Transport Services (TS) Interface proxies the framework data exchange
mechanisms/interfaces including Request/Reply, Publish/Subscribe, and events-based
APIs.
 The FACE TS Interface proxies the framework persistent storage interfaces.
 The FACE TS Interface proxies the framework lifecycle API.
— Lifecycle States are modeled in the FACE Data Model.
 The FACE TS Interface proxies the framework time API.
— Time messages are modeled in the FACE Data Model.
 The FACE TS Interface proxies the framework error and logging APIs.
 The proposed FACE Configuration API will proxy the framework configuration API.
 The FACE IOS Interface proxies the framework device drivers.

TS API
FACE HMFM API
FACE TS Syntactic Interface and
FACE Semantic Data Model
FACE Config API
Runtime Lifecycle Messages FACE PSS UoP
(FACE Data Model) FACE IOS API
Framework Messaging Time Service

Get/Set Time Message Device Adaptation
Runtime Lifecycle
Adaptation HMFM Config IOS
Adaptation Library
(FACE Data Model) Module Library Library
Framework request
response, publish subscribe,
persistence storage and Framework
event based APIs Configuration API
Framework runtime Framework error

lifecycle API and logging APIs
Framework Get/Set
Time API
Figure 91: FACE PSS UoP a Framework Device Module
G.1.3 Data Modeling Framework Interfaces

As indicated above, the individual data elements of the FACE TS Interface are modeled in the
FACE Data Model. Figure 92 shows the UoP model for a lifecycle control messages. Figure 93
shows the corresponding Platform and Logical elements from which the lifecycle control
messages are derived.
Figure 92: UoP Model of Lifecycle Messages

Figure 93: Logical Model of Lifecycle Message
G.1.4 Component Assembly

As depicted in Figure 94, the Framework Component will be derived from multiple FACE
Conformant Framework Modules (functionally decomposed) and reside on any Framework
Container. The container uses the FACE specified Operating System Interface as the computing
infrastructure. In the example in Figure 94 a supervisor module is used to communicate with the
container for lifecycle management and manages each of the other modules which are single
threaded.
Framework Component
X
FACE PCS UoP FACE PCS UoP
Framework Messaging
Runtime Lifecycle
Time Service Messaging
Runtime Lifecycle
Time Service
Supervisor Adaptation
Adaptation Library
Adaptation HMFM Config Framework X Adaptation
Adaptation Library
Module Library Library Module Library Library
X and Y
Data
Framework Messaging Time Service Messaging Time Service

Runtime Lifecycle Runtime Lifecycle
Add Adaptation Adaptation HMFM Config Framework Y Adaptation
Adaptation Library
Adaptation Library Library Library
Module Library Library Module
Shared Libraries can be

called by All Framework
Modules in a Framework
Component
Figure 94: FACE Conformant Generic Framework Component
Another example of a component implementation is one where each of the modules

communicates directly with the container for lifecycle management without the use of a
supervisor module. In this example the framework modules can be multi-threaded or single
threaded. This is depicts in Figure 95 below.
Framework Component
X
FACE PCS UoP
Messaging Time Service

Runtime Lifecycle
Framework X Adaptation
Adaptation Library
Module Library Library
X and Y
Data
Framework Messaging Time Service Messaging Time Service

Runtime Lifecycle Runtime Lifecycle
Add Adaptation Adaptation HMFM Config Framework Y Adaptation
Adaptation Library
Adaptation Library Library Library
Module Library Library Module
Shared Libraries can be

called by All Framework
Modules in a Framework
Component
Figure 95: FACE Conformant Generic Framework Component
G.1.5 Reuse Benefits

This abstraction strategy allows for potential reuse benefits to include:
 Components developed for FACE framework abstraction interface are easily ported to
several frameworks
 Components developed for FACE framework abstraction interface are easily ported to
several frameworks and to a traditional execution environment

 Businesses do not need prior knowledge of exploitation opportunities for their IP
— If they currently have contracts for a specific framework, by designing their IP using
the library-linked API approach they will be able to support a future opportunity that
uses FACE, another open standard, or a proprietary platform.
 Components developed for any framework to be interoperable using an SDM
 Alignment of development tools
 Allows for flexibility in architectural design decisions
 Allows for software component deployment flexibility
 Provides a standardized I/O interface for driver components
 The use of components developed to traditional software infrastructure to be used in
enterprise systems through component models.
Allows the intgrator to posibly consolidate the number of disparate frameworks needed on
a given system or platform.
In addition to the alignment and reuse benefits, there are technical benefits that ease
development as well as support the business benefits.
 Main() can now be put in the library enabling the following points (thus removing the
requirement for inversion of control):
— Thread management can be performed on behalf of the Business Logic.
— Platform resources can be accessed on behalf of the Business Logic.
The library approach also enables the Business Logic to be ported across different middleware
APIs (including different FACE Profiles) for ultimate reuse opportunity.
G.2 Example API Implementations

G.2.1 Initialize Function
The Initialize(TS) function call allows for the PCS and PSSS components to trigger the
initialization of the TSS component.
module FACE
{
interface TS
{
void Initialize
( in CONFIGURATION_RESOURCE configuration,
};
};
G.2.2 Create_Connection Function
The TSS provides an interface to create a connection. This interface allows the use of DDS,
CORBA, ARINC 653, and POSIX connections. The TSS implements the underlying DDS,
CORBA, ARINC 653, and POSIX function calls, and passes the parameters and data of the PCS
through these standardized function calls. The parameters for the individual connections are
determined through the TSS configuration capability. The TSS manages the system-level
connection identifiers based on DDS, CORBA, ARINC 653, and POSIX connections for routing
purposes. Certain communication APIs may be called natively without using the TS Interface.
For restrictions, see Section F.4.
module FACE
{
interface TS
{
void Create_Connection
( in CONNECTION_NAME_TYPE connection_name,
in MESSAGING_PATTERN_TYPE pattern,
out CONNECTION_ID_TYPE connection_id,
out CONNECTION_DIRECTION_TYPE connection_direction,
out MESSAGE_SIZE_TYPE max_message_size,
in TIMEOUT_TYPE timeout,
};
};
When a sampling port is instantiated through Create_Connection(TS) there are certain

parameters that have input and others associated with POSIX connections that are NULL due to
no operation for this particular transport mechanism.
void CREATE_SAMPLING_PORT (
/*in */ SAMPLING_PORT_NAME_TYPE SAMPLING_PORT_NAME,
/*in */ MESSAGE_SIZE_TYPE MAX_MESSAGE_SIZE,
/*in */ PORT_DIRECTION_TYPE PORT_DIRECTION,
/*in */ SYSTEM_TIME_TYPE REFRESH_PERIOD,
/*out*/ SAMPLING_PORT_ID_TYPE *SAMPLING_PORT_ID,
/*out*/ RETURN_CODE_TYPE *RETURN_CODE);
When a queuing port is instantiated through Create_Connection(TS) there are certain parameters
that have input and others associated with POSIX connections that are NULL due to no
void CREATE_QUEUING_PORT (
/*in */ QUEUING_PORT_NAME_TYPE QUEUING_PORT_NAME,
/*in */ MESSAGE_SIZE_TYPE MAX_MESSAGE_SIZE,
/*in */ MESSAGE_RANGE_TYPE MAX_NB_MESSAGE,

/*in */ PORT_DIRECTION_TYPE PORT_DIRECTION,
/*in */ QUEUING_DISCIPLINE_TYPE QUEUING_DISCIPLINE,
/*out*/ QUEUING_PORT_ID_TYPE *QUEUING_PORT_ID,
/*out*/ RETURN_CODE_TYPE *RETURN_CODE);
POSIX Socket
When a socket is instantiated through Create_Connection(TS) there are certain parameters that
have input and others associated with ARINC 653 connections that are NULL due to no
Note the order of the OS calls necessary to implement a TCP POSIX socket.
1. int socket(int domain, /* connection_domain */
int type, /* socket_type */
int protocol); /* chosen by the TSS */
2. int bind(int socket, /* connection_id */
OR
int connect( int socket, /* connection_id */
3. int listen(int socket, /* connection_id */
int backlog); /* provided by TSS */
4. int accept(int socket,
struct sockaddr *restrict address,
socklen_t *restrict address_len);
POSIX Queue
When a queue is instantiated through Create_Connection(TS) there are certain parameters that
have input and others associated with ARINC connections that are NULL due to no operation
for this particular transport mechanism. The TSS is responsible for completing the parameter list
of the mq_open() function call.
mqd_t mq_open(const char *name, /* connection_name */
int oflag); /* connection_direction */
/* mqd_t is mapped to connection_id through TSS */
POSIX Shared Memory
When shared memory is instantiated through Create_Connection(TS) there are certain

no operation for this particular transport mechanism. The TSS is responsible for completing the
parameter list of the shm_open() function call.
Note the order of the function calls necessary to establish a POSIX shared memory connection.
1. int shm_open(const char *name, /* connection_name */
int oflag, /* chosen by TSS */
mode_t mode); /* chosen by TSS */
2. void *mmap(void *addr, /* connection_id */
size_t len,
int prot, /* chosen by TSS */
int flags, /* chosen by TSS */
int fildes, /* chosen by TSS */
off_t off); /* chosen by TSS */
CORBA
The following CORBA methods are called in this order by Transport Services when a CORBA
Object Request Broker (ORB) is instantiated by Create_Connection(TS).
Since CORBA is distributed object middleware, a CORBA object is created for components
receiving data. Any component sending data retrieves a reference to the CORBA object to which
it wants to send data. The configuration file for a component determines the unique name(s) for
the CORBA object(s) used.
/* NOTE: THESE ARE THE CALLS MADE BY TRANSPORT SERVICES FOR THE
COMPONENT SENDING DATA */
/* NOTE: These calls assume a C++ mapping from the CORBA IDL, and
should be performed in the order specified below */
/* NOTE: These calls assume an IDL FACE module with a TransportObject
interface. The FACE module name and the TransportObject interface
name is verbatim including case */
1. CORBA::ORB_ptr CORBA::ORB_init (int arg_count,
// count of ORB arguments
char** arg_vector); // vector of ORB arguments
2. CORBA::ORB_ptr CORBA::ORB:resolve_initial_references
(char * objectId);
// the objectId is set to "NameService" to retrieve
the CORBA Naming Service.
3. CosNaming::NamingContext_ptr CosNaming::NamingContext::_narrow
(CORBA::Object_ptr);
// Narrow the CORBA object to the Naming Service
4. bool CORBA::is_nil (CORBA::Object_ptr);
// Check that the object reference was narrowed correctly
to a NamingService.
5. CORBA::ORB_ptr CosNaming::NamingContext:resolve
(CosNaming::Name receiver_name);
// Retrieve the object to receive the data
// Check that the Naming Service was able to resolve the name.
7. CosNaming::NamingContext_ptr FACE::TransportObject::_narrow
// Narrow the CORBA object to the one and only Transport object
to a Transport object.
/* NOTE: THESE ARE THE CALLS MADE BY TRANSPORT SERVICES FOR THE

COMPONENT RECEIVING DATA */
/* NOTE: These calls assume a C++ mapping from the CORBA IDL and
should be performed in the order specified below. */
/* NOTE: These calls also assume a CORBA IDL FACE module with a
TransportObject interface. The “FACE” module name and the
“TransportObject” interface name is used verbatim including case. */
1. CORBA::ORB_ptr CORBA::ORB_init (int arg_count,
// count of ORB arguments
char** arg_vector); // vector of ORB arguments
(char * objectId);
// the objectId is set to "RootPOAManager" to retrieve the root
Portable Object Adapter (POA) manager.
3. PortableServer::POAManager_ptr PortableServer::POAManager::_narrow
// Narrow the CORBA object to the root POA manager.
to the root POA manager.
(char * objectId);
// The objectId is set to "NameService" to retrieve the
CORBA Naming Service.
6. CosNaming::NamingContext_ptr CosNaming::NamingContext::_narrow
// Narrow the CORBA object to the Naming Service.
to a NamingService.
8. TransportObject * new TransportObject ();
// Create the object to receive data whose interface is
defined by CORBA IDL.
9. FACE::TransportObject_ptr FACE::TransportObject:_this ();
// Register the object with the ORB.
10. CosNaming::NamingContext:rebind (CosNaming::Name receiver_name,
FACE::TransportObject_ptr);
11. PortableServer::POAManager:activate ();
// Activate the POA manager.
12. CORBA::ORB:run ();
// Run the ORB to make the TransportObject available.
When the Data Distribution Service (DDS) is instantiated through Create_Connection(TS) there
are certain parameters that have input and others associated with POSIX and ARINC
connections that are NULL.
Since DDS does not provide a connection_id, the TSS is responsible for generating the
connection_id. For the following, the data namespace is “SPACE” and the data type used is
“Foo”. Any call involving the QoS of a domain entity can be modified based upon the needs of
the connection.
1. DDS_DomainParticipantFactory
DDS_DomainParticipantFactory_get_instance(void);
2. DDS_DomainParticipant
DDS_DomainParticipantFactory_create_participant(
DDS_DomainParticipantFactory factory, /* Provided by 1 */
const DomainID_t domainId, /* Empty variable */
const DDS_DomainParticipantQos *qos, /* chosen/configured by TSS */
const struct DDS_DomainParticipantListener *a_listener,
/* chosen by TSS */
const DDS_StatusMask mask); /* chosen by TSS */
3. DDS_TypeSupport SPACE_FooTypeSupport__alloc(void);
4. DDS_string SPACE_FooTypeSupport_get_type_name
(DDS_TypeSupport type);
5. DDS_ReturnCode_SPACE_FooTypeSupport_register_type (
DDS_TypeSupport type, /* Provided by 3 */
DDS_DomainParticipant participant, /* Provided by 2 */
DDS_string type_name); /* Provided by 4 */
6. DDS_TopicQos* DDS_TopicQos__alloc(void);
7. DDS_ReturnCode_t DDS_DomainParticipant_get_default_topic_qos (
DDS_TopicQos* qos); /* Provided by 6 */
8. Adjust the QoS as configured/required by modifying the DDS_TopicQos
structure.
9. DDS_Topic DDS_DomainParticipant_create_topic (
const DDS_char* topic_name, /* Parsed connection_name */
const DDS_char* type_name, /* Provided by 4 */
const DDS_TopicQos* qos, /* Provided by 6 */
const struct DDS_TopicListener* a_listener, /* Chosen by TSS */
const DDS_StatusMask mask); /* Chosen by TSS */
10.If connection_direction is:
a. SOURCE
i. DDS_PublisherQos* DDS_PublisherQos__alloc(void);
ii. DDS_ReturnCode_t
DDS_DomainParticipant_get_default_publisher_qos(
DDS_PublisherQos* qos); /* Provided by 10.a.i */
iii.Adjust partition name in the DDS_PublisherQos structure.
Partition name provided by the connection_name attribute.
iv. DDS_Publisher DDS_DomainParticipant_create_publisher (
const DDS_PublisherQos* qos, /* Provided by 10.a.i */
const struct DDS_PublisherListener* a_listener,
/* Chosen by TSS */
v. DDS_DataWriterQos* DDS_DataWriterQos__alloc(void);
vi. DDS_ReturnCode_t DDS_Publisher_get_default_datawriter_qos (
DDS_Publisher publisher, /* Provided by 10.a.iv */
DDS_DataWriterQos* qos); /* Provided by 10.a.v */
vii.DDS_ReturnCode_t DDS_Publisher_copy_from_topic_qos (
DDS_DataWriterQos* dw_qos, /* Provided by 10.a.v */
const DDS_TopicQos* topic_qos); /* Provided by 6 */
viii.DDS_DataWriter DDS_Publisher_create_datawriter (
const DDS_Topic a_topic, /* Provided by 9 */

const DDS_DataWriterQos* qos, /* Provided by 10.a.v */
const struct DDS_DataWriterListener* listener,
/* Chosen by TSS */
b. DESTINATION
i. DDS_SubscriberQos* DDS_SubscriberQos__alloc(void);
ii. DDS_ReturnCode_t
DDS_DomainParticipant_get_default_subscriber_qos (
DDS_SubscriberQos* qos); /* Provided by 10.b.i */
iii.Adjust partition name in the DDS_SubscriberQos structure.
Partition name provided by the connection_name attribute.
iv. DDS_Subscriber_DDS_DomainParticipant_create_subscriber (
const DDS_SubscriberQos* qos, /* Provided 10.b.i */
const struct DDS_SubscriberListener* a_listener,
/* Chosen by TSS */
v. DDS_DataReaderQos* DDS_DataReaderQos__alloc(void);
vi. DDS_ReturnCode_t DDS_Subscriber_get_default_datareader_qos (
DDS_Subscriber subscriber, /* Provided by 10.b.iv */
DDS_DataReaderQos* qos); /* Provided by 10.b.v */
vii.DDS_ReturnCode_t DDS_Subscriber_copy_from_topic_qos (
DDS_DataReaderQos* dw_qos, /* Provided by 10.b.v */
const DDS_TopicQos* topic_qos); /* Provided by 6 */
viii.DDS_DataReader DDS_Subscriber_create_datareader (
const DDS_Topic a_topic, /* Provided by 6 */
const DDS_DataReaderQos* qos, /*Provided by 10.b.v*/
const struct DDS_DataReaderListener* listener, /*Chosen by TSS*/
const DDS_StatusMask mask); /*Chosen by TSS*/
G.2.3 Destroy_Connection Function

The Destroy_Connection(TS) function frees up any resources allocated to the connection. This
can be an empty function if no cleanup is required.
ARINC 653 Sampling Port and ARINC 653 Queuing Port
The Destroy_Connection(TS) function performs no action and returns no errors for ARINC 653-
based software components.
POSIX Queue
Transport Services is responsible for tracking of the mqd_t descriptors and have them searchable
by connection name.
Transport Services is responsible for calling int mq_unlink(const char *name); after mq_close()
in Transport Services.
POSIX Shared Memory
Transport Services is responsible for tracking of the address and length of the shared memory
referenced by the connection name.
Transport Services is responsible for calling int shm_unlink(const char *name); after munmap()
in Transport Services.
For the DDS, Transport Services is responsible for tracking of the DDS_DomainParticipant and
DDS_Topic variables for deletion.
For SOURCE connection_direction, Transport Services is responsible for tracking the

DDS_Publisher and DDS_DataWriter for deletion.
For DESTINATION connection_direction, Transport Services is responsible for tracking the

DDS_Subscriber and DDS_DataReader for deletion.
module FACE
{
interface TS
{
void Destroy_Connection
( in CONNECTION_ID_TYPE connection_id,
out RETURN_CODE_TYPE return_code );
};
};
CORBA
The following CORBA method is called by Transport Services when CORBA is shutdown by
Destroy_Connection(TS).
/* NOTE: THIS IS THE CALL MADE BY TRANSPORT SERVICES */
CORBA::ORB:destroy (); // Destroy the ORB.
G.2.4 Receive_Message Function

The Receive_Message(TS) function is used to receive data from another source.
The TypeAbstraction Receive_Message(TS) is used to call the following ARINC 653 function
calls:
Sampling Port READ_SAMPLING_MESSAGE
Receive message is used to call the following POSIX function calls:

Shared Memory None.
The TSS manages the source information from the recvfrom() and recvmsg() function calls for
routing purposes.
Certain communication APIs may be called natively without using the TS Interface. For
restrictions, see Section F.4.
Receive_Message(TS) is used to call the following DDS function calls:

 SPACE_FooDataReader_take
 SPACE_FooDataReader_read
The form of this function is as follows:

module FACE
{
interface TypeAbstractionTS
{
in CONNECTION_ID_TYPE connection_id,
inout TRANSACTION_ID_TYPE transaction_id,
inout void message,
inout MESSAGE_TYPE_GUID message_type_id,
inout MESSAGE_SIZE_TYPE message_size,
};
};
When the connection is set up as a CLIENT, the transaction_id is an “in” parameter. In this
case, Receive_Message(TS) blocks until the TSS receives a response from the server matching
that transaction_id.
When the connection is set up as a SERVER, the transaction_id is an “out” parameter. In this
case, Receive_Message(TS) returns the transaction_id of the incoming message from the client.
The server component uses this transaction_id when sending a response using
Send_Message(TS).
CORBA
The following CORBA method is called by Transport Services when receiving data using
CORBA.
/* NOTE: These calls use a CORBA IDL FACE module with a
TransportObject interface. The TransportObject interface
has two methods: get_data() that returns an array of bytes
and store_data() which stores an array of bytes. The FACE
module name, the TransportObject interface name, and the
method names of get_data and store_data is
used verbatim including case. */
FACE::TransportObject:get_data (); // Get the data stored in the CORBA
object.
G.2.5 Send_Message Function

The TypeAbstraction Send_Message(TS) is used to call the following ARINC 653 function
calls:
Sampling Port WRITE_SAMPLING_MESSAGE
Queuing Port SEND_QUEUING_MESSAGE
Send_Message(TS) is used to call the following POSIX function calls:
Sockets send(), sendmsg(), sendto()
Shared Memory None.
The TSS manages the destination information from the sendto() and sendmsg() function calls for
routing purposes.
Certain communication APIs may be called natively without using the TS Interface. For
restrictions, see Section F.4.
Send message is used to call the following DDS function call:

 SPACE_FooDataWriter_write()
The form of this function is as follows:

module FACE
{
interface TypeAbstractionTS
{
void Send_Message (
inout TRANSACTION_ID_TYPE transaction_id,
inout void message,
in MESSAGE_TYPE_GUID message_type_id,
in MESSAGE_SIZE_TYPE message_size,
};
};
When the connection is set up as a CLIENT, the transaction_id is an “out” parameter. In this
case, TSS generates a unique transaction_id and returns it. Subsequently, the client component
passes this to Receive_Message(TS) when waiting on the response from the server.

When the connection is set up as a SERVER, the transaction_id is an “in” parameter. In this
case, Send_Message(TS) transmits the transaction_id to the client. This identifies the request to
which the server is responding.
CORBA
The following CORBA method is called by the TSS when sending data using CORBA.
/* NOTE: These calls use a CORBA IDL FACE module with
TransportObject interface. The TransportObject interface
has two methods: get_data() that returns an array of bytes
and store_data() which stores an array of bytes. The FACE
module name, the TransportObject interface name, and the
method names of get_data and store_data is
used verbatim including case */
FACE::TransportObject:store_data(); // Store the data in the CORBA
object.
G.2.6 Register_Callback Function

The purpose of Register_Callback(TS) is to provide a mechanism to read data without polling.
This is used for Publish/Subscribe transportation mechanisms. Certain communication APIs may
be called natively without using the Transport Interface. For restrictions, see Section F.4.
Register read callback is used to address periodic ARINC 653 function calls without having to
poll for data:
The Register_Callback(TS) call is used to address periodic POSIX function calls without having
to poll for data:
Shared Memory None.
The TSS manages the source information from the recvfrom() and recvmsg() function calls for
routing purposes. The form of this function is as follows:
module FACE
{
interface TypeSpecificTS
{
void Register_Callback (
in WAITSET_TYPE waitset,
inout Read_Callback data_callback,
in MESSAGE_SIZE_TYPE max_message_size,
};
};
There is only one registration per connection_id.
G.2.7 Unregister_Callback Function

The purpose of Unregister_Callback(TS) is to provide a mechanism to unregister the callback
associated with a connection_id. The form of this function is as follows:
module FACE
{
interface TypeSpecificTS
{
void Unregister_ Callback
( in CONNECTION_ID_TYPE connection_id,
};
};
G.2.8 Get_Connection_Parameters Function

The purpose of Get_Connection_Parameters(TS) is to get the information regarding the
requested connection. Certain communication APIs may be called natively without using the TS
Interface. For restrictions, see Section F.4.
The get_connection_parameters() call is used to call the following ARINC 653 function calls:
Sampling Port GET_SAMPLING_PORT_ID

GET_SAMPLING_PORT_STATUS
Queuing Port GET_QUEUING_PORT_ID

GET_QUEUING_PORT_STATUS
POSIX calls:
Sockets getsockname()
Message Queue mq_getattr()
Shared Memory None.
DDS does not need to call anything to determine the status of the connection. The most recent
DDS_ReturnCode_t or the validity of DataReader/Writer handles can be used to determine the
connection status.
module FACE
{
interface TS
{
void Get_Connection_Parameters
( inout CONNECTION_NAME_TYPE connection_name,
inout CONNECTION_ID_TYPE connection_id,

out TRANSPORT_CONNECTION_STATUS_TYPE connection_status,
};
};
H Example USM FACE XMI
<face:DataModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:conceptual="http://www.opengroup.us/face/conceptual/2.1" xmlns:face="http://www.opengroup.us/face/2.1"
xmlns:logical="http://www.opengroup.us/face/logical/2.1"
xmlns:platform="http://www.opengroup.us/face/platform/2.1" xmlns:uop="http://www.opengroup.us/face/uop/2.1"
xmi:id="_AJ9NYBRAEeSZNohePfXakg" name="FACE_Data_Model">
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_3511E63F_1D0B_4e10_A561_57648BBF67D4"
name="Conceptual_Model">
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_B39E9DAD_7B4E_4eff_89C0_FCD963B8235C"
name="Observables">
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_944C9593_EADB_41f9_BE22_B7F71BBA5E8E"
name="InformationElement" description="Abstract information that applies to attributes of an entity
(e.g., text, diagrams, labels, etc.)">
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_1234D951_C778_464c_84EB_7081F576A92E"
name="Description">
<element xmi:type="conceptual:Observable" xmi:id="EAID_137FD219_342E_47be_A785_7324D2954BAB"
name="Description" description="Summary level information about an item."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_6E186690_63B7_4e35_8E7E_B5D8DFFD6D2E"
name="Name">
<element xmi:type="conceptual:Observable" xmi:id="EAID_44DA0EBC_675A_476f_8EC1_E10C43728A21"
name="Name" description="Human meaningful term for referring to an item. Names are often but not
always unique for a given entity."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_53BCC2C7_42F6_46b7_9DD0_7F901BF5AF83"
name="Status">
<element xmi:type="conceptual:Observable" xmi:id="EAID_7BF4374F_EC27_40ba_B155_54CEA52345C2"
name="HealthStatus" description="Condition of an item with respect to some purpose or use."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_F87F5A3C_11D8_4b0f_9FDF_9449EBC63D3F"
name="Validity">
<element xmi:type="conceptual:Observable" xmi:id="EAID_629FBDD0_AEAD_41f0_9C6F_603D7CF9D269"
name="Validity" description="Indication of fitness of information with respect to some use or
purpose."/>
</cdm>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_259A9F0C_5DB1_4fb3_B9E2_C0EBB9654C1B"
name="Orientation">
<element xmi:type="conceptual:Observable" xmi:id="EAID_AB3FAE18_6F92_4a74_812F_77AF2DCD6F6F"
name="Orientation" description="Angular position of an object relative to a fixed reference frame
that describes how the object is placed."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_FD9862C9_B48C_481a_8116_AF98D0A35708"
name="AmountOfSubstance">
<element xmi:type="conceptual:Observable" xmi:id="EAID_280D1606_DD95_455c_B535_04810D45E721"
name="AmountOfSubstance" description="Quantity of elementary entities, such as atoms, molecules,
electrons, and other particles."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_0016984E_BB39_4f54_95F7_41C62B101EBF"
name="ChemicalConcentration" description="Amount of substance contained within a defined volume or
mass."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_23E097F2_6E1A_4d74_B068_649072247CC5"
name="Angle">
<element xmi:type="conceptual:Observable" xmi:id="EAID_5977632F_0313_4d51_82A4_E716D94C7D7D"
name="Angle" description="Divergence of two straight lines from a common point or of two planes
from a common line."/>
</cdm>

<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_98D3DCF6_6061_48db_9FC9_9BD741CA665C"
name="Area">
<element xmi:type="conceptual:Observable" xmi:id="EAID_4B94E0C3_63C2_4166_9A21_564E6B39FEE1"
name="Area" description="Magnitude of a surface space."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_60F805D3_2250_4e40_81E6_5C474709C019"
name="Counting">
<element xmi:type="conceptual:Observable" xmi:id="EAID_39CB7F84_FBC5_4861_BD11_FAC97574B2A2"
name="Count" description="Total number of a collection of objects."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_D6D476D1_7FDC_4375_B79B_785E5E9EBA3D"
name="ScreenResolution" description="Number of pixels per unit area. "/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_7116FAF1_D771_4dcf_A9CF_112EC57E77D8"
name="Density">
<element xmi:type="conceptual:Observable" xmi:id="EAID_4D9CB92E_1010_4fd8_9520_0184188C4374"
name="Density" description="Mass of a substance per unit volume."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_29F6EF02_F3F2_4590_8A84_3F28FE25B16F"
name="Humidity" description="Amount of water vapor in the atmosphere or in a gas."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_ACB62864_ED0D_4e1e_AE3D_58581E71754C"
name="DoseEquivalent">
<element xmi:type="conceptual:Observable" xmi:id="EAID_29F32E46_EDB2_472d_80CA_7B91F8275889"
name="DoseEquivalent" description="Biological effectiveness of an absorbed dose of ionizing
radiation."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_AAFBD590_8038_4a34_B35C_1AB8A5559744"
name="Electricity">
<element xmi:type="conceptual:Observable" xmi:id="EAID_FFF9F507_6448_48bd_B548_5B85F4057903"
name="ElectricCapacitance" description="Ability of an item to store an electrical change."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_0B869DF6_099A_4526_95F5_4BFC7393718E"
name="ElectricCharge" description="Extent to which an item has more or fewer electrons than
protons."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_CAE607F9_8F99_4a23_854E_8B8536720799"
name="ElectricChargeDensity" description="Electric charge per unit volume of space, in one, two or
three dimensions which are per unit length, surface area, or volume respectively."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_35DDCEBF_B184_4159_B5C4_932587A840B5"
name="ElectricCurrent" description="Movement of electric charge through a medium."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_60A46947_91C7_4bc7_A74D_1DE2137E5CC5"
name="ElectricCurrentDensity" description="Amount of net charge that crosses an area perpendicular
to the current flow per time period."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_FD27C3E6_3A30_45b8_B836_91CD599BD168"
name="ElectricPotential" description="Difference in electric charge between two points."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_29322D03_5221_4476_BCE0_FCD59CEADE7E"
name="Energy">
<element xmi:type="conceptual:Observable" xmi:id="EAID_AFCB75C7_863B_4112_8F1E_2FB4FE1D4D2A"
name="AbsorbedDose" description="Radiation energy absorbed by unit mass of substances."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_EEED99B8_359B_41bf_B6B0_2BA8EC5E1B07"
name="AbsorbedDoseRate" description="Rate of radiation energy absorbed by unit mass of
substances."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_32D02294_1A54_48ee_AA9D_2EA0EDBC4B76"
name="Energy" description="Capacity of a physical system to perform work."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_5D8EBA55_61ED_4e7e_8F29_9F619CA59DC0"
name="Force">
<element xmi:type="conceptual:Observable" xmi:id="EAID_B4FA8AFA_1FC5_4cc3_8E95_1956D00176DC"
name="Force" description="Influence on an object with a mass."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_69A1D868_1DE4_4fce_9C0B_7A47AB1FC46B"
name="Torque" description="Twisting force that tends to cause rotation."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_9CF8817E_BFC5_4933_BEDB_629449526974"
name="Identifier">
<element xmi:type="conceptual:Observable" xmi:id="EAID_B14C698C_13F8_434c_9D67_54CF514CA74E"
name="UniqueIdentifier" description="Distinguishes an item from all other items."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_BC5499CE_F7FA_4e9c_810F_9E8C3CE5ADC3"
name="Illuminance">
<element xmi:type="conceptual:Observable" xmi:id="EAID_F07E3618_8CE7_4422_9D21_C8FBB9D77794"
name="Illuminance" description="Total luminous flux incident on a surface per unit area."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_7C07FAB4_CDF5_4a09_9787_55E357205B81"
name="Length">
<element xmi:type="conceptual:Observable" xmi:id="EAID_80D92BE8_8DF0_4f7c_82A6_CBF5DF17443A"
name="Distance" description="Amount of separation between two points."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_0C0725EB_2FB1_46d2_A11A_716E6D6299E3"
name="Extent" description="Dimensions of the bounding region encompassing the item."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_1D725B44_BAC9_4733_8D4B_4F072340BC6F"
name="LuminousIntensity">
<element xmi:type="conceptual:Observable" xmi:id="EAID_8B463517_0982_4cd0_884D_DD91D17AC345"
name="LuminousIntensity" description="Wavelength weighted power emitted by a light source in a
particular direction per unit solid angle."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_6133412F_3EAA_4a9b_8B54_C2A30F2E4A0C"
name="Mass">
<element xmi:type="conceptual:Observable" xmi:id="EAID_5D0D98B4_F3C5_4131_ACA9_A6CBCDEE8F6B"
name="Mass" description="Amount of matter in a physical body (solid, liquid, gas) which determines
the body's resistance to being accelerated by a force and the strength of its mutual gravitational
attraction with other bodies."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_87B06E46_6F77_4b0f_B10F_811F93CF30BF"
name="Position">
<element xmi:type="conceptual:Observable" xmi:id="EAID_7CA3D9F9_0614_4f82_A971_D2367427403F"
name="Position" description="Location of an item relative to a fixed reference frame."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_C73A97BA_5AAF_4a5a_A17D_D3F6C6378F53"
name="Power">
<element xmi:type="conceptual:Observable" xmi:id="EAID_0FE1D4CF_7DB9_46c2_961B_2C3AB44B694F"
name="Power" description="Rate at which work is performed or energy is converted."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_2AA28623_C4E2_4471_85F6_79A1D13E5768"
name="Pressure">
<element xmi:type="conceptual:Observable" xmi:id="EAID_54D14004_BB23_4f72_95FB_9FF384A743A7"
name="Pressure" description="Force per unit area perpendicular to the surface of an item."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_82448C3A_F8D7_4ffd_A311_F530C41FA5ED"
name="Rate">
<element xmi:type="conceptual:Observable" xmi:id="EAID_A082A853_2D96_4222_8065_D06483A48AE8"
name="Acceleration" description="Rate of change of velocity per unit time."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_E0FD8349_12D2_40aa_9131_1FF4BA823E26"
name="AngularAcceleration" description="Rate of change of angular velocity."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_21309243_2D0E_4536_8135_69F86BE3D515"
name="AngularVelocity" description="Norm of a vector of angular motion of the target body."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_29913A1B_DFBB_4db4_AE2B_93C6CC1EF116"
name="CountRate" description="Rate at which a total amount is accumulated over a time period."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_5C94882D_D81D_44fd_9A96_04915D63D7BD"
name="DataRate" description="Quantity of data transferred over a defined time period."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_2435A700_DF6F_4e88_98FA_05AD14BA5F5D"
name="MassFlowRate" description="Mass of substance which passes through a given surface per unit
time."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_6A475A9C_9D31_4f7e_92EF_2D00DE6F7E66"
name="OrientationAcceleration" description="Rate of change in Orientation Velocity."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_8A6BA64A_0232_41e4_AA18_CD71B80A66DC"
name="OrientationVelocity" description="Rate of change in Orientation."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_CD425350_A680_49d4_974D_4052C9BABB30"
name="ScalarAcceleration" description="Rate of change of speed."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_06B460A8_5CEC_4e63_9607_4413DB527E37"
name="Speed" description="Rate at which an object covers a distance."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_6576E8D2_2D88_4881_819E_7CA0B661B8A5"
name="TemporalFrequency" description="Number of occurrences of a repeating event per unit time.
Events are assumed to have a uniform period."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_331BB7F2_6E37_433e_8027_991D9E82BA67"
name="Velocity" description="Rate at which an object covers a distance in a specified direction."/>
</cdm>

<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_C48D59AA_06DF_480b_A3DE_113C0620BD16"
name="Temperature">
<element xmi:type="conceptual:Observable" xmi:id="EAID_2912B4B3_E784_4796_A911_6CE50C6872FB"
name="Temperature" description="Average kinetic energy of particles in an item (i.e., how hot or
cold the item is)."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_413788BB_764C_45d6_BBB3_904F396F92A3"
name="TemperatureDelta" description="A change or difference between two temperatures."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_2F81B2B6_4024_4e4d_BDC2_34DBD1B84CE4"
name="Time">
<element xmi:type="conceptual:Observable" xmi:id="EAID_6F2C6003_64FF_42a1_B4D1_00E34745B793"
name="CalendarTime" description="Position in time, a realization of which could be a specific date
& time on a calendar. This is not to be used for time durations, which would be the difference
between two time observables."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_4E729952_4D4F_46f9_B372_04489372E9D4"
name="Duration" description="Quantity of time, such as would be obtained from the difference
between two specific date/times on a calendar (i.e., the difference between two CalendarTime
observables)."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_FF5D2D41_EF3E_434e_8501_96DBDD70DECD"
name="TimeOfDay" description="Instant within a calendar day."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_4C132758_4862_40cf_8CC9_3F02FF5C88BD"
name="Viscosity">
<element xmi:type="conceptual:Observable" xmi:id="EAID_C58154E2_40C4_466f_AAF2_CF0751E434A6"
name="DynamicViscosity" description="Property of a fluid that expresses its resistance to shearing
flows. Also called Shear Viscosity."/>
<element xmi:type="conceptual:Observable" xmi:id="EAID_9894902C_4D24_43b6_9EA0_3FC535B15003"
name="KinematicViscosity" description="Property of a fluid that is the ratio of its resistance to
shearing flows (i.e., its dynamic viscosity) to its density."/>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_619822DB_095A_4c7c_8B95_078BF3ACB963"
name="Volume">
<element xmi:type="conceptual:Observable" xmi:id="EAID_363355FA_D46C_4c74_BF38_B9466951F1A0"
name="Volume" description="Magnitude of a three dimensional space."/>
</cdm>
</cdm>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_CA6F30CB_009C_4376_A141_E6728E72E76B"
name="USM_CDM">
<element xmi:type="conceptual:Entity" xmi:id="_AJ90cBRAEeSZNohePfXakg" name="EGI"
description="Conceptual entity representing the Embedded Global Positioning System (GPS) / Inertial
Navigation System (INS).">
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_CkBRAEeSZNohePfXakg" rolename="attitude"
type="EAID_AB3FAE18_6F92_4a74_812F_77AF2DCD6F6F"/>
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_CkhRAEeSZNohePfXakg" rolename="id"
type="EAID_B14C698C_13F8_434c_9D67_54CF514CA74E"/>
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_CkRRAEeSZNohePfXakg" rolename="position"
type="EAID_7CA3D9F9_0614_4f82_A971_D2367427403F"/>
</element>
<element xmi:type="conceptual:Entity" xmi:id="_AJ_CkxRAEeSZNohePfXakg" name="InertialMeasurementUnit"
description="Conceptual entity representing the inertial measurement unit(s) (IMU).">
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_ClBRAEeSZNohePfXakg" rolename="attitude"
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_ClRRAEeSZNohePfXakg" rolename="id"
</element>
<element xmi:type="conceptual:Association" xmi:id="_AJ_ClhRAEeSZNohePfXakg"
name="NavManagementFunction" description="Conceptual entity representing the navigation management
function which performs the navigation solution determination based on the EGI and IMU source(s).">
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_ClxRAEeSZNohePfXakg" rolename="attitude"
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_poRRAEeSZNohePfXakg" rolename="id"
<composition xmi:type="conceptual:Composition" xmi:id="_AJ_poBRAEeSZNohePfXakg" rolename="position"
type="EAID_7CA3D9F9_0614_4f82_A971_D2367427403F"/>
<associatedEntity xmi:type="conceptual:AssociatedEntity" xmi:id="_AJ_pohRAEeSZNohePfXakg"
rolename="imuNavSource" upperBound="-1" type="_AJ_CkxRAEeSZNohePfXakg" path=""/>
<associatedEntity xmi:type="conceptual:AssociatedEntity" xmi:id="_AJ_poxRAEeSZNohePfXakg"
rolename="egiNavSource" upperBound="-1" type="_AJ90cBRAEeSZNohePfXakg" path=""/>
</element>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="EAID_F26F2D3F_ACAF_42fe_B3AA_B7518E7B5F64"
name="Observables"/>
<cdm xmi:type="face:ConceptualDataModel" xmi:id="_AJ_ppBRAEeSZNohePfXakg" name="ConceptualViews">
<element xmi:type="conceptual:View" xmi:id="_AKA3whRAEeSZNohePfXakg" name="EGI_Data">
<characteristic xmi:type="conceptual:CharacteristicProjection" xmi:id="_AKA3wxRAEeSZNohePfXakg"
projectedCharacteristic="_AJ90cBRAEeSZNohePfXakg" rolename="att" path=".attitude"/>
<characteristic xmi:type="conceptual:CharacteristicProjection" xmi:id="_AKA3xBRAEeSZNohePfXakg"
projectedCharacteristic="_AJ90cBRAEeSZNohePfXakg" rolename="pos" path=".position"/>
</element>
<element xmi:type="conceptual:View" xmi:id="_AKAQsBRAEeSZNohePfXakg" name="IMU_Data">
<characteristic xmi:type="conceptual:CharacteristicProjection"
xmi:id="EAID_53314BC3_ABC7_4bb6_8A78_006A8DFB5EA7"
projectedCharacteristic="_AJ_CkxRAEeSZNohePfXakg" rolename="att" path=".attitude"/>
</element>
<element xmi:type="conceptual:View" xmi:id="_AKA3xRRAEeSZNohePfXakg" name="Nav_Data">
<characteristic xmi:type="conceptual:CharacteristicProjection" xmi:id="_AKA3xhRAEeSZNohePfXakg"
projectedCharacteristic="_AJ_ClhRAEeSZNohePfXakg" rolename="att" path=".attitude"/>
<characteristic xmi:type="conceptual:CharacteristicProjection" xmi:id="_AKA3xxRAEeSZNohePfXakg"
projectedCharacteristic="_AJ_ClhRAEeSZNohePfXakg" rolename="pos" path=".position"/>
</element>
</cdm>
</cdm>
</cdm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9BA39F14_4927_484a_B00F_7D1C8B0CC103"
name="Logical_Model">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1D413311_4852_40a3_8919_33A7AD77146E"
name="CoordinateSystems">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5F7EE196_6B19_4727_BBA7_C39452D13B3C"
name="Cartesian">
<element xmi:type="logical:CoordinateSystem" xmi:id="EAID_D73E1979_E607_48ce_A01F_2EAD5226614D"
name="Cartesian1D" description="One dimensional Cartesian coordinate system."
axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087" axisRelationshipDescription="There is only one
axis." angleEquation="n/a" distanceEquation="d = x2-x1"/>
<element xmi:type="logical:CoordinateSystem" xmi:id="EAID_91380EB8_66EF_4d12_AC1D_84FF7F719080"
name="Cartesian2D" description="Two dimensional Cartesian coordinate system."
axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087 EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
axisRelationshipDescription="Axes are orthogonal to each other." angleEquation="theta = inverse cos
((a dot b)/(|a|*|b|)), where a and b are vectors." distanceEquation="d=sqrt((x2-x1)^2+(y2-y1)^2)"/>
<element xmi:type="logical:CoordinateSystem" xmi:id="EAID_E16B78B2_B2BA_43e5_837E_018DC1FD621C"
name="Cartesian3D" description="Three dimensional Cartesian coordinate system."
axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087 EAID_185CD9A8_B677_41ab_907D_C7F232756DCE
EAID_C74601C9_0E7A_483b_AD4C_28D64BE141E3" axisRelationshipDescription="Axes are orthogonal to each
other." angleEquation="theta = inverse cos ((a dot b)/(|a|*|b|)), where a and b are vectors."
distanceEquation="d = sqrt((x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2)"/>
<element xmi:type="logical:CoordinateSystem" xmi:id="EAID_B55C9EAD_191D_4857_B016_3DA66484CD06"
name="Cartesian4D" description="4 dimensional Cartesian coordinate system."
axis="EAID_B9400988_0D42_4158_B085_F2301B7EC419 EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087
EAID_185CD9A8_B677_41ab_907D_C7F232756DCE EAID_C74601C9_0E7A_483b_AD4C_28D64BE141E3"
axisRelationshipDescription="Axes are orthogonal to each other." angleEquation="theta = inverse cos
((a dot b)/(|a|*|b|)), where a and b are vectors." distanceEquation="d = sqrt((x2-x1)^2 + (y2-y1)^2
+ (z2-z1)^2 + (t2-t1)^2)"/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="EAID_B9400988_0D42_4158_B085_F2301B7EC419"
name="CartesianTAxis" description="T (time) axis of Cartesian coordinate system"/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
name="CartesianXAxis" description="X Axis of Cartesian coordinate system."/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
name="CartesianYAxis" description="Y Axis of Cartesian coordinate system"/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="EAID_C74601C9_0E7A_483b_AD4C_28D64BE141E3"
name="CartesianZAxis" description="Z Axis of Cartesian coordinate system"/>
</ldm >
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E26AFB94_7E63_47b5_A95F_373A0B2B8F3B"
name="Discrete">
<element xmi:type="logical:CoordinateSystem" xmi:id="EAID_9073ABED_00F3_4b1f_8045_9AE46DBC3456"
name="Discrete1D" description="Coordinate system used to model sets of discrete states (e.g.,
enumerations)." axis="EAID_DBE6EC88_CB55_4a45_8937_D79C72C5D688" axisRelationshipDescription="n/a"
angleEquation="n/a" distanceEquation="n/a"/>

<element xmi:type="logical:CoordinateSystemAxis" xmi:id="EAID_DBE6EC88_CB55_4a45_8937_D79C72C5D688"
name="DiscreteSetAxis" description="The axis used to represent a set of discrete states (e.g., a
set of enumerations)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1EA992A2_64A8_405a_9F50_9C328D38069D"
name="Polar3D">
<element xmi:type="logical:CoordinateSystem" xmi:id="_vZiY1wg5EeSFspy8Kj3F4Q" name="Polar3D"
description="Describes a two dimensional (2D) Polar coordinate system."
axis="_vZiY1Ag5EeSFspy8Kj3F4Q _vZiY1gg5EeSFspy8Kj3F4Q _vZiY1Qg5EeSFspy8Kj3F4Q"
axisRelationshipDescription="" angleEquation="" distanceEquation=""/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="_vZiY1Ag5EeSFspy8Kj3F4Q"
name="Polar3DAngularAxis"/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="_vZiY1gg5EeSFspy8Kj3F4Q"
name="Polar3DAzimuthalAxis"/>
<element xmi:type="logical:CoordinateSystemAxis" xmi:id="_vZiY1Qg5EeSFspy8Kj3F4Q"
name="Polar3DRadialAxis"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6E6385F7_641B_446e_BC94_0298C7D73125"
name="LogicalValueTypes" description="The types available to represent the values of Measures">
<element xmi:type="logical:Boolean" xmi:id="EAID_16DE4A98_8206_47b3_A77D_39227129E528" name="Boolean"
description="A type that can represent only two values, often meaning True or False"/>
<element xmi:type="logical:Character" xmi:id="EAID_CE8514D2_720F_447f_AA6A_B22659E23666"
name="Character" description="A type representing a single character in some written language"/>
<element xmi:type="logical:Enumerated" xmi:id="EAID_B5C091B5_8C32_4e6a_B9D9_9114CE1D748B"
name="Enumerated" description="A type used to represent a value that is selected from distinct,
predefined set of possible values" standardReference="">
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_2452D895_DC9D_4226_9D23_224053B492CB"
name="DEFAULT_ENUMERATION_LABEL"/>
</element>
<element xmi:type="logical:Integer" xmi:id="EAID_372D8BFC_47B1_4385_AD77_6703541E7FAC" name="Integer"
description="A whole number in the range -infinity to +infinity"/>
<element xmi:type="logical:Natural" xmi:id="EAID_7DE12CF5_1B85_482b_9830_783D356833E9" name="Natural"
description="A whole number ranging from +1 to +infinity; also called "counting numbers""/>
<element xmi:type="logical:NonNegativeReal" xmi:id="EAID_1EA04603_631A_403e_82FD_D6E5825D1F31"
name="NonNegativeReal" description="A real number ranging from 0 to +infinity"/>
<element xmi:type="logical:Real" xmi:id="EAID_7CB1E0A3_7D27_45fa_BF9E_22EB15886D68" name="Real"
description="A type to represent any numeric quantity along a continuous line. Real numbers include
all rational and irrational numbers"/>
<element xmi:type="logical:String" xmi:id="EAID_B93CB919_D464_4577_82EB_0298B395EDB4" name="String"
description="A type used to represent an ordered set of characters in some written language"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_0AC531F9_F91B_460e_A7C3_27859F3E8A79" name="Measures"
description="FACE data model logical measurements.">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_25F84E64_2935_4cd9_88C8_D0D1B91FBBB1"
name="VolumeMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_CD94D57B_BFAF_4f19_8129_43362BD5FC10"
name="VolumeMeasurement" description="Measurement to hold values of volume."
measurementAxis="EAID_BF654B2D_5864_49de_879B_96C9BDD7684A"
measurementSystem="EAID_A1ED4E98_B10D_4e7f_BFAD_86BA34D7C3DB"
realizes="EAID_363355FA_D46C_4c74_BF38_B9466951F1A0"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_BF654B2D_5864_49de_879B_96C9BDD7684A"
name="VolumeMeasurementAxis" description="Measurement taxis to hold values of volume."
precision="0.001" measurementSystemAxis="EAID_F7F3A12A_7530_4370_9235_928317E0BC98"
realizes="EAID_363355FA_D46C_4c74_BF38_B9466951F1A0"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_621304AA_28B7_423c_8816_643563B97A7F"
name="VolumeLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_1550FA6E_1F8C_4b47_9DC2_F36336B730F0"
name="OneCubicMeterLandmark" description="Landmark for a value of one cubic meter of volume."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_2205BF3D_7A57_4440_A3B4_1D1EE359EFDF"
name="ZeroVolumeLandmark" description="Landmark for zero volume"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BA0C3A35_FA8A_411f_8D1E_8BF51136EFC5"
name="VolumeMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_F77FC9A7_BB84_4e52_96C5_088210366367"
name="NonNegativeRealCubicMeters" description="Non-negative Real cubic meters"
unit="EAID_B6983E55_B326_4925_B8B0_0EF9E75250DD"
valueType="EAID_1EA04603_631A_403e_82FD_D6E5825D1F31"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_A1ED4E98_B10D_4e7f_BFAD_86BA34D7C3DB"
name="VolumeMeasurementSystem" description="Measurement system for values of volume."
measurementSystemAxis="EAID_F7F3A12A_7530_4370_9235_928317E0BC98"
coordinateSystem="EAID_D73E1979_E607_48ce_A01F_2EAD5226614D" externalStandardReference=""
orientation="Values increase as volume increases.">
<referencePoint xmi:type="logical:ReferencePoint"
xmi:id="EAID_E74EA2A2_D555_4371_9AC2_C14B2243D666" name="ZeroVolumeReferencePoint"
description="Reference point for a zero volme"
landmark="EAID_2205BF3D_7A57_4440_A3B4_1D1EE359EFDF">
<referencePointPart xmi:type="logical:ReferencePointPart"
xmi:id="EAID_A1182165_AEE6_4671_8589_54799FFD9E3C"
axis="EAID_F7F3A12A_7530_4370_9235_928317E0BC98" value="0.0"
valueTypeUnit="EAID_F77FC9A7_BB84_4e52_96C5_088210366367"/>
</referencePoint>
xmi:id="EAID_18278755_32E3_4550_A88E_C57EE92ECFEF" name="OneCubicMeterReferencePoint"
description="reference point for a volume of one cubic meter."
landmark="EAID_1550FA6E_1F8C_4b47_9DC2_F36336B730F0">
xmi:id="EAID_5F2E34BC_46ED_4b54_8866_4878F80D86BB"
axis="EAID_F7F3A12A_7530_4370_9235_928317E0BC98" value="1.0"
valueTypeUnit="EAID_F77FC9A7_BB84_4e52_96C5_088210366367"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis"
xmi:id="EAID_F7F3A12A_7530_4370_9235_928317E0BC98" name="VolumeMeasurementSystemAxis"
description="Measurement system axis for values of volume."
axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_F77FC9A7_BB84_4e52_96C5_088210366367"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_7A761013_2939_482c_9DBE_FBFE3256BAF6"
name="TemporalFrequency" description="Logical model for the number of occurrences of a repeating
event per unit time">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_AFB6D10F_59C7_4f0b_882F_858971C1E91D"
name="RealHertz" description="Temporal frequency as real number in Hertz"
unit="EAID_161469CC_7BFE_4206_BF8E_17E105C1A679"
valueType="EAID_7CB1E0A3_7D27_45fa_BF9E_22EB15886D68"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_173741CF_C731_4508_AFC9_DB1919375D9C"
name="OneHertzLandmark" description="One occurrence of a repeatable event per second"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_4221DC2B_A11C_4974_B680_59E35E5F3D34"
name="ZeroFrequencyLandmark" description="No occurrences of a repeatable event"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_FFDFA047_BDBD_4ab3_A66D_B8AB68DBA582"
name="TemporalFrequencyMeasurementSystem" description="Measurement system for frequency of periodic
events." measurementSystemAxis="EAID_FB000C46_0D64_4280_8E88_5C967757A7BE"
coordinateSystem="EAID_D73E1979_E607_48ce_A01F_2EAD5226614D"
externalStandardReference="International System of Units (SI)" orientation="Value increases as
frequency increases.">
xmi:id="EAID_78B1F6C4_434F_4197_B3C3_001A14EC2BDA" name="OneHertzReferencePoint"
description="One occurrence per second" landmark="EAID_173741CF_C731_4508_AFC9_DB1919375D9C">
xmi:id="EAID_0CDFCF20_54D5_49fd_870A_8B329ABF6C87"
axis="EAID_FB000C46_0D64_4280_8E88_5C967757A7BE" value="1.00"
valueTypeUnit="EAID_AFB6D10F_59C7_4f0b_882F_858971C1E91D"/>
</referencePoint>
xmi:id="EAID_1CF7F1AF_B4BF_408c_8CDB_6B7AC1939E01" name="ZeroFrequencyReferencePoint"
description="No occurrences per second" landmark="EAID_4221DC2B_A11C_4974_B680_59E35E5F3D34">
xmi:id="EAID_5E653C8A_BDAA_4470_A3DF_CBF01A408367"
axis="EAID_FB000C46_0D64_4280_8E88_5C967757A7BE" value="0.00"
valueTypeUnit="EAID_AFB6D10F_59C7_4f0b_882F_858971C1E91D"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_FB000C46_0D64_4280_8E88_5C967757A7BE"
name="TemporalFrequencyMeasurementSystemAxis" description="Measurement axis for frequency."

defaultValueTypeUnit="EAID_AFB6D10F_59C7_4f0b_882F_858971C1E91D"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_2C068008_5E90_4c8f_95A3_0E3A0B58E47D"
name="TemporalFrequencyMeasurement" description="Measurement of frequency measured in Hertz with
Real numbers" measurementAxis="EAID_4C2554B4_612B_4aae_A5E3_D82BD8F258F9"
measurementSystem="EAID_FFDFA047_BDBD_4ab3_A66D_B8AB68DBA582"
realizes="EAID_6576E8D2_2D88_4881_819E_7CA0B661B8A5"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_4C2554B4_612B_4aae_A5E3_D82BD8F258F9"
name="TemporalFrequencyMeasurementAxis" precision="0.01"
measurementSystemAxis="EAID_FB000C46_0D64_4280_8E88_5C967757A7BE"
realizes="EAID_6576E8D2_2D88_4881_819E_7CA0B661B8A5">
<constraint xmi:type="logical:MeasurementConstraint"
xmi:id="EAID_1AD1DBF7_E59A_4717_A123_3F3561C46C1C" constraintText="Always >= 0"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C83D14DB_1EF5_4bc1_87FA_DD3DAA43AE9E"
name="IdentifierMeasures"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_45B09A4F_264A_412d_A307_58F430F2950C"
name="InformationElementMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F4C72C8B_7433_4eca_B397_0C9B4186E6F8"
name="AbstractDiscreteSetMeasurementSystem">
<element xmi:type="logical:Enumerated" xmi:id="EAID_87E593E9_A387_4059_89D3_2186644F837E"
name="AbstractDiscreteSet" description="Set of discrete states for the
AbstractDiscreteSetMeasurementSystemAxis that has one "dummy" state for metamodel
conformance. This set must be overridden on real Measurement's MeasurementAxis with the actual set
of states used by the measurement." standardReference="">
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_4517C956_4977_4893_BD7F_DAAAD28718AA"
name="AbstractState"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_1356F678_1656_494d_9587_5615F7840EFA"
name="AbstractDiscreteSetUnitless" description="Abstract set of states for the
AbstractDiscreteSetMeasurementSystem, which must be overridden in the MeasurementAxis for a
"real" Measurement." unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
valueType="EAID_87E593E9_A387_4059_89D3_2186644F837E"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_0D6D5FAF_71A2_4452_B2F9_AB8F15C4D13F"
name="AbstractDiscreteSetMeasurementSystem" description="A template MeasurementSystem referenced by
all "real" Measurements whose value is one of a set of selected discrete states (e.g.,
enumerations & multi-state variables). The Measurement must specify the real state set in it's
MeasurementAxis discrete set." measurementSystemAxis="EAID_A60E666A_2E05_4c81_A7CB_BDE7B7C3A189"
coordinateSystem="EAID_9073ABED_00F3_4b1f_8045_9AE46DBC3456" externalStandardReference=""
orientation="n/a"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_A60E666A_2E05_4c81_A7CB_BDE7B7C3A189"
name="AbstractDiscreteSetMeasurementSystemAxis" description="Axis for the
AbstractDiscreteSetMeasurementSystem. All "real" MeasurementAxes must reference this
MSAxis and must override the ValueTypeUnitPair with one that specifies the real states in the
Measurement's discrete set." axis="EAID_DBE6EC88_CB55_4a45_8937_D79C72C5D688"
defaultValueTypeUnit="EAID_1356F678_1656_494d_9587_5615F7840EFA"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D3DABF9D_36F9_4b7b_97CA_49D419B4AAB8"
name="TextMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D0C34A2D_4DF4_435b_BD0D_39375F4DC173"
name="StringUnitless" description="The StringUnitless ValueType is typically used for text based
measurement systems." unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
valueType="EAID_B93CB919_D464_4577_82EB_0298B395EDB4"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_3328F5AF_7CAE_4149_A03E_EB78F6653396"
name="TextUTF8MeasurementSystem" description="A TextMeasurementSystem supports definition of a
single text element. UTF-8 was chosen as the default string encoding."
measurementSystemAxis="EAID_53E5C75D_0FAB_4090_9AB4_763E7AEF327C"
coordinateSystem="EAID_9073ABED_00F3_4b1f_8045_9AE46DBC3456" externalStandardReference="UTF-8"
orientation="N/A"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_53E5C75D_0FAB_4090_9AB4_763E7AEF327C"
name="TextUTF8MeasurementSystemAxis" description="Representation of a single text based axis."
axis="EAID_DBE6EC88_CB55_4a45_8937_D79C72C5D688"
defaultValueTypeUnit="EAID_D0C34A2D_4DF4_435b_BD0D_39375F4DC173"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_6AB00B4C_3201_4a5e_B0CC_A52DDF2F4571"
name="DescriptionMeasurement" description="Measurement representing a description as a single
element" measurementAxis="EAID_19947789_47A4_4add_A517_DF904813B923"
measurementSystem="EAID_3328F5AF_7CAE_4149_A03E_EB78F6653396"
realizes="EAID_137FD219_342E_47be_A785_7324D2954BAB"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_29A7DF39_BC02_4cf3_8899_D586B7220C67"
name="NameMeasurement" description="Measurement for representing a name."
measurementAxis="EAID_C1593D3F_5E10_4f8e_8DB3_E6D374FA42E3"
measurementSystem="EAID_3328F5AF_7CAE_4149_A03E_EB78F6653396"
realizes="EAID_44DA0EBC_675A_476f_8EC1_E10C43728A21"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_19947789_47A4_4add_A517_DF904813B923"
name="DescriptionMeasurementAxis" precision="1"
realizes="EAID_137FD219_342E_47be_A785_7324D2954BAB"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_C1593D3F_5E10_4f8e_8DB3_E6D374FA42E3"
name="NameMeasurementAxis" precision="1"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D64E0352_022A_4eeb_B9FD_BD7E6BDAD940"
name="NameTextPrimaryAxis" description="The primary name axis." precision=""
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4AD8CC67_0181_4553_A1D4_0811D74BC14D"
name="UniqueIdentifierMeasurements"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_449BBCB0_25E2_4bb8_B6B7_08676DD46583"
name="StatusMeasures">
<element xmi:type="logical:Enumerated" xmi:id="EAID_9BB3F64F_2C33_422a_8B59_28D92F6410C6"
name="HealthStatusStateSet" description="Set of possible HealthStatus states" standardReference="">
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_28135A7A_37C1_416a_A295_D6EA78B7DDAF"
name="Bus_Error"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_A34427F2_D922_49f3_8909_323CA5FA6FA7"
name="Go"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_184A694E_8080_458a_8F5E_56367E965403"
name="Mem_Error"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_4D807032_2282_4f20_8E3D_E1AFDB3F1BD2"
name="NoGo"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_3989746A_802A_4357_80BE_5ED3CA4CF862"
name="HealthStatusDiscreteStates" description="The set of possible HealthStatus states"
unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
valueType="EAID_9BB3F64F_2C33_422a_8B59_28D92F6410C6"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_DD698959_0290_4a32_9D3A_F37F5DB63DC3"
name="HealthStatusMeasurement" description="Multistate health status measurement."
measurementAxis="EAID_CBC2B1EA_AB83_45fe_B831_3D2DE67241A1"
measurementSystem="EAID_0D6D5FAF_71A2_4452_B2F9_AB8F15C4D13F"
realizes="EAID_7BF4374F_EC27_40ba_B155_54CEA52345C2"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_CBC2B1EA_AB83_45fe_B831_3D2DE67241A1"
name="HealthStatusMeasurementAxis" valueTypeUnit="EAID_3989746A_802A_4357_80BE_5ED3CA4CF862"
precision="1" measurementSystemAxis="EAID_A60E666A_2E05_4c81_A7CB_BDE7B7C3A189"
realizes="EAID_7BF4374F_EC27_40ba_B155_54CEA52345C2"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_72328038_53DE_4bc6_A6E7_FDD926C9D0B7"
name="ValidityMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_CBC4F83A_D055_404a_948F_301D7024B339"
name="TwoStateValidityStates" description="Discrete states representing data validity indications"
valueType="EAID_98387E85_666B_4e9b_86E1_AA9E9975500E">
<constraint xmi:type="logical:EnumerationConstraint"
xmi:id="EAID_B4F76269_74CF_4aba_867F_9D69CCDCBEF4" name="ValidityConstraintTwoState"
description="Constraint limiting validity to Valid & Invalid (omits FunctionalTest &
NoComputedData)" allowedValue="EAID_B70F6907_5B02_4d61_83CD_C6F4385FDB1A
EAID_F0A086C3_4797_48f4_8DC4_DCD5EDB30DAF"/>
</element>
<element xmi:type="logical:Measurement" xmi:id="EAID_2843BB77_A385_4725_8143_5561E157F9E3"
name="ValidityMeasurementFourState" description="Data validity measurement that can have the four
states common to ARINC 429, 664P7, & 653P2 (Valid, Invalid, Functional test, & No Computed
Data)" measurementAxis="EAID_DF346A52_E72B_456d_ABA1_E36EF3060986"
realizes="EAID_629FBDD0_AEAD_41f0_9C6F_603D7CF9D269"/>

<element xmi:type="logical:Measurement" xmi:id="EAID_2AD3F89F_4D7A_4957_9EF7_A5216171A41B"
name="ValidityMeasurementTwoState" description="Data validity measurement that can have states of
Valid or Invalid, which is a subset of the four states common to ARINC 429, 664P7, & 653P2
(Valid, Invalid, Functional test, & No Computed Data)"
measurementAxis="EAID_3E9B93FF_2CBB_4b5e_82A8_5C3062BB3007"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_DF346A52_E72B_456d_ABA1_E36EF3060986"
name="ValidityMeasurementAxisFourState" valueTypeUnit="EAID_AB8E23AF_FCDC_459a_8BD3_D2C50A554BAF"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_3E9B93FF_2CBB_4b5e_82A8_5C3062BB3007"
name="ValidityMeasurementAxisTwoState" valueTypeUnit="EAID_CBC4F83A_D055_404a_948F_301D7024B339"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_488C14A6_E447_4141_8FD3_EAFCF9EDC4B1"
name="ValidityMeasurementSystem">
<element xmi:type="logical:Enumerated" xmi:id="EAID_98387E85_666B_4e9b_86E1_AA9E9975500E"
name="ValidityEnumeration" description="Enumeration with the four states common to ARINC 429,
664P7, & 653P2 (Valid, Invalid, Functional test, & No Computed Data)"
standardReference="">
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_0A52C53D_5802_41be_AB5B_89FC41784B18"
name="FunctionalTest"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_B70F6907_5B02_4d61_83CD_C6F4385FDB1A"
name="Invalid"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_490ECFE1_BB4C_4f31_9420_488A44BC6E41"
name="NoComputedData"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_F0A086C3_4797_48f4_8DC4_DCD5EDB30DAF"
name="Valid"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_AB8E23AF_FCDC_459a_8BD3_D2C50A554BAF"
name="AllValidityStates" description="Discrete states representing data validity indications"
valueType="EAID_98387E85_666B_4e9b_86E1_AA9E9975500E"/>
</ldm>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E5D26C4F_5745_4521_962D_2B4732FD5A0F"
name="AmountOfConcentrationMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_92EDA331_F512_45ab_83C3_17934647991B"
name="ChemicalConcentrationMeasurement" description="Measurement used to describe observable
properties of a chemical concentration." measurementAxis="EAID_C243BE2B_1EC9_4458_B02B_A4101462D1A5"
measurementSystem="EAID_4EEF0F23_1874_450c_BB7D_52DDBE50A712"
realizes="EAID_0016984E_BB39_4f54_95F7_41C62B101EBF"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_C243BE2B_1EC9_4458_B02B_A4101462D1A5"
name="ChemicalConcentrationMeasurementAxis" precision="1.0"
measurementSystemAxis="EAID_46FC50D2_7494_46f3_8494_DDAA55E45A2F"
realizes="EAID_0016984E_BB39_4f54_95F7_41C62B101EBF"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2EEC258C_54F0_4838_BF13_E922001DFEC9"
name="AmountOfConcentrationLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_E6D16447_F932_4bae_85F5_749590338288"
name="OneMolePerCubicMeterConcentrationLandmark" description="Represents an amount of 1 Mole per
cubic meter concentration of a substance"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_BA35625A_C590_411f_83AA_23C717E26A46"
name="ZeroConcentrationLandmark" description="Represents a chemical concentration of zero (i.e., no
amount of substance)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_48A8A209_6711_4a00_BED7_33DEE66B75FA"
name="AmountOfConcentrationMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_76E379BA_96C9_4f5d_A0F4_BCF5D4D5B9D3"
name="RealMolesPerCubicMeter" description="Moles per cubic meter in a real numerical
representation." unit="EAID_0B528C0C_B50B_4152_89FE_09BA977E13FE"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_4EEF0F23_1874_450c_BB7D_52DDBE50A712"
name="AmountOfConcentrationMeasurementSystem" description="System for measuring the amount of
concentration." measurementSystemAxis="EAID_46FC50D2_7494_46f3_8494_DDAA55E45A2F"
coordinateSystem="EAID_D73E1979_E607_48ce_A01F_2EAD5226614D" externalStandardReference="N/A"
orientation="Values increase as concentration increases">
xmi:id="EAID_10C3231C_6547_464f_A0F2_D6750CB4E51B"
name="OneMolePerCubicMeterConcentrationReferencePoint" description="Represents a unit amount of
chemical concentration (i.e., 1 mole/cubic meter."
landmark="EAID_E6D16447_F932_4bae_85F5_749590338288">
xmi:id="EAID_D43002FD_821D_4679_9A53_3B58FA9E7017"
axis="EAID_46FC50D2_7494_46f3_8494_DDAA55E45A2F" value="1.0"
valueTypeUnit="EAID_76E379BA_96C9_4f5d_A0F4_BCF5D4D5B9D3"/>
</referencePoint>
xmi:id="EAID_E5210479_294C_4137_A1CB_8F34A558D305" name="ZeroConcentrationReferencePoint"
description="Origin point for chemical concentration"
landmark="EAID_BA35625A_C590_411f_83AA_23C717E26A46">
xmi:id="EAID_CBBC03AF_8E5C_49af_A5DA_D64E2F5EFD20"
axis="EAID_46FC50D2_7494_46f3_8494_DDAA55E45A2F" value="0"
valueTypeUnit="EAID_76E379BA_96C9_4f5d_A0F4_BCF5D4D5B9D3"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_46FC50D2_7494_46f3_8494_DDAA55E45A2F"
name="AmountOfConcentrationMeasurementSystemAxis" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_76E379BA_96C9_4f5d_A0F4_BCF5D4D5B9D3"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C39FE4A0_A543_485f_9E48_280DB21A5EBC"
name="AmountOfSubstanceMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_BAB39D5C_4C60_4915_B31B_4F1E398424CD"
name="AmountOfSubstanceMeasurement" description="A measure of the number of entities (atoms,
molecules) present in a substance." measurementAxis="EAID_50838858_BB3A_4378_849A_0A29801BEB06"
measurementSystem="EAID_DC62CAA1_21DA_4849_8464_F08A23263D53"
realizes="EAID_280D1606_DD95_455c_B535_04810D45E721"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_50838858_BB3A_4378_849A_0A29801BEB06"
name="AmountOfSubstanceMeasurementAxis" description="Value increases as amount of substance
increases." precision="0.01" measurementSystemAxis="EAID_EA62EF67_9A36_4f82_BCF9_74E7F11310BB"
realizes="EAID_280D1606_DD95_455c_B535_04810D45E721"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1A43B456_A5AC_4744_8F9F_E72B5B739C01"
name="AmountOfSubstanceLandmarks" description="Collection of landmark elements applicable to Amount
Of Substance measurements.">
<element xmi:type="logical:Landmark" xmi:id="EAID_E586CBA3_83E6_448e_86FC_785FB8EA3435"
name="OneMoleAmountOfSubstanceLandmark" description="The mole represents an amount of substance in
the unit of Avogadro's constant (6.022x10^23) of atoms or molecules."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_396D9821_327B_4ed3_ABD0_A4ABACE8B529"
name="ZeroAmountOfSubstanceLandmark" description="The natural units of substances are molecules,
which are groups of atoms bonded together, this represents no molecules for a referenced
substance."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B43B92D6_DE84_4481_9483_B92CC02C264C"
name="AmountOfSubstanceMeasurementSystem" description="Collection of elements applicable to Amount Of
Substance measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_B50F1085_EE30_4408_9028_ECD2D1151D8A"
name="RealMoles" description="Amount of Substance described in the real numerical value of Moles."
unit="EAID_81285D76_2D91_4edd_B41D_009A1301FB63"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_DC62CAA1_21DA_4849_8464_F08A23263D53"
name="AmountOfSubstanceMeasurementSystem" description="The measurement system for amount of
substance is a quantity proportional to the number of entities N in a sample. The proportionality
constant is the same for all substances and is the reciprocal of the Avogadro constant."
measurementSystemAxis="EAID_EA62EF67_9A36_4f82_BCF9_74E7F11310BB"
orientation="Right-Handed">
xmi:id="EAID_7B50FCD5_19F1_4317_B1F1_85C69EC70BD6" name="OneMoleAmountOfSubstanceReferencePoint"
description="The mole represents an amount of substance in the unit of Avogadro's constant
(6.022x10^23) of atoms or molecules." landmark="EAID_E586CBA3_83E6_448e_86FC_785FB8EA3435">
xmi:id="EAID_4FEC69AA_F25D_40e4_95E4_BD3CCE7F0723"

axis="EAID_EA62EF67_9A36_4f82_BCF9_74E7F11310BB" value="1"
valueTypeUnit="EAID_B50F1085_EE30_4408_9028_ECD2D1151D8A"/>
</referencePoint>
xmi:id="EAID_96FB2447_6EF4_4b14_BEA8_563C1FD96A85" name="ZeroAmountOfSubstanceReferencePoint"
description="Represents the absence, lack of or zero amount of substance."
landmark="EAID_396D9821_327B_4ed3_ABD0_A4ABACE8B529">
xmi:id="EAID_AE87CB5B_D6DC_4003_891B_192B059DBD95"
axis="EAID_EA62EF67_9A36_4f82_BCF9_74E7F11310BB" value="0"
valueTypeUnit="EAID_B50F1085_EE30_4408_9028_ECD2D1151D8A"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_EA62EF67_9A36_4f82_BCF9_74E7F11310BB"
name="AmountOfSubstanceMeasurementSystemAxis" description="The measurement system axis to describe
the basis of amount of substance measurement." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_B50F1085_EE30_4408_9028_ECD2D1151D8A"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6C48A902_376D_42c4_8C6C_1125EDE3A04A"
name="AngleMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_04F52B3A_CD05_4773_B93D_B45595296870"
name="CrabAngle"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B6C0EFFA_C543_42be_A06A_FF5DBCC47CC4"
name="SharedAngularValueTypeUnits">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF"
name="RealDegrees" description="Degrees as a real numerical representation."
unit="EAID_6BE551B4_AC4C_467d_8264_95EB34EF81FE"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_FE60D41B_86AF_4f9e_B507_96A5730B1E52"
name="RealRadians" description="Radian rotations as a real numerical representation."
unit="EAID_DDC5A152_31FF_4e32_815A_3A1EE216C85A"
valueType="EAID_7CB1E0A3_7D27_45fa_BF9E_22EB15886D68">
<constraint xmi:type="logical:RealRangeConstraint"
xmi:id="EAID_23D6435C_5A52_4e2d_8114_67CB000A5D07" name="RotationRange" upperBound="3.14159"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2AD4FB4A_A65E_4472_BB42_776266E16FE8"
name="CenterOfGravity" description="Angle measurements based on the Center of Gravity Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9045FC94_4B15_4749_8BD1_F614009C4435"
name="LocalHorizontal" description="Angle measurements based on the Local Horizontal Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_DF1556E6_BCD8_48c6_BF80_FE2DC143C1CD"
name="LocalMagneticNorth" description="Angle measurements based on the Local Magnetic North Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_47C74EF3_1379_4dd4_9F3F_097501DF2E4F"
name="BodyAngle" description="Angle measurements based on the Local Vehicle Reference Frame.">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D5D8AF8D_9169_4cf0_A80F_8F0F07BD0AD6"
name="BodyAngleMeasurementDegrees">
<element xmi:type="logical:Measurement" xmi:id="EAID_37710E35_3DC5_4489_B0D0_92E98E890F06"
name="PitchMeasurementDegrees" description="Specifies the rotation about the latitudinal axis
(pitch) measured as an angle with respect to the vertical axis as viewed from the origin of the
local vehicle frame of reference." measurementAxis="EAID_B1CF8E91_53B6_4940_A3C5_98F8828300D4"
measurementSystem="EAID_5CDB3F7E_0762_43c5_ABBD_F6F8B4685244"
realizes="EAID_5977632F_0313_4d51_82A4_E716D94C7D7D"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_EFF46CEF_7F12_424c_B5CF_6DF0F0D67A09"
name="RollMeasurementDegrees" description="Specifies the rotation about the longitudinal axis
(roll) measure as a angle with respect to the lateral axis as viewed from the origin of the
Local Vehicle Frame of Reference." measurementAxis="EAID_9F6F8C29_7A0A_414c_A920_246C93235289"
measurementSystem="EAID_5044E59D_C305_465e_944E_4DA6187EF0DC"
<element xmi:type="logical:Measurement" xmi:id="EAID_644D6734_5BB4_461b_A37F_11DB3385BACA"
name="YawMeasurementDegrees" description="Specifies the rotation about the vertical axis (yaw)
measure as a angle with respect to the longitudinal axis as viewed from the origin of the Local
Vehicle Frame of Reference." measurementAxis="EAID_BFC17479_9D79_4762_BCDB_CEB6B869A8FB"
measurementSystem="EAID_9F30D0CA_14E4_4d03_9B4B_6E859FE51594"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_B1CF8E91_53B6_4940_A3C5_98F8828300D4"
name="PitchMeasurementDegreesAxis" description="Pitch Axis (Lateral Axis) passes through the
plane from wingtip to wingtip. Pitch changes the vertical direction the aircraft’s nose is
pointing." valueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF" precision="0.0001"
measurementSystemAxis="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997"
realizes="EAID_5977632F_0313_4d51_82A4_E716D94C7D7D">
xmi:id="EAID_83FE7B24_DB9C_4220_A419_4F326C52A5F7" constraintText="-180 <= value <
180"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9F6F8C29_7A0A_414c_A920_246C93235289"
name="RollMeasurementDegreesAxis" description="Roll Axis (Longitudinal Axis) passes through the
plane from nose to tail. Roll changes the orientation of the aircraft’s wings with respect to
the downward force of gravity." valueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF"
precision="0.0001" measurementSystemAxis="EAID_772DB699_434A_45e4_B6D8_A0E020712C67"
xmi:id="EAID_FA20FFE7_2899_4717_B74F_4F0546D64D61" constraintText="-180 <= value <
180"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_BFC17479_9D79_4762_BCDB_CEB6B869A8FB"
name="YawMeasurementDegreesAxis" description="Yaw Axis (Normal Axis) is the vertical axis
through an aircraft, rocket or similar body about which the body yaws."
valueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF" precision="0.0001"
measurementSystemAxis="EAID_C0539EFA_68AA_4243_81E3_F2052C1B496A"
xmi:id="EAID_B43C1E49_38A4_4f74_B438_C8F42A70316F" constraintText="-180 <= value <
180"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E85CF7BF_F349_4e79_A032_1C5B9874F3F5"
name="BodyAngleMeasurement">
<element xmi:type="logical:Measurement" xmi:id="EAID_F34BA7FF_1BEF_41e1_B694_812BE1BFCD49"
name="PitchMeasurement" description="Specifies the rotation about the latitudinal axis (pitch)
measured as an angle with respect to the vertical axis as viewed from the origin of the local
vehicle frame of reference." measurementAxis="EAID_A322E2DF_714C_45ae_AF5C_9D42179B6E83"
measurementSystem="EAID_5CDB3F7E_0762_43c5_ABBD_F6F8B4685244"
<element xmi:type="logical:Measurement" xmi:id="EAID_99BA0E0C_1417_4ff9_9B37_E18BD579FBF9"
name="RollMeasurement" description="Specifies the rotation about the longitudinal axis (roll)
measure as a angle with respect to the latitudinal axis as viewed from the origin of the Local
Vehicle Frame of Reference." measurementAxis="EAID_D5479935_C658_4188_AD63_965007CA6583"
measurementSystem="EAID_5044E59D_C305_465e_944E_4DA6187EF0DC"
<element xmi:type="logical:Measurement" xmi:id="EAID_94E1CAC3_2D40_40fd_9A11_3A8F53B0E484"
name="YawMeasurement" description="Specifies the rotation about the vertical axis (yaw) measure
as a angle with respect to the longitudinal axis as viewed from the origin of the Local Vehicle
Frame of Reference." measurementAxis="EAID_371B3270_F224_4dbc_B1E1_9482D3E91066"
measurementSystem="EAID_9F30D0CA_14E4_4d03_9B4B_6E859FE51594"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_A322E2DF_714C_45ae_AF5C_9D42179B6E83"
name="PitchMeasurementAxis" description="Pitch Axis (Lateral Axis) passes through the plane from
wingtip to wingtip. Pitch changes the vertical direction the aircraft’s nose is pointing."
precision="0.000001" measurementSystemAxis="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997"
xmi:id="EAID_FF4C0E70_6155_4dae_8A6E_3557D56AC874" constraintText="-Pi <= value < Pi"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D5479935_C658_4188_AD63_965007CA6583"
name="RollMeasurementAxis" description="Roll Axis (Longitudinal Axis) passes through the plane
from nose to tail. Roll changes the orientation of the aircraft’s wings with respect to the
downward force of gravity." precision="0.000001"
measurementSystemAxis="EAID_772DB699_434A_45e4_B6D8_A0E020712C67"
xmi:id="EAID_9F201858_916A_44b1_B1DA_8D8C3700A2E7" constraintText="-Pi <= value < Pi"/>
</element>

<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_371B3270_F224_4dbc_B1E1_9482D3E91066"
name="YawMeasurementAxis" description="Yaw Axis (Normal Axis) is the vertical axis through an
aircraft, rocket or similar body about which the body yaws." precision="0.000001"
xmi:id="EAID_724651ED_8E31_4fb3_9D5E_B74AB317EC4B" constraintText="-Pi <= value < Pi"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_50A2650B_114C_4eed_A1E4_9BA9193E23CC"
name="BodyAngleMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_5CDB3F7E_0762_43c5_ABBD_F6F8B4685244"
name="BodyLateralAngleMeasurementSystem" description="Measurement system that provides angle
measurement with respect to the local vehicle lateral axis"
measurementSystemAxis="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997"
xmi:id="EAID_5824A4D4_3275_47bb_BC09_195A99F20E8D" name="PiOver4RadianPitchUpReferencePoint"
description="Pi/4 radian rotation along the lateral axis (a pitch up)"
landmark="EAID_46C2DBA8_097E_4920_BA96_7CC8F27215AC">
xmi:id="EAID_4DA3CB8F_B0CD_415d_A4B0_A763CEE911E7"
axis="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997" value="Pi/4"
valueTypeUnit="EAID_FE60D41B_86AF_4f9e_B507_96A5730B1E52"/>
</referencePoint>
xmi:id="EAID_402CEA8A_0A55_40a8_85B9_FFD8375203B9" name="LateralEquilibrium" description="Zero
rotation about the latitudinal axis" landmark="EAID_7E2AA6B0_4E32_428e_B420_674937EB807B">
xmi:id="EAID_975E1A8A_61D6_4080_8209_27B035F9ED95"
axis="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997" value="0"
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_5044E59D_C305_465e_944E_4DA6187EF0DC"
name="BodyLongitudinalMeasurementSystem" description="Measurement system that provides angle
measurement with respect to the local vehicle longitudinal axis"
measurementSystemAxis="EAID_772DB699_434A_45e4_B6D8_A0E020712C67"
orientation="Right Handed">
xmi:id="EAID_74D6CF40_D216_43d7_9AE1_F2D9BB50063A" name="LongitudinalEquilibrium"
description="Zero rotation about the longitudinal, lateral, and vertical axes."
landmark="EAID_7E2AA6B0_4E32_428e_B420_674937EB807B">
xmi:id="EAID_28496158_2831_44c5_975B_7F80612DBC6B"
axis="EAID_772DB699_434A_45e4_B6D8_A0E020712C67" value="0"
</referencePoint>
xmi:id="EAID_8B9FCA8B_0D79_481b_A091_F9313EFEF4AD" name="PiOver2RadianRollLeftReferencePoint"
description="-90 degree rotation along the longitudinal axis (a roll left)"
landmark="EAID_EB421BF8_9BA2_4b2c_9F12_89947506FFAC">
xmi:id="EAID_DA448C7A_2D62_4276_9490_AFD7BB7D8A3E"
axis="EAID_772DB699_434A_45e4_B6D8_A0E020712C67" value="-Pi/2"
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_9F30D0CA_14E4_4d03_9B4B_6E859FE51594"
name="BodyVerticalAngleMeasurementSystem" description="Measurement system that provides angle
measurement with respect to the local vehicle vertical axis"
orientation="Right Handed">
xmi:id="EAID_6E09D18A_D50D_4b76_9537_EB05FFD8256E" name="VerticalEquilibrium"
description="Zero rotation about the Vertical axis"
landmark="EAID_7E2AA6B0_4E32_428e_B420_674937EB807B">
xmi:id="EAID_9A3CAADF_5147_4276_86E1_94F9D00E26C2"
axis="EAID_C0539EFA_68AA_4243_81E3_F2052C1B496A" value="0"
</referencePoint>
xmi:id="EAID_37757EE5_7A9F_4d5c_840C_9E456D90643D" name="PiOver6RadianYawLeftReferencePoint"
description="-Pi/6 radian rotation along the vertical axis (a yaw left)"
landmark="EAID_7BA5AA9E_8487_4169_8591_E8A62103DE76">
xmi:id="EAID_8DFE9652_ACCA_4cf7_A11F_9F0194AE2751"
axis="EAID_C0539EFA_68AA_4243_81E3_F2052C1B496A" value="-Pi/6"
</referencePoint>
</element>
xmi:id="EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A" name="BodyAngleOfRotationAboutLateralAxis"
description="An axis running from the pilot's left to right in piloted aircraft, and parallel to
the wings of a fixed winged aircraft. Rotation about this axis is called pitch."
axis="EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
defaultValueTypeUnit="EAID_FE60D41B_86AF_4f9e_B507_96A5730B1E52"/>
xmi:id="EAID_CACB8663_7644_489e_BE01_2F05B1EE3997" name="BodyAngleOfRotationAboutLateralAxis1D"
description="An axis running from the pilot's left to right in piloted aircraft, and parallel to
the wings of a fixed winged aircraft. Rotation about this axis is called pitch."
xmi:id="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84"
name="BodyAngleOfRotationAboutLongitudinalAxis" description="An axis drawn through the body of
the vehicle from tail to nose in the direction of flight, or the direction the pilot faces.
Rotation about this axis is called bank or roll."
xmi:id="EAID_772DB699_434A_45e4_B6D8_A0E020712C67"
name="BodyAngleOfRotationAboutLongitudinalAxis1D" description="An axis drawn through the body of
the vehicle from tail to nose in the direction of flight, or the direction the pilot faces.
Rotation about this axis is called bank or roll."
xmi:id="EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5" name="BodyAngleOfRotationAboutVerticalAxis"
description="Also known as the Normal axis is drawn from top to bottom, and perpendicular to the
other two axes. Rotation about this axis is called yaw."
axis="EAID_C74601C9_0E7A_483b_AD4C_28D64BE141E3"
xmi:id="EAID_C0539EFA_68AA_4243_81E3_F2052C1B496A"
name="BodyAngleOfRotationAboutVerticallAxis1D" description="Also known as the Normal axis is
drawn from top to bottom, and perpendicular to the other two axes. Rotation about this axis is
called yaw." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B08FDE57_5C49_41e7_9D11_EF49F447F2BC"
name="BodyAngleLandmark">
<element xmi:type="logical:Landmark" xmi:id="EAID_7E2AA6B0_4E32_428e_B420_674937EB807B"
name="BodyAngleAttitudeEquilibrium" description="The point at which the local vehicle body frame
has no rotation in any of the three axes that originate at the vehicle center of gravity
(longitudinal, lateral, & vertical)."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_EB421BF8_9BA2_4b2c_9F12_89947506FFAC"
name="BodyAnglePiOver2RadianLeftRoll" description="The orientation of the local vehicle body
frame with respect to the vertical axis (or lateral axis) after a -Pi/2 radian rotation along
the longitudinal axis (a roll to left)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_46C2DBA8_097E_4920_BA96_7CC8F27215AC"
name="BodyAnglePiOver4RadianPitchUp" description="The orientation of the local vehicle body

frame with respect to the longitudinal (or vertical axis) after a Pi/4 radian rotation along the
lateral axis (a pitch up)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_7BA5AA9E_8487_4169_8591_E8A62103DE76"
name="BodyAnglePiOver6RadianYawLeft" description="The orientation of the local vehicle body
frame with respect to the longitudinal axis (or lateral axis) after a -Pi/6 radian rotation
along the vertical axis (a yaw left)"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_182EEBF4_489D_4818_9783_C3CC0B714ED2"
name="NorthSouthMeridians" description="Angle measurements based on the North South Meridians
Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_98B2A3BD_3829_42d4_818A_71BE46E26E0B"
name="TrueNorth" description="Angle measurements based on the True North Reference Frame."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2E96FCE3_39D7_46b6_8A16_3A62E88F6FE7"
name="AreaMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_942D7E12_8F27_4ebf_8FDE_6CC2F8ECC087"
name="AreaMeasurement" description="Measurement used to describe observable properties of area."
measurementAxis="EAID_2A8986A5_EB0D_4fba_BC35_61EE8CAF5AC0"
measurementSystem="EAID_ECDCA729_FCAC_4488_912E_705D7772C930"
realizes="EAID_4B94E0C3_63C2_4166_9A21_564E6B39FEE1"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_2A8986A5_EB0D_4fba_BC35_61EE8CAF5AC0"
name="AreaMeasurementAxis" description="Mearurement axis for describing observable properties of
area." precision="0.001" measurementSystemAxis="EAID_94BB6EBD_0C38_4569_935D_E3B57B432375"
realizes="EAID_4B94E0C3_63C2_4166_9A21_564E6B39FEE1"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_68896E49_8D19_4c6c_BD0D_56F4799C0BDB"
name="AreaLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_E9E460F3_91B4_4bc3_887F_68AC7C7D5133"
name="UnitAreaLandmark" description="Landmark representing an area of 1 square meter"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_C47A25DB_FE40_4b10_A43F_B646B6B2FDE2"
name="ZeroAreaLandmark" description="Landmark representing zero area"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A657F579_91F9_4f14_8D18_C4BE6225ECA3"
name="AreaMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D936F85E_17F7_417a_9240_849DECFAA5FE"
name="RealSquareMeters" unit="EAID_C4A8FCC1_585A_4d82_B7BF_606489503F25"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_ECDCA729_FCAC_4488_912E_705D7772C930"
name="AreaMeasurementSystem" description="Measurement system for values of area."
measurementSystemAxis="EAID_94BB6EBD_0C38_4569_935D_E3B57B432375"
orientation="Values increase as area increases.">
xmi:id="EAID_D1E57CDE_A82D_4668_B0DE_E92152F46E28" name="ZeroAreaReferencePoint"
description="Reference point representing an area of zero."
landmark="EAID_C47A25DB_FE40_4b10_A43F_B646B6B2FDE2">
xmi:id="EAID_65DCF42F_4765_48de_87C5_570604881F96"
axis="EAID_94BB6EBD_0C38_4569_935D_E3B57B432375" value="0.0"
valueTypeUnit="EAID_D936F85E_17F7_417a_9240_849DECFAA5FE"/>
</referencePoint>
xmi:id="EAID_FA4C5A80_2A2B_4c98_A2C0_E5C7656F7946" name="UnitAreaReferencePoint"
description="Reference point defining a value of one suare meter of area."
landmark="EAID_E9E460F3_91B4_4bc3_887F_68AC7C7D5133">
xmi:id="EAID_1682646B_31E8_466f_92B6_17F54A3F4EEB"
axis="EAID_94BB6EBD_0C38_4569_935D_E3B57B432375" value="1.0"
valueTypeUnit="EAID_D936F85E_17F7_417a_9240_849DECFAA5FE"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_94BB6EBD_0C38_4569_935D_E3B57B432375"
name="AreaMeaurementSystemAxis" description="Primary axis for the measurement of areas."
defaultValueTypeUnit="EAID_D936F85E_17F7_417a_9240_849DECFAA5FE"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8B7A7415_09ED_466a_95DA_0D8D6CC83444"
name="CountingMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_3A0FDB20_5D89_4e8c_A4B3_FC7719F166BA"
name="ResolutionMeasurement" measurementAxis="EAID_99FB9D82_EA30_4b1e_AB91_811010E0A1E5
EAID_76F671A6_9D73_4c82_A243_5BF51576FBA0"
measurementSystem="EAID_4FE8838C_BDFB_4d71_BB05_B6665A4465B9"
realizes="EAID_D6D476D1_7FDC_4375_B79B_785E5E9EBA3D"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_99FB9D82_EA30_4b1e_AB91_811010E0A1E5"
name="HorizontalResolutionMeasurementAxis" precision="1"
measurementSystemAxis="EAID_68D640BD_4D6B_4d01_BE52_5CDF213BC3EB"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_76F671A6_9D73_4c82_A243_5BF51576FBA0"
name="VerticalResolutionMeasurementAxis" precision="1"
measurementSystemAxis="EAID_ADF21458_AA79_4492_AB79_71DE58A8D6DE"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_3307EE35_37F1_4f0a_AB2C_3934FFD68366"
name="ResolutionLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_58DED9B5_477F_4054_AA12_9877FDC7782B"
name="OriginLandmark" description="Screen resolution origin expressed as (0,0)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_57C5E3B5_6C67_4d1b_89B9_6EFD08E28F1B"
name="UnitPixelLandmark" description="A one unit pixel defined landmark."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B0F4D136_C746_421e_AC20_CCD2912DA500"
name="ResolutionMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_888A1206_11E0_434b_A43D_1CC0091F92BB"
name="NaturalPixelCount" description="Pixel count as a natural numerical representation."
valueType="EAID_7DE12CF5_1B85_482b_9830_783D356833E9"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_4FE8838C_BDFB_4d71_BB05_B6665A4465B9"
name="ResolutionMeasurementSystem" description="Measurement system for screen resolution
measurements." measurementSystemAxis="EAID_68D640BD_4D6B_4d01_BE52_5CDF213BC3EB
EAID_ADF21458_AA79_4492_AB79_71DE58A8D6DE"
coordinateSystem="EAID_91380EB8_66EF_4d12_AC1D_84FF7F719080" externalStandardReference=""
orientation="Value increases as Pixel Count increase">
xmi:id="EAID_F4FA9B7F_4286_4f34_9D52_B8B4810DE16C" name="OriginResolutionReferencePoint"
description="screen (x,y) origin" landmark="EAID_58DED9B5_477F_4054_AA12_9877FDC7782B">
xmi:id="EAID_F83C22E7_CA3F_4405_A97B_C8388252225D"
axis="EAID_68D640BD_4D6B_4d01_BE52_5CDF213BC3EB" value="0"
valueTypeUnit="EAID_888A1206_11E0_434b_A43D_1CC0091F92BB"/>
xmi:id="EAID_16B296C2_5A87_4c1f_8E7E_9ADE3D4087F9"
axis="EAID_ADF21458_AA79_4492_AB79_71DE58A8D6DE" value="0"
</referencePoint>
xmi:id="EAID_CFDDFAC6_32C7_4a89_AFDA_019DD2B5B204" name="UnitHorizontalResolutionReferencePoint"
description="Unit resolution in the horizontal direction (x,0)"
landmark="EAID_57C5E3B5_6C67_4d1b_89B9_6EFD08E28F1B">
xmi:id="EAID_6106A8C5_C4B4_4051_A516_394C4DE0A589"
xmi:id="EAID_319F870C_336A_4ca9_97AE_D7458E9EB116"
xmi:id="EAID_616DD011_CF4C_483d_B9CB_0FE99097B0CE"
</referencePoint>
xmi:id="EAID_67B2D930_02EF_4ab1_B71F_2CC1F29D9024" name="UnitVerticalResolutionReferencePoint"
description="Unit resolution in the vertical direction (0,y)"
landmark="EAID_57C5E3B5_6C67_4d1b_89B9_6EFD08E28F1B">

xmi:id="EAID_34A91D3A_36CE_45c2_BCC5_D7BDF41CD909"
xmi:id="EAID_214991A8_A94D_403a_BC8B_FBBB22535241"
xmi:id="EAID_2CEFF5D9_0C5A_4970_8E17_CE3D64BA38F1"
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_68D640BD_4D6B_4d01_BE52_5CDF213BC3EB"
name="HorizontalResolutionMeasurementSystemAxis" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_888A1206_11E0_434b_A43D_1CC0091F92BB"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_ADF21458_AA79_4492_AB79_71DE58A8D6DE"
name="VerticalResolutionMeasurementSystemAxis" axis="EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
defaultValueTypeUnit="EAID_888A1206_11E0_434b_A43D_1CC0091F92BB"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D60F2512_A1F0_4e57_A1E8_6AE444CF1B02" name="Count"
description="Logical model for the number of occurrences of a repeating event per unit time">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_87ABB560_138F_4984_908E_3D7C00EFFCC5"
name="IntegerCount" description="Number of occurrences as an integer"
valueType="EAID_372D8BFC_47B1_4385_AD77_6703541E7FAC"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_23090211_4137_49e3_BE03_478F7B076C5A"
name="OneCountLandmark" description="One occurrence of a countable event"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_96044A9F_18B8_4b8f_B293_2E6A8EE88CED"
name="ZeroCountLandmark" description="No occurrences of a countable event"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_C47A17E6_C71A_476e_BE60_180AF8419F3F"
name="CountMeasurementSystem" description="Measurement system for event occurrences measured in
Counts." measurementSystemAxis="EAID_0BC3E999_77C6_4c63_AF7D_ABF70A593686"
orientation="Value increases as event occurrences increases.">
xmi:id="EAID_1FC9AD43_49BA_4ee5_BBEB_D0F6F8AC21F5" name="ZeroCountReferencePoint"
description="No occurrences of an event" landmark="EAID_96044A9F_18B8_4b8f_B293_2E6A8EE88CED">
xmi:id="EAID_14274BEE_EF95_48af_9095_33186A88F6D7"
axis="EAID_0BC3E999_77C6_4c63_AF7D_ABF70A593686" value="0"
valueTypeUnit="EAID_87ABB560_138F_4984_908E_3D7C00EFFCC5"/>
</referencePoint>
xmi:id="EAID_2EDF9D15_B08E_4890_AB43_0D607A7CB33B" name="OneCountReferencePoint"
description="One counted event" landmark="EAID_23090211_4137_49e3_BE03_478F7B076C5A">
xmi:id="EAID_9CAB63B4_4535_44db_BD42_E9A4A8B29E5E"
axis="EAID_0BC3E999_77C6_4c63_AF7D_ABF70A593686" value="1"
valueTypeUnit="EAID_87ABB560_138F_4984_908E_3D7C00EFFCC5"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_0BC3E999_77C6_4c63_AF7D_ABF70A593686"
name="CountMeasurementSystemAxis" description="Measurement system axis for Counts measured in
counts with integers." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_87ABB560_138F_4984_908E_3D7C00EFFCC5"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_E627B572_0133_4045_AA2A_2244CB7F53F5"
name="CountMeasurement" description="Measurement of event occurrences measured in Counts with non-
negative Integers" measurementAxis="EAID_CE66B9CB_E529_468a_A4F4_4FC5690CE902"
measurementSystem="EAID_C47A17E6_C71A_476e_BE60_180AF8419F3F"
realizes="EAID_39CB7F84_FBC5_4861_BD11_FAC97574B2A2"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_CE66B9CB_E529_468a_A4F4_4FC5690CE902"
name="CountMeasurementAxis" precision="1"
measurementSystemAxis="EAID_0BC3E999_77C6_4c63_AF7D_ABF70A593686"
realizes="EAID_39CB7F84_FBC5_4861_BD11_FAC97574B2A2"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A6B2FEB4_F4FF_4b7b_973C_1CB5F0BB5FB6"
name="DensityMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_069A0A6A_83E0_408f_9A38_D2A5CFAC0962"
name="DensityMeasurement" description="Measurement used to describe observable properties of
density." measurementAxis="EAID_57E6F76F_CAE2_4230_AFC1_CBC9C319C84E"
measurementSystem="EAID_824295E2_26C0_4f6b_AC04_AAD0D5331862"
realizes="EAID_4D9CB92E_1010_4fd8_9520_0184188C4374"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_B983D025_1147_429e_A693_68357EA7B8D8"
name="RelativeHumidtyMeasurement" description="Measure of relative humidity."
measurementAxis="EAID_9D3B6233_550D_4b5e_95C2_E3A06AE6CA15"
measurementSystem="EAID_249E210D_69CB_4315_BCF4_0DD0B5EE9AF0"
realizes="EAID_29F6EF02_F3F2_4590_8A84_3F28FE25B16F"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_57E6F76F_CAE2_4230_AFC1_CBC9C319C84E"
name="DensityMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_EAFBC1AF_4737_43c5_842B_282D3FCEBF0D"
realizes="EAID_4D9CB92E_1010_4fd8_9520_0184188C4374"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9D3B6233_550D_4b5e_95C2_E3A06AE6CA15"
name="RelativeHumidtyMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_95FFC181_60A9_41cf_9486_008968CEDD17"
realizes="EAID_29F6EF02_F3F2_4590_8A84_3F28FE25B16F">
xmi:id="EAID_316ED692_652D_4082_AAB4_294CD0350A62" constraintText="Values are constrained to the
range of 0 to 100%."/>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_46AE3D14_1673_4d58_B36F_2EF1CB493C2B"
name="DensityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_9F7700F1_01DE_4525_A353_EFB98340E64A"
name="WaterDensityLandmark" description="Density of water at 4 degrees C and 1 Atmosphere
pressure"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_ED886DCA_4126_41d7_88CF_DEB43A2462C8"
name="ZeroDensityLandmark" description="Zero value of density (i.e., no mass in a volume)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_DAC1E95A_198D_4400_87B1_E8C99B2C9FC5"
name="DensityMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_1194AAE8_DD2D_44c0_BD43_58C01BD29FFF"
name="RealKilogramsPerCubicMeter" description="Real kilograms per cubic meter."
unit="EAID_BE2795B1_06AD_4261_B7E8_8A4F4D94FC84"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_824295E2_26C0_4f6b_AC04_AAD0D5331862"
name="DensityMeasurementSystem" description="Measurement system used in the measurement of density
(mass per unit volume)" measurementSystemAxis="EAID_EAFBC1AF_4737_43c5_842B_282D3FCEBF0D"
orientation="Values increase as density increases">
xmi:id="EAID_C4FE9A96_0B55_4772_A566_8C3B434AA18E" name="ZeroDensityReferencePoint"
description="Reference point corresponding to a density of zero (no mass in a defined volume)"
landmark="EAID_ED886DCA_4126_41d7_88CF_DEB43A2462C8">
xmi:id="EAID_4082573B_B06E_4a62_B5B4_E35307277C38"
axis="EAID_EAFBC1AF_4737_43c5_842B_282D3FCEBF0D" value="0.0"
valueTypeUnit="EAID_1194AAE8_DD2D_44c0_BD43_58C01BD29FFF"/>
</referencePoint>
xmi:id="EAID_B67544D5_0574_43c3_B6AC_02BD0A4D8F76" name="WaterDensityReferencePoint"
description="Reference point corresponding to the density of water at 4 degrees C and 1
atmosphere of pressure." landmark="EAID_9F7700F1_01DE_4525_A353_EFB98340E64A">
xmi:id="EAID_C035D78E_D6F3_47d9_BE86_AA03FD77F6F5"
axis="EAID_EAFBC1AF_4737_43c5_842B_282D3FCEBF0D" value="1000.0"
valueTypeUnit="EAID_1194AAE8_DD2D_44c0_BD43_58C01BD29FFF"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_EAFBC1AF_4737_43c5_842B_282D3FCEBF0D"
name="DensityMeasurementSystemAxis" description="Primary axis for measurements of density"
defaultValueTypeUnit="EAID_1194AAE8_DD2D_44c0_BD43_58C01BD29FFF"/>
</ldm>

<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9B83362B_5297_4186_8F22_C36667F71F25"
name="HumidityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_E9D530D6_1823_4e71_BB7D_1271C64B263C"
name="SaturatedRelativeHumidityLandmark" description="Represents 100% relative humidity."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_4AA2689D_30FC_46a2_9429_1B3741351F35"
name="ZeroRelativeHumidity" description="Represents zero relative humidity."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D4D37FFD_C368_4525_AD63_F8DAFBBE1B63"
name="HumidityMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_32D64A1E_4E12_41f2_802F_E09F36EC367A"
name="RealPercentage" description="Percentage represented as a real value."
unit="EAID_68A9F947_C54C_4c06_84C6_29E302284981"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_249E210D_69CB_4315_BCF4_0DD0B5EE9AF0"
name="RelativeHumidityMeasurementSystem" description="Measurement system for relative humidity
measurements." measurementSystemAxis="EAID_95FFC181_60A9_41cf_9486_008968CEDD17"
orientation="Values increase as relative humidity increases.">
xmi:id="EAID_491801C6_9ECC_40a9_985D_32EE6BEB4E77"
name="SaturatedRelativeHumidityReferencePoint" description="Saturated (100%) relative humidity."
landmark="EAID_E9D530D6_1823_4e71_BB7D_1271C64B263C">
xmi:id="EAID_36BD5AA2_1B93_4081_82F7_465510E4BAAF"
axis="EAID_95FFC181_60A9_41cf_9486_008968CEDD17" value="100.0"
valueTypeUnit="EAID_32D64A1E_4E12_41f2_802F_E09F36EC367A"/>
</referencePoint>
xmi:id="EAID_D81383B1_A3A6_42ca_BA77_7A31D3F3A932" name="ZeroRelativeHumidityReferencePoint"
description="Zero relative humidity." landmark="EAID_4AA2689D_30FC_46a2_9429_1B3741351F35">
xmi:id="EAID_9E81DE98_8EC9_46b3_91E8_2E3DABFE3A3C"
axis="EAID_95FFC181_60A9_41cf_9486_008968CEDD17" value="0.0"
valueTypeUnit="EAID_32D64A1E_4E12_41f2_802F_E09F36EC367A"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_95FFC181_60A9_41cf_9486_008968CEDD17"
name="RelativeHumidityMeasurementSystemAxis" description="Axis for relative humidity"
defaultValueTypeUnit="EAID_32D64A1E_4E12_41f2_802F_E09F36EC367A"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_849E8A14_5414_4e08_9CFB_A19CF061BBA6"
name="ElectricityMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_B1320CCC_42D6_40f1_ADFE_41BD8B26E069"
name="RealAmpHour" description="Electric charge described in real numerical value of Amp per hour ."
unit="EAID_611BFBF3_9651_4770_BEED_69B1E5BA509A"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2F0BAF61_326D_4c89_968F_9B4598739E75"
name="ElectricCapacitance" description="Root package for Electric capacitance measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_E96F42F8_30BD_443f_BB26_0E186EE6E4F1"
name="ElectricCapacitanceMeasurement" description="The measurement to describe a body's ability to
store an electrical charge." measurementAxis="EAID_DF3ED095_E9A6_4372_AF6B_1E95C547D029"
measurementSystem="EAID_5EB6B860_4679_41b4_AB31_F06F93C6F5E3"
realizes="EAID_FFF9F507_6448_48bd_B548_5B85F4057903"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_F20BBE62_4A3E_4237_B10B_62696C8034F7"
name="ElectricCapacitanceMeasurementMicroFarads" description="The measurement to describe a body's
ability to store an electrical charge." measurementAxis="EAID_37C9B33F_D967_4ee4_8DF4_29C3A93114CB"
measurementSystem="EAID_5EB6B860_4679_41b4_AB31_F06F93C6F5E3"
realizes="EAID_FFF9F507_6448_48bd_B548_5B85F4057903"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_DF3ED095_E9A6_4372_AF6B_1E95C547D029"
name="ElectricCapacitanceMeasurementAxis" precision=".0000001"
measurementSystemAxis="EAID_4F1DFAAF_75EF_460f_B55F_D3876B433EFA"
realizes="EAID_FFF9F507_6448_48bd_B548_5B85F4057903">
xmi:id="EAID_E9A0F554_2BFC_4e45_A7EF_BFECDE6796B4" constraintText="Always >= 0"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_37C9B33F_D967_4ee4_8DF4_29C3A93114CB"
name="ElectricCapacitanceMeasurementAxisMicroFarads" precision=".001"
realizes="EAID_FFF9F507_6448_48bd_B548_5B85F4057903">
xmi:id="EAID_6547DB5A_FA45_4e86_83E2_84DFAA7E3289" constraintText="Always >= 0"/>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_10CC9195_10BE_4103_9B78_7FF765EF835C"
name="ElectricCapacitanceMeasurementSystem" description="Collection of elements applicable to
Electric Capacitance measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_88944113_E0D8_475b_90B9_A0BF53FE5027"
name="RealFarad" description="Electric capacitance described in real numerical value Farad."
unit="EAID_2DEC664F_516A_499d_A29B_661CC1D8C7B2"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_5EB6B860_4679_41b4_AB31_F06F93C6F5E3"
name="ElectricCapacitanceMeasurementSystem" description="The measurement system to describe an
objects ability to store an electrical charge."
orientation="Values increase as capacitance increases.">
xmi:id="EAID_AEDA2D5B_F743_4e70_A597_17CBDA09232E" name="ZeroCapacitanceReferencePoint"
description="Representative of no measureable electrical capacitance."
landmark="EAID_425AD038_620E_4728_AAEA_06C1B85F4160">
xmi:id="EAID_84D9B296_E078_4453_AEE4_7BC3C0234C45"
axis="EAID_4F1DFAAF_75EF_460f_B55F_D3876B433EFA" value="0"
valueTypeUnit="EAID_88944113_E0D8_475b_90B9_A0BF53FE5027"/>
</referencePoint>
xmi:id="EAID_181F8DE7_E8CE_432c_860D_8F8331EB3C5A" name="OneFaradCapacitanceReferencePoint"
description="Representative of ability to store one farad unit of electrical charge."
landmark="EAID_79DB8969_ED34_45fa_B559_C6C84BCA72C0">
xmi:id="EAID_768FA36A_E0E1_434d_9747_F9A6E94AAD31"
axis="EAID_4F1DFAAF_75EF_460f_B55F_D3876B433EFA" value="1"
valueTypeUnit="EAID_88944113_E0D8_475b_90B9_A0BF53FE5027"/>
</referencePoint>
</element>
xmi:id="EAID_4F1DFAAF_75EF_460f_B55F_D3876B433EFA"
name="ElectricCapacitanceMeasurementSystemAxis" description="The measurement system axis to
describe the nature of the electric capacitance measurement."
defaultValueTypeUnit="EAID_88944113_E0D8_475b_90B9_A0BF53FE5027"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9AA6CDE5_4DDE_4e2a_8A65_B28A159A7A85"
name="ElectricCharge" description="Root package for Electric Charge measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_B48F7C3A_377D_4969_A199_C77B8B11BBCA"
name="ElectricChargeMeasurementAmpHour" description="The physical property of matter that causes it
to experience a force when close to other electrically charged matter; the charge is either
positive: having more protons than electrons or negative: having more electrons than protons."
measurementAxis="EAID_BE0B46F9_1387_40b3_86E4_3AFB6476CBFD"
measurementSystem="EAID_3B0BCA26_22AB_4c9e_9047_D9107BD68377"
realizes="EAID_0B869DF6_099A_4526_95F5_4BFC7393718E"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_2BA7BCEA_FA7F_48dc_BEEF_B83BA9D7F83C"
name="ElectricChargeMeasurement" description="The physical property of matter that causes it to
experience a force when close to other electrically charged matter; the charge is either positive:
having more protons than electrons or negative: having more electrons than protons."
measurementAxis="EAID_5BD43CDE_4522_40cf_8AE6_C65552E0BCF9"
measurementSystem="EAID_3B0BCA26_22AB_4c9e_9047_D9107BD68377"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_BE0B46F9_1387_40b3_86E4_3AFB6476CBFD"
name="ElectricChargeMeasurementAxisAmpHour"
valueTypeUnit="EAID_B1320CCC_42D6_40f1_ADFE_41BD8B26E069" precision="0.001"
measurementSystemAxis="EAID_8D1D2442_0110_4250_BA82_97688EC62F37"

<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_5BD43CDE_4522_40cf_8AE6_C65552E0BCF9"
name="ElectricChargeMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_8D1D2442_0110_4250_BA82_97688EC62F37"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_401CE94F_7F8C_48d9_ADA8_44A6B97B093D"
name="ElectricChargeMeasurementSystem" description="Collection of elements applicable to Electric
Charge measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_38E03039_78D2_40f5_AB1B_9AF607B5C0E1"
name="RealCoulomb" description="Electric charge described in the real numerical value of
Coulomb" unit="EAID_F0BEB8DA_1C6E_43a8_A030_C04F74B8E417"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_3B0BCA26_22AB_4c9e_9047_D9107BD68377"
name="ElectricChargeMeasurementSystem" description="The measurement system to describe the
physical property of matter that causes it to experience a force when close to other
electrically charged matter." measurementSystemAxis="EAID_8D1D2442_0110_4250_BA82_97688EC62F37"
orientation="Values increase as electric charge increases.">
xmi:id="EAID_5707B670_489F_489d_B3C5_C2BD1628A293" name="OneCoulombChargeReferencePoint"
description="Representative of positively charged characteristic as defined by having more
protons than electrons and measured as one coulomb of electric charge."
landmark="EAID_7C6FB1B9_F9F9_4b44_94F3_E6883ACC835F">
xmi:id="EAID_2359BFCB_6735_445d_BDDD_4C207F7778EB"
axis="EAID_8D1D2442_0110_4250_BA82_97688EC62F37" value="1"
valueTypeUnit="EAID_38E03039_78D2_40f5_AB1B_9AF607B5C0E1"/>
</referencePoint>
xmi:id="EAID_EA832F8A_C32F_44fd_9695_64EA503AD766" name="ZeroElectricChargeReferencePoint"
description="Representative of no measureable electric charge."
landmark="EAID_C4DAF340_8D6D_494b_A77D_B012BDCC2CB0">
xmi:id="EAID_2ACA012F_0D85_47a9_9AA8_BABAE5EEF839"
axis="EAID_8D1D2442_0110_4250_BA82_97688EC62F37" value="0"
valueTypeUnit="EAID_38E03039_78D2_40f5_AB1B_9AF607B5C0E1"/>
</referencePoint>
</element>
xmi:id="EAID_8D1D2442_0110_4250_BA82_97688EC62F37" name="ElectricChargeMeasurementSystemAxis"
description="The measurement system axis to describe the nature of the electrical charge
measurement." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_38E03039_78D2_40f5_AB1B_9AF607B5C0E1"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2609AE41_3C23_4ec1_85CC_9BFDD255D721"
name="ElectricChargeDensity" description="Root package for Electric Charge Density measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_371CC632_0DD9_41c2_8C37_8F47FA133E97"
name="ElectricChargeDensityLinearMeasurement" description="The measurement to describe the linear
charge density as the amount of electric charge per unit length,"
measurementAxis="EAID_CAD9C421_B858_4b9e_ACA9_76BD811632ED"
measurementSystem="EAID_61840EFB_6722_437e_8E66_BF5B091BA1BA"
realizes="EAID_CAE607F9_8F99_4a23_854E_8B8536720799"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_CAD9C421_B858_4b9e_ACA9_76BD811632ED"
name="ElectricChargeDensityLinearMeasurementAxis" precision=".001"
measurementSystemAxis="EAID_B383AED6_CE79_452a_83B5_3D3452624D24"
realizes="EAID_CAE607F9_8F99_4a23_854E_8B8536720799"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B49ADC07_54D4_48f1_B515_15C57852A118"
name="ElectricChargeDensityMeasurementSystem" description="Collection of elements applicable to
Electric Charge Density measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_FC0CC9EF_5264_46f8_97E5_BD9B4B98D732"
name="RealCoulombsPerMeter" description="Charge Density described in real numerical value in
Coulombs per Meter" unit="EAID_DED3DC3D_2228_4180_9A4F_CF994B64B6CF"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_61840EFB_6722_437e_8E66_BF5B091BA1BA"
name="ElectricChargeDensityLinearMeasurementSystem" description="Measurement system to describe
the electric charge density of per unit length."
measurementSystemAxis="EAID_B383AED6_CE79_452a_83B5_3D3452624D24"
orientation="Values increase as charge density increases.">
xmi:id="EAID_D9D49BE6_E438_4e43_8A62_2702AD15CF9D" name="ZeroChargeDensity"
description="Representative of no measureable linear electric charge density."
landmark="EAID_3099F886_D076_4f49_98A5_452E887259DA">
xmi:id="EAID_DFDF7387_5899_49d8_9EB7_CD2BBC89BDA9"
axis="EAID_B383AED6_CE79_452a_83B5_3D3452624D24" value="0"
valueTypeUnit="EAID_FC0CC9EF_5264_46f8_97E5_BD9B4B98D732"/>
</referencePoint>
xmi:id="EAID_73DE5CE4_CA7B_45e8_8CB5_2A91EA022C59" name="OneCoulombPerMeterChargeDensity"
description="Representative of one unit of linear electric charge density measured in coulombs
per meter" landmark="EAID_E266B00D_B505_41f8_8219_9AF152973344">
xmi:id="EAID_7AA65249_F422_4a22_AB8E_70BCDE44CF8B"
axis="EAID_B383AED6_CE79_452a_83B5_3D3452624D24" value="1"
valueTypeUnit="EAID_FC0CC9EF_5264_46f8_97E5_BD9B4B98D732"/>
</referencePoint>
</element>
xmi:id="EAID_B383AED6_CE79_452a_83B5_3D3452624D24"
name="ElectricChargeDensityLinearMeasurementSystemAxis" description="The measurement system axis
to describe the electric charge density of per unit length."
defaultValueTypeUnit="EAID_FC0CC9EF_5264_46f8_97E5_BD9B4B98D732"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5C6DCB9B_9DEF_4ca7_AE1B_912C5ADD7AE5"
name="ElectricCurrent" description="Root package for electtric current measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_ABF24DC3_5528_4c1f_9B20_FB1962FA03F1"
name="ElectricCurrentMeasurement" description="An electric current is a flow of electric charge
when there is voltage present across a conductor."
measurementAxis="EAID_AFAA7020_957F_4f96_A42A_DBFF475E676A"
measurementSystem="EAID_0BBECB23_57B7_42d6_B9FD_4D5DC34E99B8"
realizes="EAID_35DDCEBF_B184_4159_B5C4_932587A840B5"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_AFAA7020_957F_4f96_A42A_DBFF475E676A"
name="ElectricCurrentMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_50C42368_AC6D_49d2_8BE4_652F6B4AD446"
realizes="EAID_35DDCEBF_B184_4159_B5C4_932587A840B5"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_36935DC1_A845_4466_AE64_5917C02AA51C"
name="ElectricCurrentMeasurementSystem" description="Collection of elements applicable to Electric
Current measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_08C169D6_365F_4573_BB2D_87F29AFF3BF0"
name="RealAmp" description="Electric current described in the real numerical value of Amp."
unit="EAID_1BC72413_1442_4d9a_BBC6_5D13EA4B334F"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_0BBECB23_57B7_42d6_B9FD_4D5DC34E99B8"
name="ElectricCurrentMeasurementSystem" description="The measurement system to describe
electrical current as the rate at which a charge flows past a point on a circuit."
measurementSystemAxis="EAID_50C42368_AC6D_49d2_8BE4_652F6B4AD446"
xmi:id="EAID_D788B9DC_6BF3_4d81_B245_7B9C4F2C57A7" name="ZeroCurrentReferencePoint"
description="No electric current is the absence of flow of electric charge moving through a
wire." landmark="EAID_C4DAF340_8D6D_494b_A77D_B012BDCC2CB0">
xmi:id="EAID_65041C17_2ED2_4ee0_9AE8_24A640DFB3F8"
axis="EAID_50C42368_AC6D_49d2_8BE4_652F6B4AD446" value="0"
valueTypeUnit="EAID_08C169D6_365F_4573_BB2D_87F29AFF3BF0"/>
</referencePoint>
xmi:id="EAID_F20FBF46_F3AE_44ff_AC38_CD7A65FCC0ED" name="OneAmpCurrentReferencePoint"
description="A positive one amp current value means that the actual direction of current
through that circuit element is same direction of the chosen reference direction."
landmark="EAID_1F30EE79_9169_465b_865B_96D6C06844B4">

xmi:id="EAID_BDAFE115_24F6_4bae_A3DF_1A0606219BE9"
axis="EAID_50C42368_AC6D_49d2_8BE4_652F6B4AD446" value="1"
valueTypeUnit="EAID_08C169D6_365F_4573_BB2D_87F29AFF3BF0"/>
</referencePoint>
</element>
xmi:id="EAID_50C42368_AC6D_49d2_8BE4_652F6B4AD446" name="ElectricCurrentMeasurementSystemAxis"
description="The measurement system axis to describe the nature of the electrical current
defaultValueTypeUnit="EAID_08C169D6_365F_4573_BB2D_87F29AFF3BF0"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_79AE1F63_682D_4261_98AB_511DBF2340C5"
name="ElectricCurrentDensity" description="Root package for Electric Current Density measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_19A4B23D_A61C_4b1c_BA8F_3B4C13DB6336"
name="ElectricCurrentDensityMeasurement" description="The measurement to describe the concept of
electric current density as used to express the electric current per unit area of cross section."
measurementAxis="EAID_E9B727B7_C445_4a62_A301_DBB60EE73708
EAID_0873478C_D0CA_4585_8105_01F380080FFC EAID_3BDD89B1_3F23_486c_9B62_6B737E1C82CE"
measurementSystem="EAID_9353FDBC_EFFD_4501_BDE0_71B036A925B8"
realizes="EAID_60A46947_91C7_4bc7_A74D_1DE2137E5CC5"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_E9B727B7_C445_4a62_A301_DBB60EE73708"
name="ElectricCurrentDensityMeasurementXAxis" precision="0.001"
measurementSystemAxis="EAID_6146F258_1614_44a4_92C3_D40E23FF89B9"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_0873478C_D0CA_4585_8105_01F380080FFC"
name="ElectricCurrentDensityMeasurementYAxis" precision="0.001"
measurementSystemAxis="EAID_5489D8EA_46AC_4632_8A58_B90539C4B59D"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_3BDD89B1_3F23_486c_9B62_6B737E1C82CE"
name="ElectricCurrentDensityMeasurementZAxis" precision="0.001"
measurementSystemAxis="EAID_E044265D_45C5_4ed4_8A99_C51C425DF2F9"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_EC9832A6_925E_44fc_BAD1_E0C0252F3BBF"
name="ElectricCurrentDensityMeasurementSystem" description="Collection of elements applicable to
Electric Current Density measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D0606B2C_8462_4b2d_969A_CA3E6A32276C"
name="RealAmpPerSquareMeters" description="Electric Current Density described in the real
numerical value of Amp per square meter" unit="EAID_1B59A0CB_A750_4fde_B861_3C0FBACB9E7B"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_9353FDBC_EFFD_4501_BDE0_71B036A925B8"
name="ElectricCurrentDensityMeasurementSystem" description="The measurement system to describe
the electric current density as a vector whose magnitude is the electric current per cross-
sectional area at a given point in space."
measurementSystemAxis="EAID_6146F258_1614_44a4_92C3_D40E23FF89B9
EAID_5489D8EA_46AC_4632_8A58_B90539C4B59D EAID_E044265D_45C5_4ed4_8A99_C51C425DF2F9"
coordinateSystem="EAID_E16B78B2_B2BA_43e5_837E_018DC1FD621C" externalStandardReference=""
xmi:id="EAID_6683DC3F_6D13_4687_8EFB_8FE9B32550D8"
name="ZeroElectricCurrentDensityReferencePoint" description="Representative of no measureable
electric current density for any axis, acting as the origin for the measurement system."
landmark="EAID_4EFDCA88_21D2_413e_A8E7_C237BAAD6EF8">
xmi:id="EAID_CC06C503_486F_48fa_B6BC_961B9EB360C9"
axis="EAID_6146F258_1614_44a4_92C3_D40E23FF89B9" value="0"
valueTypeUnit="EAID_D0606B2C_8462_4b2d_969A_CA3E6A32276C"/>
xmi:id="EAID_ADE10536_459F_4566_85CA_104EB524F19F"
axis="EAID_5489D8EA_46AC_4632_8A58_B90539C4B59D" value="0"
xmi:id="EAID_9D903B93_3EAD_4844_AC2D_11E322C40A74"
axis="EAID_E044265D_45C5_4ed4_8A99_C51C425DF2F9" value="0"
</referencePoint>
xmi:id="EAID_F483C36F_331D_4d0c_9EDD_912DCD43CE91"
name="OneAmpPerSquareMeterDensityYDirection" description="Representative of measureable vector
direction of electric current density in the Y direction."
landmark="EAID_97227095_5555_43bc_A29F_18C21EF95AD1">
xmi:id="EAID_0BE0740D_F248_449a_963A_22D8F1B93DB0"
axis="EAID_6146F258_1614_44a4_92C3_D40E23FF89B9" value="0.0"
xmi:id="EAID_4FF3F3AD_B986_4983_8A66_5DFCCE79A852"
axis="EAID_5489D8EA_46AC_4632_8A58_B90539C4B59D" value="1.0"
xmi:id="EAID_1528AABB_3F0E_449e_8CF5_D6EAD649505A"
axis="EAID_E044265D_45C5_4ed4_8A99_C51C425DF2F9" value="0.0"
</referencePoint>
xmi:id="EAID_1D428E76_D0B4_4d52_89A9_046287D3630A"
name="OneAmpPerSquareMeterDensityZDirection" description="Representative of measureable vector
direction of electric current density in the Z direction."
landmark="EAID_3812651D_A79A_4181_8D48_8E7D2B39160E">
xmi:id="EAID_57A067CF_8E75_4aad_8C21_B5012315F693"
xmi:id="EAID_71B1245A_ECD5_4a92_9B94_6802ECE82FDC"
xmi:id="EAID_F8E725C6_4842_4692_867E_F180C2B32A72"
</referencePoint>
xmi:id="EAID_FF2A9D86_F4E3_43b1_911B_F038297B2D75"
name="OneAmpPerSquareMeterDensityXDirection" description="Representative of measureable vector
direction of electric current density in the X direction."
landmark="EAID_D906AAE7_5FE3_46a0_8164_81A17CE49BDB">
xmi:id="EAID_29043933_0AAF_4908_B83F_7663090F50B9"
xmi:id="EAID_D98A1665_F1C9_4ada_B665_63FF3240D6E5"
xmi:id="EAID_78D0A7CE_1478_4a1f_AD1F_68BE0293C1FC"
</referencePoint>
</element>
xmi:id="EAID_6146F258_1614_44a4_92C3_D40E23FF89B9"
name="ElectricCurrentDensityMeasurementSystemXAxis" description="The measurement system axis to
describe the nature of the electric current density measurement X direction."
defaultValueTypeUnit="EAID_D0606B2C_8462_4b2d_969A_CA3E6A32276C"/>
xmi:id="EAID_5489D8EA_46AC_4632_8A58_B90539C4B59D"
name="ElectricCurrentDensityMeasurementSystemYAxis" description="The measurement system axis to
describe the nature of the electric current density measurement Y direction."

xmi:id="EAID_E044265D_45C5_4ed4_8A99_C51C425DF2F9"
name="ElectricCurrentDensityMeasurementSystemZAxis" description="The measurement system axis to
describe the nature of the electric current density measurement Z direction."
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_605F71F8_52B9_4cc7_A510_6961CE9E770E"
name="ElectricityLandmarks" description="Collection of landmark elements applicable to Electric
Current measurements.">
<element xmi:type="logical:Landmark" xmi:id="EAID_1F30EE79_9169_465b_865B_96D6C06844B4"
name="OneAmpLandmark" description="A current of 1 amp means that there is 1 coulomb of charge
passing through a cross section of a wire every 1 second."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_D906AAE7_5FE3_46a0_8164_81A17CE49BDB"
name="OneAmpPerSquareMeterCurrentDensityXDirectionLandmark" description="One amp per square meter
of electric current density of the X vector direction. "/>
<element xmi:type="logical:Landmark" xmi:id="EAID_97227095_5555_43bc_A29F_18C21EF95AD1"
name="OneAmpPerSquareMeterCurrentDensityYDirectionLandmark" description="One amp per square meter
of electric current density of the Y vector direction. "/>
<element xmi:type="logical:Landmark" xmi:id="EAID_3812651D_A79A_4181_8D48_8E7D2B39160E"
name="OneAmpPerSquareMeterCurrentDensityZDirectionLandmark" description="One amp per square meter
of electric current density of the Z vector direction. "/>
<element xmi:type="logical:Landmark" xmi:id="EAID_7C6FB1B9_F9F9_4b44_94F3_E6883ACC835F"
name="OneCoulombLandmark" description="Its SI definition is the charge transported by a constant
current of one amp in one second:"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_932FC611_74B3_4b33_BA1B_0C017A64F0E0"
name="OneCoulombPerMeterCubedLandmark" description="A unit of electric current density measured at
one unit of coulombs per meter cubed as applied to volume."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_E266B00D_B505_41f8_8219_9AF152973344"
name="OneCoulombPerMeterLandmark" description="A unit of electric current density measured at one
unit of coulombs per meter."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_F581EEC1_D7B0_4a12_A380_CFDE0FE31101"
name="OneCoulombPerMeterSquaredLandmark" description="A unit of electric current density measured
at one unit of coulombs per meter squared as applied to a surface area."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_79DB8969_ED34_45fa_B559_C6C84BCA72C0"
name="OneFaradLandmark" description="A unit of stored electrical charge measured at One Farad"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_36E07197_7892_4ac1_A1DE_03F74C4423F3"
name="OneVoltLandmark" description="A unit of electric potential measured at one unit of volt."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_425AD038_620E_4728_AAEA_06C1B85F4160"
name="ZeroCapacitanceLandmark" description="No electrical charge stored by a body."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_3099F886_D076_4f49_98A5_452E887259DA"
name="ZeroElectricChargeDensityLandmark" description="No measureable electric charge density."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_C4DAF340_8D6D_494b_A77D_B012BDCC2CB0"
name="ZeroElectricChargeLandmark" description="No charge is flowing through a circuit."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_4EFDCA88_21D2_413e_A8E7_C237BAAD6EF8"
name="ZeroElectricCurrentDensityLandmark" description="No measureable electric current density."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_02BD4EDE_A62E_44d3_806E_5F0959476547"
name="ZeroElectricPotentialLandmark" description="No measureable electric potential. No voltage."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6DDBAB7E_514D_44a4_BC55_052F36901686"
name="ElectricPotential" description="Root package for Electric Potential measure">
<element xmi:type="logical:Measurement" xmi:id="EAID_A6729EA2_89C1_47c8_A7CC_936E67DC2289"
name="ElectricPotentialMeasurement" description="The measurement to describe the concept of
electric potential as used to express the effect of an electric field of a source in terms of the
location within the electric field." measurementAxis="EAID_1078A57E_70F5_46a7_AEAC_574A46A5B0CA"
measurementSystem="EAID_6FE2873F_6DC7_416e_B5B4_C25387FF0D58"
realizes="EAID_FD27C3E6_3A30_45b8_B836_91CD599BD168"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_1078A57E_70F5_46a7_AEAC_574A46A5B0CA"
name="ElectricPotentialMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_387376D6_BB43_44ac_9375_40F79A2E3641"
realizes="EAID_FD27C3E6_3A30_45b8_B836_91CD599BD168"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C483A13F_5B24_477c_8E58_86F70A7F330F"
name="ElectricPotentialMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_BB71A3BE_09B3_4824_95EF_19A4464F51B8"
name="RealVolt" description="Electric Potential described in the real numerical value of Volts"
unit="EAID_7DAFAFA2_9CA0_4db4_ADB9_A483D5B16E8D"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_6FE2873F_6DC7_416e_B5B4_C25387FF0D58"
name="ElectricPotentialMeasurementSystem" description="Measurement system to describe the amount
of potential energy per unit of charge."
measurementSystemAxis="EAID_387376D6_BB43_44ac_9375_40F79A2E3641"
orientation="Values increase as electric potential increases.">
xmi:id="EAID_FE16C2DC_AFB9_4763_AE36_8D3FE34ADBAA" name="ZeroVoltageReferencePoint"
description="Representative of no measureable electric potential energy."
landmark="EAID_02BD4EDE_A62E_44d3_806E_5F0959476547">
xmi:id="EAID_AD4BEDEF_5FA7_4e6b_AF5B_E314614DE4B7"
axis="EAID_387376D6_BB43_44ac_9375_40F79A2E3641" value="0"
valueTypeUnit="EAID_BB71A3BE_09B3_4824_95EF_19A4464F51B8"/>
</referencePoint>
xmi:id="EAID_7BA0F893_82EE_44b6_99C6_B3C6830EA306" name="OneVoltReferencePoint"
description="Representative of voltage measured as one volt of electric potential.."
landmark="EAID_36E07197_7892_4ac1_A1DE_03F74C4423F3">
xmi:id="EAID_0CE5E2ED_452F_4ec0_A6D7_290C550B4E7E"
axis="EAID_387376D6_BB43_44ac_9375_40F79A2E3641" value="1"
valueTypeUnit="EAID_BB71A3BE_09B3_4824_95EF_19A4464F51B8"/>
</referencePoint>
</element>
xmi:id="EAID_387376D6_BB43_44ac_9375_40F79A2E3641" name="ElectricPotentialMeasurementSystemAxis"
description="The measurement system axis to describe the nature of the electrical potential
defaultValueTypeUnit="EAID_BB71A3BE_09B3_4824_95EF_19A4464F51B8"/>
</ldm>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E26B9376_676D_49b1_9B1D_53C60D15AB0B"
name="EnergyMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_8235F89B_570F_44f3_8727_450838068E4E"
name="AbsorbedDoseMeasurement" description="Measurement for absorbed doses of energy."
measurementAxis="EAID_D31D0AEB_C79B_459e_A73E_64936C46B1B0"
measurementSystem="EAID_B590A760_ABD9_4fce_AB3E_FC4F371B75D5"
realizes="EAID_AFCB75C7_863B_4112_8F1E_2FB4FE1D4D2A"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_D239BB0A_61E9_4d73_B220_267948315A3B"
name="AbsorbedDoseRateMeasurement" description="Measurement for absorbed dose rates of energy."
measurementAxis="EAID_FA7A6735_EC09_41b6_8827_23E614353067"
measurementSystem="EAID_480C3917_A3B2_485d_BE04_C95A1B7ACA62"
realizes="EAID_EEED99B8_359B_41bf_B6B0_2BA8EC5E1B07"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_6C9FA1B6_8028_4e37_B5C2_DA1F53AE15B1"
name="DoseEquivalentMeasurement" description="Measurement of dose equivalence."
measurementAxis="EAID_B65BC791_44F7_4bf8_BC40_F903D9667248"
measurementSystem="EAID_B4EBE367_B3E2_40d8_ABED_E1C8BE743AA2"
realizes="EAID_29F32E46_EDB2_472d_80CA_7B91F8275889"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_EE720C4B_87E1_4002_849B_B49DB991A0AB"
name="EnergyMeasurement" description="Measurement for energy."
measurementAxis="EAID_CFD06888_1695_41c6_9409_2C79101B0BD1"
measurementSystem="EAID_35B208F2_17F0_4a5e_B767_DC3DA3ADFF87"
realizes="EAID_32D02294_1A54_48ee_AA9D_2EA0EDBC4B76"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D31D0AEB_C79B_459e_A73E_64936C46B1B0"
name="AbsorbedDoseMeasurementAxis" precision="0.000001"
measurementSystemAxis="EAID_48DD6F0C_0129_4d4a_B28C_90CE92C8B6E3"
realizes="EAID_AFCB75C7_863B_4112_8F1E_2FB4FE1D4D2A"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_FA7A6735_EC09_41b6_8827_23E614353067"
name="AbsorbedDoseRateMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_2061E509_E576_4a46_9159_FE533C475099"
realizes="EAID_EEED99B8_359B_41bf_B6B0_2BA8EC5E1B07"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_B65BC791_44F7_4bf8_BC40_F903D9667248"
name="DoseEquivalentMeasurementAxis" precision="0.0001"
measurementSystemAxis="EAID_BB03831D_9E78_4a66_82E2_40B4EB76F437"
realizes="EAID_29F32E46_EDB2_472d_80CA_7B91F8275889"/>

<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_CFD06888_1695_41c6_9409_2C79101B0BD1"
name="EnergyMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_02569D51_133C_46a1_B2B6_87A5DB877565"
realizes="EAID_32D02294_1A54_48ee_AA9D_2EA0EDBC4B76"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_EB97C09D_FA9A_4981_BCE4_DE80C8BAC012"
name="AbsorbedDoseLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_F1759756_0DA4_49d7_B58C_1B2DD187B77E"
name="OneGrayAbsorbedDoseLandmark" description="Unit absorbed dose."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_E7A24B06_5DDB_4231_8E10_D0B9CC02B13C"
name="ZeroAbsorbedDoseLandmark" description="Zero absorbed dose."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_61BAE311_8AF8_456c_996D_4DC29D366847"
name="AbsorbedDoseMeasurementSystems">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_E6457D6B_6D62_4e74_8BDB_21EC7A0254E2"
name="NonNegativeRealGrays" description="Non-negative Grays."
unit="EAID_06F05060_CF06_4f65_A9AF_75CA9D6D4343"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_B590A760_ABD9_4fce_AB3E_FC4F371B75D5"
name="AbsorbedDoseMeasurementSystem" description="System for measuring absorbed doses of energy."
measurementSystemAxis="EAID_48DD6F0C_0129_4d4a_B28C_90CE92C8B6E3"
orientation="Values increase as absorbed dose increases.">
xmi:id="EAID_EE7DE422_A0CF_43ba_9A18_BBA1E4BE3979" name="OneGrayAbsorbedDoseReferencePoint"
description="Represents 1 Gray of absorbed dose."
landmark="EAID_F1759756_0DA4_49d7_B58C_1B2DD187B77E">
xmi:id="EAID_1DF9B37F_72F2_46f4_9750_A29F0B7DAC2E"
axis="EAID_48DD6F0C_0129_4d4a_B28C_90CE92C8B6E3" value="1.0"
valueTypeUnit="EAID_E6457D6B_6D62_4e74_8BDB_21EC7A0254E2"/>
</referencePoint>
xmi:id="EAID_84CD1D40_9F0E_4f87_AD2A_C2C97CA8B8BE" name="ZeroAbsorbedDosReferencePoint"
description="Represents zero absorbed dose."
landmark="EAID_E7A24B06_5DDB_4231_8E10_D0B9CC02B13C">
xmi:id="EAID_4E6AE9B9_0B42_45db_BB21_A2D9016F893B"
axis="EAID_48DD6F0C_0129_4d4a_B28C_90CE92C8B6E3" value="0.0"
valueTypeUnit="EAID_E6457D6B_6D62_4e74_8BDB_21EC7A0254E2"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_48DD6F0C_0129_4d4a_B28C_90CE92C8B6E3"
name="AbsorbedDoseMeasurementSystemAxis" description="Axis for measuring absorbed doses of energy."
defaultValueTypeUnit="EAID_E6457D6B_6D62_4e74_8BDB_21EC7A0254E2">
xmi:id="EAID_565C6DD2_355F_42c1_9D79_D72DD2C15A88" constraintText="Always >= 0"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E26E705B_7C17_499a_BEC6_BEB070D87319"
name="AbsorbedDoseRateLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_47DED456_6C3D_44c7_9586_CAFE4585DB0E"
name="OneGrayPerSecondAbsorbedDoseRateLandmark" description="Unit absorbed dose rate landmark."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_FD255658_0DE4_4a8c_8C24_E8A7983EA13D"
name="ZeroAbsorbedDoseRateLandmark" description="Zero absorbed dose rate."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_07764EF4_A8F3_45b9_9103_6FFC3BAFE6E8"
name="AbsorbedDosRateMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_AC8A2C1D_F694_403a_A8A3_79014B281D10"
name="NonNegativeGraysPerSecond" description="Non-negative Grays per second"
unit="EAID_F8CE6A2C_0E47_4f2f_88E0_5F255664DCDA"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_480C3917_A3B2_485d_BE04_C95A1B7ACA62"
name="AbsorbedDoseRateMeasurementSystem" description="System for measuring absorbed doses of
energy." measurementSystemAxis="EAID_2061E509_E576_4a46_9159_FE533C475099"
orientation="Values increase as absorbed dose rate increases.">
xmi:id="EAID_019E1CF2_F9C6_40af_97F7_24E68D5C2759"
name="OneGrayPerSecondAbsorbedDoseRateReferencePoint" description="Represents 1 unit value of
absorbed dose rate." landmark="EAID_47DED456_6C3D_44c7_9586_CAFE4585DB0E">
xmi:id="EAID_E6673EA7_F2FC_4b52_B5DA_963F9C7A3D45"
axis="EAID_2061E509_E576_4a46_9159_FE533C475099" value="1.0"
valueTypeUnit="EAID_AC8A2C1D_F694_403a_A8A3_79014B281D10"/>
</referencePoint>
xmi:id="EAID_EA33F6E2_A38C_4fd8_8236_0F33D7875D1B" name="ZeroAbsorbedDoseRateReferencePoint"
description="Represents a zero value of absorbed dose rate"
landmark="EAID_FD255658_0DE4_4a8c_8C24_E8A7983EA13D">
xmi:id="EAID_5A89051E_0E85_490b_903D_289958F27BF6"
axis="EAID_2061E509_E576_4a46_9159_FE533C475099" value="0.0"
valueTypeUnit="EAID_AC8A2C1D_F694_403a_A8A3_79014B281D10"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_2061E509_E576_4a46_9159_FE533C475099"
name="AbsorbedDoseRateMeasurementSystemAxis" description="The measurement system axis to describe
the nature of measuring absorbed doses of energy." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_AC8A2C1D_F694_403a_A8A3_79014B281D10">
xmi:id="EAID_1F5B2E71_5834_4214_85AC_A8BC0FEEC1EA" constraintText="Always >= 0"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4FCEC184_A34E_4892_A205_A30FEEA2C46B"
name="DoseEquivalentLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_FDC373B4_972D_4e28_BF96_F2C36D7ADDD3"
name="OneSievertDoseEquivalentLandmark" description="One Sievert dose equivalent."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_DA54FC44_ED7D_48f6_AB58_4EB88B717F97"
name="ZeroDoseEquivalentLandmark" description="Zero dose equivalent"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C73089B7_D748_467b_A674_AB298B91299B"
name="DoseEquivalentMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_46C7930A_5384_4f0e_BF83_DF1D0ABF6026"
name="NonNegativeRealSieverts" description="Sieverts as a non-negative real representation."
unit="EAID_FEF61F65_30EA_4429_BF95_EC1A4A8AC7E7"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_B4EBE367_B3E2_40d8_ABED_E1C8BE743AA2"
name="DoseEquivalentMeasurementSystem" description="Measurement system for measuring dose
equivalent." measurementSystemAxis="EAID_BB03831D_9E78_4a66_82E2_40B4EB76F437"
orientation="Values increase as dose equivalent increases.">
xmi:id="EAID_00C8A671_0B68_4506_B0E6_E0C87D23C5BB" name="ZeroDoseEquivalentReferencePoint"
description="zero amount of dose equivalent reference point"
landmark="EAID_DA54FC44_ED7D_48f6_AB58_4EB88B717F97">
xmi:id="EAID_D92AE307_9C49_45ed_9F50_56959A048DA4"
axis="EAID_BB03831D_9E78_4a66_82E2_40B4EB76F437" value="0.0"
valueTypeUnit="EAID_46C7930A_5384_4f0e_BF83_DF1D0ABF6026"/>
</referencePoint>
xmi:id="EAID_6DC57B3A_3E40_4338_8F01_C7F4DA9B22FD" name="OneSievertDoseEquivalentReferencePoint"
description="Unit amount of dose equivalent reference point"
landmark="EAID_FDC373B4_972D_4e28_BF96_F2C36D7ADDD3">
xmi:id="EAID_C4AF5F2C_8209_4659_9EC1_C66804F0C374"
axis="EAID_BB03831D_9E78_4a66_82E2_40B4EB76F437" value="1.0"
valueTypeUnit="EAID_46C7930A_5384_4f0e_BF83_DF1D0ABF6026"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_BB03831D_9E78_4a66_82E2_40B4EB76F437"
name="DoseEquivalentMeasurementSystemAxis" description="Measurement system axis for dose equivalent
measurements." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_46C7930A_5384_4f0e_BF83_DF1D0ABF6026"/>

</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_72F6375A_57C3_466b_8DF6_36D507D3D64E"
name="EnergyLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_FC5FCA4E_4789_465a_A59A_5ABF75EC9B83"
name="OneJouleEnergyLandmark" description="A force of 1 newton through distance of meter."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_52901778_4D76_4bb1_8A71_C9462DF5B4E8"
name="ZeroEnergyLandmark" description="Zero energy."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_CEEA5986_F492_4abb_AB84_669D28B6B047"
name="EnergyMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_CBAB96B0_9F89_4e60_A472_F652D5F52946"
name="RealJoules" description="Joules as a real numerical representation"
unit="EAID_6BEAC65A_17AD_49d0_A7D3_0A49C14B7489"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_35B208F2_17F0_4a5e_B767_DC3DA3ADFF87"
name="EnergyMeasurementSystem" description="Measurement system for measuring energy."
measurementSystemAxis="EAID_02569D51_133C_46a1_B2B6_87A5DB877565"
orientation="Values increase as energy increases.">
xmi:id="EAID_B093293A_1525_47dc_B734_9A5808F8D22A" name="ZeroEnergyReferencePoint"
description="Zero energy reference point" landmark="EAID_52901778_4D76_4bb1_8A71_C9462DF5B4E8">
xmi:id="EAID_48047EA4_DB1A_4ff7_B59B_110F151814CD"
axis="EAID_02569D51_133C_46a1_B2B6_87A5DB877565" value="0.0"
valueTypeUnit="EAID_CBAB96B0_9F89_4e60_A472_F652D5F52946"/>
</referencePoint>
xmi:id="EAID_99371D94_822A_492c_A43C_09FC3F89F409" name="OneJouleEnergyReferencePoint"
description="Unit amount of energy reference point."
landmark="EAID_FC5FCA4E_4789_465a_A59A_5ABF75EC9B83">
xmi:id="EAID_DF63DDCC_C4E0_415c_B27B_E89AA9F43FCA"
axis="EAID_02569D51_133C_46a1_B2B6_87A5DB877565" value="1.0"
valueTypeUnit="EAID_CBAB96B0_9F89_4e60_A472_F652D5F52946"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_02569D51_133C_46a1_B2B6_87A5DB877565"
name="EnergyMeasurementSystemsAxis" description="Measurement system axis for energy measurements."
defaultValueTypeUnit="EAID_CBAB96B0_9F89_4e60_A472_F652D5F52946"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F2EDB867_9489_4262_BE19_4EDAC30BD4DB"
name="ForceMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_7B96051A_6A05_471b_BFC8_24B5DE1DE4E2"
name="ForceMeasurement" description="Measurement used to describe observable properties of force."
measurementAxis="EAID_D1CC7A3B_B4CE_4843_9413_FF9C7825A18D"
measurementSystem="EAID_1811EA5E_350D_45ca_9BE1_1E9D148DB99F"
realizes="EAID_B4FA8AFA_1FC5_4cc3_8E95_1956D00176DC"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_0306815A_D122_4fa8_9C28_68ECDF99374F"
name="TorqueMeasurement" description="Measurement used to describe observable properties of torque"
measurementAxis="EAID_64EE472A_5E96_4dc7_B324_7B553E69BD99"
measurementSystem="EAID_A7098479_C56F_4dae_B04A_092FA4562F75"
realizes="EAID_69A1D868_1DE4_4fce_9C0B_7A47AB1FC46B"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D1CC7A3B_B4CE_4843_9413_FF9C7825A18D"
name="ForceMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_763EF3D5_B7E4_4c88_88A6_5843A9D2A1FF"
realizes="EAID_B4FA8AFA_1FC5_4cc3_8E95_1956D00176DC"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_64EE472A_5E96_4dc7_B324_7B553E69BD99"
name="TorqueMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_B2CA99C4_C812_4ecf_AE6E_BA15A40467E3"
realizes="EAID_69A1D868_1DE4_4fce_9C0B_7A47AB1FC46B"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E462EE61_6AE0_4b94_97D9_84A47BC33704"
name="ForceLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_75F976AD_CA44_4adb_8D48_8BA2B25A1DCD"
name="Kilopond" description="Force landmark equal to the magnitude of the force exerted by one
kilogram of mass in a 9.80665 m/s2 gravitational field ."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_7EB3F434_82EC_4375_A434_5085A142F9BA"
name="ZeroForceLandmark" description="Landmark indicating a force of zero (no applied force)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A1FF4BC8_634C_4fe2_99BE_47273C78E79D"
name="ForceMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D40F5AB0_A485_4b81_AA5B_E668E0ACB798"
name="RealNewtons" description="Value type used to describe a value of Newtons as a real."
unit="EAID_3F9CBF28_F842_4896_ABEC_B4498760BD80"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_1811EA5E_350D_45ca_9BE1_1E9D148DB99F"
name="ForceMeasurementSystem" description="Measurement system used to measure values of force"
measurementSystemAxis="EAID_763EF3D5_B7E4_4c88_88A6_5843A9D2A1FF"
orientation="Values increase as force increases.">
xmi:id="EAID_50ED91CE_76C8_485c_A7B9_4CCF2F142A08" name="KilopondForceReferencePoint"
description="Reference point indicating a value of 1 kilopond of applied force"
landmark="EAID_75F976AD_CA44_4adb_8D48_8BA2B25A1DCD">
xmi:id="EAID_9FB666DC_BBE3_4bdf_A369_F70CE02C7F96"
axis="EAID_763EF3D5_B7E4_4c88_88A6_5843A9D2A1FF" value="9.80665"
valueTypeUnit="EAID_D40F5AB0_A485_4b81_AA5B_E668E0ACB798"/>
</referencePoint>
xmi:id="EAID_F11A00B4_2F80_425e_B134_9FB2542E1B61" name="ZeroForceReferencePoint"
description="Reference point indicating a value of zero applied force"
landmark="EAID_7EB3F434_82EC_4375_A434_5085A142F9BA">
xmi:id="EAID_C20DB0BF_1455_4f4a_BF97_EF2679C53818"
axis="EAID_763EF3D5_B7E4_4c88_88A6_5843A9D2A1FF" value="0.0"
valueTypeUnit="EAID_D40F5AB0_A485_4b81_AA5B_E668E0ACB798"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_763EF3D5_B7E4_4c88_88A6_5843A9D2A1FF"
name="ForceMeasurementSystemAxis" description="Measurement system axis used to measure values of
force." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_D40F5AB0_A485_4b81_AA5B_E668E0ACB798"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6CA6C2B7_0436_414a_B387_95B15A033D83"
name="TorqueLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_12C94E15_7436_4c2e_891F_279398A2CD96"
name="OneNewtonMeterLandmark" description="Unit value of torque representing 1 newton of force
applied to a moment arm of 1 meter."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_0A16B1C3_3293_4b6d_AE0B_CD5DB0606EC2"
name="ZeroTorqueLandmark" description="No measureable torque."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F2AB5E2B_3EB4_4603_B191_9DB594494BD8"
name="TorqueMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_2E982ED3_8795_413c_9E7D_AF1362B8E313"
name="RealNewtonMeters" description="Real newton meters"
unit="EAID_0A9F29A7_3ABC_4790_9E6D_CEBD6C7DBE5E"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_A7098479_C56F_4dae_B04A_092FA4562F75"
name="TorqueMeasurementSystem" description="Measurement system used to measure values of torque"
measurementSystemAxis="EAID_B2CA99C4_C812_4ecf_AE6E_BA15A40467E3"
orientation="Values increase as torque increases">
xmi:id="EAID_DCB29640_5B46_4820_93A6_2001AF13D37B" name="ZeroTorqueReferencePoint"
description="Reference point indicating a value measurement of zero torque"
landmark="EAID_0A16B1C3_3293_4b6d_AE0B_CD5DB0606EC2">
xmi:id="EAID_15D18789_956D_468e_BA59_191A890A8425"
axis="EAID_B2CA99C4_C812_4ecf_AE6E_BA15A40467E3" value="0.0"
valueTypeUnit="EAID_2E982ED3_8795_413c_9E7D_AF1362B8E313"/>
</referencePoint>
xmi:id="EAID_43B3D3A9_8135_4f01_928D_AB6B81E910E2" name="OneNewtonMeterReferencePart"

description="Reference point indicating a value of 1 newton meter of torque"
landmark="EAID_12C94E15_7436_4c2e_891F_279398A2CD96">
xmi:id="EAID_557E626E_36BA_4f7d_AA78_86B92FE57834"
axis="EAID_B2CA99C4_C812_4ecf_AE6E_BA15A40467E3" value="1.0"
valueTypeUnit="EAID_2E982ED3_8795_413c_9E7D_AF1362B8E313"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_B2CA99C4_C812_4ecf_AE6E_BA15A40467E3"
name="TorqueMeasurementSystemAxis" description="Measurement system axis used to measure values of
torque." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_2E982ED3_8795_413c_9E7D_AF1362B8E313"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_55B3FB0E_A77A_413a_8B8C_FEFA7AF455D8"
name="IlluminanceMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_C8E57B11_DD7B_445c_9000_3582226352A8"
name="IlluminanceMeasurement" description="Measurement of illuminance."
measurementAxis="EAID_2BD3908C_B758_4918_B282_12BE909F737A"
measurementSystem="EAID_E3FD4AE5_1A21_48b3_9ACF_777A59094757"
realizes="EAID_F07E3618_8CE7_4422_9D21_C8FBB9D77794"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_2BD3908C_B758_4918_B282_12BE909F737A"
name="IlluminanceMeasurementAxis" precision="0.0001"
measurementSystemAxis="EAID_E26914E4_539B_42b8_B009_473AF3E4A2B2"
realizes="EAID_F07E3618_8CE7_4422_9D21_C8FBB9D77794">
xmi:id="EAID_9C70827F_45C2_4fb5_ACA8_E34A08518058" constraintText="Always >= 0"/>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1234FB8E_0203_4acb_8BE1_DC5EF4BA80CA"
name="IlluminanceLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_72916D9B_2F88_4238_BEFC_6BE360FECB2D"
name="OneLuxIlluminanceLandmark" description="1 lux (= lumen per square meter)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_4ED560B6_21E8_4034_AC6A_3E13CA23DB34"
name="ZeroIlluminanceLandmark" description="zero illuminance landmark"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C0BA83CB_F844_4fd9_AFE6_18A48620D545"
name="IlluminanceMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D7BCB56E_6A7C_49a8_BC34_45FCEB45A6C3"
name="NonNegativeRealLux" description="Newton Meters as a real numerical representation"
unit="EAID_65D4712B_C8F8_4e24_98E0_32A8040A0F94"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_E3FD4AE5_1A21_48b3_9ACF_777A59094757"
name="IlluminanceMeasurementSystem" description="Measurement system for Illuminance"
measurementSystemAxis="EAID_E26914E4_539B_42b8_B009_473AF3E4A2B2"
orientation="Value increases as Illuminance increases.">
xmi:id="EAID_24D5F2A8_867B_4030_98CD_E76FF0EE616E" name="ZeroIlluminanceReferencePoint"
description="zero illuminance reference point"
landmark="EAID_4ED560B6_21E8_4034_AC6A_3E13CA23DB34">
xmi:id="EAID_A7D05736_71DB_46c4_9808_8F6640C0532B"
axis="EAID_E26914E4_539B_42b8_B009_473AF3E4A2B2" value="0.0"
valueTypeUnit="EAID_D7BCB56E_6A7C_49a8_BC34_45FCEB45A6C3"/>
</referencePoint>
xmi:id="EAID_39843784_5939_45af_ACE8_145D4D4DEAB0" name="OneLuxIlluminanceReferencePoint"
description="one lux illuminance reference point"
landmark="EAID_72916D9B_2F88_4238_BEFC_6BE360FECB2D">
xmi:id="EAID_BD603318_A062_46aa_9DE9_42B388DB3CBD"
axis="EAID_E26914E4_539B_42b8_B009_473AF3E4A2B2" value="1.0"
valueTypeUnit="EAID_D7BCB56E_6A7C_49a8_BC34_45FCEB45A6C3"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_E26914E4_539B_42b8_B009_473AF3E4A2B2"
name="IlluminanceMeasurementSystemAxis" description="Measurement system axis for illuminance"
defaultValueTypeUnit="EAID_D7BCB56E_6A7C_49a8_BC34_45FCEB45A6C3"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_67A5C16C_9418_41af_B588_2D7F0FDCF8ED"
name="LengthMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_642F751C_E910_46ec_9EA5_066FF96764C1"
name="DistanceMeasure">
<element xmi:type="logical:Measurement" xmi:id="EAID_8AA5E3A8_094B_4a89_A0CE_5E652A534005"
name="DistanceMeasurement" description="Measurement for distance"
measurementAxis="EAID_418E7BCF_83F3_4c3c_B7C9_ACA0796FB814"
measurementSystem="EAID_63B53D7F_65B9_4808_94CB_79D57291FFF1"
realizes="EAID_80D92BE8_8DF0_4f7c_82A6_CBF5DF17443A"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_418E7BCF_83F3_4c3c_B7C9_ACA0796FB814"
name="DistanceMeasurementAxis" precision="0.0001"
measurementSystemAxis="EAID_28497806_74F7_4473_A56D_C9978462C722"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_CDEEE592_702E_4842_AD6E_72C39B337181"
name="DistanceMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_63B53D7F_65B9_4808_94CB_79D57291FFF1"
name="DistanceMeasurementSystem" description="Measurement system for distance"
measurementSystemAxis="EAID_28497806_74F7_4473_A56D_C9978462C722"
orientation="Value increases as distance increases">
xmi:id="EAID_6654049D_9954_49fe_9D11_31C05FCC2076" name="ZeroDistanceReferencePoint"
description="zero distance reference point"
landmark="EAID_DD4089D3_E5F9_459f_AF68_2E7D03864E85">
xmi:id="EAID_9BC877DD_877F_495b_8D94_8B2D61BB0FCE"
axis="EAID_28497806_74F7_4473_A56D_C9978462C722" value="0.0"
valueTypeUnit="EAID_08FEE312_2D6C_498d_B43C_0A241BED52B2"/>
</referencePoint>
xmi:id="EAID_C095602A_9B87_446b_88FB_860C39785536" name="OneMeterDistanceReferencePoint"
description="Unit distance reference point"
landmark="EAID_80F96761_0360_479d_98D0_300A625D8793">
xmi:id="EAID_B3526424_147A_4bfe_9E72_C0DD95FFD0C0"
axis="EAID_28497806_74F7_4473_A56D_C9978462C722" value="1.0"
</referencePoint>
</element>
xmi:id="EAID_28497806_74F7_4473_A56D_C9978462C722" name="DistanceMeasurementSystemAxis"
defaultValueTypeUnit="EAID_08FEE312_2D6C_498d_B43C_0A241BED52B2"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6F44EB0A_D348_4d67_A98B_4943DE4C339B"
name="ExtentMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_9F6CBA03_9585_4e44_A3F2_4AB40FE76C7D"
name="ExtentMeasurement" description="Length distance dimension of the extent."
measurementAxis="EAID_025B2FE1_E76C_4b77_ABF9_8475DD97BCE5
EAID_E145CFA5_FCBB_4d8e_B452_DA9F6D17F2CF"
measurementSystem="EAID_CA5FF699_AFF6_41b4_A05F_9FB0BFCF2BA8"
realizes="EAID_0C0725EB_2FB1_46d2_A11A_716E6D6299E3"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_025B2FE1_E76C_4b77_ABF9_8475DD97BCE5"
name="LengthExtentMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_9670FC89_77BA_435e_8566_E620BCF11743"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_E145CFA5_FCBB_4d8e_B452_DA9F6D17F2CF"
name="WidthExtentMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_A7E348A5_3B56_4b27_BCDF_5CCD3E178C10"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5EA28638_8A2C_45a6_8C1F_7C9EC5DA8FED"
name="ExtentMeasurementSystem">

<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_CA5FF699_AFF6_41b4_A05F_9FB0BFCF2BA8"
name="ExtentMeasurementSystem" description="Measrement system for range or space to which an
object extends." measurementSystemAxis="EAID_9670FC89_77BA_435e_8566_E620BCF11743
EAID_A7E348A5_3B56_4b27_BCDF_5CCD3E178C10"
coordinateSystem="EAID_91380EB8_66EF_4d12_AC1D_84FF7F719080" externalStandardReference=""
xmi:id="EAID_A8636598_EE62_43ba_880C_2DBC1430C5D6" name="LengthOfZero" description="Length of
zero meters" landmark="EAID_DD4089D3_E5F9_459f_AF68_2E7D03864E85">
xmi:id="EAID_4CFF1A25_86D9_4c80_B563_BDF2B831B151"
axis="EAID_9670FC89_77BA_435e_8566_E620BCF11743" value=""
</referencePoint>
xmi:id="EAID_793FB81C_7F87_4a3a_B36E_EAAA895857F9" name="ZeroExtentReferencePoint"
description="Zero value of measurement as origin."
landmark="EAID_DD4089D3_E5F9_459f_AF68_2E7D03864E85">
xmi:id="EAID_09352C06_62D4_4a08_8E31_CAEB8BE5E619"
axis="EAID_9670FC89_77BA_435e_8566_E620BCF11743" value="0"
xmi:id="EAID_45F69B16_F62D_4046_BC4C_C0E4B77661D0"
axis="EAID_A7E348A5_3B56_4b27_BCDF_5CCD3E178C10" value="0"
</referencePoint>
xmi:id="EAID_CFFBDE99_1B33_4240_96D3_37F158CCAB2A" name="OneMeterLengthExtentReferencePoint"
description="One meter unit of a length extent measurement system."
landmark="EAID_80F96761_0360_479d_98D0_300A625D8793">
xmi:id="EAID_2B79AF9F_2F9E_4cbf_84E3_6730812BB38A"
xmi:id="EAID_6429E9EC_9D96_4e5f_87E9_13CBA42894D8"
</referencePoint>
xmi:id="EAID_2B1887BC_83AA_45b0_A86B_AD9CAAA2D031" name="OneMeterWidthExtentReferencePoint"
description="One meter unit of a width extent measurement system."
landmark="EAID_BE2755D6_D723_4955_A378_04212C88ACF3">
xmi:id="EAID_61F58ACB_097C_4522_8939_60C04EF8458E"
xmi:id="EAID_8189E2CC_402F_4cfb_B1EA_0ECB696DF67E"
</referencePoint>
</element>
xmi:id="EAID_9670FC89_77BA_435e_8566_E620BCF11743" name="LengthExtentMeasurementSystemAxis"
description="The width measurement system axis to describe the nature of the extent
measurement." axis="EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
xmi:id="EAID_A7E348A5_3B56_4b27_BCDF_5CCD3E178C10" name="WidthExtentMeasurementSystemAxis"
description="The length measurement system axis to describe the nature of the extent
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_33F3D7F7_F29C_4dab_BDDB_1975059426D4"
name="LengthLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_80F96761_0360_479d_98D0_300A625D8793"
name="OneMeterDistanceLandmark" description="One meter."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_BE2755D6_D723_4955_A378_04212C88ACF3"
name="ONeMeterWidthExtentLandmark" description="One Meter width landmark for extent"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_DD4089D3_E5F9_459f_AF68_2E7D03864E85"
name="ZeroDistanceLandmark" description="Zero distance."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AD61766A_1A38_4e9c_9F7E_680E1CDD052B"
name="LengthValueUnitType" description="Length measures common value unit pairs">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_08FEE312_2D6C_498d_B43C_0A241BED52B2"
name="NonNegativeRealMeter" description="Meter as a non-negative real numerical representation."
unit="EAID_0A9F29A7_3ABC_4790_9E6D_CEBD6C7DBE5E"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E789B9AA_560D_437c_A519_E00704438780"
name="LocalAir" description="Length measurements based on the Local Air Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_47FB3278_127F_4372_90C5_026806D81CA2"
name="LocalBody" description="Length measurements based on the Local Body Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C3B69079_5BCD_414b_AF59_DB18386970DE"
name="LocalGround" description="Length measurements based on the Local Ground Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D2CEC778_6599_40a5_B974_E45C3FAD538B"
name="LocalHorizontal" description="Length measurements based on the Local Horizontal Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4A531006_8DAE_4373_9413_FAA3AEDC7186"
name="LocalNorthEastDown" description="Length measurements based on the Local North East Down
Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A5691424_7631_47f7_85BE_0761869349F7"
name="LocalVehicle" description="Length measurements based on the Local Vehicle Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BC6E8DBF_BC82_4eee_B57D_628DFD2E97DD"
name="MeanSeaLevel" description="Length measurements based on the Mean Sea Level Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D6B2314B_B07A_4d2a_89CE_3F39060A3534" name="WGS84"
description="Length measurements based on the WGS-84 Reference Frame."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D2B4934D_072A_4582_8210_0E84B8CC846C"
name="LuminousIntensityMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_8156220D_353F_4be1_95A6_FA2553A6F3DD"
name="LuminousIntensityMeasurement" description="Measurement of wavelength weighted power (as
perceived by human eyes) emitted by a light source per unit solid angle. "
measurementAxis="EAID_F322AA41_26F6_4dd1_A3C9_1CF2B763BFBA"
measurementSystem="EAID_76A044C2_309B_4032_9FD0_493AEA64E632"
realizes="EAID_8B463517_0982_4cd0_884D_DD91D17AC345"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_F322AA41_26F6_4dd1_A3C9_1CF2B763BFBA"
name="LuminousIntensityMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_C186715F_C942_416c_A08C_EF95261E82E7"
realizes="EAID_8B463517_0982_4cd0_884D_DD91D17AC345"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F3688BCF_0AE5_4ca9_BB0C_11EC5E0BD15C"
name="LuminousIntensityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_E55AD9BB_D33A_4a81_8ED1_1B0833BA91BF"
name="Darkness" description="Represents no visible light."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_899B5AFF_D42E_4649_8089_0D7F02146AB6"
name="SingleCandela" description="power emitted by a light source in a particular direction"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_36CD1855_3C72_48b8_BE7D_B1E6C4FFE78C"
name="LuminousIntensityMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_2AD72CD8_0C70_4620_A675_683A13073D43"
name="NonNegativeRealCandelas" description="power emitted by a light source in a particular
direction" unit="EAID_846F619C_9BC7_40b2_AAA5_3CD2222F84CF"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_76A044C2_309B_4032_9FD0_493AEA64E632"
name="LuminousIntensityMeasurementSystem" description="Measurement system for LuminusIntensity
measured in Candelas" measurementSystemAxis="EAID_C186715F_C942_416c_A08C_EF95261E82E7"
orientation="Value increases as luminous intensity increases.">
xmi:id="EAID_E9211DAA_1222_4019_95A2_F071E6D2ADF6" name="LuminousIntensityOfOne"
description="Luminous Intensity of a single Candela"
landmark="EAID_899B5AFF_D42E_4649_8089_0D7F02146AB6">

xmi:id="EAID_676B6DD7_9FE4_4a2d_B188_D7FEEA48A712"
axis="EAID_C186715F_C942_416c_A08C_EF95261E82E7" value="1"
valueTypeUnit="EAID_2AD72CD8_0C70_4620_A675_683A13073D43"/>
</referencePoint>
xmi:id="EAID_C5E6F1A5_72B4_411d_BD92_6E9F9B037BEB" name="AbsenceOfLuminousInstenisty"
description="No Luminous Intensity" landmark="EAID_E55AD9BB_D33A_4a81_8ED1_1B0833BA91BF">
xmi:id="EAID_E92B3DB6_5A52_44bc_9C98_7049BC2A6EAF"
axis="EAID_C186715F_C942_416c_A08C_EF95261E82E7" value="0"
valueTypeUnit="EAID_2AD72CD8_0C70_4620_A675_683A13073D43"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_C186715F_C942_416c_A08C_EF95261E82E7"
name="LuminousIntensityMeasurementSystemAxis" description="Luminuos Intensity increases as values
increase" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_2AD72CD8_0C70_4620_A675_683A13073D43"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_52DEC862_E1FD_49a3_B8B4_086A76599A52"
name="MassMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_AB8973A2_514B_4406_85DE_695868C93C82"
name="MassMeasurement" description="The mass measurement of an object determines its acceleration in
the presence of an applied force." measurementAxis="EAID_536925C8_E755_404d_B1DB_F180A081DA83"
measurementSystem="EAID_E10C27FD_D46D_48f8_AD45_1B1B7BAFBBBE"
realizes="EAID_5D0D98B4_F3C5_4131_ACA9_A6CBCDEE8F6B"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_536925C8_E755_404d_B1DB_F180A081DA83"
name="MassMeasurementAxis" precision="0.01"
measurementSystemAxis="EAID_1B100E6A_9C51_4e2a_A9A7_0DD7B2772F94"
realizes="EAID_5D0D98B4_F3C5_4131_ACA9_A6CBCDEE8F6B">
xmi:id="EAID_CEAA196F_C931_4dc9_8C92_CA8AD1D17A1C" constraintText=""/>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_379D18D5_787E_4a60_ACF7_2E1334620243"
name="MassLandmarks" description="Collection of landmark elements applicable to Mass measurements.">
<element xmi:type="logical:Landmark" xmi:id="EAID_F5EE0165_F768_43ea_8E46_19F80DA779FF"
name="OneKilogramLandmark" description="The one kilogram mass for a body as measured when the body
is a rest relative to an observer, an inherent property of the body."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_894D6C59_4EAA_470a_B61A_D5561C678545"
name="ZeroMassLandmark" description="No recorded object mass."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E6CF394B_57A0_4c45_9667_D2DA98E78F23"
name="MassMeasurementSystem" description="Collection of elements applicable to Mass measurements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_B4409B5D_DA7B_4d42_9A81_C62B97A89B11"
name="RealKilogram" description="Mass described in the real numerical value of Kilograms."
unit="EAID_A21827D1_48AF_4e25_A534_D2CDAE199D76"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_E10C27FD_D46D_48f8_AD45_1B1B7BAFBBBE"
name="MassMeasurementSystem" description="Inertial mass is a measure of an object's resistance to
changing its state of motion when a force is applied."
measurementSystemAxis="EAID_1B100E6A_9C51_4e2a_A9A7_0DD7B2772F94"
orientation="Values increase as mass increases.">
xmi:id="EAID_2B113B56_BEDB_4c25_8685_7E4F610ACD2B" name="OneKilogramReferencePoint"
description="The minimum amount of weight necessary to keep the measured object from free fall."
landmark="EAID_F5EE0165_F768_43ea_8E46_19F80DA779FF">
xmi:id="EAID_C9B17E5E_5705_4311_A3FC_66FF76EB0BFE"
axis="EAID_1B100E6A_9C51_4e2a_A9A7_0DD7B2772F94" value="0"
valueTypeUnit="EAID_B4409B5D_DA7B_4d42_9A81_C62B97A89B11"/>
</referencePoint>
xmi:id="EAID_FDCBB799_98CE_4a7f_873A_633370C1D5B6" name="ZeroMassReferencePoint"
description="This is the value of the force acting on the object to change its state of motion."
landmark="EAID_894D6C59_4EAA_470a_B61A_D5561C678545">
xmi:id="EAID_BB6C5E54_554A_4c0e_AA0D_856061A0AC49"
axis="EAID_1B100E6A_9C51_4e2a_A9A7_0DD7B2772F94" value="0"
valueTypeUnit="EAID_B4409B5D_DA7B_4d42_9A81_C62B97A89B11"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_1B100E6A_9C51_4e2a_A9A7_0DD7B2772F94"
name="MassMeasurementSystemAxis" description="The measurement system axis describing an objects
resistance to changing its state of motion." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_B4409B5D_DA7B_4d42_9A81_C62B97A89B11"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8D89E667_43D0_40bd_9175_D2444B83B96E"
name="OrientationMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C038CD82_5CA1_459a_B2EC_0285C602DD57"
name="AttitudeMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2599B789_CB20_440f_B297_B743757DDEA6"
name="BodyFrameAttitudeMeasure">
<element xmi:type="logical:Measurement" xmi:id="EAID_71E81CF0_EAF6_44d4_BD02_86707A5FC113"
name="BodyFrameAttitudeMeasurement" description="The measure to describe the attitude of an
aircraft in flight with the relative orientation is body-fixed, with origins moving along with
the aircraft, typically at the center of gravity"
measurementAxis="EAID_D2CAC852_73A3_4aec_9790_9640043C825C
EAID_C3BAB08D_406E_4267_B08C_E97972CB018C EAID_821137A0_2FF0_4ad2_8E68_8EC50128AD03"
measurementSystem="EAID_449F4D2F_6805_4049_BD5B_FA27FD570EEF"
realizes="EAID_AB3FAE18_6F92_4a74_812F_77AF2DCD6F6F"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC"
name="BodyFrameAttitudeMeasurementDegrees" description="The measure to describe the attitude of
an aircraft in flight with the relative orientation is body-fixed, with origins moving along
with the aircraft, typically at the center of gravity"
measurementAxis="EAID_1E4718CF_69A1_459d_B69A_73171E3B4B38
EAID_FAE1C598_8B37_4329_A065_0AEE5E518F65 EAID_C6705DC3_8C55_4de3_A7A6_C7B36A93C5A3"
measurementSystem="EAID_449F4D2F_6805_4049_BD5B_FA27FD570EEF"
realizes="EAID_AB3FAE18_6F92_4a74_812F_77AF2DCD6F6F"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9B4979E6_2648_41b3_B77B_09B193C47BCB"
name="BodyFrameAttiudeLandmark">
<element xmi:type="logical:Landmark" xmi:id="EAID_39753BD3_1FF4_47ca_A367_845117E99553"
name="BodyAttitudeOriginLandmark" description="The point at which the body attitude is aligned
to the local level frame and has no rotation in any of the three axes that originate at the
vehicle center of gravity (longitudinal, lateral, & vertical)."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_913ABE8D_D741_4b8e_AA57_E015677CB52D"
name="BodyAttitudePiOver2RadianLeftRoll" description="The orientation of the body with respect
to the vertical axis (or lateral axis) after a Pi/2 radian rotation along the longitudinal
axis (a roll to left)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_3E7D915F_92BA_4d27_BC1A_52D9915CAFEF"
name="BodyAttitudePiOver4RadianUpPitch" description="The orientation of the body with respect
to the longitudinal (or vertical axis) after a Pi/4 radian rotation along the lateral axis (a
pitch up)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_F8CBB773_7EC3_4cf3_A6BF_322F5E0611A2"
name="BodyAttitudePiOver6RadianLeftYaw" description="The orientation of the body with respect
to the longitudinal axis (or lateral axis) after a -Pi/6 radian rotation along the vertical
axis (a yaw left)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F8D4CE33_D33E_4592_A072_3F5AED57D0CF"
name="BodyFrameMeasurementAxes">
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D2CAC852_73A3_4aec_9790_9640043C825C"
name="BodyFrameMeasurementPitchAxis" description="Pitch Axis (Lateral Axis) passes through the
plane from wingtip to wingtip. Pitch changes the vertical direction the aircraft’s nose is
pointing." precision="0.01" measurementSystemAxis="EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_C3BAB08D_406E_4267_B08C_E97972CB018C"
name="BodyFrameMeasurementRollAxis" description="Roll Axis (Longitudinal Axis) passes through
the plane from nose to tail. Roll changes the orientation of the aircraft’s wings with respect
to the downward force of gravity." precision="0.01"
measurementSystemAxis="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_821137A0_2FF0_4ad2_8E68_8EC50128AD03"
name="BodyFrameMeasurementYawAxis" description="Yaw Axis (Normal Axis) is the vertical axis

through an aircraft, rocket or similar body about which the body yaws." precision="0.01"
measurementSystemAxis="EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_56269F0B_8282_4c19_A244_DC614C031E66"
name="BodyAttitudeMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_449F4D2F_6805_4049_BD5B_FA27FD570EEF"
name="BodyAttitudeMeasurementSystem" description="An attitude measurement system referenced to
local level." measurementSystemAxis="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84
EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5 EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A"
xmi:id="EAID_6E1B977A_72E0_4ab8_B306_536A8C90598D" name="BodyAttitudeOriginReferencePoint"
description="Zero rotation about the longitudinal, lateral and vertical axes."
landmark="EAID_39753BD3_1FF4_47ca_A367_845117E99553">
xmi:id="EAID_EDC548A1_5637_4908_A4D2_0A899EC2956D"
axis="EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A" value="0"
xmi:id="EAID_20EB0A36_5BC1_46ab_A1AD_EDD770324146"
axis="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84" value="0"
xmi:id="EAID_89B80BC4_9CBE_4262_BFC6_AFB517CEA8B6"
axis="EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5" value="0"
</referencePoint>
xmi:id="EAID_E60C87D2_31CD_4b48_B135_BEDAD66FC83F"
name="PiOver2RadianRollLeftReferencePoint" description="-Pi/2 radian rotation along the
longitudinal axis (a roll left)." landmark="EAID_913ABE8D_D741_4b8e_AA57_E015677CB52D">
xmi:id="EAID_E28610F6_BE61_482a_AD1A_0EA1CDA3F273"
axis="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84" value="-Pi/2"
xmi:id="EAID_717C9CCC_69BB_4df5_9A5A_8E733886E968"
xmi:id="EAID_0A4CBA4C_A4C2_44cc_BD81_A0D57E5E5E7A"
</referencePoint>
xmi:id="EAID_08D02DA1_7BF3_48bb_A71F_1B4CFF80BA79"
name="PiOver4RadianPitchUpReferencePoint" description="Pi/4 Radians rotation along the
lateral axis (a pitch up)." landmark="EAID_3E7D915F_92BA_4d27_BC1A_52D9915CAFEF">
xmi:id="EAID_9BDD51F2_B21E_48df_A00E_5BF0A5DF7B40"
axis="EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A" value="Pi/4"
xmi:id="EAID_7AA3C4FB_564D_4029_85D7_6EF0FE9BAD11"
xmi:id="EAID_21776D5C_E4FE_43f0_9D07_1C6499C3E931"
</referencePoint>
xmi:id="EAID_5A69D685_5CB3_456b_9EB5_1362DEC20D73"
name="PiOver6RadianYawLeftReferencePoint" description="-Pi/6 Radians rotation along the
vertical axis ( a yaw left)." landmark="EAID_F8CBB773_7EC3_4cf3_A6BF_322F5E0611A2">
xmi:id="EAID_A6FD8A95_4692_4947_A93B_58B5A5A3D625"
axis="EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5" value="-Pi/6"
xmi:id="EAID_A660FC74_BA5D_4baf_9057_163ED0282462"
xmi:id="EAID_C5187DAA_C4FB_43b0_839F_9BCD601F1C19"
</referencePoint>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A734C35A_5D32_456a_97BD_D2A02279EC6D"
name="BodyFrameMeasurementAxesDegrees">
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_1E4718CF_69A1_459d_B69A_73171E3B4B38"
name="BodyFrameMeasurementPitchDegreesAxis" description="Pitch Axis (Lateral Axis) passes
through the plane from wingtip to wingtip. Pitch changes the vertical direction the aircraft’s
nose is pointing." valueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF" precision="0.01"
measurementSystemAxis="EAID_A4B9B253_9061_4f28_A8F7_89BFA86EE91A"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_FAE1C598_8B37_4329_A065_0AEE5E518F65"
name="BodyFrameMeasurementRollDegreesAxis" description="Roll Axis (Longitudinal Axis) passes
through the plane from nose to tail. Roll changes the orientation of the aircraft’s wings with
respect to the downward force of gravity."
measurementSystemAxis="EAID_309DE716_2AA8_4eb3_A6EA_C0C37AA8CA84"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_C6705DC3_8C55_4de3_A7A6_C7B36A93C5A3"
name="BodyFrameMeasurementYawDegreesAxis" description="Yaw Axis (Normal Axis) is the vertical
axis through an aircraft, rocket or similar body about which the body yaws."
measurementSystemAxis="EAID_1B9ED73D_796D_487c_85CC_15170C5E25E5"
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_85A5AF60_6477_47dc_B465_7159E6A57CD8"
name="EarthFrameAtitude">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_03631913_CE44_4aa5_88D3_63FF2683AF4E"
name="EarthFrameLandmarks"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_0384A349_1EB3_4f7a_80BE_3FEB25F9BC52"
name="EarthFrameMeasurementSystem"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_43008F72_D8DD_4a6b_B144_767CEE45E6F1"
name="CenterOfGravity" description="Orientation measurements based on the Center of Gravity Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_CDBB94DC_6048_422d_BD41_62B7DB15BA49"
name="LocalVehicle" description="Orientation measurements based on the Local Vehicle Reference
Frame."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A02E9E72_52C6_4ebb_A39E_D9FBF4C98149"
name="PositionMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A8094015_98E2_4ffe_AA60_5ED65E11EAED"
name="ECEFPosition">
<element xmi:type="logical:Measurement" xmi:id="_HIqhDQExEeSj3_IywtjKpA"
name="ECEFPositionMeasurement" description="Describes a position in the ECEF measurement system."
measurementAxis="_HIqhDwExEeSj3_IywtjKpA _HIqhEQExEeSj3_IywtjKpA _HIqhEwExEeSj3_IywtjKpA"
measurementSystem="_HIqhBAExEeSj3_IywtjKpA" realizes="EAID_7CA3D9F9_0614_4f82_A971_D2367427403F"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="_HIqhDwExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementXAxis" description="ECEF X axis." precision="0.001"
measurementSystemAxis="_HIqhCAExEeSj3_IywtjKpA"
<element xmi:type="logical:MeasurementAxis" xmi:id="_HIqhEQExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementYAxis" description="ECEF Y axis." precision="0.001"

measurementSystemAxis="_HIqhCgExEeSj3_IywtjKpA"
<element xmi:type="logical:MeasurementAxis" xmi:id="_HIqhEwExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementZAxis" description="ECEF Z axis." precision="0.001"
measurementSystemAxis="_HIqhDAExEeSj3_IywtjKpA"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_3983833B_19EB_4043_B178_CC2879CE171D"
name="ECEFPositionLandmarks">
<element xmi:type="logical:Landmark" xmi:id="_qfQeQAE1EeSj3_IywtjKpA" name="EarthCenter"
description="The center of the Mass of the Earth"/>
<element xmi:type="logical:Landmark" xmi:id="_jDNG8AE2EeSj3_IywtjKpA"
name="PrimeMeridianEquatorSurface" description="Describes the point of Intersection of the prime
meridian, the equator, and the surface of the earth."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C5E533B1_762D_4e2f_B8BA_3B71567F1A0B"
name="ECEFPositionMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="_HIqhBAExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementSystem" description="Describes the Earth-centered, earth-fixed
measurement system." measurementSystemAxis="_HIqhCAExEeSj3_IywtjKpA _HIqhCgExEeSj3_IywtjKpA
_HIqhDAExEeSj3_IywtjKpA" coordinateSystem="EAID_E16B78B2_B2BA_43e5_837E_018DC1FD621C"
externalStandardReference="" orientation="">
<referencePoint xmi:type="logical:ReferencePoint" xmi:id="_o7OfsAE1EeSj3_IywtjKpA"
name="OriginReferencePoint" landmark="_qfQeQAE1EeSj3_IywtjKpA">
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_5ORQYAE1EeSj3_IywtjKpA"
axis="_HIqhCAExEeSj3_IywtjKpA" value="0"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_9Hm5cAE1EeSj3_IywtjKpA"
axis="_HIqhCgExEeSj3_IywtjKpA" value="0"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_9wJgIAE1EeSj3_IywtjKpA"
axis="_HIqhDAExEeSj3_IywtjKpA" value="0"/>
</referencePoint>
<referencePoint xmi:type="logical:ReferencePoint" xmi:id="_Ukc-YAE2EeSj3_IywtjKpA"
name="PrimeMeridianEquatorSurfaceReferencePoint" description="Describes the point of
Intersection of the prime meridian, the equator, and the surface of the earth."
landmark="_jDNG8AE2EeSj3_IywtjKpA">
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_xCHR0AE2EeSj3_IywtjKpA"
axis="_HIqhCAExEeSj3_IywtjKpA" value="Earths Surface"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_xlvjUAE2EeSj3_IywtjKpA"
axis="_HIqhCgExEeSj3_IywtjKpA" value="0"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_yHm6QAE2EeSj3_IywtjKpA"
axis="_HIqhDAExEeSj3_IywtjKpA" value="0"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_HIqhCAExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementSystemXAxis" description="Specifies a link to the ECEF X
measurement system axis." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="_vZiY3wg5EeSFspy8Kj3F4Q"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_HIqhCgExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementSystemYAxis" description="Specifies a link to the ECEF Y
measurement system axis." axis="EAID_185CD9A8_B677_41ab_907D_C7F232756DCE"
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_HIqhDAExEeSj3_IywtjKpA"
name="ECEFPositionMeasurementSystemZAxis" description="Specifies a link to the ECEF Z
measurement system axis." axis="EAID_C74601C9_0E7A_483b_AD4C_28D64BE141E3"
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2CEE700F_27AB_4056_856C_90231AC3B071"
name="WGS84Position">
<element xmi:type="logical:Measurement" xmi:id="_vZiY3Ag5EeSFspy8Kj3F4Q"
name="WGS84PositionMeasurement" description="Describes a location relative to the WGS-84 frame of
reference." measurementAxis="_vZiY4Ag5EeSFspy8Kj3F4Q _vZiY4wg5EeSFspy8Kj3F4Q
_vZiY5Ag5EeSFspy8Kj3F4Q" measurementSystem="_vZiY2Ag5EeSFspy8Kj3F4Q"
realizes="EAID_7CA3D9F9_0614_4f82_A971_D2367427403F"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="_vZiY4Ag5EeSFspy8Kj3F4Q"
name="WGS84PositionHeightMeasurementAxis" description="Specifies the height component of location."
precision="0.000001" measurementSystemAxis="_vZiY2Qg5EeSFspy8Kj3F4Q"
<element xmi:type="logical:MeasurementAxis" xmi:id="_vZiY4wg5EeSFspy8Kj3F4Q"
name="WGS84PositionLatitudeMeasurementAxis" description="Specifies the latitude component of
location." precision="0.000001" measurementSystemAxis="_vZiY2gg5EeSFspy8Kj3F4Q"
<element xmi:type="logical:MeasurementAxis" xmi:id="_vZiY5Ag5EeSFspy8Kj3F4Q"
name="WGS84PositionLongitudeMeasurementAxis" description="Specifies the longitude component of
location." precision="0.000001" measurementSystemAxis="_vZiY2wg5EeSFspy8Kj3F4Q"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_520D39E0_B7F5_4946_A25B_023F5682F4F2"
name="WGS84PositionMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="_vZiY3wg5EeSFspy8Kj3F4Q" name="RealMeters"
description="Meters representation as a Real" unit="EAID_0A9F29A7_3ABC_4790_9E6D_CEBD6C7DBE5E"
<element xmi:type="logical:MeasurementSystem" xmi:id="_vZiY2Ag5EeSFspy8Kj3F4Q"
name="WGS84PositionMeasurementSystem" description="Describes the WGS84 Frame of Reference in
terms of coordinate system, origin, and axis orientation."
measurementSystemAxis="_vZiY2Qg5EeSFspy8Kj3F4Q _vZiY2gg5EeSFspy8Kj3F4Q _vZiY2wg5EeSFspy8Kj3F4Q"
coordinateSystem="_vZiY1wg5EeSFspy8Kj3F4Q" externalStandardReference="Reference: http://earth-
info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf
DEPARTMENT OF DEFENSE WORLD GEODETIC
SYSTEM 1984 Its Definition and Relationships with Local Geodetic Systems" orientation="right-
handed orthogonal">
<referencePoint xmi:type="logical:ReferencePoint" xmi:id="_LPRUIAg7EeSFspy8Kj3F4Q"
name="EarthCenter" description="Earths Center of Mass" landmark="_qfQeQAE1EeSj3_IywtjKpA">
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_WU1TUAg7EeSFspy8Kj3F4Q"
axis="_vZiY2Qg5EeSFspy8Kj3F4Q" value="Earths Center of mass (-height)"
valueTypeUnit="_vZiY3wg5EeSFspy8Kj3F4Q"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_Xq1c8Ag7EeSFspy8Kj3F4Q"
axis="_vZiY2gg5EeSFspy8Kj3F4Q" value="0"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_XACMcAg7EeSFspy8Kj3F4Q"
axis="_vZiY2wg5EeSFspy8Kj3F4Q" value="0"/>
</referencePoint>
<referencePoint xmi:type="logical:ReferencePoint" xmi:id="_SvmAEAg9EeSFspy8Kj3F4Q"
name="PrimeMeridianEquatorSurface" description="Describes the point of Intersection of the
prime meridian, the equator, and the surface of the earth."
landmark="_jDNG8AE2EeSj3_IywtjKpA">
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_XQ8EUAg9EeSFspy8Kj3F4Q"
axis="_vZiY2Qg5EeSFspy8Kj3F4Q" value="0" valueTypeUnit="_vZiY3wg5EeSFspy8Kj3F4Q"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_XQ8EUQg9EeSFspy8Kj3F4Q"
axis="_vZiY2gg5EeSFspy8Kj3F4Q" value="0"/>
<referencePointPart xmi:type="logical:ReferencePointPart" xmi:id="_XQ8EUgg9EeSFspy8Kj3F4Q"
axis="_vZiY2wg5EeSFspy8Kj3F4Q" value="0"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_vZiY2Qg5EeSFspy8Kj3F4Q"
name="WGS84PositionMeasurementSystemHeightAxis" description="Specifies the height axis for WGS-
84." axis="_vZiY1Qg5EeSFspy8Kj3F4Q" defaultValueTypeUnit="_vZiY3wg5EeSFspy8Kj3F4Q"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_vZiY2gg5EeSFspy8Kj3F4Q"
name="WGS84PositionMeasurementSystemLatitudeAxis" description="Specifies the latitude axis for
WGS-84." axis="_vZiY1Ag5EeSFspy8Kj3F4Q"
defaultValueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF"/>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="_vZiY2wg5EeSFspy8Kj3F4Q"
name="WGS84PositionMeasurementSystemLongitudeAxis" description="Specifies the longitude axis for
WGS-84." axis="_vZiY1gg5EeSFspy8Kj3F4Q"
defaultValueTypeUnit="EAID_C5AE86FF_FB90_4d95_A739_4025CA644CDF"/>
</ldm>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_16C3F0D3_66F4_4482_814F_DD6029B51906"
name="PowerMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_F2DF1196_40EB_41a4_AC09_72D6A55D3C4F"
name="PowerMeasurement" description="Measurement for power."
measurementAxis="EAID_2B1F4E67_0284_4990_9F3F_37C03457F75E"
measurementSystem="EAID_AC33E859_EF4E_4f9e_B9F1_9E8EFA9D1497"
realizes="EAID_0FE1D4CF_7DB9_46c2_961B_2C3AB44B694F"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_2B1F4E67_0284_4990_9F3F_37C03457F75E"
name="PowerMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_E60055A6_AAF7_4b15_9B96_2E85E42CB36A"
realizes="EAID_0FE1D4CF_7DB9_46c2_961B_2C3AB44B694F"/>

<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8A972E2D_AD23_4489_BC11_B5F08ABD3612"
name="PowerLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_6B2B9037_EBBE_44ea_B0D3_1A9DA3542A18"
name="OneWattPowerLandmark" description="Landmark for 1 Watt of power"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_8D7C54F8_850B_443a_8875_DDA859EDDF8E"
name="ZeroPowerLandmark" description="Zero Watts of Power Landmark"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_7FDBB961_78D3_460a_8AF9_8D80A56C8176"
name="PowerMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_5F476114_19FC_45df_B348_DE6F26145C2D"
name="RealWatts" description="Watts as a non-negative real numerical representation."
unit="EAID_ACAA2155_27C3_4a8d_9F84_17451EC9DE42"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_AC33E859_EF4E_4f9e_B9F1_9E8EFA9D1497"
name="PowerMeasurementSystem" description="Measurement system for power measurements."
measurementSystemAxis="EAID_E60055A6_AAF7_4b15_9B96_2E85E42CB36A"
orientation="Values increase as power increases.">
xmi:id="EAID_7339EEA0_71EF_41b1_83BB_E100EB114AA0" name="ZeroPowerReferencePoint"
description="Reference point for zero power"
landmark="EAID_8D7C54F8_850B_443a_8875_DDA859EDDF8E">
xmi:id="EAID_FE80FA6F_6444_4bce_A8F9_1FD2601E8044"
axis="EAID_E60055A6_AAF7_4b15_9B96_2E85E42CB36A" value="0.0"
valueTypeUnit="EAID_5F476114_19FC_45df_B348_DE6F26145C2D"/>
</referencePoint>
xmi:id="EAID_B192F6E9_5EB8_466e_A1A1_3F8CB39EB23B" name="OneWattPowerReferencePoint"
description="Reference point for 1 Watt of power"
landmark="EAID_6B2B9037_EBBE_44ea_B0D3_1A9DA3542A18">
xmi:id="EAID_8712F59A_B2F4_41bf_8F9A_6569B0263D72"
axis="EAID_E60055A6_AAF7_4b15_9B96_2E85E42CB36A" value="1.0"
valueTypeUnit="EAID_5F476114_19FC_45df_B348_DE6F26145C2D"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_E60055A6_AAF7_4b15_9B96_2E85E42CB36A"
name="PowerMeasurementSystemAxis" description="Measurement system axis for power measurements."
defaultValueTypeUnit="EAID_5F476114_19FC_45df_B348_DE6F26145C2D">
xmi:id="EAID_18C4F8C1_7952_4aaa_BAA0_FF61DC3CB5FD" constraintText="Always >= 0"/>
</element>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C18C07A4_CB5D_4587_8803_C13190D7BAB5"
name="PressureMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_CFA82AAB_E3FA_463d_8928_F13C9347D8A0"
name="PressureMeasurement" description="Measurement for pressure."
measurementAxis="EAID_694D6BFB_F390_4072_960B_AFBC983A647F"
measurementSystem="EAID_FE7D5B8A_FF57_4418_A928_E78D52681907"
realizes="EAID_54D14004_BB23_4f72_95FB_9FF384A743A7"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_694D6BFB_F390_4072_960B_AFBC983A647F"
name="PressureMeasurementAxis" precision="0.001"
measurementSystemAxis="EAID_3DE8B358_7FA3_4f96_AEF9_B36F9DCC3E6E"
realizes="EAID_54D14004_BB23_4f72_95FB_9FF384A743A7"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_0311A086_04D9_4342_BDF1_7EB23855EB7E"
name="PressureLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_CF1128BC_C286_4666_BAD7_F91AD3BA58FC"
name="OnePascalLandmark" description="Force of 1 N per square meter"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_5E2A754E_190C_41fb_92DA_1C9627E027DA"
name="ZeroPressureLandmark" description="Zero pressure"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AF15887F_BE6E_4707_BC6A_5A7503505584"
name="PressureMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_19E866E6_D186_469f_8670_97CDF785C2D9"
name="RealPascal" description="Pascal as a real numerical representation."
unit="EAID_9CDA2125_1689_411c_AC85_04287E8FC3CE"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_FE7D5B8A_FF57_4418_A928_E78D52681907"
name="PressureMeasurementSystem" description="Measurement system for pressure."
measurementSystemAxis="EAID_3DE8B358_7FA3_4f96_AEF9_B36F9DCC3E6E"
orientation="Value increases as pressure increases">
xmi:id="EAID_BE496D32_F9EA_4203_8E96_0BF7EB86FE21" name="ZeroPressureReferencePoint"
description="zero pressure reference point"
landmark="EAID_5E2A754E_190C_41fb_92DA_1C9627E027DA">
xmi:id="EAID_57D96CF0_5037_4ac5_9A84_2FA8560A2B49"
axis="EAID_3DE8B358_7FA3_4f96_AEF9_B36F9DCC3E6E" value="0.0"
valueTypeUnit="EAID_19E866E6_D186_469f_8670_97CDF785C2D9"/>
</referencePoint>
xmi:id="EAID_3CC8A464_0727_4da4_83C3_E28FC922F77F" name="OnePascalReferencePoint"
description="unit amount of pressure" landmark="EAID_CF1128BC_C286_4666_BAD7_F91AD3BA58FC">
xmi:id="EAID_D508BF70_60B3_4d29_B305_ED4D0587ABC8"
axis="EAID_3DE8B358_7FA3_4f96_AEF9_B36F9DCC3E6E" value="1.0"
valueTypeUnit="EAID_19E866E6_D186_469f_8670_97CDF785C2D9"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_3DE8B358_7FA3_4f96_AEF9_B36F9DCC3E6E"
name="PressureMeasurementSystemAxis" description="measurement axis for pressure"
defaultValueTypeUnit="EAID_19E866E6_D186_469f_8670_97CDF785C2D9"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E97DCBEF_91E8_4511_8334_4BF8F1476CEA"
name="LocalAir" description="Pressure measurements based on the Local Air Reference Frame."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_3FE463AE_0E83_4e93_8E97_443FFEF54796"
name="RateMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_8C5A362E_D672_4335_B72E_C2CC6252F884"
name="SpeedMeasurement" description="Measurement for speed."
measurementAxis="EAID_FA94A385_E790_4ab7_965F_D81D542D69F9"
measurementSystem="EAID_CA7165EF_5605_49ab_8B6F_24B78C4842AF"
realizes="EAID_06B460A8_5CEC_4e63_9607_4413DB527E37"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_FA94A385_E790_4ab7_965F_D81D542D69F9"
name="SpeedMeasurementAxis" precision="0.0001"
measurementSystemAxis="EAID_34208C77_1C32_4838_89B7_FC6777140322"
realizes="EAID_06B460A8_5CEC_4e63_9607_4413DB527E37"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4F6B65DC_D0F5_4997_B653_D3E8BF595D9B"
name="AngularAcceleration">
<element xmi:type="logical:Measurement" xmi:id="EAID_15163722_EC03_48fc_BD03_A4303213DCC5"
name="AngularAccelerationMeasurement" description="Measurement for values of angular acceleration."
measurementAxis="EAID_F8F45C73_9387_4734_94DC_24DDADF11AF2"
measurementSystem="EAID_20463F5D_4D0E_4f2f_917D_A96A001118FC"
realizes="EAID_E0FD8349_12D2_40aa_9131_1FF4BA823E26"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_F8F45C73_9387_4734_94DC_24DDADF11AF2"
name="AngularAccelerationMeasurementAxis" description="Measurement axis for values of angular
acceleration." precision="0.001" measurementSystemAxis="EAID_4178F53A_5F5A_45a3_B674_461B48DA2C25"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B715C26A_2294_4470_BD10_E657D1177AAC"
name="AngularAccelerationLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_D2BEEBE6_6083_41a1_A2D1_218FFEB94D37"
name="PiRadiansPerSecondPerSecondAngularAccelerationLandmark" description="Landmark for Pi
radians per second per second."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_00FDA1C5_DB08_435d_B0B5_3EB09EB42534"
name="ZeroAngularAccelerationLandmark" description="Landmark for zero angular acceleration."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E8ACE295_224A_4a91_BD1F_214E6361B3AA"
name="AngularAccelerationMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_8AB5E4C7_4D23_411d_B40D_01DD8CDD2525"
name="RealRadiansPerSecondPerSecond" description="Real radians per second per second."

unit="EAID_F2444AAF_68C5_4355_8AB0_5BFC0A73975F"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_20463F5D_4D0E_4f2f_917D_A96A001118FC"
name="AngularAccelerationMeasurementSystem" description="Measurement system for values of
angular acceleration." measurementSystemAxis="EAID_4178F53A_5F5A_45a3_B674_461B48DA2C25"
orientation="Values increase as angular acceleration increases.">
xmi:id="EAID_F8285533_7BAB_456b_A304_E9C5E22CF507"
name="ZeroAngularAccelerationReferencePoint" description="Reference point for a zero angular
acceleration." landmark="EAID_00FDA1C5_DB08_435d_B0B5_3EB09EB42534">
xmi:id="EAID_00ED9EDA_372A_4b04_A8B8_5074264039D0"
axis="EAID_4178F53A_5F5A_45a3_B674_461B48DA2C25" value="0.0"
valueTypeUnit="EAID_8AB5E4C7_4D23_411d_B40D_01DD8CDD2525"/>
</referencePoint>
xmi:id="EAID_64484363_074D_415d_8B91_01830C2E288A"
name="PiRadiansPerSecondPerSecondReferencePoint" description="Reference point for Pi radians
per second/second angular acceleration." landmark="EAID_D2BEEBE6_6083_41a1_A2D1_218FFEB94D37">
xmi:id="EAID_C420B85B_F89E_4208_8B0D_BCEC3FB42C45"
axis="EAID_4178F53A_5F5A_45a3_B674_461B48DA2C25" value="3.1415927"
valueTypeUnit="EAID_8AB5E4C7_4D23_411d_B40D_01DD8CDD2525"/>
</referencePoint>
</element>
xmi:id="EAID_4178F53A_5F5A_45a3_B674_461B48DA2C25"
name="AngularAccelerationMeasurementSystemAxis" description="Measurement system axis for values
of angular acceleration." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_8AB5E4C7_4D23_411d_B40D_01DD8CDD2525"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A720B675_477C_4ab5_96CD_B90229728579"
name="AngularVelociity">
<element xmi:type="logical:Measurement" xmi:id="EAID_00FEAF10_F102_46d1_9F47_15EAB262F4A1"
name="AngularVelocityMeasurement" description="Measurement for expressing values of angular rate in
radians per second." measurementAxis="EAID_9820B35F_7801_45a3_AF38_A8DCC094C8ED"
measurementSystem="EAID_2CC7D8B4_09A7_4c7f_8066_A2D51355D1FE"
realizes="EAID_21309243_2D0E_4536_8135_69F86BE3D515"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9820B35F_7801_45a3_AF38_A8DCC094C8ED"
name="AngularVelocityMeasurementAxis" description="Measurement axis for expressing values of
angular rate." precision="0.001" measurementSystemAxis="EAID_89BC6B2D_8DE0_4dde_AC7C_66F795A553C2"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BC319A47_C930_4249_8D89_61D5085B1756"
name="AngularVelocityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_C33668AC_6B16_4868_B8DF_EFCD6DF0F440"
name="PiRadiansPerSecondAngularVelocityLandmark" description="Landmark indicating an angular
rate of Pi radians per second."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_3D64786C_A7B2_496d_818E_3D426333E4B7"
name="ZeroAngularVelocityLandmark" description="Angular velocity landmark representing a zero
angluar velocity (i.e., no rotation)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_25B92824_DA70_48aa_8813_9E761AF322C8"
name="AngularVelocityMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_7C107E2B_CDC3_4f2f_86AD_DBEC40A0C0E3"
name="RealRadiansPerSecondValuetypeUnit" description="Value type unit for real radians per
second." unit="EAID_C21F5F62_131A_4807_894F_A58BF924B164"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_2CC7D8B4_09A7_4c7f_8066_A2D51355D1FE"
name="AngularVelociityMeasurementSystem" description="Measurement system for expressing values
of angular velocity." measurementSystemAxis="EAID_89BC6B2D_8DE0_4dde_AC7C_66F795A553C2"
orientation="Angular rate increases as value increase.">
xmi:id="EAID_E8A8690E_BD6E_4b1d_9BA5_9B9A75952D48" name="ZeroAngularVelocityReferencePoint"
description="Reference point for zero radians per second (no rotation)"
landmark="EAID_3D64786C_A7B2_496d_818E_3D426333E4B7">
xmi:id="EAID_B3DD7932_FC3F_4445_9D0E_5743C99FECCA"
axis="EAID_89BC6B2D_8DE0_4dde_AC7C_66F795A553C2" value="0.0"
valueTypeUnit="EAID_7C107E2B_CDC3_4f2f_86AD_DBEC40A0C0E3"/>
</referencePoint>
xmi:id="EAID_162DFA87_A40D_419f_8119_29AF0BDC65AF"
name="PiRadiansPerSecondAngularVelocityReferencePoint" description="Reference point for pi
radians per second." landmark="EAID_C33668AC_6B16_4868_B8DF_EFCD6DF0F440">
xmi:id="EAID_5D2C477B_3CC0_4e30_B5E5_F4C821ACC9C0"
axis="EAID_89BC6B2D_8DE0_4dde_AC7C_66F795A553C2" value="3.1415927"
valueTypeUnit="EAID_7C107E2B_CDC3_4f2f_86AD_DBEC40A0C0E3"/>
</referencePoint>
</element>
xmi:id="EAID_89BC6B2D_8DE0_4dde_AC7C_66F795A553C2" name="AngularVelociityMeasurementSystemAxis"
description="Measurement system axis used to express values of angular rate."
defaultValueTypeUnit="EAID_7C107E2B_CDC3_4f2f_86AD_DBEC40A0C0E3"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5B1DC97A_BC16_4e20_AA26_D17043A737D5"
name="OrientationAcceleration" description="Logical model representing the rate of orientation
acceleration measurement">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_880C3557_FFFE_4dfc_AE15_C94E41EB8931"
name="OrientationAccelerationLandmarks" description="Logical package to capture orientation
acceleration landmarks elements.">
<element xmi:type="logical:Landmark" xmi:id="EAID_ABE2EA4A_7F83_4b9e_817F_592893C43816"
name="AxialForcePiOver4RadianUpPitchAxis" description="Net force in the positive x-direction
(Lateral Axis/PitchAxis) to create an angle Pi/4 radians in the up direction"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_8F4761A5_A3AE_468f_B499_319860B64B8D"
name="NormalForcePiOver6RadianLeftYawAxis" description="Net force in positive z-direction
(Vertical Axis/Yaw Axis) to create a Pi/6 radians angle in the negative direction"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_0F69C644_7864_4e70_9C0C_97365921347E"
name="SideForcePiOver2RaidanRightRollAxis" description="Net force in positive y-direction
(Longitudinal Axis/Roll Axis) to create a Pi/2 radians angle in the positive direction."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_FEB346B7_0463_40ca_BDEF_CC2F44B8CF5A"
name="ZeroRotationalAcceleration" description="No rotation about any axis due to external forces
on an object."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D7B238E2_71E3_4e71_A259_E98A96FF49DB"
name="OrientationAccelerationMeasurement" description="Root package orientation acceleration in
radians.">
<element xmi:type="logical:Measurement" xmi:id="EAID_33B19387_B68E_4b45_8CE2_0A0BACE6F94F"
name="OrientationAccelerationMeasurement" description="Measurement representing the acceleration
applied to the orientation angles: pitch, roll and yaw"
measurementAxis="EAID_F8FC376A_2D5B_45a8_9C61_76AF25616387
EAID_D22FA4DD_BE4B_4a7f_BE0B_3863D495D7E3 EAID_3DF79A56_B732_4042_A1C6_F54295C8FB16"
measurementSystem="EAID_C0798AAE_A69A_44b5_AEE1_2AA620670786"
realizes="EAID_6A475A9C_9D31_4f7e_92EF_2D00DE6F7E66"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_F8FC376A_2D5B_45a8_9C61_76AF25616387"
name="OrientationAccelerationPitchAxis" description="Pitch Axis (Lateral Axis) passes through
the plane from wingtip to wingtip. Pitch changes the vertical direction the aircraft’s nose is
pointing." precision="0.0001" measurementSystemAxis="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D22FA4DD_BE4B_4a7f_BE0B_3863D495D7E3"
name="OrientationAccelerationRollAxis" description="Roll Axis (Longitudinal Axis) passes through
the plane from nose to tail. Roll changes the orientation of the aircraft’s wings with respect
to the downward force of gravity." precision="0.0001"
measurementSystemAxis="EAID_B735596A_CC53_4799_99A1_48A8D7846841"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_3DF79A56_B732_4042_A1C6_F54295C8FB16"
name="OrientationAccelerationYawAxis" description="Yaw Axis (Normal Axis) is the vertical axis
measurementSystemAxis="EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21"
</ldm>

<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F117C1EF_7A91_463e_AB01_91A2B78A13CE"
name="OrientationAccelerationMeasurementDegreesPerSecondSquared" description="Root package
orientation acceleration in degrees.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_06E92ADA_7777_4544_965E_B598909369E6"
name="RealDegreesPerSecondPerSecond" description="Orientation acceleration in degrees per second
squared as a real numerical representation." unit="EAID_8864E77B_D4D8_4491_8145_285B1F8959A2"
<element xmi:type="logical:Measurement" xmi:id="EAID_D1495FA0_51A7_4150_A858_5B0B45C69E6E"
name="OrientationAccelerationMeasurementDegreesPerSecondPerSecond" description="Measurement
representing the acceleration applied to the orientation angles: pitch, roll and yaw"
measurementAxis="EAID_95FF0623_8CCB_4996_AE16_329764E57003
EAID_D5B63EB9_052F_4b9c_9227_BE582BAD2B9D EAID_ACD9769F_0596_4877_9597_E34387B7B43E"
measurementSystem="EAID_C0798AAE_A69A_44b5_AEE1_2AA620670786"
realizes="EAID_6A475A9C_9D31_4f7e_92EF_2D00DE6F7E66"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_95FF0623_8CCB_4996_AE16_329764E57003"
name="OrientationAccelerationPitchAxisDegreesPerSecondPerSecond" description="Pitch Axis
(Lateral Axis) passes through the plane from wingtip to wingtip. Pitch changes the vertical
direction the aircraft’s nose is pointing."
valueTypeUnit="EAID_06E92ADA_7777_4544_965E_B598909369E6" precision="0.0001"
measurementSystemAxis="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_D5B63EB9_052F_4b9c_9227_BE582BAD2B9D"
name="OrientationAccelerationRollAxisDegreesPerSecondPerSecond" description="Roll Axis
(Longitudinal Axis) passes through the plane from nose to tail. Roll changes the orientation of
the aircraft’s wings with respect to the downward force of gravity."
valueTypeUnit="EAID_06E92ADA_7777_4544_965E_B598909369E6" precision="0.0001"
measurementSystemAxis="EAID_B735596A_CC53_4799_99A1_48A8D7846841"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_ACD9769F_0596_4877_9597_E34387B7B43E"
name="OrientationAccelerationYawAxisDegreesPerSecondPerSecond" description="Yaw Axis (Normal
Axis) is the vertical axis through an aircraft, rocket or similar body about which the body
yaws." valueTypeUnit="EAID_06E92ADA_7777_4544_965E_B598909369E6" precision="0.0001"
measurementSystemAxis="EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_16A44413_1469_46bd_BA9F_9280B514D1B4"
name="OrientationAccelerationMeasurementSystem" description="Logical package to capture orientation
acceleration measurement system elements.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D2F368C7_B356_4229_B15D_89F2E1A76DC7"
name="RealRadiansPerSecondSquared" description="Orientation acceleration in radians per second
squared as a real numerical representation." unit="EAID_F2444AAF_68C5_4355_8AB0_5BFC0A73975F"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_C0798AAE_A69A_44b5_AEE1_2AA620670786"
name="OrientationAccelerationMeasurementSystem" description="Measurement system representing the
rate change of acceleration applied to the orientation angles: pitch, roll and yaw"
measurementSystemAxis="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583
EAID_B735596A_CC53_4799_99A1_48A8D7846841 EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21"
xmi:id="EAID_F6D7F8E4_C0F8_47c7_ADA6_C220FBB4BDCD" name="PitchMomentPoint" description="A
pitching moment is a vertical force applied at a distance forward or aft from the center of
gravity of the aircraft, that causes it to undergo angular acceleration about its laterial
axis. " landmark="EAID_ABE2EA4A_7F83_4b9e_817F_592893C43816">
xmi:id="EAID_2F4D0F41_22ED_474c_9560_23CFDF3E89A0"
axis="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583" value="Pi/4"
valueTypeUnit="EAID_D2F368C7_B356_4229_B15D_89F2E1A76DC7"/>
xmi:id="EAID_EB8C9772_2564_438d_AD85_28326A3FFC1A"
axis="EAID_B735596A_CC53_4799_99A1_48A8D7846841" value="0"
xmi:id="EAID_52330337_35F8_4c13_B601_39653319EBD0"
axis="EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21" value="0"
</referencePoint>
xmi:id="EAID_489E8E99_D971_4523_82A1_531645182D07" name="RollMomentPoint" description="A roll
moment is the vertical force applied at a distance from an aircraft's center of mass that
causes the aircraft to undergo angular acceleration about its longitudinal axis. "
landmark="EAID_0F69C644_7864_4e70_9C0C_97365921347E">
xmi:id="EAID_EDA4F4BE_0900_45f7_BBA7_854EE53B54A9"
axis="EAID_B735596A_CC53_4799_99A1_48A8D7846841" value="-Pi/2"
xmi:id="EAID_53E6F3C4_3645_4251_89A0_A1B6CA78783C"
axis="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583" value="0"
xmi:id="EAID_F560F233_CE7E_41fe_9F57_92B1BD8FE655"
</referencePoint>
xmi:id="EAID_BEFAC062_6355_4715_983F_5968C835270F" name="YawMomentPoint" description="A yaw
moment is a horizontal force applied to rotate an airplane about its vertical aixs, with a
rotation to the right considered positiive and rotation to the left as negative."
landmark="EAID_8F4761A5_A3AE_468f_B499_319860B64B8D">
xmi:id="EAID_E7F60801_8515_4c7a_A37E_36E713168C8B"
axis="EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21" value="-Pi/6"
xmi:id="EAID_7C4874E4_8E28_46fb_B466_09FBBD80A9F2"
xmi:id="EAID_53957466_7975_4111_A0F0_367A0685CB0D"
</referencePoint>
xmi:id="EAID_0E9282DC_C8CD_4d3e_8244_5F9ABC152DA6" name="MassMomentOfInertia"
description="Measures the extent to which an object resists rotational acceleration about an
axis." landmark="EAID_FEB346B7_0463_40ca_BDEF_CC2F44B8CF5A">
xmi:id="EAID_61B7B684_2BE1_4142_ABE0_203BD2B7FDAC"
xmi:id="EAID_E571F250_8452_40e3_B92A_EC0F26E57305"
xmi:id="EAID_483AC7FE_8D99_400a_B71D_5098AD6DD0B0"
</referencePoint>
</element>
xmi:id="EAID_D1088725_2FE5_41e1_8EE4_3A5867309583" name="OrientationAccelerationLateralAxis"
description="Change of orientation acceleration about the lateral axis."
defaultValueTypeUnit="EAID_D2F368C7_B356_4229_B15D_89F2E1A76DC7"/>
xmi:id="EAID_B735596A_CC53_4799_99A1_48A8D7846841"
name="OrientationAccelerationLongitudinalAxis" description="Change of orientation accelertion
about the longitudinal axis." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
xmi:id="EAID_394EB610_0E99_47a3_B0D7_9F458AD50B21" name="OrientationAccelerationVeriticalAxis"
description="Change of orientation acceleration about the veritical axis."

</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D72C0C6D_B00D_4eef_A0F5_1499AB0EE11C"
name="OrientationVelocity" description="Logical model representing the rate of acceleration velocity
measurement.">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_0DDD5E4F_E9D5_48bb_A2B7_1FC0A54377FC"
name="OrientationVelocityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_874C6C78_DAD9_4ef9_8CBE_6213F4FA5252"
name="NeutralChangeRate" description="Rate of change in orientation is non-existant."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_6A77CF2F_C9B8_47e5_BF5B_6B243F14AAB6"
name="PiOver2RadianRightRollRate" description="Velocity Rate required to change the roll angle
of orientation pi/2 radians right."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_37236D77_26DF_45fd_B528_88F78467EE4C"
name="PiOver4RadianUpPitchRate" description="Velocity Rate required to change the pitch angle of
orientation Pi/4 radians up."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_EF97A4DA_ED5B_4704_B17D_2A4FA62603C6"
name="PiOver6RadianLeftYawRate" description="Velocity Rate required to change the roll angle of
orientation Pi/6 radians left."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5125DD20_87B4_48da_A40C_C868ABB44798"
name="OrientationVelocityMeasurement">
<element xmi:type="logical:Measurement" xmi:id="EAID_9833ED39_D532_4c00_AE09_3F2E0D7D92E8"
name="OrientationVelocityMeasurement" description="Measurement representing the velocity applied
to the orientation angles: pitch, roll and yaw"
measurementAxis="EAID_A51D17A7_BB17_4ad6_A1A6_768845DA49D8
EAID_311A63BC_E7C6_4bd7_B2F5_CEE6948EBD1F EAID_BA8FDD80_1C31_4b7d_8321_CE5EF0D3B427"
measurementSystem="EAID_B0F6E3C3_4CA7_44fa_93FD_C211F4F956B0"
realizes="EAID_8A6BA64A_0232_41e4_AA18_CD71B80A66DC"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_A51D17A7_BB17_4ad6_A1A6_768845DA49D8"
name="OrientationVelocityPitchAxis" description="sses through the plane from wingtip to wingtip.
Pitch changes the vertical direction the aircraft’s nose is pointing." precision="0.000001"
measurementSystemAxis="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_311A63BC_E7C6_4bd7_B2F5_CEE6948EBD1F"
name="OrientationVelocityRollAxis" description="Roll Axis (Longitudinal Axis) passes through the
plane from nose to tail. Roll changes the orientation of the aircraft’s wings with respect to
the downward force of gravity." precision="0.000001"
measurementSystemAxis="EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_BA8FDD80_1C31_4b7d_8321_CE5EF0D3B427"
name="OrientationVelocityYawAxis" description="Yaw Axis (Normal Axis) is the vertical axis
measurementSystemAxis="EAID_48607400_E718_4ac3_ACC8_78052AA684CB"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5A8EF8A4_50A4_4171_A3F5_1B751E78BDB8"
name="OrientationVelocityMeasurementDegreesPerSecond">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_B153F0A8_254B_414d_B9B4_F51B02D32419"
name="RealDegreesPerSecond" description="Orientation velocity in radians per second as a real
numerical representation." unit="EAID_D0BB71A9_1DA4_4b42_B20F_1DA918A74312"
<element xmi:type="logical:Measurement" xmi:id="EAID_C1B6A2C8_0039_4525_B633_4477709A79AB"
name="OrientationVelocityMeasurementDegreesPerSecond" description="Measurement representing the
velocity applied to the orientation angles: pitch, roll and yaw"
measurementAxis="EAID_5C38BF81_64CA_4891_9B5D_ADC5367D2220
EAID_18E2FD63_A85D_496e_BB38_F6CC03F5E3F9 EAID_214A281F_382B_483b_87C4_9DF9EA6BA97E"
measurementSystem="EAID_B0F6E3C3_4CA7_44fa_93FD_C211F4F956B0"
realizes="EAID_8A6BA64A_0232_41e4_AA18_CD71B80A66DC"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_5C38BF81_64CA_4891_9B5D_ADC5367D2220"
name="OrientationVelocityPitchAxisDegreesPerSecond" description="sses through the plane from
wingtip to wingtip. Pitch changes the vertical direction the aircraft’s nose is pointing."
valueTypeUnit="EAID_B153F0A8_254B_414d_B9B4_F51B02D32419" precision="0.0001"
measurementSystemAxis="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_18E2FD63_A85D_496e_BB38_F6CC03F5E3F9"
name="OrientationVelocityRollAxisDegreesPerSecond" description="Roll Axis (Longitudinal Axis)
passes through the plane from nose to tail. Roll changes the orientation of the aircraft’s wings
with respect to the downward force of gravity."
measurementSystemAxis="EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_214A281F_382B_483b_87C4_9DF9EA6BA97E"
name="OrientationVelocityYawAxisDegreesPerSecond" description="Yaw Axis (Normal Axis) is the
vertical axis through an aircraft, rocket or similar body about which the body yaws."
measurementSystemAxis="EAID_48607400_E718_4ac3_ACC8_78052AA684CB"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_12F876C2_E11E_4f1d_9C11_037BEB2FD997"
name="OrientationVelocityMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_222F7273_01B5_4e83_B616_DFEC1E04ABED"
name="RealRadianPerSecond" description="Orientation velocity in radians per second as a real
numerical representation." unit="EAID_C21F5F62_131A_4807_894F_A58BF924B164"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_B0F6E3C3_4CA7_44fa_93FD_C211F4F956B0"
name="OrientationVelocityMeasurementSystem" description="Measurement system representing the
rate change of velocity applied to the orientation angles: pitch, roll and yaw"
measurementSystemAxis="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90
EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D EAID_48607400_E718_4ac3_ACC8_78052AA684CB"
xmi:id="EAID_5422D41E_2CF8_4d14_8F11_BB6DF0421437" name="YawRatePoint" description="Represents
the change of 20 degrees in yaw angle resulting the necessary change in velocity rate."
landmark="EAID_EF97A4DA_ED5B_4704_B17D_2A4FA62603C6">
xmi:id="EAID_8FC47AC2_AF60_487b_82EF_C60D6683D8BF"
axis="EAID_48607400_E718_4ac3_ACC8_78052AA684CB" value="-Pi/6"
valueTypeUnit="EAID_222F7273_01B5_4e83_B616_DFEC1E04ABED"/>
xmi:id="EAID_001CEA74_FD44_4a88_A29E_020C9C780800"
axis="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90" value="0"
xmi:id="EAID_1581437E_5E34_4dec_B736_6DE35872A4D1"
axis="EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D" value="0"
</referencePoint>
xmi:id="EAID_A9CC8532_D91E_4932_AF87_DBF096389F27" name="RollRatePoint"
description="Represents the change of 90 degrees in roll angle resulting the necessary change
in velocity rate." landmark="EAID_6A77CF2F_C9B8_47e5_BF5B_6B243F14AAB6">
xmi:id="EAID_B30A8DB8_EF19_4581_8FC9_12E7D77A8BFD"
axis="EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D" value="Pi/2"
xmi:id="EAID_B92398BE_6176_43bb_85F9_915925C6DBDF"
xmi:id="EAID_22EC6337_816E_4de3_8045_06029D6D09AD"
axis="EAID_48607400_E718_4ac3_ACC8_78052AA684CB" value="0"
</referencePoint>
xmi:id="EAID_962FB837_2091_483a_816D_C42829589B73" name="PitchRatePoint"
description="Represents the change of 45 degrees in pitch angle resulting the necessary change
in velocity rate." landmark="EAID_37236D77_26DF_45fd_B528_88F78467EE4C">
xmi:id="EAID_2AE136A8_CF32_469b_9F40_EF56601F36FC"
axis="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90" value="Pi/4"

xmi:id="EAID_E113A791_7FF0_44c9_BF9C_5F68E5073AAE"
xmi:id="EAID_89F679DD_F970_4a34_ABA4_8FF2CEA2581C"
</referencePoint>
xmi:id="EAID_2E155A18_3673_4016_961E_4993A104E118" name="NoRateChangeOrientation"
description="Represents no change in velocity rate with the net result of no changes to pitch,
yaw or roll angles of orientation." landmark="EAID_874C6C78_DAD9_4ef9_8CBE_6213F4FA5252">
xmi:id="EAID_B8B8C87A_7DA7_494a_A56E_C8A7AF737212"
xmi:id="EAID_6DD6A468_46BC_4c61_B5F2_E59E94417CFD"
xmi:id="EAID_CE0C671F_061C_469a_8794_7C86AD9A880F"
</referencePoint>
</element>
xmi:id="EAID_06891598_E070_4ae8_AEE7_67A5B8BBCA90" name="OrientationVelocityLateralAxis"
description="Change of orientation velocity about the laterial axis."
defaultValueTypeUnit="EAID_222F7273_01B5_4e83_B616_DFEC1E04ABED"/>
xmi:id="EAID_D695C2CA_5B48_483e_A5EC_31D7A40CCA0D" name="OrientationVelocityLongitudinalAxis"
description="Change of orientation velocity about the longitudinal axis."
xmi:id="EAID_48607400_E718_4ac3_ACC8_78052AA684CB" name="OrientationVelocityVerticalAxis"
description="Change of orientation velocity about the vertical axis."
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_12947217_849A_4ef4_9E57_E260A6BD122C"
name="ScalarAcceleration">
<element xmi:type="logical:Measurement" xmi:id="EAID_61062334_5B0A_4e9b_8173_4AAB58D2248C"
name="ScalarAccelerationMeasurement" description="Measurement for the magnitude component of
acceleration, does not consider direction."
measurementAxis="EAID_9C551F3B_A775_4f31_AB23_A505CB49E061"
measurementSystem="EAID_7A26FFB7_E420_4c15_8E7F_BC831D7FE3A2"
realizes="EAID_CD425350_A680_49d4_974D_4052C9BABB30"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9C551F3B_A775_4f31_AB23_A505CB49E061"
name="ScalarAccelerationMeasurementAxis" description="Measurement axis for the magnitude component
of acceleration." precision="0.001"
measurementSystemAxis="EAID_DCE9B393_1F4E_472a_A293_0587767C6BB2"
realizes="EAID_CD425350_A680_49d4_974D_4052C9BABB30"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6B2ECCBA_9FFA_488f_92C4_D4772E754371"
name="ScalarAccelerationLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_816CEBC9_F8B9_4002_8383_997BAA6C63DB"
name="OneMeterPerSecondPerSecondScalarAccelerationLandmark" description="Acceleration landmark
of one m/sec^2 in X axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_79DDE6C7_4797_4dfd_975D_116B337B8E63"
name="ZeroScalarAccelerationLandmark" description="Zero velocity, an object's motion is
constant, neither speeding up or slowing down"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9F2C3797_6B4E_4fd7_B987_D714D0D2FA05"
name="ScalarAccelerationMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_7A26FFB7_E420_4c15_8E7F_BC831D7FE3A2"
name="ScalarAccelerationMeasurementSystem" description="System for measuring scalar acceleration
ie: speeding up or slowing down."
measurementSystemAxis="EAID_DCE9B393_1F4E_472a_A293_0587767C6BB2"
orientation="Values increase as object speeds up in a forward direction.">
xmi:id="EAID_9B745EC7_EF25_40dc_8229_1958086F7BD4" name="ZeroAccelerationReferencePoint"
description="Zero velocity in any direction"
landmark="EAID_79DDE6C7_4797_4dfd_975D_116B337B8E63">
xmi:id="EAID_CCCC2DEC_4AC5_42ce_8B9D_D6453DB54293"
axis="EAID_DCE9B393_1F4E_472a_A293_0587767C6BB2" value="0"/>
</referencePoint>
xmi:id="EAID_0ED24CF4_E1D9_4b2e_83A8_15FFC5161CDE"
name="OneMeterPerSecondPerSecondAccelerationReferencePoint" description="One meter/sec in
positive acceleration." landmark="EAID_816CEBC9_F8B9_4002_8383_997BAA6C63DB">
xmi:id="EAID_8BB3FE11_741F_4801_8125_C9DA48BB10E9"
axis="EAID_DCE9B393_1F4E_472a_A293_0587767C6BB2" value="1"/>
</referencePoint>
</element>
xmi:id="EAID_DCE9B393_1F4E_472a_A293_0587767C6BB2"
name="ScalarAccelerationMeasurementSystemAxis" description="The measurement system axis to
describe the nature of measuring scalar acceleration of an object."
defaultValueTypeUnit="EAID_BC96F5E1_6F63_462c_84A3_61CFB36D8011"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E69B26E5_875C_4325_AF95_BD44D4C2B6DD"
name="SpeedLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_E463202C_BB78_4ea0_ACCE_34527B0C18C5"
name="OneMeterPerSecondLandmark" description="One meter per second"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_7D5FCB19_24EB_4641_BA39_BD21319038CD"
name="ZeroSpeedLandmark" description="Zero speed."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A6A59C8E_19E5_4248_8C6C_A203F150BC84"
name="SpeedMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_21572174_353B_4fb9_92AB_66D35B6D1D45"
name="NonNegativeRealMetersPerSecond" description="Meters per second as a non-negative real
numerical representation." unit="EAID_D656A860_B181_4712_B6C0_3CC4761A682D"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_CA7165EF_5605_49ab_8B6F_24B78C4842AF"
name="SpeedMeasurementSystem" description="Measurement system for measuring speed."
measurementSystemAxis="EAID_34208C77_1C32_4838_89B7_FC6777140322"
orientation="Value increases as speed increases">
xmi:id="EAID_5A0740C1_C539_41b0_8E59_BC3163D70547" name="ZeroSpeedReferencePoint"
description="zero speed reference point" landmark="EAID_7D5FCB19_24EB_4641_BA39_BD21319038CD">
xmi:id="EAID_F1CC04E6_3801_4835_9AB8_48F6007DC0D8"
axis="EAID_34208C77_1C32_4838_89B7_FC6777140322" value="0.0"
valueTypeUnit="EAID_21572174_353B_4fb9_92AB_66D35B6D1D45"/>
</referencePoint>
xmi:id="EAID_9589609F_BFE9_48fa_BAC5_5E2BE1D3D4F6" name="OneMeterPerSecondReferencePoint"
description="unit speed reference point" landmark="EAID_E463202C_BB78_4ea0_ACCE_34527B0C18C5">
xmi:id="EAID_A42AC528_2AC6_4a19_8DDA_CB965EB271B9"
axis="EAID_34208C77_1C32_4838_89B7_FC6777140322" value="1.0"
valueTypeUnit="EAID_21572174_353B_4fb9_92AB_66D35B6D1D45"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_34208C77_1C32_4838_89B7_FC6777140322"
name="SpeedMeasurementSystemAxis" description="Measurement system axis for speed measurements"

defaultValueTypeUnit="EAID_21572174_353B_4fb9_92AB_66D35B6D1D45"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_70B502DF_752C_4951_9A59_D29E1271BB9F"
name="Acceleration">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_CA989C3B_DF5E_4455_9105_18A186D41CD7"
name="RealKnotsPerSecondPerSecond" description="Knots as a real number"
unit="EAID_9B5484D4_F922_407d_9E61_17E56532FDD8"
<element xmi:type="logical:Measurement" xmi:id="EAID_5BCE61BE_2E0D_43b2_A9C7_F47F16B5F4DB"
name="AccelerationMeasurement" description="3D acceleration vector in meters/sec/sec"
measurementAxis="EAID_B3BBA097_69D0_492a_80BC_68F77B3220BD
EAID_16A3F606_E73F_4801_88D5_D5118240ED53 EAID_BB810841_9A0C_445c_BA02_2833212B8314"
measurementSystem="EAID_F9D8A82F_C1F7_44f8_92AD_535912C28E4C"
realizes="EAID_A082A853_2D96_4222_8065_D06483A48AE8"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_DB98E386_721A_4d88_A903_6E9EB075D94C"
name="AccelerationMeasurementRealKnotsPerSecondPerSecond" description="3D acceleration vector in
knots per second." measurementAxis="EAID_525334A4_8890_4d2a_934B_60569EABB02B
EAID_36A0966D_BFE6_4773_9F19_48B64D194799 EAID_7D8913CE_BE20_4951_8EC3_905757F265C0"
measurementSystem="EAID_F9D8A82F_C1F7_44f8_92AD_535912C28E4C"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_B3BBA097_69D0_492a_80BC_68F77B3220BD"
name="AccelerationMeasurementXAxis" precision="0.01"
measurementSystemAxis="EAID_F160EF73_8C7D_496f_93C7_020262ED8563"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_525334A4_8890_4d2a_934B_60569EABB02B"
name="AccelerationMeasurementXAxisRealKnotsPerSecondPerSecond" description="X"
valueTypeUnit="EAID_CA989C3B_DF5E_4455_9105_18A186D41CD7" precision="0.01"
measurementSystemAxis="EAID_F160EF73_8C7D_496f_93C7_020262ED8563"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_16A3F606_E73F_4801_88D5_D5118240ED53"
name="AccelerationMeasurementYAxis" precision="0.01"
measurementSystemAxis="EAID_C8DCFFF3_1918_49fb_B7EE_0A801B03FE9E"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_36A0966D_BFE6_4773_9F19_48B64D194799"
name="AccelerationMeasurementYAxisRealKnotsPerSecondPerSecond"
measurementSystemAxis="EAID_C8DCFFF3_1918_49fb_B7EE_0A801B03FE9E"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_BB810841_9A0C_445c_BA02_2833212B8314"
name="AccelerationMeasurementZAxis" precision="0.01"
measurementSystemAxis="EAID_5446A913_78FE_4af0_BDAD_17593E11AAFE"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_7D8913CE_BE20_4951_8EC3_905757F265C0"
name="AccelerationMeasurementZAxisRealKnotsPerSecondPerSecond"
measurementSystemAxis="EAID_5446A913_78FE_4af0_BDAD_17593E11AAFE"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_20C84A34_373E_4d18_9840_27DB599A1FBE"
name="AccelerationLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_09ABA2E4_B0C7_44a8_BE55_4EA8AAA0A739"
name="OneMeterPerSecondPerSecondAccelerationInXAxisLandmark" description="Acceleration landmark
of one m/sec^2 in X axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_323305A0_518D_4ce4_8088_588354B84E57"
name="OneMeterPerSecondPerSecondAccelerationInYAxisLandmark" description="Acceleration landmark
of one m/sec^2 in Y axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_B317A567_5F73_4116_B993_B97BBEF86098"
name="OneMeterPerSecondPerSecondAccelerationInZAxisLandmark" description="Acceleration landmark
of one m/sec^2 in Z axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_D136372D_418A_4f80_B84C_9244DE95A17A"
name="ZeroAccelerationLandmark" description="Landmark for zero acceleration in all directions"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_61BF2F18_591A_4929_AAB2_6AEA3C2291EA"
name="AccelerationMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_BC96F5E1_6F63_462c_84A3_61CFB36D8011"
name="RealMetersPerSecondPerSecond" description="Meters Per Second Per Second As Real"
unit="EAID_D656A860_B181_4712_B6C0_3CC4761A682D"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_F9D8A82F_C1F7_44f8_92AD_535912C28E4C"
name="AccelerationMeasurementSystem" description="System for measuring vector acceleration."
measurementSystemAxis="EAID_F160EF73_8C7D_496f_93C7_020262ED8563
EAID_C8DCFFF3_1918_49fb_B7EE_0A801B03FE9E EAID_5446A913_78FE_4af0_BDAD_17593E11AAFE"
orientation="right handed">
xmi:id="EAID_C01943E2_09A4_470c_9C38_05637F047A66"
name="OneMeterPerSecondPerSecondAccelerationZAxisReferencePoint" description="One meter/sec in
positive Z direction,0 in X & Y" landmark="EAID_B317A567_5F73_4116_B993_B97BBEF86098">
xmi:id="EAID_8D4EF853_154F_40f0_8AFA_36DAC5BCE616"
axis="EAID_5446A913_78FE_4af0_BDAD_17593E11AAFE" value="1.0"
valueTypeUnit="EAID_BC96F5E1_6F63_462c_84A3_61CFB36D8011"/>
xmi:id="EAID_8B13499B_A6A6_404a_8C85_3BAD93522D30"
axis="EAID_F160EF73_8C7D_496f_93C7_020262ED8563" value="0.0"
xmi:id="EAID_22B3E877_F6C4_4bad_9909_779EEE3D5206"
axis="EAID_C8DCFFF3_1918_49fb_B7EE_0A801B03FE9E" value="0.0"
</referencePoint>
xmi:id="EAID_0BB5D96B_BBBE_4a00_AFDB_2C3DC4E146DF"
name="OneMeterPerSecondPerSecondAccelerationYAxisReferencePoint" description="One meter/sec in
positive Y direction,0 in X & Z" landmark="EAID_323305A0_518D_4ce4_8088_588354B84E57">
xmi:id="EAID_251B16D3_41F8_454e_977C_320DEEEAA2C3"
xmi:id="EAID_4A2B13FC_BD1C_4579_9DCE_64E6A057A985"
xmi:id="EAID_D7F0CE70_1956_4b8b_A38E_18C4533DC4B1"
</referencePoint>
xmi:id="EAID_5631F1B3_161E_4e32_B02B_2C1840480007" name="ZeroAccelerationReferencePoint"
landmark="EAID_D136372D_418A_4f80_B84C_9244DE95A17A">
xmi:id="EAID_C3FA5A2C_FC0C_4da9_B381_C4A0BE591BA0"
xmi:id="EAID_327AB049_B6C4_4c50_A3F7_AF2F27CC0874"
xmi:id="EAID_7EFA9382_A10A_455f_8921_8F54CFCF9352"
</referencePoint>
xmi:id="EAID_A9E08B88_6502_4fdd_B913_12760C6778FF"
name="OneMeterPerSecondPerSecondAccelerationXAxisReferencePoint" description="One meter/sec in
positive X direction,0 in Y & Z" landmark="EAID_09ABA2E4_B0C7_44a8_BE55_4EA8AAA0A739">
xmi:id="EAID_1EFC0410_9438_40e2_875A_A55F6BC00C84"
xmi:id="EAID_59B7A04D_ED38_434a_82CE_9738801152AE"

xmi:id="EAID_2DD10E44_31F6_4795_B009_CB1206F691ED"
</referencePoint>
</element>
xmi:id="EAID_F160EF73_8C7D_496f_93C7_020262ED8563" name="AccelerationMeasurementSystemXAxis"
xmi:id="EAID_C8DCFFF3_1918_49fb_B7EE_0A801B03FE9E" name="AccelerationMeasurementSystemYAxis"
xmi:id="EAID_5446A913_78FE_4af0_BDAD_17593E11AAFE" name="AccelerationMeasurementSystemZAxis"
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_05EDED37_CE18_4412_85ED_CC3B22CA864B"
name="CenterOfGravity" description="Rate measurements based on the Center of Gravity Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BE7A14DF_5462_4db0_A0DD_382CBD47F2A6"
name="CountRate" description="Logical model for the number of occurrences of a repeating event per
unit time">
<element xmi:type="logical:Unit" xmi:id="EAID_AFB0E821_EDA0_43fa_9BFE_6989D7A150D2"
name="CountsPerSecond" description="Number of events that occur per second"/>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_6E69624B_5262_42bc_B6F2_6972D125FC06"
name="NaturalEventsPerSecond" description="Count rate as real number in counts per second"
unit="EAID_AFB0E821_EDA0_43fa_9BFE_6989D7A150D2"
<element xmi:type="logical:Landmark" xmi:id="EAID_175292B7_54B4_4291_8319_AAC132B024F7"
name="OneCountPerSecondLandmark" description="One occurrence of a countable event per second"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_19BA6F6F_BB75_4d4e_BB33_192B0F9C4222"
name="ZeroCountRateLandmark" description="No occurrences of a countable event per second"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_1B1757D9_6651_468a_93E2_FDD643FC0B28"
name="CountRateMeasurementSystem" description="Measurement system for Count Rate."
measurementSystemAxis="EAID_05CB9A19_1A96_4048_8133_20D818840B1C"
orientation="Value increases as counts per second increases">
xmi:id="EAID_6C9BA7F4_0B69_451c_890A_C7D5758A1560" name="ZeroCountRateReferencePoint"
description="No occurrences of an event per second"
landmark="EAID_19BA6F6F_BB75_4d4e_BB33_192B0F9C4222">
xmi:id="EAID_44DE62CA_912F_4df5_A3D5_1E0B7C9CE79E"
axis="EAID_05CB9A19_1A96_4048_8133_20D818840B1C" value="0.00"
valueTypeUnit="EAID_6E69624B_5262_42bc_B6F2_6972D125FC06"/>
</referencePoint>
xmi:id="EAID_FAF05377_6D9B_4208_A3C1_2DCE8648EFB9" name="OneCountPerSecondReferencePoint"
description="One countable event per second"
landmark="EAID_175292B7_54B4_4291_8319_AAC132B024F7">
xmi:id="EAID_BDE7FC36_B7AF_4289_8F91_44752BB589F4"
axis="EAID_05CB9A19_1A96_4048_8133_20D818840B1C" value="1.00"
valueTypeUnit="EAID_6E69624B_5262_42bc_B6F2_6972D125FC06"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_05CB9A19_1A96_4048_8133_20D818840B1C"
name="CountRateMeasurementSystemAxis" description="Measurement axis for CountsPerSecond"
defaultValueTypeUnit="EAID_6E69624B_5262_42bc_B6F2_6972D125FC06"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_8562C3EE_E7A9_4c2f_80A7_88224E87F85A"
name="CountRateMeasurement" description="Measurement of Count Rate measured in CountsPerSecond with
Real numbers" measurementAxis="EAID_96AB26FE_F38A_4d37_8733_8514CC518EAB"
measurementSystem="EAID_1B1757D9_6651_468a_93E2_FDD643FC0B28"
realizes="EAID_29913A1B_DFBB_4db4_AE2B_93C6CC1EF116"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_96AB26FE_F38A_4d37_8733_8514CC518EAB"
name="CountRateMeasurementAxis" precision="1"
measurementSystemAxis="EAID_05CB9A19_1A96_4048_8133_20D818840B1C"
realizes="EAID_29913A1B_DFBB_4db4_AE2B_93C6CC1EF116"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_64A2A70D_8134_4dd2_B865_768418BE803A"
name="DataRate" description="Logical model for the number of occurrences of a repeating event per
unit time">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_22D33FCC_F623_427d_B954_D2AFD978990E"
name="NaturalBitsPerSecond" description="Data rate as real number in bits per second"
unit="EAID_4BD00953_158E_4ebe_B5C2_5D7F99C4C843"
<element xmi:type="logical:Landmark" xmi:id="EAID_BE0A312C_18B3_4bab_AB14_66F783441FB7"
name="OneBitPerSecondDataRateLandmark" description="One bit per second data movement"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_21588F8E_3D75_4d1b_8D50_3C1D7B234FA8"
name="ZeroDataRateLandmark" description="No data movement"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_67D02CF0_6F36_4512_9A72_79FC782D1877"
name="DataRateMeasurementSystem" description="Measurement system for data rate."
measurementSystemAxis="EAID_CA4F5AB4_B6C5_4e43_AB25_8C2FBDBCCC48"
orientation="Value increases as data rate increases">
xmi:id="EAID_9D0A8CEE_93F1_422a_B8B2_D33EEF1E3960" name="OneBitPerSecondDataRateReferencePoint"
description="One bit per second" landmark="EAID_BE0A312C_18B3_4bab_AB14_66F783441FB7">
xmi:id="EAID_4EE2A836_8AC3_4665_B834_31E344A78461"
axis="EAID_CA4F5AB4_B6C5_4e43_AB25_8C2FBDBCCC48" value="1.00"
valueTypeUnit="EAID_22D33FCC_F623_427d_B954_D2AFD978990E"/>
</referencePoint>
xmi:id="EAID_DA83A96E_5D75_468b_AD74_FA565EDA2677" name="ZeroDataRateReferencePoint"
description="No data movement" landmark="EAID_21588F8E_3D75_4d1b_8D50_3C1D7B234FA8">
xmi:id="EAID_E061979C_47D3_48a7_886B_648ADCBBF48E"
axis="EAID_CA4F5AB4_B6C5_4e43_AB25_8C2FBDBCCC48" value="0.00"
valueTypeUnit="EAID_22D33FCC_F623_427d_B954_D2AFD978990E"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_CA4F5AB4_B6C5_4e43_AB25_8C2FBDBCCC48"
name="DataRateMeasurementSystemAxis" description="Measurement axis for data rate measured in bits
per second with real numbers." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_22D33FCC_F623_427d_B954_D2AFD978990E"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_8FB0E728_5F04_4523_B308_CB1890B0CBD8"
name="DataRateMeasurement" description="Measurement of data rater measured in bits per second with
real numbers" measurementAxis="EAID_A6D1CF56_59FA_41c5_B889_F2666586D756"
measurementSystem="EAID_67D02CF0_6F36_4512_9A72_79FC782D1877"
realizes="EAID_5C94882D_D81D_44fd_9A96_04915D63D7BD"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_A6D1CF56_59FA_41c5_B889_F2666586D756"
name="DataRateMeasurementAxis" precision="1"
measurementSystemAxis="EAID_CA4F5AB4_B6C5_4e43_AB25_8C2FBDBCCC48"
realizes="EAID_5C94882D_D81D_44fd_9A96_04915D63D7BD"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_343D18EE_EB21_4691_988F_57A0F932238C"
name="DataRateUnits">
<element xmi:type="logical:Unit" xmi:id="EAID_4BD00953_158E_4ebe_B5C2_5D7F99C4C843"
name="BitsPerSecond" description="Bits per second"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_3C0A8364_1658_4665_88CE_FD29B718C67E"
name="LocalAir" description="Rate measurements based on the Local Air Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E49420B6_67AA_4440_8BB1_B736DD667A73"
name="LocalGround" description="Rate measurements based on the Local Ground Reference Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AB3D4BB4_40B8_492e_B145_0C49070B2BA0"
name="LocalHorizontal" description="Rate measurements based on the Local Horizontal Reference
Frame."/>

<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D688AB1B_E65E_4d5d_9CD4_9A63E3BB04C8"
name="LocalMagneticNorth" description="Rate measurements based on the Local Magnetic North Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AAA64CCF_46CE_44b4_A87E_50DFB4FD6224"
name="LocalNorthEastDown" description="Rate measurements based on the local North East Down Reference
Frame."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1BAC062C_CD2B_49e9_9120_B4BDEC36CC1D"
name="MassFlowRate" description="Logical model for the rate of change in Mass">
<element xmi:type="logical:Unit" xmi:id="EAID_B3BD94A4_1DCA_49c1_96AB_21E7933947F1"
name="KilogramsPerSecond" description="Rate of change in mass that occur per second"/>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_9A891B27_936C_4ffb_A999_2D737950B1E6"
name="RealKilogramsPerSecond" description="Mass rate as real number in kilograms per second"
unit="EAID_B3BD94A4_1DCA_49c1_96AB_21E7933947F1"
<element xmi:type="logical:Landmark" xmi:id="EAID_4432BF37_F8E1_4711_810A_C0F63807C62A"
name="OneKilogramPerSecondLandmark" description="One kilogram per second rate of flow in mass"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_8C6E7A81_45EB_4bbc_AADC_A8626F0B16D4"
name="ZeroKilogramPerSecondLandmark" description="No change in mass per second"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_B4355855_DB71_47d9_85BD_518369AC3D82"
name="MassFlowRateMeasurementSystem" description="Measurement system for MassFlowRate measured in
KilogramsPerSecond with Real numbers"
measurementSystemAxis="EAID_4ACDE562_CF5E_4822_81E7_C8E9AD21F208"
orientation="Value increases as rate of mass change per second increases">
xmi:id="EAID_A9510FFE_F48E_406c_BFF4_FBB504C99755" name="OneKilogramPerSecondReferencePoint"
description="One kilogram per second rate of change in mass"
landmark="EAID_4432BF37_F8E1_4711_810A_C0F63807C62A">
xmi:id="EAID_2FDE3ED0_77E9_4616_9E07_3511D11C94D8"
axis="EAID_4ACDE562_CF5E_4822_81E7_C8E9AD21F208" value="1.00"
valueTypeUnit="EAID_9A891B27_936C_4ffb_A999_2D737950B1E6"/>
</referencePoint>
xmi:id="EAID_D86DFF34_BBA0_4609_BB21_E17C59387C85" name="ZeroKilogramPerSecondReferencePoint"
description="No change in mass per second" landmark="EAID_8C6E7A81_45EB_4bbc_AADC_A8626F0B16D4">
xmi:id="EAID_D25B176E_C31D_439c_9DE9_70BF92086C07"
axis="EAID_4ACDE562_CF5E_4822_81E7_C8E9AD21F208" value="0.00"
valueTypeUnit="EAID_9A891B27_936C_4ffb_A999_2D737950B1E6"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_4ACDE562_CF5E_4822_81E7_C8E9AD21F208"
name="MassFlowRateMeasurementSystemAxis" description="Measurement axis for mass flow rate
measurements.." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_9A891B27_936C_4ffb_A999_2D737950B1E6"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_D4F564A9_C7A8_4187_B7F8_D5D5D2D52EDF"
name="MassFlowRateMeasurement" description="Measurement of mass flow rate. "
measurementAxis="EAID_B9141C5E_2CF4_4c3e_8791_1D7A7D678CCD"
measurementSystem="EAID_B4355855_DB71_47d9_85BD_518369AC3D82"
realizes="EAID_2435A700_DF6F_4e88_98FA_05AD14BA5F5D"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_B9141C5E_2CF4_4c3e_8791_1D7A7D678CCD"
name="MassFlowRateMeasurementAxis" precision="0.0001"
measurementSystemAxis="EAID_4ACDE562_CF5E_4822_81E7_C8E9AD21F208"
realizes="EAID_2435A700_DF6F_4e88_98FA_05AD14BA5F5D"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A7F66D1E_7524_4318_A343_C5682FCB63AB"
name="Velocity">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_F6853D08_6D00_4844_AB9C_60686E09323F"
name="RealKnots" description="Knots as a real number"
unit="EAID_C791EA45_64E6_469f_A762_B7E86B5359A0"
<element xmi:type="logical:Measurement" xmi:id="EAID_AB57D526_0BFB_4f61_A0EA_ECDECE528829"
name="VelocityMeasurement" description="Measurement for 3D velocity vector in meters/sec."
measurementAxis="EAID_04695DE4_B19B_49ba_884F_ACF26F444B6B
EAID_DE69C0F8_4DC4_4a07_A0A9_F3314F74DBEA EAID_DCB13086_2312_460f_A6FB_B5AE29D9C94F"
measurementSystem="EAID_9A7494F0_FA99_4291_B943_D13D93CB8970"
realizes="EAID_331BB7F2_6E37_433e_8027_991D9E82BA67"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_62DE52DE_264C_47c4_AD06_EF3052056DD5"
name="VelocityMeasurementRealKnots" description="Measurement for 3D velocity vector in knots."
measurementAxis="EAID_7CE90824_A338_4b84_9E20_4AC763056349
EAID_66DB4E23_EE19_4baa_8587_649E0EBDD9E0 EAID_A3844C03_BC64_4ee2_AAAC_26846D39BF3A"
measurementSystem="EAID_9A7494F0_FA99_4291_B943_D13D93CB8970"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_04695DE4_B19B_49ba_884F_ACF26F444B6B"
name="VelocityMeasurementXAxis" precision="0.01"
measurementSystemAxis="EAID_00AA39C5_5552_4b3c_B216_E8BB9C034583"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_7CE90824_A338_4b84_9E20_4AC763056349"
name="VelocityMeasurementXAxisRealKnots" valueTypeUnit="EAID_F6853D08_6D00_4844_AB9C_60686E09323F"
precision="0.01" measurementSystemAxis="EAID_00AA39C5_5552_4b3c_B216_E8BB9C034583"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_DE69C0F8_4DC4_4a07_A0A9_F3314F74DBEA"
name="VelocityMeasurementYAxis" precision="0.01"
measurementSystemAxis="EAID_3DDF59AE_D3CF_4af4_B961_74B4767E82F4"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_66DB4E23_EE19_4baa_8587_649E0EBDD9E0"
name="VelocityMeasurementYAxisRealKnots" valueTypeUnit="EAID_F6853D08_6D00_4844_AB9C_60686E09323F"
precision="0.01" measurementSystemAxis="EAID_3DDF59AE_D3CF_4af4_B961_74B4767E82F4"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_DCB13086_2312_460f_A6FB_B5AE29D9C94F"
name="VelocityMeasurementZAxis" precision="0.01"
measurementSystemAxis="EAID_5ED509C3_48D9_4c7f_9047_B636C7162F68"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_A3844C03_BC64_4ee2_AAAC_26846D39BF3A"
name="VelocityMeasurementZAxisRealKnots" valueTypeUnit="EAID_F6853D08_6D00_4844_AB9C_60686E09323F"
precision="0.01" measurementSystemAxis="EAID_5ED509C3_48D9_4c7f_9047_B636C7162F68"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_FF1AFED9_85B0_4398_8DA0_715BEAEDAFE1"
name="VelocityLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_924F91D1_E7B0_41f0_9E35_9A5EABAD0DDC"
name="NoMotionVelocityLandmark" description="Landmark for zero velocity in all directions"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_C4B225CB_048A_4847_8BB7_5FE18049CAA5"
name="UnitVelocityInXAxisLandmark" description="Velocity landmark of one m/sec in X axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_BA313E72_BA10_4b3f_B184_7B146075F771"
name="UnitVelocityInYAxisLandmark" description="Velocity landmark of one m/sec in Y axis"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_0456CB67_FDB8_48db_B9AF_0690B41F3AA1"
name="UnitVelocityInZAxisLandmark" description="Velocity landmark of one m/sec in Z axis"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_5CB4F2D0_60BC_4706_8678_BC030735133D"
name="VelocityMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_A3E35DAE_F099_4f94_814A_3CCBD68FD08E"
name="RealMetersPerSecond" description="Velocity In Meters Per Second As Real"
unit="EAID_D656A860_B181_4712_B6C0_3CC4761A682D"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_9A7494F0_FA99_4291_B943_D13D93CB8970"
name="VelocityMeasurementSystem" description="Measurement system for values of velocity."
measurementSystemAxis="EAID_00AA39C5_5552_4b3c_B216_E8BB9C034583
EAID_3DDF59AE_D3CF_4af4_B961_74B4767E82F4 EAID_5ED509C3_48D9_4c7f_9047_B636C7162F68"
orientation="right handed">
xmi:id="EAID_6AC32D56_19A0_4f1c_98B6_7936DDC88E8E" name="ZeroVelocityReferencePoint"
landmark="EAID_924F91D1_E7B0_41f0_9E35_9A5EABAD0DDC">
xmi:id="EAID_9F9DD44A_D086_4418_B650_0D75E6DBCCC7"
axis="EAID_00AA39C5_5552_4b3c_B216_E8BB9C034583" value="0.0"
valueTypeUnit="EAID_A3E35DAE_F099_4f94_814A_3CCBD68FD08E"/>
xmi:id="EAID_33CA168C_C05A_477b_9931_C0F2EC5C2464"
axis="EAID_3DDF59AE_D3CF_4af4_B961_74B4767E82F4" value="0.0"
xmi:id="EAID_C3523237_D62D_4f01_8E0E_2BA6AA763C56"

axis="EAID_5ED509C3_48D9_4c7f_9047_B636C7162F68" value="0.0"
</referencePoint>
xmi:id="EAID_45983774_5CFB_4a1b_9715_1B2629E17515" name="OneMeterPerSecondXAxisReferencePoint"
description="One meter/sec in positive X direction, 0 in Y & Z"
landmark="EAID_C4B225CB_048A_4847_8BB7_5FE18049CAA5">
xmi:id="EAID_86B761F3_23AE_45a3_BA90_906B69840266"
xmi:id="EAID_5550D503_6FDA_4db3_BE7E_203862F9AD7B"
xmi:id="EAID_13578EF5_F7C5_41af_844E_69EF05398BFE"
</referencePoint>
xmi:id="EAID_F95D223E_6EF2_4c32_8E38_1CA62862018F" name="OneMeterPerSecondZAxisReferencePoint"
description="One meter/sec in positive Z direction, 0 in X & Y"
landmark="EAID_0456CB67_FDB8_48db_B9AF_0690B41F3AA1">
xmi:id="EAID_07682483_985F_4214_B49F_A234FF69FB8A"
xmi:id="EAID_4B2C2FEF_4D56_403d_9DF0_2C43D27F484E"
xmi:id="EAID_2616C879_E949_499b_874E_1F11111FFBBF"
</referencePoint>
xmi:id="EAID_9F05FEE4_416D_479c_80F1_225CE6158569" name="OneMeterPerSecondYAxisReferencePoint"
description="One meter/sec in positive Y direction, 0 in X & Z"
landmark="EAID_BA313E72_BA10_4b3f_B184_7B146075F771">
xmi:id="EAID_1C3A6560_8113_4aeb_8883_913E93D23CB0"
xmi:id="EAID_30A352AD_9A94_4c4c_8106_B3DDA79ECA07"
xmi:id="EAID_56A58262_5F02_4fad_B563_DD4384BA0142"
</referencePoint>
</element>
xmi:id="EAID_00AA39C5_5552_4b3c_B216_E8BB9C034583" name="VelocityMeasurementSystemXAxis"
defaultValueTypeUnit="EAID_A3E35DAE_F099_4f94_814A_3CCBD68FD08E"/>
xmi:id="EAID_3DDF59AE_D3CF_4af4_B961_74B4767E82F4" name="VelocityMeasurementSystemYAxis"
xmi:id="EAID_5ED509C3_48D9_4c7f_9047_B636C7162F68" name="VelocityMeasurementSystemZAxis"
</ldm>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_472F515A_471B_46b8_B93A_34C59A3D56FA"
name="TemperatureMeasures">
<element xmi:type="logical:Measurement" xmi:id="EAID_96A30055_C2CE_41c4_8B18_54D31F550C5C"
name="TemperatureDeltaMeasurement" description="Measurement for expressing temperature deltas"
measurementAxis="EAID_9A198C4A_7F41_49c8_8E88_A78CC6036D71"
measurementSystem="EAID_170CE113_B44C_4e3d_900C_145AD5038DA1"
realizes="EAID_413788BB_764C_45d6_BBB3_904F396F92A3"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_4D93682B_D923_46db_BEBE_5316D34D5BA9"
name="TemperatureMeasurement" description="Thermodynamic temperature measures in degrees Kelvin."
measurementAxis="EAID_383C7B72_1F72_4471_8962_0676820582FD"
realizes="EAID_2912B4B3_E784_4796_A911_6CE50C6872FB"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_4C0798C1_CC70_4d59_9836_14C5490A158D"
name="TemperatureMeasurementDegreesCelsius" description="Thermodynamic temperature measures in
degrees Celsius." measurementAxis="EAID_AD359229_9EA5_4b17_BD48_3ACADEFBE806"
<element xmi:type="logical:Measurement" xmi:id="EAID_4992D477_7343_44e0_BE44_8BB3DDDDE001"
name="TemperatureMeasurementDegreesFahrenheit" description="Thermodynamic temperature measures in
degrees Fahrenheit." measurementAxis="EAID_985CF56E_0DC3_49a8_B45C_40933A0703B2"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9A198C4A_7F41_49c8_8E88_A78CC6036D71"
name="TemperatureDeltaMeasurementAxis" description="Measurement axis for values of temperature
deltas." precision="0.001" measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
realizes="EAID_413788BB_764C_45d6_BBB3_904F396F92A3"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_383C7B72_1F72_4471_8962_0676820582FD"
name="TemperatureMeasurementAxis" valueTypeUnit="EAID_8AEE5DA4_5925_412c_9D23_D625B93B0665"
precision=".01" measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
realizes="EAID_2912B4B3_E784_4796_A911_6CE50C6872FB">
xmi:id="EAID_233E9016_F98B_4932_B10B_C9111298BEF9" constraintText="Always >= absolute zero"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_AD359229_9EA5_4b17_BD48_3ACADEFBE806"
name="TemperatureMeasurementAxisDegreesCelsius"
valueTypeUnit="EAID_5570B556_17D4_41a8_B786_840B7A4CAAE3" precision=".01"
measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
xmi:id="EAID_4AE4B31A_323C_4b0c_B0AB_201895AE1287" constraintText="Always >= absolute zero."/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_985CF56E_0DC3_49a8_B45C_40933A0703B2"
name="TemperatureMeasurementAxisDegreesFahrenheit"
valueTypeUnit="EAID_E3839F0F_515A_4496_AE49_EA85C5A5F0AC" precision=".01"
measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
xmi:id="EAID_D23D6885_FC6D_4ee1_852A_98E10C9DF1B4" constraintText="Always >= absolute zero"/>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_F027902E_D342_4e78_8E53_ADCCA7688954"
name="DegC_to_DegF_Temperature_Conversion" description="Conversion from Degrees Celsius to Degrees
Fahrenheit" conversionLossDescription="none" source="EAID_4C0798C1_CC70_4d59_9836_14C5490A158D"
target="EAID_4992D477_7343_44e0_BE44_8BB3DDDDE001">
<equation>DegF=1.8*DegC+32</equation>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_3409B03E_9DDA_4fef_B2BB_C07BE7EF6729"
name="DegC_to_DegK_Temperature_Conversion" description="Conversion from Degrees Celsius to Degrees
Kelvin" conversionLossDescription="none" source="EAID_4C0798C1_CC70_4d59_9836_14C5490A158D"
target="EAID_4D93682B_D923_46db_BEBE_5316D34D5BA9">
<equation>DegK=DegC + 273.15</equation>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_E3B47DC7_E224_4876_9E21_81391DB7FB19"
name="DegF_to_DegC_Temperature_Conversion" description="Conversion from Degrees Fahrenheit to Degrees
Celsius" conversionLossDescription="none" source="EAID_4992D477_7343_44e0_BE44_8BB3DDDDE001"
target="EAID_4C0798C1_CC70_4d59_9836_14C5490A158D">
<equation>DegC=(DegF-32)/1.8</equation>

</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_341E3FF5_1C19_4d71_8773_FC266F97557F"
name="DegF_to_DegK_Temperature_Conversion" description="Conversion from Degrees Fahrenheit to Degrees
Kelvin" conversionLossDescription="none" source="EAID_4992D477_7343_44e0_BE44_8BB3DDDDE001"
target="EAID_4D93682B_D923_46db_BEBE_5316D34D5BA9">
<equation>DegK=(DegF-459.67)/1.8</equation>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_E1501D4D_D7EB_4cf9_86AB_260A75418C3E"
name="DegK_to_DegC_Temperature_Conversion" description="Conversion from Degrees Kelvin to Degrees
Celsius" conversionLossDescription="none" source="EAID_4D93682B_D923_46db_BEBE_5316D34D5BA9"
<equation>DegC=DegK - 273.15</equation>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_AF340A57_827E_4ec9_8DBF_773FB14BBD65"
name="DegK_to_DegF_Temperature_Conversion" description="Conversion from Degrees Kelvin to Degrees
Fahrenheit" conversionLossDescription="none" source="EAID_4D93682B_D923_46db_BEBE_5316D34D5BA9"
<equation>DegF=1.8*DegK+459.67</equation>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_84DB3782_2285_445d_8349_10B5D5BB5708"
name="TemperatureLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_99B14262_EA23_4511_A3F0_3546D028849D"
name="AbsoluteZero" description="The lower limit of the thermodynamic temperature scale, a
ficticious state at which the enthalpy and entropy of a cooled ideal gas reaches its minimum value
(-459.67 deg F, -273.15 deg C, 0 deg K)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_CED1C8C6_F278_4501_A043_E59507D5CF90"
name="BoilingPointOfWater" description="Boiling point of water at 1 atmosphere pressure (212 deg F,
671.67 deg R, 100 deg C, 373.15 deg K)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_F1FC1D80_0D3E_402b_B1BE_6271F0BC9DED"
name="FreezingPointOfWater" description="Freezing point of water at 1 atmosphere pressure (32 deg
F, 491.67 deg R, 0 deg C, 273.15 deg K)"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_93166DCD_0CF7_452e_B424_EF549ECE6E99"
name="TemperatureMeasurementSystem">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_5570B556_17D4_41a8_B786_840B7A4CAAE3"
name="RealCelsius" description="Value in Degrees Celsius"
unit="EAID_723C724A_263B_48fe_B9EA_6D471D78BECA"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_E3839F0F_515A_4496_AE49_EA85C5A5F0AC"
name="RealFahrenheit" description="Value in Degrees Fahrenheit"
unit="EAID_A1A79A69_F65A_4734_8957_894EFEDA1F5A"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_8AEE5DA4_5925_412c_9D23_D625B93B0665"
name="RealKelvin" description="Value in Degrees Kelvin"
unit="EAID_C06308E5_8978_48e2_963B_596CFB8C04A4"
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_170CE113_B44C_4e3d_900C_145AD5038DA1"
name="TemperatureMeasurementSystem" description="Measurement system to represent temperature values
in Kelvin degrees" measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
orientation="Values increase as temperature increases">
xmi:id="EAID_0CA2F5C3_2423_43be_9498_6D20DB65235E" name="WaterFreezingPoint"
description="Represents waters freezing point."
landmark="EAID_F1FC1D80_0D3E_402b_B1BE_6271F0BC9DED">
xmi:id="EAID_4970F1ED_D7DB_4aaf_90A1_32AE8116864C"
axis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26" value="273.15"
valueTypeUnit="EAID_8AEE5DA4_5925_412c_9D23_D625B93B0665"/>
</referencePoint>
xmi:id="EAID_37E7441D_FC5F_4ba4_8742_4F66FB54367E" name="WaterBoilingPoint"
description="Represents waters boiling point"
landmark="EAID_CED1C8C6_F278_4501_A043_E59507D5CF90">
xmi:id="EAID_4DD11403_BD01_4ca6_8D23_D74104E5FB42"
axis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26" value="373.15"
</referencePoint>
xmi:id="EAID_4154DA2F_D4A4_484a_933F_4A0FC6D8565E" name="AbsoluteZeroPoint"
description="Represents zero point of temperature"
landmark="EAID_99B14262_EA23_4511_A3F0_3546D028849D">
xmi:id="EAID_255054E2_0E11_469b_9A82_CDC964ACB70D"
axis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26" value="0"
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26"
name="TemperatureMeasurementSystemAxis" description="Axis for Real number values in degrees Kelvin"
defaultValueTypeUnit="EAID_8AEE5DA4_5925_412c_9D23_D625B93B0665"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8C083820_6466_483b_9047_3DF9D2990363"
name="LocalAir" description="Temperature measurements based on the Local Air Reference Frame.">
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_528F4773_240A_4ac0_AA34_1F6F4C40D1BD"
name="LocalAirMeasurementAxis_DegreesCelsius" precision="How should this be specified"
measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26">
xmi:id="EAID_74F489DA_BA25_4578_A399_D0C72DA7834C" constraintText="Temperature range in Earth
atmosphere from surface through stratosphere (-70C to +70C)"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_B58D75F6_F61A_4f66_A846_031A65AA3EF0"
name="LocalAirMeasurementAxis_DegreesFahrenheit" precision="How should this be specified?"
measurementSystemAxis="EAID_E023E619_ED37_429a_B3FC_653CDC4D5C26">
xmi:id="EAID_7B22CF80_557D_42c6_B26B_FD70DA877CEF" constraintText="Temperature range in Earth
atmosphere from surface through stratosphere (-100F to +160F)"/>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_9C5FFD4F_C2C7_404d_B8F8_B4BC7CD0C64D"
name="DegC_to_DegF_TAT_LocalAir_Temperature_Conversion" description="Conversion from Degrees
Celsius to Degrees Fahrenheit" conversionLossDescription="none"
source="EAID_4C0798C1_CC70_4d59_9836_14C5490A158D"
<equation>DegF=1.8*DegC+32</equation>
</element>
<element xmi:type="logical:MeasurementConversion" xmi:id="EAID_071E1D6E_7654_4dd4_AF38_FECB88F6FB0A"
name="DegF_to_DegC_TAT_LocalAir_Temperature_Conversion" description="Conversion from Degrees
Fahrenheit to Degrees Celsius" conversionLossDescription="none"
source="EAID_4992D477_7343_44e0_BE44_8BB3DDDDE001"
<equation>DegC=(DegF-32)/1.8</equation>
</element>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9314B184_811C_43b2_AB0D_F8D48CA1AD23"
name="TimeMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E7A2C8B2_BF2F_43b2_AE9F_AACEFA4B26FA"
name="CalendarTimeMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B6E638E9_194C_407f_A1F3_BCC272577B5E"
name="UTC_Measures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_78C708C0_6629_4464_B0DD_8D88EF3B63EC"
name="StringISO8601Basic" description="Text String formatted per ISO 8601's basic format"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_ED9E8C67_EADC_4e8b_AE9D_FDE127E74F8A"
name="StringISO8601Extended" description="Text String formatted per ISO 8601's extended format"
<element xmi:type="logical:Measurement" xmi:id="EAID_E8FA7DE3_3604_472d_845F_1BC6324B3DA8"
name="TimeISO8601BasicMeasurement" description="A date-time expressed as a text string
conforming to the ISO8601 standard's basic format (no separators between time and date
components)" measurementAxis="EAID_389549E1_3214_4ab6_AD52_31456B5B56D0"
measurementSystem="EAID_919C63A9_0165_4912_8EB0_2385631BEDF5"
realizes="EAID_6F2C6003_64FF_42a1_B4D1_00E34745B793"/>

<element xmi:type="logical:Measurement" xmi:id="EAID_EBA84EE8_B7C1_4235_B2D7_5E0E26CE9726"
name="TimeISO8601ExtendedMeasurement" description="A date-time expressed as a text string
conforming to the ISO8601 standard's extended format (hyphens between date components, colons
between time components)" measurementAxis="EAID_01B4E089_43BE_4fbd_8B2F_0E6D4F1D54C4"
<element xmi:type="logical:Measurement" xmi:id="EAID_BB3EA4C8_7C42_46ca_9FAC_2B2F97A6B421"
name="UTCTimeOfDayMeasurement" description="A time in a specific calendar day indicating the
number of hours,minutes,and seconds since the day start per the UTC standard"
measurementAxis="EAID_A742838B_04C5_4ac6_BE93_23DFB19E071D"
measurementSystem="EAID_C5B2FCE6_50D5_49bd_B283_E3C5F1C922CC"
realizes="EAID_FF5D2D41_EF3E_434e_8501_96DBDD70DECD"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_8A676269_31C8_4328_887F_4A4037361262"
name="GregorianDateMeasurement" description="Gregorian calendar date measurement. Like UTC Time,
but without time of day components" measurementAxis="EAID_F668E99E_69A8_4f62_9E5E_AED67ECA8F4B"
<element xmi:type="logical:Measurement" xmi:id="EAID_C37DD99D_2780_4d77_97C1_0C0B7E356E6F"
name="LocalTimeMeasurement" description="Local calendar date & time in a time zone per the
UTC standard, using Gregorian calendar days (vs. Julian day number) and an hr:min offset from
UTC" measurementAxis="EAID_208221D0_6397_42f8_A95E_68D653800C9F"
<element xmi:type="logical:Measurement" xmi:id="EAID_35DA47A4_BE0D_429f_A3EB_884AA94E9F18"
name="UTCTimeMeasurement" description="Date & time per the UTC standard using Gregorian
calendar days (vs. Julian day number). The measure does not include a local time offset."
measurementAxis="EAID_4B74DE56_0A5D_4f0e_9B46_9C2D5DDA1DCE"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_389549E1_3214_4ab6_AD52_31456B5B56D0"
name="TimeISO8601BasicMeasurementAxis" description="Measurement axis to represent date-time
expressed as a text string conforming to the ISO8601 standard’s basic format."
valueTypeUnit="EAID_78C708C0_6629_4464_B0DD_8D88EF3B63EC" precision="0.001"
measurementSystemAxis="EAID_5464AD82_2C21_4ad1_9FF8_77A64C196E82"
realizes="EAID_6F2C6003_64FF_42a1_B4D1_00E34745B793">
xmi:id="EAID_22C0D3D5_E274_4164_AA3C_3D900CBA4986" constraintText="Constrained per ISO8601
Time Basic"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_01B4E089_43BE_4fbd_8B2F_0E6D4F1D54C4"
name="TimeISO8601ExtendedMeasurementAxis" description="Measurement axis to represent date-time
expressed as a text string conforming to the ISO8601 standard's extended format"
valueTypeUnit="EAID_ED9E8C67_EADC_4e8b_AE9D_FDE127E74F8A" precision="0.001"
realizes="EAID_6F2C6003_64FF_42a1_B4D1_00E34745B793">
xmi:id="EAID_7011F8EC_D7B5_484a_813F_F762F68C7A48" constraintText="Constrained per ISO8601
Time Extended"/>
</element>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_A742838B_04C5_4ac6_BE93_23DFB19E071D"
name="UTCTimeOfDayMeasurementAxis" description="Measurement axis for time offset since the start
of a UTC/Gregorian calendar day, represented with HourOfDay, MinuteOfHour, & SecondOfMinute
components" valueTypeUnit="EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19
EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65 EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020"
precision="1" measurementSystemAxis="EAID_A9475213_1F9D_4967_9F5B_5454DF64813D"
realizes="EAID_FF5D2D41_EF3E_434e_8501_96DBDD70DECD"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_F668E99E_69A8_4f62_9E5E_AED67ECA8F4B"
name="GregorianDateMeasurementAxis" description="Measurement axis for Gregorian date. Same as
UTCTimeAxis, but without time of day components."
valueTypeUnit="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59
EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D"
precision="1" measurementSystemAxis="EAID_5464AD82_2C21_4ad1_9FF8_77A64C196E82"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_208221D0_6397_42f8_A95E_68D653800C9F"
name="LocalTimeMeasurementAxis" description="Measurement axis for UTC time with local time
offset" precision="1" measurementSystemAxis="EAID_5464AD82_2C21_4ad1_9FF8_77A64C196E82"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_4B74DE56_0A5D_4f0e_9B46_9C2D5DDA1DCE"
name="UTCTimeMeasurementAxis" description="Measurement axis for UTC time"
valueTypeUnit="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59
EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D
EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19 EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65
EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020" precision="1"
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_DB5F3FD5_6C95_4a75_919D_81F51C907608"
name="UTC_MeasurementSystem" description="Time measurements based on Universal Coordinated Time.">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59"
name="UTC_GregorianYear" description="Gregorian calendar year of the measurement"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE"
name="UTC_MonthOfGregorianYear" description="Month of the Gregorian Year of the measurement"
valueType="EAID_372D8BFC_47B1_4385_AD77_6703541E7FAC">
<constraint xmi:type="logical:IntegerRangeConstraint"
xmi:id="EAID_18669915_5A53_4caa_9D0A_354EE23975D8" name="UTC_MonthOfYearConstraint"
description="UTC (& Gregorian calendar) uses values of 1 through 12 to represent the 12
months January through December, respectively" lowerBound="1" upperBound="12"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D"
name="UTC_DayOfGregorianMonth" description="Day of the Gregorian Month & Year of the
measurement" unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
xmi:id="EAID_E5263524_9EF8_4bea_BF77_DB5811A1CA39" name="UTC_DayOfMonthConstraint"
description="UTC (& Gregorian) Day of Month is represented by values from 1 for the first
day of the month to the number of days in the month, which depends on the month and year, but
never exceeds 31" lowerBound="1" upperBound="31"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19"
name="UTC_HourOfGregorianDay" description="Hour of the Gregorian Day, Month, Year of the
measurement. Each UTC day contains exactly 24 hours."
xmi:id="EAID_C2BB6D22_F3FC_4b14_8CCB_6543C0CD22D5" name="UTC_HourOfDayConstraint"
description="UTC Hour of Day starts a 0 and ends at 23. All days are 24 hours long."
upperBound="23"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65"
name="UTC_MinuteOfHour" description="Minute of the hour of the Gregorian Day, Month, Year of the
measurement. Each UTC hour contains exactly 60 minutes."
xmi:id="EAID_0F803579_FBA4_47ea_948A_0E98A06E0885" name="UTC_MinuteOfHourConstraint"
description="UTC Minute of hour starts at 0 and ends at 59. There are always 60 minutes per
hour, though sometimes the last minute may be 1 sec longer or shorter than the other minutes"
upperBound="59"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020"
name="UTC_SecondOfMinute" description="Second of the hour and minute of the Gregorian Day,
Month, Year of the measurement. UTC minutes usually have 60 seconds, but the last minute of the
last day of a month can have 59 or 61 seconds." unit="EAID_17A1BB83_047A_4b42_A183_1237BC07B435"
xmi:id="EAID_921B1D6C_6254_44e5_8454_D836DF6B4046" name="UTC_SecondOfMinuteConstraint"
description="UTC second of day starts at 0 and ranges to the number of seconds in a minute
minus 1. UTC minutes usually have 60 seconds, but the last minute of the last day of a month
can have 59 or 61 seconds." upperBound="60"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_F525FE9D_FC27_4971_AB94_AAB65C8FD169"
name="UTC_LocalTimeHourOffset" description="The number of hours that the local time is before or

after the prime meridian (Zulu time). This offset represents the difference from Zulu due to
time zone and daylight savings time." unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
xmi:id="EAID_EBF61D38_B48D_4398_BF79_EA01FD593B76" name="UTC_LocalTimeHourOffsetConstraint"
description="UTC time offset can range from UTC-12:00 to UTC+14:00 in 15 minute increments.
This element is just the hour component of the offset." lowerBound="-12" upperBound="14"/>
</element>
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_DA807F63_757D_47ee_9A1A_4C45CFA6E054"
name="UTC_LocalTimeMinuteOffset" description="The minute component of the hour:minute offset
that the local time is before or after the prime meridian (Zulu time). Values can range from -45
to +45 in 15 min increments." unit="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B"
xmi:id="EAID_C4A9341E_CD92_4f67_B09D_364B1B811CD4" name="UTC_LocalTimeMinuteOffsetConstraint"
description="UTC time offset can range from UTC-12:00 to UTC+14:00 in 15 minute increments.
This element is just the minute component of the offset." lowerBound="-45" upperBound="45"/>
</element>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_919C63A9_0165_4912_8EB0_2385631BEDF5"
name="UTCwithLocalTimeOffsetMeasurementSystem" description="Primary time system the world uses
to regulate clocks and date-times, a main goal of which is to correlate one rotation of the
earth with one 24 hour day by making occasional 1 second corrections to the duration of a day. "
externalStandardReference="Coordinated Universal Time defined by International
Telecommunications Union Recommendation (ITU-R TF.460-6), Standard-frequency and time-signal
emissions" orientation="see UTC standard">
xmi:id="EAID_7F44601B_B222_40d1_9D07_AA758F940631" name="UTC_GregorianCalendarOrigin"
description="Start of Gregorian Calendar - Jan 1, 0:0:0 Zulu"
landmark="EAID_712C56C3_07E9_4693_B56E_4DD0BD9C13A3">
xmi:id="EAID_AC478CA1_3ACF_4953_8EF2_9EEBF661D4A2"
axis="EAID_5464AD82_2C21_4ad1_9FF8_77A64C196E82" value="1"
valueTypeUnit="EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D"/>
xmi:id="EAID_053D2DC3_22B8_44cc_AB89_2F4A923E8255"
valueTypeUnit="EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE"/>
xmi:id="EAID_227EA9B2_E102_478f_90E4_FC9669A86248"
valueTypeUnit="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59"/>
xmi:id="EAID_3E5CD4B1_D330_433d_B4A0_7C3AD7875818"
valueTypeUnit="EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19"/>
xmi:id="EAID_FAB26483_9965_4a52_9866_41A72E9BBB5D"
valueTypeUnit="EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65"/>
xmi:id="EAID_3924559C_8AEC_4891_BB6D_EB07EBB21AA4"
valueTypeUnit="EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020"/>
xmi:id="EAID_E650AB59_CDB4_4173_9B24_41D273F8722F"
valueTypeUnit="EAID_F525FE9D_FC27_4971_AB94_AAB65C8FD169"/>
xmi:id="EAID_2C814F58_6FEA_43fc_8614_60031F3462C8"
valueTypeUnit="EAID_DA807F63_757D_47ee_9A1A_4C45CFA6E054"/>
</referencePoint>
xmi:id="EAID_3E8BE104_A9BD_4f7d_9E57_C0066E58B660" name="UTC_UnixEpochTime" description="Unix
Epoch Time - Jan 1,1970 0:0:0 UTC" landmark="EAID_E3DB5E79_28F5_4546_AF37_5C5C59EAA687">
xmi:id="EAID_659DD027_C82C_48f9_ADC6_571A156A2CB9"
valueTypeUnit="EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D"/>
xmi:id="EAID_652FD54A_1EC2_49a7_A85A_FAC77D3FB135"
valueTypeUnit="EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE"/>
xmi:id="EAID_A665040B_20B6_45d3_B8F9_F9DAC9CE5986"
valueTypeUnit="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59"/>
xmi:id="EAID_42C27C48_F64D_4fd9_9097_9D1138D8C112"
xmi:id="EAID_798AF305_1CE8_4eaa_96A3_620F0CC6BC12"
xmi:id="EAID_B49E1C0E_B45E_43f8_B957_DF81D9BCB4ED"
xmi:id="EAID_C66BB73F_A016_4fd9_95DE_4C176E4A2DBC"
valueTypeUnit="EAID_F525FE9D_FC27_4971_AB94_AAB65C8FD169"/>
xmi:id="EAID_7DE63EBC_2574_42a6_9CF8_F6F402BB4A6D"
valueTypeUnit="EAID_DA807F63_757D_47ee_9A1A_4C45CFA6E054"/>
</referencePoint>
</element>
xmi:id="EAID_5464AD82_2C21_4ad1_9FF8_77A64C196E82" name="UTCLocalTimeMeasurementSystemAxis"
description="Represents calendar day using Gregorian calendar (year, month of year, & day of
month), time of day as hour of day, minute of hour, and second of minute, and local offset from
UTC as count of hours, count of minutes." axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_4363AD8C_A1ED_447c_8074_A9C2C1BFAD59
EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19 EAID_E2FA4AF7_5100_4797_A1BD_B5E448ED93EE
EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65 EAID_770A3B26_286B_4669_9D59_28EEEDDFA38D
EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020 EAID_F525FE9D_FC27_4971_AB94_AAB65C8FD169
EAID_DA807F63_757D_47ee_9A1A_4C45CFA6E054"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_75917908_BE51_48a0_90FA_6112089129D3"
name="TimeDurationMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_A71F1148_7ED6_47bb_8D23_40879881A511"
name="IntegerHours" description="Integer hours" unit="EAID_ACBBECC7_C23C_48d8_8355_ED0A3A3A3324"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_4F8968A0_E38F_4434_B511_EE50E0BD0A5A"
name="IntegerMinutes" description="Integer minutes"
unit="EAID_D16C8EB8_AEA3_4dc4_B32D_2EA864931180"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_D4E6F91B_E17A_42b5_9D3F_A5A852B8519E"
name="IntegerSeconds" description="Integer seconds"
unit="EAID_17A1BB83_047A_4b42_A183_1237BC07B435"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_C9419C4D_A541_4810_82FB_FC6266B893DD"
name="IntegerMilliseconds" description="Integer milliseconds"
unit="EAID_CDB24D2F_2CBF_4617_BD58_7A64770B4AF7"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_53D339BB_B8AB_4c87_8FCE_EF87F0CB7BEF"
name="IntegerMicroseconds" description="Integer microseconds"
unit="EAID_DD9D1386_CC2E_4f76_BD72_A2E1BAF61CAC"

<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_8FAB4588_E952_4394_AA69_083EAF893AF4"
name="IntegerNanoseconds" description="Integer nanoseconds"
unit="EAID_8E83CE63_89C9_4911_98A0_F7D3A60EF0EB"
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_A558BC68_B8EF_43d8_8889_65E126114613"
name="RealSeconds" description="Seconds as Real" unit="EAID_17A1BB83_047A_4b42_A183_1237BC07B435"
<element xmi:type="logical:Measurement" xmi:id="EAID_B892AB87_32A2_4d24_AB2E_B903C6515760"
name="PosixTimeMeasurement" description="Measurement describing a instant in time as the number of
seconds that have elapsed since the Unix Epoch Time (00:00:00 Coordinated Universal Time
(UTC),Thursday,1 January 1970),not counting leap seconds."
measurementAxis="EAID_101C0D13_D395_47fb_8885_743191537CB9"
measurementSystem="EAID_3E078B08_3024_4dfe_B01E_74929C579251"
realizes="EAID_4E729952_4D4F_46f9_B372_04489372E9D4"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_1A8D73E3_1037_43b2_BE82_A4F03B55274B"
name="TimeDurationMeasurementIntegerHours" description="The time duration to or from a specific
reference time in hours." measurementAxis="EAID_78BB6B9A_2D62_403e_B630_5908C9C2DCA1"
measurementSystem="EAID_4C31C156_E6E2_4115_AF63_8794199664AA"
<element xmi:type="logical:Measurement" xmi:id="EAID_C6874185_57C1_48c2_9D10_1C07854096FC"
name="TimeDurationMeasurementIntegerMinutes" description="The time duration to or from a specific
reference time in minutes." measurementAxis="EAID_FD3C0CAF_58D2_4955_8E25_3D08220DF370"
<element xmi:type="logical:Measurement" xmi:id="EAID_8728BC54_83E3_4539_8DD9_E585B96842D5"
name="TimeDurationMeasurementIntegerSeconds" description="The time duration to or from a specific
reference time in seconds." measurementAxis="EAID_94B8472E_5F5B_4f87_B89F_70B2B293D187"
<element xmi:type="logical:Measurement" xmi:id="EAID_3BA75C1A_FDDB_4a94_A7F0_E5283B956F06"
name="TimeDurationMeasurementIntegerMicroseconds" description="The time duration to or from a
specific reference time in microseconds."
measurementAxis="EAID_3F6678FA_B48F_41b2_8C42_35C4BC3901C0"
<element xmi:type="logical:Measurement" xmi:id="EAID_4805C60A_CC31_45af_B3A1_57C9353A3B21"
name="TimeDurationMeasurementIntegerMilliseconds" description="The time duration to or from a
specific reference time in milliseconds."
measurementAxis="EAID_3457128D_EDE7_4e41_9D0F_E05E81B52C4A"
<element xmi:type="logical:Measurement" xmi:id="EAID_A41947AA_BEE6_4056_9BD2_D9862491D063"
name="TimeDurationMeasurementIntegerNanoseconds" description="The time duration to or from a
specific reference time in minutes." measurementAxis="EAID_9850C6AD_C2FE_44b1_B2E2_D25EE8E548B5"
<element xmi:type="logical:Measurement" xmi:id="EAID_EDBCEFD8_B3FF_472d_ACA1_9E0A2C477AF1"
name="TimeDurationMeasurementRealSeconds" description="Measure of time duration as real with
microsecond precision." measurementAxis="EAID_C60479DC_124E_4445_82B5_55F128A30016"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_101C0D13_D395_47fb_8885_743191537CB9"
name="PosixTimeMeasurementAxis" description="Measurement axis for POSIX/Unix time duration in
integer seconds" precision="1" measurementSystemAxis="EAID_789E08B1_DC02_497e_A8C9_75BC1AB027CD"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_78BB6B9A_2D62_403e_B630_5908C9C2DCA1"
name="TimeDurationMeasurementAxisIntegerHours" description="Measurement axis for time duration in
integer hours." valueTypeUnit="EAID_A71F1148_7ED6_47bb_8D23_40879881A511" precision="1"
measurementSystemAxis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_FD3C0CAF_58D2_4955_8E25_3D08220DF370"
name="TimeDurationMeasurementAxisIntegerMinutes" description="Measurement axis for time duration in
integer minutes." valueTypeUnit="EAID_4F8968A0_E38F_4434_B511_EE50E0BD0A5A" precision="1"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_94B8472E_5F5B_4f87_B89F_70B2B293D187"
name="TimeDurationMeasurementAxisIntegerSeconds" description="Measurement axis for time duration in
integer seconds." precision="1" measurementSystemAxis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_3F6678FA_B48F_41b2_8C42_35C4BC3901C0"
name="TimeDurationMeasurementAxisIntegerMicroseconds" description="Measurement axis for time
duration in integer microseconds." valueTypeUnit="EAID_53D339BB_B8AB_4c87_8FCE_EF87F0CB7BEF"
precision="1" measurementSystemAxis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_3457128D_EDE7_4e41_9D0F_E05E81B52C4A"
name="TimeDurationMeasurementAxisIntegerMilliseconds" description="Measurement axis for time
duration in integer milliseconds." valueTypeUnit="EAID_C9419C4D_A541_4810_82FB_FC6266B893DD"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_9850C6AD_C2FE_44b1_B2E2_D25EE8E548B5"
name="TimeDurationMeasurementAxisIntegerNanoseconds" description="Measurement axis for time
duration in integer nanoseconds." valueTypeUnit="EAID_8FAB4588_E952_4394_AA69_083EAF893AF4"
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_C60479DC_124E_4445_82B5_55F128A30016"
name="TimeDurationMeasurementAxisRealSeconds" description="Time duration measurement axis for
measure in real seconds." valueTypeUnit="EAID_A558BC68_B8EF_43d8_8889_65E126114613"
precision=".000001" measurementSystemAxis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42"
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_88109987_2B7A_4359_BF72_824220B1B26D"
name="TimeDurationMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_4C31C156_E6E2_4115_AF63_8794199664AA"
name="TimeDurationMeasurementSystem" description="Measurement system for time duration."
externalStandardReference="International System of Units - Second" orientation="Value increases
as time moves towards the future">
xmi:id="EAID_8E969EF7_1154_4619_88E5_A384897359FF" name="ZeroDurationReferencePoint"
description="Duration origin" landmark="EAID_3149A12E_1AB1_4ffd_9D14_1466FA5DCDE0">
xmi:id="EAID_3632CAB3_6D8C_4605_A19E_449E330C68CE"
axis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42" value="0.0"
valueTypeUnit="EAID_D4E6F91B_E17A_42b5_9D3F_A5A852B8519E"/>
</referencePoint>
xmi:id="EAID_E1F77F65_7D13_4ac2_B7FE_207A831259B4" name="OneSecondDurationReferencePoint"
description="Duration on positive one second"
landmark="EAID_26121EAF_96C4_4e3b_90B5_568E427782FE">
xmi:id="EAID_6326CE28_99C7_4c52_9584_D40D5451D565"
axis="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42" value="1.0"
</referencePoint>
</element>
xmi:id="EAID_13D5B7DF_48FF_4ad4_B66E_AA8AD7621A42" name="TimeDurationMeasurementSystemAxis"
description="Axis for time duration in seconds" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_D4E6F91B_E17A_42b5_9D3F_A5A852B8519E"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_69800871_BDC1_4b18_8A05_965A0D6AA56B"
name="PosixTimeMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_3E078B08_3024_4dfe_B01E_74929C579251"
name="PosixTimeMeasurementSystem" description="Measurement system for time in accordance with
the Posix." measurementSystemAxis="EAID_789E08B1_DC02_497e_A8C9_75BC1AB027CD"
coordinateSystem="EAID_D73E1979_E607_48ce_A01F_2EAD5226614D" externalStandardReference="IEEE Std
1003.1-2008" orientation="Value increases as time moves towards the future">
xmi:id="EAID_BD9DFD8C_8109_4fca_AE6D_751BDFE80A13" name="PositiveOneSecondAfterEpochStart"
description="Duration on positive one second"
landmark="EAID_26121EAF_96C4_4e3b_90B5_568E427782FE">
xmi:id="EAID_4412FD57_2CF3_444c_81F6_A45CDB5C4DB3"
axis="EAID_789E08B1_DC02_497e_A8C9_75BC1AB027CD" value="1"

</referencePoint>
xmi:id="EAID_284CB1EC_7ABC_4b2a_9318_7BC671B9CE47" name="PosixEpochTimeStart"
description="POSIX/Unix time origin" landmark="EAID_E3DB5E79_28F5_4546_AF37_5C5C59EAA687">
xmi:id="EAID_100655DF_5991_4cfa_AE21_558FBE47C299"
axis="EAID_789E08B1_DC02_497e_A8C9_75BC1AB027CD" value="0"
</referencePoint>
</element>
xmi:id="EAID_789E08B1_DC02_497e_A8C9_75BC1AB027CD" name="PosixTimeMeasurementSystemAxis"
description="Axis for time durationin seconds since Epoch Start."
defaultValueTypeUnit="EAID_D4E6F91B_E17A_42b5_9D3F_A5A852B8519E"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A01C0685_A0EE_4fbb_BF7F_DC92C48FB6EB"
name="UTC_TimeOfDayMeasurementSystem">
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_C5B2FCE6_50D5_49bd_B283_E3C5F1C922CC"
name="UTC_TimeOfDayMeasurementSystem" description="Measurement system for time duration in
seconds" measurementSystemAxis="EAID_A9475213_1F9D_4967_9F5B_5454DF64813D"
externalStandardReference="Universal Coordinated Time" orientation="Value increases as time
moves towards the future">
xmi:id="EAID_1C36C981_7243_4fa0_B185_9A11CCA96E08" name="UTC_DayStart" description="Start of
UTC day" landmark="EAID_07D5AF61_422D_4fff_8E3F_EBADE19C9743">
xmi:id="EAID_27226E3A_C2A6_46ba_8D1C_71C6EB8FB7FF"
axis="EAID_A9475213_1F9D_4967_9F5B_5454DF64813D" value="0"
xmi:id="EAID_5E09C042_D984_4514_9904_00741A524CBC"
xmi:id="EAID_E319846B_6F59_4dd6_8088_2755F5A8DAB7"
</referencePoint>
xmi:id="EAID_EDF032ED_4EB4_4a22_B0CB_7B3105DFB92D" name="UTC_Noon" description="Noon of UTC
day" landmark="EAID_0F3F8CEA_7F8A_4d9d_B338_692BCEA4F9EB">
xmi:id="EAID_B353EF9D_A365_4da1_8A0E_C7764A5AB1E3"
xmi:id="EAID_4D1379E6_76B2_472c_839F_E1BA41E08195"
xmi:id="EAID_7A741ED7_A134_44a9_BBD3_645A68289BFF"
</referencePoint>
</element>
xmi:id="EAID_A9475213_1F9D_4967_9F5B_5454DF64813D" name="UTC_TimeOfDayMeasurementSystemAxis"
description="Axis for time duration in HMS" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_7CE0FD03_E2B8_4a2b_BEF3_AC063A10AF19
EAID_6BBAF578_C863_44a7_A3E6_EDCF0E358B65 EAID_C6177F0A_A31C_496d_8F54_D3C02C9FA020"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C92F89A2_E3B1_49b7_8456_685F37F21356"
name="TimeLandmarks">
<element xmi:type="logical:Landmark" xmi:id="EAID_712C56C3_07E9_4693_B56E_4DD0BD9C13A3"
name="GregorianCalendarOrigin" description="Beginning of year 0 (1/1/0 0:00:00) per Pope Gregory's
bull in 1582, to reform the Julian calendar to set the date for Easter to the time the First
Council of Nicaea had agreed to in 325."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_26121EAF_96C4_4e3b_90B5_568E427782FE"
name="OneSecondDurationLandmark" description="One second duration landmark."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_526E5000_ED7A_408d_86CD_65EEED91050F"
name="SpecificGregorianDayStart" description="The moment that a specified day of a specified month
of a specified year starts. e.g. 0:00:0 of Feb 12, 2000."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_D15D3A25_475C_4597_A3C8_D1BCE85BA908"
name="SpecificGregorianMonthStart" description="The moment that a specified month of a specified
year starts. e.g. 0:00:0 of Feb 1, 2000."/>
<element xmi:type="logical:Landmark" xmi:id="EAID_0114BCB1_A3F4_44b0_B710_D128C24A8C58"
name="SpecificGregorianYearStart" description="The moment that a specified year starts (0:00:00 on
Jan 1 of specified year)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_DE454468_5239_4a39_81AC_B71B1EEAC2CA"
name="SpecificTimeOfDay" description="The time duration between the specified time and the start of
the specified Gregorian day"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_E3DB5E79_28F5_4546_AF37_5C5C59EAA687"
name="UnixEpochStart" description="Start of Unix Epoch (Jan 1, 1970 0:00:00)"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_07D5AF61_422D_4fff_8E3F_EBADE19C9743"
name="UTC_DayStart" description="The moment that a specified UTC day of a specified month of a
specified year starts. e.g. 0:00:00 Zulu"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_0F3F8CEA_7F8A_4d9d_B338_692BCEA4F9EB"
name="UTC_Noon" description="12 hours after the start of a specified UTC day of a specified month
of a specified year. e.g. 12:00:00 Zulu"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_3149A12E_1AB1_4ffd_9D14_1466FA5DCDE0"
name="ZeroDurationLandmark" description="A zero second duration meaning no time has elapsed."/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_59C3F554_23B6_4bf8_A0F8_107DDD00657E"
name="ViscosityMeasures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_057CBEFA_AE56_4c92_9C84_8EC23BBF9DDA"
name="DynamicViscosityMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_B31A800C_880E_4285_8914_12871094C4EE"
name="RealPascalSeconds" description="Real numeric value for dynamic viscosity in SI units of
Pascal-seconds" unit="EAID_1C753236_2F55_4424_9CA3_47AD45CC4934"
<element xmi:type="logical:Landmark" xmi:id="EAID_2F0D69A5_4129_4c17_9019_E5E7887CF69B"
name="DynamicViscosityOfWaterAt100DegreesC" description="Dynamic viscosity of liquid water at100
degrees Celsius"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_4A5A23A8_A843_4a9e_AD4A_123D5C05C2E1"
name="DynamicViscosityOfWaterAt20DegreesC" description="Dynamic viscosity of liquid water at 20
degrees Celsius"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_ABE06F26_4180_4736_BB0D_CF8FE9B05010"
name="DynamicViscosityMeasurementSystem" description="Measurement system for dynamic (shear)
viscosity." measurementSystemAxis="EAID_2CA8F2E2_0148_48c7_BA65_555A7CEED7EF"
orientation="Values increase as viscosity increases">
xmi:id="EAID_EB720FFC_942A_41de_88DE_362C5C31D500" name="WaterDynamicViscosityAt100DegreesC"
description="Reference point for dynamic viscosity of liquid water at100 degrees Celsius"
landmark="EAID_2F0D69A5_4129_4c17_9019_E5E7887CF69B">
xmi:id="EAID_9B78B3A4_8A08_49f0_92DC_44D610044196"
axis="EAID_2CA8F2E2_0148_48c7_BA65_555A7CEED7EF" value="0.0002822"
valueTypeUnit="EAID_B31A800C_880E_4285_8914_12871094C4EE"/>
</referencePoint>
xmi:id="EAID_D7BF3B19_656B_49c8_A910_3A29EB42B993" name="WaterDynamicViscosityAt20DegreesC"
description="Dynamic viscosity of liquid water at 20 degrees Celsius"
landmark="EAID_4A5A23A8_A843_4a9e_AD4A_123D5C05C2E1">
xmi:id="EAID_53BE9E6D_168D_445f_86D8_65FE73FA216C"
axis="EAID_2CA8F2E2_0148_48c7_BA65_555A7CEED7EF" value="0.001002"
valueTypeUnit="EAID_B31A800C_880E_4285_8914_12871094C4EE"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_2CA8F2E2_0148_48c7_BA65_555A7CEED7EF"
name="DynamicViscosityMeasurementSystemAxis" description="Measurement system axis for dynamic

(shear) viscosity in SI units of pascal-seconds" axis="EAID_3EFC05DA_4D3A_4e3d_8AEC_C9FEC8D85087"
defaultValueTypeUnit="EAID_B31A800C_880E_4285_8914_12871094C4EE"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_0C15A43D_D229_46d4_A5A7_D1A5F3B8D746"
name="DynamicViscosityMeasurement" description="Measurement for dynamic (shear) viscosity"
measurementAxis="EAID_E327EBE0_C09F_4407_AA4D_FC87B9365598"
measurementSystem="EAID_ABE06F26_4180_4736_BB0D_CF8FE9B05010"
realizes="EAID_C58154E2_40C4_466f_AAF2_CF0751E434A6"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_E327EBE0_C09F_4407_AA4D_FC87B9365598"
name="DynamicViscosityMeasurementAxis" description="Measurement axis for dynamic (shear) viscosity
in " precision=".0000001" measurementSystemAxis="EAID_2CA8F2E2_0148_48c7_BA65_555A7CEED7EF"
realizes="EAID_C58154E2_40C4_466f_AAF2_CF0751E434A6"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B7D3BF1B_779E_4a9d_A41D_532267932C39"
name="KinematicViscosityMeasures">
<element xmi:type="logical:ValueTypeUnit" xmi:id="EAID_C5E6300B_BD72_485e_83C1_63975AF70D50"
name="RealSquareMetersPerSecond" description="Real numeric value for kinematic viscosity in SI
units of m^2/sec" unit="EAID_9B5D0AEF_2419_442d_B413_AD98445E7BC7"
<element xmi:type="logical:Landmark" xmi:id="EAID_BB1C688B_89B0_4870_91D0_859F5FF6528B"
name="KinematicViscosityOfGycerineAt20point3DegreesC" description="Kinematic viscosity of glycerine
at 20.3 degrees Celsius"/>
<element xmi:type="logical:Landmark" xmi:id="EAID_1EC36204_738B_488c_91FF_A5D749D60501"
name="KinematicViscosityOfWaterAt20DegreesC" description="Kinematic viscosity of liquid water at 20
degrees Celsius"/>
<element xmi:type="logical:MeasurementSystem" xmi:id="EAID_426F4C83_FAFB_42ae_BA99_51EF798EA3CD"
name="KinematicViscosityMeasurementSystem" description="Measurement system for kinematic viscosity"
measurementSystemAxis="EAID_3D69C939_50F0_4bf9_8699_8CCB6784F721"
orientation="Values increase as viscosity increases.">
xmi:id="EAID_5323E41C_24F5_4555_9F35_FF80A60D65D0" name="WaterKinematicViscosityAt20DegreesC"
description="Reference point for kinematic viscosity of liquid water at 20 degrees Celsius"
landmark="EAID_1EC36204_738B_488c_91FF_A5D749D60501">
xmi:id="EAID_B7D20687_4C07_4838_BDCC_4DCBBB36E5D0"
axis="EAID_3D69C939_50F0_4bf9_8699_8CCB6784F721" value="0.000001038"
valueTypeUnit="EAID_C5E6300B_BD72_485e_83C1_63975AF70D50"/>
</referencePoint>
xmi:id="EAID_9227B12E_F220_488c_A7F4_AB3595EE4C96"
name="GlycerineKinematicViscosityAt20point3DegreesC" description="Reference point for kinematic
viscosity of glycerine at 20.3 degrees Celsius"
landmark="EAID_BB1C688B_89B0_4870_91D0_859F5FF6528B">
xmi:id="EAID_F0509B19_F852_44cc_8FFC_8EF7C7E55C77"
axis="EAID_3D69C939_50F0_4bf9_8699_8CCB6784F721" value="0.000648"
valueTypeUnit="EAID_C5E6300B_BD72_485e_83C1_63975AF70D50"/>
</referencePoint>
</element>
<element xmi:type="logical:MeasurementSystemAxis" xmi:id="EAID_3D69C939_50F0_4bf9_8699_8CCB6784F721"
name="KinematicViscosityMeasurementSystemAxis" description="Measurement system axis for kinematic
viscosity in SI units of meters squared per second"
defaultValueTypeUnit="EAID_C5E6300B_BD72_485e_83C1_63975AF70D50"/>
<element xmi:type="logical:Measurement" xmi:id="EAID_F4954C31_9D48_4d0e_977D_C0B54AE0B5B6"
name="KinematicViscosityMeasurement" description="Measurement for kinematic viscosity"
measurementAxis="EAID_0B64D617_7FAB_4939_97C0_3998C5D76296"
measurementSystem="EAID_426F4C83_FAFB_42ae_BA99_51EF798EA3CD"
realizes="EAID_9894902C_4D24_43b6_9EA0_3FC535B15003"/>
<element xmi:type="logical:MeasurementAxis" xmi:id="EAID_0B64D617_7FAB_4939_97C0_3998C5D76296"
name="KinematicViscosityMeasurementAxis" description="Measurement axis for kinematic viscosity in
square meters per second" precision=".000000001"
measurementSystemAxis="EAID_3D69C939_50F0_4bf9_8699_8CCB6784F721"
realizes="EAID_9894902C_4D24_43b6_9EA0_3FC535B15003">
xmi:id="EAID_30AC859B_0BDF_414e_8667_BCB31F729535" constraintText="Always >= 0"/>
</element>
</ldm>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_7F48F8D3_EBBB_43d4_A3FC_28E4C02FD6D7" name="Units">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E119CB56_8C90_4344_9234_48BC281646E1"
name="ElectricChargedDensity">
<element xmi:type="logical:Unit" xmi:id="EAID_DED3DC3D_2228_4180_9A4F_CF994B64B6CF"
name="CoulombsPerMeter" description="Coulombs per meter"/>
<element xmi:type="logical:Unit" xmi:id="EAID_90D9E4E8_7A91_4dd4_A96E_DF01C3157644"
name="CoulombsPerMeterCubed" description="Coulombs per meter cubed."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C784CF8E_F7F8_4370_865A_33FDF5B0CF44"
name="CoulombsPerMeterSquared" description="Coulombs per meter squared"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1155820A_4F2D_4c2a_AE88_C07FB1D7DCEE"
name="ElectricCurrentDensity">
<element xmi:type="logical:Unit" xmi:id="EAID_1B59A0CB_A750_4fde_B861_3C0FBACB9E7B"
name="AmpPerSquareMeter" description="Unit of measure for representing one amp of electric current
flowing through a material with a cross-sequential area of one square meter."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_34A3104E_B9CC_4d0c_B1ED_7A8A9A725886"
name="Percentage">
<element xmi:type="logical:Unit" xmi:id="EAID_68A9F947_C54C_4c06_84C6_29E302284981" name="Percentage"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_141C89BD_8FBF_4ba9_8C07_06EA541A4D65"
name="AbsorbedDose">
<element xmi:type="logical:Unit" xmi:id="EAID_06F05060_CF06_4f65_A9AF_75CA9D6D4343" name="Grays"
description="Unit of measure for the absorption of on joule of radiation energy by one kilogram or
matter."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A48F5144_B237_48e3_95DE_91E8428E64AC"
name="AbsorbedDoseRate">
<element xmi:type="logical:Unit" xmi:id="EAID_F8CE6A2C_0E47_4f2f_88E0_5F255664DCDA"
name="GraysPerSecond" description="Unit of measure for the rate of the absorption of on joule of
radiation energy by one kilogram or matter over a one second of time."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F0484DCD_1396_4317_A8A3_067DDB8A1CC3"
name="Acceleration">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_06176F99_5497_4016_AB99_E148D5C196E8"
name="AngularAcceleration">
<element xmi:type="logical:Unit" xmi:id="EAID_8864E77B_D4D8_4491_8145_285B1F8959A2"
name="DegreesPerSecondPerSecond" description="Unit of measure for the rate of change of an angular
speed in which the base angular measure unit is degees."/>
<element xmi:type="logical:Unit" xmi:id="EAID_F2444AAF_68C5_4355_8AB0_5BFC0A73975F"
name="RadiansPerSecondPerSecond" description="Unit of measure for the rate of change of an angular
velocity in which the base angular measure unit is radian."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_341B2966_715A_4534_BA74_851528FAF3AE"
name="LinearAcceleration">
<element xmi:type="logical:Unit" xmi:id="EAID_FCADE251_5B0A_4336_9E35_DE698096B06F"
name="FeetPerSecondPerSecond" description="Unit of measure for the rate of change of velocity in
which the base distance measure traveled is feet."/>
<element xmi:type="logical:Unit" xmi:id="EAID_9B5484D4_F922_407d_9E61_17E56532FDD8"
name="KnotsPerSecondPerSecond"/>
<element xmi:type="logical:Unit" xmi:id="EAID_59A485AE_23F2_4b2d_87E7_18ECB59553EE"
name="MetersPerSecondPerSecond" description="Unit of measure for the rate of change of velocity in
which the base distance measure traveled is meters."/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_07C807C7_A137_4da8_A9B6_E4317F682AC7"
name="AmountOfConcentration">
<element xmi:type="logical:Unit" xmi:id="EAID_0B528C0C_B50B_4152_89FE_09BA977E13FE"
name="MolesPerCubicMeter" description="Unit of measure for the number of atoms of a substance per
unit volume."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_92823862_B9DB_4795_8B2E_8C0F397E54C3"
name="AmountOfSubstance">
<element xmi:type="logical:Unit" xmi:id="EAID_81285D76_2D91_4edd_B41D_009A1301FB63" name="Moles"
description="Unit of measure to express amounts of a chemical substance, defined as the amount of any

substance that contains as many elementary entities as there are atoms in 12 grams of pure carbon-
12."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8E0AE736_DA76_4d8e_904C_1A89CB353790" name="Angle">
<element xmi:type="logical:Unit" xmi:id="EAID_6BE551B4_AC4C_467d_8264_95EB34EF81FE" name="DegreesOfArc"
description="Unit of measure for a plane angle representing 1/360 of a full rotation. Not an SI
unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_B852B3B4_206E_400b_B352_D86D2DC60748" name="Gradians"
description="Unit of measure for a pane angle representing 1/400 of a full rotation. Not an SI
unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_8BCEBA5A_6555_4984_B381_F8F96DA34437" name="MinutesOfArc"
description="Unit of measure for angular measurement equal to 1/60 of one degree, because one degree
is 1/360 of a circle, one minute of arc is 1/21,600 of a circle."/>
<element xmi:type="logical:Unit" xmi:id="EAID_DDC5A152_31FF_4e32_815A_3A1EE216C85A" name="Radians"
description="Unit of measure for angular measurement equal to the length of a corresponding arc of a
unit circle, one radian is just under 57.3 degrees. It is a SI derived unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_D4279E45_927A_442f_AC92_E62BA52F5D2C" name="SecondsOfArc"
description="Unit of measure for angular measurement equal to 1/60 of one minute because one degree
is 1/360 of a circle, one minute of arc is 1/21,600 of a circle and one second of arc is
1/1296000."/>
<element xmi:type="logical:Unit" xmi:id="EAID_7D11C92B_E44B_451f_BBE2_88A81B7C9D6F" name="Turns"
description="Unit of measure for angular measurement equal to 360 degrees or 2 pi radians. 1
revolution."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_868CF58F_8777_4443_9E23_8D155F08799B" name="Area">
<element xmi:type="logical:Unit" xmi:id="EAID_579A46B3_B398_4030_9A44_1D66192DE8DE" name="Acres"
description="Unit of measure for land area in US and Britain, defined as 1/640 of a square mile."/>
<element xmi:type="logical:Unit" xmi:id="EAID_5D6C29C2_C26C_4503_AE5B_AF304582BFAF" name="Barns"
description="Unit of measure for area in nuclear physics expressing the cross sectional are of nuclei
and nuclear reactions. Is approximately the cross sectional area of a uranium's nucleus."/>
<element xmi:type="logical:Unit" xmi:id="EAID_90E8AA70_4288_4042_B946_342AAE7B015D" name="Hectares"
description="Unit of measure in the meter system for land area defined as 10,000 square meters."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A4DFC00C_AF69_43aa_865D_A4574343F7A1" name="SquareFeet"
description="Unit of measure for area equal to a square measuring one foot on each side, not an SI
unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_85A3E015_825D_426b_A14C_6FE8FADD7F5B"
name="SquareKilometers" description="Unit of measure is a decimal multiple of the surface area
measure square meters, and is a derived SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C4A8FCC1_585A_4d82_B7BF_606489503F25" name="SquareMeters"
description="Unit of measure for surface area equal to a square measuring one meter on each side, and
is a derived SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_8C7E4423_1F5E_47c9_A4FE_AC528FC574E8" name="SquareMiles"
description="Unit of measure for area equal to the area of a square of on statute mile, not an SI
unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1D757B7B_AA6B_475c_BC94_5ED6388E1449"
name="CatalyticActivity">
<element xmi:type="logical:Unit" xmi:id="EAID_67C6498E_77C1_46dd_8018_6577637A7D29" name="Katals"
description="Unit of measure for quantifying the catalytic activity of enzymes and other catalysts,
is SI unit of catalytic activity."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_3531245C_4691_4b68_8CE9_55B9BABF3E4A"
name="CatalyticActivityConcentration">
<element xmi:type="logical:Unit" xmi:id="EAID_DFCFB2F0_47C7_4242_8272_E2F55BE621CB"
name="KatalsPerCubicMeter" description="Unit of measure for quantifying catalytic activity per unit
or volume."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_7CE279C0_C759_484e_A956_5A39A5BBB743" name="Density">
<element xmi:type="logical:Unit" xmi:id="EAID_8E188C8D_CA5B_49d9_B4B7_1E01E451F88D"
name="CoulombsPerCubicMeter" description="Unit of measure for representing one coulomb of electric
charge per one cubic meter of volume."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E991E9BF_F0B8_4b0f_80B6_9BCA1639DC0C"
name="CoulombsPerSquareMeter" description="Unit of measure for representing one coulomb of electric
charge per one square meter of surface."/>
<element xmi:type="logical:Unit" xmi:id="EAID_16B1EB25_69FB_469a_B7CD_6D74B1A9AA42" name="Density"/>
<element xmi:type="logical:Unit" xmi:id="EAID_24DF0495_0101_413a_8B3E_5132DFC4095F"
name="JoulesPerCubicMeter" description="Unit of measure for representing useful energy in joules
released from on cubic meter of fuel volume during complete combustion."/>
<element xmi:type="logical:Unit" xmi:id="EAID_BE2795B1_06AD_4261_B7E8_8A4F4D94FC84"
name="KilogramsPerSquareMeter" description="Unit of measure for representing surface density in mass
per unit area."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3B4BB6FB_6B1F_4b41_8EAA_24C1CA377436"
name="WattsPerSquareMeter" description="Unit of measure for representing the rate one watt of heat
energy to flow through one square meter of area normal to the direction of heat flux. Derived SI
Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2666FD95_0B38_4c4a_8681_F3A9B32C257E"
name="DerivedUnits">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_31A71A77_D00A_4a7c_8BC2_24DEA8414740" name="Ratios">
<element xmi:type="logical:Unit" xmi:id="EAID_EB709A75_CD50_4887_8E40_086CE821CBAA"
name="AmpPerMeter" description="Unit of measure for representing a magnetic field strength. Derived
SI unit"/>
<element xmi:type="logical:Unit" xmi:id="EAID_D51FFEB5_1DE1_416b_8794_3EBECB2C3ABC" name="Bels"
description="Unit of measure for representing the comparison of the power levels in electrical
communication or sound."/>
<element xmi:type="logical:Unit" xmi:id="EAID_311835BB_B20D_434d_8CBD_F5E857464151"
name="CubicMetersPerKilogram" description="Unit of measure for representing specific volume of a
substance as the ratio of the substance's volume per mass, the reciprocal of density."/>
<element xmi:type="logical:Unit" xmi:id="EAID_00C18C06_4B39_4c90_97AC_8F3E5B3A70BF" name="Decibels"
description="Unit of measure for representing the intensity of sound."/>
<element xmi:type="logical:Unit" xmi:id="EAID_825A32F7_E47C_467e_8BF1_6A7D8010ABE6"
name="JoulesPerKelvin" description="Unit of measure for representing heat capacity or entropy.
Derived SI unit"/>
<element xmi:type="logical:Unit" xmi:id="EAID_5D20F6EE_0253_4544_87B4_058BA94B36AD"
name="JoulesPerKilogram" description="Unit of measure for representing specific energy per unit
mass. Derived SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_784D140F_A7CF_48d8_8732_26AD73355194"
name="JoulesPerKilogramKelvin" description="Unit of measure for representing specific heat
capacity, which is the heat capacity per unit mass of a material. Derived SI Unit"/>
<element xmi:type="logical:Unit" xmi:id="EAID_E998A459_D274_4ecc_A138_88BE059E72A3"
name="KilogramsPerCubicMeter" description="Unit of measure for material density. Derived SI Unit"/>
<element xmi:type="logical:Unit" xmi:id="EAID_40659D46_18A7_4bdf_A4E2_B6DB4B5FE62B"
name="LitersPerHour" description="Unit of measure for volume flow rate."/>
<element xmi:type="logical:Unit" xmi:id="EAID_02B18938_8AD8_4ec0_A8C2_B7DFFCC1CE8E"
name="MillimetersPerHour" description="Unit of measure for representing the number of millimeters
traveled in one hour used in speed and velocity metrics."/>
<element xmi:type="logical:Unit" xmi:id="EAID_6FE784C0_3B93_4de4_B23A_0A5E83DCDFBA" name="Nepers"
description="Unit of measure for representing the ratio of two current, voltages, or analogous
quantities. Not an SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_393B5A6F_990A_4186_92E8_F6BA2012123D"
name="NewtonsPerMeter" description="Unit of measure for representing surface tension in force per
unit length. SI Derived unit"/>
<element xmi:type="logical:Unit" xmi:id="EAID_E4A57064_F91E_4cea_8915_E2586756CC3E"
name="RevolutionsPerMinute" description="Unit of measure for representing the frequency of
rotation."/>
<element xmi:type="logical:Unit" xmi:id="EAID_9948928A_E5D5_4399_81B8_D1B7A8D0D017"
name="WattsPerSteradian" description="Unit of measure for representing the radiant intensity of an
object."/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BC922F67_DA3D_4cf0_8EB2_27B5FCFE7E09" name="DryVolume">
<element xmi:type="logical:Unit" xmi:id="EAID_4E83620B_DF8D_4a73_BCD8_CFCE5F8CE838" name="Bushels"
description="Unit of measure for representing the capacity used for dry goods."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3C7531E9_39D0_4c97_92DF_6EE768E48340" name="DryBarrels"
description="Unit of measure for representing the volume for dry materials."/>
<element xmi:type="logical:Unit" xmi:id="EAID_03EC1A39_CC6B_425c_A594_99607CEC301D" name="Gallons"
description="Unit of measure for representing the capacity of liquid measures."/>
<element xmi:type="logical:Unit" xmi:id="EAID_66072D3A_A38C_4f03_B011_ACBCB092388E" name="Pecks"
description="Unit of measure for representing the capacity used for dry goods, equal to 1/4 of a
bushel."/>
<element xmi:type="logical:Unit" xmi:id="EAID_0B14534E_61DC_4b30_BA8A_1B4CAEE4707B" name="Pints"
description="Unit of measure for representing the capacity of liquid or dry goods, equal to 1/2 of a
quart."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3716B9AA_FCB9_48c8_B7C4_6A14551BE748" name="Quarts"
description="Unit of measure for representing the capacity of liquid or dry goods, equal to 1/4 of a
gallon."/>

</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_48235C2B_6A88_44d9_8D89_C6B2AB511F64"
name="ElectricCharge">
<element xmi:type="logical:Unit" xmi:id="EAID_611BFBF3_9651_4770_BEED_69B1E5BA509A" name="AmpHour"
description="Unit of measure for representing the electric charge noting the amount of electricity
transferred by a current of one amp in one hour."/>
<element xmi:type="logical:Unit" xmi:id="EAID_F0BEB8DA_1C6E_43a8_A030_C04F74B8E417" name="Coulombs"
description="Unit of measure for representing the electric charge, equal to the quantity of
electricity conveyed in one second by a current of one amp."/>
<element xmi:type="logical:Unit" xmi:id="EAID_8837C190_8C86_48d4_88A1_AB1DA8E83D36"
name="MilliAmpHours" description="Unit of measure for representing the electric charge which is
1000th of an amp hour."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_17544AD5_99C8_431e_9230_A18EB54B2344"
name="ElectricCurrent">
<element xmi:type="logical:Unit" xmi:id="EAID_1BC72413_1442_4d9a_BBC6_5D13EA4B334F" name="Amp"
description="Unit of measure for representing the rate at which electric current flows."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C5C03122_CF73_47ec_8478_2807E78D3CB0" name="MilliAmp"
description="Unit of measure for representing small electric currents, 1000th of an amp."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_D765AAFC_D4C8_42a2_9ACB_45F8FDB3C6C9"
name="ElectricFieldStrength">
<element xmi:type="logical:Unit" xmi:id="EAID_F891B933_289F_4ef0_9131_3FF6843D84F4"
name="VoltsPerMeter" description="Unit of measure for representing electric field strength. An SI
Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2F1A2D15_E3D5_481a_B6B2_21EFA023BBB2"
name="ElectricalCapacitance">
<element xmi:type="logical:Unit" xmi:id="EAID_2DEC664F_516A_499d_A29B_661CC1D8C7B2" name="Farads"
description="Unit of measure for representing the capacitance of a capacitor across which one coulomb
of charge causes a potential difference of one volt. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F21DDA2E_6B43_4465_AC12_4EE82DAD6D9F"
name="ElectricalConductance">
<element xmi:type="logical:Unit" xmi:id="EAID_35FE1B11_2FBC_48c9_BC83_5FBACCC37648" name="Siemens"
description="Unit of measure for representing electrical conductance equal to 1 reciprocal ohm. An SI
unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_DD382BB0_A1C7_4ad2_B829_1460CDE07A8B"
name="ElectricalResistance">
<element xmi:type="logical:Unit" xmi:id="EAID_5ED25A27_0996_4f32_92CE_6FCC0BAB86A9" name="KiloOhms"
description="Unit of measure for representing electrical resistance equal to 1000 ohms."/>
<element xmi:type="logical:Unit" xmi:id="EAID_51EC828B_E415_4906_8F6E_022EEF6545A7" name="MegaOhms"
description="Unit of measure for representing electrical resistance equal to 1,000,000 ohms."/>
<element xmi:type="logical:Unit" xmi:id="EAID_86DA43C5_3454_4f35_9359_E73F1FA7A235" name="Ohms"
description="Unit of measure for representing electrical resistance of a circuit in which an
electromotive force of one volt maintains a current of one amp. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6CDBE16D_652A_4e06_AB94_87B0AB825592" name="Energy">
<element xmi:type="logical:Unit" xmi:id="EAID_6BEAC65A_17AD_49d0_A7D3_0A49C14B7489" name="Joules"
description="Unit of measure for representing the work done by a force of one newton when its point
of application moved one meter in the direction of action of the force. An SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_ABE41825_9C94_44f1_8193_DA019AF6540E"
name="KilowattHours" description="Unit of measure for representing electrical energy equivalent to a
power consumption of 1,000 watts for 1 hour."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C4EEB582_915F_457c_90BA_1CDB5A7D47B6" name="Entropy"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2D1B5992_D34F_475c_AC12_E41665A3D76D"
name="EquivalentDose">
<element xmi:type="logical:Unit" xmi:id="EAID_FEF61F65_30EA_4429_BF95_EC1A4A8AC7E7" name="Sieverts"
description="Unit of measure for representing dose equivalent, equal to an effective dose of a joule
of energy per kilogram of recipient mass. An SI Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_97441F90_FD0E_471e_A91C_E6A630DD00CA" name="Exposure">
<element xmi:type="logical:Unit" xmi:id="EAID_6440D768_FDAB_40bb_8BAC_9FA4C7C72394"
name="CoulombsPerKilogram" description="Unit of measure for representing radiation exposure in which
electrical charges (ion pairs) in a kilogram of air. An Derived SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_EADEC90A_9D10_4328_9A03_84D925C7EDE4"
name="FluidVolume">
<element xmi:type="logical:Unit" xmi:id="EAID_4DD8AE21_0EB0_492f_8BBF_048D399C924F" name="CupsUS"
description="Unit of measure for representing the customary cup for cooking ingredients and is
defined as 1/2 of a US Pint."/>
<element xmi:type="logical:Unit" xmi:id="EAID_F1B57A45_867B_4808_936F_6C4F1F50EF10" name="FluidDramsUS"
description="Unit of measure for representing the volume or capacity in the apothecary system, equal
to 1/8 of a fluid ounce."/>
<element xmi:type="logical:Unit" xmi:id="EAID_0976132A_E70B_4d8f_B219_B8E01258897D"
name="FluidOuncesUS" description="Unit of measure for representing the volume or capacity in the US
Customary System used liquid measure."/>
<element xmi:type="logical:Unit" xmi:id="EAID_13E19836_0B3F_4546_8FB5_5C2F7170F7F6" name="GallonsUS"
description="Unit of measure for representing the liquid volume or capacity in the US Customary
System equal to 4 quarts."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E48F9A6C_D5FF_4ee5_AD73_429FF52D50D7" name="GillsUS"
description="Unit of measure for representing the liquid volume, defined as 1/2 a cup in the US
Customary System."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A5C59AE1_1DF6_4cf7_8D52_99A1D52461BA"
name="LiquidBarrels" description="Unit of liquid measure for representing 42 gallons or 5.6145833
cubic feet."/>
<element xmi:type="logical:Unit" xmi:id="EAID_253BAAF2_22DF_4e68_B114_3947BF549D8C" name="Liters"
description="Unit of measure for representing the volume of on kilogram of pure water at 4 Degrees
Celsius and standard atmospheric pressure."/>
<element xmi:type="logical:Unit" xmi:id="EAID_DA6FF1E2_BE3B_4d32_B429_82D068FE4855" name="Minims"
description="Unit of measure for representing the smallest unit of liquid measure 1/60 of a fluid
dram, or roughly equivalent to one drop."/>
<element xmi:type="logical:Unit" xmi:id="EAID_11AAA861_4C74_4f26_BA69_9D7BA3EAC5FD" name="OilBarrels"
description="Unit of measure for representing an oil barrels holding 42 US gallons."/>
<element xmi:type="logical:Unit" xmi:id="EAID_896D563A_1CED_48f3_AD92_234DF3ADEE9F" name="PintsUS"
description="Unit of measure for representing volume or capacity in US Customary System, used in
liquid measure and equal to 1/8 gallons."/>
<element xmi:type="logical:Unit" xmi:id="EAID_9448BB79_C145_432f_90B7_2535DAB51CED" name="QuartsUS"
description="Unit of measure for representing volume or capacity in US Customary System, used in
liquid measure and equal to 1/4 of a US gallon."/>
<element xmi:type="logical:Unit" xmi:id="EAID_0BC25F42_D33B_4780_82D8_7508088534AE" name="Tablespoons"
description="Unit of measure for representing 1/2 a fluid ounce or 3 teaspoons typically used as a
measure for cooking."/>
<element xmi:type="logical:Unit" xmi:id="EAID_B5226835_2703_4f5b_9837_13DE5347B9C6" name="Teaspoons"
description="Unit of measure for representing a small spoon used in cooking equivalent 1/6 fluid
ounce."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4D16D625_6245_4ddc_A597_C7A4FE9AA71B" name="Force">
<element xmi:type="logical:Unit" xmi:id="EAID_F4C79394_2908_4acb_9317_6E30C94B489D" name="Dyns"
description="Unit of measure for representing a unit of force specified in the Centimeter Gram Second
system of units."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3F9CBF28_F842_4896_ABEC_B4498760BD80" name="Newtons"
description="Unit of measure for representing the force that would give a mass of one kilogram an
acceleration of on meter per second per second and is equivalent to 100,000 dynes. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A521DBEC_C8C6_4ab0_A723_98FF5C6418B9" name="Frequency">
<element xmi:type="logical:Unit" xmi:id="EAID_F7DB7C83_5B79_4a4b_AEEE_FF7AAB4861E5" name="GigaHertz"
description="Unit of measure for representing frequency used to measure the clock rate of modern
digital logic, equal t one billion hertz."/>
<element xmi:type="logical:Unit" xmi:id="EAID_161469CC_7BFE_4206_BF8E_17E105C1A679" name="Hertz"
description="Unit of measure for representing frequency, equal to one cycle per second . An SI
unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_2DC04833_07D0_462c_B494_1AAF26BAC3F8" name="KiloHertz"
description="Unit of measure for representing frequency equivalent to 1,000 cycles per second or
1,000 hertz."/>
<element xmi:type="logical:Unit" xmi:id="EAID_B757844F_7DD2_4be1_B0B0_9AAC190AA821" name="MegaHertz"
description="Unit of measure for representing one million hertz, as measure of frequency of radio
transmissions or transmission speeds of electronic devices."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_6A88C4F4_1721_4f53_BB31_F3254300B00D"
name="HeatCapacity"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_FBAA40BF_3DE0_4d3f_93DF_689E6D11CE27"
name="Illuminance">

<element xmi:type="logical:Unit" xmi:id="EAID_65D4712B_C8F8_4e24_98E0_32A8040A0F94" name="Lux"
description="Unit of measure for representing illumination equal to the direct illumination on a
surface that is equal to one lumen per square meter. An SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_01CFBEEB_B898_4df8_995C_036BDB6C4188" name="Phot"
description="Unit of measure for representing illuminance equal to one lumen per square centimeter in
the Centimeter Gram Second system."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A3FBB11C_EC48_4816_9676_9C1B6593411C"
name="Inductance">
<element xmi:type="logical:Unit" xmi:id="EAID_56F719FC_B33B_44e1_9D77_5D3C3D692182" name="Henrys"
description="Unit of measure for representing inductance equal to an electromotive force of one volt
in a closed circuit with a uniform rate of change of current of one amp per second. An SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_37066CF1_9515_4b75_B009_12F418FEA4B0" name="MicroHenrys"
description="Unit of measure for representing inductance equal to 1 millionth of a henry."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3B3AB347_3754_436c_9C41_A0E33CD813ED" name="MilliHenrys"
description="Unit of measure for representing inductance equal to 1 thousandth of a henry."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_64408E5C_0BF5_48cd_A9C8_196D035D628E" name="Length">
<element xmi:type="logical:Unit" xmi:id="EAID_A763DED3_CE36_462f_9C64_C385D35A8F03" name="Angstroms"
description="Unit of measure for representing length equal to one hundred-millionth of a centimeter
mainly to express wavelengths and interatomic distances."/>
<element xmi:type="logical:Unit" xmi:id="EAID_BB032E2F_0B77_4617_BEB8_CBF2872478B8"
name="AstronomicalUnits" description="Unit of measure for representing the mean distance between the
Earth and the Sun, equal to 149.6 million kilometers."/>
<element xmi:type="logical:Unit" xmi:id="EAID_55B68600_CD69_459e_825D_A0EF0067E79A" name="Cables"
description="Unit of measure for representing length as a nautical unit of measure equal to one tenth
of a nautical mile or 100 fathoms."/>
<element xmi:type="logical:Unit" xmi:id="EAID_F6A1CE92_DD0B_4f03_8AEC_CE88E62A1C0D" name="Centimeters"
description="Unit of measure for representing length equal to one hundredth of a meter."/>
<element xmi:type="logical:Unit" xmi:id="EAID_19B91A7E_DD89_458f_BA4F_63B55DCDD16A" name="Chains"
description="Unit of measure for representing a geodetic measure used for land survey, equal to 66
feet."/>
<element xmi:type="logical:Unit" xmi:id="EAID_90F83E4E_186E_43ce_9C8C_9E618E60F133" name="DataMiles"
description="Unit of measure for representing radar related subjects and in JTIDS, is equal to 6000
feet or 0.987 nautical miles."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A41BDA35_F482_48e1_8588_B676BF4C8011" name="Fathoms"
description="Unit of measure for representing depth of water equal to 6 feet."/>
<element xmi:type="logical:Unit" xmi:id="EAID_4B11E95B_FBAD_48c8_A03C_B7E641F18AFE" name="Feet"
description="Unit of measure for representing length as multiple units of the international foot,
equal to 12 inches."/>
<element xmi:type="logical:Unit" xmi:id="EAID_114E6AF4_7196_454e_AF95_281046536321" name="Inches"
description="Unit of measure for representing length in the imperial and US customary systems of
measurement."/>
<element xmi:type="logical:Unit" xmi:id="EAID_9782EE69_B788_462b_8852_563747B1F80F" name="Kilometers"
description="Unit of measure for representing length equal to 1000 meters."/>
<element xmi:type="logical:Unit" xmi:id="EAID_0DA0C3BF_9EF2_44c7_99A8_F9D8677BA783" name="Links"
description="Unit of measure for representing length equal to 7.92 survey inches formerly used in
land surveying. 0"/>
<element xmi:type="logical:Unit" xmi:id="EAID_0A9F29A7_3ABC_4790_9E6D_CEBD6C7DBE5E" name="Meters"
description="Unit of measure for representing length equal to the distance traveled in a vacuum by
light in 1/299, 782, 458 second or to about 39.37 inches. An SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_3A901F73_BD0D_4479_AAF0_58AB0A05E545" name="MetricMiles"
description="Unit of measure for representing length in international athletics of 1500 meters."/>
<element xmi:type="logical:Unit" xmi:id="EAID_380536E1_27EB_4939_AA22_68976D95172B" name="Millimeters"
description="Unit of measure for representing length equal to one thousandth of a meter."/>
<element xmi:type="logical:Unit" xmi:id="EAID_705F2A05_3E50_4ecd_AC15_ED90D7540C76"
name="NauticalMiles" description="Unit of measure for representing length at sea or air travel equal
to 1.15 miles"/>
<element xmi:type="logical:Unit" xmi:id="EAID_27B71847_5DA3_49e8_9ECD_0965941CC914"
name="ReciprocalMeters" description="Unit of measure for representing a measure of the shape of a
curved surface equal to the reciprocal of the radius of curvature of a surface in meters."/>
<element xmi:type="logical:Unit" xmi:id="EAID_337EB82F_0B9D_44ec_963D_16B87BDBE65E" name="Rods"
description="Unit of measure for representing length equal to 5 1/5 yards or 16 1/2 feet used in land
surveying."/>
<element xmi:type="logical:Unit" xmi:id="EAID_721BF4F7_FF61_4e7e_93A4_4708E22C0C4F" name="StatuteMiles"
description="Unit of measure for representing length on land in English speaking countries equal to
5,280 feet."/>
<element xmi:type="logical:Unit" xmi:id="EAID_25E89165_B7E4_4b86_A7F5_CB20E507EE6F" name="Yards"
description="Unit of measure for representing length in the US Customary and British Imperial Systems
equal to 3 feet."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C13D2921_9AB4_407a_B3ED_BB3F5CB60DFA" name="Luminance">
<element xmi:type="logical:Unit" xmi:id="EAID_95E8CD97_D12C_43b4_AC04_AEFE6A88D852"
name="CandelasPerSquareMeter" description="Unit of measure for representing light emitted per unit
area, commonly used to specify the brightness of a display device. An SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C1D5EE04_3949_4231_877F_74D1CE7E8C39" name="Stilbs"
description="Unit of measure for representing luminance in the Centimeter Gram Seconds system for
objects that are not self-luminous, equal to one candela per square centimeter."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C4AE669F_20BA_483f_A73F_0C3FFDE10B93"
name="LuminousFlux">
<element xmi:type="logical:Unit" xmi:id="EAID_4B042F46_5BE0_4555_BE22_C079264EEC1E" name="Lumens"
description="Unit of measure for representing luminous flux, equal to the amount of light emitted per
second in a unit solid angle of on steradina from a uniform source of one candela. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C8A344B6_9D5F_4024_9583_19169181C457"
name="LuminousIntensity">
<element xmi:type="logical:Unit" xmi:id="EAID_846F619C_9BC7_40b2_AAA5_3CD2222F84CF" name="Candelas"
description="Unit of measure for representing luminous intensity emitted by a light source in a
particular direction, weighted by the luminosity function. An SI Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A91A24BA_052C_4046_B78B_73C36C479497"
name="MagneticField">
<element xmi:type="logical:Unit" xmi:id="EAID_4D37723D_ACC0_44e7_B1C7_6EB897E4F748" name="Oersteds"
description="Unit of measure for representing magnetic field strength in the Centimeter Gram Second
system."/>
<element xmi:type="logical:Unit" xmi:id="EAID_4733852F_C574_42b8_B6CD_6A665A869BCF" name="Teslas"
description="Unit of measure for representing magnetic flux density equal to a flux of one weber in
an area of one square meter. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B6DFB41D_2B7F_44a2_AA9A_EF10F98EC4DA"
name="MagneticFlux">
<element xmi:type="logical:Unit" xmi:id="EAID_1D856CCC_D134_490e_A26B_A55DE73BD59C" name="Maxwells"
description="Unit of measure for representing magnetic flux equal to the flux through one square
centimeter normal to a field of one gauss, in the Centimeter Gram Second system."/>
<element xmi:type="logical:Unit" xmi:id="EAID_FC322DA3_AB79_4c7d_8736_EC76A47812A8" name="Webers"
description="Unit of measure for representing magnetic flux equal to the flux that produces in a
circuit of one turn an electromotive force of one volt, when the flux is uniformly reduced to zero
within one second. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_162DEF21_C862_442e_B0C3_3A2149F72396"
name="MagneticFluxDensity">
<element xmi:type="logical:Unit" xmi:id="EAID_7F0BDC60_82FF_4291_993B_0247FE33C000" name="Gauss"
description="Unit of measure for representing magnetic flux density equal one Maxwell per square
centimeter, in the Centimeter Gram Second system."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_8145F73A_1151_4a74_A2CB_F0A732321088" name="Mass">
<element xmi:type="logical:Unit" xmi:id="EAID_353F519A_9F65_47ce_A46C_FFA8E2555DEA"
name="Dalton_UnifiedAtomicMassUnits" description="Unit of measure for representing mass on an atomic
or molecular scale defined as one twelfth of the rest mass of an unbound atom of carbon-12 in its
nuclear and electronic ground state."/>
<element xmi:type="logical:Unit" xmi:id="EAID_D7D0A1EB_DF28_4ed9_B090_C877DCDEEDF0" name="ElectronMass"
description="Unit of measure for representing electron rest mass is an atomic fundamental physical
constant is defined as the mass of a stationary electron."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E389C2FD_BCCD_4263_AF43_474D39577BFE" name="Grams"
description="Unit of measure for representing a metric unit of mass equal to one thousandth of a
kilogram."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A21827D1_48AF_4e25_A534_D2CDAE199D76" name="KiloGrams"
description="Unit of measure for representing the mass equal to the International Prototype of the
Kilogram."/>
<element xmi:type="logical:Unit" xmi:id="EAID_5B6C4513_5B50_45de_904F_CC6838B799B7" name="Milligrams"
description="Unit of measure for representing a metric unit of mass equal to one thousandth of a
gram."/>

<element xmi:type="logical:Unit" xmi:id="EAID_2B22C06E_920A_4f7d_A448_80257FE3E92C" name="Tonnes"
description="Unit of measure for representing a metric unit of mass equal to 1,000 kilograms or 2,
240 pounds. A non-SI unit."/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AF92DCDD_8F89_4f00_9B77_3E15B22C9A2C"
name="Avoirdupois">
<element xmi:type="logical:Unit" xmi:id="EAID_6313EB2C_C1DF_4bb8_909E_706066DAC8C7"
name="AvoirdupoisGrains" description="Unit of measure for representing a unit of 1/7000 of a pound
from the avoirdupois system based on the 16 ounce pound or 7,000 grains."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E2830A10_28D1_42e5_869C_C877BA89B178" name="Drams"
description="Unit of measure for representing a unit of mass of 1/256 of a pound or 1/16 of an
ounce."/>
<element xmi:type="logical:Unit" xmi:id="EAID_EBE1D89F_3A41_4039_965B_9C14FD995D1D"
name="Hundredweights" description="Unit of measure for representing a unit of mass equal to 100
pounds defined and used in the US Customary System."/>
<element xmi:type="logical:Unit" xmi:id="EAID_05A0CF20_2537_4082_9DA0_CEC3B171F99D"
name="LongHundredweights" description="Unit of measure for representing a unit of mass equal to 112
pounds defined and used in the Imperial System."/>
<element xmi:type="logical:Unit" xmi:id="EAID_40CDD4FC_7078_48ee_B9D8_D6DD15EB6D57" name="LongTons"
description="Unit of measure for representing a unit of weight equal to 2240 pounds used in the
Imperial System."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E0C37101_E706_4367_B997_F415C16EBB5A" name="Ounces"
description="Unit of measure for representing an avoirdupois unit of weight equal to 1/16 of an
avoirdupois pound or 437.5 grains."/>
<element xmi:type="logical:Unit" xmi:id="EAID_2B44DABD_6782_433a_8B99_8AB710AFAC31" name="Pounds"
description="Unit of measure for representing an avoirdupois unit of weight equal to 7000
grains."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A6E38DAD_887B_4b79_8292_CD090E037FB9" name="Tons"
description="Unit of measure for representing a unit of weight equal to 2000 pounds used in the US
Customary System."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_E452AD3E_E6EF_48a3_9000_A486BFD74208" name="Troy">
<element xmi:type="logical:Unit" xmi:id="EAID_29152C26_65FA_4226_93D5_214F28E63E10" name="TroyGrains"
description="Unit of measure for representing a unit of weight used for precious metals and
gemstones equal to 1/60 dram or equal to the avoirdupois grain."/>
<element xmi:type="logical:Unit" xmi:id="EAID_DCB6C9FA_27ED_4dc0_99C3_5BBAF1C6C58B" name="TroyOunces"
gemstones equal to 480 grains."/>
<element xmi:type="logical:Unit" xmi:id="EAID_74D51E3B_0B05_4b5b_B9E4_0F2848DD100C" name="TroyPounds"
gemstones equal to 5,760 grains."/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_523ABAE7_04E0_4de7_B3FA_D0A3D1468D89"
name="MassConcentration"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A52F3819_F68E_49a2_AE92_3000B8873476"
name="MolarEnergy">
<element xmi:type="logical:Unit" xmi:id="EAID_5E1C4348_C669_4229_A707_90C0BE07D7B1"
name="JoulesPerMole" description="Unit of measure for representing the measure of the energy per
amount of material. An SI derived unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_AF1BEB28_2C68_4f7a_A654_1A436CFDE512"
name="MolarEntropy">
<element xmi:type="logical:Unit" xmi:id="EAID_F578A32F_EBCB_4a34_A6DB_0BFD0E4EEDCE"
name="JoulesPerMoleKelvin" description="Unit of measure for representing molar heat capacity defining
the amount of heat needed to increase the temperature of one mole of a substance by one degree."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C00995EC_762D_4025_97A8_93F26514E05A"
name="MomentOfForce">
<element xmi:type="logical:Unit" xmi:id="EAID_C0B1C69D_4742_4acf_82CD_DB92D5878FAA" name="NewtonMeters"
description="Unit of measure for representing torque resulting from a force of one newton applied
perpendicularly to a moment arm which is one meter long. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_B5F13586_8376_4642_8FF5_D7F05C886A5B" name="Power">
<element xmi:type="logical:Unit" xmi:id="EAID_ACAA2155_27C3_4a8d_9F84_17451EC9DE42" name="Watts"
description="Unit of measure for representing the power in an electric circuit in which the potential
difference is one volt and the current one amp., equal to one joule per second and is an SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_20724726_250C_4ff4_B6D2_8A7FA5801793"
name="Permeability">
<element xmi:type="logical:Unit" xmi:id="EAID_88F0F618_A2DD_4536_921F_6D2E6CA1CD0D"
name="HenrysPerMeter" description="Unit of measure for representing the permeability of a material
surrounded by a single turn of a flat sheet conductor including an area of one square meter and
length one meter which gives an inductance of one henry. A Derived SI Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_53C9FC83_79BD_4e7e_A5D0_420F11424DC8"
name="Permittivity">
<element xmi:type="logical:Unit" xmi:id="EAID_7A1862E4_E85E_46d5_8A59_F50EFBBE9131"
name="FaradsPerMeter" description="Unit of measure for representing the resistance encountered when
forming an electric field in a medium. An SI derived unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_4B7EA033_0489_40cf_B20F_DBA28D250A53" name="Pressure">
<element xmi:type="logical:Unit" xmi:id="EAID_C28AD0FA_5435_4be9_BC05_F718E801C001" name="Bars"
description="Unit of measure for representing pressure equal to a million dynes per square centimeter
used in meteorology to report atmospheric pressure."/>
<element xmi:type="logical:Unit" xmi:id="EAID_B12A36E4_D202_4eca_913A_41313B5C69F0" name="FlightLevel"
description="Unit of measure for representing a surface of constant atmosphere pressure which is
related to a specific pressure datum, 1013.2hPa, and is separated from other such surfaces by
specific pressure intervals."/>
<element xmi:type="logical:Unit" xmi:id="EAID_0A0C5318_D176_4967_8B4E_E436A3715FF3"
name="InchesOfMercury" description="Unit of measure for representing the pressure exerted by a column
of mercury one inch high under standard conditions of temperature and gravity."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C437C35F_4DFB_4200_8133_5DA158EB6085"
name="MillimetersOfMercury" description="Unit of measure for representing the pressure exerted by a
column of mercury one millimeter high under standard conditions of temperature and gravity."/>
<element xmi:type="logical:Unit" xmi:id="EAID_9CDA2125_1689_411c_AC85_04287E8FC3CE" name="Pascals"
description="Unit of measure for representing pressure of one newton per square meter. An SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_411C9D3A_3AC2_4123_BDAE_7F5C771611E6"
name="PoundsPerSquareInch" description="Unit of measure for representing pressure based o he
avoirdupois units resulting form a force of one pound-force applied to an area of one square inch. A
non-SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E55C3C11_FA94_4421_9280_F20C673B8919" name="Torr"
description="Unit of measure for representing pressure with the ratio of 760 to 1 standard
atmosphere, roughly equal to the fluid pressure exerted by a millimeter of mercury used in high-
vacuum physics and engineering. A non SI Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_99CD3AB8_443B_403a_B846_2D5EB490CD77" name="Radiance">
<element xmi:type="logical:Unit" xmi:id="EAID_449612D3_50F4_4eb2_8187_91A1482ACE83"
name="WattsPerSquareMeterSteradian" description="Unit of measure for representing radiance and is
defined as the power per unit solid angle. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_C2C0FF0B_B5C6_4057_B8C1_61992C1C5CA0"
name="RadiantIntensity">
<element xmi:type="logical:Unit" xmi:id="EAID_3A685039_DB3F_4044_AAEC_945F46598CC5"
name="WattPerSteradian" description="Unit of measure for representing radiant intensity characterized
as the emission of radiation by an antenna. An SI Unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_57EC71DE_6A7E_4cab_A347_3077716EF57E"
name="Radioactivity">
<element xmi:type="logical:Unit" xmi:id="EAID_CAF4F95D_F642_423c_83A6_6219ED07002D" name="Becquerels"
description="Unit of measure for representing radioactivity, defined as the activity of a quantity of
radioactive material in which one nucleus decays per second. An SI derived unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_BE375988_26A7_4ac0_98F8_C8F0339DF492"
name="SolidAngle">
<element xmi:type="logical:Unit" xmi:id="EAID_02B1EB9C_7717_42b5_A24B_5BB6C5E413B4"
name="SquareDegrees" description="Unit of measure for representing the measure of a solid angle used
to measure parts of a sphere. A non-SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_51821B33_5943_4d6c_9667_151F4D916559" name="Steradians"
description="Unit of measure for representing squared radian is the measure of a solid angle used to
measure parts of a sphere. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_56EEC7F8_8058_43af_83D2_11480E771BBE" name="Speed">
<element xmi:type="logical:Unit" xmi:id="EAID_D0BB71A9_1DA4_4b42_B20F_1DA918A74312"
name="DegreesPerSecond" description="Unit of measure for representing rotational speed, defined by
the change in orientation of an object, in degrees every second. An SI Unit."/>

<element xmi:type="logical:Unit" xmi:id="EAID_E3D2CD7F_05FE_4878_ACD3_C4E23734ED1F"
name="KilometersPerHour" description="Unit of measure for representing a measure of speed expressed
as the number of kilometers travelled in one hour."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C791EA45_64E6_469f_A762_B7E86B5359A0" name="Knots"
description="Unit of measure for representing a measure of speed equal to one nautical mile per
hour."/>
<element xmi:type="logical:Unit" xmi:id="EAID_F0BA2B63_62FD_42c1_8A47_9706562E9E84" name="Mach"
description="Unit of measure for representing the speed of sound, the distance travelled per unit of
time by a sound wave propagating through an elastic medium. "/>
<element xmi:type="logical:Unit" xmi:id="EAID_D656A860_B181_4712_B6C0_3CC4761A682D"
name="MetersPerSecond" description="Unit of measure for representing speed and velocity. An SI
derived unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_774E705B_1B1D_406a_8403_42360910A569" name="MilesPerHour"
description="Unit of measure for representing speed expressing the number of statute miles covered in
one hour used in the Imperial and US Customary systems."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C21F5F62_131A_4807_894F_A58BF924B164"
name="RadiansPerSecond" description="Unit of measure for representing rotational speed, defined by
the change in orientation of an object, in radians every second. An SI Unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_5C4E1875_B52B_4a98_8F0E_A235796974BB" name="SpeedOfLight"
description="Unit of measure for representing the speed of light in a vacuum, is a universal physical
constant whose value is 299,792,458 meters per second."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_84B65442_5510_48d5_9976_18707D937C5A"
name="Temperature">
<element xmi:type="logical:Unit" xmi:id="EAID_723C724A_263B_48fe_B9EA_6D471D78BECA"
name="DegreesCelsius" description="Unit of measure for representing temperature where water freezes
at 0 degrees and boils at 100 degrees."/>
<element xmi:type="logical:Unit" xmi:id="EAID_A1A79A69_F65A_4734_8957_894EFEDA1F5A"
name="DegreesFarenheit" description="Unit of measure for representing temperature where water freezes
at 32 degrees and boils at 212 degrees (at standard atmospheric pressure)."/>
<element xmi:type="logical:Unit" xmi:id="EAID_C06308E5_8978_48e2_963B_596CFB8C04A4"
name="DegreesKelvin" description="Unit of measure for representing temperature at which all thermal
motion ceases in the classical description of thermodynamics. An SI unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_93A2E7E2_61C3_48d8_98E7_CE20EF168722"
name="ThermalConductivity">
<element xmi:type="logical:Unit" xmi:id="EAID_DE210BBE_A970_49f8_888D_776EC8E42FB3"
name="WattsPerMeterKelvin" description="Unit of measure for representing thermal conductance where a
material of one joule of energy per one second moves through the distance of one meter due to a
temperature difference of one kelvin. An SI derived unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2342696B_A50C_4a50_93E9_0C18B97AC18A" name="Time">
<element xmi:type="logical:Unit" xmi:id="EAID_55641AED_3F8A_497b_BF82_630E05CFCEE4" name="Days"
description="Unit of time duration equal to 24 hours; approximately one rotation of the Earth"/>
<element xmi:type="logical:Unit" xmi:id="EAID_ACBBECC7_C23C_48d8_8355_ED0A3A3A3324" name="Hours"
description="Unit of time duration equal to 60 minutes"/>
<element xmi:type="logical:Unit" xmi:id="EAID_DD9D1386_CC2E_4f76_BD72_A2E1BAF61CAC" name="Microseconds"
description="Unit of time duration equal to one millionth of a second"/>
<element xmi:type="logical:Unit" xmi:id="EAID_CDB24D2F_2CBF_4617_BD58_7A64770B4AF7" name="Milliseconds"
description="Unit of time duration equal to one thousandth of a second"/>
<element xmi:type="logical:Unit" xmi:id="EAID_D16C8EB8_AEA3_4dc4_B32D_2EA864931180" name="Minutes"
description="Unit of time duration equal to 60 seconds"/>
<element xmi:type="logical:Unit" xmi:id="EAID_8E83CE63_89C9_4911_98A0_F7D3A60EF0EB" name="Nanoseconds"
description="Unit of time duration equal to one billionth of a second"/>
<element xmi:type="logical:Unit" xmi:id="EAID_17A1BB83_047A_4b42_A183_1237BC07B435" name="Seconds"
description="SI base unit of time. One second is defined to be the duration of 9192631770 periods of
the radiation corresponding to the transition between the two hyperfine levels of the ground state of
the cesium 133 atom"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_A65AABFB_BDEB_49f4_938A_0C6D0A2FAB3C" name="Viscosity">
<element xmi:type="logical:Unit" xmi:id="EAID_80D9C661_993E_4fd3_833C_855ABF3F1359" name="Centipoise"
description="Units for dynamic (shear) viscosity, equivalent to milliPascal-seconds"/>
<element xmi:type="logical:Unit" xmi:id="EAID_F25C01B7_B6ED_481e_B13B_5EFA4E8A0315" name="Centistokes"
description="Units for kinematic viscosity,1 centistokes (cSt) = 0.01 St= 0.000001 m^2/sec"/>
<element xmi:type="logical:Unit" xmi:id="EAID_1C753236_2F55_4424_9CA3_47AD45CC4934"
name="PascalSeconds" description="SI units for dynamic (shear) viscosity"/>
<element xmi:type="logical:Unit" xmi:id="EAID_E1018FCF_16B7_4a50_8D59_EA9270C4288C" name="Poise"
description="Units for dynamic (shear) viscosity. 1 Poise = 100 cP = 0.1 Pascal-seconds"/>
<element xmi:type="logical:Unit" xmi:id="EAID_610F07F0_80C3_4243_81DD_70AD7BF78660"
name="SayboltUniversalSeconds" description="Obsolete units for kinematic viscosity. Conversion to the
preferred units of centistokes (cSt) is defined in ASTM D 2161"/>
<element xmi:type="logical:Unit" xmi:id="EAID_9B5D0AEF_2419_442d_B413_AD98445E7BC7"
name="SquareMetersPerSecond" description="SI units for kinematic viscosity"/>
<element xmi:type="logical:Unit" xmi:id="EAID_B146CC58_0C97_4511_A034_B1E3D4414251" name="Stokes"
description=" Units for kinematic viscosity, 1 stokes (St) = 0.0001 m^2/sec"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_9BAF9C2C_5BB2_4e98_994F_5BB8307528B8" name="Voltage">
<element xmi:type="logical:Unit" xmi:id="EAID_D1F6B8CB_00D0_447a_B871_02D5EA97DFED"
name="ElectronVolts" description="Unit of measure representing the amount of kinetic energy gained by
a single unbound electron when it accelerates through an electric potential difference of one volt. A
non-SI unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_7DAFAFA2_9CA0_4db4_ADB9_A483D5B16E8D" name="Volts"
description="Unit of measure representing the difference in electric potential between two points of
a conducting wire when an electric current of one amp dissipates one watt of power between those
points. An SI derived unit."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_F4FE45A0_0E6E_41d9_B525_A30FB6A008BC" name="Volume">
<element xmi:type="logical:Unit" xmi:id="EAID_6C2D0767_7566_4967_B174_C1F38C5F3DC5"
name="CubicCentimeters" description="Unit of measure representing volume of a cube measuring 1 cm x 1
cm x 1 cm. A SI derived unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_E959EB0F_095E_4e90_88F4_32E5490BB442" name="CubicFeet"
description="Unit of measure representing volume of a cube measuring the same multiple of a foot unit
in length on all sides."/>
<element xmi:type="logical:Unit" xmi:id="EAID_8EED50A7_7179_44ab_B373_930D69E2476B" name="CubicInches"
description="Unit of measure representing volume of a cube measuring 1 in x 1 in x 1 in."/>
<element xmi:type="logical:Unit" xmi:id="EAID_B6983E55_B326_4925_B8B0_0EF9E75250DD" name="CubicMeters"
description="Unit of measure representing volume of a cube measuring 1 m x 1 m x 1 m. A SI derived
unit."/>
<element xmi:type="logical:Unit" xmi:id="EAID_8BA0E5B0_CB13_490a_9363_6A3C2C2B16B8"
name="CubicMillimeters" description="Unit of measure representing volume of a cube measuring 1 mm x 1
mm x 1 mm. A SI derived unit.m"/>
<element xmi:type="logical:Unit" xmi:id="EAID_3DF7E5B0_A605_4e2b_BB15_B8EC36059B8B" name="CubicYards"
description="Unit of measure representing volume of a cube measuring 1 yds x 1 yds x 1 yds."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_1A440A82_31D5_4a0d_B09E_D7771FF6A41C" name="Work">
<element xmi:type="logical:Unit" xmi:id="EAID_C1B2CBC7_C0DB_4a69_80B2_087D899DC14A" name="Ergs"
description="Unit of measure representing work or energy equal to the work done by a force of one
dyne when its point of application moves through a distance of one centimeter in the direction of the
force, used in the Centimeter Gram Seconds system."/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_43329893_F8AF_41cd_8872_35C8FFBFEFCA"
name="UnitlessDimensionless">
<element xmi:type="logical:Unit" xmi:id="EAID_1268C4EA_1948_4472_B251_CDD0342B9BC1" name="Percent"
description="A number or rate that is expressed as a certain number of parts of something divided
into 100 parts."/>
<element xmi:type="logical:Unit" xmi:id="EAID_DA342318_2A86_40ad_9B8F_93BD6F02D542" name="Ratio"
description="A unit used to specify the ratio of one value to another having the same units"/>
<element xmi:type="logical:Unit" xmi:id="EAID_0C482F2C_A548_4cf1_B9AD_5086FD62C41B" name="Unitless"
description="A "placeholder" to specify for values that have no engineering units or where
units are not meaningful, but a Unit specification is required"/>
</ldm>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_92A25A5B_0CF9_42d2_89F0_937FCFCF5B76"
name="Enumerations">
<element xmi:type="logical:Enumerated" xmi:id="EAID_5B1EEC9D_680C_432a_9C40_DFD0205F43E6"
name="CardinalOrdinalDirection_TrueNorth" description="Describes the set of cardinal and ordinal
directions with respect to True North." standardReference="">
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_20459257_A276_4701_8510_50E052392B7D"
name="EAST"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_894365BA_911E_4f04_BBC8_8140D93DA65D"
name="NORTH"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_A2C82B44_99C5_4ced_AE90_C18E9B38CB81"
name="NORTHEAST"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_F7385E06_3643_40bd_9D7C_E9D377FA142D"
name="NORTHWEST"/>

<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_42C45248_BA49_4dea_9C84_BA76CD4C72D5"
name="SOUTH"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_ABFC3010_2311_4908_872D_5E3CBD7AAD9E"
name="SOUTHEAST"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_F5FE8312_3FBE_4602_9CB8_42FF5BEBE0E0"
name="SOUTHWEST"/>
<label xmi:type="logical:EnumerationLabel" xmi:id="EAID_AED484EB_9170_480f_922F_4459F8F25F3B"
name="WEST"/>
</element>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="_AKCs8hRAEeSZNohePfXakg" name="USM_LDM">
<element xmi:type="logical:Entity" xmi:id="_AKGXURRAEeSZNohePfXakg" name="EGI1" description="Logical
entity representing a single instance of an EGI." realizes="_AJ90cBRAEeSZNohePfXakg">
<composition xmi:type="logical:Composition" xmi:id="_AKGXUhRAEeSZNohePfXakg" rolename="attitude"
type="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC" realizes="_AJ_CkBRAEeSZNohePfXakg"/>
<composition xmi:type="logical:Composition" xmi:id="_AKG-YBRAEeSZNohePfXakg" rolename="position"
type="_vZiY3Ag5EeSFspy8Kj3F4Q" realizes="_AJ_CkRRAEeSZNohePfXakg"/>
</element>
<element xmi:type="logical:Entity" xmi:id="_AKG-YRRAEeSZNohePfXakg" name="EGI2" description="Logical
entity representing a single instance of an EGI." realizes="_AJ90cBRAEeSZNohePfXakg">
<composition xmi:type="logical:Composition" xmi:id="_AKG-YhRAEeSZNohePfXakg" rolename="attitude"
type="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC" realizes="_AJ_CkBRAEeSZNohePfXakg"/>
<composition xmi:type="logical:Composition" xmi:id="_AKG-YxRAEeSZNohePfXakg" rolename="position"
type="_vZiY3Ag5EeSFspy8Kj3F4Q" realizes="_AJ_CkRRAEeSZNohePfXakg"/>
</element>
<element xmi:type="logical:Entity" xmi:id="_AKEiIBRAEeSZNohePfXakg" name="InertialMeasurementUnit"
description="Logical entity representing a single instance of an IMU."
realizes="_AJ_CkxRAEeSZNohePfXakg">
<composition xmi:type="logical:Composition" xmi:id="_AKGXUBRAEeSZNohePfXakg" rolename="attitude"
type="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC" realizes="_AJ_ClBRAEeSZNohePfXakg"/>
</element>
<element xmi:type="logical:Association" xmi:id="_AKIMgBRAEeSZNohePfXakg" name="NavManagementFunction"
description="Logical entity representing the navigation management function."
realizes="_AJ_ClhRAEeSZNohePfXakg">
<composition xmi:type="logical:Composition" xmi:id="_AKIMgRRAEeSZNohePfXakg" rolename="attitude"
type="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC" realizes="_AJ_ClxRAEeSZNohePfXakg"/>
<composition xmi:type="logical:Composition" xmi:id="_AKIMghRAEeSZNohePfXakg" rolename="position"
type="_vZiY3Ag5EeSFspy8Kj3F4Q" realizes="_AJ_poBRAEeSZNohePfXakg"/>
<associatedEntity xmi:type="logical:AssociatedEntity" xmi:id="_AKIzkBRAEeSZNohePfXakg"
rolename="imuNavSource" upperBound="-1" type="_AKEiIBRAEeSZNohePfXakg" path=""
realizes="_AJ_pohRAEeSZNohePfXakg"/>
<associatedEntity xmi:type="logical:AssociatedEntity" xmi:id="_AKJaoBRAEeSZNohePfXakg"
rolename="egi1NavSource" upperBound="-1" type="_AKGXURRAEeSZNohePfXakg" path=""
realizes="_AJ_poxRAEeSZNohePfXakg"/>
<associatedEntity xmi:type="logical:AssociatedEntity"
xmi:id="EAID_DCE7CA57_55AC_41b6_A9C4_A51973392FF9" rolename="egi2NavSource" upperBound="-1"
type="_AKG-YRRAEeSZNohePfXakg" path="" realizes="_AJ_poxRAEeSZNohePfXakg"/>
</element>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_0EC2EE29_E4D6_4d31_8932_196FA77B4840" name="Measures">
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_986FA770_163A_4ff1_8C1A_6863BACD39E5"
name="Orientation Measures"/>
<ldm xmi:type="face:LogicalDataModel" xmi:id="EAID_2B70811F_C2D3_454f_8756_CDA364EFA84E" name="Position
Measures"/>
</ldm>
<ldm xmi:type="face:LogicalDataModel" xmi:id="_AKJaoRRAEeSZNohePfXakg" name="LogicalViews">
<element xmi:type="logical:View" xmi:id="_AKJaohRAEeSZNohePfXakg" name="EGI_Data" description="Logical
view representing EGI data." realizes="_AKA3whRAEeSZNohePfXakg">
<characteristic xmi:type="logical:CharacteristicProjection"
xmi:id="EAID_E7FC4175_620B_40a0_BCFB_B548B3A95449"
projectedCharacteristic="_AKGXURRAEeSZNohePfXakg" rolename="att" realizes="_AKA3wxRAEeSZNohePfXakg"
path=".attitude"/>
<characteristic xmi:type="logical:CharacteristicProjection" xmi:id="_AKKBsBRAEeSZNohePfXakg"
projectedCharacteristic="_AKGXURRAEeSZNohePfXakg" rolename="pos" realizes="_AKA3xBRAEeSZNohePfXakg"
path=".position"/>
</element>
<element xmi:type="logical:View" xmi:id="_AKKowhRAEeSZNohePfXakg" name="IMU_Data" description="Logical
view representing the IMU data." realizes="_AKAQsBRAEeSZNohePfXakg">
<characteristic xmi:type="logical:CharacteristicProjection" xmi:id="_AKKowxRAEeSZNohePfXakg"
projectedCharacteristic="_AKEiIBRAEeSZNohePfXakg" rolename="att"
realizes="EAID_53314BC3_ABC7_4bb6_8A78_006A8DFB5EA7" path=".attitude"/>
</element>
<element xmi:type="logical:View" xmi:id="_AKKBsRRAEeSZNohePfXakg" name="Nav_Data" description="Logical
view representing the resolved navigation data." realizes="_AKA3xRRAEeSZNohePfXakg">
<characteristic xmi:type="logical:CharacteristicProjection" xmi:id="_AKKowRRAEeSZNohePfXakg"
projectedCharacteristic="_AKIMgBRAEeSZNohePfXakg" rolename="att" realizes="_AKA3xhRAEeSZNohePfXakg"
path=".attitude"/>
<characteristic xmi:type="logical:CharacteristicProjection" xmi:id="_AKKowBRAEeSZNohePfXakg"
projectedCharacteristic="_AKIMgBRAEeSZNohePfXakg" rolename="pos" realizes="_AKA3xxRAEeSZNohePfXakg"
path=".position"/>
</element>
</ldm>
</ldm>
</ldm>
<pdm xmi:type="face:PlatformDataModel" xmi:id="_ALcbIBRAEeSZNohePfXakg" name="Platform_Model">
<pdm xmi:type="face:PlatformDataModel" xmi:id="EAID_6584F90E_CB01_429f_B147_54186900BE80" name="USM_PDM">
<element xmi:type="platform:Entity" xmi:id="_ALjv4BRAEeSZNohePfXakg" name="EGI1" description="Platform
entity representing a single instance of an EGI." realizes="_AKGXURRAEeSZNohePfXakg">
<composition xmi:type="platform:Composition" xmi:id="_ALjv4RRAEeSZNohePfXakg" rolename="attitude"
type="_ALrEpBRAEeSZNohePfXakg" realizes="_AKGXUhRAEeSZNohePfXakg"/>
<composition xmi:type="platform:Composition" xmi:id="_ALjv4hRAEeSZNohePfXakg" rolename="position"
type="_ALp2gBRAEeSZNohePfXakg" realizes="_AKG-YBRAEeSZNohePfXakg"/>
</element>
<element xmi:type="platform:Entity" xmi:id="EAID_CF6F14E1_DD1D_439b_A993_7B9F0CE0E7A0" name="EGI2"
description="Platform entity representing a single instance of an EGI." realizes="_AKG-
YRRAEeSZNohePfXakg">
<composition xmi:type="platform:Composition" xmi:id="EAID_825D9566_A9EC_4174_86C0_E30AA16F3CD3"
rolename="attitude" type="_ALrEpBRAEeSZNohePfXakg" realizes="_AKG-YhRAEeSZNohePfXakg"/>
<composition xmi:type="platform:Composition" xmi:id="EAID_B7D3D2F9_A5C7_4460_BF95_6D66F262FBBC"
rolename="position" type="_ALp2gBRAEeSZNohePfXakg" realizes="_AKG-YxRAEeSZNohePfXakg"/>
</element>
<element xmi:type="platform:Entity" xmi:id="_ALhToBRAEeSZNohePfXakg" name="InertialMeasurementUnit"
description="Platform entity representing a single instance of an IMU."
realizes="_AKEiIBRAEeSZNohePfXakg">
<composition xmi:type="platform:Composition" xmi:id="_ALjI0BRAEeSZNohePfXakg" rolename="attitude"
type="_ALrEpBRAEeSZNohePfXakg" realizes="_AKGXUBRAEeSZNohePfXakg"/>
</element>
<element xmi:type="platform:Association" xmi:id="_ALkW8BRAEeSZNohePfXakg" name="NavManagementFunction"
description="Platform entity representing the navigation management function."
realizes="_AKIMgBRAEeSZNohePfXakg">
<composition xmi:type="platform:Composition" xmi:id="_ALk-ABRAEeSZNohePfXakg" rolename="attitude"
type="_ALrEpBRAEeSZNohePfXakg" realizes="_AKIMgRRAEeSZNohePfXakg"/>
<composition xmi:type="platform:Composition" xmi:id="_ALk-ARRAEeSZNohePfXakg" rolename="position"
type="_ALp2gBRAEeSZNohePfXakg" realizes="_AKIMghRAEeSZNohePfXakg"/>
<associatedEntity xmi:type="platform:AssociatedEntity" xmi:id="_ALllEBRAEeSZNohePfXakg"
rolename="imuNavSource" upperBound="-1" type="_ALhToBRAEeSZNohePfXakg"
realizes="_AKIzkBRAEeSZNohePfXakg" path=""/>
<associatedEntity xmi:type="platform:AssociatedEntity" xmi:id="_ALllERRAEeSZNohePfXakg"
rolename="egi1NavSource" upperBound="-1" type="_ALjv4BRAEeSZNohePfXakg"
realizes="_AKJaoBRAEeSZNohePfXakg" path=""/>
<associatedEntity xmi:type="platform:AssociatedEntity"
xmi:id="EAID_6D3938D1_2BDB_423d_8131_3E8D7E074E0D" rolename="egi2NavSource" upperBound="-1"
type="EAID_CF6F14E1_DD1D_439b_A993_7B9F0CE0E7A0" realizes="EAID_DCE7CA57_55AC_41b6_A9C4_A51973392FF9"
path=""/>
</element>
<pdm xmi:type="face:PlatformDataModel" xmi:id="_ALmMIBRAEeSZNohePfXakg" name="Physical_Data_Types">
<element xmi:type="platform:Double" xmi:id="_8vWQEBQxEeSHdN934ouJpQ" name="Altitude"
description="Physical data type representing the altitude component of the position measurement."
realizes="_vZiY4Ag5EeSFspy8Kj3F4Q"/>
<element xmi:type="platform:Double" xmi:id="_ALooZhRAEeSZNohePfXakg" name="HeadingDegree"
description="Physical data type representing the heading component of attitude in degrees."
realizes="EAID_C6705DC3_8C55_4de3_A7A6_C7B36A93C5A3"/>
<element xmi:type="platform:Double" xmi:id="_ALpPcRRAEeSZNohePfXakg" name="Latitude"
description="Physical data type representing the latitude component of the position measurement."
realizes="_vZiY4wg5EeSFspy8Kj3F4Q"/>

<element xmi:type="platform:Double" xmi:id="_ALpPchRAEeSZNohePfXakg" name="Longitude"
description="Physical data type representing the longitude component of the position measurement."
realizes="_vZiY5Ag5EeSFspy8Kj3F4Q"/>
<element xmi:type="platform:Double" xmi:id="_ALnaQBRAEeSZNohePfXakg" name="PitchDegree"
description="Physical data type representing the pitch component of attitude in degrees."
realizes="EAID_1E4718CF_69A1_459d_B69A_73171E3B4B38"/>
<element xmi:type="platform:Double" xmi:id="_ALnaQhRAEeSZNohePfXakg" name="RollDegree"
description="Physical data type representing the roll component of attitude in degrees."
realizes="EAID_FAE1C598_8B37_4329_A065_0AEE5E518F65"/>
<element xmi:type="platform:IDLStruct" xmi:id="_ALrEpBRAEeSZNohePfXakg" name="AttitudeDegree"
description="Physical data structure representing the attitude components."
realizes="EAID_199CAB4E_D00F_4e3c_BB08_00DCC2C374AC">
<composition xmi:type="platform:IDLComposition" xmi:id="_ALrEphRAEeSZNohePfXakg"
type="_ALnaQBRAEeSZNohePfXakg" rolename="pitch"/>
<composition xmi:type="platform:IDLComposition" xmi:id="_ALrEpRRAEeSZNohePfXakg"
type="_ALnaQhRAEeSZNohePfXakg" rolename="roll"/>
<composition xmi:type="platform:IDLComposition" xmi:id="_ALrEpxRAEeSZNohePfXakg"
type="_ALooZhRAEeSZNohePfXakg" rolename="yaw"/>
</element>
<element xmi:type="platform:IDLStruct" xmi:id="_ALp2gBRAEeSZNohePfXakg" name="WGS84Position"
description="Physical data structure representing the position components."
realizes="_vZiY3Ag5EeSFspy8Kj3F4Q">
<composition xmi:type="platform:IDLComposition" xmi:id="_BkHmoBQyEeSHdN934ouJpQ"
type="_8vWQEBQxEeSHdN934ouJpQ" rolename="altitude"/>
<composition xmi:type="platform:IDLComposition" xmi:id="_ALqdkBRAEeSZNohePfXakg"
type="_ALpPcRRAEeSZNohePfXakg" rolename="latitude"/>
<composition xmi:type="platform:IDLComposition" xmi:id="_ALqdkRRAEeSZNohePfXakg"
type="_ALpPchRAEeSZNohePfXakg" rolename="longitude"/>
</element>
</pdm>
<pdm xmi:type="face:PlatformDataModel" xmi:id="_ALrEqBRAEeSZNohePfXakg" name="PlatformViews">
<element xmi:type="platform:View" xmi:id="_ALsSwBRAEeSZNohePfXakg" name="EGI_Data"
description="Conceptual view representing EGI data." realizes="_AKJaohRAEeSZNohePfXakg">
<characteristic xmi:type="platform:CharacteristicProjection"
xmi:id="EAID_C048D526_764D_419b_9176_9F1584E256FE"
projectedCharacteristic="_ALjv4BRAEeSZNohePfXakg" rolename="att"
realizes="EAID_E7FC4175_620B_40a0_BCFB_B548B3A95449" path=".attitude"/>
<characteristic xmi:type="platform:CharacteristicProjection" xmi:id="_ALtg4BRAEeSZNohePfXakg"
projectedCharacteristic="_ALjv4BRAEeSZNohePfXakg" rolename="pos" realizes="_AKKBsBRAEeSZNohePfXakg"
path=".position"/>
</element>
<element xmi:type="platform:View" xmi:id="_ALuH8RRAEeSZNohePfXakg" name="IMU_Data"
description="Conceptual view representing the IMU data." realizes="_AKKowhRAEeSZNohePfXakg">
<characteristic xmi:type="platform:CharacteristicProjection" xmi:id="_ALuH8hRAEeSZNohePfXakg"
projectedCharacteristic="_ALhToBRAEeSZNohePfXakg" rolename="att" realizes="_AKKowxRAEeSZNohePfXakg"
path=".attitude"/>
</element>
<element xmi:type="platform:View" xmi:id="_ALtg4RRAEeSZNohePfXakg" name="Nav_Data"
description="Conceptual view representing the resolved navigation data."
realizes="_AKKBsRRAEeSZNohePfXakg">
<characteristic xmi:type="platform:CharacteristicProjection" xmi:id="_ALuH8BRAEeSZNohePfXakg"
projectedCharacteristic="_ALkW8BRAEeSZNohePfXakg" rolename="att" realizes="_AKKowRRAEeSZNohePfXakg"
path=".attitude"/>
<characteristic xmi:type="platform:CharacteristicProjection" xmi:id="_ALtg4hRAEeSZNohePfXakg"
projectedCharacteristic="_ALkW8BRAEeSZNohePfXakg" rolename="pos" realizes="_AKKowBRAEeSZNohePfXakg"
path=".position"/>
</element>
</pdm>
</pdm>
</pdm>
<uopModel xmi:type="face:UoPModel" xmi:id="_ALvWEBRAEeSZNohePfXakg" name="UoP_Model">
<element xmi:type="uop:PortableComponent" xmi:id="_AL01oRRAEeSZNohePfXakg" name="NavigationManager"
description="Navigation Manager Unit of Portability." faceProfile="Security" partitionType="ARINC653"
notes="">
<port xmi:type="uop:MessagePort" xmi:id="_AL1csRRAEeSZNohePfXakg" name="EGI1_Data" description="Message
port for EGI 1." messageType="_ALsSwBRAEeSZNohePfXakg" communicationStyle="SingleInstanceMessaging"
messageExchangeType="OutboundMessage" period="0.05" programmingLanguage="Ada"
synchronizationStyle="NonBlocking"/>
<port xmi:type="uop:MessagePort" xmi:id="_AL01oxRAEeSZNohePfXakg" name="EGI2_Data" description="Message
port for EGI 1." messageType="_ALsSwBRAEeSZNohePfXakg" communicationStyle="SingleInstanceMessaging"
<port xmi:type="uop:MessagePort" xmi:id="_AL01ohRAEeSZNohePfXakg" name="IMU_Data"
messageType="_ALuH8RRAEeSZNohePfXakg" communicationStyle="SingleInstanceMessaging"
<port xmi:type="uop:MessagePort" xmi:id="_AL1csBRAEeSZNohePfXakg" name="NavData"
messageType="_ALtg4RRAEeSZNohePfXakg" communicationStyle="SingleInstanceMessaging"
<aliasSet xmi:type="uop:AliasSet" xmi:id="EAID_E361F81B_31AB_3531_AEBE_B145FFED2DF5">
<alias xmi:type="uop:Alias" xmi:id="_AL2DwRRAEeSZNohePfXakg" name="IMU"
aliasedElement="_ALhToBRAEeSZNohePfXakg"/>
</aliasSet>
</element>
</uopModel>
</face:DataModel>

Glossary
Acronyms
The following acronyms are used within this Guide or included as an aid to understanding.
Acronym Definition
2D/3D 2-Dimensional/3-Dimensional
AC Aircraft
AED Aviation Engineering Directorate
APEX Application Executive
API Application Programming Interface
AQS Airworthiness Qualification Specification
AQSR Airworthiness Qualification Substantiation Report
ARINC Aeronautical Radio Inc.
ARP Aerospace Recommended Practice
ASR Alternative System Review
AT Anti-Tamper
AWR Airworthiness Release
AVS Air Vehicle Systems
BC Bus Controller
BLOS Beyond Line of Sight
BM Bus Monitor
BSP Board Support Package
C&A Certification & Accreditation
CBIT Continuous Built-In Test
CCB Configuration Control Board
CCD Component Configurability Definition
CCS Component Configuration Set
Acronym Definition
CDR Critical Design Review
CDRL Contract Data Requirements Lists
CDS Cockpit Display System
CDU Control and Display Unit
CL Confidentiality Level
CM Configuration Management
CNSS Committee on National Security Systems
COE Common Operating Environment
COMM Communications Management
COMSEC Communications Security
COP Common Operating Picture
CORBA Common Object Request Broker Architecture
COTS Commercial Off-The-Shelf
CPI Critical Program Information
CPID Configuration Parameter Identifier
CRC Cyclical Redundancy Checking
CSC Computer Software Component
CSCI Computer Software Configuration Item
CSEP Component Set Encoding Package
CSID Configuration Set Identifier
CSIL Component Set Identifier List
CT Critical Technology
DAA Designated Approving Authority
DAFIF Digital Aeronautical Flight Information File
DAL Design Assurance Level
DDS Data Distribution Service
DHS Department of Homeland Security
DIACAP Department of Defense Information Assurance Certification and Accreditation

Process

Acronym Definition
DigMap Digital Map
DIL Disadvantaged, Intermittent, Limited
DISA Defense Information Systems Agency
DMA Dynamic Memory Access
DME Distance Measuring Equipment
DO Document
DoD Department of Defense
DoDAF Department of Defense Architecture Framework
DoDD Department of Defense Directive
DoDI Department of Defense Instruction
DPM Device Protocol Mediation
DTD Data Transfer Device
DTED Digital Terrain Elevation Data
EGI Embedded Global Positioning System/Inertial Navigation System
EIA Electronic Industries Alliance
ERCC Error Checking and Correction
ESM Electronic Support Measures
EXT System Data Model Extensions
FAA Federal Aviation Administration
FACE Future Airborne Capability Environment
FCS Flight Control System
FHA Functional Hazard Assessment
FIFO First In, First Out
FIPS Federal Information Processing Standard
FISMA Federal Information Security Management Act
FMEA Failure Modes Effects Analysis
GE General Electric
GLX OpenGL Extension to the X Window System
Acronym Definition
GNU GNUs Not UNIX
GOTS Government Off-The-Shelf
GP General-Purpose
GPR Government Purpose Rights
GPS Global Positioning System
GPU Graphics Processing Unit
GUID Globally Unique Identifier
HAIPE High Assurance Internet Protocol Encryptor
HMFM Health Monitoring/Fault Management
I/O Input/Output
IA Information Assurance
IBIT Initiated Built-In Test
ICAO International Civilian Aviation Organization
ICD Interface Control Document
ID Identification, Identifier
IDD Interface Design Description
IDL Interface Definition Language
IEDM Information Exchange Data Model
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ILS Instrument Landing System
IMA Integrated Modular Avionics (as defined by DO-297)
IMU Inertial Measurement Unit
INFOSEC Information Security
INS Inertial Navigation System
IOS Input/Output Services
IOSS Input/Output Services Segment
IP Internet Protocol

Acronym Definition
IPC Inter-Process Communication
IRS Interface Requirements Specification
ISBN International Standard Book Number
ISIS Institute for Software Integrated Systems
ISO/IEC International Organization for Standardization/International Electrotechnical

Commission
IT Information Technology
JC3 Joint Consultation, Command, and Control
LDM Logical Data Model
LOS Line of Sight
LRU Line Replaceable Unit
MAC Mission Assurance Category
MBE Model-Based Engineering
MCDU Multi-purpose Control and Data Unit
MIL-STD Military Standard
MISRA Motor Industry Software Reliability Association
MMU Memory Management Unit
MOF Meta Object Facility
MOSA Modular Open Systems Approach
MPEG Moving Picture Experts Group
MSGID Message Identifier
MUX Multiplex
NAS National Airspace
NAVAIR Naval Air Systems Command
NAVSEA Naval Sea Systems Command
NIAP National Information Assurance Partnership
NIST National Institute of Standards and Technology
NSA National Security Agency
NSS National Security System
Acronym Definition
NSTISSP National Security Telecommunications and Information Systems Security Policy
OAR Online Applications Research
OCL Object Constraint Language
OE Operating Environment
OFP Operational Flight Program
OMG Object Management Group
OPSEC Operations Security
ORB Object Request Broker
OS Operating System
OSS Operating System Segment
PBIT Periodic Built-In Test
PCS Portable Components Segment
PDR Preliminary Design Review
PDS Platform-Specific Device Service
PIT Platform Information Technology
POSIX Portable Operating System Interface
PP Protection Profile
PPP Program Protection Plan
PSAC Plan for Software Aspects of Certification
PSS Platform-Specific Services
PSSA Preliminary System Safety Assessment
PSSS Platform-Specific Services Segment
QA Quality Assurance
QAW Quality Attribute Workshop
QoS Quality of Service
RFC Request for Comments
RGB Red, Green, Blue (color model)
RMF Risk Management Framework

Acronym Definition
RNP Required Navigation Performance
RT Remote Terminal
RTCA Radio Technical Commission for Aeronautics
RTOS Real-Time Operating System
RTP Real-time Transport Protocol
SA Situational Awareness
SAE Society of Automotive Engineers
SAS Software Accomplishment Summary
SDI Source/Destination Identifier
SDM Shared Data Model
SECNAVINST Secretary of the Navy Instruction
SED Systems Engineering Directorate
SETR Systems Engineering Technical Review
SFR System Functional Review
SMPTE Society of Motion Picture and Television Engineers
SNMP Simple Network Management Protocol
SQL Structured Query Language
SRG Security Requirements Guides
SRR System Requirements Review
SSA System Safety Assessment
SSE Systems Security Engineering
SSM Sign/Status Matrix
ST Security Target
STIG Security Technical Implementation Guides
SwA Software Assurance
SysML Systems Modeling Language
TACAN Tactical Air Navigation
TCP Transmission Control Protocol
Acronym Definition
TD Technical Directive
TLS Transport Layer Security
TS Transport Services
TSS Transport Services Segment
TWG Technical Working Group
UDP User Datagram Protocol
UHF Ultra High Frequency
UIS User Interface Service
UML Unified Modeling Language
UoP Unit of Portability
US United States
VHF Very High Frequency
VICTORY Vehicular Integration for (C4ISR) Command, Control, Communication,

Computers, Intelligence, Surveillance, Reconnaissance/Electronic Warfare (EW)
Interoperability
VOR Very High Frequency (VHF) Omni-directional Radio-Range
WG Working Group
WRA Weapons Replaceable Assembly
XMI XML Metadata Interchange
XML eXtensible Markup Language
XSD XML Schema Definition
Terms and Definitions
The following terms and phrases are defined both with respect to present day computer and
software engineering as well as their specific meaning within the FACE Technical Standard.
 Aircraft Platform: Represents an airframe that hosts mechanical, computing, and other
resources necessary to perform a particular mission within the aviation domain.
 Airworthiness Authority: The agency or entity responsible for flight safety and/or
airworthiness with signatory authority for Flight.
 Airworthiness Release: A Release for the DoD aircraft that FACE software components
are integrated into. Disposition of airworthiness is based on engineering cognizance and
documented evidence of qualification, resulting in Airworthiness Certification or Flight

Release in some form. For purposes of this section of the FACE Reference
Implementation Guide, certification refers to this subject, rather than to certification of
FACE conformance.
 API: An Application Programming Interface (API) is a particular set of rules and
specifications that a software program can follow to access and make use of the services
and resources provided by another particular software program that implements that API.
It serves as an interface between different software programs and facilitates their
interaction, similar to the way the user interface facilitates interaction between humans
and computers.
 Application: A software executable designed to allow a user to complete tasks.
 Application Characterization: A quantified description of the UoP for the purpose of
facilitating integration without exposing the internal design of the deliverable.
 Application Framework: See Component Framework.
 Build Time: The time when source code written in a programming language is
configured, compiled, and linked to form one or more machine-readable binary
executables.
 Capability: A set of software deliverables that provides one or more mission-level
facilities to the existing functionality of the current software suite.
 Centralized Configuration: A singular software component exists that manages the
initialization parameters of the individual software components or software configuration
items.
 CPID: Configuration Parameter ID. The name of a configurable parameter as modeled or
used in a configuration file. In the example, “MaxPower = 50”, MaxPower is the CPID
and 50 is the assigned value.
 CSCI: Computer Software Configuration Item (see Software Configuration Item for
details).
 CSID: Configuration Set Identifier. The name of a non-empty set of configurable
parameters.
 Compile Time: The time where source code written in a programming language is
analyzed and transformed into a machine-readable target language.
 Complex Software: Software for which a set of deterministic tests cannot be composed
that verify all possible combinations of paths through the system. Detailed qualification
guidance such as the Civil RTCA DO-178B/C and associated publications acknowledge
that the scope and intricacy of modern software is such that exhaustive testability is not
possible.
 Component Framework: A set of software deliverables providing a programming
language specific set of APIs that support application programming in a component
paradigm and often provide services which are useful to a wide range of applications.
 Computing Platform: The combination of hardware and the software infrastructure that
supports software components; it is the hardware the software is targeted to run on.
Typically refers to a processing hardware within a Weapons Replaceable Assembly
(WRA), or Line Replaceable Unit (LRU).
 Configurable Parameter: A named feature of configurable components which may be
used to effect a behavioral modification of the component without modifying its
executable object code. Behavioral modifications to the component are achieved by
assigning or otherwise associating values or objects (e.g., numbers, strings, structures)
with such a feature.
 Configuration: The selection of values or features of a component or system such that the
intended operational characteristics are achieved.
 Component Configuration File: An XML document containing the desired set of CPIDs
and selection of associated valid value for each. This XML model is to be encoded in a
way that is both native to the component and suitable for consumption at run-time to
achieve run-time configuration.
 Conformant: With respect to the FACE Technical Standard, this term applies when
software components and/or a computing architecture, environment, or platform meets all
of the stated requirements.
 Data Movement: Refers to the conveyance and/or transfer of data from one component to
another.
 Deactivated Code:
1. Source code that compiles conditionally and, when not enabled, generates no binary
executable code in the compiled file.
2. Binary executable portions of a compiled file that may be deselected from operation
based on run-time configuration information fed to the program at start-up or during
execution. This executable code traces to both software requirements and test cases that
verify its implementation. Further, the configuration mechanisms and the software that
controls the optional execution of the deactivated code trace to requirements and test
cases.
 Dead Code: Executable binary code that does not trace to software requirements or test
cases. This may include residual code from other applications of a source code module,
extraneous compiler/linker-generated binary, diagnostic or maintenance code used by
developers or field personnel, and any other executable that is not engineered as part of
the system and properly documented.
 Distributed Configuration: Distributed Configuration of the initialization parameters is
the responsibility of the individual software components or software configuration items.
 Dynamic Personalization: Occurs when the software and hardware setting are adjusted
for a specific user during Run-time.
 Execution Time: The time post-initialization where a software program is loaded in
memory and in a running state (i.e., in the run-time state).

 FACE Component: Software that provides a specific capability or function.
 FACE Computing Environment: Includes all elements of the FACE Reference
Architecture necessary to deploy FACE conformant components. The FACE Computing
Environment is composed of the underlying computing and networking hardware, the
software infrastructure (Transport Services, Operating System, I/O Services Segments),
the Platform-Specific Services Segment, and any common services required by the FACE
components. The FACE Computing Environment is a generic concept and instantiated for
a particular system under development.
 FACE Computing Platform: A computing platform that hosts FACE components (see
Computing Platform).
 FACE Computing Software Infrastructure: Consists of the Operating System Segment,
the Transport Services Segment, and the I/O Services Segment.
 FACE Conformant: An implementation is considered FACE conformant if it adheres to
a subset of the FACE Technical Standards without going outside of the FACE Technical
Standards.
 FACE Software Infrastructure: See FACE Computing Software Infrastructure.
 Framework: See Application Framework.
 Framework Component: A component built to execute on a specified application
framework.
 Initialization Time: The time after software is loaded (i.e., within the run-time state)
where the software is given specific values using initialization parameters to perform
setup and prepare for execution time activities.
 I/O Service: The Input and Output Services provided by a computing platform,
specifically with respect to the movement of electronic data between the data bus and
PSS.
 Language Run-time: A set of software deliverables constituting a software layer that
provides a software programming language API and the capability to execute programs
written to that API.
 Level of Rigor: The level to which an increasingly stringent set of qualification
requirements are imposed on a software system, based on evaluation of the safety and/or
operational implications of loss or failure of functionality provided by the software.
 Logical Ports: The path over which data is moved between FACE architectural segments.
This is in reference to system data addressability between partitions or computing
platforms.
 Memory Management: The act of managing computer memory and involves the
allocation and deallocation of memory resources during run-time based on application
needs. This has the advantage of flexibility of operation, but it also has the disadvantage
of potential inefficiencies and lack of predictability during operations. Since efficiency
and predictability are extremely important aspects of most real-time systems, pre-
allocation of computing resources such as memory, processes, threads, file descriptors,
etc. is required, and is mandatory in the Safety and Security Profile. The preferred design
approach to control these potential sources of non-determinism is through the use of pre-
allocated resource pools. With modern languages and OSs, it is possible to defer binding
of many system resources until run-time.
 Mission-level Capabilities: Software adding high-level discernible value to the user’s
mission. An example is “situational awareness” which adds value to some missions.
However, a bubble-sort is a supporting algorithm and while it may be a component of a
mission capability, it is not the mission capability itself.
 Monolithic Code Deliverable: A singular bundle of highly inter-dependent software
components characterized by a lack of modularity or that any single change to the code
has vast ramifications that are reviewed and tested.
 Partition: The term “partition” originates from ARINC 653, which discusses the
allocation and isolation of computing platform resources on a partition basis (the POSIX
Standard covers service interfaces only; it does not specify nor prohibit use of
partitioning). A partition is an OS allocation of computing platform and processor
resources, including time. An executable, implementing an application or portion of an
application, is associated with each partition. A partition provides a means to isolate
resources to a particular application, preventing other applications from using or
consuming them. In support of application independence, each partition has its own
virtual address space for resources to be assigned within.
System designers use partitions to host multiple applications on a computing platform. By
assigning separate time, memory, and other resources, applications may execute with
sufficient independence that changes in one application cannot impact the execution of
other applications running on the same computing platform.
Processor time is allocated by dividing a fixed-length period of time (referred to as the
major-frame) into fixed-length time windows. One or more time window is allocated to
each partition. By selecting time windows that are harmonic to the major frame, the
system designer can cause some partitions to execute at a faster rate relative to other
partitions (e.g., 20 Hz, 10 Hz, 5 Hz). When the partition schedule is started, the OS selects
the first time window of the major frame. When this time window has completed, the next
time window is selected. When the last time window of the major frame is complete, the
OS starts the processor-time allocation sequence over with the first time window of the
major frame. This sequence is repeated continuously until the computing platform is
power-downed, halted, or reset.
System designers may define partitions whose memory and other non-time resources are
separately allocated, but whose time allocations are identical. When so designated, all
threads associated with the applications assigned to the partitions will compete on a
priority pre-emptive basis. This capability permits applications to be tightly coupled (e.g.,
client/server) in terms of time response (e.g., sever can respond immediately instead of
waiting for a uniquely allocated time window to execute in). Note that applications
allocated to partitions that share time resources are considered dependent applications
(i.e., change in one application may directly impact the execution and time resources
available to the other time-coupled applications), which prevents their qualification at
different criticality levels).

 Personalization: Configuration of software and hardware setting is adjusted for a specific
user prior to run-time. For example, a pilot changing the zoom on a screen, powering it
off, and then powering it back up.
 Platform: Refers to one of two related things with respect to the FACE Technical
Standard: Aircraft (to include one or more computing platforms) and Computing
(comprised of electronic circuitry and software).
 Process: The term “process”, as discussed in this FACE Technical Standard, originates
from the POSIX Standard (in ARINC 653, the term “process” is equivalent to the POSIX
term “thread”). In concept, every partition has an associated process. Within a partition, a
process represents basic capabilities for execution, including a thread schedulable by the
OS. Historically, processes, like partitions, are allocated resources and an address space
by the OS. Like partitions, multi-process support historically permitted multiple
applications to execute on a computing platform. Within an application, threads provide
support for multiple independent execution sequences. Control over the partition time
allocations provides support for tightly coupled applications (using shared time
allocations) or loosely coupled applications (using unique time allocations).
 Point Solution: A solution intended to solve a unique issue or fill a capability gap.
 Portable: An attribute that describes the reuse of the existing code instead of creating new
code when moving software from an environment to another. The pre-requirement for
portability is the generalized abstraction between the application logic and system
interfaces. When targeting several platforms with the same application, portability is the
key issue for development cost reduction. Software is portable if it can easily be ported to
multiple platforms. A FACE conformant component is portable between FACE
Computing Environments and is the main goal of the FACE architecture.
 Programming Language Run-time: See Language Run-time.
 Qualification: Achievement of qualification objectives, as defined by the Airworthiness
Authority.
 Qualification Authority: See Airworthiness Authority.
 Qualification Objectives: Specific activities required to establish the quality of a
software development and its output.
 Run-time Application: A software program that is only functioning and operational once
a computing platform has completed the start-up sequence and is now ready for normal
run-time operations.
 Run-time Configuration: The act of assigning valid values or objects (e.g., strings) to
configurable parameters of an executing component.
 Safety: The freedom from conditions that can cause death, injury, occupational illness,
damage to or loss of equipment or property, or damage to the environment.
 Safety Assessment: A rigorous analysis of the details of software functionality necessary
to establish a level of design assurance (qualification level of rigor) applied to ensure
safety and effective operation.
 Safety-critical: A term applied to a condition, event, operation, process, or item whose
mishap severity consequence is either Catastrophic or Critical (e.g., safety-critical
function, safety-critical path, and safety-critical component).
 Safety-related Software: Components for which a safety analysis has determined that a
high level of criticality exists, requiring achievement of qualification tasks and
documentation of development practices consistent with a high level of rigor.
 Segment: A logical grouping of applications and/or services within a boundary whereby
elements within are allowed to vary based on system needs and the interface to elements
outside the segment boundary adhere to the FACE Technical Standard.
 Service: A software utility providing capability to software applications or other services.
 Software Component: A functionally or logically distinct part of a system, distinguished
for the purpose of convenience in designing and specifying a complex system as an
assembly of subordinate elements (ISO/IEC 24765:2010).
 Software Configuration Item: A software configuration item is an aggregation of
software designated for Configuration Management and treated as a single entity in the
Configuration Management process (ISO/IEC 24765:2010). This entity satisfies an end
use function and can be uniquely identified at a given reference point (ISO/IEC
12207:2008 §4.7).
 Technical Data Package: A consolidation of information used by designers and
manufacturers describing a software product or component. A collection of all the
information needed to integrate and deploy a specific software component or UoP.
 Third Party: An entity (business, person, or component) that is beyond the two primary
interacting parties.
 Thread: A schedulable execution sequence within an application (ARINC 653 uses the
term “process” when referring to thread behaviors).
 Traditional Transport Middleware: A general description for a software component(s)
that is responsible for transferring data between applications and the OS.
 Tuple: A finite ordered set of terms. In this context a tuple refers to the ordered set of a
CPID and a selected value for that CPID. Configuration tuples take the form of {<CPID>,
<value>}.
 UML: Unified Modeling Language is a standardized general-purpose modeling language
in the field of object-oriented software engineering. The standard was created and is
managed by the OMG. UML includes a set of graphic notation techniques to create visual
models of object-oriented software-intensive systems.
 XML: eXtensible Markup Language is a set of rules for encoding documents in a format
that is both human-readable and machine-readable. The design goals of XML emphasize
simplicity, generality, and usability over the Internet. It is widely used for the
representation of arbitrary data structures; for example, in web services. This Standard
was created and is managed by the World Wide Web Consortium (W3C).

 XSD: Like all XML schema languages, XML Schema Definition can be used to express a
set of rules to which an XML document conforms in order to be considered “valid”
according to that schema. However, unlike most other schema languages, XSD was also
designed with the intent that determination of a document's validity would produce a
collection of information adhering to specific data types. This Standard was created and is
managed by the World Wide Web Consortium (W3C).

Face Technology PDF

Uploaded by

Copyright:

Available Formats

Face Technology PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Face Technology PDF

Uploaded by

Copyright:

Available Formats

What are the main topics discussed in the document?

What are the main topics discussed in the document?

What is the purpose of the document?

What is the purpose of the document?

Open Group Guide

Reference Implementation Guide for

Vice Admiral (ret.) Arthur K. Cebrowski

NAVAIR Public Release 2015-268

Open Group Guide

Published by The Open Group, April 2016.

ii Open Group Guide (2016)

2 Segment Guidance .................................................................................................... 4

4 FACE Profile Guidance ........................................................................................ 107

5 Data Architecture Guidance .................................................................................. 111

6 Health Monitoring/Fault Management Guidance ................................................. 131

iv Open Group Guide (2016)

7 Graphics Services Guidance ................................................................................. 143

8 Configuration Services Guidance ......................................................................... 152

9 Language Run-Time Guidance ............................................................................. 164

10 Safety Guidance .................................................................................................... 167

11 Security Guidance ................................................................................................. 168

12 Implementation Scenario Examples ...................................................................... 178

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 v

A Example of a FACE Conformant Implementation ................................................ 221

B FACE Data Model UML Profile ........................................................................... 233

C Configuration Services API .................................................................................. 310

D Standard Color Index ............................................................................................ 319

E XSD Schema for Configuration File ..................................................................... 325

vi Open Group Guide (2016)

G FACE Framework Interface .................................................................................. 357

viii Open Group Guide (2016)

H Example USM FACE XMI ................................................................................... 376

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 ix

x Open Group Guide (2016)

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xi

xii Open Group Guide (2016)

Further information on The Open Group is available at www.opengroup.org.

This document is a Reference Implementation Guide to be used in conjunction with the

xiv Open Group Guide (2016)

Linux® is a registered trademark of Linus Torvalds.

LynxOS® is a registered trademark of Lynx Software Technologies, Inc.

POSIX® is a registered trademark of the IEEE.

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 xv

 Kirk Avery, Lockheed Martin

 Judy Cerenzia, The Open Group

With special thanks to W. Mark Vanfleet, National Security Agency (NSA).

xvi Open Group Guide (2016)

xviii Open Group Guide (2016)

1.2 FACE Approach

The FACE approach to software portability and reuse consists of:

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 1

The FACE approach allows software-based “capabilities” to be developed as components that

1.3 Scope of this Document

2 Open Group Guide (2016)

PSSS Units of Conformance (UoC)

One or more Components can make up a UoC

Figure 1: FACE Terminology

Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1 3

The five (5) segments of the FACE Technical Standard are: