1、AIR5315Issued 1998-04Overview and Rationale for GOA Framework StandardFOREWORDThis SAE Aerospace Information Report (AIR) was developed as a supplement to SAE AS4893 Generic Open Architecture (GOA) Framework standard. This AIR provides an overview and rationale of the GOA Framework. This AIR was pre
2、pared under the direction of:Chuck Roark Chairman, AS-5 CommitteeBosch Telecom, Inc.P.O. Box 742466Dallas, TX 75374TABLE OF CONTENTS1. SCOPE .31.1 Purpose .31.2 Intended Audience.31.3 Document Structure.42. REFERENCES .42.1 Standards 42.2 Specifications.42.2.1 Government Specifications42.3 Other Pub
3、lications .53. GOA FRAMEWORK DESCRIPTION .53.1 Purpose of GOA Framework Structure53.2 Baseline Document Overview - SGOAA63.3 Basic Concepts and Perspective.6Reaffirmed 2011-04AEROSPACEINFORMATIONREPORTSAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the s
4、tate of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.” SAE reviews each technical report at least every five
5、years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. Copyright 2011 SAE International All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electroni
6、c, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.orgSAE values your in
7、put. To provide feedbackon this Technical Report, please visit http:/www.sae.org/technical/standards/AIR5315SAE AIR5315- 2 -TABLE OF CONTENTS (Continued)4. GOA FRAMEWORK DEVELOPMENT APPROACH164.1 Evolution from SGOAA 164.2 Issues and Resolution164.3 Types of Companies and Agencies Involved.195. EXAM
8、PLES.195.1 Pi-Bus Mapping to GOA Framework195.2 GOA Stack Definition and Interface Control Documents (ICDs)205.2.1 Application Interfaces.205.2.2 System Services Interfaces .225.2.3 Resource Access Services and Physical Resources Interfaces226. COMPARISON TO OTHER MODELS226.1 POSIX Comparison236.2 I
9、SO OSI Comparison .236.3 TAFIM Comparison 246.4 PCMCIA Comparison.267. COMPLIANCE 30APPENDIX A 31A.1 Background31A.2 Objectives 31A.3 Approach33A.4 Results.35FIGURE A1- Mission and Operational Requirements for all Vehicles 35FIGURESFIGURE 1 - GOA Framework .7FIGURE 2 - Different Ways of Viewing GOA
10、Framework .11FIGURE 3 - Example Inter-Backplane Communication15FIGURE 4 - Recursion Using the GOA Framework15FIGURE 5 - Example GOA Stack and ICDs .21FIGURE 6 - Comparison of GOA Framework with POSIX and OSI Reference Models.23FIGURE 7 - DoD Technical Reference Model (from TAFIM v3.0).25FIGURE 8 - P
11、CMCIA Architecture28FIGURE 9 - Mapping of PCMCIA Architecture to GOA Framework - Alternative 128FIGURE 10 - Mapping of PCMCIA Architecture to GOA Framework - Alternative 230SAE AIR5315- 3 -1. SCOPE:This document is a companion document to SAE AS4893 “Generic Open Architecture (GOA) Framework Standar
12、d” and provides an overview and rationale for SAE AS4893. The GOA Framework establishes an architectural framework to assist in the application of open systems interface standards to the design of specific hardware/software systems. The GOA Framework standard is intended for use by both system desig
13、ners and system implementers in the development of open systems architectures. It is intended that domain specific guidelines be developed to provide clarification for application of the GOA Framework.The Generic Open Architecture (GOA) Framework was initially developed by the SAE to provide a frame
14、work which could be used to classify interfaces needed in airborne avionics systems. At the time of the development of the GOA Framework, development of such a classification was considered crucial to the application of open systems standards to military avionics. However, it was recognized during t
15、he development of the GOA that the GOA Framework might be applicable to domains other than avionics. For that reason the framework is entitled Generic Open Architecture instead of the original name, Generic Open Avionics Architecture (GOAA).This document is one of several documents contained within
16、the GOA document set. “Introduction to the GOA Family of Document Set”, SAE AIR5314, provides an overview of the GOA Family of Documents. SAE AIR5314, the GOA Framework Standard, and this document make up the domain independent set of documents within the GOA Family of Documents. These domain indepe
17、ndent documents are augmented with domain specific sets of document. The Domain specific sets of documents consist of a Catalog of Preferred Standards document, Rationale for Catalog of Preferred Standards Document, and GOA Guidance Document for each domain. The first domain specific set of document
18、s within the GOA Family of Documents being developed is for the aviation domain.1.1 Purpose:The purpose of this document is two-fold:1. provide detailed explanation of the key concepts contained within the GOA Framework standard.2. provide rationale for key concepts on which the GOA Framework standa
19、rd is based.1.2 Intended Audience:The intended audience for this document is anyone that has an interest in using or understanding the GOA Framework standard. This typically would include system engineers, hardware engineers, software engineers, engineering managers, project managers, academia, and
20、procurement personnel. This document assumes the reader is familiar with the GOA Framework, SAE AS4893.SAE AIR5315- 4 -1.3 Document Structure:This document is organized as follows:Section 1: Scope - provides an introduction and purpose to this document.Section 2: References - provides documents refe
21、renced within this document.Section 3: GOA Framework Description - provides a description of the GOA Framework.Section 4: GOA Framework Development Approach - provides an overview of how the GOA Framework was developed.Section 5: Examples - provides several examples of the application of the GOA Fra
22、mework.Section 6: Comparison With Other Models - compares the GOA Framework with other well-known reference models.Section 7: Compliance - discusses issues of compliance with the GOA Framework.Appendix A: Overview of the Space Generic Open Avionics Architecture (SGOAA) the baseline documents for the
23、 GOA Framework.2. REFERENCES:2.1 Standards:ISO International Organization for Standardization 7498: Information Processing Systems - Open Systems Interconnection - Basic Reference Model, 1984POSIX91 “Draft Guide to the POSIX Open Systems Environment”, P1003.0/D14, IEEE Computer Society, November 199
24、1SAE AS4893 “Generic Open Architecture (GOA) Framework”, SAE AS4893, SAE AS5, Jan 1996SAE AIR5314 “Introduction to the GOA Family of Document Set”, SAE AIR5314, SAE AS5, TBD2.2 Specifications:2.2.1 Government Specifications:TAFIM97 “Technical Architecture Framework for Information Management”, Defen
25、se Information Systems Agency, Version 3.0, April, 1997.SGOAAWray, R.B. and Stovall, J.R., “Space Generic Open Avionics Architecture SGOAA Standard Specification“, LESC-30354-C (NASA CR-188290), LockheedEngineering instead, information transfer takes place as part of one or more direct interfaces. S
26、imply stated, logical interfaces define what information is transferred, and direct interfaces define how the information is transferred.One example of a logical interface is the definition of interface requirements for exchange of latitude and longitude information from a Navigation application to
27、a Stores Management application. The logical interface defines information that would become the basis for an Interface Control Document (ICD) for Navigation to Stores Management communication. Another example of a logical interface is the message header used by a Communications XOS service to encap
28、sulate message data. This message header contains information that is interpreted by the peer Communications XOS service entities in order to make a message transfer occur. For example, logical designations of the message destination(s) and type might appear in such a header. The definition of the m
29、essage header is a logical interface that tells the two peer Communications XOS services how to initialize and interpret the message header when a message transfer actually takes place.Direct interfaces specify how components in one layer invoke services in the layer immediately below it within the
30、same GOA stack or how the physical layer in one GOA stack “physically“ interfaces with the physical layer of another GOA stack (e.g. between processor modules). Logical interfaces occur as the result of invocations of direct interfaces that support communications. For example, consider the latitude
31、and longitude logical interface example presented in the previous paragraph. If message-passing communication is used, the actual transfer of the latitude and longitude information would occur as the result of the Navigation application invoking a “send” operation in the System Services layer. The i
32、nvocation of the send routine would cause the system to physically transfer the data to make it available to the Stores Management application. The Stores Management application would then invoke a “receive” System Services operation to actually get the message containing latitude and longitude info
33、rmation. These send and receive routines are example of direct interfaces. However, there are also direct interfaces that have nothing to do with communications - these direct interfaces just invoke a service such as reading the time, allocating or deallocating memory, etc. The interface specificati
34、on of a component within a GOA layer designates the direct interfaces to that GOA layer. For example, POSIX defines a standard Operating System component interface; bus standards define the electrical characteristics of the bus.Thus, logical interfaces are considered important to define communicatio
35、n and synchronization requirements between peer-to-peer components. Direct interfaces are important for defining the interface to services (including communication services that make logical interfaces possible.)Before one can define interfaces, one must know what is being interfaced. The following
36、provides an overview of these components - the GOA layers and some rationale for choosing the GOA layers.SAE AIR5315- 9 -3.3 (Continued):The Application Software layer contains the platform level application specific code (or function).The application layer within a specific GOA stack can contain mu
37、ltiple software application components. The requirements for communication between different application components (whether within the same or different GOA stacks) is a logical interface. As noted above, the communication occurs through direct interfaces. For message passing paradigms, the communi
38、cation occurs by invoking message-passing services. If the interface is through shared memory (instead of message passing), the direct interface is simply a load or store operation, and the logical interface is the association of the address and size of the data. The 4D interfaces, i.e., Application
39、 Program Interfaces (APIs), are critical since they are important from a reuse perspective and a seamless upgradeability point-of-view. APIs support reuse by having the same Systems Services implemented the same way on different hardware platforms. Seamless upgrades can be supported by 4D interfaces
40、 since they abstract the Applications Software from the lower GOA layers.In particular, the Systems Service layer abstracts the Applications Software from changes in the Physical Resources layer, such as processor modifications/upgrades.The Physical Resources layer is the bottom-most layer and provi
41、des the interface between different physical components. The Physical Resources layer within a specific GOA stack can contain multiple Physical Resource components. The following are examples of Physical Resource components that might appear in the same GOA layer: Pi-Bus interface unit for intermodu
42、le data communication, TM-Bus interface unit for intermodule test and maintenance, IEEE-488 interface unit for debug, and CPU device for program execution. The 1D direct and 1L logical interfaces are clearly critical interfaces from a black box point-of-view. These interfaces include the physical an
43、d data link level definitions of busses where the electrical/mechanical requirements are direct (1D) interfaces and how the bits are interpreted are logical (1L) interfaces.The System Services Layer is provided to encapsulate common services accessed by the Application Software Layer. The Operating
44、System (OS) Service is the minimal component within the System Services Layer. XOSServices designate other components contained within the Systems Services Layer besides the OS. This layer is important since it allows an abstract view of common services required by applications. As discussed in sect
45、ion 4.2 Issues and Resolution, the 3X interface provides an interface between XOS and the OS services to provide either capabilities not included in the OS 4D interface (i.e., privileged operations) or optimized 4D interface capabilities.The optimization is for performance and could occur through an
46、 interface that has reduced checking or has less call overhead (such as avoiding a system trap). The logical 3L interface provides System Service Layer peer-to-peer interface communications interfaces. For example, the interpretation of the fields within the communications header added to a message
47、between two applications is an example of a 3L interface. It should be noted that, even though not explicitly mentioned in SAE AS4893, an XOS Service may use 4D interfaces to invoke the Operating System or other XOS Services resident within the same GOA stack.SAE AIR5315- 10 -3.3 (Continued):The Res
48、ource Access Layer contains components that directly access the hardware. This layer includes classical device drivers and memory mapped I/O definition translation, for example. The GOA Framework supports the idea that this layer abstracts the remaining layers from the Physical Resources. The 3D int
49、erface is provided between the System Services Layer and the Resource Access Layer to allow the non-processor dependent (i.e., non-I/O dependent) algorithms within the Systems Services Layer to be abstracted from specific Physical Resource Layer implementations.This supports OS and XOS portability between target platforms. The Joint Integrated Avionics Working Group (JIAWG) Input/Output Built-In-Test Description Specification (IOBIDS) specification and the Uniform Device Driver Interface (UDI) interface are example of 3D interfaces. The 2D interface defines th
