DRAFT
4.1 Relationship to the Functional ReferenceModel
4.2 TRM Overview
4.3 Application Software Entity
4.3.1 Mission Area Applications
4.3.2 Common Support Applications
4.4 Application Platform Entity
4.4.1 Operating System Services
4.4.2 Software Engineering Services
4.4.2.1 Programming Languages
4.4.2.2 Language Bindings and Object Linking
4.4.2.3 Computer Aided Software Engineering (CASE) Environments and Tools
4.4.3 User Interface Services
4.4.4 Data Management Services
4.4.5 Data Interchange Services
4.4.6 Graphics Services
4.4.7 Communications Services
4.4.8 Internationalization Services
4.4.9 Security Services
4.4.10 System Management Services
4.4.11 Distributed Computing Services
4.5 External Environment Entity
4.6 Application Program Interfaces
4.6.1 System Services API
4.6.2 Human/Computer Interaction Services API
4.6.3 Information Services API
4.6.4 Communications API
4.7 External Environment Interfaces
4.7.1 HCI Services EEI
4.7.2 Standards in this area will be addressed in a later version of the ARITA.
Information Services EEI
4.7.3 Standards in this area will be addressed in a later version of the ARITA.
Network Services EEI
The airborne reconnaissance Technical Reference Model (TRM) providesa common framework depicting the open systems software environment to befollowed in migrating or developing airborne reconnaissance systems. TheTRM was derived from the Technical Architecture Framework for InformationManagement (TAFIM). Information technology (IT) standards follow the DoDJoint Technical Architecture (JTA) - Draft Version 1.0, 25 July 1996.
The FRM (Figure 3-1) represents information flow from an operationalor functional view, whereas the TRM represents the software interactionsin satisfying discrete services or functions associated with IT. These services/functionsassociated with IT apply to various areas of the FRM, especially OperatorOriented Processing Functions (purple), High Performance Processing Functions(orange), Networking Functions (red) Reporting and Connectivity Functions(yellow).
The TRM shown in Figure 4-1 does not imply any specific system design;rather, its purpose is to provide the framework for defining IT standards.As with the TAFIM, the airborne reconnaissance TRM is based on the POSIXOpen System Reference Model and includes three entities and two classesof interfaces. The three entities are the Application Software Entity,the Application Platform Entity, and the External EnvironmentEntity. The classes of interfaces are the Application ProgramInterfaces (APIs) and the External Environment Interfaces(EEIs).
The Application Software Entity includes the Intelligence Mission Area Applications(SIGINT, IMINT, MASINT), as well as common support applications. The ApplicationSoftware Entity resides on the Application platform. The Application PlatformEntity provides platform services and processing capabilities. The ExternalEnvironment includes entities (such as operators, removable disks/tapes,and communication pathways) with which the application platform exchangesinformation.
A description of each entity and interface identified in the TRM is givenin the following subsections together with identification of standards selectedfor airborne reconnaissance systems (i.e., mandated), and references tostandards which are not yet mature enough to select but show promise forresolving specific technical architecture issues. 
Figure 4-1: Airborne Reconnaissance Technical Reference Model
The Application Software Entity comprises the airborne reconnaissanceMission Area Applications and Common Support Applications. This applicationsoftware may be commercial off the shelf (COTS), government off the shelf(GOTS), custom-developed software, or a combination of these. The followingmandate applies:
4.3.1 Mission Area Applications
Mission area applications implement specific end user requirements (e.g.,multi-sensor information processing, control of real-time systems, decisionsupport, analysis of order of battle). These applications encompass allsoftware embedded in airborne reconnaissance and associated ground/surfacesystems. The Imagery Exploitation Support System (IESS) is the only "standardized"mission area application identified for the ARITA to date (see Section 3.6.3).This system was selected by the ISB (with CIO and DARO concurrence) to bethe migration system for imagery exploitation management functions. * Future applications will address the SIGINT and MASINTareas.
4.3.2 Common Support Applications
Common support applications (e.g., message handling, graphics, imagery)can be standardized across individual or multiple mission areas. The servicesthey provide can be used to develop mission-area-specific applications orcan be made available to the user. The TAFIM TRM defines six (6) commonsupport application categories: Multimedia, Communications, Business Processing,Environment Management, Database Utilities, and Engineering Support. Thedefinitions of these categories are found in the TAFIM, Volume 2, Section2.4.2. One additional category has been added for the airborne reconnaissanceTRM: Navigation and Timing.
The Application Platform Entity includes the standard services upon whichthe required functionality is built. The Application Platform Entity isused by support applications and unique mission area applications software.The TAFIM TRM version 3.0 defines seven (7) service areas within the ApplicationPlatform Entity: Operating System, Software Engineering, User Interface,Data Management, Data Interchange, Graphics, and Communications. The TAFIMTRM also defines four (4) Application Platform cross-service areas: Internationalization,Security, System Management, and Distributed Computing services. The definitionsof these services are found in the TAFIM, Volume 2, Section 2.4.3 and 2.4.4respectively. The corresponding mandates are provided in the following subsections.
4.4.1 Operating System Services
These core services are necessary to operate and administer a computer platformand to support the operation of application software. They include kerneloperations, shell, and utilities. The kernel controls access to informationand the underlying hardware. These services are accessed by applicationsthrough either the standard Portable Operating System Interface (POSIX)(e.g., VX Works, Solaris 2.3, HP-UX 9.01) or WIN32 APIs. The standards forARITA are:
4.4.2 Software Engineering Services
The software engineering services provide system developers the tools appropriateto the development and maintenance of applications. These include programminglanguages, language bindings and object code linking, and Computer AidedSoftware Engineering (CASE) environments and tools.
4.4.2.1 Programming Languages
Language services provide the basic syntax and semantic definitions foruse by developers to describe the desired software function. Ada is mandatedin DoD Directive 3405.1. This directive requires that Ada be used for customdeveloped software in all DoD system developments. This mandate does notinclude software that is developed and maintained commercially. Softwaredevelopment will be based on Ada 95. Ada 95 is backward compatible withAda 83 language specification. The standards for ARITA are:
4.4.2.2 Language Bindings and Object Linking
Language bindings and object code linking provide the ability for softwareto access services and software through API's that have been defined independentlyof the computer language. Ada bindings will be used to provide the interfaceto COTS or GOTS software that is developed in other languages. The standardsfor ARITA are:
4.4.2.3 Computer Aided Software Engineering(CASE) Environments and Tools
CASE provides the environment and tools, include systems and programs thatassist in the automated development and maintenance of systems (hardwareand software). The standards for ARITA are:
4.4.3 User Interface Services
These services implement the Human-Computer Interface (HCI) style and controlhow users interact with the system. The ARITA follows the JTA which mandateseither Common Desktop Environment (CDE) version 1.0 based on X window systemand Open System Foundation (OSF) Motif APIs, or the applicable native windowingWIN32 APIs The standards for ARITA are:
4.4.4 Data Management Services
These services support the definition, storage, and retrieval of data elementsfrom monolithic and distributed, relational Database Management Systems(DBMSs). These services also support platform-independent file management(e.g., the creation, access, and destruction of files and directories).The ARITA follows the JTA which mandates conformance to Entry level ANSIStructured Query Language (SQL) standards and adds Ada interfaces. The standardsfor ARITA are:
4.4.5 Data Interchange Services
The data interchange services provide specialized support for the exchangeof data and information between applications and to and from the externalenvironment. These services include document, graphics data, geospatialdata, imagery data, product data, audio data, video data, atmospheric data,oceanographic data, and compression interchange services.
The ARITA follows the JTA for the following mandated standards. Emergingstandards are identified in JTA Section 2.3.4.
Additional standards for data interchange services that apply to imagery-relatedsystems are identified in Section 4 of the USIS Standards and Guidelinesdocument, Version 1, dated 13 October 1995.
Message standards for airborne reconnaissance reporting functions are citedin ARITA Sections 3.7.1 and 3.7.2.
4.4.6 Graphics Services
These services support the creation and manipulation of graphics. They includedevice-independent, multidimensional graphic object definition, and themanagement of hierarchical database structures containing graphics data.The ARITA follows the JTA which mandates standards for non-COTS graphicsdevelopment in JTA Section 2.2.2.1.5, Graphics Services. Additional standardsfor the ARITA are:
4.4.7 Communications Services
These services support the distributed applications that require data accessand applications interoperability in networked environments. The mandatedand emerging standards identified in Section 3 of the JTA apply to the ARITA.
4.4.8 Internationalization Services
The internationalization services provide interfaces that allow a user todefine, select, and change between different culturally related applicationenvironments supported by the particular implementation. These servicesinclude character sets, data representation, cultural convention, and nativelanguage support. The standards mandated in Section 2.2.2.2.1 of the JTAapply to the ARITA.
4.4.9 Security Services
These services assist in protecting information and processing platformresources. They must often be combined with security procedures, which arebeyond the scope of the information technology service areas, to fully meetsecurity requirements. Security services include security policy, accountability,assurance, user authentication, access control, data integrity and confidentiality,non-repudiation, and system availability control. The mandated and emergingstandards identified in Section 6 of the JTA apply to the ARITA.
4.4.10 System Management Services
These services provide capabilities to manage the Application Platform Entity(Section 4.4), its resources and users. System management services includeconfiguration management, performance management, and fault management.There are no standards currently mandated for systems management in theJTA (Section 2.2.2.2.3). Additional standards that apply to the ARITA are:
4.4.11 Distributed Computing Services
These services allow various tasks, operations, and information transfersto occur on multiple, physically- or logically- dispersed, computer platforms.These services include but are not limited to global time; data, file andname services; thread services; and remote process services. In additionto the standards mandated in the JTA Section 2.2.2.2.4, the ARITA mandates:
An external environment entity exchanges information with the applicationplatform. These entities include system users (e.g., operators) with informationinterchange through a keyboard, display monitor, mouse, track ball, etc.;information interchanges (e.g., tape drives, disk drives, etc.), andnetworking (e.g., terrestrial landlines, satellite circuits, data links,LANs, etc.). As with the JTA, standards in this area will be addressed ina later version of the ARITA.
An application software entity communicates with the Application PlatformEntity though application program interfaces (APIs). Application portability,system interoperability, and application interoperability can be realizedthrough use of standardized APIs.
The Reference Model API is based on the POSIX.0 API, as defined in the DraftGuide to POSIX Open Systems Environment, IEEE P1003.0 (also known asPOSIX.0), which has four (4) parts:
Standards in this area will be addressed in a later version of the ARITA.
4.6.1 System Services API
The System Services API provides access to resources thatare internal to the application platform entity. These include API's forSoftware Engineering Services and Operating System Services. Two such servicesare listed below:
Standards in this area will be addressed in a later version of the ARITA.
4.6.2 Human/Computer Interaction ServicesAPI
The Human-Computer Interaction Services API supports User Interface andGraphics Services. Access to other services in the TRM are provided throughthe User Interface Services. Standards in this area will be addressed ina later version of the ARITA.
4.6.3 Information Services API
The Information Services API supports Data Management and Data InterchangeServices. Standards in this area will be addressed in a later version ofthe ARITA.
4.6.4 Communications API
The Communications Services API supports services associated with CommunicationsServices.
Many application platform entities will interact through communicationsnetworks that are part of the external environment. Application softwareentities typically will request access to communications services throughan API that will, in turn, take the appropriate action at the EEI to providerequested connectivity. Communication will then occur via external entitiesthat provide data transport functions. By providing distributed computingthrough a standardized API, the distributed system can be viewed by a userand by an application software entity as being only a single applicationplatform entity.
Standards in this area will be addressed in a later version of the ARITA.
The EEIs are the interfaces with which the application platform entityexchanges information with the outside world, whether that outside worldis a user, a peripheral storage device, communications system/network, oranother application platform entity. There are three (3) types of EEIs providedby the application platform entity:
Standards in this area will be addressed in a later version of the ARITA.
4.7.1 HCI Services EEI
The HCI Services EEI is the physical interface across whichinteraction between the application platform and the human user takes place.As such, it includes, display monitors, keyboards, mouse, track balls, joysticks,printers, removable disk/tapes, and additional input/output devices (e.g.,scanners, digitizers). Standardization of this interface, as is the generaltrend, allows the user to access the services of multiple systems with relativeease and access the services of compliant systems without retraining.
4.7.2 Information Services EEI
The Information Services EEI defines the boundary across whichexternal peripheral, persistent information storage is provided and wherestandards for format and syntax need be defined for data portability andinteroperability. Examples of the types of devices to which these interfacesare found include diskettes, hard disks, and CD-ROM, write-once read-many(WORM), Electro-Optical (EO), and Magneto-Optical (MO) Standards in thisarea will be addressed in a later version of the ARITA. Information ServicesEEI.
drives.
4.7.3 Network Services EEI
The Network Services EEI supports services for interactionbetween application software entities, running on the local applicationplatform, (e.g., single board computers) with remote application platformsand application software entities running on them. Thus, it provides supportfor external data transport facilities and devices using standards for protocolstate, syntax, and format to ensure application interoperability throughthe application platform(s). When the application platform is a device suchas a single board computer or a memory unit then the EEI may be a set ofbackplane standards such as VME Bus. Standards in this area will be addressedin a later version of the ARITA. Network Services EEI.
Additional standards in this area will be addressed in alater version of the ARITA.