1、AEROSPACE STANDARDAS4893Issued 1996-01Reaffirmed 2011-04Generic Open Architecture (GOA) FrameworkFOREWORDThe Generic Open Architecture (GOA) development was initiated to develop a framework which can be used to classify interfaces needed in airborne avionics systems. At the time of the development o
2、f the GOA, development of such a classification was considered a crucial part of transitioning open systems standards to military avionics. However, it was determined during the development of the GOA that the GOA Framework is applicable to domains other than avionics. For that reason the framework
3、is entitled Generic Open Architecture instead of the original name, Generic Open Avionics Architecture (GOAA).The GOA effort was fortunate that a suitable base document existed as a starting point for its definition. The base document for the GOA standard is the Space Generic Open Avionics Architect
4、ure (SGOAA), NASA CR-188269. The SGOAA was produced by Mr. Richard B. Wray and Mr. John R. Stovall of Lockheed Engineering and Sciences Company (LESC), the codevelopers of the avionics architectures and standards represented in NASA CR-188269. The contributions of Mr. Ben Doeckel of LESC who partici
5、pated in early development of the concepts for the avionics architectures and standards represented in the SGOAA is acknowledged. Special acknowledgment is also given to Mr. Dave Pruett of the Johnson Space Center for his support of the Advanced Architecture Analysis, assistance in the development o
6、f the avionics architecture and constructive criticisms of the SGOAA.The GOA is an evolution of the SGOAA. This evolution occurred through the work of several diligent people who made up the SAE AS-5 GOA Task Group. This standard was prepared under the direction of:Chuck Roark Chairman, AS-5 Committ
7、eeTexas Instruments Communications used in standards to indicate text which poses requirements. (Derived from POSIX91) Each section of this document is normative, except for sections 4. Non-normative parts of each section are explicitly indicated.2.5.4 SHALL: Shall, in implementation, indicates a re
8、quirement for implementors.2.5.5 SHOULD: Should, in implementation, indicates a recommendation for implementors, but does not establish a requirement.3. ARCHITECTURE INTERFACE DETAILED REQUIREMENTS:The GOA Framework establishes a structure for hardware, software and interfaces that implement the fun
9、ctions for systems in varying domains. The GOA Framework is a set of nine interface classes partitioned into logical and direct interface classes. This description of the nine required classes includes both system service software and Application Software for systems and subsystems. Interfaces in th
10、is framework are valid for both one platform and multi-platform architectures (if applicable).The frameworks nine interface classes are partitioned into 4 logical and 5 direct interface classes. Logical interfaces define what information is exchanged while direct interfaces define how the informatio
11、n is transported. Figure 1 illustrates a logical interface between Application Software entity A and entity B with the direct interfaces that provide the services to accomplish the information exchange between them. These interface detailed requirements define the GOA Frameworks nine interface class
12、es.This framework is used to organize system (and lower level) requirements and define how those requirements are applied at an appropriate system level to determine the logical and direct interface points. In a given instance of this framework, system logical data flow requirements should be create
13、d for each communicating entity addressing the data attributes needed by that entity or needed to be provided to some other entity. The data flow requirements of the logical interface identify the source of the data and the end-user needing the data, as well as the characteristic attributes required
14、 of the data and the coordination needed by them.SAE AS4893 - 8 -FIGURE 1 - Logical Interfaces are Implemented by Means of Direct Interfaces3. (Continued):Logical data flow requirements should not be concerned with the mechanism for implementing the data interchange. Implementation related requireme
15、nts for the interfaces belong to a direct interface class which defines the mechanisms provided to flow the data from the source to the end-user. Sources of such design requirements for the interfaces, application platform hardware and application platform services should be derived from the Applica
16、tion Software requirements and their logical data attribute requirements based on the users needs.3.1 Architecture Framework Requirements:The GOA Framework consists of nine classes of interfaces as shown in Figure 2, Figure 3, and defined in Table 1. Figure 2 shows the GOA Framework within the conte
17、xt of a POSIX environment, while Figure 3 shows the GOA Framework within the context of two separate application platforms. These classes are the levels of interfaces from Physical Resource up to systems of Application Software which are to be completely defined in an architecture developed in accor
18、dance with this standard. Definition of each interface class shall 1 be in accordance with the requirements contained in the following paragraphs. An architecture that is partitioned within the definition of the nine GOA classes of interface will be consistent with the GOA Framework.SAE AS4893 - 9 -
19、FIGURE 2 - GOA Framework - View 1SAE AS4893 - 10 -FIGURE 3 - GOA Framework - View 2SAE AS4893 - 11 -TABLE 1 - GOA Interface ClassesSAE AS4893 - 12 -3.1 (Continued):The GOA Framework is a hierarchical model. There are four primary GOA layers within the GOA Framework: Application Software, System Serv
20、ices, Resource Access Services, and Physical Resources. The System Services GOA layer consists of two secondary GOA layers: Operating System Services and eXtended Operating System Services.3.1.1 Class 4L - Application Logical Peer Interface Requirements: The application logical peer interface shall
21、1 be a peer to peer information exchange and coordination interface between software applications. This interface may be between Application Software executing on the same application platform or between application software executing on separate application platforms. Since Classes 1D to 4D isolate
22、 the Physical Resources, System Services, and applications in any processor, class 4L shall 2 provide the interface capability for Application Software in any processor to interact with other Application Software executing in any processor. Application logical peer interfaces may also include interf
23、aces between Application Software in two different systems.3.1.2 Class 4D - System Services-to-Applications Direct Interface Requirements: System Services to applications direct interfaces shall 1 provide the direct interface between the Application Software and the System Services (language binding
24、s/specification) executing on the same application platform to allow provision of needed services. Since Classes 1 to 3 isolate the Physical Resources and System Services in all the processors, Class 4D shall 2 provide the interface capability for services in any processor to interact with Applicati
25、on Software executing in the processor.3.1.3 Class 3L - System Service Logical Peer Interface Requirements: System Services logical peer interfaces are the peer to peer interface of System Services. The interface may be within a single application platform or between different application platforms
26、to coordinate operations in a distributed environment. Since classes 1D through 3X isolate the Physical Resources and System Services in each processor, 3L shall 1 provide the interface capability for services in one processor to interact with services in the same or another processor. Local service
27、s and remote services shall 2 have a common logical interface.3.1.4 Class 3X - OS Services-to-XOS Services Direct Interface Requirements: The OS Services to XOS Services direct interface shall 1 consist of the interfaces between the OS Services and the XOS Services that comprise the System Services.
28、 Class 3X provides privileged and other interfaces needed to insure effective XOS Services performance. Class 3X provides the interface necessary to extend a given operating system. This interface supports the modularized expansion of the system services without modifying the given operating system.
29、Class 3X shall 2 provide the direct interfaces between the OS Services to local XOS Services for effective local interprocess communications and support. Although the OS Services are a subset of the System Services, they shall 3 also provide direct low level OS Services access not provided by the 4D
30、 System Services interface for System Services functions requiring this type of interface.SAE AS4893 - 13 -3.1.5 Class 3D - System Services-to-Resource Access Services Direct Interface Requirements:System Services to Resource Access Services direct interfaces shall 1 consist of the interfaces betwee
31、n the System Services to the Resource Access Services. An example of a System Services to Resource Access Services direct interface is the interfaces for low level service drivers that interact with the Physical Resources. For systems in which the Resource Access Services and System Services are imp
32、lemented in software, the 3D interface defines a boundary between the hardware specific portion of the system and the hardware independent portion of the system.3.1.6 Class 2L - Resource Access Services Logical Peer Interface Requirements: Resource Access Services logical peer interfaces shall 1 con
33、sist of the requirements for peer to peer information/data exchange and coordination interface between Resource Access Services within the same application platform or between separate application platforms. This class shall 2 define the interfaces that enable information/data exchange and coordinat
34、ion between the low level service drivers.3.1.7 Class 2D - Resources Access Service-to-Physical Resources Direct Interface Requirements:Resource Access Services to Physical Resources direct interfaces shall 1 consist of the interfaces from the Resource Access Services to the hardware instruction set
35、 architecture (ISA) and register usage.3.1.8 Class 1L - Physical Resources Logical Peer Interface Requirements: Physical Resources logical peer interfaces shall 1 consist of the requirements for establishing a data interchange interface/protocol between Physical Resources enabling communication link
36、 Physical Resources to address their peers.3.1.9 Class 1D - Physical Resources-to-Physical Resources Direct Interface Requirements: The Physical Resources to Physical Resources direct interfaces consist of the nuts and bolts, chips and wires of the system architecture model. This interface shall 1 c
37、onsist of all the Physical Resources to Physical Resources interfaces within each application platform, as well as the Physical Resources interfaces to the external environment.4. NOTES:4.1 Relationship Between GOA, POSIX, and ISO OSI Models:Figure 4 demonstrates how the ISO Open System Interconnect
38、 (OSI) communications model, the POSIX model, and the GOA Framework complement one another. Both the GOA Framework and ISO OSI communications model expand the view of the application platform within the POSIX model. The ISO OSI communications model deals solely with communication where as the GOA Fr
39、amework is not limited to communication.SAE AS4893 - 14 -FIGURE 4 - GOA and POSIX/ISO OSI Model Relationship4.2 Example GOA Framework Application:Figure 5 provides an example application of the GOA Framework using a PCMCIA FAX/modem example. In this example, a Microsoft Windows (MS) based personal c
40、omputer (PC) is the assumed platform, with at least one PCMCIA slot. A FAX/modem PCMCIA card will be plugged into one of the PCMCIA slots for the example. Example Application Software within the PC application platform is a MS Windows based application with FAX/modem services. An example GOA class 4
41、L interface would be the format and structure of a particular FAX to send. There are two types of GOA class 4D interfaces shown in the PC application platform of Figure 5: operating system API interfaces to DOS/Windows and a non-OS API for modem services. Example modem services accessed via this API
42、 would be modem setup, call, send/receive, and FAX. In Figure 5, the GOA class 3X interface for the PC application platform is identical to the 4D interface to OS Services. The GOA 2L and 3L interfaces shown in Figure 5, deal with error handling.SAE AS4893 - 15 -FIGURE 5 - Example GOA Application Us
43、ing PC with PCMCIASAE AS4893 - 16 -4.2 (Continued):In Figure 5, the GOA class 3D interfaces for the PC application platform shown are PCMCIA specific interfaces to drivers and DOS interfaces to drivers. Note that PCMCIA and configuration drivers are identified along side the PC Resource Access Servi
44、ces. The actual driver interface to hardware shown in the PC application platform are the PCMCIA drivers. The GOA class 1D interface between the PC and the FAX/modem card are the physical characteristics of the PCMCIA bus, while the corresponding GOA Class 1L interface are the logical/protocol chara
45、cteristics of the PCMCIA bus.The recursiveness of the GOA Framework is demonstrated by applying the GOA Framework interfaces to the PCMCIA FAX/modem application platform. In addition to the PCMCIA bus 1L and 1D interfaces of the FAX/modem, there are telephone line GOA Class 1L and 1D interfaces. Fig
46、ure 5 shows the Physical Resources of the FAX/modem application platform to include PCMCIA and modem hardware as well as a processor such as the TMSC25. The Resource Access Services for the FAX/modem application platform include PCMCIA and telephone drivers. The Operating System Services for the FAX
47、/modem application platform include a real-time OS, communication, and C support libraries, while the XOS Services includes line control, message data handler, modem CODEC, FAX CODEC, message buffer handler, error handler, and setup. The line control, message data handler, etc. are considered XOS Se
48、rvices due to their peer-to-peer 3L interface with the PC modem XOS services. Note that if the PCMCIA card was considered alone (i.e., not in a system view including the PC platform), then its XOS services could be considered Application Software. Within the PCMCIA card as modeled, there are no 4D i
49、nterfaces and the 3X, 3D, and 2D interface classes are interfaces defined between the XOS services, Operating System Services, Resource Access Services, and Physical Resources as described above.4.3 Example System Architecture Template Using GOA:Figure 6 provides an example architecture template using GOA in a system in which data is input through sensors and results output through displays. The example exhibits the recursiveness of the GOA Framework and introduces the concept of virtual machine interface (VMI) to emphasize the
