1、_ AIR5314AEROSPACEINFORMATIONREPORTIssued 2006-12 Introduction to Generic Open Architecture (GOA) Family of Documents RATIONALEThis document will provide an overview of the structure of the Generic Open Architecture (GOA) family of documents.1. SCOPE The Generic Open Architecture (GOA) Framework fam
2、ily of documents is organized into sets. This is the introductory document for those sets. The GOA family of documents is intended to support the development of affordable systems through the use of open systems concepts. The GOA family of documents is intended to provide input for the systems engin
3、eering process. The documents are applicable to the analysis of existing architectures as well as the development of new system architectures using open systems concepts. The domain specific documents catalog appropriate interface standards and, along with the domain independent documents, define a
4、technical architecture for an associated specific domain. In other words, they provide the “rules and regulations” (i.e., the “building codes”) to be used during the systems engineering process when developing a system architecture for use in that domain. Each domain specific set of documents includ
5、es recommended interface standards, rationale for those standards, and guidance in the application of those standards for a given analysis or development.1.1 Purpose This document provides an overview of the structure of the GOA family of documents. It also outlines the process for maintenance of de
6、fined documents in the GOA family of documents and the process for development of new domain specific extension sets. 1.2 Intended Audience This document describes the structure of the GOA family of documents for anyone that has an interest in understanding or using the GOA Framework. This includes
7、system engineers, hardware engineers, software engineers, engineering managers, project managers, academia, and procurement personnel. Reaffirmed 2011-04SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The
8、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 years at which time it may be reaffirmed, revise
9、d, 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, electronic, mechanical, photocopying, recording, or other
10、wise, 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 input. To provide feedbackon this Technical Report
11、, please visit http:/www.sae.org/technical/standards/AIR5314SAE AIR5314 - 2 -1.3 Document Structure This document is organized as follows: Section 1: Scope - provides an introduction and purpose of this document. Section 2: References - lists documents referenced within this document. Section 3: GOA
12、 Family of Documents Structure - defines the structure and provides an overview of the GOA Family of Documents Set Section 4: GOA Family of Documents Maintenance and Extensions Development Process Appendix A: Domain Catalog Set Documents 2. REFERENCES 2.1 Applicable Documents The following publicati
13、ons form a part of this document to the extent specified herein. The latest issue of SAE publications shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In the event of conflict between the text of this document and references cite
14、d herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. 2.1.1 SAE Publications Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-
15、7323 (inside USA and Canada) or 724-776-4970 (outside USA), www.sae.org.AS4893 Generic Open Architecture (GOA) Framework AIR5315 Overview and Rationale for the Generic Open Architecture (GOA) Framework Standard 2.2 Other Publications JTA 1.0 The Joint Technical Architecture, Version 1.0 Aug 22, 1996
16、 2.3 Definitions 2.3.1 DOMAIN A Domain is a grouping of related items within a certain area of interest. DoD domains include Operational Domains (e.g., joint strike, strategic deterrence) and Functional Domains (e.g., communications, navigation, fire control). (Source: TRI-SERVICE Open Systems Archi
17、tecture Working Group) 2.3.2 PROFILE A standardization document that characterizes the requirements of a standard or group of standards, and specifies how the options and ambiguities in the standard(s) should be interpreted or implemented. (Based on the definition of “functional profile” from Federa
18、l Standard 1031C.) In particular, a profile is a version definition of a baseline standard or group of standards that includes all mandatory items unchanged but specifically includes or eliminates each possible option. It forms a version with options defined. SAE AIR5314 - 3 -2.3.3 REFERENCE MODEL A
19、 generally accepted abstract representation that allows users to focus on establishing definitions, building common understandings and identifying issues for resolution. For Warfare and Warfare Support Systems (WWSS) acquisitions, a reference model is necessary to establish a context for understandi
20、ng how the disparate technologies and standards required to implement WWSS relate to each other. A reference model provides a mechanism for identifying the key issues associated with applications portability, modularity, scalability and interoperability. Most importantly, Reference Models will aid i
21、n the evaluation and analysis of domain-specific architectures. (Source: TRI-SERVICE Open Systems Architecture Working Group) 2.3.4 SUB-SET A standardization document that characterizes some of the requirements of a standard or group of standards, and specifies how the options and ambiguities in the
22、 standard(s) should be interpreted or implemented. In particular, a sub-set is a version definition of a baseline standard that includes only that portion of the mandatory items and options that are pertinent. It forms a new standard without options. 2.3.5 SYSTEM ARCHITECTURE A description, includin
23、g graphics, of systems and interconnections providing for or supporting functions (modified from C4ISR ITF Integrated Architecture Panel, 18 December 1995). The System Architecture defines the physical connection, location, and identification of the key nodes, circuits, networks, platforms, etc., an
24、d specifies system and component performance parameters. It is constructed to satisfy Operational Architecture requirements per standards defined in the Technical Architecture. The System Architecture shows how multiple systems, within a subject area, link and interoperate and may describe the inter
25、nal construction or operations of particular systems within the architecture. (C4 Chiefs Consensus SA Definition, 12 January 1996, as modified at the suggestion of the USD (A&T) community.) (Source: JTA 1.0)2.3.6 TECHNICAL ARCHITECTUREA minimal set of rules governing the arrangement, interaction, an
26、d interdependence of the parts or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The technical architecture identifies the services, interfaces, standards, and their relationships. It provides the technical guidelines for implementation of sys
27、tems upon which engineering specifications are based, common building blocks are built, and product lines are developed. (Source: JTA 1.0) 3. GOA FAMILY OF DOCUMENTS STRUCTURE This GOA family of documents includes domain independent and domain specific documents as shown in Figure 1. The domain inde
28、pendent documents consist of this introduction document plus a set of two documents that define the GOA Framework and associated rationale. The domain specific documents consist of sets of documents for each domain. The SAE has developed the domain independent documents and is developing domain spec
29、ific documents for avionics. It is intended that the structure outlined in this document could also be applied to domain specific documents for other domains. Refer to Appendix A of this document for a list of domain dependent documents and associated status. SAE AIR5314 - 4 -FIGURE 1 - GOA FAMILY O
30、F DOCUMENTS DIAGRAM 3.1 Domain Independent Documents 3.1.1 AIR5314, “Introduction to Generic Open Architecture (GOA) Family of Documents” This document, AIR5314, is an SAE Aerospace Information Report. It is an introduction to the entire GOA family of documents.3.1.2 AS4893, “Generic Open Architectu
31、re (GOA) Framework Standard” AS4893 is an SAE Aerospace Standard. It defines the GOA Framework. It is the first of two documents in the GOA Family Framework Set. It establishes the framework standard but provides minimal rationale and discussion material. The associated companion document of this se
32、t, AIR5315, provides such material. 3.1.3 AIR5315, “Rationale and Overview of Generic Open Architecture (GOA) Framework Standard” AIR5315 is an SAE Aerospace Information Report. It is the second of two documents in the GOA Family Framework Set. It provides discussion and examples to aid in the under
33、standing of the GOA Framework specified in AS4893. 3.2 Domain Dependent Documents The GOA Framework is intended to be an aid in defining Technical Architectures of various domains. To complete the Technical Architecture for a specific domain, a preferred standards catalog is required for the domain.
34、 The GOA Framework, along with the preferred standards catalog for the domain, defines the Technical Architecture for that domain. In order to document the rationale behind the definition and selection of the preferred standards for the domain, an accompanying rationale and overview document is requ
35、ired. To aid in applying the Technical Architecture in the systems engineering process when defining a Systems Architecture, a guidance document is also required for the domain. Therefore, the following domain specific documents are included for each domain adhering to the GOA Family of Documents st
36、ructure: Domain Specific Preferred Standards. This document identifies standard interface profiles for critical interfaces for a domain. It defines these interfaces in terms of the GOA Framework logical and direct interface types and classes. It presents the preferred standards without associated ex
37、planation, discussion, and justification. It will likely contain standards developed by numerous industry standards bodies. It may sub-set existing standards and map them to the direct and logical classes of the GOA Framework. SAE AIR5314 - 5 - Domain Specific Rationale and Overview of the Preferred
38、 Standards. This document for a given domain provides the additional information about the selection and definition of the domain specific preferred standards. It is intended to contain explanation, discussion, justification, and rationale behind the inclusion of preferred standards for the domain.
39、Domain Specific Guidance Document for the Application of the GOA Framework. This document provides domain specific guidance on how to apply the GOA Framework, the preferred standards catalog for the domain, and open systems principles to the systems engineering process when developing a systems arch
40、itecture for the domain. One key item in this document is an example technical architecture for the domain. This example should include typical domain specific critical components and critical interfaces. These three documents form the “domain catalog set” for a given domain. Since these documents w
41、ill evolve through time and may require rapid approval to support their application, each version of these documents is considered a short-lived document that may be continually revised. In SAE terminology, these documents will be of type Aerospace Resource Document (ARD) instead of Aerospace Inform
42、ation Report (AIR) or Aerospace Standard (AS). This means these documents require only committee approval and have a maximum life-time of 2 years (without re-balloting). 4. GOA FAMILY OF DOCUMENTS MAINTENANCE AND EXTENSIONS DEVELOPMENT PROCESS The GOA Framework establishes an architecture reference
43、model. It formally defines concepts of functionality layering plus classes of direct and logical interface types. It is assumed that revisions to the GOA family of documents will be required as documented ambiguities and desired changes are experienced. The following paragraphs are intended to help
44、in this future process of maintenance and extension of the GOA family of documents. 4.1 Maintenance of Domain Independent Documents Three documents have been developed by the SAE AS-5 Committee and will be maintained by the SAE AS-5 Committee in accordance with the SAE guidelines. In particular, the
45、 Appendix A of this document, which provides a “pointer” to the domain specific documents of the family, should be revised as other updates are performed. 4.2 Development of Domain Specific Documents 4.2.1 Domain Definitions A domain is defined if there is a recognized industry forum that develops a
46、nd maintains a GOA “domain catalog set” of documents. For example, SAE ASD is the industry forum responsible for the GOA “Avionics Domain Catalog Set” of documents.4.2.2 Domain Catalog Set Development Process The recommended process for development of a domain catalog set of documents for a specific
47、 domain entails the following steps: 1. Identify Critical Processing Functions. Identify the critical processing functions (hardware, services, support functions, applications) which are typical of the given domain. This is based on experience and review of domain operational requirements and histor
48、ical system developments. These critical functions are those that may be modular, re-useable, and portable. They are candidates for standard interface definitions. 2. Identify Critical Components. De-compose the critical processing functions into critical components that fit into the GOA Framework h
49、ierarchical layers. Some functions may span GOA Framework layers and should be partitioned into components that do not span GOA Framework layers. The identification and organization of these critical components forms the basis for an example or reference architecture for the domain and should be documented and discussed in the guidance document for the domain catalog set of documents. 3. Identify Critical Interfaces. Identify the GOA F
